Migliora le prestazioni di più thread di I/O per OpenShift Virtualization

Red Hat OpenShift Virtualization 4.19 migliora notevolmente le prestazioni e la velocità dei carichi di lavoro di I/O intensivi, come i database. Multiple IOThreads for Red Hat OpenShift Virtualization è una nuova funzionalità che consente di distribuire l'I/O su disco delle macchine virtuali (VM) tra più thread di lavoro sull'host, che a loro volta vengono mappati nelle code dei dischi all'interno della VM. Ciò consente alle VM di utilizzare in modo efficiente sia la vCPU che la CPU dell'host per l'I/O multistream, migliorando le prestazioni.

Questo articolo completa la presentazione della funzionalità della mia collega Jenifer Abrams. In aggiunta, fornisco i risultati delle prestazioni per aiutarti a ottimizzare la tua VM e ottenere un throughput di I/O migliore.

Per i test, ho utilizzato fio con le VM Linux come carico di lavoro di I/O sintetico. Sono in corso altre attività di test con le applicazioni e anche su Microsoft Windows.

Per ulteriori informazioni sull'implementazione di questa funzionalità in KVM, consulta l'articolo sul mapping di Virtqueue di IOThread e questo articolo complementare che illustra i miglioramenti delle prestazioni per i carichi di lavoro del database nelle VM eseguite in un ambiente Red Hat Enterprise Linux (RHEL). 

Descrizione del test

Ho testato il throughput di I/O su due configurazioni: 

1. un cluster con storage locale che utilizza Logical Volume Manager fornito dal Local Storage Operator (LSO);
2. un cluster separato che utilizza OpenShift Data Foundation (ODF). 

Le configurazioni sono molto diverse e non è possibile metterle a confronto.

I test sono stati eseguiti su pod (come baseline) e VM. Alle VM sono stati assegnati 16 core e 8 GB di RAM. Per i test ho utilizzato file da 512 GB con 1 VM e da 256 GB con 2 VM. In tutti i test ho utilizzato l'I/O diretto. Ho utilizzato le attestazioni di volume persistenti (PVC), in modalità a blocchi e formattate come ext4, per le VM, e le PVC in modalità filesystem, anch'esse formattate come ext4 per i pod. Tutti i test sono stati eseguiti con il motore di I/O di libaio.

I test sono stati eseguiti con i dati della tabella seguente:

Ho utilizzato ClusterBuster per orchestrare i test. Le VM utilizzano CentOS Stream 9 e anche i pod utilizzano CentOS Stream come base di immagini dei container.

Storage locale

Il cluster di storage locale è un cluster a 5 nodi (3 nodi master + 2 nodi di lavoro) costituito da nodi Dell R740xd contenenti 2 CPU Intel Xeon Gold 6130, ciascuna con 16 core e 2 thread (32 CPU) per un totale di 32 core e 64 CPU. Ogni nodo contiene 192 GB di RAM. Il sottosistema di I/O è costituito da quattro unità Kioxia CM6 MU 1,6 TB NVMe a marchio Dell configurate come configurazione di più dispositivi (MD) con striping RAID0 con impostazioni predefinite. Le richieste di volumi persistenti sono state estratte da questa MD utilizzando l'operatore lvmcluster. Questa modesta configurazione era l'unica che avevo a disposizione ed è molto probabile che un sistema di I/O più veloce avrebbe prodotto ulteriori miglioramenti da più thread di I/O.

OpenShift Data Foundation 

Il cluster OpenShift Data Foundation (ODF) è un cluster a 6 nodi (3 nodi master + 3 nodi di lavoro) costituito da nodi Dell PowerEdge R7625 contenenti 2 CPU AMD EPYC 9534, ciascuna con 64 core e 2 thread (128 CPU), per un totale di 128 core e 256 CPU. Ogni nodo contiene 512 GB di RAM. Il sottosistema di I/O è costituito da due unità NVMe da 5,8 TB per nodo, con replica a 3 vie su una rete di pod predefinita da 25 GbE. Non avevo accesso a una rete più veloce per questo test, ma un hardware di rete più recente avrebbe probabilmente garantito un miglioramento più netto.

Riepilogo dei risultati

Questo test valuta più thread di I/O con back end di I/O specifici che potrebbero non rappresentare il tuo scenario di utilizzo. Le differenze nelle caratteristiche dello storage possono incidere notevolmente sulla scelta del numero di thread di I/O.

Ecco cosa hanno rivelato i miei test.

• Throughput di I/O massimo: per lo storage locale, il throughput massimo è stato di circa 7,3 GB/sec in lettura e 6,7 GB/sec in scrittura, sia per i pod che per le VM, indipendentemente dall'iodepth o dal numero di processi nello storage locale. Questo dato è sostanzialmente inferiore a quanto ci si aspetterebbe dall'hardware. I dispositivi (4 PCIe gen4) hanno una velocità nominale di 6,9 GB/sec in lettura e 4,2 MB/sec in scrittura. Non ho ancora esaminato le cause, ma ho utilizzato un hardware obsoleto. Le prestazioni superiori sono chiaramente migliori rispetto alle prestazioni dell'unità singola, il che indica che lo striping ha avuto effetto. Per ODF, la prestazione massima ottenuta è di circa 5 GB/sec in lettura e 2 GB/sec in scrittura.
• L'I/O a blocchi di grandi dimensioni (1 MB) ha mostrato un miglioramento minimo o nullo, perché le prestazioni erano già limitate dal sistema.
• La scelta ottimale per il numero di thread di I/O varia in base al carico di lavoro e alle caratteristiche dello storage. Come previsto, i carichi di lavoro con un numero non significativo di I/O simultanei hanno offerto scarsi vantaggi.
  • Storage locale: per le VM con un numero significativo di I/O simultanei, 4-8, è in genere un buon punto di partenza. Soprattutto per i carichi di lavoro che utilizzano dimensioni di I/O ridotte e simultaneità elevata, più thread possono risultare vantaggiosi.
  • ODF: in rari casi la presenza di più di un thread di I/O simultanei ha prodotto vantaggi significativi e in molti casi non è stato necessario aggiungerne. Ciò è forse dovuto alla rete di pod relativamente lenta; è probabile che una rete più rapida produca risultati diversi.
• Almeno con questo test, più thread di I/O si sono dimostrati più efficaci nell'offrire miglioramenti con più processi simultanei rispetto all'I/O asincrono su più livelli.
• Ho rilevato poca differenza nel comportamento tra 1 e 2 VM simultanee fino a quando non è stato raggiunto il throughput massimo aggregato di I/O alla base (indicato sopra).
• I thread di I/O simultanei non hanno colmato completamente il divario con i pod, con un numero di processi inferiore o con iodepth I/O. Con un iodepth I/O più elevato e operazioni di piccole dimensioni, le VM hanno effettivamente superato i pod, con margini significativi nelle operazioni di scrittura.

Vantaggi in cifre

Di seguito è riportato il throughput di I/O complessivo che si ottiene utilizzando più thread di I/O sul mio sistema basato su storage locale. Come si può vedere, i carichi di lavoro con dimensioni di I/O più piccole e un grado di parallelismo elevato rispetto a un sistema di I/O veloce possono offrire grandi vantaggi. Di seguito riporto altri risultati ottenuti con diversi valori relativi ai thread di I/O. Ho riscontrato solo un lieve miglioramento con una dimensione del blocco di 1 MB, perché le prestazioni erano già molto vicine al limite del sistema alla base. Con un hardware più veloce, è possibile che thread di I/O aggiuntivi producano miglioramenti anche con blocchi di grandi dimensioni.

Di seguito è indicato il numero di thread di I/O necessari per ottenere il 90% del miglior risultato ottenibile con un massimo di 16 thread di I/O. Ad esempio, se il miglior risultato ottenuto nel mio test con una specifica combinazione di operazioni, dimensioni dei blocchi, processi e iodepth è stato di 1 GB/sec, la metrica in questo caso equivale al numero minimo di thread necessari per raggiungere 900 MB/sec. In questo modo è possibile impostare un numero ridotto di thread pur ottenendo prestazioni ottimali.

Risultati dettagliati

Per ogni scenario di test misurato, ho calcolato le seguenti cifre di merito:

1. Misurazione del throughput di I/O
2. Migliori prestazioni delle VM (non segnalate direttamente)
3. Numero minimo di iothread per ottenere il 90% di prestazioni migliori delle VM
4. Rapporto tra le migliori prestazioni delle VM e quelle dei pod
5. Miglioramento delle migliori prestazioni delle VM rispetto alla prestazione della VM di base

NON sto segnalando il numero di thread per la prestazione migliore, perché in molti casi le differenze sono molto piccole, inferiori alla normale varianza delle prestazioni di I/O segnalate.

Fornisco riepiloghi separati per i risultati relativi allo storage locale e a ODF, perché hanno caratteristiche molto diverse.

Tutti i grafici delle prestazioni seguenti mostrano i risultati per i pod (pod), una VM di base senza thread di I/O (0) e il numero specificato di thread di I/O sull'asse X.

Storage locale

Se osserviamo le prestazioni non elaborate, notiamo che, almeno in alcuni casi, l'utilizzo di più thread di I/O offre vantaggi sostanziali. Ad esempio, con 16 processi, I/O asincrono con iodepth 1 sullo storage locale, l'utilizzo di thread di I/O aggiuntivi può, nella maggior parte dei casi, produrre vantaggi consistenti:

Anche con un singolo flusso di I/O, l'utilizzo di un thread I/O in più può offrire vantaggi. Non sempre l'aggiunta di thread è d'aiuto:

In alcuni casi anomali, l'aggiunta di thread di I/O compromette le prestazioni. In questo caso, utilizzando un I/O asincrono su più livelli con blocchi di piccole dimensioni, le prestazioni migliori (anche rispetto ai pod) si ottengono con le VM che non utilizzano thread di I/O dedicati. Non ho ancora stabilito il motivo per cui ciò accade.

Questo lavoro dimostra che per ottenere le migliori prestazioni da più thread di I/O, è necessario effettuare le dovute sperimentazioni con il proprio carico di lavoro specifico.

Risultati del cluster ODF

A differenza dello storage locale, in cui la scrittura casuale di piccoli blocchi ha mostrato notevoli miglioramenti con l'utilizzo di più thread di I/O, con ODF ho osservato un miglioramento minimo, anche con un numero elevato di processi. È probabile che una rete più veloce o una latenza inferiore offrano maggiori vantaggi. Le operazioni di lettura, in particolare la lettura casuale, hanno ottenuto vantaggi modesti, mentre le operazioni di scrittura e un numero di processi inferiore hanno fatto registrare vantaggi scarsi, se non nulli.

Conclusioni

Multiple I/OThreads for OpenShift Virtualization è una nuova interessante funzionalità di OpenShift 4.19 in grado di offrire miglioramenti sostanziali delle prestazioni di I/O per i carichi di lavoro con I/O simultanei, in particolare con i sistemi di I/O veloci come lo storage NVMe locale utilizzato nei miei test. I sottosistemi di I/O più veloci possono ottenere vantaggi elevati dall'utilizzo di più thread di I/O, perché sono necessarie più CPU per gestire l'I/O bare metal alla base. Come sempre per l'I/O, le differenze nei sistemi di I/O e nei carichi di lavoro complessivi possono influire notevolmente sulle prestazioni, quindi ti consiglio di testare i tuoi carichi di lavoro per sfruttare al meglio questa nuova funzionalità. Spero che i risultati dei miei test ti aiuteranno a scegliere consapevolmente i tuoi thread di I/O.