Benchmark regolari delle prestazioni del volume di Azure NetApp Files per Linux

Questo articolo descrive i benchmark delle prestazioni di Azure NetApp Files per Linux con un volume normale.

Carichi di lavoro di streaming di file interi (test di benchmark con scalabilità orizzontale)

Lo scopo di un test con scalabilità orizzontale consiste nel mostrare le prestazioni di un volume di Azure NetApp File quando si aumenta o si aumenta il numero di client che generano un carico di lavoro simultaneo allo stesso volume. Questi test sono in genere in grado di eseguire il push di un volume al limite dei limiti di prestazioni e sono indicativi di carichi di lavoro come il rendering multimediale, intelligenza artificiale/MACHINE e altri carichi di lavoro che usano farm di calcolo di grandi dimensioni per eseguire il lavoro.

Configurazione del benchmark con scalabilità orizzontale elevata di I/OP

Questi benchmark hanno usato quanto segue:

• Un singolo volume regolare di Azure NetApp Files 100-TiB con un set di dati a 1 TiB usando il livello di prestazioni Ultra
• FIO (con e senza impostazione randrepeat=0)
• Dimensioni dei blocchi da 4 KiB e 8 KiB
• 6 D32s_v5 macchine virtuali che eseguono RHEL 9.3
• NFSv3
• QoS manuale
• Opzioni di montaggio: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configurazione del benchmark con scalabilità orizzontale con velocità effettiva elevata

Questi benchmark hanno usato quanto segue:

• Un singolo volume regolare di Azure NetApp Files con un set di dati a 1 TiB usando il livello di prestazioni ULTRA FIO (con e senza impostare randrepeat=0)
• FIO (con e senza impostazione randrepeat=0)
• Dimensioni del blocco da 64 KiB e 256 KiB
• 6 D32s_v5 macchine virtuali che eseguono RHEL 9.3
• NFSv3
• QoS manuale
• Opzioni di montaggio: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configurazione del benchmark della connessione di rete parallela (nconnect)

Questi benchmark hanno usato quanto segue:

• Un singolo volume regolare di Azure NetApp Files con un set di dati a 1 TiB usando il livello di prestazioni Ultra
• FIO (con e senza impostazione randrepeat=0)
• 4-KiB e 64-KiB wsize/rsize
• Una singola macchina virtuale D32s_v4 che esegue RHEL 9.3
• NFSv3 con e senza nconnect
• Opzioni di montaggio: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Test di benchmark con scalabilità orizzontale

Lo scopo del test di aumento delle prestazioni consiste nel mostrare le prestazioni di un volume di Azure NetApp File quando si aumenta (o aumenta) il numero di processi che generano un carico di lavoro simultaneo tra più connessioni TCP in un singolo client allo stesso volume (ad esempio con nconnect).

Senza nconnect, questi carichi di lavoro non possono eseguire il push dei limiti delle prestazioni massime di un volume, poiché il client non può generare una velocità effettiva di I/O o di rete sufficiente. Questi test sono in genere indicativi dell'esperienza di un singolo utente in carichi di lavoro, ad esempio rendering multimediale, database, intelligenza artificiale/Machine Learning e condivisioni file generali.

Benchmark con scalabilità orizzontale elevata di I/OP

I benchmark seguenti mostrano le prestazioni ottenute per Azure NetApp Files con un carico di lavoro di I/OP elevato usando:

• 32 client
• Letture e scritture casuali da 4 KiB e 8 KiB
• Set di dati 1 TiB
• Rapporti di lettura/scrittura come segue: 100%:0%, 90%:10%, 80%:20% e così via
• Con e senza memorizzazione nella cache del file system coinvolta (uso randrepeat=0 in FIO)

Per altre informazioni, vedere Metodologia di test.

Risultati: 4 KiB, casuale, memorizzazione nella cache client inclusa

In questo benchmark, FIO è stato eseguito senza l'opzione randrepeat per casualizzare i dati. Di conseguenza, è entrata in gioco una quantità indeterminato di memorizzazione nella cache. Questa configurazione comporta un numero di prestazioni leggermente migliore rispetto ai test eseguiti senza memorizzare nella cache l'intero stack di I/O usato.

Nel grafico seguente, il test mostra un volume regolare di Azure NetApp Files che può gestire tra circa 130.000 scritture casuali 4 KiB pure e circa 460.000 letture casuali 4 KiB pure durante questo benchmark. Combinazione di lettura/scrittura per il carico di lavoro regolato del 10% per ogni esecuzione.

Man mano che la combinazione di operazioni di I/OP di lettura/scrittura aumenta verso un numero elevato di operazioni di scrittura, la riduzione totale delle operazioni di I/O al secondo.

Risultati: 4 KiB, casuale, memorizzazione nella cache client esclusa

In questo benchmark, FIO è stato eseguito con l'impostazione randrepeat=0 per casualizzare i dati, riducendo l'influenza della memorizzazione nella cache sulle prestazioni. Ciò ha comportato una riduzione approssimativa dell'8% delle operazioni di I/O al secondo di scrittura e una riduzione approssimativa del 17% delle operazioni di I/O al secondo di lettura, ma visualizza i numeri di prestazioni più rappresentativi delle operazioni effettivamente consentite dall'archiviazione.

Nel grafico seguente, il test mostra un volume regolare di Azure NetApp Files che può gestire tra circa 120.000 scritture casuali casuali da 4 KiB pure e circa 388.000 letture casuali pure da 4 KiB. Combinazione di lettura/scrittura per il carico di lavoro regolato del 25% per ogni esecuzione.

Man mano che la combinazione di operazioni di I/OP di lettura/scrittura aumenta verso un numero elevato di operazioni di scrittura, la riduzione totale delle operazioni di I/O al secondo.

Risultati: 8 KiB, casuale, memorizzazione nella cache client esclusa

Le dimensioni di lettura e scrittura maggiori comportano un minor numero totale di operazioni di I/O al secondo, perché con ogni operazione è possibile inviare più dati. È stata usata una dimensione di lettura e scrittura da 8 KiB per simulare in modo più accurato le applicazioni più moderne usate. Ad esempio, molte applicazioni EDA usano letture e scritture da 8 KiB.

In questo benchmark, FIO è stato eseguito con randrepeat=0 per casualizzare i dati in modo che l'impatto sulla memorizzazione nella cache del client sia stato ridotto. Nel grafico seguente, il test mostra che un volume regolare di Azure NetApp Files può gestire tra circa 111.000 scritture casuali 8-KiB pure e circa 293.000 letture casuali 8-KiB pure. Combinazione di lettura/scrittura per il carico di lavoro regolato del 25% per ogni esecuzione.

Man mano che la combinazione di operazioni di I/OP di lettura/scrittura aumenta verso un numero elevato di operazioni di scrittura, la riduzione totale delle operazioni di I/O al secondo.

Confronti side-by-side

Per illustrare come la memorizzazione nella cache può influenzare i test del benchmark delle prestazioni, il grafico seguente mostra il totale di operazioni di I/O al secondo per i test da 4 KiB con e senza meccanismi di memorizzazione nella cache. Come illustrato, la memorizzazione nella cache offre un lieve incremento delle prestazioni per le operazioni di I/O al secondo piuttosto coerenti.

Offset specifico, carichi di lavoro di lettura/scrittura casuali in streaming: test di scalabilità orizzontale tramite connessioni di rete parallele (nconnect)

I test seguenti mostrano un benchmark di I/OP elevato usando un singolo client con carichi di lavoro casuali da 4 KiB e un set di dati a 1 TiB. La combinazione di carico di lavoro generata usa una profondità di I/O diversa ogni volta. Per migliorare le prestazioni per un singolo carico di lavoro client, è stata usata l'opzione nconnect di montaggio per migliorare il parallelismo rispetto ai montaggi client senza l'opzione nconnect di montaggio.

Quando si usa una connessione TCP standard che fornisce un solo percorso all'archiviazione, vengono inviate meno operazioni totali al secondo rispetto a quando un montaggio è in grado di sfruttare più connessioni TCP (ad esempio con nconnect) per punto di montaggio. Quando si usa nconnect, la latenza totale per le operazioni è in genere inferiore. Questi test vengono eseguiti anche con randrepeat=0 per evitare intenzionalmente la memorizzazione nella cache. Per altre informazioni su questa opzione, vedere Metodologia di test.

Risultati: 4 KiB, casuale, con e senza nconnect, memorizzazione nella cache esclusa

I grafici seguenti mostrano un confronto side-by-side di letture e scritture da 4 KiB con e senza nconnect evidenziare i miglioramenti delle prestazioni riscontrati quando si usa nconnect: operazioni di I/O al secondo complessive più elevate, minore latenza.

Benchmark ad alta velocità effettiva

I benchmark seguenti mostrano le prestazioni ottenute per Azure NetApp Files con un carico di lavoro con velocità effettiva elevata.

I carichi di lavoro con velocità effettiva elevata sono più sequenziali e spesso sono pesanti in lettura/scrittura con metadati bassi. La velocità effettiva è in genere più importante rispetto alle operazioni di I/O al secondo. Questi carichi di lavoro sfruttano in genere dimensioni di lettura/scrittura maggiori (da 64K a 256.000), che generano latenze più elevate rispetto alle dimensioni di lettura/scrittura inferiori, poiché i payload più grandi richiedono naturalmente più tempo per l'elaborazione.

Esempi di carichi di lavoro con velocità effettiva elevata includono:

• Repository multimediali
• High Performance Computing (HPC)
• INTELLIGENZA ARTIFICIALE/ML/LLP

I test seguenti mostrano un benchmark a velocità effettiva elevata che usa carichi di lavoro sequenziali da 64 KiB e 256 KiB e un set di dati a 1 TiB. La combinazione di carico di lavoro generata riduce una percentuale impostata alla volta e dimostra ciò che è possibile prevedere quando si usano rapporti di lettura/scrittura variabili (ad esempio, 100%:0%, 90%:10%, 80%:20%e così via).

Risultati: 64 KiB sequenziali I/O, memorizzazione nella cache inclusa

In questo benchmark, FIO è stato eseguito usando la logica di ciclo che ha popolato in modo più aggressivo la cache, quindi una quantità indeterminato di memorizzazione nella cache ha influenzato i risultati. Ciò comporta un numero di prestazioni leggermente migliore rispetto ai test eseguiti senza memorizzazione nella cache.

Nel grafico seguente, il test mostra che un volume regolare di Azure NetApp Files può gestire tra circa 4.500MiB/s letture sequenziali pure da 64 KiB e circa 1.600MiB/s scritture sequenziali pure da 64 KiB. La combinazione di lettura/scrittura per il carico di lavoro è stata modificata del 10% per ogni esecuzione.

Risultati: 64 KiB sequenziale I/O, memorizzazione nella cache esclusa

In questo benchmark, FIO è stato eseguito usando la logica di ciclo che ha popolato in modo meno aggressivo la cache. La memorizzazione nella cache del client non ha influenzato i risultati. Questa configurazione comporta numeri di prestazioni di scrittura leggermente migliori, ma numeri di lettura inferiori rispetto ai test senza memorizzazione nella cache.

Nel grafico seguente, il test dimostra che un volume regolare di Azure NetApp Files può gestire tra circa 3.600MiB/s letture sequenziali pure da 64 KiB e circa 2.400MiB/s scritture sequenziali pure da 64 KiB. Durante i test, una combinazione di 50/50 ha mostrato una velocità effettiva totale pari a un carico di lavoro di lettura sequenziale puro.

La combinazione di lettura/scrittura per il carico di lavoro è stata modificata del 25% per ogni esecuzione.

Risultati: 256 KiB sequenziale I/O, memorizzazione nella cache esclusa

In questo benchmark, FIO è stato eseguito usando la logica di ciclo che ha popolato in modo meno aggressivo la cache, quindi la memorizzazione nella cache non ha influenzato i risultati. Questa configurazione comporta un numero di prestazioni di scrittura leggermente inferiore rispetto ai test di 64 KiB, ma numeri di lettura superiori rispetto agli stessi test da 64 KiB eseguiti senza memorizzazione nella cache.

Nel grafico seguente, il test mostra che un volume regolare di Azure NetApp Files può gestire tra circa 3.500MiB/s letture sequenziali pure da 256 KiB e circa 2.500MiB/s scritture sequenziali pure da 256 KiB. Durante i test, una combinazione di 50/50 ha mostrato un picco di velocità effettiva totale superiore a un carico di lavoro di lettura sequenziale puro.

La combinazione di lettura/scrittura per il carico di lavoro è stata modificata in incrementi del 25% per ogni esecuzione.

Confronto affiancato

Per mostrare meglio come la memorizzazione nella cache può influenzare i test del benchmark delle prestazioni, il grafico seguente mostra il totale di MiB/s per i test da 64 KiB con e senza meccanismi di memorizzazione nella cache. La memorizzazione nella cache offre un miglioramento iniziale delle prestazioni per il totale di MiB/s perché la memorizzazione nella cache migliora in genere le letture in modo maggiore rispetto alle scritture. Man mano che la combinazione di lettura/scrittura cambia, la velocità effettiva totale senza memorizzazione nella cache supera i risultati che utilizzano la memorizzazione nella cache del client.

Connessioni di rete parallele (nconnect)

I test seguenti mostrano un benchmark di I/OP elevato usando un singolo client con carichi di lavoro casuali da 64 KiB e un set di dati a 1 TiB. La combinazione di carico di lavoro generata usa una profondità di I/O diversa ogni volta. Per migliorare le prestazioni per un singolo carico di lavoro client, l'opzione nconnect di montaggio è stata usata per migliorare il parallelismo rispetto ai montaggi client che non usano l'opzione nconnect di montaggio. Questi test sono stati eseguiti solo con la memorizzazione nella cache esclusa.

Risultati: 64 KiB, sequenziale, memorizzazione nella cache esclusa, con e senza nconnect

I risultati seguenti mostrano i risultati di un test di scalabilità orizzontale durante la lettura e la scrittura in blocchi 4-KiB in un montaggio NFSv3 su un singolo client con e senza parallelizzazione delle operazioni (nconnect). I grafici mostrano che, man mano che aumenta la profondità di I/O, aumentano anche le operazioni di I/O al secondo. Tuttavia, quando si usa una connessione TCP standard che fornisce solo un singolo percorso all'archiviazione, vengono inviate meno operazioni totali al secondo rispetto a quando un montaggio è in grado di sfruttare più connessioni TCP per punto di montaggio. Inoltre, la latenza totale per le operazioni è in genere inferiore quando si usa nconnect.

Confronto affiancato (con e senza nconnect)

I grafici seguenti mostrano un confronto affiancato di letture e scritture sequenziali da 64 KiB con e senza nconnect evidenziare i miglioramenti delle prestazioni riscontrati quando si usa nconnect: velocità effettiva complessiva superiore, latenza inferiore.

Ulteriori informazioni

• Metodologia di test