Scegliere i criteri di suddivisione in livelli nel cloud
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 nozioni fondamentali sul cloud a livelli, vedere Informazioni Sincronizzazione file di Azure cloud a livelli. Per una spiegazione approfondita dei criteri di suddivisione in livelli nel cloud con esempi, vedere Sincronizzazione file di Azure criteri di suddivisione in livelli nel cloud.
Limiti
Il cloud a livelli non è supportato nel volume di 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 rigida è presente in una radice del volume, lo spazio disponibile effettivo nel volume e la quota limitata spazio sul volume potrebbero non essere uguali. Ciò potrebbe causare un'infinità di livelli se Sincronizzazione file di Azure ritiene che lo spazio disponibile sul volume non sia sufficiente nell'endpoint server.
Dimensioni minime dei file per un file a livelli
Le dimensioni minime dei file per un file a livelli si basano sulle dimensioni del cluster del file system. Le dimensioni minime dei file idonee per il cloud a livelli sono calcolate per 2 volte le dimensioni del cluster e 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 a 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 MiB |
| 1 MiB (1.048.576 byte) | 2 MiB |
| 2 MiB (2.097.152 byte) | 4 MiB |
Sincronizzazione file di Azure supporta la suddivisione in livelli cloud nei volumi con dimensioni del 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 vengono visualizzate in un multiplo di dimensioni del cluster, è necessario usare spazio aggiuntivo per contenere il file, fino al multiplo successivo delle dimensioni del cluster.
Sincronizzazione file di Azure è supportato 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.
| Volume size | 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 cloud a livelli viene sempre archiviato su disco e occupa esattamente un cluster. La suddivisione in livelli di tali file di piccole dimensioni potrebbe comportare un risparmio di spazio. I casi estremi potrebbero persino finire per usare più spazio con il cloud a livelli abilitato. Per evitare questo comportamento, le dimensioni più piccole di un file a livelli cloud sono pari a 8 KiB in 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, Sincronizzazione file di Azure funziona anche se sono presenti più endpoint server nella stessa unità, per informazioni dettagliate, vedere la sezione Più endpoint server nel volume locale. Quando si abilita per la prima volta il cloud a livelli, è consigliabile mantenere disabilitati i criteri di data e i criteri di spazio disponibile per il volume a circa il 10% e il 20%. Per la maggior parte dei volumi di file server, lo spazio disponibile del 20% è in genere l'opzione migliore.
Nota
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 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. È consigliabile 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 livelli il resto nel cloud. Tuttavia, i criteri di data possono essere utili se si vuole liberare in modo proattivo lo spazio su disco locale e si conoscono i file in tale endpoint server a cui si accede dopo il numero di giorni specificati nei criteri di data non è necessario mantenere in locale. 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 dei criteri di spazio disponibile del volume in incrementi ridotti. Anche la riduzione della percentuale di spazio disponibile 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. Altrimenti è possibile basarsi sulla percentuale di varianza durante un determinato periodo. Ad esempio, se si sa che il 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, si vuole mantenere il 5% (o 100 GiB) locale, ovvero il 95% rimanente è la percentuale di spazio libero 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, il cloud a livelli dipende dal caricamento iniziale
- Il cloud a livelli verifica la conformità con i criteri di spazio disponibile e 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 del formato di una mappa termica, i file verranno archiviati a livelli in base al timestamp dell'ultima modifica