SMB Multichannel via een VPN: wat de client werkelijk gebruikt
SMB Multichannel via een VPN voegt weinig kanalen toe: lees de interfaces van de client, de geselecteerde verbindingen en de SMB-dialect voordat u de tunnel de schuld geeft van trage bestanden.
Trage bestandstoegang via een VPN verleidt ertoe de Multichannel-instelling als oplossing te zien, en vaak heeft de instelling niets om mee te werken. Eén virtuele adapter zonder RSS kan verkeer niet over meerdere kanalen verdelen, wat het selectievakje ook zegt. Wat telt is de capaciteit die SMB aan beide uiteinden ziet, niet de specificatie van de fysieke NIC van de laptop. De uitleg hieronder begint bij een actieve sessie en werkt terug naar de adapterindeling.
Begin bij de sessie, niet bij de NIC-specificatie
Bevestig eerst dat de sessie überhaupt Multichannel kan gebruiken. De functie hoort bij SMB3, dus een oudere dialect die met een apparaat of een oude server is onderhandeld sluit dit uit voordat enige adaptvraag relevant wordt. Bevestig daarna met welke server de client werkelijk is verbonden, want een naam die naar een ander knooppunt resolveert dan het knooppunt dat u onderzoekt, levert een overtuigend maar irrelevant resultaat op.
Get-SmbConnection
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbClientNetworkInterface
De eerste opdracht noemt de dialect, de server en de share op één regel. De tweede laat zien of de functie op de client is ingeschakeld, en de derde somt de interfaces op die SMB kent, met hun gerapporteerde mogelijkheden. Een virtuele adapter die geen RSS en geen RDMA rapporteert, vertelt u wat de indeling kan worden.
Als de dialect niet SMB3 is, stop dan en los eerst die vraag op. Anders beschrijft elke latere opdracht een functie die niet kan aangrijpen.
Lees de interfaces van de client eerlijk
SMB interesseert het niet welke adapter uw standaardroute draagt; het somt de interfaces op die het kan gebruiken en beoordeelt elk ervan. Een laptop met Wi-Fi, Ethernet en een VPN-adapter kan drie interfaces presenteren, en slechts één daarvan is mogelijk bereikbaar voor de server waarmee u spreekt. De andere zijn kandidaten, geen kanalen.
Lees de kolommen RSS en RDMA in plaats van de kolom voor linksnelheid. Een virtuele adapter rapporteert vaak een hoge nominale snelheid zonder RSS-capaciteit, en de nominale snelheid beschrijft de virtuele verbinding, niet het pad via internet. Geen van beide getallen vertelt u hoeveel kanalen de sessie gebruikt.
Als de adapter geen RSS-capaciteit toont, hoort de ondersteunde oplossing bij het stuurprogramma van de VPN-leverancier, niet bij de geavanceerde eigenschappen van de fysieke NIC. Een RSS-vakje aanvinken op de hardware-adapter verandert niets aan wat de virtuele adapter aan SMB toont.
Onderscheid geselecteerde kanalen van ontdekte kandidaten
De verbindingslijst is het deel dat het vaakst verkeerd wordt gelezen. Met niet-geselecteerde kandidaten meegerekend toont de uitvoer alles wat SMB heeft overwogen, en dat is niet de verzameling kanalen die gegevens draagt. Lees de selectievlag en het kanaalaantal voor het specifieke paar client- en serverinterfaces dat u interesseert.
Get-SmbMultichannelConnection -ServerName files.lab.example -IncludeNotSelected
Get-SmbMultichannelConnection -ServerName files.lab.example | Format-List *
Vervang dit door uw eigen servernaam. De tweede vorm drukt de eigenschappen van de geselecteerde verbindingen af, inclusief de interface-indexen en het huidige kanaalaantal, en dat is het getal dat ertoe doet. Meerdere ontdekte adressen op één adapter zijn nog steeds één adapter.
Een ontdekt adres kan ook onbruikbaar zijn door het VPN-beleid: het kan een lokaal subnetadres zijn dat de tunnel niet draagt, of een adres dat de server alleen op een ander netwerk bedient. SMB vermeldt het als kandidaat omdat de interface bestaat, niet omdat het pad werkt.
Wat de VPN-adapter met de indeling doet
Drie indelingen zijn het waard om te onderscheiden, want slechts twee ervan kunnen meer dan één kanaal opleveren. Eén adapter zonder RSS levert één kanaal. Eén adapter met RSS kan verbindingen over cores verdelen. Meerdere bruikbare adapters kunnen ook zonder RSS meerdere kanalen opleveren, en dat is de configuratie die mensen vergeten wanneer zij aannemen dat RSS verplicht is.
| 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 |
De laatste rij is degene die via een VPN telt. Kanalen die allemaal dezelfde versleutelde tunnel in gaan, delen de doorvoer van de tunnel, de CPU van de gateway en de WAN-verbinding. Daar een kanaal toevoegen herverdeelt werk zonder capaciteit toe te voegen, en de meting zal het laten zien.
Houd ondertekening en versleuteling ingeschakeld terwijl u vergelijkt, want ze uitschakelen verandert wat u meet. Een prestatie-resultaat dat afhangt van het uitschakelen van een beveiligingsinstelling is geen resultaat dat u kunt uitrollen.
Meet de werklast die werkelijk traag is
Noem de werklast voordat u iets verandert: één grote sequentiële kopie, veel kleine bestanden in één map, of een toepassing die handles opent en sluit. Multichannel kan het eerste geval helpen wanneer er echt onafhankelijke paden bestaan, en doet voor het derde heel weinig, omdat de kosten daar afhankelijke retouren zijn in plaats van bandbreedte.
Leg een basislijn vast met de huidige indeling, wijzig één ding en leg opnieuw vast met dezelfde bestandsset en op hetzelfde moment van de dag. Noteer het aantal geselecteerde paden naast het getal, zodat een latere lezer kan zien of de wijziging de indeling of alleen de belasting heeft veranderd.
Als de kanalen niet zijn veranderd, ligt de prestatievraag elders: de versleutelingskosten van de tunnel, de latentie van het pad, of de schijf en CPU van de server zelf. Dat is het meten waard voordat er nog een adapter aan een laptop wordt toegevoegd die er al genoeg heeft.