Informazioni sulle prestazioni di File di Azure
File di Azure possono soddisfare i requisiti di prestazioni per la maggior parte delle applicazioni e dei casi d'uso. Questo articolo illustra i diversi fattori che possono influire sulle prestazioni della condivisione file e su come ottimizzare le prestazioni delle condivisioni file di Azure per il carico di lavoro.
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 | |
|
Glossario
Prima di leggere questo articolo, è utile comprendere alcuni termini chiave relativi alle prestazioni di archiviazione:
Operazioni di I/O al secondo (IOPS)
Le operazioni di I/O al secondo o di input/output misurano il numero di operazioni del file system al secondo. Il termine "I/O" è modificabile con i termini "operation" e "transaction" nella documentazione File di Azure.
Dimensioni di I/O
Le dimensioni di I/O, talvolta definite dimensioni del blocco, sono le dimensioni della richiesta usata da un'applicazione per eseguire una singola operazione di input/output (I/O) nell'archiviazione. A seconda dell'applicazione, le dimensioni di I/O possono variare da dimensioni molto ridotte, ad esempio 4 KiB a dimensioni molto maggiori. Le dimensioni di I/O svolgono un ruolo importante nella velocità effettiva ottenibile.
Velocità effettiva
La velocità effettiva misura il numero di bit letti o scritti nella risorsa di archiviazione al secondo ed è misurata in mebibyte al secondo (MiB/s). Per calcolare la velocità effettiva, moltiplicare le operazioni di I/O in base alle dimensioni di I/O. Ad esempio, 10.000 IOPS * 1 MiB I/O size = 10 GiB/s, mentre 10.000 IOPS * 4 KiB I/O size = 38 MiB/s.
Latency
La latenza è un sinonimo di ritardo ed è in genere misurata in millisecondi (ms). Esistono due tipi di latenza: latenza end-to-end e latenza del servizio. Per altre informazioni, vedere Latenza.
Profondità coda
La profondità della coda è il numero di richieste di I/O in sospeso che una risorsa di archiviazione può gestire in qualsiasi momento. Per altre informazioni, vedere Profondità coda.
Scelta di un livello di prestazioni in base ai modelli di utilizzo
File di Azure offre una gamma di livelli di archiviazione che consentono di ridurre i costi consentendo di archiviare i dati al livello appropriato di prestazioni e prezzo. Al livello più alto, File di Azure offre due livelli di prestazioni: Standard e Premium. Le condivisioni file standard sono ospitate in un sistema di archiviazione supportato da unità disco rigido (HDD), mentre le condivisioni file Premium sono supportate da unità SSD (Solid State Drive) per ottenere prestazioni migliori. Le condivisioni file standard hanno diversi livelli di archiviazione (ottimizzati per le transazioni ottimizzati, ad accesso frequente e ad accesso sporadico) che consentono di spostarsi facilmente tra per ottimizzare i dati inattivi e i prezzi delle transazioni. Tuttavia, non è possibile spostarsi tra i livelli Standard e Premium senza eseguire fisicamente la migrazione dei dati tra account di archiviazione diversi.
Quando si sceglie tra condivisioni file Standard e Premium, è importante comprendere i requisiti del modello di utilizzo previsto che si prevede di eseguire in File di Azure. Se sono necessarie grandi quantità di operazioni di I/O al secondo, velocità di trasferimento dei dati estremamente veloci o una latenza molto bassa, è consigliabile scegliere condivisioni file di Azure Premium.
La tabella seguente riepiloga gli obiettivi di prestazioni previsti tra standard e Premium. Per informazioni dettagliate, vedere File di Azure obiettivi di scalabilità e prestazioni.
| Requisiti dei modelli di utilizzo | Standard | Premium |
|---|---|---|
| Latenza di scrittura (millisecondi a cifra singola) | Sì | Sì |
| Latenza di lettura (millisecondi a cifra singola) | No | Sì |
Le condivisioni file Premium offrono un modello di provisioning che garantisce il profilo di prestazioni seguente in base alle dimensioni della condivisione. Per altre informazioni, vedere Modello con provisioning. I crediti burst si accumulano in un bucket burst ogni volta che il traffico per la condivisione file è inferiore alle operazioni di I/O al secondo di base. I crediti ottenuti vengono usati in un secondo momento per abilitare il bursting quando le operazioni superano le operazioni di I/O al secondo di base.
| Capacità (GiB) | Operazioni di I/O al secondo di base | Operazioni di I/O al secondo in modalità burst | Crediti burst | Velocità effettiva (ingresso + uscita) |
|---|---|---|---|---|
| 100 | 3,100 | Fino a 10.000 | 24,840,000 | 110 MiB/s |
| 500 | 3\.500 | Fino a 10.000 | 23,400,000 | 150 MiB/s |
| 1\.024 | 4,024 | Fino a 10.000 | 21,513,600 | 203 MiB/s |
| 5120 | 8,120 | Fino a 15.360 | 26,064,000 | 613 MiB/s |
| 10,240 | 13,240 | Fino a 30.720 | 62,928,000 | 1.125 MiB/s |
| 33,792 | 36,792 | Fino a 100.000 | 227,548,800 | 3.480 MiB/s |
| 51,200 | 54,200 | Fino a 100.000 | 164,880,000 | 5.220 MiB/s |
| 102.400 | 100,000 | Fino a 100.000 | 0 | 10.340 MiB/s |
Elenco di controllo delle prestazioni
Se si valutano i requisiti di prestazioni per un carico di lavoro nuovo o esistente, la comprensione dei modelli di utilizzo consente di ottenere prestazioni prevedibili. Consultare l'amministratore dell'archiviazione o lo sviluppatore di applicazioni per determinare i modelli di utilizzo seguenti.
Riservatezza della latenza: Gli utenti che aprono file o interagiscono con desktop virtuali eseguiti in File di Azure? Questi sono esempi di carichi di lavoro sensibili alla latenza di lettura e hanno anche visibilità elevata agli utenti finali. Questi tipi di carichi di lavoro sono più adatti per le condivisioni file premium di Azure, che possono fornire latenza a millisecondi singolo per operazioni di lettura e scrittura (< 2 ms per dimensioni di I/O piccole).
Requisiti di I/O al secondo e velocità effettiva: Le condivisioni file Premium supportano limiti di I/O al secondo e velocità effettiva maggiori rispetto alle condivisioni file standard. Per altre informazioni, vedere Destinazioni di scalabilità di condivisione file .
Durata e frequenza del carico di lavoro: I carichi di lavoro brevi (minuti) e infrequenti (oraria) saranno meno probabili per raggiungere i limiti di prestazioni superiori delle condivisioni file standard rispetto ai carichi di lavoro a esecuzione prolungata, che si verificano spesso. Nelle condivisioni file Premium, la durata del carico di lavoro è utile quando si determina il profilo di prestazioni corretto da usare in base alle dimensioni del provisioning. A seconda del tempo necessario per il carico di lavoro e del tempo trascorso al di sotto delle operazioni di I/O al secondo di base, è possibile determinare se si accumulano crediti di bursting sufficienti per soddisfare in modo coerente il carico di lavoro durante il picco. La ricerca del giusto equilibrio ridurrà i costi rispetto al over-provisioning della condivisione file. Un errore comune consiste nell'eseguire test delle prestazioni solo per pochi minuti, che spesso è fuorviante. Per ottenere una visualizzazione realistica delle prestazioni, assicurarsi di testare a una frequenza e una durata sufficientemente elevata.
Parallelizzazione del carico di lavoro: Per i carichi di lavoro che eseguono operazioni in parallelo, ad esempio tramite più thread, processi o istanze dell'applicazione nello stesso client, le condivisioni file Premium offrono un vantaggio chiaro sulle condivisioni file standard: SMB Multichannel. Per altre informazioni, vedere Migliorare le prestazioni della condivisione file di Azure SMB .
Distribuzione dell'operazione api: i metadati del carico di lavoro sono pesanti con operazioni aperte/chiudi file? Questo è comune per i carichi di lavoro che eseguono operazioni di lettura su un numero elevato di file. Vedere Metadati o carico di lavoro elevato dello spazio dei nomi.
Latenza
Quando si pensa alla latenza, è importante capire prima come viene determinata la latenza con File di Azure. Le misurazioni più comuni sono la latenza associata alla latenza end-to-end e alle metriche di latenza del servizio . L'uso di queste metriche di transazione consente di identificare la latenza lato client e/o problemi di rete determinando il tempo trascorso dal traffico dell'applicazione in transito da e verso il client.
La latenza end-to-end (SuccessE2ELatency) è il tempo totale necessario per eseguire un round trip completo dal client, attraverso la rete, al servizio File di Azure e tornare al client.
Latenza del servizio (SuccessServerLatency) è il tempo necessario per un round trip della transazione solo all'interno del servizio File di Azure. Non include alcuna latenza client o di rete.
La differenza tra i valori SuccessE2ELatency e SuccessServerLatency è la latenza probabilmente causata dalla rete e/o dal client.
È comune confondere la latenza client con latenza del servizio (in questo caso, File di Azure prestazioni). Ad esempio, se la latenza del servizio segnala bassa latenza e la latenza end-to-end segnala una latenza molto elevata per le richieste, che suggerisce che tutto il tempo viene trascorso in transito da e verso il client e non nel servizio File di Azure.
Inoltre, come illustrato dal diagramma, più lontano si è lontani dal servizio, l'esperienza di latenza più lenta sarà e più difficile sarà raggiungere i limiti di scalabilità delle prestazioni con qualsiasi servizio cloud. Ciò è particolarmente vero quando si accede a File di Azure da locale. Anche se le opzioni come ExpressRoute sono ideali per l'ambiente locale, non corrispondono ancora alle prestazioni di un'applicazione (calcolo e archiviazione) in esecuzione esclusivamente nella stessa area di Azure.
Suggerimento
L'uso di una macchina virtuale in Azure per testare le prestazioni tra locale e Azure è un modo efficace e pratico per fare riferimento alle funzionalità di rete della connessione ad Azure. Spesso un carico di lavoro può essere rallentato da un circuito ExpressRoute o da un gateway VPN sottosizzato o instradato in modo errato.
Profondità coda
La profondità della coda è il numero di richieste di I/O in sospeso che possono essere eseguite da una risorsa di archiviazione. Poiché i dischi usati dai sistemi di archiviazione si sono evoluti da spindles HDD (IDE, SATA, SAS) ai dispositivi a stato solido (SSD, NVMe), sono stati anche sviluppati per supportare una profondità di coda più elevata. Un carico di lavoro costituito da un singolo client che interagisce in modo seriale con un singolo file all'interno di un set di dati di grandi dimensioni è un esempio di profondità di coda bassa. Al contrario, un carico di lavoro che supporta il parallelismo con più thread e più file può raggiungere facilmente una profondità elevata della coda. Poiché File di Azure è un servizio file distribuito che si estende su migliaia di nodi del cluster di Azure ed è progettato per eseguire carichi di lavoro su larga scala, è consigliabile creare e testare i carichi di lavoro con profondità elevata della coda.
La profondità elevata della coda può essere ottenuta in diversi modi in combinazione con client, file e thread. Per determinare la profondità della coda per il carico di lavoro, moltiplicare il numero di client in base al numero di file (client * file * thread = profondità coda).
La tabella seguente illustra le varie combinazioni che è possibile usare per ottenere una maggiore profondità della coda. Anche se è possibile superare la profondità ottimale della coda di 64, non è consigliabile. Non verranno visualizzati altri miglioramenti delle prestazioni se si esegue e si rischia di aumentare la latenza a causa della saturazione TCP.
| Client | File | Thread | Profondità coda |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
Suggerimento
Per ottenere limiti di prestazioni superiori, assicurarsi che il test del carico di lavoro o del benchmarking sia multi threading con più file.
Applicazioni a thread singolo e multi-thread
File di Azure è più adatto per le applicazioni a più thread. Il modo più semplice per comprendere l'impatto delle prestazioni che il multi-threading ha su un carico di lavoro consiste nel seguire lo scenario di I/O. Nell'esempio seguente è disponibile un carico di lavoro che deve copiare 10.000 file di piccole dimensioni il più rapidamente possibile in o da una condivisione file di Azure.
Questa tabella suddivide il tempo necessario (in millisecondi) per creare un singolo file KiB in una condivisione file di Azure, in base a un'applicazione a thread singolo che scrive in 4 dimensioni dei blocchi KiB.
| Operazione di I/O | Creare | 4 Scrittura KiB | 4 Scrittura KiB | 4 KiB write | 4 KiB write | Close | Totale |
|---|---|---|---|---|---|---|---|
| Thread 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
In questo esempio sono necessari circa 14 ms per creare un singolo file KiB di 16 kiB dalle sei operazioni. Se un'applicazione a thread singolo vuole spostare 10.000 file in una condivisione file di Azure, che si traduce in 140.000 ms (14 ms * 10.000) o 140 secondi perché ogni file viene spostato in sequenza uno alla volta. Tenere presente che il tempo necessario per gestire ogni richiesta è determinato principalmente dalla vicinanza tra le risorse di calcolo e archiviazione, come descritto nella sezione precedente.
Usando otto thread anziché uno, il carico di lavoro precedente può essere ridotto da 140.000 ms (140 secondi) fino a 17.500 ms (17,5 secondi). Come illustrato nella tabella seguente, quando si spostano otto file in parallelo anziché un file alla volta, è possibile spostare la stessa quantità di dati in meno dell'87,5%.
| Operazione di I/O | Creare | 4 KiB write | 4 KiB write | 4 KiB write | 4 KiB write | Close | Totale |
|---|---|---|---|---|---|---|---|
| Thread 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 2 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 3 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 4 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 5 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 6 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 7 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Thread 8 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |