Keš metadat Azure Files versus místní keš pobočky
Keš metadat na straně služby snižuje práci serveru. Neodstraňuje však obrátky přes vaši WAN. Porovnejte obě možnosti podle toho, co skutečně zkracují.
Pro pomalý přístup k Azure Files přes VPN se navrhují dvě změny a každá zkracuje něco jiného. Keš metadat na straně služby zlevňuje způsobilé operace pro server. Místní keš pobočky přibližuje bajty i operace uživateli. Vybrat mezi nimi podle ceníku nebo tiskové zprávy je cesta, jak sdílená složka zrychí v testu a zůstane beze změny v devět ráno.
Dvě keše, dvě různé latence
Obě možnosti se objevují pod slovem keš, a právě tam začíná zmatek. Stojí na opačných stranách sítě.
| 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 |
Příručka výkonu SMB od Microsoftu popisuje keš metadat pro způsobilé sdílené složky SSD spolu s krokem registrace, který k tomu patří. Způsobilost a stav funkce náleží skutečnému účtu úložiště, proto čtěte aktuální stránku, ne oznámení náhledu z doby před dvěma lety.
Rozdělte čekání na tři části
Každý pomalý výpis adresáře má tři nákladové složky a ty reagují na různé opravy. Existuje doba zpracování požadavku na straně služby, počet závislých obrátek přes VPN a data, která je třeba přenést. Keš na straně služby útočí na první. Nic na straně serveru neútočí na druhou.
Proto může sdílená složka vykazovat lepší metriky služby, zatímco volič souborů u uživatele stále visí osm sekund.
Kde si každá možnost zaslouží své místo
Pokud je zátěž náročná na metadata, s mnoha otevřeními, voláními stat a výpisy adresářů vůči způsobilé sdílené složce SSD, je keš na straně služby levný experiment. Nevyžaduje novou infrastrukturu a nemění to, jak se uživatelé ke složce dostávají.
Pokud je zátěž interaktivní a omezená latencí, poctivou možností je podporovaný návrh místního serveru s dokumentovaným modelem synchronizace. To je jiná architektura s vlastními provozními náklady, ne přepínač.
Co nemění ani jedna možnost
Podepisování a šifrování SMB stále platí a stále stojí, co stojí. Řízení přístupu se stále řeší pro každého uživatele, takže kešovaná kopie nezjednodušuje autorizaci. Konzistence mezi lokalitami stále potřebuje definovaný model, protože místní čtení v pobočce a zápisy na straně cloudu se musí na něčem shodnout. A offline přístup zůstává nastavením klienta, ne vedlejším účinkem funkce serveru.
Když někdo slibuje, že funkce služby odstraní obrátky WAN, je to tvrzení, které je třeba ověřit jako první.
Měřte podle operace, na kterou si uživatelé stěžují
Změřte přesnou operaci, ne syntetickou kopii. Measure-Command { Get-ChildItem \\files\projects -Recurse } na klientském počítači pobočky dá číslo, které můžete porovnat před a po, a Get-SmbMultichannelConnection ukáže, zda klient používá více než jednu cestu. Postavte to vedle metrik latence na straně služby za stejné okno.
Držte sdílenou složku, umístění klienta, cestu VPN a bezpečnostní politiku konstantní, jinak měříte své okno změn, ne funkci. Zaznamenejte také počet souborů a rozdělení velikostí, protože zátěže s malými soubory a hromadné kopie reagují na zcela jiné páky.
Výsledek, který stojí za to, je změna sladěná s hranicí, která byla skutečně pomalá, s popsanými provozními náklady a náklady na konzistenci. Větší číslo IOPS úložiště na slidu tím výsledkem není.