Einführung
Zusammenfassung: In Blog-Episode 1 haben wir RHCS, BlueStore-Einführung, Laborhardwaredetails, Benchmarking-Methodik und Leistungsvergleich zwischen Standard-Ceph-Konfiguration und getunter Ceph-Konfiguration behandelt
Dies ist die zweite Episode der Performance-Blog-Serie über RHCS 3.2 BlueStore, die auf dem All-Flash-Cluster ausgeführt wird. Es gibt keine Faustregel, um Blockgrößen in eine kleine, mittlere und große Kategorie zu kategorisieren. Als solche haben wir 4K zur kleinen Blockgrößenkategorie, 8K-64K zur mittleren und 1M-4M in große Blockgrößenkategorie bezeichnet. In dieser Episode erfahren Sie mehr über die Leistungscharakterisierung von Ceph Block Storage für kleine (4K), mittlere (8K-32K) und große (1M-4M) Blockgrößen über zufällige Lese-, zufällige Schreib- und zufällige Lese-Schreib-Workload-Muster.
Zusammenfassung
- Kleiner Block 4K-Workload, geliefert bis zu 2.2 Millionen zufällige Lesevorgänge, 691 KB zufällige Lese-Schreib-(70/30) und 463 KB zufällige Schreib-IOPS, bis sie durch CPU- und Medienkonflikte begrenzt sind.
- Ähnlich wie bei der Workload kleiner Blöcke wurde festgestellt, dass die Leistung mittlerer Blöcke durch CPU- und Medienkonflikte eingeschränkt ist.
- Große block 4 M arbeitslast spitzen leistung aufgezeichnet zu 10,9 GB/s für alle drei test muster dh gelegentliche lesen, schreiben und lesen-schreiben (70/30) mix bis begrenzte durch die Client netzwerk bandbreite.
Teil 1: Kleine Blockgröße (4 KB) Leistung
Wichtige Erkenntnisse
- Zufällige Leseauslastung
- Random Read-Write (70/30) Mix Workload zeigte 691K IOPS @6ms durchschnittliche Latenz bis zum Engpass durch Ceph Node CPU Resource Contention.
- Random Write: 463K IOPS @ 11ms durchschnittliche Latenz bis zum Engpass durch CPU-Ressourcenkonflikte des Ceph-Knotens.
Zusammenfassung
In diesem Teil des Tests wurde die Ceph-Blockspeicherschnittstelle mit einer kleinen Blockgröße (4 KB) über zufällige Lese-, zufällige Schreib- und zufällige Lese-Schreib-Mischmuster (70/30) getestet. Die während des Tests erfassten Schlüsselmetriken umfassen IOPS, Durchschnitt, Latenz, Ceph-Knoten-CPU und Mediennutzung.
Graph-1 zeigt die Top-Line-Leistung für die 4K-Blockgröße über verschiedene Zugriffsmuster mit 5 All-Flash-Knoten. Als solche wurde die maximale Leistung gefunden
- Gelegentliche Lesen: 2,2 Millionen IOPS @ 3 ms durchschnitt latenz
- Gelegentliche Lesen-Schreiben (70/30) Mix: 691 karat IOPS @ 6 ms durchschnitt latenz
- Gelegentliche Schreiben: 463K IOPS@11ms durchschnittliche Latenz
HDie CPU- und Mediennutzung, die in Grafik 2 und Grafik 3 erfasst wurde, half uns, die Engpässe für verschiedene Workload-Muster zu verstehen.
- Es wurde festgestellt, dass die zufällige Leseleistung durch CPU-Ressourcenkonflikte beeinträchtigt wird, aber auch die Mediennutzung war höher. Da wir zusätzliche Ceph-Knoten (CPU und Medien) hinzugefügt haben, hätte die zufällige Leseleistung höher skaliert werden können.
- Sowohl beim Random Write- als auch beim Random Read-Write-Mix (70/30) wurde die Leistung durch einen höheren CPU-Verbrauch beeinträchtigt. Interessanterweise verfügten Medien gleichzeitig über genügend freien Durchsatz, der aufgrund fehlender Rechenleistung ungenutzt blieb. Daher hätte eine höhere CPU-Kernzuweisung an Ceph-OSDs eine höhere Leistung für zufällige Schreib- & zufällige Lese-Schreib-Mix-Workloads liefern können.
Die Auslastung des OSD-Datengeräts (P4500 NVMe) blieb unter 50%, das Intel Optane P4800-Gerät, auf dem BlueStore WAL- und Rocksdb-Metadaten gehostet wurden, war bei 90% sehr ausgelastet. Der Parameter bluestore_min_alloc_size_ssd wurde auf 16 KB gesetzt, daher wurden alle Schreibvorgänge unter 16 KB verschoben, der Schreibvorgang geht zuerst in das WAL-Gerät und wird dann asynchron in die OSD-Daten geschrieben, daher hatte das Optane P4800-Gerät absorbiert die Schreibvorgänge für alle OSDs auf dem Host. Trotz der hohen Auslastung auf dem RocksDB / WAL-Gerät haben wir keine Anzeichen von Konflikten auf dem P4500 OSD-Datengerät gesehen. Aufgrund dieser Erfahrung würden wir jedoch nicht empfehlen, mehr als 7 x P4500 NVMe-Geräte hinter einen einzelnen Intel Optane P4800 für WAL / RocksDB zu stellen.
Graph 2
Graph 3
Ein weiterer interessanter Test, den wir durchgeführt haben, war der Client-Sweep-Test, bei dem wir die Anzahl der Clients linear von 20 auf 140 erhöht haben. Als wir die Client-Last erhöhten, beobachteten wir eine lineare Leistungsverbesserung, bis wir eine CPU-Überlastung auf Ceph OSD erreichten. Mit 100 Clients haben wir ~ 445K aggregierte 4K Schreib-IOPS beobachtet. Nach diesem Punkt führte die Überlastung der Systemressourcen zu hohen Tail-Latenzen. Intel Optane, das als Metadaten verwendet wurde, trug dazu bei, Latenzspitzen mit einer hohen Anzahl paralleler Clients zu absorbieren, da die durchschnittliche Latenz unter 40 ms blieb.
G
Teil-2: Mittlere Blockgröße Leistung
Wichtige Erkenntnisse
- Bis die Leistung durch CPU- und Mediensättigung beeinträchtigt wurde, lieferten 5 All-Flash-Ceph-Knoten ~ 1,8 Millionen zufällige Lesevorgänge, ~ 636K zufällige Lesevorgänge (70/30) und ~ 410K zufällige Schreib-IOPS.
- Um die Leistung zu skalieren, mussten zusätzliche Ceph OSD Nodes im bestehenden Ceph Cluster hinzugefügt werden.
Zusammenfassung
In den folgenden Diagrammen haben wir versucht, verschiedene Datenpunkte wie IOPS, durchschnittliche Latenz, Tail-Latenz, Ceph-Knoten-CPU und Mediennutzung darzustellen. Und all dies in einem Bereich von Blockgrößen, dh von 4K bis 64K für Random Write, Random Read und Random Read-Write (70/30) Mix.
Einige interessante Datenpunkte sind
- Wie erwartet zeigten kleine Blockgrößen im Vergleich zu mittleren Blockgrößen die höchsten IOPS und niedrigere Durchschnitts- und Tail-Latenzen. Als solche beobachteten wir ~ 1,8 Millionen, ~ 636K, ~ 410K IOPS für zufällige Lese-, zufällige Schreib- und zufällige Schreib-Workload.
- Auf CPU- und Mediengeräten auf Ceph OSD-Knoten wurde eine hohe Auslastung beobachtet. Die Auslastung wurde als ~ 90% bzw. ~ 80% für CPU bzw. Daher hätte die Leistung erhöht werden können, wenn wir dem vorhandenen Ceph-Cluster Ceph-OSD-Knoten hinzugefügt hätten.
G
Teil-3: Große Blockgröße Leistung
Key Takeaways
- Große Block 4M Leistung erreichte bei 10.9 GB/s für gelegentliche lesen, schreiben und lesen-schreiben (70/30) mix.
- Das Clientnetzwerk erwies sich als limitierender Faktor und verursachte einen Leistungsengpass.
- Die Leistung hätte höher sein können, hätten wir entweder mehr Client-Knoten oder größere Netzwerk-Pipes gehabt.
Zusammenfassung
Alle verschiedenen Muster, die wir getestet haben, dh zufällige Lese-, Schreib- und Lese-Schreib-Mix (70/30) für große Blockgröße 4M Workload gekrönt bei 10,9 GB / s aggregierten Durchsatz. Es wurde festgestellt, dass das Client-Netzwerk der limitierende Faktor ist, der den Leistungsengpass verursacht. Abgesehen vom Netzwerk waren Medien die am zweithäufigsten genutzte Ressource, es stand jedoch genügend Headroom zur Verfügung, um mehr Leistung zu liefern, wenn das Netzwerk nicht der Engpass war.
G
Als Nächstes
In Fortsetzung der Benchmarking-Blogserie werden im nächsten Abschnitt die Ergebnisse im Zusammenhang mit RHCS 3.2-Skalierbarkeitstests erläutert. Beantwortung einiger wichtiger Fragen wie „Wie ändert sich die Leistung, wenn von 3 Knoten auf 5 Knoten gewechselt wird?“. Bleiben Sie dran.