Verbesserung der Performance mehrerer I/O-Threads für OpenShift Virtualization

Red Hat OpenShift Virtualization 4.19 verbessert die Performance und Geschwindigkeit für I/O-intensive Workloads wie Datenbanken erheblich. Multiple IO Threads für Red Hat OpenShift Virtualization ist ein neues Feature, mit dem Disk-I/Os von virtuellen Maschinen (VMs) auf mehrere Worker-Threads auf dem Host verteilt werden können, die wiederum Disk-Warteschlangen innerhalb der VM zugeordnet sind. So kann eine VM sowohl die vCPU als auch die Host-CPU effizient für Multi-Stream-I/O nutzen und so die Performance verbessern.

Dieser Artikel ergänzt die Vorstellung der Funktionen meiner Kollegin Jenifer Abrams. Im Anschluss stelle ich Performanceergebnisse zur Verfügung, damit Sie Ihre VM optimieren und einen besseren I/O-Durchsatz erzielen können.

Zum Testen habe ich fio mit Linux-VMs als synthetische I/O-Workload verwendet. Es sind weitere Tests mit Anwendungen auch unter Microsoft Windows vorgesehen.

Weitere Hintergrundinformationen zur Implementierung dieses Features in KVM finden Sie in diesem Artikel über IOThread Virtqueue Mapping sowie in diesem Begleitartikel, in dem Performanceverbesserungen für Datenbank-Workloads in VMs demonstriert werden, die in einer Red Hat Enterprise Linux (RHEL) Umgebung ausgeführt werden. 

Beschreibung des Tests

Ich habe den I/O-Durchsatz für 2 Konfigurationen getestet: 

1. Ein Cluster mit lokalem Storage unter Verwendung des Logical Volume Managers, der vom Local Storage Operator (LSO) bereitgestellt wird.
2. Ein separater Cluster, der OpenShift Data Foundation (ODF) verwendet. 

Die Konfigurationen sind sehr unterschiedlich und können nicht verglichen werden.

Wir haben den Test mit Pods (als Baseline) und VMs durchgeführt. Den VMs wurden 16 Kerne und 8 GB RAM zugewiesen. Ich habe Testdateien mit 512 GB mit 1 VM und 256 GB mit 2 VMs verwendet. Ich habe in allen Tests direkten I/O verwendet. Ich habe Persistent Volume Claims (PVC) im Blockmodus und der ext4-Formatierung für VMs und PVCs im Dateisystemmodus, ebenfalls als ext4 formatiert, für Pods verwendet. Alle Tests wurden mit der I/O-Engine „libaio“ durchgeführt.

Ich habe die folgende Matrix getestet:

Zur Orchestrierung der Tests habe ich ClusterBuster verwendet. Die VMs verwendeten CentOS Stream 9, und die Pods verwendeten ebenfalls CentOS Stream als Container Image-Basis.

Lokaler Storage

Der lokale Storage-Cluster war ein Cluster mit 5 Knoten (3 Master + 2 Worker), bestehend aus Dell R740xd-Knoten mit 2 Intel Xeon Gold 6130 CPUs mit jeweils 16 Kernen und 2 Threads (32 CPUs) für insgesamt 32 Kerne und 64 CPUs. Jeder Knoten enthielt 192 GB RAM. Das I/O-Subsystem bestand aus 4 Kioxia CM6 MU 1,6 TB NVMe-Laufwerken von Dell, die als RAID0 Striped Multiple Device (MD) mit Standardeinstellungen konfiguriert waren. Persistent Volume Claims wurden mit dem lvmcluster-Operator aus dieser MD herausgearbeitet. Leider war diese eher unkomplizierte Konfiguration alles, was mir zur Verfügung stand. Es ist gut möglich, dass ein schnelleres I/O-System zu noch mehr Verbesserung durch mehrere I/O-Threads führen würde.

OpenShift Data Foundation 

Der ODF-Cluster (OpenShift Data Foundation) war ein Cluster mit 6 Knoten (3 Master + 3 Worker), der aus Dell PowerEdge R7625-Knoten mit 2 AMD EPYC 9534-CPUs mit jeweils 64 Kernen und 2 Threads (128 CPUs) für 128 Kerne und 256 CPUs insgesamt bestand. Jeder Knoten enthält 512 GB RAM. Das I/O-Subsystem bestand aus 2 NVMe-Laufwerken mit 5,8 TB pro Knoten mit 3-Wege-Replikation über ein standardmäßiges Pod-Netzwerk mit 25 GbE. Ich hatte für diesen Test keinen Zugang zu einem schnelleren Netzwerk, aber neuere Netzwerkhardware hätte wahrscheinlich für einen besseren Uplift gesorgt.

Zusammenfassung der Ergebnisse

Bei diesem Test werden mehrere I/O-Threads mit spezifischen I/O-Backends bewertet, die möglicherweise nicht repräsentativ für Ihren Use Case sind. Unterschiede in den Storage-Eigenschaften können einen großen Einfluss auf die Auswahl der Anzahl von I/O-Threads haben.

Nun mehr zu den Ergebnissen meiner Tests.

• Maximaler I/O-Durchsatz: Für lokalen Storage betrug der maximale Durchsatz etwa 7,3 GB/s (Lesen) und 6,7 GB/s (Schreiben) für Pods und VMs, und zwar unabhängig von iodepth oder der Anzahl der Jobs auf dem lokalen Storage. Das ist erheblich weniger, als von der Hardware erwartet werden würde. Die Geräte (mit jeweils 4 PCIe gen4) sind für 6,9 GB/s (Lesen) und 4,2 MB/s (Schreiben) ausgelegt. Den Grund dafür habe ich nicht untersucht, aber ich habe das System auf veralteter Hardware ausgeführt. Die Top-Performance ist deutlich besser als die Performance mit einem einzelnen Laufwerk, was darauf hindeutet, dass Striping funktionierte. Bei ODF lag der Bestwert, den wir erreicht haben, bei etwa 5 GB/s (Lesen) und 2 GB/s (Schreiben).
• Bei dem I/O für große Blöcke (1 MB) kam es kaum zu einer Verbesserung, da die Performance bereits durch das System begrenzt war.
• Die optimale Wahl für die Anzahl der I/O-Threads hängt von den Workload- und Storage-Eigenschaften ab. Wie erwartet zeigten Workloads ohne signifikante I/O-Nebenläufigkeit kaum Vorteile.
  • Lokaler Storage: Für VMs mit erheblicher I/O-Nebenläufigkeit sind 4–8 im Allgemeinen ein guter Ausgangspunkt. Insbesondere für Workloads mit geringer I/O-Größe und großer Nebenläufigkeit können mehr Threads von Vorteil sein.
  • ODF: Mehr als 1 I/O-Thread brachte selten einen signifikanten Vorteil, und in vielen Fällen wurde gar keiner benötigt. Dies ist wahrscheinlich auf das vergleichsweise langsame Pod-Netzwerk zurückzuführen. Ein schnelleres Networking führt wahrscheinlich zu anderen Ergebnissen.
• Mehrere I/O-Threads waren bei mehreren gleichzeitigen Jobs effektiver bei der Verbesserung als mit tiefem asynchronem I/O, zumindest bei diesem Test.
• Es gab kaum Unterschiede im Verhalten zwischen 1 und 2 gleichzeitigen VMs, bis der zugrundeliegende aggregierte maximale I/O-Durchsatz (siehe oben) erreicht wurde.
• Mehrere I/O-Threads konnten die Lücke zu Pods mit einer geringeren Jobanzahl oder I/O-iodepth nicht vollständig schließen. Bei einer hohen I/O-iodepth und kleinen Vorgängen zeigten VMs eine bessere Performance als Pods bei Schreibvorgängen.

In Zahlen

Hier ist der I/O-Gesamtdurchsatz, der bei Verwendung mehrerer I/O-Threads auf meinem lokalen Storage-basierten System erreicht werden kann. Wie Sie sehen, können Workloads mit kleineren I/O-Größen und viel Parallelverarbeitung zu einem schnellen I/O-System große Vorteile bieten. Im Folgenden präsentiere ich weitere meiner Ergebnisse in Bezug auf die Vorteile, die ich mit der unterschiedlichen Anzahl von I/O-Threads erhalten habe. Bei einer Blockgröße von 1 MB konnte ich nur eine geringfügige Verbesserung feststellen, da die Performance bereits sehr nahe am zugrunde liegenden Systemlimit war. Mit noch schnellerer Hardware ist es möglich, dass zusätzliche I/O-Threads selbst bei großen Blockgrößen zu Verbesserungen führen.

Hier ist die Anzahl an I/O-Threads, die erforderlich sind, um 90 % des besten Ergebnisses zu erreichen, das mit bis zu 16 I/O-Threads erreichbar ist. Wenn beispielsweise das beste Ergebnis, das in meinem Test mit einer bestimmten Kombination aus Vorgang, Blockgröße, Jobs und iodepth erzielt wurde, 1 GB/s war, dann wäre die hier gemanagte Metrik die geringsten Threads, die benötigt werden, um 900 MB/s zu erreichen. Dies ermöglicht das Festlegen einer konservativen Anzahl von Threads bei gleichzeitig guter Performance.

Detaillierte Ergebnisse

Für jeden gemessenen Testfall habe ich die folgenden Leistungszahlen berechnet:

1. Messung des I/O-Durchsatzes
2. Beste VM-Performance (nicht direkt angegeben)
3. Minimale Anzahl an I/O-Threads, um 90 % der besten VM-Performance zu erreichen
4. Verhältnis zwischen bester VM-Performance und Pod-Performance
5. Verbesserung der besten VM-Performance im Vergleich zur Baseline-VM-Performance

Ich gebe NICHT die Anzahl der Threads für die beste Performance an, da die Unterschiede in vielen Fällen sehr klein waren, also geringer als die normale Abweichung bei der Angabe der I/O-Performance.

Da die Eigenschaften so unterschiedlich sind, stelle ich separate Zusammenfassungen der Ergebnisse für lokalen Storage und ODF bereit.

Alle folgenden Performancediagramme zeigen Ergebnisse für Pods (pod), eine Baseline-VM ohne I/O-Threads (0) und die angegebene Anzahl von I/O-Threads auf der X-Achse.

Lokaler Storage

Wenn wir die reine Performance betrachten, sehen wir, dass die Verwendung mehrerer I/O-Threads zumindest in einigen Fällen von großem Vorteil ist. Beispiel: Bei 16 Jobs kann asynchroner I/O mit iodepth 1 auf lokalem Storage durch die Verwendung zusätzlicher I/O-Threads zu einem Vorteil in etwa in dieser Größenordnung führen:

Selbst bei einem einzelnen Stream-I/O kann die Verwendung eines zusätzlichen I/O-Threads von Vorteil sein. Es überrascht nicht, dass mehr als eine nicht hilft:

Es gibt abweichende Fälle, in denen zusätzliche I/O-Threads tatsächlich die Performance beeinträchtigen. In einem solchen Fall wird bei Verwendung von tiefem asynchronem I/O mit kleinen Blöcken die beste Performance (sogar besser als Pods) mit VMs erreicht, die keine dedizierten I/O-Threads verwenden. Ich habe nicht herausgefunden, warum das so ist.

Dies zeigt, dass Sie mit Ihren jeweiligen Workloads experimentieren müssen, um die optimale Performance aus mehreren I/O-Threads herauszuholen.

ODF-Cluster-Ergebnisse

Im Gegensatz zum lokalen Storage, bei dem das zufällige Schreiben kleiner Blöcke mit mehreren I/O-Threads eine erhebliche Verbesserung zeigte, konnte ich mit ODF selbst bei einer hohen Anzahl von Jobs nur minimale Verbesserungen beobachten. Es ist wahrscheinlich, dass schnellere Netzwerke oder niedrigere Latenz größere Vorteile mit sich bringen. Lesevorgänge (read), insbesondere zufälliges Lesen (random read), zeigten einen kleinen Vorteil, aber Schreibvorgänge (write) und eine geringere Jobanzahl zeigten unwesentliche bis keine Vorteile.

Schlussfolgerungen

Multiple I/O-Threads für OpenShift Virtualization sind eine spannende neue Funktion in OpenShift 4.19, die das Potenzial erheblicher Verbesserungen der I/O-Performance für Workloads mit gleichzeitigem I/O bietet, insbesondere bei schnellen I/O-Systemen wie dem in meinen Tests verwendeten lokalen NVMe-Storage. Schnellere I/O-Subsysteme werden voraussichtlich am meisten von mehreren I/O-Threads profitieren, da mehr CPUs benötigt werden, um den zugrunde liegende Bare Metal-I/O vollständig zu steuern. Wie immer bei I/O können Unterschiede in den I/O-Systemen und den allgemeinen Workloads die Performance stark beeinflussen. Ich empfehle daher, Ihre eigenen Workloads zu testen, um diese neue Funktion optimal zu nutzen. Ich hoffe, dass meine Testergebnisse Ihnen dabei helfen, eine gute Wahl für I/O-Threads zu treffen.