Keširanje metapodataka u Azure Files nasuprot lokalnom kešu podružnice
Keš metapodataka na strani usluge smanjuje rad poslužitelja. Ne uklanja povratna putovanja s vašeg WAN-a. Usporedite ih po tome što doista skraćuju.
Za spor pristup Azure Files putem VPN-a predlažu se dvije promjene i one skraćuju različite stvari. Keširanje metapodataka na strani usluge čini prihvatljive operacije jeftinijima za poslužitelj. Lokalni keš podružnice približava bajtove i operacije korisniku. Biranje između njih prema cjeniku ili priopćenju za javnost jest način na koji dijeljeni resurs postane brži na testu i nepromijenjen u devet ujutro.
Dva keša, dvije različite latencije
Obje se opcije pojavljuju pod riječju keš i tu počinje zabuna. Nalaze se na suprotnim stranama mreže.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Microsoftove smjernice za performanse SMB-a opisuju keširanje metapodataka za prihvatljiva SSD dijeljenja zajedno s korakom registracije koji ide uz to. Prihvatljivost i stanje značajke pripadaju stvarnom računu za pohranu, zato čitajte trenutačnu stranicu, a ne najavu pregleda od prije dvije godine.
Podijelite čekanje na tri dijela
Svaki spor popis direktorija ima tri komponente troška i one reagiraju na različita rješenja. Postoji vrijeme obrade zahtjeva na strani usluge, broj ovisnih povratnih putovanja preko VPN-a i sadržaj koji se mora prenijeti. Keš na strani usluge napada prvo. Ništa na strani poslužitelja ne napada drugo.
Zato dijeljeni resurs može pokazivati bolje metrike usluge dok se korisnički birač datoteka još uvijek zamrzava na osam sekundi.
Gdje svaka opcija zaslužuje svoje mjesto
Ako je radno opterećenje teško na metapodacima, s mnogo otvaranja, poziva stat i nabrajanja direktorija prema prihvatljivom SSD dijeljenju, keširanje na strani usluge je jeftin eksperiment. Ne traži novu infrastrukturu i ne mijenja način na koji korisnici dolaze do dijeljenja.
Ako je radno opterećenje interaktivno i ograničeno latencijom, iskrena je opcija podržani dizajn lokalnog poslužitelja s dokumentiranim modelom sinkronizacije. To je druga arhitektura s vlastitim operativnim troškovima, a ne prekidač.
Što ne mijenja nijedna opcija
Potpisivanje i šifriranje SMB-a i dalje vrijede i i dalje koštaju ono što koštaju. Kontrola pristupa i dalje se rješava po korisniku, pa keširana kopija ne pojednostavljuje autorizaciju. Konzistentnost između lokacija i dalje traži definiran model, jer se lokalna čitanja u podružnici i upisi sa strane oblaka moraju složiti oko nečega. A izvanmrežni pristup ostaje postavka klijenta, a ne nuspojava značajke poslužitelja.
Kada netko obeća da značajka usluge uklanja WAN povratna putovanja, to je tvrdnja koju treba prvo testirati.
Mjerite prema operaciji na koju se korisnici žale
Izmjerite točnu operaciju, a ne sintetičku kopiju. Measure-Command { Get-ChildItem \\files\projects -Recurse } na klijentu podružnice daje broj koji možete usporediti prije i poslije, a Get-SmbMultichannelConnection pokazuje koristi li klijent više od jednog puta. Stavite to uz metrike latencije na strani usluge za isti period.
Držite dijeljenje, lokaciju klijenta, VPN put i sigurnosnu politiku konstantnima, inače mjerite svoj prozor promjena, a ne značajku. Zabilježite i broj datoteka i raspodjelu veličina, jer radna opterećenja s malim datotekama i masovno kopiranje reagiraju na posve različite poluge.
Rezultat koji vrijedi imati jest promjena usklađena s granicom koja je doista bila spora, s upisanim operativnim troškovima i troškovima konzistentnosti. Veća brojka IOPS pohrane na slajdu nije taj rezultat.