Lėtam Azure Files pasiekimui per VPN siūlomi du pakeitimai, ir jie sutrumpina skirtingus dalykus. Metaduomenų podėlis paslaugos pusėje tinkamas operacijas daro pigesnes serveriui. Vietinis filialo podėlis priartina baitus ir operacijas prie naudotojo. Rinktis tarp jų pagal kainoraštį ar pranešimą spaudai yra kelias, kuriuo bendrinimas tampa greitesnis bandyme ir nepakitęs devintą ryto.

Du podėliai, du skirtingi vėlavimai

Abu variantai pasirodo po žodžiu podėlis, ir čia prasideda painiava. Jie yra priešingose tinklo pusėse.

ChangeWhere it actsWhat it does not imply
Azure Files service metadata cachingThe service's handling of supported metadata operations on eligible sharesNo removal of the client's network round trips
A supported local server or cache designSome content and operations placed nearer the usersNo universal offline access or instant cross-site consistency
Application batching or limited copy concurrencyThe number and overlap of remote operationsNo automatic speedup for every workload

„Microsoft“ SMB našumo gairės aprašo metaduomenų podėliavimą tinkamiems SSD bendrinimams kartu su registracijos veiksmu, kuris prie to pridedamas. Tinkamumas ir funkcijos būsena priklauso nuo faktinės saugyklos paskyros, todėl skaitykite dabartinį puslapį, o ne dvejų metų senumo peržiūros pranešimą.

Padalinkite laukimą į tris dalis

Kiekvienas lėtas katalogo sąrašas turi tris sąnaudų komponentus, ir jie reaguoja į skirtingus sprendimus. Yra užklausos apdorojimo laikas paslaugos pusėje, priklausomų kelionių pirmyn ir atgal per VPN skaičius ir naudingasis krūvis, kurį reikia perkelti. Podėlis paslaugos pusėje atakuoja pirmąjį. Niekas serverio pusėje neatakuoja antrojo.

Štai kodėl bendrinimas gali rodyti geresnes paslaugos metrikas, kol naudotojo failų parinkiklis vis dar stringa aštuonias sekundes.

Kur kiekvienas variantas užsitarnauja savo vietą

Jei darbo krūvis sunkus metaduomenims, su daug atidarymų, stat iškvietimų ir katalogų išvardijimų tinkamam SSD bendrinimui, podėliavimas paslaugos pusėje yra pigus eksperimentas. Jam nereikia naujos infrastruktūros ir jis nekeičia, kaip naudotojai pasiekia bendrinimą.

Jei darbo krūvis interaktyvus ir ribojamas vėlavimo, sąžiningas variantas yra palaikomas vietinio serverio dizainas su dokumentuotu sinchronizavimo modeliu. Tai kita architektūra su savo eksploatacinėmis sąnaudomis, o ne jungiklis.

Ko nekeičia nė vienas variantas

SMB pasirašymas ir šifravimas vis dar taikomi, ir jie vis dar kainuoja tiek, kiek kainuoja. Prieigos kontrolė vis dar sprendžiama kiekvienam naudotojui, todėl podėlyje laikoma kopija nesusipaprastina autorizacijos. Nuoseklumas tarp vietovių vis dar reikalauja apibrėžto modelio, nes vietiniai skaitymai filiale ir rašymai debesies pusėje turi dėl kažko sutarti. O neprisijungusioji prieiga lieka kliento nustatymu, o ne serverio funkcijos šalutiniu poveikiu.

Kai kas nors žada, kad paslaugos funkcija pašalins WAN keliones pirmyn ir atgal, tai yra teiginys, kurį reikia patikrinti pirmiausia.

Matuokite pagal operaciją, kuria skundžiasi naudotojai

Išmatuokite tikslią operaciją, o ne sintetinę kopiją. Measure-Command { Get-ChildItem \\files\projects -Recurse } filialo kliente pateikia skaičių, kurį galite palyginti prieš ir po, o Get-SmbMultichannelConnection parodo, ar klientas naudoja daugiau nei vieną kelią. Padėkite tai šalia paslaugos pusės vėlavimo metrikų tam pačiam langui.

Laikykite bendrinimą, kliento vietą, VPN kelią ir saugumo politiką pastovius, kitaip matuosite savo pakeitimo langą, o ne funkciją. Užrašykite ir failų skaičių bei dydžių pasiskirstymą, nes mažų failų darbo krūviai ir masinis kopijavimas reaguoja į visiškai skirtingas svirtis.

Rezultatas, kurį verta turėti, yra pakeitimas, atitinkantis ribą, kuri iš tikrųjų buvo lėta, su užrašytomis eksploatacinėmis ir nuoseklumo sąnaudomis. Didesnis saugyklos IOPS skaičius skaidrėje nėra tas rezultatas.

Susiję straipsniai