SMB multicanal por VPN: o que o cliente usa realmente
O SMB multicanal por VPN engade poucos canles: lea as interfaces do cliente, as conexións seleccionadas e o dialecto SMB antes de culpar o túnel dos ficheiros lentos.
O acceso lento aos ficheiros por VPN convida a tomar o axuste multicanal como solución, e a miúdo o axuste non ten con que traballar. Un só adaptador virtual sen RSS non pode repartir o tráfico entre varios canles, diga o que diga a caixa. O que importa é a capacidade que SMB ve nos dous extremos, non a especificación da NIC física do portátil. O percorrido seguinte comeza nunha sesión activa e volve á disposición dos adaptadores.
Comece pola sesión, non pola especificación da NIC
Confirme primeiro que a sesión pode usar o multicanal. A función pertence a SMB3, así que un dialecto máis antigo negociado cun equipo ou un servidor legado descártaa antes de que calquera pregunta sobre o adaptador importe. Despois confirme a que servidor se conectou realmente o cliente, porque un nome que resolve a un nodo distinto do que inspecciona produce un resultado convincente pero irrelevante.
Get-SmbConnection
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbClientNetworkInterfaceO primeiro comando nomea o dialecto, o servidor e o recurso compartido nunha liña. O segundo mostra se o cliente ten a función activada, e o terceiro enumera as interfaces que SMB coñece coas súas capacidades declaradas. Un adaptador virtual que non declara RSS nin RDMA dille en que se pode converter a disposición.
Se o dialecto non é SMB3, detéñase e resolva esa cuestión primeiro. Se non, cada comando posterior describirá unha función que non pode activarse.
Lea as interfaces do cliente con honestidade
A SMB non lle importa que adaptador leva a súa ruta predeterminada; enumera as interfaces que pode usar e avalia cada unha. Un portátil con Wi-Fi, Ethernet e un adaptador VPN pode presentar tres interfaces, e só unha delas pode ser accesible para o servidor co que fala. As demais son candidatas, non canles.
Lea as columnas RSS e RDMA en lugar da columna de velocidade de enlace. Un adaptador virtual adoita declarar unha velocidade nominal alta sen capacidade RSS, e a velocidade nominal describe o enlace virtual, non a ruta por internet. Ningún dos dous números lle di cantos canles usa a sesión.
Se o adaptador non mostra capacidade RSS, a corrección admitida corresponde ao controlador do provedor de VPN, non ás propiedades avanzadas da NIC física. Marcar unha caixa RSS no adaptador de hardware non cambia nada do que o adaptador virtual expón a SMB.
Separe os canles seleccionados das candidatas descubertas
A lista de conexións é a parte que máis se le mal. Coas candidatas non seleccionadas incluídas, a saída mostra todo o que SMB considerou, e iso non é o conxunto de canles que levan datos. Lea o indicador de selección e o número de canles para o par concreto de interfaces de cliente e servidor que lle interesa.
Get-SmbMultichannelConnection -ServerName files.lab.example -IncludeNotSelected
Get-SmbMultichannelConnection -ServerName files.lab.example | Format-List *Substitúa o nome polo do seu servidor. A segunda forma imprime as propiedades das conexións seleccionadas, incluídos os índices de interface e o número actual de canles, que é o número que importa. Varias direccións descubertas nun adaptador seguen sendo un adaptador.
Unha dirección descuberta tamén pode ser inutilizable pola política de VPN: pode ser unha dirección de subrede local que o túnel non transporta, ou unha dirección que o servidor só serve noutra rede. SMB enuméraa como candidata porque a interface existe, non porque a ruta funcione.
Que fai o adaptador VPN coa disposición
Vale a pena distinguir tres disposicións, porque só dúas poden producir máis dun canle. Un só adaptador sen RSS dá un canle. Un só adaptador con RSS pode repartir as conexións entre núcleos. Varios adaptadores utilizables poden producir varios canles mesmo sen RSS, e esa é a configuración que a xente esquece cando supón que RSS é obrigatorio.
| 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 |
A última fila é a que importa por VPN. Os canles que entran todos no mesmo túnel cifrado comparten o caudal do túnel, a CPU da porta de enlace e o enlace WAN. Engadir un canle alí redistribúe traballo sen engadir capacidade, e a medición mostraráo.
Manteña a sinatura e o cifrado activados mentres compara, porque desactivalos cambia o que mide. Un resultado de rendemento que depende de desactivar un axuste de seguridade non é un resultado que poida despregar.
Mida a carga que é realmente lenta
Nomee a carga antes de cambiar nada: unha copia secuencial grande, moitos ficheiros pequenos nun directorio ou unha aplicación que abre e pecha identificadores. O multicanal pode axudar o primeiro caso cando existen rutas independentes reais, e fai moi pouco polo terceiro, porque alí o custo son viaxes de ida e volta dependentes e non o ancho de banda.
Capture unha liña base coa disposición actual, cambie unha cousa e capture de novo co mesmo conxunto de ficheiros e á mesma hora do día. Anote o número de rutas seleccionadas xunto ao valor, para que un lector posterior poida saber se o cambio alterou a disposición ou só a carga.
Se os canles non cambiaron, a cuestión de rendemento está noutro sitio: o custo de cifrado do túnel, a latencia da ruta ou o disco e a CPU do propio servidor. Paga a pena medilo antes de engadir outro adaptador a un portátil que xa ten abondos.