Keš metadát Azure Files verzus miestna keš pobočky
Keš metadát na strane služby znižuje prácu servera. Neodstraňuje však obrátky z vašej WAN. Porovnajte obe možnosti podľa toho, čo skutočne skracujú.
Pre pomalý prístup k Azure Files cez VPN sa navrhujú dve zmeny a každá skracuje niečo iné. Keš metadát na strane služby zlacňuje spôsobilé operácie pre server. Miestna keš pobočky približuje bajty aj operácie používateľovi. Vybrať medzi nimi podľa cenníka alebo tlačovej správy je cesta, ako zdieľaná položka zrýchli v teste a zostane nezmenená o deviatej ráno.
Dve keše, dve rôzne latencie
Obe možnosti sa objavujú pod slovom keš, a práve tam sa začína zmätok. Stoja na opačných stranách siete.
| 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 |
Príručka výkonu SMB od Microsoftu opisuje keš metadát pre spôsobilé zdieľané položky SSD spolu s krokom registrácie, ktorý k tomu patrí. Spôsobilosť a stav funkcie patria skutočnému účtu úložiska, preto čítajte aktuálnu stránku, nie oznámenie náhľadu spred dvoch rokov.
Rozdeľte čakanie na tri časti
Každý pomalý výpis adresára má tri nákladové zložky a tie reagujú na rôzne opravy. Existuje čas spracovania požiadavky na strane služby, počet závislých obrátok cez VPN a údaje, ktoré treba preniesť. Keš na strane služby útočí na prvú. Nič na strane servera neútočí na druhú.
Preto môže zdieľaná položka vykazovať lepšie metriky služby, zatiaľ čo výber súborov u používateľa stále visí osem sekúnd.
Kde si každá možnosť zaslúži svoje miesto
Ak je záťaž náročná na metadáta, s mnohými otvoreniami, volaniami stat a výpismi adresárov voči spôsobilej zdieľanej položke SSD, je keš na strane služby lacný experiment. Nevyžaduje novú infraštruktúru a nemení to, ako sa používatelia k položke dostávajú.
Ak je záťaž interaktívna a obmedzená latenciou, poctivou možnosťou je podporovaný návrh miestneho servera s dokumentovaným modelom synchronizácie. To je iná architektúra s vlastnými prevádzkovými nákladmi, nie prepínač.
Čo nemení ani jedna možnosť
Podpisovanie a šifrovanie SMB stále platia a stále stoja, čo stoja. Riadenie prístupu sa stále rieši pre každého používateľa, takže kešovaná kópia nezjednodušuje autorizáciu. Konzistencia medzi lokalitami stále potrebuje definovaný model, pretože miestne čítania v pobočke a zápisy na strane cloudu sa musia na niečom zhodnúť. A offline prístup zostáva nastavením klienta, nie vedľajším účinkom funkcie servera.
Keď niekto sľubuje, že funkcia služby odstráni obrátky WAN, je to tvrdenie, ktoré treba overiť ako prvé.
Merajte podľa operácie, na ktorú sa používatelia sťažujú
Zmerajte presnú operáciu, nie syntetickú kópiu. Measure-Command { Get-ChildItem \\files\projects -Recurse } na klientskom počítači pobočky dá číslo, ktoré môžete porovnať pred a po, a Get-SmbMultichannelConnection ukáže, či klient používa viac ako jednu cestu. Postavte to vedľa metrík latencie na strane služby za rovnaké okno.
Držte zdieľanú položku, umiestnenie klienta, cestu VPN a bezpečnostnú politiku konštantné, inak meriate svoje okno zmien, nie funkciu. Zaznamenajte aj počet súborov a rozdelenie veľkostí, pretože záťaže s malými súbormi a hromadné kópie reagujú na úplne iné páky.
Výsledok, ktorý stojí za to, je zmena zladená s hranicou, ktorá bola skutočne pomalá, s popísanými prevádzkovými nákladmi a nákladmi na konzistenciu. Väčšie číslo IOPS úložiska na slide nie je tým výsledkom.