Comprendere e ottimizzare le prestazioni della condivisione file di Azure

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

Modello di gestione	Modello di fatturazione	Livello supporti	Ridondanza	Piccole e Medie Imprese (PMI)	NFS (Network File System)
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)

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" è intercambiabile con i termini "operazione" e "transazione" nella documentazione di 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 ridotte, ad esempio 4 KiB a dimensioni 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 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 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 multimediale in base ai modelli di utilizzo

File di Azure offre due livelli di supporto di archiviazione che consentono di bilanciare le prestazioni e il prezzo: SSD e HDD. È possibile selezionare il livello multimediale della condivisione file a livello di account di archiviazione e, dopo aver creato un account di archiviazione in un determinato livello multimediale, non è possibile passare all'altro senza eseguire manualmente la migrazione a una nuova condivisione file.

Quando si sceglie tra condivisioni file SSD e HDD, è 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 veloci o bassa latenza, è consigliabile scegliere condivisioni file SSD.

La tabella seguente riepiloga gli obiettivi di prestazioni previsti tra le condivisioni file SSD e HDD. Per informazioni dettagliate, vedere File di Azure obiettivi di scalabilità e prestazioni.

Le condivisioni file SSD offrono un modello di provisioning che garantisce il profilo di prestazioni seguente in base alle dimensioni della condivisione. Per altre informazioni, vedere il modello v1 di cui è stato effettuato il provisioning.

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.

• Sensibilità alla latenza: I carichi di lavoro sensibili alla latenza di lettura e con visibilità elevata per gli utenti finali sono più adatti per le condivisioni file SSD, che possono offrire una latenza nell'ordine di singoli millisecondi 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 SSD supportano limiti di operazioni di I/O al secondo e velocità effettiva maggiori rispetto alle condivisioni file HDD. Per altre informazioni, vedere Destinazioni di scalabilità di condivisioni file.

• Durata e frequenza del carico di lavoro: I carichi di lavoro brevi (minuti) e non frequenti (orari) hanno meno probabilità di raggiungere i limiti di prestazioni superiori delle condivisioni file HDD rispetto ai carichi di lavoro a esecuzione prolungata. Nelle condivisioni file SSD, è utile considerarne la durata del carico di lavoro per determinare il profilo di prestazioni corretto da usare in base allo spazio di archiviazione, alle operazioni di I/O al secondo e alla velocità effettiva provisionata. 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 SSD offrono un vantaggio chiaro rispetto alle condivisioni file HDD: SMB multicanale. Per altre informazioni, vedere Migliorare le prestazioni della condivisione file di Azure SMB.

• Distribuzione delle operazioni API: i carichi di lavoro pesanti dei metadati, ad esempio i carichi di lavoro che eseguono operazioni di lettura su un numero elevato di file, rappresentano una soluzione migliore per le condivisioni file SSD. 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 affinché una transazione completi un ciclo solo all'interno di Azure Files. Ciò non include alcuna latenza di rete o client.

  

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, più lenta è l'esperienza di latenza e più difficile è 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.

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.

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.

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%.

Vedi anche

• Risolvere i problemi di prestazioni delle condivisioni file di Azure
• Monitoraggio di File di Azure
• Pianificazione per la distribuzione di File di Azure
• Informazioni sulla fatturazione di File di Azure
• Prezzi di File di Azure