Obiettivi di scalabilità e prestazioni per File di Azure
File di Azure offre condivisioni file completamente gestite nel cloud accessibili tramite i protocolli di file system SMB e NFS. Questo articolo descrive gli obiettivi di scalabilità e prestazioni per File di Azure e Sincronizzazione file di Azure.
Le destinazioni elencate di seguito potrebbero essere interessate 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. È necessario testare il modello di utilizzo per determinare se la scalabilità e le prestazioni di File di Azure soddisfare 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.
Archiviazione destinazioni di scalabilità degli account
Archiviazione le destinazioni di scalabilità degli account si applicano a livello di account di archiviazione. Esistono due tipi principali di account di archiviazione per File di Azure:
Account di archiviazione per utilizzo generico versione 2 (GPv2): gli account di archiviazione per utilizzo generico v2 consentono di distribuire condivisioni file di Azure su hardware standard/basato su disco rigido (basato su HDD). 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.
File Archiviazione account di archiviazione: gli account di archiviazione file Archiviazione consentono di distribuire condivisioni file di Azure su hardware basato su disco premium/ssd.File Archiviazione storage accounts allow you to deploy Azure file shares on premium/solid-state disk-based (SSD-based). 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 per utilizzo generico v2 (standard) | File Archiviazione account di archiviazione (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 | Nessun limite | Le dimensioni totali con provisioning illimitate 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 (in ingresso e uscita) per archiviazione con ridondanza locale/archiviazione con ridondanza geografica
|
|
10.340 MiB/sec |
Velocità effettiva (in ingresso e uscita) per l'archiviazione con ridondanza della zona
|
|
10.340 MiB/sec |
| Velocità effettiva (in ingresso + uscita) per le combinazioni di ridondanza/area non elencate nella riga precedente |
|
10.340 MiB/sec |
| Numero massimo di regole di rete virtuale | 200 | 200 |
| Numero massimo di regole di indirizzo IP | 200 | 200 |
| Operazioni di lettura della gestione | 800 per 5 minuti | 800 per 5 minuti |
| Operazioni di scrittura della gestione | 10 al secondo/1200 all'ora | 10 al secondo/1200 all'ora |
| Operazioni dell'elenco di gestione | 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à più elevati e limiti più elevati per l'ingresso per richiesta. Per richiedere un incremento dei limiti di archiviazione, contattare il supporto tecnico di Azure.
Destinazioni di scalabilità di condivisioni file di Azure
Le destinazioni di scalabilità di condivisioni file di Azure si applicano a livello di condivisione file.
| Attributo | Condivisionifile standard 1 | Condivisioni file Premium |
|---|---|---|
| Dimensione massima di una condivisione file | Nessun minimo | 100 GiB (con provisioning) |
| Aumento/riduzione delle dimensioni di cui è stato effettuato il provisioning | N/D | 1 GiB |
| Dimensioni massime di una condivisione file |
|
100 TiB |
| Numero massimo di file in una condivisione file | Nessun limite | Nessun limite |
| Frequenza massima richieste (numero massimo di operazioni di I/O al secondo) |
|
|
| Velocità effettiva (in ingresso e uscita) per una singola condivisione file (MiB/sec) |
|
100 + CEILING(0.04 * Provisioned Archiviazione GiB) + CEILING(0.06 * Provisioned Archiviazione GiB) |
| Numero massimo di condivisioni snapshot | 200 snapshot | 200 snapshot |
| Lunghezza massima del nomeoggetto 3 (percorso completo, inclusi tutte le directory, i nomi di file e i caratteri barra rovesciata) | 2.048 caratteri | 2.048 caratteri |
| Lunghezza massima del singolo componentepathname 3 (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 le condivisioni file standard: ottimizzato per le transazioni, ad accesso frequente e sporadico.
2 Il valore predefinito per le condivisioni file standard è 5 TiB, vedere Creare una condivisione file di Azure per informazioni dettagliate su come creare condivisioni file con dimensioni di 100 TiB e aumentare le condivisioni file standard esistenti fino a 100 TiB. Per sfruttare i vantaggi delle destinazioni di scalabilità più grandi, è necessario modificare la quota in modo che sia maggiore di 5 TiB.
3 File di Azure applica determinate regole di denominazione per i nomi di 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 directoryradice 3 | 10.000 handle | 10.000 handle |
| Numero massimo di handle simultanei per file e directory3 | 2\.000 handle | 2\.000 handle |
1 Si applica alle operazioni di I/O di lettura e scrittura (in genere dimensioni di I/O inferiori 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à della coda e altri fattori. Per informazioni dettagliate, vedere Prestazioni multicanale SMB.
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 le immagini del disco per carichi di lavoro di desktop virtuali su larga scala, è possibile che si esauriscano gli handle per la directory radice o per ogni file/directory. In questo caso, potrebbe essere necessario usare più condivisioni file di Azure. Per altre informazioni, vedere File di Azure indicazioni sul ridimensionamento per Desktop virtuale Azure.
File di Azure linee guida per il ridimensionamento per Desktop virtuale Azure
Un caso d'uso comune per File di Azure consiste nell'archiviare i contenitori dei profili utente e le immagini del disco per Desktop virtuale Azure, usando FSLogix o Collegamento app. Nelle distribuzioni di Desktop virtuale Azure su larga scala, è possibile che si esauriscano gli handle per la directory radice o per ogni file/directory se si usa una singola condivisione file di Azure. Questa sezione descrive il modo in cui gli handle vengono utilizzati da vari tipi di immagini disco e fornisce indicazioni sul dimensionamento a seconda della tecnologia in uso.
FSLogix
Se si usa FSLogix con Desktop virtuale Azure, i contenitori del profilo utente sono dischi rigidi virtuali (VHD) o file VHDX (Virtual Hard Disk) Hyper-V 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 di avere la condivisione file (\\storageaccount.file.core.windows.net\sharename) + la directory del profilo () + il contenitore del profilo (%sid%_%username%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 tra le 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 con le dimensioni e il tipo di condivisione file creati. I requisiti possono variare in base a utenti, dimensioni del profilo e carico di lavoro.
Ad esempio, se si hanno 2.400 utenti simultanei, sono necessari 2.400 handle nella directory radice (uno per ogni utente), che è inferiore al limite di 10.000 handle aperti. Per gli utenti FSLogix, è estremamente improbabile raggiungere il limite di 2.000 handle di file aperti e di directory. 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 (profilo ed ODFC), è necessario un handle aggiuntivo per il file ODFC.
Collegamento di app con CimFS
Se si usa MSIX App Attach o App Attach per collegare in modo dinamico le applicazioni, è possibile usare file cimFS (Composite Image File System) o VHD/VHDX per le immagini del disco. In entrambi i casi, i limiti di scalabilità sono per ogni 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 del disco, anche se sono presenti zero utenti.
Se si usa Il collegamento app con CimFS, le immagini del disco usano solo handle nei file di immagine del disco. Non usano 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 di almeno due altri file, per ogni macchina virtuale che monta l'immagine del disco, è necessario un handle ogni per 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 esaurisca l'handle di file. In questo caso, usare una condivisione file di Azure aggiuntiva.
Collegamento app con VHD/VHDX
Se si usa Il collegamento app con i file VHD/VHDX, i file vengono montati in un contesto di sistema, non in un contesto utente e vengono condivisi e di sola lettura. Più handle nel file VHDX possono essere utilizzati da un sistema di connessione. Per rimanere entro File di Azure limiti di scalabilità, 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 è quello che si raggiunge per primo.
In questo scenario, è possibile 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, è possibile 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 200 handle in questo caso (100 handle di file + 100 handle di directory), che è comodamente inferiore al limite di 2.000 handle per ogni file/directory.
Se si stanno raggiungendo i limiti per il numero massimo di handle simultanei per la directory radice o per ogni file/directory, usare una condivisione file di Azure aggiuntiva.
Obiettivi di scalabilità di Sincronizzazione file di Azure
La tabella seguente indica quali destinazioni sono soft, che rappresentano il limite testato da Microsoft e hard, che indicano 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 di dimensioni della condivisione file di Azure, la sincronizzazione non sarà in grado di funzionare.
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 prestazioni di sincronizzazione effettive dipendono da diversi fattori nell'infrastruttura: Windows Server e la configurazione del disco sottostante, la larghezza di banda di rete tra il server e l'archiviazione di Azure, le dimensioni dei file, le dimensioni totali del set di dati e l'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 contemporaneamente, 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 a breve e alla fine avranno esito positivo una volta ridotta la congestione.
Risultati interni dei test
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 al cloud: quando viene creato un nuovo gruppo di sincronizzazione, l'enumerazione delle modifiche al cloud iniziale è il primo passaggio che viene eseguito. In questo processo, il sistema enumererà tutti gli elementi nella condivisione file di Azure. Durante questo processo, non verrà eseguita alcuna attività di sincronizzazione. Nessun elemento verrà scaricato dall'endpoint cloud all'endpoint server e nessun elemento verrà caricato 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 al cloud determinando il numero di elementi nella condivisione cloud e usando la formula seguente 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 delle modifiche al cloud iniziale è veloce e la maggior parte del tempo viene impiegato per sincronizzare le modifiche da Windows Server alle condivisioni file di Azure.
Mentre la sincronizzazione carica i dati nella condivisione file di Azure, non si verificano tempi di inattività nel file server locale e gli amministratori possono configurare limiti di rete per limitare la quantità di 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 la suddivisione in livelli cloud è abilitata, è probabile che si osservino prestazioni migliori perché vengono scaricati solo alcuni dei dati del file. Sincronizzazione file di Azure scarica solo i dati dei file memorizzati nella cache quando vengono modificati in uno degli endpoint. Per i file a livelli o appena creati, l'agente non scarica i dati del file e sincronizza invece solo lo spazio dei nomi con tutti gli endpoint server. L'agente supporta anche i download parziali dei file a livelli man mano che sono accessibili dall'utente.
Nota
Questi numeri non indicano le prestazioni che si otterranno. Le prestazioni effettive dipendono da più fattori, come descritto nell'inizio di questa sezione.
Come guida 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 otterrà una velocità effettiva maggiore in termini di numero di oggetti elaborati al secondo, ma una velocità effettiva miB al secondo inferiore. Viceversa, per file di dimensioni maggiori, si otterranno meno oggetti elaborati al secondo, ma una velocità effettiva miB al secondo superiore. La velocità effettiva in MiB al secondo è limitata dagli obiettivi di scalabilità di File di Azure.