Azure Files-metadatacache kontra en lokal filialcache
En metadatacache på tjenestesiden skærer serverarbejde væk. Den flytter ikke rundture væk fra din WAN. Sammenlign de to efter, hvad de faktisk forkorter.
Der foreslås to ændringer til langsom Azure Files-adgang over en VPN, og de forkorter forskellige ting. Metadatacache på tjenestesiden gør kvalificerede handlinger billigere for serveren. En lokal filialcache flytter bytes og handlinger tættere på brugeren. At vælge mellem dem ud fra en prisliste eller en pressemeddelelse er, hvordan en deling ender med at være hurtigere i en benchmark og uændret klokken ni om morgenen.
To caches, to forskellige latenstider
Begge muligheder optræder under ordet cache, og det er der, forvirringen starter. De ligger på hver sin side af netværket.
| 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 vejledning i SMB-ydeevne beskriver metadatacache for kvalificerede SSD-delinger sammen med det registreringstrin, der hører til. Kvalifikation og funktionstilstand hører til den faktiske lagerkonto, så læs den aktuelle side i stedet for en forhåndsvisningsmeddelelse fra for to år siden.
Del ventetiden i tre dele
Hver langsom mappevisning har tre omkostningskomponenter, og de reagerer på forskellige rettelser. Der er behandlingstid pr. anmodning på tjenestesiden, antallet af afhængige rundture over VPN og den nyttelast, der skal flyttes. En cache på tjenestesiden angriber den første. Intet på serversiden angriber den anden.
Derfor kan en deling vise bedre tjenestemålinger, mens brugerens filvælger stadig hænger i otte sekunder.
Hvor hver mulighed gør sig fortjent til sin plads
Hvis arbejdsbyrden er metadatatung, med masser af åbninger, stat-kald og mappeopslag mod en kvalificeret SSD-deling, er cache på tjenestesiden det billige eksperiment. Det kræver ingen ny infrastruktur og ingen ændring af, hvordan brugerne når delingen.
Hvis arbejdsbyrden er interaktiv og latenstidsbundet, er det ærlige valg et understøttet lokalt serverdesign med en dokumenteret synkroniseringsmodel. Det er en anden arkitektur med sine egne driftsomkostninger, ikke en kontakt.
Hvad ingen af mulighederne ændrer
SMB-signering og -kryptering gælder stadig, og de koster stadig, hvad de koster. Adgangskontrol afgøres stadig pr. bruger, så en cachet kopi gør ikke autorisation enklere. Konsistens mellem lokationer kræver stadig en defineret model, fordi lokale læsninger i filialen og skrivninger fra cloud-siden skal være enige om noget. Og offlineadgang forbliver en klientindstilling, ikke en bivirkning af en serverfunktion.
Når nogen lover, at en tjenestefunktion fjerner WAN-rundturene, er det den påstand, der skal testes først.
Mål mod den handling, brugerne klager over
Tag tid på den præcise handling i stedet for en syntetisk kopi. Measure-Command { Get-ChildItem \\files\projects -Recurse } på en filialklient giver et tal, du kan sammenligne før og efter, og Get-SmbMultichannelConnection viser, om klienten bruger mere end én sti. Sæt det ved siden af latenstidsmålingerne på tjenestesiden for samme vindue.
Hold delingen, klientens placering, VPN-stien og sikkerhedspolitikken konstant, ellers måler du dit ændringsvindue i stedet for funktionen. Noter også filantal og størrelsesfordeling, fordi arbejdsbyrder med små filer og massekopier reagerer på helt forskellige håndtag.
Det resultat, der er værd at have, er en ændring, der passer til den grænse, der faktisk var langsom, med dens drifts- og konsistensomkostninger skrevet ned. Et større lager-IOPS-tal på en slide er ikke det resultat.