Obiettivi di scalabilità e prestazioni per File di Azure e Sincronizzazione file di Azure

File di Azure offre condivisioni file completamente gestite nel cloud, accessibili tramite i protocolli file system Server Message Block (SMB) e Network File System (NFS). Questo articolo descrive gli obiettivi di scalabilità e prestazioni per gli account di archiviazione di Azure, File di Azure e Sincronizzazione file di Azure.

Gli obiettivi elencati di seguito potrebbero essere interessati da altre variabili nella distribuzione. Ad esempio, le prestazioni di I/O per un file potrebbero essere influenzate dal comportamento del client SMB e dalla larghezza di banda di rete disponibile. È consigliabile eseguire il test del criterio di utilizzo per determinare se la scalabilità e le prestazioni di File di Azure soddisfano i requisiti.

Si applica a

Tipo di condivisione file	SMB	NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona

Obiettivi di scalabilità di File di Azure

Le condivisioni file di Azure vengono distribuite in account di archiviazione, ovvero oggetti di primo livello che rappresentano un pool di archiviazione condiviso. Questo pool di archiviazione può essere usato per distribuire più condivisioni file. Esistono quindi tre categorie da considerare: account di archiviazione, condivisioni file di Azure e singoli file.

Obiettivi di scalabilità degli account di archiviazione

Gli obiettivi di scalabilità degli account di archiviazione si applicano a livello di account di archiviazione. Sono due i tipi principali di account di archiviazione per File di Azure:

• Account di archiviazione per utilizzo generico versione 2 (GPv2): gli account di archiviazione GPv2 consentono di distribuire condivisioni file di Azure in hardware standard o basato su disco rigido. Oltre a archiviare le condivisioni file di Azure, gli account di archiviazione per utilizzo generico v2 possono archiviare altre risorse di archiviazione, ad esempio contenitori BLOB, code o tabelle. Le condivisioni file possono essere distribuite nei livelli ottimizzati per le transazioni (impostazione predefinita), ad accesso frequente o ad accesso sporadico.

• Account di archiviazione FileStorage: Gli account di archiviazione FileStorage consentono di distribuire le condivisioni file di Azure a risorse hardware di livello Premium o basate su unità SSD. Gli account FileStorage possono essere usati solo per archiviare le condivisioni file di Azure. Non è infatti possibile distribuire altre risorse di archiviazione (contenitori BLOB, code, tabelle e così via) in un account FileStorage.

¹ Con un aumento di quota, è possibile creare fino a 500 account di archiviazione con endpoint standard per area. Per altre informazioni, vedere Aumentare le quote dell'account di archiviazione di Azure. ² Gli account di archiviazione per utilizzo generico versione 2 supportano limiti di capacità superiori e limiti più elevati per il traffico in ingresso in base alle richieste. Per richiedere un incremento dei limiti di archiviazione, contattare il supporto tecnico di Azure.

Obiettivi di scalabilità di condivisione file di Azure

Gli obiettivi di scalabilità di condivisione file di Azure si applicano a livello di condivisione file.

¹ I limiti per le condivisioni file standard si applicano a tutti e tre i livelli disponibili per tali condivisioni: ottimizzate per le transazioni, ad accesso frequente e ad accesso sporadico.

² File di Azure applica determinate regole di denominazione per directory e file.

Obiettivi di scalabilità file

Gli obiettivi di scalabilità file si applicano ai singoli file archiviati nelle condivisioni file di Azure.

^{1 Si applica a operazioni di I/O in lettura e scrittura (in genere dimensioni di I/O più piccole minori o uguali a 64 KiB). Le operazioni sui metadati, diverse da letture e scritture, possono essere inferiori. Si tratta di limiti flessibili, oltre i quali può verificarsi la limitazione.}

^{2 Soggetto ai limiti di rete del computer, larghezza di banda disponibile, dimensioni di I/O, profondità coda e altri fattori. Per informazioni dettagliate, vedere Prestazioni di SMB multicanale.}

^{3 File di Azure supporta 10.000 handle aperti nella directory radice e 2.000 handle aperti per file e directory all'interno della condivisione. Il numero di utenti attivi supportati per condivisione dipende dalle applicazioni che accedono alla condivisione. Se le applicazioni non aprono un handle nella directory radice, File di Azure può supportare più di 10.000 utenti attivi per condivisione. Tuttavia, se si usa File di Azure per archiviare immagini disco per carichi di lavoro desktop virtuali su larga scala, è possibile che si esauriscano gli handle per la directory radice o per file/directory. In questo caso, potrebbe essere necessario usare più condivisioni file di Azure. Per altre informazioni, vedere Materiale sussidiario sul dimensionamento di File di Azure per Desktop virtuale Azure.}

Materiale sussidiario sul dimensionamento di File di Azure per Desktop virtuale Azure

Un caso d'uso comune per File di Azure consiste nell'archiviare i contenitori dei profili utente e le immagini disco per Desktop virtuale Azure usando FSLogix o App Attach. Se si usa una condivisione file di Azure singola, nelle distribuzioni di Desktop virtuale Azure su larga scala è possibile che si esauriscano gli handle per la directory radice o per file/directory. Questa sezione descrive il modo in cui gli handle vengono utilizzati da vari tipi di immagini disco e fornisce materiale sussidiario sul dimensionamento a seconda della tecnologia in uso.

FSLogix

Se è in uso FSLogix con Desktop virtuale Azure, i contenitori dei profili utente sono file Virtual Hard Disk (VHD) o Hyper-V Virtual Hard Disk (VHDX) e vengono montati in un contesto utente, non in un contesto di sistema. Ogni utente aprirà un singolo handle di directory radice, che deve essere nella condivisione file. File di Azure può supportare un massimo di 10.000 utenti supponendo che si disponga di condivisione file (\\storageaccount.file.core.windows.net\sharename) + directory del profilo (%sid%_%username%) + contenitore del profilo (profile_%username.vhd(x)).

Se si raggiunge il limite di 10.000 handle simultanei per la directory radice o gli utenti riscontrano prestazioni scarse, provare a usare una condivisione file di Azure aggiuntiva e a distribuire i contenitori nelle diverse condivisioni.

Ad esempio, se si hanno 2.400 utenti simultanei, servono 2.400 handle nella directory radice (uno per ogni utente), il che è inferiore al limite di 10.000 handle aperti. Per gli utenti FSLogix, è estremamente improbabile raggiungere il limite di 2.000 handle di directory e file aperti. Se si dispone di un singolo contenitore di profili FSLogix per utente, si utilizzano solo due handle di file/directory: uno per la directory del profilo e uno per il file del contenitore del profilo. Se gli utenti hanno due contenitori ciascuno (profilo e ODFC), è necessario un handle aggiuntivo per il file ODFC.

App Attach con CimFS

Se è in uso MSIX App Attach o App Attach per collegare le applicazioni in modo dinamico, è possibile usare file Composite File System (CimFS) o VHD/VHDX per le immagini disco. In entrambi i casi, i limiti di scalabilità sono per macchina virtuale che monta l'immagine, non per utente. Il numero di utenti è irrilevante quando si calcolano i limiti di scalabilità. Quando una macchina virtuale viene avviata, monta l'immagine disco anche se sono presenti zero utenti.

Se è in uso App Attach con CimFS, le immagini disco utilizzano solo gli handle nei file di immagine del disco. Non utilizzano handle nella directory radice o nella directory contenente l'immagine del disco. Tuttavia, poiché un'immagine CimFS è una combinazione del file con estensione cim e almeno altri due file, per ogni macchina virtuale che monta l'immagine disco è necessario un handle per ogni tre file nella directory. Pertanto, se si dispone di 100 macchine virtuali, sono necessari 300 handle di file.

Se il numero di macchine virtuali per app supera 2.000, è possibile che si esauriscano gli handle di file. In questo caso usare una condivisione file di Azure aggiuntiva.

App Attach con VHD/VHDX

Se è in uso App Attach con file VHD/VHDX, i file vengono montati in un contesto di sistema, non un contesto utente, vengono condivisi e sono di sola lettura. Più handle nel file VHDX possono essere utilizzati da un sistema di connessione. Per rimanere entro i limiti di scalabilità di File di Azure, il numero di macchine virtuali moltiplicato per il numero di app deve essere inferiore a 10.000 e il numero di macchine virtuali per app non può superare 2.000. Quindi il vincolo è qualsiasi limite venga raggiunto per primo.

In questo scenario si potrebbe raggiungere il limite per file/directory con 2.000 montaggi di un singolo VHD/VHDX. In alternativa, se la condivisione contiene più file VHD/VHDX, si potrebbe raggiungere prima il limite di directory radice. Ad esempio, 100 macchine virtuali che montano 100 file VHDX condivisi raggiungeranno il limite di 10.000 handle directory radice.

In un altro esempio 100 macchine virtuali che accedono a 20 app richiederanno 2.000 handle di directory radice (100 x 20 = 2.000), che rientra nel limite di 10.000 per gli handle di directory radice. È anche necessario un handle di file e un handle di directory/cartella per ogni macchina virtuale che monta l'immagine VHD(X), quindi in questo caso 200 handle (100 handle di file + 100 handle di directory), che è decisamente inferiore al limite di 2.000 handle per file/directory.

Se si stanno raggiungendo i limiti per il numero massimo di handle simultanei per la directory radice o per file/directory, usare una condivisione file di Azure aggiuntiva.

Obiettivi di scalabilità di Sincronizzazione file di Azure

La tabella seguente indica quali obiettivi sono flessibili, che rappresenta il limite testato da Microsoft, e quali sono rigidi, che indica un valore massimo applicato:

Metriche delle prestazioni di Sincronizzazione file di Azure

Poiché l'agente Sincronizzazione file di Azure viene eseguito in un computer Windows Server che si connette alle condivisioni file di Azure, le effettive prestazioni di sincronizzazione dipendono da diversi fattori nell'infrastruttura: Windows Server e configurazione dei dischi sottostante, larghezza di banda di rete tra il server e l'archiviazione di Azure, dimensioni dei file, dimensioni totali del set di dati e attività nel set di dati. Poiché Sincronizzazione file di Azure opera a livello di file, le caratteristiche in termini di prestazioni di una soluzione basata su Sincronizzazione file di Azure possono essere misurate meglio in base al numero di oggetti (file e directory) elaborati al secondo.

Per Sincronizzazione file di Azure, le prestazioni sono critiche in due fasi:

1. Provisioning iniziale una tantum: per ottimizzare le prestazioni del provisioning iniziale, vedere Onboarding con Sincronizzazione file di Azure per informazioni dettagliate sulla distribuzione ottimale.
2. Sincronizzazione continua: dopo il seeding iniziale dei dati nelle condivisioni file di Azure, Sincronizzazione file di Azure mantiene sincronizzati più endpoint.

Risultati di test interni

Per pianificare la distribuzione per ognuna delle fasi (provisioning monouso iniziale e sincronizzazione continua), ecco i risultati osservati durante i test interni in un sistema con la configurazione seguente:

Provisioning monouso iniziale

Enumerazione iniziale delle modifiche del cloud: quando viene creato un nuovo gruppo di sincronizzazione, l'enumerazione iniziale delle modifiche del cloud è il primo passaggio che viene eseguito. In questo processo il sistema enumera tutti gli elementi nella condivisione file di Azure. Durante questo processo, non verrà eseguita alcuna attività di sincronizzazione. Non verrà scaricato alcun elemento dall'endpoint cloud all'endpoint server e non verrà caricato alcun elemento dall'endpoint server all'endpoint cloud. L'attività di sincronizzazione riprenderà al termine dell'enumerazione iniziale delle modifiche del cloud.

La velocità delle prestazioni è di 80 oggetti al secondo. È possibile stimare il tempo necessario per completare l'enumerazione iniziale delle modifiche del cloud determinando il numero di elementi nella condivisione cloud e usando le formule seguenti per ottenere il tempo in giorni.

Tempo (in giorni) per l'enumerazione iniziale del cloud = (Numero di oggetti nell'endpoint cloud)/(80 * 60 * 60 * 24)

Sincronizzazione iniziale dei dati da Windows Server alla condivisione file di Azure: molte distribuzioni di Sincronizzazione file di Azure iniziano con una condivisione file di Azure vuota perché tutti i dati si trovano in Windows Server. In questi casi l'enumerazione iniziale delle modifiche del cloud è veloce e la maggior parte del tempo viene impiegata per sincronizzare le modifiche da Windows Server alle condivisioni file di Azure.

Durante il caricamento dei dati nella condivisione file di Azure, non si verificano tempi di inattività nel file server locale e gli amministratori possono impostare i limiti di rete in modo da limitare la larghezza di banda usata per il caricamento dei dati in background.

La sincronizzazione iniziale è in genere limitata dalla velocità di caricamento iniziale di 20 file al secondo per ogni gruppo di sincronizzazione. I clienti possono stimare il tempo necessario per caricare tutti i dati in Azure usando la formula seguente per ottenere il tempo in giorni:

Tempo (in giorni) per il caricamento dei file in un gruppo di sincronizzazione = (Numero di oggetti nell'endpoint server)/(20 * 60 * 60 * 24)

La suddivisione dei dati in più endpoint server e gruppi di sincronizzazione può velocizzare il caricamento iniziale dei dati, perché il caricamento può essere eseguito in parallelo per più gruppi di sincronizzazione a una velocità di 20 elementi al secondo ciascuno. Due gruppi di sincronizzazione verranno quindi eseguiti a una velocità combinata di 40 elementi al secondo. Il tempo totale per il completamento dell'operazione sarà il tempo stimato per il gruppo di sincronizzazione con il maggior numero di file da sincronizzare.

Velocità effettiva di download dello spazio dei nomi: quando un nuovo endpoint server viene aggiunto a un gruppo di sincronizzazione esistente, l'agente Sincronizzazione file di Azure non scarica alcun contenuto del file dall'endpoint cloud. Sincronizza prima di tutto lo spazio dei nomi completo e quindi attiva il richiamo in background per scaricare i file, interamente o, se è abilitato il cloud a più livelli, in base ai criteri di suddivisione in livelli cloud impostati nell'endpoint del server.

Sincronizzazione continua

*Se è abilitato il cloud a livelli, è probabile che si osserveranno prestazioni migliori, in quanto vengono scaricati solo alcuni dei dati dei file. Sincronizzazione file di Azure scarica i dati dei file memorizzati nella cache solo quando vengono modificati in uno degli endpoint. Per tutti i file a livelli o appena creati, l'agente non scarica i dati dei file e sincronizza invece solo lo spazio dei nomi per tutti gli endpoint del server. L'agente supporta anche download parziali di file a livelli man mano che vi accedono gli utenti.

Come indicazione generale per la distribuzione, tenere presenti alcuni aspetti:

• La velocità effettiva degli oggetti cambia all'incirca in misura proporzionale al numero di gruppi di sincronizzazione nel server. La suddivisione dei dati in più gruppi di sincronizzazione in un server produce una maggiore velocità effettiva, che è limitata anche dal server e dalla rete.
• La velocità effettiva degli oggetti è inversamente proporzionale alla velocità effettiva in MiB al secondo. Per i file più piccoli, si riscontrerà una velocità effettiva maggiore per quanto riguarda il numero di oggetti elaborati al secondo, ma con una minore velocità effettiva in MiB al secondo. Al contrario, per i file di dimensioni maggiori, si otterrà un numero minore di oggetti elaborati al secondo, ma con una maggiore velocità effettiva in MiB al secondo. La velocità effettiva in MiB al secondo è limitata dagli obiettivi di scalabilità di File di Azure.

Vedi anche

• Informazioni sulle prestazioni di File di Azure
• Pianificazione per la distribuzione di File di Azure
• Pianificazione per la distribuzione di Sincronizzazione file di Azure