Bei der Einrichtung eines neuen Proxmox VE Ceph Clusters sind viele Faktoren relevant. Die richtige Dimensionierung der Hardware, die Konfiguration von Ceph, sowie das richtige Testen der Datenträgern, des Netzwerks und des Ceph-Pools haben große Auswirkungen auf die erzielbare Performance des Systems. In diesem Artikel erfahren Sie, wie Sie einen Proxmox Ceph Cluster planen. Der Artikel hilft Ihnen auch bei der Fehlersuche im Falle von Performance-Problemen von Ceph.
Folgende Begriffe verwenden wir im Artikel:
wikiNodes: die Minimalanzahl an Nodes für den Einsatz von Ceph beträgt 3.Datenträger: jeder dieser Nodes benötigt mindestens 4 Storage-Datenträger (OSDs).OSD: ein OSD (Object Storage Daemon) ist ein Prozess, der für die Speicherung von Daten auf einen zum OSD gehörenden Datenträger verantwortlich ist.Ceph-Cluster: ein Cluster besteht somit aus mindestens 3 Nodes, je 4 Datenträgern (OSDs), welche zusammen dann den Pool (= 12 Disks) bilden.Pool: der Standard-Replikations-Faktor bei Proxmox-VE Ceph Pools ist 3 (3-fach Replikation) (1 Kopie pro Host)Die Anzahl der OSDs in einem Cluster beeinflusst die Gesamtleistung des Clusters. Mehr OSDs ermöglichen eine höhere parallele Verarbeitung und Verteilung der Last. Eine höhere Anzahl an OSDs erhöht jedoch auch die Anforderungen an die Netzwerkbandbreite und die Ressourcen (CPU/RAM) des Clusters.
Ebenso wichtig ist aber auch die Anzahl der Nodes im Cluster. Mehr Knoten bieten mehr Ressourcen und mehr Platz für die Verteilung von OSDs. Somit verteilen sich Lese- und Schreibzugriffe auf das Storage über mehrere Nodes. Dies hat natürlich aber auch Auswirkungen auf die Netzwerkbandbreite, da diese dadurch steigt. Eine ausreichende Anzahl an Switchports und entsprechende Switching-Capacity sollte vorhanden sein.
Ein weiterer Punkt ist das Pool-Setup. Es beeinflusst die Verfügbarkeit und die Datensicherheit der Daten im Cluster. Ein Pool besteht aus einer Gruppe von OSDs (definiert über die Ceph Device-Classes), die für die Speicherung von Daten verantwortlich sind. Der Replikationsfaktor legt fest, wie oft ein Objekt auf mehrere OSDs (auf unterschiedlichen Hosts / eventuell auch Räumen usw.) via CRUSH repliziert wird. Ein höherer Replikationsfaktor erhöht die Datensicherheit, erfordert jedoch auch mehr Speicherplatz. Zudem erhöht er die Latenz für Schreibvorgänge, da Replikate in der Regel mindestens 2 mal geschrieben werden müssen (bei Replikationsfaktor (SIZE=3)), damit ein ACK an den Storage-Client geschickt wird.
Bei einer zu geringen Anzahl an OSDs konzentriert sich die Last auf zu wenige OSDs, was zu Engpässen und einer schlechten Leistung führen kann. Eine zu hohe Anzahl an OSDs kann jedoch auch zu höheren Anforderungen an die Netzwerkbandbreite und Ressourcen des Clusters führen. Hier gilt es eine passende Balance zu finden und ausreichend Ressourcen für das Vorhaben einzuplanen.
Fazit: Es ist wichtig, die Anzahl der OSDs und Knoten sowie das Netzwerk für Ceph sorgfältig zu planen und zu überwachen, um die Leistung und die Verfügbarkeit des Ceph-Clusters zu maximieren und Fallstricke zu vermeiden.
Je nach Anzahl an Ceph Datenträgern sollte man entsprechende Ressourcen für CPU und RAM einplanen.[1][2][3] Je mehr OSDs im System konfiguriert werden, umso mehr CPU Cores und mehr RAM sind erforderlich.
Da die Dimensionierung auch abhängig von der Auswahl und Anzahl der Ceph Dienste (Ceph MON, Ceph MGR, Ceph MDS) ist, helfen wir Ihnen gerne bei der Dimensionierung Ihres nächsten Ceph oder Proxmox Ceph HCI Clusters.
Die wohl größte Rolle für die Performance in Ceph hat das Netzwerk-Setup, welches man für Ceph einsetzt. Warum ist das so? Sehr viele der in Ceph relevanten Dienste sind komplett netzwerkbasiert. Die einzelnen Server (Nodes) kommunizieren rein über das Netzwerk miteinander und tauschen ständig Daten und Informationen untereinander aus. Sie schreiben auch die Datenreplikate über das Netzwerk auf die jeweils anderen Datenträger (OSDs) der Nodes. Das hat natürlich große Auswirkungen auf die Leistung, die man für ein performantes Ceph-Netzwerk benötigt.
Dabei gilt:
Zusätzlich kann der Einsatz von Jumbo-Frames eine Verbesserung der Ceph-Performance erzielen.
Die Leistung eines Ceph-Systems wird auch bedeutend durch die Leistung der verwendeten Datenträger beeinflusst. Kommen SSDs zum Einsatz, sollten folgende Faktoren bei der Auswahl berücksichtigt werden:
DWPD (Drive Writes Per Day): dieser Wert gibt an, wie oft ein Datenträger pro Tag beschrieben werden kann, bevor er potentiell ausfallen könnte. Ein höherer DWPD-Wert bedeutet, dass der Datenträger langlebiger ist.TBW (Total Bytes Written): dieser Wert gibt die Gesamtmenge an Daten an, die auf einen Datenträger geschrieben werden können, bevor er potentiell ausfallen könnte. Ein höherer TBW-Wert bedeutet, dass der Datenträger langlebiger ist.IOPS (Input/Output Operations Per Second): dieser Wert gibt die Anzahl der Ein- und Ausgabeoperationen pro Sekunde an, die ein Datenträger ausführen kann. Typischerweise werden dabei 4 kB große Blockoperationen betrachtet. Ein höherer IOPS-Wert bedeutet, dass mehr Operationen pro Sekunde durchgeführt werden können. Relevant ist dabei auch die Queue Depth, die beschreibt wie viele I/O Operationen parallel vom Testsystem durchgeführt werden.Throughput: dieser Wert gibt die Geschwindigkeit an, mit der Daten auf einen Datenträger geschrieben oder von einem Datenträger gelesen werden können. Ein höherer Throughput-Wert bedeutet, dass der Datenträger schneller ist.Latency: Latency bezieht sich auf die Zeit, die ein Datenträger benötigt, um auf eine Anfrage vollständig zu reagieren, sowohl beim Schreiben als auch beim Lesen von Daten.PLP (Powerloss Protection): der Cache des Datenträgers wird bei einem Stromausfall des Servers noch komplett auf den Datenträger geschrieben und geht somit nicht verloren. Dies bringt den generellen Vorteil, dass das Write-ACK (Acknowledgement) an den Storage-Client bereits nach dem Schreiben in den Cache erfolgen kann, was in einer erhöhten Performance resultieren kann.
Um die Leistung eines einzelnen Datenträgers zu testen, kann das Tool fio verwendet werden. Fio ermöglicht es, verschiedene Schreib- und Lesevorgänge auf dem Datenträger auszuführen und die Ergebnisse in Bezug auf IOPS und Throughput auszugeben. Der folgende Befehl kann verwendet werden, um den Datenträger /dev/nvme0 auf IOPS zu testen, unter Verwendung der Blockgröße 4K:
fio --ioengine=libaio --filename=/dev/nvme0n1 --direct=1 --sync=1 --rw=write --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --time_based --name=fio
| Parameter | Erklärung |
|---|---|
| ioengine=libaio | legt die I/O-Engine für fio fest |
| filename=/dev/nvme0n1 | legt das zu testende Gerät fest |
| direct=1 | aktiviert direkten I/O ohne Cache (kein Pagecache, kein RAM) |
| sync=1 | aktiviert synchronen I/O-Modus (synchrone Writes) |
| rw=write | legt den Schreib-Modus für das Test fest |
| bs=4K | legt die Block-Größe des Tests fest |
| numjobs=1 | legt die Anzahl der parallelen Jobs fest |
| iodepth=1 | legt die IO-Tiefe pro Job fest |
| runtime=60 | legt die Dauer des Tests in Sekunden fest |
| time_based | aktiviert zeitgesteuerten Modus für den Test |
| name=fio | legt den Namen des Tests fest |
Dieser Befehl führt einen Schreibtest mit einer Blockgröße von 4K auf dem Datenträger /dev/nvme0 durch. Der Test wird für eine Dauer von 60 Sekunden durchgeführt und die Ergebnisse in Bezug auf IOPS ausgegeben. Wichtig: die nachfolgenden Ergebnisse haben wir analog zum Proxmox Ceph Performance Paper von der Proxmox Server Solutions GmbH durchgeführt, diese Tests sind nicht geschönt und spiegeln die absolute Minimal-Performance eines einzelnen Datenträgers wieder, da keine Parallelisierung (Number of Jobs = 1) und IO-Depth entsprechend eingestellt wurde. Wir tun dies, damit Sie einen Vergleich ziehen können zu den Werten von Proxmox. Die tatsächliche Performance innerhalb der VM hängt von ganzen vielen anderen Faktoren ab und sollte nicht mit den Werten hier verglichen werden, da es sehr viele Optimierungen und Verbesserungen hierzu gibt.
root@PMX1:~# fio --ioengine=libaio --filename=/dev/nvme0n1 --direct=1 --sync=1 --rw=write --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --time_based --name=fio
fio: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=445MiB/s][w=114k IOPS][eta 00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=2028745: Wed Feb 1 10:37:38 2023
write: IOPS=114k, BW=444MiB/s (465MB/s)(26.0GiB/60001msec); 0 zone resets
slat (nsec): min=1092, max=125185, avg=1238.68, stdev=769.33
clat (nsec): min=251, max=859795, avg=7242.66, stdev=1484.45
lat (usec): min=7, max=861, avg= 8.51, stdev= 1.70
clat percentiles (usec):
| 1.00th=[ 8], 5.00th=[ 8], 10.00th=[ 8], 20.00th=[ 8],
| 30.00th=[ 8], 40.00th=[ 8], 50.00th=[ 8], 60.00th=[ 8],
| 70.00th=[ 8], 80.00th=[ 8], 90.00th=[ 8], 95.00th=[ 8],
| 99.00th=[ 9], 99.50th=[ 9], 99.90th=[ 13], 99.95th=[ 17],
| 99.99th=[ 118]
bw ( KiB/s): min=433496, max=460096, per=100.00%, avg=454720.47, stdev=4372.66, samples=119
iops : min=108374, max=115024, avg=113680.13, stdev=1093.17, samples=119
lat (nsec) : 500=0.01%, 750=0.01%, 1000=0.01%
lat (usec) : 2=0.01%, 4=0.01%, 10=99.78%, 20=0.18%, 50=0.02%
lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
cpu : usr=11.52%, sys=23.95%, ctx=6816318, majf=0, minf=14
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,6816793,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=444MiB/s (465MB/s), 444MiB/s-444MiB/s (465MB/s-465MB/s), io=26.0GiB (27.9GB), run=60001-60001msec
Disk stats (read/write):
nvme0n1: ios=92/6805234, merge=0/0, ticks=2/45719, in_queue=45722, util=99.91%
Ein weiterer wichtiger Faktor, der die Ceph-Performance beeinflussen kann, ist die Netzwerkverbindung. Um die Leistung des Ceph-Netzwerks zu testen, kann das Tool iperf3 verwendet werden. Mit iperf3 können die Bandbreite und die Latenz des Netzwerks gemessen werden. Hierzu erstellt man am besten 2 iperf3 Server und verbindet sich mit einem Client zu diesen iperf-Servern parallel, damit man die maximale Bandbreite des Netzwerks ausreizen kann. Wichtig: Sollten Sie nicht die gewünschte Bandbreite erreichen, erhöhen Sie die Anzahl der iperf3-Server und iperf3-Clients.
# iperf Server auf Server 1 und Server 3 root@PMX1:~# iperf3 -s C-m root@PMX3:~# iperf3 -s C-m # Zwei parallele iperf Clients auf Server 2 root@PMX2:~# iperf3 -c 192.168.99.34 -t 3600 C-m root@PMX2:~# iperf3 -c 192.168.99.36 -t 3600 C-m # Überprüfen der Netzwerklast des Ceph Bonds: bond1 root@PMX2:~# nload bond1 C-m
Innerhalb Ceph kann man auf verschiedenen Ebenen Performance-Tests durchführen. Diese sind grundsätzlich beim Erst-Setup zur Kontrolle einer korrekten Konfiguration sinnvoll, können aber auch nützlich für das Debugging von Performance-Problemen sein.
Um die Leistung eines einzelnen OSD-Datenträgers zu testen, kann das Tool tell osd bench verwendet werden. Der Befehl ceph tell osd.X benchgibt die Leistungsdaten des OSD-Datenträgers mit der ID X zurück.
root@PMX4:~# ceph tell osd.1 bench
{
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 0.572842187,
"bytes_per_sec": 1874411222.4402215,
"iops": 446.89446030622042
}
Die Ausgabe enthält folgende Informationen:
| Parameter | Erklärung |
|---|---|
| bytes_written | Die Anzahl der Bytes, die während des Tests geschrieben wurden |
| blocksize | Die Größe der Datenblöcke, die während des Tests verwendet wurden |
| elapsed_sec | Die Zeitdauer des Tests in Sekunden |
| bytes_per_sec | Die durchschnittliche Schreibrate in Bytes pro Sekunde |
| iops | Die durchschnittliche Anzahl der Schreiboperationen pro Sekunde (IOPS) |
Die Ausgabe zeigt, dass während des Tests 1 GB (1.073.741.824 Bytes) mit einer Blockgröße von 4 MB (4.194.304 Bytes) in 0,57 Sekunden geschrieben wurde. Das entspricht einer durchschnittlichen Schreibrate von 1874411222 Bytes (= 1,87 GB) pro Sekunde und einer durchschnittlichen IOPS-Anzahl von 446 (unter Berücksichtigung von 4 MB Blocksize).
Man kann den Befehl natürlich auch für IOPS mit einer Blocksize von 4K durchführen:
root@PMX4:~# ceph tell osd.1 bench 12288000 4096
{
"bytes_written": 12288000,
"blocksize": 4096,
"elapsed_sec": 0.043518787000000003,
"bytes_per_sec": 282360811.20551449,
"iops": 68935.744923221311
}
Hier ergeben sich aufgrund der Blockgröße 4K ein höherer Wert bei den IOPS und zwar: 68935 IOPS.
| Die Performance-Tests auf Ceph Pool Ebene benötigen - um einen realistischen Gesamtwert der Performance zu erhalten - mehrfache Ausführung und Parallelisierung. Das heißt konkret: ein einzelner Performance-Test spiegelt niemals die Gesamtperformance des Systems wieder. Bei einem 3-Node Ceph Cluster führen wir z.B. den RADOS-Bench Write 6x bis 8x parallel aus, damit man das Netzwerk z.B. komplett auslasten kann im Ceph. Bitte beachten Sie dies bei der Ausführung dieser Kommandos. |
|---|
Ein Pool ist eine Gruppe von OSDs, die gemeinsam Daten speichern und verwalten. Für einen optimalen Pool ist es wichtig, die richtige Anzahl an PGs (Placement Groups) zu wählen. PGs sind kleine Gruppen innerhalb der OSDs, die für die Verteilung und Redundanz von Daten verantwortlich sind. Eine zu geringe Anzahl an PGs kann zu einer schlechten Verteilung der Daten führen, während eine zu hohe Anzahl an PGs zu einer unnötigen Belastung der Ressourcen führen kann.
Wichtig: um die tatsächlichen Performance in einem Ceph Cluster messen zu können, sollten Sie die nachfolgenden Befehle mehrfach und parallel ausführen. Hierzu eignet sich der Einsatz von tmux. Führen Sie das Kommando nur einzeln aus, so spiegelt das nicht die Gesamt-Performance des Systems wieder, da keine Parallelisierung von Zugriffen auf Ceph statt findet.
Exkurs PG-Autoscaler: Mittels des PG-Autoscalers kann die optimale Anzahl an PGs je Pool automatisch von Ceph errechnet werden - wenn gewünscht. Dies ist allerdings nur empfehlenswert, wenn Sie kein untypisches Daten-Wachstum oder eine Daten-Abnahme im System haben. Das heißt, dass Sie typischerweise nicht sehr viel Daten plötzlich generieren (mehrere 100GB) und oder wieder verlieren (= löschen). Wieso? Da sonst anhand des stetigen Datenwachstums aber auch der Daten-Abnahme der PG-Autoscaler ständig die optimale Anzahl an PGs erhöhen und oder verringern müsste. Dies ist nicht gut, da eine Erhöhung oder Reduktion der PGs auch immer eine Neu-Verteilung der Daten im Ceph bedeutet. Dies würde zu einem ständigem Daten-Rebalancing führen, was schlecht für die Cluster-Performance aber auch für die Datenträger an sich ist (TBW). Für das typische mittelständische Unternehmen mit normalem Datenzuwachs empfehlen wir aus Einfachheitsgründen den Einsatz des PG-Autoscalers.
Um die Leistung eines Ceph-Pools zu testen, kann das Tool rados bench verwendet werden. Mit rados bench können Schreibvorgänge auf dem Pool durchgeführt und die Ergebnisse in Bezug auf IOPS und Throughput ausgegeben werden.
rados bench -p vm_nvme 600 write -t 16 --object_size=4MB --no-cleanup
| Parameter | Erklärung |
|---|---|
| -p vm_nvme | gibt den Namen des Pools an, auf dem der Test durchgeführt wird |
| 600 | legt die Dauer des Tests in Sekunden fest (600 Sekunden entspricht 10 Minuten) |
| write | gibt an, dass der Test ein Schreiboperationen durchführt |
| -t 16 | legt die Anzahl der parallelen Threads fest, die verwendet werden sollen |
| --object_size=4MB | legt die Blocksize fest |
| --no-cleanup | legt fest, dass die erstellten Testdaten nach dem Test nicht gelöscht werden (da wir von diesen lesen werden, brauchen wir diese noch) |
Die Ergebnisse werden in Bytes pro Sekunde ausgegeben und der Test wird mit 16 parallelen Threads durchgeführt.
Total time run: 600.017 Total writes made: 383501 Write size: 4194304 Object size: 4194304 Bandwidth (MB/sec): 2556.6 Stddev Bandwidth: 1098.42 Max bandwidth (MB/sec): 4620 Min bandwidth (MB/sec): 1540 Average IOPS: 639 Stddev IOPS: 274.605 Max IOPS: 1155 Min IOPS: 385 Average Latency(s): 0.0250308 Stddev Latency(s): 0.0178465 Max latency(s): 0.15803 Min latency(s): 0.00460356
Ebenso können Lesevorgänge auf dem Pool durchgeführt werden, um die Leseleistung des Pools zu testen. Der folgende Befehl kann verwendet werden, um den Lesedurchsatz eines Ceph-Pools mit einer Blocksize von 4MB zu testen:
rados bench -p vm_nvme 60 read -t 16 --object_size=4MB
| Parameter | Funktion |
|---|---|
| -p vm_nvme | gibt den Namen des Pools an, auf dem der Test durchgeführt wird. |
| 60 | legt die Dauer des Tests in Sekunden fest (60 Sekunden entspricht 1 Minute). |
| seq | gibt an, dass der Test mit sequentielle Lesevorgänge durchführt wird. |
| -t 16 | legt die Anzahl der parallelen Threads fest, die verwendet werden sollen. |
Dieser Befehl führt einen Lesedurchsatz-Test auf dem Pool vm_nvme durch, bei dem sequentielle Lesevorgänge durchgeführt werden. Der Test wird für eine Dauer von 60 Sekunden durchgeführt und die Ergebnisse werden in Bytes pro Sekunde ausgegeben. Der Test wird mit 16 parallelen Threads durchgeführt.
Total time run: 60.0276 Total reads made: 53525 Read size: 4194304 Object size: 4194304 Bandwidth (MB/sec): 3566.69 Average IOPS: 891 Stddev IOPS: 20.0448 Max IOPS: 935 Min IOPS: 842 Average Latency(s): 0.0176248 Max latency(s): 0.0879089 Min latency(s): 0.00350174
tbd
tbd
Um einzelne OSD-Datenträger unter Ceph zu messen, kann der Befehl ceph osd perf verwendet werden. Dieser Befehl gibt detaillierte Leistungsdaten für jeden OSD im Cluster zurück. Der Befehl zeigt tatsächlich die ID des OSD und die Commit- und Apply-Latenz an.
Commit-Latenz ist die Zeit, die ein OSD benötigt, um das Journal auf den Datenträger zu schreiben.Apply-Latenz ist die Zeit, die ein OSD benötigt, um eine Schreiboperation auf seine lokale Festplatte zu übertragen. Es ist also die Zeit, die vergeht, bis eine Schreiboperation endgültig auf dem OSD gespeichert wurde.Eine hohe Commit- oder Apply-Latenz kann darauf hindeuten, dass der OSD ausgelastet ist und nicht schnell genug schreiben kann, was die Leistung des gesamten Ceph-Clusters beeinträchtigen kann. Eine niedrige Commit- und Apply-Latenz hingegen deutet darauf hin, dass der OSD korrekt funktioniert und der darunterliegende Datenträger keine Problem aufweist.
Zusammenfassend beeinflussen folgende Faktoren die Ceph Performance:
Netzwerk-Verbindung für das Ceph-Netzwerk (Low Latency, High Bandwidth)Datenträger (Flash, Low Latency, NVMe)RAM und CPUPool-Konfiguration (Anzahl der PGs, Replikationsfaktor)Eine sorgfältige Überwachung und Messung dieser Faktoren kann dazu beitragen, die Leistung des Ceph-Systems zu optimieren. Hier empfehlen wir zum Beispiel den Einsatz von checkMK.
 |
Autor: Jonas Sterr Ich beschäftige mich mit den Themen Software Defined Storage, Proxmox Virtualisierung auf Basis von KVM, QEMU & Ceph im Produktmanagement der Thomas-Krenn.AG in Freyung. Proxmox ist meine absolute Leidenschaft und ich freue mich gerne über Kontaktanfragen und einen Austausch auf LinkedIn.
|
