Cache de metadate Azure Files versus un cache local de sucursală
Un cache de metadate din partea serviciului reduce munca serverului. Nu scoate călătoriile dus-întors din WAN-ul dumneavoastră. Comparați cele două după ceea ce scurtează cu adevărat.
Pentru accesul lent la Azure Files printr-un VPN se propun două modificări, iar ele scurtează lucruri diferite. Cache-ul de metadate din partea serviciului face operațiile eligibile mai ieftine pentru server. Un cache local de sucursală aduce octeții și operațiile mai aproape de utilizator. Alegerea între ele după o listă de prețuri sau un comunicat de presă este modul în care o partajare ajunge mai rapidă într-un test și neschimbată la nouă dimineața.
Două cache-uri, două latențe diferite
Ambele opțiuni apar sub cuvântul cache, și de acolo începe confuzia. Ele stau pe laturi opuse ale rețelei.
| 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 |
Ghidul de performanță SMB al Microsoft descrie cache-ul de metadate pentru partajările SSD eligibile împreună cu pasul de înregistrare care îl însoțește. Eligibilitatea și starea funcției aparțin contului de stocare real, așa că citiți pagina actuală, nu un anunț de previzualizare de acum doi ani.
Împărțiți așteptarea în trei părți
Fiecare listare lentă de director are trei componente de cost, iar ele răspund la remedieri diferite. Există timpul de procesare a cererii din partea serviciului, numărul de călătorii dus-întors dependente prin VPN și încărcătura care trebuie mutată. Cache-ul din partea serviciului atacă prima. Nimic din partea serverului nu atacă a doua.
De aceea o partajare poate arăta metrici de serviciu mai bune în timp ce selectorul de fișiere al utilizatorului încă se blochează timp de opt secunde.
Unde fiecare opțiune își merită locul
Dacă volumul de lucru este intens în metadate, cu multe deschideri, apeluri stat și enumerări de directoare pe o partajare SSD eligibilă, cache-ul din partea serviciului este experimentul ieftin. Nu necesită infrastructură nouă și nu schimbă modul în care utilizatorii ajung la partajare.
Dacă volumul de lucru este interactiv și limitat de latență, opțiunea onestă este un design de server local acceptat, cu un model de sincronizare documentat. Este o arhitectură diferită, cu propriile costuri operaționale, nu un comutator.
Ce nu schimbă niciuna dintre opțiuni
Semnarea și criptarea SMB se aplică în continuare și costă în continuare cât costă. Controlul accesului este încă rezolvat pe utilizator, așa că o copie din cache nu simplifică autorizarea. Consistența între locații are încă nevoie de un model definit, deoarece citirile locale din sucursală și scrierile din partea cloud trebuie să fie de acord asupra a ceva. Iar accesul offline rămâne o setare a clientului, nu un efect secundar al unei funcții de server.
Când cineva promite că o funcție a serviciului elimină călătoriile WAN dus-întors, aceea este afirmația care trebuie testată prima.
Măsurați față de operația de care se plâng utilizatorii
Cronometrați operația exactă, nu o copie sintetică. Measure-Command { Get-ChildItem \\files\projects -Recurse } pe un client de sucursală oferă un număr pe care îl puteți compara înainte și după, iar Get-SmbMultichannelConnection arată dacă clientul folosește mai mult de o cale. Puneți asta lângă metricile de latență din partea serviciului pentru aceeași fereastră.
Mențineți constante partajarea, locația clientului, calea VPN și politica de securitate, altfel măsurați fereastra dumneavoastră de schimbare, nu funcția. Notați și numărul de fișiere și distribuția dimensiunilor, deoarece volumele de lucru cu fișiere mici și copiile masive răspund la pârghii complet diferite.
Rezultatul care merită este o modificare potrivită cu limita care era cu adevărat lentă, cu costurile sale operaționale și de consistență scrise. O cifră IOPS de stocare mai mare pe un slide nu este acel rezultat.