Keširanje metapodataka u Azure Files naspram lokalnog keša podružnice
Keš metapodataka na strani usluge smanjuje rad servera. Ne uklanja povratne ture s vašeg WAN-a. Uporedite ih po tome što zaista 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 kvalifikovane operacije jeftinijim za server. Lokalni keš podružnice pomjera bajtove i operacije bliže korisniku. Biranje između njih prema cjenovniku ili saopštenju za javnost je način da dijeljeni resurs postane brži na testu i nepromijenjen u devet ujutro.
Dva keša, dvije različite latencije
Obje opcije se pojavljuju pod riječju keš i tu počinje zabuna. One stoje 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 kvalifikovana SSD dijeljenja zajedno s korakom registracije koji ide uz to. Kvalifikovanost i stanje funkcije pripadaju stvarnom računu za pohranu, zato čitajte trenutnu 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 reaguju na različita rješenja. Postoji vrijeme obrade zahtjeva na strani usluge, broj zavisnih povratnih tura preko VPN-a i sadržaj koji se mora prenijeti. Keš na strani usluge napada prvo. Ništa na strani servera ne napada drugo.
Zato dijeljeni resurs može pokazivati bolje metrike usluge dok se korisnički birač datoteka i dalje 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 kvalifikovanom 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 dijeljenog resursa.
Ako je radno opterećenje interaktivno i ograničeno latencijom, iskrena opcija je podržani dizajn lokalnog servera s dokumentovanim modelom sinhronizacije. To je druga arhitektura s vlastitim operativnim troškovima, a ne prekidač.
Šta ne mijenja nijedna opcija
Potpisivanje i šifrovanje SMB-a i dalje važe i i dalje koštaju ono što koštaju. Kontrola pristupa se i dalje rješava po korisniku, pa keširana kopija ne pojednostavljuje autorizaciju. Konzistentnost između lokacija i dalje traži definisan model, jer lokalna čitanja u podružnici i upisi sa strane oblaka moraju se složiti oko nečega. A offline pristup ostaje postavka klijenta, ne sporedni efekat serverske funkcije.
Kada neko obeća da serverska funkcija uklanja WAN povratne ture, to je tvrdnja koju prvo treba testirati.
Mjerite prema operaciji na koju se korisnici žale
Izmjerite tačnu operaciju, a ne sintetičku kopiju. Measure-Command { Get-ChildItem \\files\projects -Recurse } na klijentu podružnice daje broj koji možete uporediti prije i poslije, a Get-SmbMultichannelConnection pokazuje koristi li klijent više od jedne putanje. Stavite to uz metrike latencije na strani usluge za isti period.
Držite dijeljeni resurs, lokaciju klijenta, VPN putanju i sigurnosnu politiku konstantnim, inače mjerite svoj prozor promjena, a ne funkciju. Zabilježite i broj datoteka i raspodjelu veličina, jer radna opterećenja s malim datotekama i masovno kopiranje reaguju na potpuno različite poluge.
Rezultat koji vrijedi imati je promjena usklađena s granicom koja je zaista bila spora, s upisanim operativnim troškovima i troškovima konzistentnosti. Veća cifra IOPS pohrane na slajdu nije taj rezultat.