Cache dei metadati di Azure Files contro una cache locale di filiale
Una cache dei metadati lato servizio riduce il lavoro del server. Non sposta i viaggi di andata e ritorno dalla vostra WAN. Confrontate le due per ciò che accorciano davvero.
Per l'accesso lento ad Azure Files tramite una VPN vengono proposte due modifiche, e accorciano cose diverse. La cache dei metadati lato servizio rende le operazioni idonee meno costose per il server. Una cache locale di filiale avvicina i byte e le operazioni all'utente. Scegliere tra le due in base a un listino prezzi o a un comunicato stampa è il modo in cui una condivisione finisce più veloce in un test e invariata alle nove del mattino.
Due cache, due latenze diverse
Entrambe le opzioni compaiono sotto la parola cache, ed è lì che inizia la confusione. Si trovano su lati opposti della rete.
| 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 |
La guida alle prestazioni di SMB di Microsoft descrive la cache dei metadati per le condivisioni SSD idonee insieme al passaggio di registrazione che la accompagna. L'idoneità e lo stato della funzionalità appartengono all'account di archiviazione reale, quindi leggete la pagina attuale e non un annuncio di anteprima di due anni fa.
Dividete l'attesa in tre parti
Ogni elenco di directory lento ha tre componenti di costo, e rispondono a correzioni diverse. C'è il tempo di elaborazione della richiesta lato servizio, il numero di viaggi di andata e ritorno dipendenti attraverso la VPN e il payload da spostare. Una cache lato servizio attacca il primo. Nulla lato server attacca il secondo.
Ecco perché una condivisione può mostrare metriche di servizio migliori mentre il selettore di file dell'utente resta bloccato per otto secondi.
Dove ogni opzione si guadagna il suo posto
Se il carico di lavoro è ricco di metadati, con molte aperture, chiamate stat ed enumerazioni di directory su una condivisione SSD idonea, la cache lato servizio è l'esperimento economico. Non richiede nuova infrastruttura e non cambia il modo in cui gli utenti raggiungono la condivisione.
Se il carico di lavoro è interattivo e limitato dalla latenza, l'opzione onesta è un progetto di server locale supportato con un modello di sincronizzazione documentato. È un'architettura diversa con i suoi costi operativi, non un interruttore.
Ciò che nessuna delle due opzioni cambia
La firma e la cifratura SMB si applicano ancora, e costano ancora quello che costano. Il controllo degli accessi viene ancora risolto per utente, quindi una copia in cache non semplifica l'autorizzazione. La coerenza tra sedi richiede ancora un modello definito, perché le letture locali della filiale e le scritture lato cloud devono concordare su qualcosa. E l'accesso offline resta un'impostazione del client, non un effetto collaterale di una funzionalità del server.
Quando qualcuno promette che una funzionalità del servizio elimina i viaggi di andata e ritorno WAN, è l'affermazione da verificare per prima.
Misurate rispetto all'operazione di cui si lamentano gli utenti
Cronometrate l'operazione esatta anziché una copia sintetica. Measure-Command { Get-ChildItem \\files\projects -Recurse } su un client di filiale fornisce un numero che potete confrontare prima e dopo, e Get-SmbMultichannelConnection mostra se il client usa più di un percorso. Mettetelo accanto alle metriche di latenza lato servizio per la stessa finestra.
Mantenete costanti la condivisione, la posizione del client, il percorso VPN e la politica di sicurezza, altrimenti state misurando la vostra finestra di modifica anziché la funzionalità. Annotate anche il numero di file e la distribuzione delle dimensioni, perché i carichi di file piccoli e le copie massicce rispondono a leve completamente diverse.
Il risultato che vale la pena è una modifica adatta al confine che era davvero lento, con i suoi costi operativi e di coerenza messi per iscritto. Una cifra IOPS di archiviazione più alta su una diapositiva non è quel risultato.