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 modificare i criteri di suddivisione in livelli cloud per Sincronizzazione file di Azure. Prima di leggere questo articolo, assicurarsi di comprendere il funzionamento del cloud a livelli. Per i fondamenti del cloud tiering, vedere Comprendere il cloud tiering di Azure File Sync. Per una spiegazione approfondita delle politiche di tiering cloud con esempi, vedere Politiche di tiering cloud di Sincronizzazione file di Azure.
Limitazioni
La suddivisione in livelli del cloud non è supportata nel volume del sistema Windows.
Se si usa Gestione risorse file server (FSRM) per la gestione delle quote negli endpoint server, è consigliabile applicare le quote a livello di cartella e non a livello di volume. È comunque possibile abilitare la suddivisione in livelli nel cloud se si dispone di una quota FSRM a livello di volume. Dopo aver impostato una quota FSRM, le API di query sullo spazio libero che vengono chiamate segnalano automaticamente lo spazio disponibile nel volume in base all'impostazione della quota. Tuttavia, quando una quota fissa è presente nel volume di radice, lo spazio disponibile effettivo nel volume e lo spazio limitato dalla quota sul volume potrebbero non essere uguali. Questo potrebbe causare un tiering infinito se Sincronizzazione file di Azure ritiene che lo spazio disponibile sul volume nel punto finale del server non sia sufficiente.
Dimensione minima per i file per essere inclusi nei livelli
La dimensione minima di un file da suddividere in livelli si basa sulla dimensione del cluster del file system. Le dimensioni minime dei file idonee per il cloud tiering sono calcolate come 2 volte le dimensioni del cluster con almeno 8 KiB. La tabella seguente illustra le dimensioni minime dei file che possono essere archiviate a livelli, in base alle dimensioni del cluster del 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 |
Azure File Sync supporta il tiering cloud sui volumi con dimensioni dei cluster fino a 2 MiB.
Tutti i file system usati da Windows organizzano il disco rigido in base alle dimensioni del cluster (note anche come dimensioni dell'unità di allocazione). Le dimensioni del cluster rappresentano la quantità minima di spazio su disco che può essere usata per contenere un file. Quando le dimensioni dei file non sono un multiplo esatto della dimensione del cluster, deve essere utilizzato spazio aggiuntivo per memorizzare il file, fino a raggiungere il multiplo successivo della dimensione del cluster.
Sincronizzazione file di Azure è supportata nei volumi NTFS con Windows Server 2012 R2 e versioni successive. Nella tabella seguente vengono descritte le dimensioni predefinite del cluster quando si crea un nuovo volume NTFS con Windows Server.
| Dimensione del volume | Windows Server |
|---|---|
| 7 MiB - 16 TiB | 4 KiB |
| 16 TiB - 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
È possibile che, dopo la creazione del volume, il volume sia stato formattato manualmente con dimensioni del cluster diverse. Se il volume deriva da una versione precedente di Windows, anche le dimensioni predefinite del cluster potrebbero essere diverse. Anche se si sceglie una dimensione del cluster inferiore a 4 KiB, si applica un limite di 8 KiB in base alle dimensioni del file più piccole che possono essere archiviate a livelli. Anche se tecnicamente le dimensioni del cluster 2x equivalgono a meno di 8 KiB.
Il motivo del minimo assoluto è dovuto al modo in cui NTFS archivia file estremamente piccoli - da 1 KiB a 4 File di dimensioni KiB. A seconda di altri parametri del volume, è possibile che i file di piccole dimensioni non vengano archiviati in un cluster su disco. È probabilmente più efficiente archiviare tali file direttamente nella tabella file master del volume o nel "record MFT". Il punto di reparse del cloud per il tiering viene sempre archiviato su disco e occupa esattamente un cluster. La suddivisione in livelli di tali file di piccole dimensioni potrebbe non comportare alcun risparmio di spazio. I casi estremi potrebbero persino finire per usare più spazio con l'attivazione della stratificazione del cloud. Per prevenire ciò, la dimensione minima di un file che il tiering su cloud gestirà è di 8 KiB su un cluster di dimensioni pari a 4 KiB o inferiori.
Selezione dei criteri iniziali
In genere, quando si abilita la suddivisione in livelli cloud in un endpoint server, è necessario creare un'unità virtuale locale per ogni singolo endpoint server. L'isolamento dell'endpoint server rende più semplice comprendere il funzionamento del cloud a livelli e modificare i criteri di conseguenza. Tuttavia, Azure File Sync funziona anche se si dispone di più endpoint server sullo stesso disco, per informazioni dettagliate, vedere la sezione Più endpoint server nel volume locale . È inoltre consigliabile che, quando si abilita per la prima volta il cloud tiering, la politica della data sia disabilitata e la politica di spazio libero del volume sia impostata a circa 10% - 20%. Per la maggior parte dei volumi dei file server, 20% di spazio libero nel volume è generalmente l'opzione 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 del modo in cui gli elementi verranno archiviati a livelli, è consigliabile modificare principalmente i criteri di spazio libero del volume e mantenere disabilitati i criteri di data, a meno che non sia necessario. Consigliamo questo perché la maggior parte dei clienti lo trova utile per riempire la cache locale con il maggior numero possibile di file ad accesso frequente e trasferire il resto nel cloud. Tuttavia, la politica delle date può essere utile se si desidera liberare spazio su disco locale in modo proattivo e si è consapevoli che i file in quell'endpoint del server accessibili dopo il numero di giorni specificato nella politica delle date non devono essere mantenuti 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 l'uscita e regolare entrambi i criteri di conseguenza. È consigliabile esaminare le dimensioni del richiamo a livelli cloud e le dimensioni del richiamo a livelli cloud in base alle metriche dell'applicazione in Monitoraggio di Azure. È anche consigliabile monitorare la frequenza di riscontri nella cache per l'endpoint server per determinare la percentuale di file aperti già presenti nella cache locale. Per informazioni su come monitorare l'uscita, vedere Monitorare la suddivisione in livelli nel cloud.
Modifica dei criteri
Se il numero di file richiamati costantemente da Azure è maggiore di quello desiderato, è possibile che siano presenti più file ad accesso frequente rispetto allo spazio necessario per salvarli nel volume del server locale. Se possibile, aumentare le dimensioni del volume locale e/o ridurre la percentuale nella politica di spazio libero del volume in piccoli incrementi. Ridurre troppo la percentuale di spazio libero del volume può avere conseguenze negative. Una varianza più elevata nel set di dati richiede più spazio libero per i nuovi file e il richiamo di file "freddi". La suddivisione in livelli viene attivata con un ritardo di un massimo di un'ora e quindi richiede tempo di elaborazione, motivo per cui è consigliabile avere sempre ampio 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 larghezza di banda ridotta, è possibile che si vogliano più dati locali per garantire un ritardo minimo per gli 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 TiB viene modificato o a cui si accede attivamente ogni mese, è possibile mantenere 100 GiB locali in modo da non richiamare spesso i file. Se il volume è 2 TiB, è necessario mantenere 5% (o 100 GiB) locale, ovvero il rimanente 95% è la percentuale di spazio disponibile del volume. Tuttavia, è necessario aggiungere un buffer per periodi di varianza superiore, in altre parole, iniziare con una percentuale di spazio disponibile del volume più grande e quindi modificarlo se necessario in un secondo momento.
Procedure operative standard
- Quando si esegue la prima migrazione a File di Azure tramite Sincronizzazione file di Azure, la suddivisione in livelli del cloud dipende dal caricamento iniziale.
- Il sistema di archiviazione a livelli verifica la conformità con i criteri di spazio libero e delle politiche di data del volume ogni sessanta minuti
- L'uso dell'opzione /LFSM su Robocopy durante la migrazione dei file consentirà la sincronizzazione e la suddivisione in livelli cloud per creare spazio durante il caricamento iniziale
- Se la suddivisione in livelli si verifica prima della formazione di una mappa termica, i file verranno suddivisi in livelli in base alla data dell'ultima modifica.