SMB-plurkanala tra VPN: kion la kliento efektive uzas

Malrapida dosieraliro tra VPN invitadas uzi la agordon de plurkanaleco kiel solvon, kaj la agordo ofte havas nenion kun kio labori. Unu sola virtuala adaptilo sen RSS ne povas disdoni trafikon trans pluraj kanaloj, kion ajn la markobutono diras. Gravas la kapablo, kiun SMB vidas ĉe ambaŭ finoj, ne la specifoj de la fizika retkarto de la tekkomputilo. La sekva trairo komenciĝas ĉe aktiva seanco kaj reiras al la adaptila aranĝo.

Komencu ĉe la seanco, ne ĉe la specifoj de la retkarto

Unue konfirmu, ke la seanco entute povas uzi plurkanalecon. La funkcio apartenas al SMB3, do pli malnova dialekto intertraktita kun aparato aŭ malnova servilo ekskludas ĝin antaŭ ol iu ajn adaptila demando gravas. Poste konfirmu, al kiu servilo la kliento efektive konektiĝis, ĉar nomo, kiu solviĝas al alia nodo ol tiu, kiun vi inspektas, donas konvinkan sed nerelevantan rezulton.

Get-SmbConnection
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbClientNetworkInterface

La unua komando nomas la dialekton, la servilon kaj la kunhavon en unu linio. La dua montras, ĉu la funkcio estas ŝaltita ĉe la kliento, kaj la tria listigas la interfacojn, kiujn SMB konas, kun iliaj raportitaj kapabloj. Virtuala adaptilo, kiu raportas nek RSS nek RDMA, diras al vi, kion la aranĝo povas fariĝi.

Se la dialekto ne estas SMB3, haltu kaj unue solvu tiun demandon. Alie ĉiu posta komando priskribos funkcion, kiu ne povas ekfunkcii.

Legu la interfacojn de la kliento honeste

SMB ne zorgas, kiu adaptilo portas vian defaŭltan vojon; ĝi listigas la interfacojn, kiujn ĝi povas uzi, kaj taksas ĉiun. Tekkomputilo kun Wi-Fi, Ethernet kaj VPN-adaptilo povas prezenti tri interfacojn, kaj nur unu el ili eble estas atingebla por la servilo, kun kiu vi parolas. La aliaj estas kandidatoj, ne kanaloj.

Legu la kolumnojn RSS kaj RDMA anstataŭ la kolumno pri liga rapideco. Virtuala adaptilo kutime raportas altan nominalan rapidon sen RSS-kapablo, kaj la nominala rapido priskribas la virtualan ligon, ne la vojon tra la interreto. Neniom da tiuj du nombroj diras, kiom da kanaloj la seanco uzas.

Se la adaptilo montras neniun RSS-kapablon, la subtenata korekto apartenas al la pelilo de la VPN-provizanto, ne al la altnivelaj propraĵoj de la fizika retkarto. Marki RSS-butonon ĉe la aparatara adaptilo ŝanĝas nenion en tio, kion la virtuala adaptilo malkaŝas al SMB.

Apartigu elektitajn kanalojn disde malkovritaj kandidatoj

La konekta listo estas la parto plej ofte mislegata. Kun malkovritaj neelektitaj kandidatoj, la eligo montras ĉion, kion SMB konsideris, kaj tio ne estas la aro de kanaloj portantaj datumojn. Legu la elekton-flagon kaj la kanalan nombron por la konkreta paro de klienta kaj servila interfacoj, kiu vin interesas.

Get-SmbMultichannelConnection -ServerName files.lab.example -IncludeNotSelected
Get-SmbMultichannelConnection -ServerName files.lab.example | Format-List *

Anstataŭigu per via propra servila nomo. La dua formo presas la propraĵojn de la elektitaj konektoj, inkluzive de la interfacaj indeksoj kaj la nuna kanala nombro, kiu estas la nombro, kiu gravas. Pluraj malkovritaj adresoj sur unu adaptilo restas unu adaptilo.

Malkovrita adreso ankaŭ povas esti neuzebla pro la VPN-politiko: ĝi povas esti loka subreta adreso, kiun la tunelo ne portas, aŭ adreso, kiun la servilo nur servas en alia reto. SMB listigas ĝin kiel kandidaton ĉar la interfaco ekzistas, ne ĉar la vojo funkcias.

Kion la VPN-adaptilo faras al la aranĝo

Tri aranĝojn indas distingi, ĉar nur du el ili povas produkti pli ol unu kanalon. Unu adaptilo sen RSS donas unu kanalon. Unu RSS-kapabla adaptilo povas disdoni konektojn trans kernoj. Pluraj uzeblaj adaptiloj povas produkti plurajn kanalojn eĉ sen RSS, kaj tio estas la agordo, kiun homoj forgesas kiam ili supozas, ke RSS estas deviga.

La lasta vico estas tiu, kiu gravas tra VPN. Kanaloj, kiuj ĉiuj eniras la saman ĉifritan tunelon, dividas la trairon de la tunelo, la CPU de la kluzo kaj la WAN-ligon. Aldoni kanalon tie redistribuas laboron sen aldoni kapaciton, kaj la mezurado montros tion.

Tenu subskribadon kaj ĉifradon ŝaltitaj dum vi komparas, ĉar malŝalti ilin ŝanĝas tion, kion vi mezuras. Agadrezultaĵo, kiu dependas de malŝalto de sekureca agordo, ne estas rezultaĵo, kiun vi povas deploji.

Mezuru la laborŝarĝon, kiu efektive estas malrapida

Nomu la laborŝarĝon antaŭ ol ŝanĝi ion ajn: unu granda sinsekva kopio, multaj malgrandaj dosieroj en unu dosierujo, aŭ aplikaĵo, kiu malfermas kaj fermas tenilojn. Plurkanaleco povas helpi la unuan kazon, kiam ekzistas vere sendependaj vojoj, kaj faras tre malmulte por la tria, ĉar tie la kosto estas dependaj reiroj anstataŭ bendlarĝo.

Registru bazlinion kun la nuna aranĝo, ŝanĝu unu aferon, kaj registru denove kun la sama dosieraro kaj la sama horo de la tago. Notu la nombron de elektitaj vojoj apud la nombro, por ke posta leganto povu scii, ĉu la ŝanĝo modifis la aranĝon aŭ nur la ŝarĝon.

Se la kanaloj ne ŝanĝiĝis, la agaddemando estas aliloke: la ĉifrada superkosto de la tunelo, la latento de la vojo, aŭ la propra disko kaj CPU de la servilo. Indas mezuri tion antaŭ ol aldoni ankoraŭ unu adaptilon al tekkomputilo, kiu jam havas sufiĉe da ili.