[SOLVED] Ceph Cluster, hohes IO Wait auf einem Server

Ingo S

Renowned Member
Oct 16, 2016
333
38
68
41
Hallo zusammen

Unser Ceph verteilt sich auf 4 Server und davon ist ein Server sehr auffällig was IO-Wait angeht. Allein das "Grundrauschen" von Lesen und Schreiben von einigen MB/s durch die VMs, sorgt für ein IO Wait von zwischen 7-12%
Die anderen Server zeigen kein nennenswertes IO Wait ( <1%)

Hier mal ein Beispiel:
upload_2019-5-20_9-34-47.png
Auf den anderen Servern sieht das anders aus:
upload_2019-5-20_9-36-56.png

VM-1 ist ein etwas älterer Server als VM-2, aber auch nur ein paar Jahre, nicht steinalt, die Platten hängen an einem Serial Attached SCSI controller: LSI SAS3408.
Bei VM-2 hängen die Platten an einem LSI MegaRAID SAS 2208

Festplatten sind 4 Server a 8 HDDs.
Die Platten selbst sind 4TB HDDs, SAS und SATA gemischt, was wir grad so da hatten, alle mit 7200rpm. Ceph Journal liegt auf einer Intel Enterprise NVME SSD.

Ich bin offen für Ideen, rauszufinden was da los ist.
 
Als erstes vorweg, je gemischter die Hardware im Cluster desto unvorhersehbarer die Performance [1]. Was für Werte ergibt ein 'rados bench'? Den Befehl kann man in unserem Ceph Benchmark Paper finden [2].

Alleine die CPU der beiden im Bild zu sehenden Nodes macht schon einen Unterschied. Die IO-wait ist in Prozent angegeben und ist die Wartezeit der CPU bis die IO-Anfrage eines Prozesses fertig ist. Im Programm Top sieht man eine kumulierte Gesamtansicht aller Kerne (inkl. Threads). Also im obigen Fall 12 und 48, damit ist also die IO-wait zwischen Systemen nicht vergleichbar.

Was mir in dem Fall mehr sorgen machen würde, als die IO-wait, ist das fehlende ECC beim i7. Damit kann nicht sichergestellt werden, ob auch die richtigen Bits auf der Platte landen oder nicht. Das erhöht die Wahrscheinlichkeit, dass es öfter Fehlern beim Scrubbing auftauchen und defekte Objekte im Cluster verteilt werden.

VM-1 ist ein etwas älterer Server als VM-2, aber auch nur ein paar Jahre, nicht steinalt, die Platten hängen an einem Serial Attached SCSI controller: LSI SAS3408.
Bei VM-2 hängen die Platten an einem LSI MegaRAID SAS 2208
Ich hoffe diese sind im IT-Mode (HBA). RAID Controller sind nicht für den Einsatz von Ceph oder ZFS gemacht und verursachen leider alle möglichen Nebeneffekte [1]. Besser ist die Controller durch reine HBAs ersetzen.

Die Platten selbst sind 4TB HDDs, SAS und SATA gemischt, was wir grad so da hatten, alle mit 7200rpm.
Je nach Platte kann die tatsächliche Geschwindigkeit (IO/s) variieren und unnötige IO-delays erzeugen [1]. Falls die Platten im RAID sind, dann wird der Controller den Umstand vermutlich maskieren.

[1] https://pve.proxmox.com/pve-docs/chapter-pveceph.html#_precondition
[2] https://forum.proxmox.com/threads/proxmox-ve-ceph-benchmark-2018-02.41761/
 
Als erstes vorweg, je gemischter die Hardware im Cluster desto unvorhersehbarer die Performance [1]. Was für Werte ergibt ein 'rados bench'? Den Befehl kann man in unserem Ceph Benchmark Paper finden [2].

Ich hab gerade ein rados bench gemacht, wie in dem Paper:
Total time run: 60.135760
Total writes made: 6669
Write size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 443.596
Stddev Bandwidth: 63.777
Max bandwidth (MB/sec): 572
Min bandwidth (MB/sec): 236
Average IOPS: 110
Stddev IOPS: 15
Max IOPS: 143
Min IOPS: 59
Average Latency(s): 0.144241
Stddev Latency(s): 0.149601
Max latency(s): 1.70906
Min latency(s): 0.0140576

Mit nur einem Thread sieht das dann so aus:
Total time run: 60.078266
Total writes made: 882
Write size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 58.7234
Stddev Bandwidth: 13.928
Max bandwidth (MB/sec): 84
Min bandwidth (MB/sec): 32
Average IOPS: 14
Stddev IOPS: 3
Max IOPS: 21
Min IOPS: 8
Average Latency(s): 0.0681127
Stddev Latency(s): 0.0641894
Max latency(s): 0.52501
Min latency(s): 0.014323

Ach was ich noch vergessen habe: Das Ceph Netz ist 10Gbit

Alleine die CPU der beiden im Bild zu sehenden Nodes macht schon einen Unterschied. Die IO-wait ist in Prozent angegeben und ist die Wartezeit der CPU bis die IO-Anfrage eines Prozesses fertig ist. Im Programm Top sieht man eine kumulierte Gesamtansicht aller Kerne (inkl. Threads). Also im obigen Fall 12 und 48, damit ist also die IO-wait zwischen Systemen nicht vergleichbar.
Das verstehe ich. Wir haben allerdings noch einen weiteren Server im Cluster der nur 8 Kerne hat. Bei diesem ist die IO Wait zwar auch leicht höher als bei den 48 Kernern, aber bei weitem nicht so sehr.

Was mir in dem Fall mehr sorgen machen würde, als die IO-wait, ist das fehlende ECC beim i7. Damit kann nicht sichergestellt werden, ob auch die richtigen Bits auf der Platte landen oder nicht. Das erhöht die Wahrscheinlichkeit, dass es öfter Fehlern beim Scrubbing auftauchen und defekte Objekte im Cluster verteilt werden.
Das wäre nicht gut. Ich habe tatsächlich schon den ein oder anderen Scrub Error gesehen. Allerdings hab ich die eher auf eine defekte Platte geschoben, da smartctl auf einer der Platten "pending sector" meldet. Die werde ich kurzfristig tauschen.
Ich werde aber trotzdem mal sehen ob wir den Server irgendwie los werden können.

Ich hoffe diese sind im IT-Mode (HBA). RAID Controller sind nicht für den Einsatz von Ceph oder ZFS gemacht und verursachen leider alle möglichen Nebeneffekte [1]. Besser ist die Controller durch reine HBAs ersetzen.

Je nach Platte kann die tatsächliche Geschwindigkeit (IO/s) variieren und unnötige IO-delays erzeugen [1]. Falls die Platten im RAID sind, dann wird der Controller den Umstand vermutlich maskieren.
Ja, also die Platten in VM-1 werden durch einen reinen HBA angesteuert, in den anderen Servern waren die Raid Controller schon so drin. Bei der Anschaffung der Server war Ceph noch kein Thema.
Jedenfalls befinden sich die Platten auf keinem der Server in einem Raid Verbund
Controller = 0
Status = Success
Description = None
[...]
Product Name = HBA 9400-8i
Board Name = HBA 9400-8i
[...]
Physical Drives = 8

PD LIST :
=======

-----------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp
-----------------------------------------------------------------------------
0:0 3 JBOD - 3.638 TB SAS HDD N N 512B HUS724040ALS640 U
0:1 2 JBOD - 3.638 TB SATA HDD N N 512B WDC WD4002FYYZ-01B7CB0 U
0:2 7 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
0:3 5 JBOD - 3.638 TB SAS HDD N N 512B HUS724040ALS640 U
0:4 1 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
0:5 4 JBOD - 3.638 TB SAS HDD N N 512B HUS724040ALS640 U
0:6 6 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
0:7 8 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
-----------------------------------------------------------------------------
Controller = 0
Status = Success
Description = None

Product Name = LSI MegaRAID SAS 9271-8i
[...]
Host Interface = PCI-E
Device Interface = SAS-6G
Drive Groups = 8
Virtual Drives = 8

VD LIST :
=======

-------------------------------------------------------------
DG/VD TYPE State Access Consist Cache Cac sCC Size Name
-------------------------------------------------------------
0/0 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
1/1 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
2/2 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
3/3 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
4/4 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
5/5 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
6/6 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
7/7 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
-------------------------------------------------------------

Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|Dgrd=Degraded
Optl=Optimal|RO=Read Only|RW=Read Write|HD=Hidden|TRANS=TransportReady|B=Blocked|
Consist=Consistent|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
Check Consistency

Physical Drives = 8

PD LIST :
=======

--------------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
--------------------------------------------------------------------------------
252:0 11 Onln 0 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:1 10 Onln 1 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:2 9 Onln 2 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:3 8 Onln 3 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:4 14 Onln 4 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:5 13 Onln 5 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:6 15 Onln 6 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
252:7 12 Onln 7 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
--------------------------------------------------------------------------------
EDIT: Da ist mir der Senden Button ausgerutscht:
Ich habe schon versucht raus zu finden was es mit diesen Modes auf sich hat und scheinbar kann man den Mode des Controllers auch irgendwie wechseln. Konkrete Informationen dazu habe ich allerdings bisher nicht finden können.
Der RAID0 Modus der Festplatten ist jedenfalls der Modus in dem die Festplatten als Single Drive funktionieren. Früher gab es mal die Option "Single", aber bei diesen Controllern soll man den RAID0 für Single Drives nehmen.
 
Last edited:
Das verstehe ich. Wir haben allerdings noch einen weiteren Server im Cluster der nur 8 Kerne hat. Bei diesem ist die IO Wait zwar auch leicht höher als bei den 48 Kernern, aber bei weitem nicht so sehr.
Das kommt auf die Menge der Arbeit an, die eine CPU abarbeitet.

Das wäre nicht gut. Ich habe tatsächlich schon den ein oder anderen Scrub Error gesehen. Allerdings hab ich die eher auf eine defekte Platte geschoben, da smartctl auf einer der Platten "pending sector" meldet. Die werde ich kurzfristig tauschen.
Ich werde aber trotzdem mal sehen ob wir den Server irgendwie los werden können.
Kann natürlich auch von defekten Festplatten stammen, aber die Gefahr bleibt. Meist weiß man dann auch nicht ob Daten korrumpiert sind.

Jedenfalls befinden sich die Platten auf keinem der Server in einem Raid Verbund
Ein RAID0/JBOD ist auch nicht das wahre, spreche aus eigener Erfahrung. Da sich meist Caches und andere RAID-Optimierungen nicht ausschalten lassen, kann es zu unschönen Nebeneffekten kommen, wie zB. 'stuck/slow requests'.

Ich habe schon versucht raus zu finden was es mit diesen Modes auf sich hat und scheinbar kann man den Mode des Controllers auch irgendwie wechseln. Konkrete Informationen dazu habe ich allerdings bisher nicht finden können.
Meist geht das mit einem Firmware Update einher. Aber oft schon von der Konstruktionsweise eines RAID Kontrollers, ist dieser nicht mit einem HBA vergleichbar. Besser gleich einen HBA besorgen, dann sind einige Kopfschmerzen von vornherein umgangen.

Der RAID0 Modus der Festplatten ist jedenfalls der Modus in dem die Festplatten als Single Drive funktionieren. Früher gab es mal die Option "Single", aber bei diesen Controllern soll man den RAID0 für Single Drives nehmen.
Siehe oben und noch einmal der Link für eine detailliertere Hardwarevoraussetzung.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html#_precondition
 
Vielen Dank schonmal für die Hinweise.
Den VM-1 werden wir dann wohl mittelfristig austauschen.

Aber um das nochmal etwas klarer zusammen zu fassen:
Der problematische Server mit hohem IO Wait ist VM-1.
Auf diesem Server sind die Festplatten via Broadcom HBA 9400-8i angeschlossen. Das ist laut Broadcom ein HBA, kein RAID Controller. Auf den anderen Maschinen z.B. VM-2, wo kein hohes IO Wait zu beobachten ist, sind LSI MegaRaid SAS 9271-8i Controller verbaut.

Das verstehe ich. Wir haben allerdings noch einen weiteren Server im Cluster der nur 8 Kerne hat. Bei diesem ist die IO Wait zwar auch leicht höher als bei den 48 Kernern, aber bei weitem nicht so sehr.
Das kommt auf die Menge der Arbeit an, die eine CPU abarbeitet.
Sowohl auf VM-1, als auch auf dem anderen Server mit den 8 Kernen, läuft keine VM, weil die RAM Ausstattung dort nicht so gut ist. Die beiden machen quasi nur Storage für Ceph.

Bezogen auf die Precondition für Ceph aus den Docs:
Code:
DB/WAL auf SSD                                   -> Check
Balance OSD count / WAL DB Device                -> Check
gleichmäßige Verteilung von HDDs auf die Server  -> Check
gleiche HDD Größe                                -> Check
Für VM-1 gilt ja auch sogar "kein RAID -> Check"

Die Gesamtperformance ist ja soweit okay, also wenn ich genug Threads aufmache, dann erreiche ich die vollen 10GBits der Netzwerkanbindung und für den gesamten Cluster reicht die Performance auch aus, weil die Performance ja mit der Anzahl der parallelen Zugriffe skaliert.

Der rados bench zeigt aber eine meiner Meinung nach eher mittelmäßige bis schlechte Performance bei Single Thread Zugriffen. Es ist schon merkwürdig, 32 recht aktuelle flotte Festplatten anzusteuern und dann kommen z.B. beim Datei kopieren Datenraten von 50-70MB/s oder teilweise nur 20MB/s zustande und die IO Wait Time auf VM-1 steigt irre in die Höhe ohne das dieser viel tut.

Bevor ich aber nun Geld in die Hand nehme, einen neuen Server kaufe, oder neue HBAs bestelle, um die Performance bei einzelnen Schreibvorgängen wie Dateien kopieren, Backups erstellen oder rum schieben etc. zu verbessern, versuche ich irgendwie herauszufinden welche der Möglichkeiten der Bottleneck ist.

Mit gehen dabei folgende Dinge durch den Kopf:

- CPU und RAM auf VM-1 ist einfach Mist, insbesondere die CPU hat einfach nicht genug Power. Deshalb entsteht auch bei kleinen Lastspitzen sofort hohes IO Wait.
Das passt allerdings nicht mit meinem Verständnis von IO Wait überein. Das ist ja lediglich die Wartezeit des CPU bis der Speicher die Anfrage beantwortet hat. Wenn die CPU sonst keine Aufgaben hat ergibt das für mich aber irgendwie wenig Sinn wie das mit der Anzahl der Kerne und der Taktrate zusammen hängen sollte. 10% IO Wait bedeutet ja lediglich das die CPU pro Sekunde etwa 100ms auf IO wartet.

- Die RAID Controller maskieren das IO Wait auf den beiden dicken Servern und die Performance leidet in Wirklichkeit gar nicht unter dem "hohen" IO Wait auf VM-1 sondern darunter, dass die RAID Controller auf den beiden dicken Servern irgendwas wildes machen.

Ich habe mit rados bench ein paar Versuche gemacht und folgendes zeichnet sich ab:

kleine Blocksize (4k) & wenig Threads (1) -> sehr geringe Performance (um 1MB/s), kaum erhöhtes IO Wait auf VM-1
große Blocksize (16M) & wenig Threads (1) -> eher geringe Performance (um 100MB/s), leicht erhöhtes IO Wait auf VM-1
kleine Blocksize (4k) & viele Threads (128) -> sehr geringe Performance (12MB/s), stark erhöhtes IO Wait auf VM-1 (35-40%)
große Blocksize (16M) & viele Threads (128) -> mittelmäßige Performance (300-450MB/s), leicht erhöhtes IO Wait auf VM-1

In allen Fällen war IO Wait auf den großen Servern VM-2 und 3 fast unverändert. man sieht nur einen leichten Buckel
upload_2019-5-20_15-35-37.png
upload_2019-5-20_15-36-12.png
 
Für VM-1 gilt ja auch sogar "kein RAID -> Check"
Das betrifft aber alle an Ceph beteiligten Nodes. ;)

Der rados bench zeigt aber eine meiner Meinung nach eher mittelmäßige bis schlechte Performance bei Single Thread Zugriffen. Es ist schon merkwürdig, 32 recht aktuelle flotte Festplatten anzusteuern und dann kommen z.B. beim Datei kopieren Datenraten von 50-70MB/s oder teilweise nur 20MB/s zustande und die IO Wait Time auf VM-1 steigt irre in die Höhe ohne das dieser viel tut.
Der 'rados bench' macht im Hintergrund auch nix anders, als ein fio und bei einem thread, kann auch nur immer eine OSD (primary) angesprochen werden. Diese wiederum schreibt die Daten erst auf die sekundäre und tertiäre OSD, bevor das ACK an den Client zurück kommt. Darum sind's beim 'rados bench' auch 16 threads standard, das ein besseres Bild liefert, zwecks Parallelität.

- CPU und RAM auf VM-1 ist einfach Mist, insbesondere die CPU hat einfach nicht genug Power. Deshalb entsteht auch bei kleinen Lastspitzen sofort hohes IO Wait.
Das passt allerdings nicht mit meinem Verständnis von IO Wait überein. Das ist ja lediglich die Wartezeit des CPU bis der Speicher die Anfrage beantwortet hat. Wenn die CPU sonst keine Aufgaben hat ergibt das für mich aber irgendwie wenig Sinn wie das mit der Anzahl der Kerne und der Taktrate zusammen hängen sollte. 10% IO Wait bedeutet ja lediglich das die CPU pro Sekunde etwa 100ms auf IO wartet.
Die IO-wait wird von der Summe der Tasks auf den Cores berechnet. Ist die CPU nur 10% Ausgelastet, dann wird die IO-wait von dem 10% gerechnet. Damit ensteht das Bild, das die CPU nix tut, aber ewig auf IO gewartet werden muss. Es gilt dabei jegliche IO, meist fällt es jedoch auf, wenn die IO auf die Platten geht.

- Die RAID Controller maskieren das IO Wait auf den beiden dicken Servern und die Performance leidet in Wirklichkeit gar nicht unter dem "hohen" IO Wait auf VM-1 sondern darunter, dass die RAID Controller auf den beiden dicken Servern irgendwas wildes machen.
Genau. Da der VM-1 einen HBA hat, kommt (oder geht) jede IO auch direkt von den Platten. Bei den RAID-Controllern wird die IO schon dort terminiert und dann ist es dem Controller überlassen, was er mit den Daten macht. Das System bekommt davon auch nichts mit.

Auch wenn die Performance mit den Controllern besser ist, oft sieht man erst im Ernstfall, ob alles da ist. Und meist ist auch mehr Arbeit nötig, da noch ein RAID0/JBOD konfiguriert werden muss, zudem oben drauf noch die OSD kommt.

kleine Blocksize (4k) & wenig Threads (1) -> sehr geringe Performance (um 1MB/s), kaum erhöhtes IO Wait auf VM-1
große Blocksize (16M) & wenig Threads (1) -> eher geringe Performance (um 100MB/s), leicht erhöhtes IO Wait auf VM-1
kleine Blocksize (4k) & viele Threads (128) -> sehr geringe Performance (12MB/s), stark erhöhtes IO Wait auf VM-1 (35-40%)
große Blocksize (16M) & viele Threads (128) -> mittelmäßige Performance (300-450MB/s), leicht erhöhtes IO Wait auf VM-1
Je kleiner die Blockzise, desto mehr Pakete müssen über das Netzwerk geschrieben/gelesen werden. Daher arbeitet RBD mit 4 MiB Objekten, da es sich bei VM/CT als ein guter Kompromiss durchgesetzt hat. Aber bei der Objektgröße kommt es auf den Anwendungsfall darauf an, große Daten, wie Videos haben sicherlich einen Vorteil mit größeren Objekten.
 
Ah okay, das hat jetzt vieles klarer gemacht. Vielen Dank
Die Performance unseres Ceph ist also im groben im normalen Bereich, wenn ich das richtig deute.

Zwei Dinge noch:
Auf den RAID Controllern ist Caching aktiviert. Wenn ich das jetzt richtig interpretiere, müsste das tatsächliche IO Wait zutage treten, wenn ich dem Controller sage, er soll direct IO machen.

Und: Ich habe ja als Cache/WAL/DB eine NVME SSD. Die nimmt doch bei den Writes als erstes die Daten auf, bevor die nach einer Zeit oder einer Menge X dann auf die Festplatte geschrieben werden. Kommt das ACK also nicht, wenn die Daten sicher auf der SSD liegen sondern tatsächlich erst, wenn die HDD die Daten von dort sicher übernommen hat?
Entweder habe ich da einen Denkfehler, oder dieses Verhalten macht die SSD als Cache irgendwie etwas überflüssig. Dann könnte ich doch gleich die Daten direkt auf die HDD schreiben und nur die Metadaten auf ne kleine SSD laufen lassen.
 
Die nimmt doch bei den Writes als erstes die Daten auf, bevor die nach einer Zeit oder einer Menge X dann auf die Festplatte geschrieben werden. Kommt das ACK also nicht, wenn die Daten sicher auf der SSD liegen sondern tatsächlich erst, wenn die HDD die Daten von dort sicher übernommen hat?
Wie kommst du darauf? Der muss in dem Falle vom Cache Device kommen, dafür ist das ja da und ja, dann würde das Device ja auch keinen Sinn mehr machen - dann würdest du schneller direkt auf die Platte schreiben.

It is only useful to use a WAL device if the device is faster than the primary device (e.g., when it is on an SSD and the primary device is an HDD).
Again, it is only helpful to provision a DB device if it is faster than the primary device.
http://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/

Aktuell sind die SSD Preise aber so dermaßen im Keller, dass es sich vielleicht lohnt auf Flash Only umzusteigen? Dann nimmst du deinem Cluster ein bisschen komplexität und mehrere SPOFs raus, zusätzlich gibt es mehr Performance. Das geht natürlich nur, wenn du nicht so den Speicherplatz benötigst.

Was ich mit SPOF meine?
Du hast ein Drive als Cache für all deine Spinner pro Server, fällt das Caching Device aus ist dein Node komplett raus. Sehr kritisch wird das übrigens, wenn du alle Nodes mehr oder minder zeitgleich mit dem Caching Device ausgestattet hast. Die Wahrscheinlichkeit, dass alle Caching Devices zeitgleich oder in kurzen Abständen sterben ist da sehr hoch. Fällt die erste aus und es kommt Action ins Cluster, könnte das auch das Todesurteil für eine weitere sein. Habe ich auch bereits im produktiven Betrieb miterleben dürfen...
 
Wie kommst du darauf? Der muss in dem Falle vom Cache Device kommen, dafür ist das ja da und ja, dann würde das Device ja auch keinen Sinn mehr machen - dann würdest du schneller direkt auf die Platte schreiben.
Also, wenn ich einen Single Thread Schreibvorgang starte und das WAL Device diesen zuerst cached, dann müsste ich im Benchmark zu Beginn des Tests die Schreibgeschwindigkeit des WAL sehen wenn der Schreibvorgang schon auf dem WAL terminiert wird. Das ist bei uns eine Intel Optane P4800X PCIe pro Server. Da ich aber direkt von Beginn des Benchmarks an lediglich Geschwindigkeiten sehe, die etwa der einer HDD entsprechen, habe ich mich gefragt warum das so ist. Im schlimmsten Fall haben wir hier noch einen Konfigurationsfehler und ich denke nur, das das WAL auf der SSD liegt...o_O:eek:

Aktuell sind die SSD Preise aber so dermaßen im Keller, dass es sich vielleicht lohnt auf Flash Only umzusteigen? Dann nimmst du deinem Cluster ein bisschen komplexität und mehrere SPOFs raus, zusätzlich gibt es mehr Performance. Das geht natürlich nur, wenn du nicht so den Speicherplatz benötigst.
Ich hatte auch schon darüber nachgedacht, aber wir haben zur Zeit ca 106TB, 32x 4TB im Einsatz und da auf SSDs umzusteigen sprengt echt unser IT Budget.
Evtl könnte ich defekte HDDs nach und nach mit SSDs ersetzen.

Was ich mit SPOF meine?
Du hast ein Drive als Cache für all deine Spinner pro Server, fällt das Caching Device aus ist dein Node komplett raus. Sehr kritisch wird das übrigens, wenn du alle Nodes mehr oder minder zeitgleich mit dem Caching Device ausgestattet hast. Die Wahrscheinlichkeit, dass alle Caching Devices zeitgleich oder in kurzen Abständen sterben ist da sehr hoch. Fällt die erste aus und es kommt Action ins Cluster, könnte das auch das Todesurteil für eine weitere sein. Habe ich auch bereits im produktiven Betrieb miterleben dürfen...
Ja, das ist mir leider bewusst. Ich weiß allerdings keine gute Lösung die bei uns im Moment finanztechnisch tragbar ist.
Wir sichern allerdings täglich auf Band und auf anderen Medien und könnten im Katastrophenfall sämtliche Maschinen wiederherstellen. Außerdem haben wir ein Desaster-System auf dem wir die wichtigsten Maschinen in Betrieb nehmen können, für den Fall das der Cluster nicht mehr OK ist.
 
Also, wenn ich einen Single Thread Schreibvorgang starte und das WAL Device diesen zuerst cached, dann müsste ich im Benchmark zu Beginn des Tests die Schreibgeschwindigkeit des WAL sehen wenn der Schreibvorgang schon auf dem WAL terminiert wird. Das ist bei uns eine Intel Optane P4800X PCIe pro Server. Da ich aber direkt von Beginn des Benchmarks an lediglich Geschwindigkeiten sehe, die etwa der einer HDD entsprechen, habe ich mich gefragt warum das so ist. Im schlimmsten Fall haben wir hier noch einen Konfigurationsfehler und ich denke nur, das das WAL auf der SSD liegt...o_O:eek:
Das WAL und die DB haben für den Datenteil des Objektes keine direkte Cache-Funktion. Große Schreibvorgänge, zB. 4 MiB, werden direkt auf die HDD geschrieben. Das WAL (write-ahead-log) kann zwar kleinere Schreibvorgänge (bluestore_prefer_deferred_size_hdd) aufnehmen, per default ist das 32 KiB, ist aber nicht direkt ein cache. Hier kann natürlich getuned werden, a die P4800 schon einiges an IO ab kann. Wichtig ist aber das die Partition für die DB gross genug ist, sollte sie zu klein sein, wird der Überlauf wieder auf die HDD geschrieben.

Ich hatte auch schon darüber nachgedacht, aber wir haben zur Zeit ca 106TB, 32x 4TB im Einsatz und da auf SSDs umzusteigen sprengt echt unser IT Budget.
Evtl könnte ich defekte HDDs nach und nach mit SSDs ersetzen.
Es könnte auch sinn machen, mit unterschiedlichen Pools zu fahren, einen für die Daten und einen für IO-Performance. Ceph hat dazu die 'Device class' eingeführt, damit das Handling der OSDs einfacher wird.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_device_classes
 
Ah okay, so ergibt das mehr Sinn.

Also anscheinend verhält sich unser Ceph so wie er gerade ist, ganz normal. Gut, das ist zumindest etwas beruhigend.
Ich werde dann für die Zukunft einen Plan erstellen müssen, wie wir unseren Cluster so erweitern/umbauen, dass das alles etwas mehr flutscht.
Das lässt sich wahrscheinlich wirklich am ehesten über einen "fast pool" aus SSDs realisieren.

Mit 4 Ceph Nodes befinden wir uns ja auch ziemlich am unteren Rand der Skala, wo Ceph Sinnvoll ist.

Thx für die Meinungen und Einsichten.
 
Das lässt sich wahrscheinlich wirklich am ehesten über einen "fast pool" aus SSDs realisieren.
Bitte dann mit einem HBA aufbauen.

Mit 4 Ceph Nodes befinden wir uns ja auch ziemlich am unteren Rand der Skala, wo Ceph Sinnvoll ist.
Den Sinn hats ja bereits (ab 3), shared storage. ;)
 
Bitte dann mit einem HBA aufbauen.
Das sehe ich auch so. Habe bereits angedeutet das wir am Cluster in Zukunft noch etwas umbauen müssen.

Den Sinn hats ja bereits (ab 3), shared storage. ;)
Im Grunde ja, aber bedenkt man die niedrigen Datenraten die man bei Single Threaded Writes mit Ceph erreicht, ist man bei kleinen Systemen manchmal mit einem guten NAS und nem RAID6 oder RAID10 besser bedient, das man dann per NFS o.ä. anspricht.
Man verliert zwar etwas Ausfallsicherheit und Flexibilität, gewinnt aber sehr viel Performance.
Je größer der Cluster wird, desto besser skaliert Ceph und spielt dann seine Stärken aus.
 
  • Like
Reactions: Alwin

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!