Comprendere e ottimizzare le prestazioni delle condivisioni file di Azure

✔️ Si applica a: condivisioni file SMB e NFS classiche create con il provider di risorse Microsoft.Storage

✔️ Si applica a: Condivisioni di file create con il provider di risorse Microsoft.FileShares

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 influiscono sulle prestazioni della condivisione file e su come ottimizzare le prestazioni di File di Azure per il carico di lavoro.

Glossario sulle prestazioni di archiviazione

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 o input/output al secondo misurano il numero di operazioni del file system al secondo. Nella documentazione File di Azure il termine "I/O" è intercambiabile con i termini "operation" e "transaction".

• 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) nella risorsa di 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 raggiungibile.

• Velocità effettiva

  La velocità effettiva misura il numero di bit letti o scritti nella risorsa di archiviazione al secondo ed è espressa in mebibyte al secondo (MiB/s). Per calcolare la velocità effettiva, moltiplicare le operazioni di I/O per le dimensioni di I/O. Ad esempio, 10.000 operazioni di I/O al secondo × 1 dimensione di I/O MiB = 10 GiB/s, mentre 10.000 operazioni di I/O × 4 dimensioni di I/O KiB = 38 MiB/s.

• Latency

  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à della coda

  La profondità della coda è il numero di richieste di I/O in sospeso che possono essere gestite contemporaneamente da una risorsa di archiviazione. Per altre informazioni, vedere Profondità della coda.

Scelta di un livello multimediale in base ai modelli di utilizzo

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

Quando scegli tra condivisioni di file SSD e HDD, considera i requisiti del carico di lavoro previsto che intendi 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, scegliere condivisioni file SSD.

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

Le condivisioni file SSD usano un modello di provisioning che garantisce il profilo di prestazioni seguente in base alle dimensioni della condivisione. Per altre informazioni, vedere il modello v1 con provisioning.

Migliori pratiche prestazionali

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 in lettura e molto visibili agli utenti finali sono più adatti alle condivisioni file su SSD, che possono offrire una latenza di un solo millisecondo sia per le operazioni di lettura sia per quelle di scrittura (meno di 2 ms per operazioni di I/O di piccole dimensioni).

• 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, vedi obiettivi di scalabilità delle condivisioni file.

• Durata e frequenza del carico di lavoro: È meno probabile che i carichi di lavoro brevi (minuti) e non frequenti (orari) raggiungano i limiti di prestazioni superiori delle condivisioni file HDD rispetto ai carichi di lavoro a esecuzione prolungata. Nelle condivisioni file su SSD, la durata del carico di lavoro aiuta a determinare il profilo prestazionale corretto da utilizzare in base allo storage, agli IOPS e al throughput di cui è stato effettuato il provisioning. Un errore comune è l'esecuzione di test delle prestazioni solo per pochi minuti, che spesso è fuorviante. Per ottenere una vista realistica delle prestazioni, assicurarsi di eseguire i test con 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 di condivisione file SMB Azure.

• Distribuzione delle operazioni API: i carichi di lavoro con un numero elevato di metadati, ad esempio i carichi di lavoro che eseguono operazioni di lettura su un numero elevato di file, sono più adatti alle condivisioni file SSD. Per altre informazioni, vedi Carico di lavoro elevato di metadati o namespace.

• Posizionamento di zona: usare il posizionamento di zona per selezionare la zona di disponibilità specifica in cui risiede l'account di archiviazione. Questa funzionalità consente di inserire le macchine virtuali nella stessa zona di disponibilità dell'archiviazione, riducendo la latenza fino al 30%. Questa funzionalità è attualmente disponibile solo per gli account di archiviazione SSD che usano l'archiviazione con ridondanza locale nelle aree supportate.

Latenza

Quando si parla di latenza, è importante innanzitutto capire come File di Azure la determina. Le misurazioni più comuni sono la latenza associata alle metriche di latenza end-to-end e latenza del servizio. L'uso di queste metriche delle transazioni consente di identificare i problemi di rete e la latenza lato client mostrando 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.

• La latenza del servizio (SuccessServerLatency) è il tempo necessario per il round trip di una transazione solo all'interno di File di Azure. Questa misura 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.

Spesso la latenza del client viene confusa con la latenza del servizio (in questo caso, con le prestazioni di File di Azure). Ad esempio, se la latenza del servizio segnala bassa latenza e la latenza end-to-end segnala una latenza molto elevata per le richieste, 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ù si è lontani dal servizio, maggiore è la latenza e più difficile diventa raggiungere i limiti di scalabilità delle prestazioni con qualunque servizio cloud. Questa condizione è particolarmente vera quando si accede a File di Azure dall'ambiente locale. Anche se le opzioni come Azure ExpressRoute sono ideali per l'ambiente locale, non corrispondono ancora alle prestazioni di un'applicazione (calcolo e archiviazione) in esecuzione esclusivamente nella stessa area Azure.

Profondità coda

La profondità della coda è il numero di richieste di I/O in sospeso che possono essere eseguite da una risorsa di archiviazione. Man mano che i dischi usati dai sistemi di archiviazione si sono evoluti da spindle 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à ridotta 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 Azure ed è progettato per eseguire carichi di lavoro su larga scala, compilare e testare carichi di lavoro con profondità elevata della coda.

È possibile ottenere una profondità elevata della coda in diversi modi. 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. In tal caso, 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 funziona meglio con le applicazioni multithreading. 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 Azure.

Questa tabella suddivide il tempo necessario (in millisecondi) per creare un singolo file di 16 KiB in una condivisione file di Azure, in base a un'applicazione a thread singolo che scrive in dimensioni del blocco di 4 KiB.

In questo esempio, sono necessari circa 14 ms per creare un singolo file da 16 KiB tramite sei operazioni. Se un'applicazione a thread singolo vuole spostare 10.000 file in una condivisione file Azure, tale operazione si traduce in 140.000 ms (14 ms × 10.000) o 140 secondi perché ogni file viene spostato in sequenza uno alla volta. Il tempo necessario per il servizio di ogni richiesta è determinato principalmente dalla vicinanza tra le risorse di calcolo e archiviazione, come illustrato nella sezione precedente.

Usando otto thread anziché uno, è possibile ridurre il carico di lavoro precedente 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 87,5% meno tempo.

Vedere anche

• Risoluzione dei 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