Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo fornisce indicazioni su come selezionare e adattare le policy di cloud tiering per Sincronizzazione file di Azure. Prima di procedere, comprendi come funziona il cloud tiering. Per le basi, vedi Understand Sincronizzazione file di Azure cloud tiering. Per una spiegazione approfondita con esempi, consulta Sincronizzazione file di Azure cloud tiering policys.
Limitazioni
Il cloud a livelli non è supportato nel volume del sistema Windows.
Se usi File Server Resource Manager (FSRM) per la gestione delle quote sugli endpoint server, applica le quote a livello di cartella e non a livello di volume. Puoi ancora abilitare il cloud tiering con una quota FSRM a livello di volume, ma quando una quota rigida è presente su una radice di volume, lo spazio libero effettivo e quello limitato dalla quota potrebbero non corrispondere. Questa discrepanza può causare livelli infiniti se Sincronizzazione file di Azure pensa che non ci sia abbastanza spazio libero nel volume sull'endpoint server.
Dimensione file minima per un file da includere nel livello
I file system di Windows organizzano lo storage su disco in base alla dimensione del cluster (nota anche come dimensione dell'unità di allocazione) - la minima unità di spazio che può contenere un file. I file che non sono un multiplo della dimensione del cluster usano spazio fino al multiplo successivo.
Sincronizzazione file di Azure supporta il tiering cloud sui volumi con dimensioni dei cluster fino a 2 MiB.
La dimensione minima del file idonea per il cloud tiering è 2× la dimensione del cluster, con un minimo di 8 KiB. La seguente tabella mostra le dimensioni minime dei file tierable in base alla dimensione del cluster di volume:
| Dimensioni del cluster del volume | I file di questa dimensione o superiore possono essere suddivisi in livelli |
|---|---|
| 4 KiB o più piccoli (4.096 byte) | 8 KiB |
| 8 KiB (8.192 byte) | 16 KiB |
| 16 KiB (16.384 byte) | 32 KiB |
| 32 KiB (32.768 byte) | 64 KiB |
| 64 KiB (65.536 byte) | 128 KiB |
| 128 KiB (131.072 byte) | 256 KiB |
| 256 KiB (262.144 byte) | 512 KiB |
| 512 KiB (524.288 byte) | 1 Mebibyte |
| 1 MiB (1.048.576 byte) | 2 MiB |
| 2 MiB (2.097.152 byte) | 4 MiB |
Per trovare la dimensione del cluster di volumi, esegui fsutil fsinfo ntfsinfo volumedriveletter: da un prompt dei comandi elevato. Il campo Bytes Per Cluster mostra la dimensione del cluster in byte (kilobyte tra parentesi).
Sincronizzazione file di Azure supporta volumi NTFS. Dimensioni predefinite del cluster per i nuovi volumi NTFS:
| Dimensioni del volume | Windows Server |
|---|---|
| 7 MiB - 16 TiB | 4 KiB |
| 16 TiB - 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
Potresti aver formattato il volume con una dimensione di cluster non predefinita, oppure versioni più vecchie di Windows potrebbero usare valori predefiniti diversi. In entrambi i casi, il minimo di 8 KiB si applica anche se il 2× la dimensione del cluster sarebbe inferiore a 8 KiB.
Il minimo di 8 KiB esiste perché NTFS a volte memorizza file molto piccoli (1–4 KiB) direttamente nella Master File Table invece che su disco. Poiché il punto di reparse cloud tiering occupa sempre un cluster, affiancare tali file non potrebbe risparmiare spazio o addirittura aumentare l'uso di storage. Il livello di tier di file cloud più piccolo è di 8 KiB su un cluster di 4 KiB o di dimensioni inferiori.
Selezione dei criteri iniziali
Quando abiliti il cloud tiering, crea un disco virtuale locale per ogni endpoint server per semplificare la gestione delle policy. Sincronizzazione file di Azure supporta più endpoint server sullo stesso disco (vedi Multiple server endpoint on local volume), ma isolare gli endpoint rende più semplice la sintonia.
Sincronizzazione file di Azure ha due policy di tiering: la policy dello spazio libero del volume mantiene libera una percentuale specificata del volume tramite tiering dei file più vecchi, e i file dei tier della policy date che non vengono accessibili entro un numero specificato di giorni. Inizia con la data policy disattivata e lo spazio libero per il volume impostato su 10–20%. Per la maggior parte dei volumi, 20% è il punto di partenza migliore.
Annotazioni
In alcuni scenari di migrazione, se è stato effettuato il provisioning di meno spazio di archiviazione nell'istanza di Windows Server rispetto all'origine, è possibile impostare temporaneamente lo spazio disponibile sul volume su 99% durante la migrazione ai file di livello nel cloud e quindi impostarlo su un livello più utile al termine della migrazione.
Per semplicità e per avere una chiara comprensione di come gli elementi sono a livelli, modifica principalmente la tua politica di spazio libero di volume e mantieni disabilitata la politica sulle date a meno che non sia necessario. La maggior parte dei clienti trova utile riempire la cache locale con quanti più hot file possibile e depositare il resto nel cloud. Tuttavia, la politica sulle date potrebbe essere utile se vuoi liberare proattivamente spazio su disco locale e sai che i file in quell'endpoint server accessibili dopo il numero di giorni specificati nella tua policy sulle date non devono essere conservati localmente. L'impostazione dei criteri di data libera la capacità utile del disco locale per altri endpoint nello stesso volume per memorizzare nella cache più file.
Dopo aver impostato i criteri, monitorare il traffico in uscita e regolare entrambi i criteri di conseguenza. Guarda la dimensione del richiamo del cloud tiering e la dimensione del richiamo cloud tiering per metriche applicative in Monitoraggio di Azure. Monitora anche il tasso di successo della cache per l'endpoint del server per determinare la percentuale di file aperti che sono già nella cache locale. Per informazioni su come monitorare il traffico in uscita, vedere Monitorare il cloud a livelli.
Modifica dei criteri
Se i file vengono richiamati più del previsto, probabilmente hai più hot file che spazio locale. Aumenta la dimensione locale del volume se possibile, oppure diminuisci la percentuale di spazio libero in piccoli incrementi - ma non in modo troppo aggressivo. Un churn più alto richiede più spazio libero per nuovi file e richiami di cold file. Il tiering entra in funzione con un ritardo fino a un'ora più tempi di elaborazione, quindi tieni abbastanza spazio libero sul volume.
Mantenere più dati locali significa ridurre i costi di uscita perché un minor numero di file verrà richiamato da Azure, ma richiede anche una quantità maggiore di spazio di archiviazione locale, che comporta un costo specifico.
Quando si modificano i criteri di spazio libero del volume, la quantità di dati da mantenere in locale è determinata dai fattori seguenti: larghezza di banda, modello di accesso del set di dati e budget. Con una connessione a bassa larghezza di banda, potresti voler più dati locali, per garantire il minimo ritardo agli utenti. In caso contrario, puoi basarlo sul tasso di abbandono durante un determinato periodo. Ad esempio, se si sa che 10% del set di dati di 1 TiB viene modificato o viene utilizzato attivamente ogni mese, è possibile mantenere 100 GiB in locale in modo da non richiamare spesso i file. Se il tuo volume è di 2 TiB, allora vuoi mantenere 5% (o 100 GiB) locali, cioè i restanti 95% sono la percentuale di spazio libero in volume. Tuttavia, aggiungi un buffer per i periodi di churn più alto – in altre parole, inizia con una percentuale di spazio libero di volume maggiore e poi la aggiudi se necessario in seguito.
Impatto delle configurazioni aggressive della suddivisione del cloud in livelli
Configura la percentuale di spazio libero e la politica delle date in base all'uso effettivo del server. Ad esempio, per memorizzare in cache gli ultimi sette giorni di dati, imposta la data policy a sette giorni e assicurati che il volume possa gestire sette giorni di churn. Se il volume è di 100 GiB e il churn è di circa 10 GiB in sette giorni, un'impostazione di 20% spazio libero (20 GiB) accoglie nuovi contenuti e lascia spazio per i costi generali.
Un'impostazione di spazio libero ad alto volume riduce significativamente i dati memorizzati localmente nella cache, tierando di fatto la maggior parte dei file. Se solo una piccola percentuale del dataset funzionante viene memorizzata localmente, gli utenti sperimentano richiami più frequenti, aumentando la latenza e potenzialmente aggiungendo costi di transazione e trasferimento dati.
La politica dello spazio libero per volumi ha la precedenza sulla politica della data: Sincronizzazione file di Azure allontana i file per raggiungere il target di spazio libero indipendentemente dall'accesso recente. Una soglia di policy a breve data può anche far sì che i file recentemente inattivi si accumulino rapidamente di livelli, anche quando lo spazio libero non è limitato.
Usare l'approccio seguente:
- Configurare un criterio di gestione dello spazio libero del volume che sia allineato alla capacità del volume e all'insieme di lavoro previsto da memorizzare nella cache sul server.
- Selezionare un criterio di data che rifletta i modelli di utilizzo dei file effettivi. Questa impostazione è facoltativa.
- Monitorare lo spazio disponibile corrente, la percentuale di riscontro nella cache, le dimensioni del richiamo, le dimensioni della suddivisione dei dati in livelli e le prestazioni complessive del carico di lavoro per ottimizzare il criterio dello spazio disponibile o le dimensioni totali del volume.
Questo approccio consente di mantenere un equilibrio appropriato tra le prestazioni locali e l'utilizzo dell'archiviazione cloud.
Procedure operative standard
- Quando migri per la prima volta su File di Azure tramite Sincronizzazione file di Azure, il cloud tiering dipende prima dal completamento del caricamento iniziale.
- Sincronizzazione file di Azure verifica la conformità alle politiche di spazio libero e data ogni 60 minuti.
- Usare l'interruttore
/LFSMsu RoboCopy durante la migrazione dei file permette di sincronizzare i file, mentre il cloud tiering libera spazio durante il caricamento iniziale. - Se il tiering avviene prima che venga formata una heatmap, Sincronizzazione file di Azure classifica i file tramite l'ultimo timestamp modificato.