Condividi tramite

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

  • Articolo

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.

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

Modello di gestione Modello di fatturazione Livello multimediale Ridondanza SMB NFS
Microsoft.Storage Provisioning v2 HDD (standard) Locale (Archiviazione con ridondanza locale) Sì No
Microsoft.Storage Provisioning v2 HDD (standard) Zona (ZRS) Sì No
Microsoft.Storage Provisioning v2 HDD (standard) Geo (GRS) Sì No
Microsoft.Storage Provisioning v2 HDD (standard) GeoZone (GZRS) Sì No
Microsoft.Storage Provisioning v1 SSD (Premium) Locale (Archiviazione con ridondanza locale) Sì Sì
Microsoft.Storage Provisioning v1 SSD (Premium) Zona (ZRS) Sì Sì
Microsoft.Storage Pagamento in base al consumo HDD (standard) Locale (Archiviazione con ridondanza locale) Sì No
Microsoft.Storage Pagamento in base al consumo HDD (standard) Zona (ZRS) Sì No
Microsoft.Storage Pagamento in base al consumo HDD (standard) Geo (GRS) Sì No
Microsoft.Storage Pagamento in base al consumo HDD (standard) GeoZone (GZRS) Sì No

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 FileStorage: gli account di archiviazione FileStorage consentono di distribuire condivisioni file di Azure con 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 per utilizzo generico v2 consentono di distribuire condivisioni file con pagamento in base al consumo su hardware 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.

Attributo SSD con provisioning v1 HDD con provisioning v2 HDD con pagamento in base al consumo
Tipo di account di archiviazione FileStorage FileStorage StorageV2
SKU
  • Premium_LRS
  • Premium_ZRS
  • StandardV2_LRS
  • StandardV2_ZRS
  • StandardV2_GRS
  • StandardV2_GZRS
  • Standard_LRS
  • Standard_ZRS
  • Standard_GRS
  • Standard_GZRS
Numero di account di archiviazione per area per sottoscrizione 250 250 250
Capacità massima di archiviazione 100 TiB 4 PiB 5 PiB
Numero massimo di condivisioni file 1024 (scelta consigliata per l'uso di 50 o meno) 50 Illimitato (consigliato per usare 50 o meno)
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 macchina 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 elenco gestite 100 per 5 minuti 100 per 5 minuti 100 per 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
  • India occidentale Jio
  • 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
  • US Gov Virginia
  • US Gov Arizona
  • Stati Uniti centro-settentrionali
  • Stati Uniti centro-meridionali
  • Stati Uniti occidentali
  • West US 2
  • Stati Uniti occidentali 3

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 SSD con provisioning v1 HDD con provisioning v2 HDD con pagamento in base al consumo
Unità di provisioning dell'archiviazione 1 GiB 1 GiB N/D
Unità di provisioning di operazioni di I/O al secondo N/D 1 I/O al secondo N/D
Unità di provisioning della velocità effettiva N/D 1 MiB/sec N/D
Dimensioni minime di archiviazione 100 GiB (con provisioning) 32 GiB (con provisioning) 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 IOPS 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
Velocità effettiva massima 10.340 MiB/sec (dipendente dal provisioning) 5.120 operazioni di I/O al secondo (dipendenti dal provisioning) Fino al limite dell'account di archiviazione
Numero massimo di condivisioni snapshot 200 snapshot 200 snapshot 200 snapshot
Lunghezza massima del nome file3 (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 nome percorso2 (nel percorso \A\B\C\D ogni lettera rappresenta una directory o un file che è un singolo componente) 255 characters 255 characters 255 characters
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

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 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 I/O al secondo dei dati 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 handle 10.000 handle 10.000 handle
Numero massimo di handle simultanei per file e directory 2\.000 handle 2\.000 handle 2\.000 handle

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 100 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:

  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.

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.

Vedi anche