Azure Files-metadatacache versus een lokale branchcache
Een metadatacache aan de servicekant vermindert het werk van de server. Hij haalt de roundtrips niet uit uw WAN. Vergelijk de twee op wat ze werkelijk verkorten.
Voor langzame Azure Files-toegang via een VPN worden twee wijzigingen voorgesteld, en ze verkorten verschillende dingen. Een metadatacache aan de servicekant maakt geschikte bewerkingen goedkoper voor de server. Een lokale branchcache brengt de bytes en de bewerkingen dichter bij de gebruiker. Kiezen tussen beide op basis van een prijslijst of een persbericht is hoe een share sneller wordt in een benchmark en om negen uur 's ochtends onveranderd blijft.
Twee caches, twee verschillende latenties
Beide opties verschijnen onder het woord cache, en daar begint de verwarring. Ze zitten aan weerszijden van het netwerk.
| 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 SMB-prestatiehandleiding beschrijft metadatacaching voor geschikte SSD-shares, samen met de registratiestap die daarbij hoort. Geschiktheid en functiestatus horen bij het werkelijke opslagaccount, dus lees de huidige pagina en niet een preview-aankondiging van twee jaar geleden.
Deel de wachttijd in drie delen
Elke langzame directorylijst heeft drie kostencomponenten, en ze reageren op verschillende correcties. Er is verwerkingstijd per aanvraag aan de servicekant, het aantal afhankelijke roundtrips over de VPN en de payload die moet worden verplaatst. Een cache aan de servicekant valt de eerste aan. Niets aan de serverkant valt de tweede aan.
Daarom kan een share betere servicemetrieken tonen terwijl de bestandskiezer van de gebruiker nog acht seconden hangt.
Waar elke optie zijn plek verdient
Als de werkbelasting metadataintensief is, met veel openingen, stat-aanroepen en directory-opsommingen tegen een geschikte SSD-share, is caching aan de servicekant het goedkope experiment. Het vereist geen nieuwe infrastructuur en verandert niets aan hoe gebruikers de share bereiken.
Als de werkbelasting interactief en latentiegebonden is, is een ondersteund lokaal serverontwerp met een gedocumenteerd synchronisatiemodel de eerlijke optie. Dat is een andere architectuur met eigen operationele kosten, geen schakelaar.
Wat geen van beide opties verandert
SMB-ondertekening en -versleuteling gelden nog steeds, en ze kosten nog steeds wat ze kosten. Toegangsbeheer wordt nog steeds per gebruiker bepaald, dus een gecachte kopie vereenvoudigt de autorisatie niet. Consistentie tussen locaties vereist nog steeds een gedefinieerd model, omdat lokale leesacties in de branch en schrijfacties aan de cloudkant het ergens over eens moeten worden. En offline toegang blijft een clientinstelling, geen bijwerking van een serverfunctie.
Wanneer iemand belooft dat een servicefunctie de WAN-roundtrips wegneemt, is dat de bewering die eerst moet worden getest.
Meet tegen de bewerking waarover gebruikers klagen
Meet de exacte bewerking in plaats van een synthetische kopie. Measure-Command { Get-ChildItem \\files\projects -Recurse } op een branchclient geeft een getal dat u voor en na kunt vergelijken, en Get-SmbMultichannelConnection toont of de client meer dan één pad gebruikt. Zet dat naast de latentiemetrieken aan de servicekant voor hetzelfde venster.
Houd de share, de clientlocatie, het VPN-pad en het beveiligingsbeleid constant, anders meet u uw wijzigingsvenster in plaats van de functie. Noteer ook het aantal bestanden en de grootteverdeling, omdat werkbelastingen met kleine bestanden en bulkkopieën op heel andere hefbomen reageren.
Het resultaat dat de moeite waard is, is een wijziging die past bij de grens die werkelijk traag was, met de operationele en consistentiekosten opgeschreven. Een groter opslag-IOPS-cijfer op een dia is dat resultaat niet.