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

Articolo
2025-04-30

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 File di Azure e Sincronizzazione file di Azure.

Altre variabili nella distribuzione possono influire sulle destinazioni elencate in questo articolo. Ad esempio, il comportamento del client SMB e la larghezza di banda di rete disponibile potrebbero influire sulle prestazioni di I/O. È 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

Modello di gestione	Modello di fatturazione	Livello supporti	Ridondanza
Microsoft.Storage	Con provisioning v2	HDD (standard)	Locale
Microsoft.Storage	Con provisioning v2	HDD (standard)	Della zona
Microsoft.Storage	Con provisioning v2	HDD (standard)	Geografica
Microsoft.Storage	Con provisioning v2	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage	Con provisioning v1	SSD (Premium)	Locale
Microsoft.Storage	Con provisioning v1	SSD (Premium)	Della zona
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	Locale
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	Della zona
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	Geografica
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	GeoZone (GZRS)

Obiettivi di scalabilità di Azure Files

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 utilizzato per creare più condivisioni di 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 FileStorage: gli account di archiviazione FileStorage consentono di distribuire condivisioni file di Azure utilizzando un modello di fatturazione con provisioning. 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.
Account di archiviazione per utilizzo generico versione 2 (GPv2): gli account di archiviazione GPv2 consentono di distribuire condivisioni file di Azure in hardware basato su disco rigido. Oltre a archiviare le condivisioni file di Azure, gli account di archiviazione per utilizzo generico v2 possono essere utilizzati per archiviare altre risorse di archiviazione, ad esempio contenitori BLOB, code o tabelle.

Attributo	SSD con provisioning v1	HDD con provisioning v2	HDD con pagamento in base al consumo
Tipo di account di archiviazione	Archiviazione di file	Archiviazione di file	StorageV2
SKU	Archiviazione con ridondanza locale Premium Archiviazione con ridondanza della zona Premium	StandardV2_LRS StandardV2_ZRS StandardV2_GRS StandardV2_GZRS	Standard_LRS Archiviazione con ridondanza della zona Standard Archiviazione con ridondanza geografica Standard Archiviazione con ridondanza geografica della zona Standard
Numero di account di archiviazione per area e per sottoscrizione	250	250	250
Capacità massima di archiviazione	100 TiB	4 PiB	5 PiB
Numero massimo di condivisioni file	1024 (consigliato utilizzare 50 o meno)	50	Senza limiti (50 o meno consigliati)
Numero massimo di IOPS	102.400 operazioni di I/O al secondo	50.000 IOPS	20.000 operazioni di I/O al secondo
Velocità effettiva massima	10.340 MiB/sec	5.120 MiB/sec	Selezionare le aree: Ingresso: 7.680 MiB/sec Uscita: 25.600 MiB/sec Impostazione predefinita: Ingresso: 3.200 MiB/sec Uscita: 6.400 MiB/sec
Numero massimo di regole della rete virtuale	200	200	200
Numero massimo di regole dell'indirizzo IP	200	200	200
Operazioni di lettura gestite	800 per 5 minuti	800 per 5 minuti	800 per 5 minuti
Operazioni di scrittura gestite	10 al secondo/1200 all'ora	10 al secondo/1200 all'ora	10 al secondo/1200 all'ora
Operazioni di gestione degli elenchi	100 ogni 5 minuti	100 ogni 5 minuti	100 ogni 5 minuti

Aree selezionate con maggiore velocità effettiva massima per HDD con pagamento in base al consumo

Le aree seguenti hanno una maggiore velocità effettiva massima per gli account di archiviazione HDD con pagamento in base al consumo (StorageV2):

Asia orientale
Asia sud-orientale
Australia orientale
Brasile meridionale
Canada centrale
Cina orientale 2
Cina settentrionale 3
Europa settentrionale
Europa occidentale
Francia centrale
Germania centro-occidentale
India centrale
Giappone orientale
Jio India occidentale
Corea centrale
Norvegia orientale
Sudafrica settentrionale
Svezia centrale
Emirati Arabi Uniti settentrionali
Regno Unito meridionale
Stati Uniti centrali
Stati Uniti orientali
Stati Uniti orientali 2
Governo degli Stati Uniti, Virginia
Governo degli Stati Uniti Arizona
Stati Uniti centro-settentrionali
Stati Uniti centro-meridionali
Stati Uniti occidentali
Stati Uniti occidentali 2
Stati Uniti occidentali 3

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

Attributo	SSD con provisioning v1	HDD con provisioning v2	HDD con pagamento in base al consumo
Unità di provisioning archiviazione	1 GiB	1 GiB	N/D
Unità di allocazione IOPS	N/D	1 I/O al secondo	N/D
Unità di provisioning velocità effettiva	N/D	1 MiB/sec	N/D
Dimensioni minime di archiviazione	100 GiB (allocato)	32 GiB (allocato)	0 byte
Dimensioni di archiviazione massime	100 TiB	256 TiB	100 TiB
Numero massimo di file	Nessun limite	Nessun limite	Nessun limite
Numero massimo di operazioni di I/O al secondo (dati)	102.400 operazioni di I/O al secondo (dipendenti dal provisioning)	50.000 operazioni di I/O al secondo (dipendenti dal provisioning)	20.000 operazioni di I/O al secondo
Capacità massima IOPS (Metadati¹)	Fino a 35.000 IOPS	Fino a 12.000 operazioni di I/O al secondo*	Fino a 12.000 operazioni di I/O al secondo*
Velocità effettiva massima	10.340 MiB/sec (dipendente dal provisioning)	5.120 MiB/sec (dipendente dal provisioning)	Fino al limite dell'archiviazione dell'account
Numero massimo di snapshot condivise	200 snapshot	200 snapshot	200 snapshot
Lunghezza massima del nome file² (percorso completo, inclusi tutte le directory, i nomi di file e i caratteri barra rovesciata)	2.048 caratteri	2.048 caratteri	2.048 caratteri
Lunghezza massima del singolo componente pathname (nel percorso \A\B\C\D, ogni lettera rappresenta una directory o un file che è un singolo componente)	255 caratteri	255 caratteri	255 caratteri
Limite di collegamenti reali (solo NFS)	178	N/D	N/D
Numero massimo di canali di SMB Multichannel	4	N/D	N/D
Numero massimo di criteri di accesso archiviati per ogni condivisione file	5	5	5

¹ IOPS di metadati (apertura/chiusura/eliminazione). Consultare Monitor Metadata IOPS per indicazioni.
² Azure Files 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	SSD con provisioning v1	HDD con provisioning v2	HDD con pagamento in base al consumo
Dimensione massima dei file	4 TiB	4 TiB	4 TiB
Numero massimo di operazioni di input/output al secondo per file	8.000 operazioni di I/O al secondo	1.000 operazioni di I/O al secondo	1.000 operazioni di I/O al secondo
Velocità effettiva massima per file	1.024 MiB/sec	60 MiB/sec	60 MiB/sec
Numero massimo di handle simultanei per la directory radice	10.000 maniglie	10.000 maniglie	10.000 maniglie
Numero massimo di handle simultanei per file e directory	2.000 maniglie	2.000 maniglie	2.000 maniglie

Guida al dimensionamento di Azure Files per Azure Virtual Desktop

Un caso d'uso comune per Azure Files consiste nell'archiviare i contenitori dei profili utente e le immagini disco per Azure Virtual Desktop usando FSLogix o App attach. Se si utilizza 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. In questa sezione viene descritto il modo in cui i vari tipi di immagini disco utilizzano gli handle. Fornisce inoltre linee guida per il dimensionamento in base alla 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 apre un singolo handle di directory radice, che deve essere nella condivisione file. Azure Files possono supportare un massimo di 10.000 utenti, supponendo di avere la condivisione file (\\storageaccount.file.core.windows.net\sharename) + la directory del profilo (%sid%_%username%) + il contenitore del profilo (profile_%username.vhd(x)).

Se raggiungi il limite di 10.000 handle simultanei per la directory principale o gli utenti riscontrano prestazioni insoddisfacenti, prova a usare una condivisione file aggiuntiva su Azure 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 in uso. 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, è improbabile raggiungere il limite di 2.000 handle di file aperti e 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 altro handle 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 di almeno due altri file, per ogni macchina virtuale che monta l'immagine del disco, è necessario un handle ciascuno per tre file nella directory. Pertanto, se sono presenti 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 si usa il collegamento app con file VHD/VHDX, i file vengono montati nel contesto di sistema, non nel contesto utente, e sono condivisi e 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 della directory principale. 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 richiedono 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 sono necessari 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, utilizzare una condivisione file di Azure aggiuntiva.

Obiettivi di Scalabilità di Azure File Sync

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 dell'archiviazione per regione	100 servizi di sincronizzazione dell'archiviazione	Sì
Servizi di sincronizzazione dell'archiviazione per abbonamento	15 servizi di sincronizzazione di archiviazione	Sì
Gruppi di sincronizzazione per Servizio di sincronizzazione di archiviazione	200 gruppi di sincronizzazione	Sì
Server registrati per il servizio di sincronizzazione dell'archiviazione	100 server	Sì
Endpoint privati per il Servizio di Sincronizzazione dell'Archiviazione	100 endpoint privati	Sì
Endpoint del cloud per gruppo di sincronizzazione	Un 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	NO
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 suddividere in livelli	Basato sulle dimensioni del cluster del file system (raddoppia le dimensioni del cluster del file system). Ad esempio, se le dimensioni del cluster del file system sono pari a 4 KiB, la dimensione minima del file è 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 prestazioni di sincronizzazione effettive dipendono da molti fattori nell'infrastruttura, tra cui:

Windows Server e la configurazione del disco sottostante
Larghezza di banda di rete tra il server e l'archiviazione di Azure
Dimensione del file
Dimensioni totali del set di dati
Attività nel set di dati

Poiché Sincronizzazione file di Azure funziona a livello di file, è necessario misurare le caratteristiche delle prestazioni di una soluzione basata su Sincronizzazione file di Azure in base al numero di oggetti (file e directory) elaborati al secondo.

La tabella seguente indica le destinazioni di prestazioni di Sincronizzazione file di Azure:

Sceneggiatura	Prestazioni
Enumerazione iniziale delle modifiche del cloud	150 oggetti al secondo per gruppo di sincronizzazione
Velocità effettiva di caricamento	200 oggetti al secondo per gruppo di sincronizzazione
Velocità effettiva di download dello spazio dei nomi	400 oggetti al secondo per endpoint server
Velocità di trasferimento dati completa	60 oggetti al secondo per endpoint server

Nota

Le prestazioni effettive dipenderanno da diversi fattori, come descritto all'inizio di questa sezione.

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

La velocità effettiva degli oggetti viene ridimensionata approssimativamente in proporzione 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 riscontra una maggiore velocità effettiva in termini di numero di oggetti elaborati al secondo, ma una velocità effettiva miB al secondo inferiore. Viceversa, per file di dimensioni maggiori, si ottengono meno oggetti elaborati al secondo, ma una velocità effettiva miB al secondo più elevata. La velocità effettiva in MiB al secondo è limitata dagli obiettivi di scalabilità di File di Azure.
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 ne risentono. In casi estremi, alcune sessioni di sincronizzazione non riescono 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.
Se è abilitata la suddivisione in livelli nel cloud, è probabile che si osservino prestazioni di download migliori perché 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 strutturati a livelli quando vi accedono gli utenti.

Condividi tramite