Azure Files-metadatabuffer mot ein lokal filialbuffer
Ein metadatabuffer på tenestesida reduserer serverarbeidet. Han flyttar ikkje rundturene ut av WAN-et ditt. Samanlikn dei to etter kva dei faktisk forkortar.
For treg Azure Files-tilgang over ein VPN vert to endringar føreslått, og dei forkortar ulike ting. Ein metadatabuffer på tenestesida gjer kvalifiserte operasjonar billegare for serveren. Ein lokal filialbuffer flyttar byta og operasjonane nærare brukaren. Å velje mellom dei ut frå ei prisliste eller ei pressemelding er korleis ei deling blir raskare i ein benchmark og uendra klokka ni om morgonen.
To buffrar, to ulike latenstider
Båe alternativa viser seg under ordet buffer, og det er der forvirringa startar. Dei ligg på kvar si side av nettet.
| 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 rettleiing for SMB-ytelse skildrar metadatabuffring for kvalifiserte SSD-delingar saman med registreringstrinnet som høyrer til. Kvalifikasjon og funksjonstilstand høyrer til den faktiske lagringskontoen, så les den gjeldande sida i staden for ei førehandsvising frå for to år sidan.
Del ventetida i tre delar
Kvar treg mappevisning har tre kostnadskomponentar, og dei svarar på ulike rettingar. Det er handsamingstid per førespurnad på tenestesida, talet på avhengige rundturar over VPN-et og nyttelasta som må flyttast. Ein buffer på tenestesida går laus på den første. Ingenting på serversida går laus på den andre.
Difor kan ei deling vise betre tenestemålingar medan filveljaren til brukaren framleis heng i åtte sekund.
Kvar kvart alternativ fortener plassen sin
Viss arbeidslasta er metadatatung, med mange opningar, stat-kall og mappeoppføringar mot ei kvalifisert SSD-deling, er buffring på tenestesida det billege eksperimentet. Det krev ingen ny infrastruktur og inga endring i korleis brukarane når delinga.
Viss arbeidslasta er interaktiv og latenstidsbunden, er det ærlege valet eit støtta lokalt serverdesign med ein dokumentert synkroniseringsmodell. Det er ein annan arkitektur med eigne driftskostnader, ikkje ein brytar.
Kva ingen av alternativa endrar
SMB-signering og -kryptering gjeld framleis, og dei kostar framleis det dei kostar. Tilgangskontroll blir framleis avgjord per brukar, så ein bufra kopi forenklar ikkje autorisasjonen. Konsistens mellom lokasjonar krev framleis ein definert modell, fordi lokale lesingar i filialen og skrivingar frå skysida må bli samde om noko. Og fråkopla tilgang blir verande ei klientinnstilling, ikkje ein biverknad av ein serverfunksjon.
Når nokon lovar at ein tenestefunksjon fjernar WAN-rundturane, er det påstanden som må testast først.
Mål mot operasjonen brukarane klagar på
Ta tid på den nøyaktige operasjonen i staden for ein syntetisk kopi. Measure-Command { Get-ChildItem \\files\projects -Recurse } på ein filialklient gir eit tal du kan samanlikne før og etter, og Get-SmbMultichannelConnection viser om klienten brukar meir enn éin stig. Set det ved sida av latenstidsmålingane på tenestesida for same vindauge.
Hald delinga, klientplasseringa, VPN-stigen og tryggingspolitikken konstant, elles måler du endringsvindauget ditt i staden for funksjonen. Noter òg filtal og storleiksfordeling, fordi arbeidslaster med små filer og masse kopiering svarar på heilt ulike spakar.
Resultatet som er verdt å ha, er ei endring tilpassa grensa som faktisk var treg, med drifts- og konsistenskostnadene skrivne ned. Eit større lagrings-IOPS-tal på ein slide er ikkje det resultatet.