SMB multicanal per VPN: què fa servir realment el client
L'SMB multicanal per VPN afegeix pocs canals: llegiu les interfícies del client, les connexions seleccionades i el dialecte SMB abans de culpar el túnel dels fitxers lents.
L'accés lent als fitxers per VPN convida a prendre el paràmetre multicanal com a solució, i sovint el paràmetre no té res amb què treballar. Un sol adaptador virtual sense RSS no pot repartir el trànsit entre diversos canals, faci el que faci la casella. El que importa és la capacitat que veu l'SMB als dos extrems, no l'especificació de la NIC física de l'ordinador portàtil. El recorregut següent comença en una sessió activa i torna a la disposició dels adaptadors.
Comenceu per la sessió, no per l'especificació de la NIC
Primer confirmeu que la sessió pot fer servir el multicanal. La funció pertany a l'SMB3, així que un dialecte més antic negociat amb un aparell o un servidor llegat la descarta abans que qualsevol pregunta sobre l'adaptador sigui rellevant. Després confirmeu a quin servidor s'ha connectat realment el client, perquè un nom que es resol a un node diferent del que inspeccioneu produeix un resultat convincent però irrellevant.
Get-SmbConnection
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbClientNetworkInterfaceLa primera ordre anomena el dialecte, el servidor i el recurs compartit en una línia. La segona mostra si el client té la funció activada, i la tercera llista les interfícies que l'SMB coneix amb les capacitats que declaren. Un adaptador virtual que no declara RSS ni RDMA us diu en què es pot convertir la disposició.
Si el dialecte no és SMB3, atureu-vos i resoleu aquesta qüestió primer. Si no, cada ordre posterior descriurà una funció que no es pot activar.
Llegiu les interfícies del client amb honestedat
A l'SMB no li importa quin adaptador porta la ruta per defecte; enumera les interfícies que pot fer servir i avalua cadascuna. Un portàtil amb Wi-Fi, Ethernet i un adaptador VPN pot presentar tres interfícies, i només una pot ser abastable pel servidor amb qui parleu. Les altres són candidates, no canals.
Llegiu les columnes RSS i RDMA en lloc de la columna de velocitat d'enllaç. Un adaptador virtual sol declarar una velocitat nominal alta sense capacitat RSS, i la velocitat nominal descriu l'enllaç virtual, no el camí per internet. Cap dels dos nombres no us diu quants canals fa servir la sessió.
Si l'adaptador no mostra capacitat RSS, la correcció suportada correspon al controlador del proveïdor de VPN, no a les propietats avançades de la NIC física. Marcar una casella RSS a l'adaptador de maquinari no canvia res del que l'adaptador virtual exposa a l'SMB.
Separeu els canals seleccionats de les candidates descobertes
La llista de connexions és la part que es llegeix malament més sovint. Amb les candidates no seleccionades incloses, la sortida mostra tot el que l'SMB ha considerat, que no és el conjunt de canals que porten dades. Llegiu la marca de selecció i el nombre de canals per al parell concret d'interfícies de client i servidor que us interessa.
Get-SmbMultichannelConnection -ServerName files.lab.example -IncludeNotSelected
Get-SmbMultichannelConnection -ServerName files.lab.example | Format-List *Substituïu el nom del servidor pel vostre. La segona forma imprimeix les propietats de les connexions seleccionades, incloent-hi els índexs d'interfície i el nombre actual de canals, que és el nombre que importa. Diverses adreces descobertes en un adaptador segueixen sent un adaptador.
Una adreça descoberta també pot ser inutilitzable per la política de VPN: pot ser una adreça de subxarxa local que el túnel no transporta, o una adreça que el servidor només serveix en una altra xarxa. L'SMB la llista com a candidata perquè la interfície existeix, no perquè el camí funcioni.
Què fa l'adaptador VPN a la disposició
Val la pena distingir tres disposicions, perquè només dues poden produir més d'un canal. Un sol adaptador sense RSS dóna un canal. Un sol adaptador amb RSS pot repartir les connexions entre nuclis. Diversos adaptadors utilitzables poden produir diversos canals fins i tot sense RSS, i aquesta és la configuració que la gent oblida quan suposa que RSS és obligatori.
| Layout SMB sees | Channels possible |
|---|---|
| One adapter, no RSS | One |
| One adapter with RSS | Several, spread across cores |
| Two or more usable adapters | Several, one path per adapter |
| Several adapters behind one tunnel | Several, one shared bottleneck |
L'última fila és la que importa per VPN. Els canals que entren tots al mateix túnel xifrat comparteixen el cabal del túnel, la CPU de la passarel·la i l'enllaç WAN. Afegir-hi un canal redistribueix feina sense afegir capacitat, i la mesura ho mostrarà.
Manteniu la signatura i el xifratge activats mentre compareu, perquè desactivar-los canvia el que mesureu. Un resultat de rendiment que depèn de desactivar un paràmetre de seguretat no és un resultat que pugueu desplegar.
Mesureu la càrrega que és realment lenta
Anomeneu la càrrega abans de canviar res: una còpia seqüencial gran, molts fitxers petits en un directori o una aplicació que obre i tanca handles. El multicanal pot ajudar el primer cas quan existeixen camins independents reals, i fa molt poc pel tercer, perquè allà el cost és viatges d'anada i tornada dependents i no ample de banda.
Captureu una línia de base amb la disposició actual, canvieu una cosa i torneu a capturar amb el mateix conjunt de fitxers i la mateixa hora del dia. Anoteu el nombre de camins seleccionats al costat del nombre, perquè un lector posterior pugui saber si el canvi va alterar la disposició o només la càrrega.
Si els canals no han canviat, la qüestió de rendiment és en un altre lloc: el cost del xifratge del túnel, la latència del camí o el disc i la CPU del servidor. Val la pena mesurar-ho abans d'afegir un altre adaptador a un portàtil que ja en té prou.