Condividi tramite


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.

Diagramma dei test di benchmark con 4 KiB, memorizzazione nella cache casuale e client inclusa.

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.

Diagramma dei test di benchmark con 4 KiB, casuali, memorizzazione nella cache client esclusa.

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.

Diagramma dei test di benchmark con 8 KiB, casuali, memorizzazione nella cache client esclusa.

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.

Diagramma che confronta 4 test di benchmark KiB.

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.

Diagramma delle prestazioni di lettura da 4 KiB.

Diagramma delle prestazioni di scrittura da 4 KiB.

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.

Diagramma dei test di benchmark da 64 KiB con operazioni di I/O sequenziali e memorizzazione nella cache incluse.

Risultati: 64 KiB sequenziali I/O, letture e scrittura, baseline senza memorizzazione nella cache

In questo benchmark di base, il test dimostra che un volume regolare di Azure NetApp Files può gestire tra circa 3.600 MiB/s letture sequenziali pure da 64 KiB e circa 2.400 MiB/secondo 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.

Per quanto riguarda la lettura pura, la linea di base 64-KiB ha ottenuto prestazioni leggermente migliori rispetto alla baseline di 256 KiB. Quando si tratta di scrittura pura e di tutti i carichi di lavoro di lettura/scrittura misti, tuttavia, la baseline da 256 KiB ha superato 64 KiB, a indicare che una dimensione di blocco maggiore di 256 KiB è più efficace complessivamente per carichi di lavoro con velocità effettiva elevata.

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

Diagramma di 64 test di benchmark KiB con I/O sequenziale, memorizzazione nella cache esclusa.

Risultati: 256 KiB sequenziale I/O senza memorizzazione nella cache

Nei due benchmark di base seguenti, fio è stato usato per misurare la quantità di I/O sequenziale (lettura e scrittura) di un singolo volume regolare in Azure NetApp Files. Per produrre una linea di base che riflette la vera larghezza di banda che un carico di lavoro di lettura completamente non memorizzato nella cache può raggiungere, FIO è stato configurato per l'esecuzione con il parametro randrepeat=0 per la generazione del set di dati. Ogni iterazione di test è stata sfalsata leggendo un set di dati di grandi dimensioni completamente separato non incluso nel benchmark per cancellare qualsiasi memorizzazione nella cache che potrebbe essersi verificata con il set di dati di benchmark.

In questo grafico, il test mostra che un volume regolare di Azure NetApp Files può gestire tra circa 3.500 MiB/s letture sequenziali pure da 256 KiB e circa 2.500 MiB/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.

Diagramma dei test sequenziali di 256 KiB.

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: confronto tra le operazioni di I/O sequenziali 64KiB, cache della velocità effettiva di lettura

Per illustrare in che modo la memorizzazione nella cache influisce sui risultati delle prestazioni, FIO è stato usato nel confronto di micro benchmark seguente per misurare la quantità di operazioni di I/O sequenziali (lettura e scrittura) di un singolo volume regolare in Azure NetApp Files. Questo test è in contrasto con i vantaggi offerti da un carico di lavoro parzialmente memorizzabile nella cache.

Nel risultato senza memorizzazione nella cache, il test è stato progettato per attenuare qualsiasi memorizzazione nella cache, come descritto nei benchmark di base precedenti. Nell'altro risultato, FIO è stato usato nei volumi regolari di Azure NetApp Files senza il randrepeat=0 parametro e usando una logica di iterazione di test di ciclo che ha popolato lentamente la cache nel tempo. La combinazione di questi fattori ha prodotto una quantità indeterminato di memorizzazione nella cache, aumentando la velocità effettiva complessiva. Questa configurazione ha portato a numeri di prestazioni di lettura leggermente migliori rispetto ai test eseguiti senza memorizzazione nella cache.

I risultati dei test visualizzati nel grafico visualizzano il confronto side-by-side delle prestazioni di lettura con e senza l'influenza della memorizzazione nella cache, in cui la memorizzazione nella cache ha prodotto fino a ~4500 MiB/secondo velocità effettiva di lettura, mentre nessuna memorizzazione nella cache ha raggiunto circa 3600 MiB al secondo.

Diagramma del confronto tra velocità effettiva di lettura sequenziale di 64 KiB in base alla memorizzazione nella cache.

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.

Diagramma del confronto tra letture e scritture sequenziali da 64 KiB.

Ulteriori informazioni