Condividi tramite

Comprendere e ottimizzare le prestazioni della condivisione file di Azure

  • Articolo

File di Azure può 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 Sì No
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona Sì No
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona Sì Sì

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" è intermutabile 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 piccole, ad esempio 4 KiB a dimensioni molto più grandi. 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 nello spazio di archiviazione al secondo e misura 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 operazioni di I/O al secondo * 1 MiB I/O size = 10 GiB/s, mentre 10.000 operazioni di I/O * 4 KiB I/O size = 38 MiB/s.

  • Latenza

    La latenza è un sinonimo di ritardo e viene 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, ad accesso frequente e ad accesso sporadico) tra cui ottimizzare i prezzi di archiviazione dei dati inattivi e 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 del modello 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 e 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. Rivolgersi all'amministratore di archiviazione o allo sviluppatore di applicazioni per determinare i modelli di utilizzo seguenti.

  • Riservatezza della latenza: gli utenti 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 una visibilità elevata per gli utenti finali. Questi tipi di carichi di lavoro sono più adatti per le condivisioni file di Azure Premium, che possono offrire una latenza a millisecondi singolo per le operazioni di lettura e scrittura (< 2 ms per dimensioni di I/O ridotte).

  • Requisiti di I/O al secondo e velocità effettiva: le condivisioni file Premium supportano limiti di operazioni di I/O al secondo e velocità effettiva maggiori rispetto alle condivisioni file standard. Per altre informazioni, vedere Destinazioni di scalabilità di condivisioni file.

  • Durata e frequenza del carico di lavoro: i carichi di lavoro brevi (minuti) e i carichi di lavoro poco frequenti (orari) avranno meno probabilità di raggiungere i limiti di prestazioni superiori delle condivisioni file standard rispetto ai carichi di lavoro a esecuzione prolungata. 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 in momenti di picco. Trovare il giusto equilibrio ridurrà i costi rispetto al provisioning eccessivo della condivisione file. Un errore comune consiste nell'eseguire test delle prestazioni solo per pochi minuti, che spesso è fuorviante. Per ottenere una visione realistica delle prestazioni, assicurarsi di testare a una frequenza e una durata sufficientemente elevate.

  • 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 rispetto alle condivisioni file standard: SMB multicanale. Per altre informazioni, vedere Migliorare le prestazioni della condivisione file di Azure SMB.

  • Distribuzione delle operazioni API: i metadati del carico di lavoro sono pesanti con operazioni di apertura/chiusura dei file? Ciò è comune per i carichi di lavoro che eseguono operazioni di lettura su un numero elevato di file. Vedere Metadati o carichi di lavoro pesanti per lo spazio dei nomi.

Latenza

Quando si pensa alla latenza, è importante comprendere prima come viene determinata la latenza con File di Azure. Le misurazioni più comuni sono la latenza associata alle metriche di latenza end-to-end e alla latenza del servizio. L'uso di queste metriche delle transazioni consente di identificare i problemi di latenza lato client e/o 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 di nuovo al client.

  • Latenza del servizio (SuccessServerLatency) è il tempo necessario per il round trip di una transazione solo all'interno del servizio File di Azure. Ciò non include alcuna latenza di rete o client.

    Diagramma che confronta la latenza del client e la latenza del servizio per File di Azure.

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, ciò suggerisce che tutto il tempo viene impiegato in transito da e verso il client e non nel servizio File di Azure.

Inoltre, come illustrato nel diagramma, più lontano si sta lontano 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 dall'ambiente 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 l'ambiente locale e Azure è un modo efficace e pratico per definire le funzionalità di rete della connessione ad Azure. Spesso un carico di lavoro può essere rallentato da un circuito ExpressRoute sottodimensionato o instradato in modo non corretto o gateway VPN.

Profondità della 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) a dispositivi ssd (SSD, NVMe), si sono anche evoluti per supportare una maggiore profondità della coda. Un carico di lavoro costituito da un singolo client che interagisce serialmente con un singolo file all'interno di un set di dati di grandi dimensioni è un esempio di profondità bassa della coda. 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 carichi di lavoro con una 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 per il 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. Se lo si fa, non si noterà un miglioramento delle prestazioni 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 carico di lavoro o il test di benchmarking sia multithreading con più file.

Applicazioni a thread singolo e multithread

File di Azure è più adatto per le applicazioni multithread. Il modo più semplice per comprendere l'impatto sulle prestazioni che il multithreading ha su un carico di lavoro consiste nell'esaminare lo scenario in base all'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 Crea 4 KiB write 4 KiB write 4 KiB write 4 KiB write Chiudi Totali
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 da 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 il servizio di ogni richiesta è determinato principalmente dalla vicinanza tra calcolo e archiviazione, come illustrato 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 tempo 87,5%.

Operazione di I/O Crea 4 KiB write 4 KiB write 4 KiB write 4 KiB write Chiudi Totali
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

Vedi anche