Azure Files-metadatacache kontra en lokal filialcache
En metadatacache på tjänstesidan minskar serverarbetet. Den flyttar inte rundturerna från ditt WAN. Jämför de två efter vad de faktiskt förkortar.
För långsam Azure Files-åtkomst över ett VPN föreslås två ändringar, och de förkortar olika saker. En metadatacache på tjänstesidan gör kvalificerade operationer billigare för servern. En lokal filialcache flyttar byten och operationerna närmare användaren. Att välja mellan dem utifrån en prislista eller ett pressmeddelande är hur en delning blir snabbare i ett test och oförändrad klockan nio på morgonen.
Två cachar, två olika latenser
Båda alternativen visas under ordet cache, och det är där förvirringen börjar. De ligger på var sin sida av nätverket.
| 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 vägledning för SMB-prestanda beskriver metadatacachning för kvalificerade SSD-delningar tillsammans med registreringssteget som hör till. Kvalificering och funktionsstatus tillhör det faktiska lagringskontot, så läs den aktuella sidan i stället för ett förhandsvisningsmeddelande från för två år sedan.
Dela upp väntetiden i tre delar
Varje långsam kataloglistning har tre kostnadskomponenter, och de svarar på olika åtgärder. Det finns behandlingstid per begäran på tjänstesidan, antalet beroende rundturer över VPN:et och nyttolasten som måste flyttas. En cache på tjänstesidan angriper den första. Ingenting på serversidan angriper den andra.
Därför kan en delning visa bättre tjänstemått medan användarens filväljare fortfarande hänger i åtta sekunder.
Var varje alternativ förtjänar sin plats
Om arbetsbelastningen är metadatatung, med många öppningar, stat-anrop och kataloguppräkningar mot en kvalificerad SSD-delning, är cachning på tjänstesidan det billiga experimentet. Det kräver ingen ny infrastruktur och ingen ändring av hur användarna når delningen.
Om arbetsbelastningen är interaktiv och latensbunden är det ärliga valet en stödd lokal serverdesign med en dokumenterad synkroniseringsmodell. Det är en annan arkitektur med egna driftskostnader, inte en strömbrytare.
Vad inget av alternativen ändrar
SMB-signering och -kryptering gäller fortfarande, och de kostar fortfarande vad de kostar. Åtkomstkontroll avgörs fortfarande per användare, så en cachad kopia förenklar inte auktoriseringen. Konsistens mellan platser kräver fortfarande en definierad modell, eftersom lokala läsningar i filialen och skrivningar från molnsidan måste komma överens om något. Och offlineåtkomst förblir en klientinställning, inte en bieffekt av en serverfunktion.
När någon lovar att en tjänstefunktion tar bort WAN-rundturerna, är det påståendet som måste testas först.
Mät mot operationen som användarna klagar på
Ta tid på den exakta operationen i stället för en syntetisk kopia. Measure-Command { Get-ChildItem \\files\projects -Recurse } på en filialklient ger ett tal du kan jämföra före och efter, och Get-SmbMultichannelConnection visar om klienten använder mer än en väg. Sätt det bredvid latensmåtten på tjänstesidan för samma fönster.
Håll delningen, klientplatsen, VPN-vägen och säkerhetspolicyn konstant, annars mäter du ditt ändringsfönster i stället för funktionen. Notera också filantal och storleksfördelning, eftersom arbetsbelastningar med små filer och masskopior reagerar på helt olika spakar.
Det resultat som är värt att ha är en ändring anpassad till gränsen som faktiskt var långsam, med drifts- och konsistenskostnaderna nedskrivna. En större lagrings-IOPS-siffra på en bild är inte det resultatet.