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.
| Attributo | Account di archiviazione GPv2 (standard) | Account di archiviazione FileStorage (premium) |
|---|---|---|
| Numero di account di archiviazione per area per sottoscrizione | 2501 | 2501 |
| Capacità massima dell'account di archiviazione | 5 PiB2 | 100 TiB (con provisioning) |
| Numero massimo di condivisioni file | Illimitato | Le dimensioni totali illimitate con provisioning di tutte le condivisioni devono essere inferiori al massimo della capacità massima dell'account di archiviazione |
| Frequenza massima di richieste simultanee | 20.000 operazioni di I/O al secondo2 | 102.400 operazioni di I/O al secondo |
Velocità effettiva (ingresso e uscita) per archiviazione con ridondanza locale/archiviazione con ridondanza geografica
|
|
10.340 MiB/sec |
Velocità effettiva (ingresso e uscita) per ZRS
|
|
10.340 MiB/sec |
| Velocità effettiva (ingresso + uscita) per combinazioni di ridondanza/aree non elencate nella riga precedente |
|
10.340 MiB/sec |
| Numero massimo di regole della macchina virtuale | 200 | 200 |
| Numero massimo di regole dell'indirizzo IP | 200 | 200 |
| Operazioni di lettura gestite | 800 per 5 minuti | 800 per 5 minuti |
| Operazioni di scrittura gestite | 10 al secondo/1200 all'ora | 10 al secondo/1200 all'ora |
| Operazioni di elenco gestite | 100 per 5 minuti | 100 per 5 minuti |
1 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. 2 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.
| Attributo | Condivisioni file standard1 | Condivisioni file Premium |
|---|---|---|
| Dimensione massima di una condivisione file | Nessun minimo | 100 GiB (con provisioning) |
| Unità di aumento/riduzione delle dimensioni con provisioning | N/D | 1 GiB |
| Dimensioni massime di una condivisione file | 100 TiB | 100 TiB |
| Numero massimo di file in una condivisione file | Nessun limite | Nessun limite |
| Frequenza massima richieste (operazioni di I/O al secondo) | 20.000 |
|
| Velocità effettiva (in ingresso e uscita) per una singola condivisione file (MiB/sec) | Fino al limite dell'account di archiviazione | 100 + ARROTONDAMENTO PER ECCESSO(0,04 * ProvisionedStorageGiB) + ARROTONDAMENTO PER ECCESSO(0,06 * ProvisionedStorageGiB) |
| Numero massimo di condivisioni snapshot | 200 snapshot | 200 snapshot |
| Lunghezza massima del nome dell'oggetto3 (nome percorso completo, inclusi tutti i nomi di file, le directory e i caratteri barra rovesciata) | 2.048 caratteri | 2.048 caratteri |
| Lunghezza massima del singolo componente nome percorso2 (nel percorso \A\B\C\D ogni lettera rappresenta una directory o un file che è un singolo componente) | 255 characters | 255 characters |
| Limite di collegamenti reali (solo NFS) | N/D | 178 |
| Numero massimo di canali di SMB Multichannel | N/D | 4 |
| Numero massimo di criteri di accesso archiviati per ogni condivisione file | 5 | 5 |
1 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.
2 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.
| Attributo | File nelle condivisioni file standard | File nelle condivisioni file premium |
|---|---|---|
| Dimensione massima dei file | 4 TiB | 4 TiB |
| Frequenza massima di richieste simultanee | 1\.000 operazioni di I/O al secondo | Fino a 8.0001 |
| Valore massimo in ingresso per un file | 60 MiB/sec | 200 MiB/sec (fino a 1 GiB/s con SMB multicanale)2 |
| Valore massimo in uscita per un file | 60 MiB/sec | 300 MiB/sec (fino a 1 GiB/s con SMB multicanale)2 |
| Numero massimo di handle simultanei per la directory radice3 | 10.000 handle | 10.000 handle |
| Numero massimo di handle simultanei per file e directory3 | 2\.000 handle | 2\.000 handle |
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.
Avviso
Anche se File di Azure può supportare fino a 10.000 utenti simultanei da una singola condivisione file, è fondamentale testare correttamente i carichi di lavoro in base alle dimensioni e al tipo di condivisione file creata. I requisiti possono variare in base a utenti, dimensioni del profilo e carico di lavoro.
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:
| Risorsa | Destinazione | Limite rigido |
|---|---|---|
| Servizi di sincronizzazione archiviazione per area | 100 servizi di sincronizzazione archiviazione | Sì |
| Servizi di sincronizzazione archiviazione per sottoscrizione | 15 servizi di sincronizzazione archiviazione | Sì |
| Gruppi di sincronizzazione per servizio di sincronizzazione archiviazione | 200 gruppi di sincronizzazione | Sì |
| Server registrati per servizio di sincronizzazione archiviazione | 99 server | Sì |
| Endpoint privati per servizio di sincronizzazione archiviazione | 100 endpoint privati | Sì |
| Endpoint cloud per gruppo di sincronizzazione | 1 endpoint cloud | Sì |
| Endpoint server per gruppo di sincronizzazione | 100 endpoint server | Sì |
| Endpoint server per server | 30 endpoint server | Sì |
| Oggetti file system (directory e file) per gruppo di sincronizzazione | 100 milioni di oggetti | No |
| Numero massimo di oggetti file system (directory e file) in una directory (non ricorsiva) | 5 milioni di oggetti | Sì |
| Dimensioni massime del descrittore di protezione (directory e file) dell'oggetto | 64 KiB | Sì |
| Dimensione del file | 100 GiB | No |
| Dimensioni minime per un file da rendere a livelli | basate sulle dimensioni del cluster del file system (raddoppia le dimensioni del cluster del file system). Se, ad esempio, le dimensioni del cluster del file system sono 4 KiB, le dimensioni minime del file saranno 8 KiB. | Sì |
Nota
Le dimensioni di un endpoint di Sincronizzazione file di Azure possono aumentare fino a quelle di una condivisione file di Azure. Se viene raggiunto il limite delle dimensioni della condivisione file di Azure, la sincronizzazione non funzionerà.
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:
- Provisioning iniziale una tantum: per ottimizzare le prestazioni del provisioning iniziale, vedere Onboarding con Sincronizzazione file di Azure per informazioni dettagliate sulla distribuzione ottimale.
- Sincronizzazione continua: dopo il seeding iniziale dei dati nelle condivisioni file di Azure, Sincronizzazione file di Azure mantiene sincronizzati più endpoint.
Nota
Quando molti endpoint server nello stesso gruppo di sincronizzazione vengono sincronizzati allo stesso tempo, si contendono le risorse del servizio cloud. Di conseguenza, le prestazioni di caricamento sono interessate. In casi estremi alcune sessioni di sincronizzazione non riusciranno ad accedere alle risorse e avranno esito negativo. Tuttavia, queste sessioni di sincronizzazione riprenderanno in breve tempo e alla fine avranno esito positivo una volta ridotta la congestione.
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:
| Configurazione del sistema | Dettagli |
|---|---|
| CPU | 64 core virtuali con cache L3 da 64 MiB |
| Memoria | 128 GiB |
| Disco | Dischi SAS con RAID 10 con cache supportata da batteria |
| Rete | Rete a 1 Gbps |
| Carico di lavoro | File server per utilizzo generico |
Provisioning monouso iniziale
| Provisioning monouso iniziale | Dettagli |
|---|---|
| Numero di oggetti | 25 milioni di oggetti |
| Dimensioni del set di dati | ~4.7 TiB |
| Dimensioni medie dei file | ~200 KiB (file più grande: 100 GiB) |
| Enumerazione iniziale delle modifiche del cloud | 80 oggetti al secondo |
| Velocità effettiva di caricamento | 20 oggetti al secondo per gruppo di sincronizzazione |
| Velocità effettiva di download dello spazio dei nomi | 400 oggetti al secondo |
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
| Sincronizzazione continua | Dettagli |
|---|---|
| Numero di oggetti sincronizzati | 125.000 oggetti (circa 1% di varianza) |
| Dimensioni del set di dati | 50 GiB |
| Dimensioni medie dei file | ~500 KiB |
| Velocità effettiva di caricamento | 20 oggetti al secondo per gruppo di sincronizzazione |
| Velocità effettiva per il download completo* | 60 oggetti al secondo |
*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.
Nota
Questi numeri non sono indicativi delle prestazioni che si riscontreranno. Le prestazioni effettive dipenderanno da diversi fattori, come descritto all'inizio di questa sezione.
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.