Azure Files-metadata-kas versus 'n plaaslike takkas
'n Diens-kant metadata-kas verminder die werk op die bediener. Dit skuif nie rondrye van jou WAN af nie. Vergelyk die twee volgens wat hulle werklik verkort.
Twee veranderinge word vir stadige Azure Files-toegang oor 'n VPN voorgestel, en hulle verkort verskillende dinge. Diens-kant metadata-kas maak geskikte bewerkings goedkoper vir die bediener. 'n Plaaslike takkas skuif die grepe en die bewerkings nader aan die gebruiker. Om tussen hulle te kies op grond van 'n pryslys of 'n persverklaring is hoe 'n deel in 'n maatstaf vinniger word en om nege in die oggend onveranderd bly.
Twee kasse, twee verskillende latenthede
Albei opsies verskyn onder die woord kas, en dit is waar die verwarring begin. Hulle sit aan teenoorgestelde kante van die 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 |
Microsoft se SMB-prestasieriglyne beskryf metadata-kas vir geskikte SSD-dele saam met die registrasiestap wat daarmee saamgaan. Geskiktheid en funksiestatus hoort by die werklike stoerrekening, so lees die huidige bladsy eerder as 'n voorbeeldaankondiging van twee jaar gelede.
Verdeel die wag in drie dele
Elke stadige gidslys het drie kostekomponente, en hulle reageer op verskillende regstellings. Daar is diensverwerkingstyd per versoek, die aantal afhanklike rondrye oor die VPN, en die vrag wat moet beweeg. 'n Diens-kant kas val die eerste aan. Niks aan die bedienerkant val die tweede aan nie.
Dit is waarom 'n deel beter diensmaatstawwe kan toon terwyl die gebruiker se lêerkieser steeds vir agt sekondes hang.
Waar elke opsie sy plek verdien
As die werk metadata-swaar is, met baie oopmaak, stat-oproepe en gidslyste teen 'n geskikte SSD-deel, is diens-kant kas die goedkoop eksperiment. Dit benodig geen nuwe infrastruktuur nie en geen verandering aan hoe gebruikers die deel bereik nie.
As die werk interaktief en latentheidgebonde is, is 'n ondersteunde plaaslike bedienerontwerp met 'n gedokumenteerde sinchroniseringsmodel die eerlike opsie. Dit is 'n ander argitektuur met sy eie lopende koste, nie 'n skakelaar nie.
Wat nie een van die opsies verander nie
SMB-ondertekening en -versleuteling geld steeds, en dit kos steeds wat dit kos. Toegangsbeheer word steeds per gebruiker bepaal, so 'n gekaste kopie vereenvoudig nie magtiging nie. Samehang tussen terreine benodig steeds 'n gedefinieerde model, want tak-plaaslike lesings en wolkkant-skrywes moet oor iets saamstem. En vanlyn toegang bly 'n kliëntinstelling, nie 'n newe-effek van 'n bedienerfunksie nie.
Wanneer iemand belowe dat 'n diensfunksie die WAN-rondrye verwyder, is dit die bewering om eerste te toets.
Meet teen die bewerking waaroor gebruikers kla
Meet die presiese bewerking eerder as 'n sintetiese kopie. Measure-Command { Get-ChildItem \\files\projects -Recurse } op 'n takkliënt gee 'n getal wat jy voor en na kan vergelyk, en Get-SmbMultichannelConnection wys of die kliënt meer as een pad gebruik. Sit dit langs die diens-kant latentheidsmaatstawwe vir dieselfde venster.
Hou die deel, die kliëntligging, die VPN-pad en die sekuriteitsbeleid konstant, anders meet jy jou veranderingsvenster eerder as die funksie. Teken ook lêertelling en grootteverspreiding aan, want kleinlêerwerklading en groot kopieë reageer op heeltemal verskillende hefbome.
Die resultaat wat die moeite werd is, is 'n verandering wat by die grens pas wat werklik stadig was, met sy bedryfs- en samehangkoste neergeskryf. 'n Groter stoer-IOPS-syfer op 'n skyfie is nie daardie resultaat nie.