Azure Files-metadatabuffer mot en lokal filialbuffer
En metadatabuffer på tjenestesiden reduserer serverarbeidet. Den flytter ikke rundturene ut av WAN-et ditt. Sammenlign de to etter hva de faktisk forkorter.
For treg Azure Files-tilgang over en VPN foreslås to endringer, og de forkorter forskjellige ting. En metadatabuffer på tjenestesiden gjør kvalifiserte operasjoner billigere for serveren. En lokal filialbuffer flytter bytene og operasjonene nærmere brukeren. Å velge mellom dem ut fra en prisliste eller en pressemelding er hvordan en deling blir raskere i en benchmark og uendret klokken ni om morgenen.
To buffere, to forskjellige latenstider
Begge alternativene vises under ordet buffer, og det er der forvirringen starter. De ligger på hver sin side av nettverket.
| 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 |
Microsofts veiledning for SMB-ytelse beskriver metadatabuffering for kvalifiserte SSD-delinger sammen med registreringstrinnet som hører til. Kvalifikasjon og funksjonstilstand tilhører den faktiske lagringskontoen, så les den gjeldende siden i stedet for en forhåndsvisningsmelding fra for to år siden.
Del ventetiden i tre deler
Hver treg mappevisning har tre kostnadskomponenter, og de reagerer på forskjellige rettelser. Det er behandlingstid per forespørsel på tjenestesiden, antallet avhengige rundturer over VPN-et og nyttelasten som må flyttes. En buffer på tjenestesiden angriper den første. Ingenting på serversiden angriper den andre.
Derfor kan en deling vise bedre tjenestemålinger mens brukerens filvelger fortsatt henger i åtte sekunder.
Hvor hvert alternativ fortjener plassen sin
Hvis arbeidsbelastningen er metadatatung, med mange åpninger, stat-kall og mappeoppføringer mot en kvalifisert SSD-deling, er buffering på tjenestesiden det billige eksperimentet. Det krever ingen ny infrastruktur og ingen endring i hvordan brukerne når delingen.
Hvis arbeidsbelastningen er interaktiv og latenstidsbundet, er det ærlige valget et støttet lokalt serverdesign med en dokumentert synkroniseringsmodell. Det er en annen arkitektur med egne driftskostnader, ikke en bryter.
Hva ingen av alternativene endrer
SMB-signering og -kryptering gjelder fortsatt, og de koster fortsatt det de koster. Tilgangskontroll avgjøres fortsatt per bruker, så en bufret kopi forenkler ikke autorisasjonen. Konsistens mellom lokasjoner krever fortsatt en definert modell, fordi lokale lesinger i filialen og skrivinger fra skysiden må bli enige om noe. Og frakoblet tilgang forblir en klientinnstilling, ikke en bivirkning av en serverfunksjon.
Når noen lover at en tjenestefunksjon fjerner WAN-rundturene, er det påstanden som må testes først.
Mål mot operasjonen brukerne klager på
Ta tid på den nøyaktige operasjonen i stedet for en syntetisk kopi. Measure-Command { Get-ChildItem \\files\projects -Recurse } på en filialklient gir et tall du kan sammenligne før og etter, og Get-SmbMultichannelConnection viser om klienten bruker mer enn én sti. Sett det ved siden av latenstidsmålingene på tjenestesiden for samme vindu.
Hold delingen, klientplasseringen, VPN-stien og sikkerhetspolicyen konstant, ellers måler du endringsvinduet ditt i stedet for funksjonen. Noter også filantall og størrelsesfordeling, fordi arbeidsbelastninger med små filer og masse kopiering reagerer på helt forskjellige spaker.
Resultatet som er verdt å ha, er en endring tilpasset grensen som faktisk var treg, med drifts- og konsistenskostnadene skrevet ned. Et større lagrings-IOPS-tall på en lysbilde er ikke det resultatet.