CEPH Storage :: Schlechte Schreibperformance / hohe Latenz || Ceph Storage - Bad Writeperformance / throughput.

[proxmrmomba]

Hallo liebes Forum,

ich habe Probleme mit meinem CEPH. Ganz genau lokaliesieren kann ich das Problem leider nicht. Am Anfang habe ich es auch gerne Verdrängt, bzw. ist mir im Testing nicht aufgefallen.
Ganz verschweigen will ich nicht, dass ich nicht die Ideale Anforderung an CEPH fahre bzw. Umgesetzt habe. Gründe später.
Seit dem im Ceph aber ein PostgreSQL-Server läuft werden die Ausmaße leider sichtbar und sorgt für sehr viel Unmut im Unternehmen.
Es gibt eine handvoll Themen zu CEPH und Latenzproblemen hier, oftmals leider auch der Hinweis zu - Mehr Hardware bessere Hardware. Ich denke unsere Hardware ist gut.

Erstmal ein paar Fakten:
CPU und RAM:
2x HPe G10 380 mit 1024GB RAM 24 Kerne Gold 6146 CPU @ 3.20GHz
1x HPe G10 380 mit 512GB RAM 32 Kerne Gold 6142M CPU @ 2.60GHz (Die CPUs werden noch zu den oberen CPUs ersetzt)

HDDs:
LEIDER nur Platz für 6x Speicher in 2,5" , dabei aber ein Volumen von 29GB + Reserve + Ausfallsicherheit
Daher ist die Entscheidung (Budget gezwungen) auf Samsung QVO 8TB gegangen - im Raid 5. 5x8TB + 1x Ausfallsicherheit
Ja Raidcontroller sollen mit Ceph eigentlich nicht genutzt werden ::
Warum ist es doch passiert? Es soll die Einschränkungen die SATA mit sich bringen minimieren durch verteiltes Lesen / Schreiben.
die letzten 2 Slots werden das Betriebssystem im Raid 1 genutzt.
Ich bin nicht nur 'kein Fan' von der SD-Kartengeschichte bei HP, sondern auch absoluter SD-Kartenhasser bei HP Umsetzungen. Seit HP nach dem G7 Modell die Idee hatte die Slots auf dem Board zu packen - teilweise unter den Risers, statt wie vorher Komfortable in der oberen Querstrebe zu montieren.
Netzwerk:
jeder Server ist mit 4x10GBe angebunden, es werden jedoch BONDS genutzt.

Ich versuche es mal etwas aufzumalen:
Bond10: 2x10GBe LACP -> Switch 1
Bond20: 2x10GBe LACP -> Switch 2
Bond 0: Active (Bond 10) Passic (Bond 20)
vmbr0 -> Bond0
vmbr102->vlan102->Bond0
SDN-Configs -> vmbr0

die vmbr102-vlan102 Konstellation ist leider dadurch entstanden, dass unser Testsytem noch ein Proxmox 7 war, und das Feature mit SDN erst später dazu kam.
die vmbr102 wird von Proxmox und Ceph genutzt (bzw. der IPKreis)


HDD Benchmarks
Wie soll ich weiter machen?
Ich habe direkt nach dem erstellen:
Nicht aussagekräftig, aber ein Anhaltspunkt - Raid 5 Test unter nativ Windows Server



identischer Test jetzt: Windows Server VM unter Proxmox -> Ceph


-----------------------------------------------------------------
RADOS-Benchmarks:
[FONT=Calibri]BENCHMARK unserer Umgebung rados bench -p CephPool01 20 write -b 10M -t 16 --run-name hv03 --no-cleanup hints = 1 Maintaining 16 concurrent writes of 10485760 bytes to objects of size 10485760 for up to 20 seconds or 0 objects Object prefix: benchmark_data_hv03_147706 sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s) 0 0 0 0 0 0 - 0 1 15 64 49 489.896 490 0.251826 0.266099 2 15 127 112 559.902 630 0.209806 0.259421 3 15 191 176 586.564 640 0.27616 0.253519 4 15 256 241 602.398 650 0.207485 0.252887 5 15 324 309 617.896 680 0.212533 0.251062 6 15 388 373 621.561 640 0.173464 0.249113 7 15 454 439 627.038 660 0.253977 0.24817 8 15 518 503 628.646 640 0.247359 0.248207 9 15 588 573 636.563 700 0.187355 0.247283 10 15 644 629 628.901 560 0.320112 0.247802 11 15 712 697 633.538 680 0.218555 0.248545 12 15 773 758 631.571 610 0.293426 0.249482 13 15 835 820 630.675 620 0.239612 0.249836 14 15 897 882 629.904 620 0.252076 0.250535 15 15 967 952 634.569 700 0.207261 0.249189 16 15 1028 1013 633.027 610 0.187608 0.249963 17 15 1092 1077 633.433 640 0.255258 0.249917 18 15 1158 1143 634.902 660 0.183843 0.249557 19 15 1220 1205 634.112 620 0.302639 0.249549 2023-11-24T15:47:02.710657+0100 min lat: 0.157275 max lat: 0.502047 avg lat: 0.249024 sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s) 20 15 1287 1272 635.902 670 0.216858 0.249024 Total time run: 20.225 Total writes made: 1288 Write size: 10485760 Object size: 10485760 Bandwidth (MB/sec): 636.836 Stddev Bandwidth: 48.057 Max bandwidth (MB/sec): 700 Min bandwidth (MB/sec): 490 Average IOPS: 63 Stddev IOPS: 4.8057 Max IOPS: 70 Min IOPS: 49 Average Latency(s): 0.248776 Stddev Latency(s): 0.0396325 Max latency(s): 0.502047 Min latency(s): 0.111558 root@hv03:~# rados bench -p CephPool01 20 seq -t 16 --run-name hv03 hints = 1 sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s) 0 0 0 0 0 0 - 0 1 15 149 134 1339.64 1340 0.0781954 0.108113 2 15 273 258 1289.73 1240 0.167968 0.116796 3 15 407 392 1306.42 1340 0.105766 0.117492 4 15 541 526 1314.76 1340 0.0967754 0.117945 5 15 687 672 1343.77 1460 0.0698083 0.115759 6 15 822 807 1344.77 1350 0.16361 0.115954 7 15 964 949 1355.49 1420 0.142912 0.115441 8 15 1099 1084 1354.78 1350 0.0873367 0.115537 9 15 1240 1225 1360.89 1410 0.068914 0.115073 Total time run: 9.44074 Total reads made: 1288 Read size: 10485760 Object size: 10485760 Bandwidth (MB/sec): 1364.3 Average IOPS: 136 Stddev IOPS: 6.31357 Max IOPS: 146 Min IOPS: 124 Average Latency(s): 0.114962 Max latency(s): 0.246078 Min latency(s): 0.0386484 rados -p CephPool01 cleanup benchmark_data[/FONT]

Benchmark Netzwerk

Container1 / HV02 ---> HV03 / Container2

Server listening on TCP port 5001
TCP window size: 128 KByte (default)
------------------------------------------------------------
[ 1] local 10.1.2.120 port 5001 connected with 10.1.2.121 port 59698
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-10.0028 sec 10.8 GBytes 9.31 Gbits/sec
[ 2] local 10.1.2.120 port 5001 connected with 10.1.2.121 port 52196 (full-duplex)
[ ID] Interval Transfer Bandwidth
[ *2] 0.0000-10.0001 sec 10.6 GBytes 9.12 Gbits/sec
[ 2] 0.0000-10.0043 sec 7.04 GBytes 6.05 Gbits/sec
[SUM] 0.0000-10.0035 sec 17.7 GBytes 15.2 Gbits/sec
[ 3] local 10.1.2.120 port 5001 connected with 10.1.2.121 port 60084
[ ID] Interval Transfer Bandwidth
[ 3] 0.0000-10.0029 sec 10.8 GBytes 9.28 Gbits/sec
[ 4] local 10.1.2.120 port 5001 connected with 10.1.2.121 port 54818
[ ID] Interval Transfer Bandwidth
[ 4] 0.0000-10.0033 sec 10.8 GBytes 9.27 Gbits/sec
[ 5] local 10.1.2.120 port 5001 connected with 10.1.2.121 port 53274
[ ID] Interval Transfer Bandwidth
[ 5] 0.0000-10.0034 sec 10.8 GBytes 9.29 Gbits/sec
[ 6] local 10.1.2.120 port 5001 connected with 10.1.2.121 port 37330
[ ID] Interval Transfer Bandwidth
[ 6] 0.0000-10.0030 sec 10.9 GBytes 9.32 Gbits/sec

---------------------------------------- Netzwerkspeed aus Virtuellen Server ----------------------------------------


Die Frage aller Fragen:
- mir fehlen Vergleichswerte: Kann jemand die Werte beurteilen (objektiv bitte ;-) ) - ob die für die Leistung zu erwarten ist, oder ob die einfach nur Mies ist!
- sieht jemand auf den ersten Blick aus seiner Erfahrung heraus, wo definitiv schon mal eine Stellschraube angepasst werden kann?
- besteht die Möglichkeit ein SSD-WriteCache (wie ZFS) zu nutzen um die Latenz / Write-Throuput zu minimieren bzw. zu verbessern?

=> Ich kann gerne, falls es interessiert und hilfreich ist, noch ein paar Worte in einem neuen "Post" zum Thema PostgreSQL schreiben.

Proxmox kenne ich sonst nur aus "Stand-Alone" Umgebungen, aber wir wollten im Unternehmen lieber etwas inovatier Unterwegs sein, als was MS und VMWare angeht. Darum die Entscheidung.

Gruß
Chris

 

[fabian]

tJa Raidcontroller sollen mit Ceph eigentlich nicht genutzt werden ::
Warum ist es doch passiert? Es soll die Einschränkungen die SATA mit sich bringen minimieren durch verteiltes Lesen / Schreiben.

das macht gelinde gesagt keinen sinn - Ceph sorgt ja genau fuer die ausfallssicherheit und paralleles lesen..

Samsung QVO 8TB

sind leider auch nicht gerade die beste wahl fuer ceph (oder server einsatz generell) - gibt nen grund warum die billiger sind als enterprise SSDs derselben groesse..

 

[sb-jw]

Ganz verschweigen will ich nicht, dass ich nicht die Ideale Anforderung an CEPH fahre bzw. Umgesetzt habe. Gründe später.

Butter bei die Fische, du machst du hier alles, damit das CEPH nicht performen kann und beschwerst dich dann, dass keine Performance kommt? Es tut mir wirklich leid, aber das Thema Lessons Learned scheint nicht angekommen zu sein. Das Geld, was man in die Hardware steckt, spart man sich nachher doppelt und dreifach bei der Administration und den anderen Mitarbeitern die die langsamen Dienste jetzt nutzen müssen.

Bitte verwende keinen Inline Code Tag sondern den Code Tag, ansonsten ist das auf dem Smartphone auch einfach unlesbar und ist am Rechner teils auch nicht gut dargestellt.

Bitte mal eine Ausgabe von ceph health detail und ceph osd df tree.

Bond10: 2x10GBe LACP -> Switch 1
Bond20: 2x10GBe LACP -> Switch 2
Bond 0: Active (Bond 10) Passic (Bond 20)

Was für Switche verwendet Ihr hier? Jumbo Frames aktiv? L3+4 Hashing drin?

Aber mal ehrlich, hör bitte auf mit so einem Käse, du bekommst für nicht mal 500 EUR zwei gebrauchte Arista Switches mit MLAG oder neue Switche mit 8 Ports oder so. Die Arista Switche die reißen dir alles raus und dank MLAG profitierst du direkt von 4x 10 GbE und ein Switch kann ausfallen und es läuft dennoch alles ohne Ausfall und Störung weiter.

Entschuldige bitte, wenn meine Aussagen an manchen Stellen hart rüber kommen. Mich persönlich ärgert sowas aber einfach immer, denn plötzlich ist CEPH eine schlechte Lösung ohne Performance, was aber einfach nur darin begründet ist, dass man sich nicht an Best Practices hält. Man sieht es hier im Forum ja leider so häufig, dass man einfach erwartet, dass CEPH mit dem letzten Schrott an Hardware doch bitte 100k IOPS liefern soll. Also nimm es bitte nicht persönlich!

 

[proxmrmomba]

Hi,

ich finde die extreme Haltung hier schon etwas überraschend - auch wenn ich es nicht persönlich nehmen soll, ist gerade der Punkt lesson-learned irgendwie schon etwas provakitv in meinen Augen gefasst. Kenne das eigentlich etwas sanfter formuliert ;-)

Mich persönlich ärgert sowas aber

nimm es bitte auch nicht persönlich, ich bin hier auch auf der Suche nach Hilfe - nicht auf technologie Bashingkurs.

Ich habe CEPH weder als schlechte Lösung dargestellt noch sonst wie schlecht gemacht. CEPH ist nun mal auch gesetzt, weil es - außer den Writes - doch ganz gut läuft. ich habe halt einfach ein Problem, ich habe halt Rahmenbedingungen.

mit dem letzten Schrott an Hardware doch

Außer den Samsung QVOs kann ich keine schlechte Hardware erkennen. Die Hardware ist alt, das weiß ich selber. Aber ein nagelneuer HPe G11 Intel / AMD geht halt nicht.
Wie geschrieben - es bestand keine Chance für mehr Geld um SAS SSDs in der passenden Größe und in der passenden Anzahl. Da ich halt nur das Geld nutzen kann, was eben da ist, kann ich nicht alles kaufen, was besser ist. Sonst wäre eine Storagesolution (Nimble etc.) durchaus interessanter gewesen.

Das mit den Inline-Codes werde ich nicht mehr machen, das Problem war mir nicht bewusst. Danke für den Hinweis.
--------------------------------------------------------------------------------

das macht gelinde gesagt keinen sinn - Ceph sorgt ja genau fuer die ausfallssicherheit und paralleles lesen..

Heißt: Im in den nächsten Steps lieber das Raid 5 aufbrechen dann pro SSD eine OSD und die in ein Pool geschmissen?

ceph health detail und ceph osd df tree

hv03:~# ceph health detail
HEALTH_OK

hv03:~# ceph osd df tree
ID  CLASS  WEIGHT     REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME   
-1         109.16006         -  109 TiB  7.6 TiB  7.5 TiB  116 MiB   24 GiB  102 TiB  6.93  1.00    -          root default
-3          36.38669         -   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.8 GiB   34 TiB  6.93  1.00    -              host hv01
 0    ssd   36.38669   1.00000   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.8 GiB   34 TiB  6.93  1.00   33      up          osd.0
-7          36.38669         -   36 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00    -              host hv02
 2    ssd   36.38669   1.00000   36 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00   33      up          osd.2
-5          36.38669         -   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.4 GiB   34 TiB  6.93  1.00    -              host hv03
 1    ssd   36.38669   1.00000   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.4 GiB   34 TiB  6.93  1.00   33      up          osd.1
                         TOTAL  109 TiB  7.6 TiB  7.5 TiB  116 MiB   24 GiB  102 TiB  6.93                                 
MIN/MAX VAR: 1.00/1.00  STDDEV: 0.00

Was für Switche verwendet Ihr hier? Jumbo Frames aktiv? L3+4 Hashing drin?

Keine Jumboframes, letzteres kann ich nicht beantworten (L3+4 Hashing?)Bei Active-Backup ist dieses nicht einstellbar im Proxmox.
Es handelt sich um Unifi Aggregationswitche, die können leider kein MLAG. Danke für den Hinweis in dieser Richtung ein Blick zu werfen.
Jumboframes sind weder auf dem Switch noch im Proxmox aktiviert. Ein Verdacht, dass es hier zu Latenzprobleme kommen könnte habe ich auch. Aber auch das unter VMWare immer mal wieder Diskutiert wurde, ob man Jumboframes nutzt, oder nicht.... (Stand Juni.2023)

dass man sich nicht an Best Practices hält

Im Idealfall wird dieser Thread ein "CEPH-Leistung ohne Bestpractise" vs. "CEPH-Leistung mit fast Bestpractise" und der Weg dahin ;-)
-----------------------------

Also nehme ich mit:
1. Ich schaue mir im ersten Schritt das Netzwerkbonding an, bzw. versuche zu evaluieren ob da mehr Leistung rauszuholen ist?
- Ein Gedanke war erstmal auf balance-alb umzustellen auf allen Switchen.
2. Wenn das nicht fruchtet breche ich das RAID 5 auf... siehe Oben.

 

[aaron]

Heißt: Im in den nächsten Steps lieber das Raid 5 aufbrechen dann pro SSD eine OSD und die in ein Pool geschmissen?

Jup. Damit kann Ceph die Daten und entsprechend die Last besser verteilen. Um die Redundanz kümmert sich Ceph .

Bezüglich Consumer SSDs: Ceph macht primär sync writes auf die darunterliegenden Disks. Damit sind Consumer SSDs ohne PLP grundsätzlich schlecht. Die QVOs sind leider noch einmal eine Stufe schlechter und werden nie gute Schreibperformance liefern. Ich habe leider selbst ein paar davon in anderen Szenarien im Einsatz… ;-)

Wenn man nach SSDs sucht, z.B. bei Geizhals, mal den PLP (power loss protection) Filter aktivieren. Dann sind die wirklich unpassenden Consumer SSDs schon mal weggefiltert.


Grundsätzlich gilt bei Ceph die Faustregel, kleinere aber mehr Resourcen (OSDs, Nodes). Damit hat es im Fehlerfall mehr Möglichkeiten sich zu reparieren. Dem muss man aber auch gegenübersetzen, dass jeder zusätzliche Dienst CPU und RAM verbraucht und muss entsprechend eine Balance finden die klappt.


Schau dir auch an wie viele Pools du hast und setz die target_ratios entsprechend, damit der Autoscaler die pg_num der einzelnen Pools passend setzen kann. Den .mgr kannst du dabei ignorieren. Wenn keine target_ratio / _size gesetzt ist kann der Autoscaler nur den aktuellen Füllstand des Pools hernehmen. Sobald man ihm mitteilt, was man sich am Ende ca. erwartet können die PGs pro Pool entsprechend gesetzt werden damit am Ende jede OSD ~100 PGs hat. Dieser Faustwert ist ein guter kompromiss zwischen Performance und nicht zu viel management overhead für Ceph. Zu wenige PGs können die Performance auch deutlich verschlechtern.

Die target_ratio ist eine Gewichtung. Wenn du nur einen Pool für das VM Storage hast, wird jeder Wert bedeuten, dass du erwartest, dass dieser Pool 100% des verfügbaren Speicherplatzes verbrauchen wird.

Bei mehreren Pools bietet es sich an die ratios zwischen 0.0 und 1.0 oder 0 und 100 zu vergeben, damit man mit Prozenten arbeiten kann. Die Werte sind eine Abschätzung was ihr am Ende erwartet und keine genaue Wissenschaft.

 

[Falk R.]

Daher ist die Entscheidung (Budget gezwungen) auf Samsung QVO 8TB gegangen - im Raid 5. 5x8TB + 1x Ausfallsicherheit
Ja Raidcontroller sollen mit Ceph eigentlich nicht genutzt werden

Es gibt einen Grund warum Enterprise Hersteller, die ebenfalls QLC SSDs nutzen, diese nur für einfache Fileservices oder Backupappliances nutzen.
Hinzu kommt, dass diese QLC SSD auch keine Powerloss Protection hat, womit bei den Enterprise QLC noch vertretbare Schreibwerte auftreten.
Hast du bei dem Raid5 das Smartpath abgeschaltet und den Batteriecache für das Logische Laufwerk eingeschaltet?
Das SmartPath ist bei Raid5/6 wie fahren mit angezogener Handbremse und Anker ausgeworfen zusammen.
Das mit dem Raid bei Ceph wird sich rächen, wenn mal eine Disk komplett ausfällt, aber zum Spielen funktioniert das eigentlich erst einmal.

Warum ist es doch passiert? Es soll die Einschränkungen die SATA mit sich bringen minimieren durch verteiltes Lesen / Schreiben.
die letzten 2 Slots werden das Betriebssystem im Raid 1 genutzt.

Du kannst bei den Smart Array Gen10 auch einfach ein Raid für das OS bauen und alle Disks ohne Konfiguration werden automatisch im HBA Mode an das OS durchgereicht.

Ich bin nicht nur 'kein Fan' von der SD-Kartengeschichte bei HP, sondern auch absoluter SD-Kartenhasser bei HP Umsetzungen.

SD solltest du eh nicht nutzen bei Proxmox. Besser man kauft sich zwei m.2 SATA SSDs (geht nur SATA) und schraubt diese auf die Riser Card.
(Wenn nur 1 Riser verbaut, geht nur eine m.2)
Somit gewinnst du 2 Slots. Du kannst natürlich auch gebraucht weitere Käfige für den Server kaufen, musst dann aber auch noch einen HBA dazu einplanen.

Ich versuche es mal etwas aufzumalen:
Bond10: 2x10GBe LACP -> Switch 1
Bond20: 2x10GBe LACP -> Switch 2
Bond 0: Active (Bond 10) Passic (Bond 20)
vmbr0 -> Bond0
vmbr102->vlan102->Bond0
SDN-Configs -> vmbr0

Fährst du etwa VM Traffic und Ceph auf den gleichen NICs?
Was für Switches habt ihr denn? Da gibt's deutlich elegantere Lösungen.

HDD Benchmarks
Wie soll ich weiter machen?
Ich habe direkt nach dem erstellen:
Nicht aussagekräftig, aber ein Anhaltspunkt - Raid 5 Test unter nativ Windows Server

Die Frage aller Fragen:
- mir fehlen Vergleichswerte: Kann jemand die Werte beurteilen (objektiv bitte ;-) ) - ob die für die Leistung zu erwarten ist, oder ob die einfach nur Mies ist!

Der Windows Benchmark ist nicht vergleichbar, da Ceph ganz anders arbeitet und optimiert ist für verteiltes Arbeiten (viele Server + viele Disks)
Die Werte sind für das Setup eher zu erwartende Werte.

- sieht jemand auf den ersten Blick aus seiner Erfahrung heraus, wo definitiv schon mal eine Stellschraube angepasst werden kann?

Controllercache?

- besteht die Möglichkeit ein SSD-WriteCache (wie ZFS) zu nutzen um die Latenz / Write-Throuput zu minimieren bzw. zu verbessern?

Nein, du kannst aber eine schnelle Bluestore Disk (Access DB + LOG) benutzen, da bitte mindestens 4% der Data-Diskkapazität einplanen.

=> Ich kann gerne, falls es interessiert und hilfreich ist, noch ein paar Worte in einem neuen "Post" zum Thema PostgreSQL schreiben.

Brauchst du nicht, der ist einfach der Leidtragende

Proxmox kenne ich sonst nur aus "Stand-Alone" Umgebungen, aber wir wollten im Unternehmen lieber etwas inovatier Unterwegs sein, als was MS und VMWare angeht. Darum die Entscheidung.

Grundsätzlich gute Entscheidung

Gruß Falk

 

[sb-jw]

Mein letzter Absatz ist die allgemeine Auffassung zum Thema CEPH hier im Forum. Die Threads die solche Themen wie deines behandeln kommen hier ja regelmäßig und immer wieder Predigen die gleichen Leute die gleichen Punkte. Insofern ist auch der Punkt mit "Schrott" oder "schlechtmachen von CEPH" eher auf die allgemeine Auffassung bezogen als auf deinen konkreten Thread. Mit dem letzten Absatz habe ich meine persönliche Auffassung dargestellt, warum mich manche Dinge fuchsen, daher auch die Einleitung "Mich persönlich ärgert...".
Daher gehe ich hier auch nicht weiter auf die Punkte mit deinen Rahmenbedingungen oder Hardware ein, da dies eben nicht explizit auf dich ausgelegt war.

Heißt: Im in den nächsten Steps lieber das Raid 5 aufbrechen dann pro SSD eine OSD und die in ein Pool geschmissen?

Ich wollte mich mit dem ceph osd df tree davon überzeugen, dass ich das wirklich richtig verstanden habe. Und ja, genau das solltest du ganz dringend tun. CEPH verwaltet eine SSD als OSD (Object storage daemon), pro OSD läuft also ein Dienst, der eine eigene TCP/IP Verbindung zu anderen aufbaut. Du hast hier also derzeit 3 OSDs im Cluster, könntest aber 18 Stück haben. Mit den 4x 10G Links und einem L3+4 Hashing könnte dadurch die gesamte Anbindung auch theoretisch optimal ausgenutzt werden. Mit einem reinen L2 Hashing könnte es potenziell passieren, dass nur ein Link deiner 4 genutzt wird und im Worst-Case das Bottleneck wird.

Der Controller MUSS ein HBA sein, bitte kein RAID 0 pro SSD machen, das ist absolut nicht das gleiche. CEPH muss diese SSD direkt ansprechen und verwalten können, da darf kein Controller mit seiner eigenen Magic dazwischen sein. Das könnte zu Inkonsistenzen führen oder höheren Latenzen. CEPH ist darauf angewiesen, dass die SSD die Daten auch direkt hat und geschrieben hat und nicht noch im Controller gecached ist.

Bei Active-Backup ist dieses nicht einstellbar im Proxmox.

Das ist klar, weil Active-Backup nämlich kein LACP ist. Wenn dann ist das auf den LACP Links direkt zu konfigurieren. Active-Backup ist grundsätzlich unabhängig von Switches, während aber LACP auf beiden Seiten zu konfigurieren ist.

Jumboframes sind weder auf dem Switch noch im Proxmox aktiviert. Ein Verdacht, dass es hier zu Latenzprobleme kommen könnte habe ich auch. Aber auch das unter VMWare immer mal wieder Diskutiert wurde, ob man Jumboframes nutzt, oder nicht.... (Stand Juni.2023)

Jumboframes können einfach mehr Daten pro Paket aufnehmen, es müssen also weniger Pakete für die gleiche Menge an Daten verschickt werden. Stell dir mal vor, dass die SSDs alle einzeln angekommen wären, du musst bei allen 18 die Annahme machen und den Lieferschein prüfen, dann musst du alle einzeln auspacken und verbauen. Wären alle als Tray Ware in einem Paket angekommen, hättest du nur einmal ein Paket öffnen müssen, nur einmal den Lieferschein prüfen und müsstest diese gar nicht mehr einzeln auspacken. So ungefähr ist es dann eben auch mit einem normalen Paket vs Jumboframes.
Jumbos bringen nicht immer und überall etwas, aber in der Regel in SAN auf jeden Fall, weil die Menge der Daten auch hier gegeben ist. Jumboframes müssen nicht zwangsläufig etwas an der Latenz machen, aber sie machen auf jeden Fall etwas an der maximalen Bandbreite, da du hier einfach mehrfach auf den Overhead verzichten kannst. Es kommen also viel mehr Daten in einem Paket an als normal.

 

[Falk R.]

Keine Jumboframes, letzteres kann ich nicht beantworten (L3+4 Hashing?)

Jumboframes machen die Latenzen eher höher, reduzieren aber die Anzahl der Pakete. Bei normalen Windows/Linux VMs hast du eh meist größere I/Os und da macht Jumbo Frames auf jeden Fall Sinn.

Es handelt sich um Unifi Aggregationswitche, die können leider kein MLAG. Danke für den Hinweis in dieser Richtung ein Blick zu werfen.

Können die im Stack betrieben werden? Dann würde LACP über alle Ports funktionieren.

Jumboframes sind weder auf dem Switch noch im Proxmox aktiviert. Ein Verdacht, dass es hier zu Latenzprobleme kommen könnte habe ich auch. Aber auch das unter VMWare immer mal wieder Diskutiert wurde, ob man Jumboframes nutzt, oder nicht.... (Stand Juni.2023)

Eigentlich ganz einfaches Thema, Diskutieren tun nur die Unwissenden.
Guck dir dein Workload an und du weißt ob Jumbo oder nicht.
Mach Jumbo bitte an, auf jeden Fall zuerst auf den Switches.

Also nehme ich mit:
1. Ich schaue mir im ersten Schritt das Netzwerkbonding an, bzw. versuche zu evaluieren ob da mehr Leistung rauszuholen ist?
- Ein Gedanke war erstmal auf balance-alb umzustellen auf allen Switchen.

Mit ALB habe ich keine so gute Erfahrung, check erst einmal ob Stacking geht.

2. Wenn das nicht fruchtet breche ich das RAID 5 auf... siehe Oben.

Das wäre die beste Lösung nach Best Practice. Du Gewinnst auch etwas Speicherplatz dazu. Falls du derzeit den Raidcontroller Write Cache nutzt, wird es danach vermutlich noch langsamer. Wenn du derzeit Smart Path nutzt, wird es auf jeden Fall schneller.

 

[proxmrmomba]

Hallo,

Ich danke für die ganzen Infos: Diese werde ich erstmal verdauen, noch ein paar Mal lesen (damit ich auch alles verstehe).
Danke ich für die Erläuterung das es eine direkte Verbindung zwischen OSDs und TCPs Sessions gibt!
Auch will ich das noch ein paar mal in Ruhe lesen, um doppelte Antworten zusammenzufassen und entsprechend zu beantworten.

Ebenso gibt es hier die Hinweise mit Schreibcache, Smartpath etc. das will ich alles Überprüfen.

Zum Thema Switche: die können nur LACP, aber leider nur für sich.
Darum ist es wie folgt aufgebaut:




Vielen Dank das Ihr euch alle die Zeit genommen habt, mir das alles bis jetzt soweit zu erklären!
Ich werde mich hier wieder melden.

EDIT: Ich habe das Bild verändert, da mir hier ein Fehler in der Darstellung unterlaufen ist.

 

[Falk R.]

Zum Thema Switche: die können nur LACP, aber leider nur für sich.
Darum ist es wie folgt aufgebaut:

Das Setup wie in deine Bild ist schnell etwas irreführend. Da dein Bond0 ein Active-Backup ist, läuft der gesamte Traffic über einen LACP Bond (10 oder 10).

Deine Switches können auch kein Stacking, sind also nicht wirklich geeignet wenn man Redundanzen aufbauen will. Das nächste mal lieber ein MikroTik CRS326-24S+2Q+RM. Der kann auch MLAG.

Hast du HPE ssacli im PVE installiert? Damit kannst du im laufenden Betrieb deinen Controller auslesen und Konfigurationen ändern.

 

[proxmrmomba]

Vielen Dank für die Rückmeldungen soweit!
Ich ärgere mich bei den MikroTik-Preisen Unifi Aggregationswitche gekauft zu haben. Gut, lassen wir dieses Thema erstmal beiseite.

Vielleicht kann mir jemand die die Frage zum Vorgehen beantworten:
Im Proxmox Wiki steht; dass die Server im CEPH nach Möglichkeit "gleich" sein sollten (Erklärung - lieber 4x500, Statt 1xTB und 2x250GB).
Würde es direkt "knallen" wenn man sich kurzweilig nicht dran hält?

1. Idee
Ich frage mich, ob ich ein RAID5 Aufbrechen kann, mir entsprechend die OSDs auf dem Host baue kann und diese dann im CEPH-Pool hinzufügen kann( Ausgabe ist ein Fake, aber so stelle ich mir das vor)

2. Idee (aber nicht der Reihenfolge nach präferiert)
Hab durchaus Sorge vor ein Datenverlust und auch nicht viel "Spaß" Backup and Restores fahren zu wollen. Was aber als letzte Instanz auch möglich ist. Jedoch ist der B&R-Weg kein "schleichender" Prozess sondern ich muss alles in einen Block schaffen....
3. Idee:
Alle VMs und CT mittels Storage-Motion auf eine Synology schieben, da humpeln lassen und CEPH umbauen.

Aus eurer Erfahrung (und natürlich ohne Gewehr und Garantien) heraus, würdet ihr sagen, ist ein Versuch wert oder gibts direkt Vetos?

hv03:~# ceph osd df tree
ID  CLASS  WEIGHT     REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME  
-1         109.16006         -  109 TiB  7.6 TiB  7.5 TiB  116 MiB   24 GiB  102 TiB  6.93  1.00    -          root default
-3          36.38669         -   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.8 GiB   34 TiB  6.93  1.00    -              host hv01
 0    ssd   36.38669   1.00000   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.8 GiB   34 TiB  6.93  1.00   33      up          osd.0
-7          36.38669         -   36 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00    -              host hv02
 2    ssd   36.38669   1.00000   7.9 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00   33      up          osd.2
 3    ssd   36.38669   1.00000   7.9 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00   33      up          osd.3
 x    ssd   36.38669   1.00000   7.9 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00   33      up          osd.x
 5    ssd   36.38669   1.00000   7.9 TiB  2.5 TiB  2.5 TiB   39 MiB  8.7 GiB   34 TiB  6.93  1.00   33      up          osd.5
-5          36.38669         -   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.4 GiB   34 TiB  6.93  1.00    -              host hv03
 1    ssd   36.38669   1.00000   36 TiB  2.5 TiB  2.5 TiB   39 MiB  7.4 GiB   34 TiB  6.93  1.00   33      up          osd.1

Ich würde erstmal die OSD-Geschichte glatt ziehen. Danach würde ich mir Gedanken über Netzwerk machen mit gegebener Hardware. Erstmal schauen was da geht, bevor ich mehr Gelder erfragen muss.

Grundsätzlich gilt bei Ceph die Faustregel, kleinere aber mehr Resourcen (OSDs, Nodes). Damit hat es im Fehlerfall mehr Möglichkeiten sich zu reparieren. Dem muss man aber auch gegenübersetzen, dass jeder zusätzliche Dienst CPU und RAM verbraucht und muss entsprechend eine Balance finden die klappt.

Da bin ich aktuell recht Entspannt, da für CEPH die RAM-Größe und CPU in der Anschaffung der Hardware berücktsichtigt wurde.
Jeder Server hat >500GB Ram - die Server werden in Zukunft alle 32 Kerne und >3GHZ haben.

Grüße.

PS.: die anderen offenen Punkte bezüglich
- Smartpath
- HPE ssacli
- Jumbo
habe ich heute noch nicht umgesetzt oder getan.

Controllercache? <- 2GB installiert, über LI-ION Akku gesichert und aktiviert.

 

[Falk R.]

Vielen Dank für die Rückmeldungen soweit!
Ich ärgere mich bei den MikroTik-Preisen Unifi Aggregationswitche gekauft zu haben. Gut, lassen wir dieses Thema erstmal beiseite.

Das nächste mal Hardwaretipps im Forum oder auf Blogs/Videos holen.

Vielleicht kann mir jemand die die Frage zum Vorgehen beantworten:
Im Proxmox Wiki steht; dass die Server im CEPH nach Möglichkeit "gleich" sein sollten (Erklärung - lieber 4x500, Statt 1xTB und 2x250GB).
Würde es direkt "knallen" wenn man sich kurzweilig nicht dran hält?

Natürlich nicht, Ceph ist da sehr tolerant, performt dann nur nicht so doll.

1. Idee
Ich frage mich, ob ich ein RAID5 Aufbrechen kann, mir entsprechend die OSDs auf dem Host baue kann und diese dann im CEPH-Pool hinzufügen kann( Ausgabe ist ein Fake, aber so stelle ich mir das vor)

Klar geht das. Der sync dauert dann nur ein wenig.

2. Idee (aber nicht der Reihenfolge nach präferiert)
Hab durchaus Sorge vor ein Datenverlust und auch nicht viel "Spaß" Backup and Restores fahren zu wollen. Was aber als letzte Instanz auch möglich ist. Jedoch ist der B&R-Weg kein "schleichender" Prozess sondern ich muss alles in einen Block schaffen....
3. Idee:
Alle VMs und CT mittels Storage-Motion auf eine Synology schieben, da humpeln lassen und CEPH umbauen.

Aus eurer Erfahrung (und natürlich ohne Gewehr und Garantien) heraus, würdet ihr sagen, ist ein Versuch wert oder gibts direkt Vetos?

Funktionieren tut alles 3. Ich habe auch schon verbastelte Ceph Cluster im laufenden Betrieb umgebaut. Musst nur geduld mitbringen für die recovery. Gerade bei den Disks.

Ich würde erstmal die OSD-Geschichte glatt ziehen. Danach würde ich mir Gedanken über Netzwerk machen mit gegebener Hardware. Erstmal schauen was da geht, bevor ich mehr Gelder erfragen muss.

Da bin ich aktuell recht Entspannt, da für CEPH die RAM-Größe und CPU in der Anschaffung der Hardware berücktsichtigt wurde.
Jeder Server hat >500GB Ram - die Server werden in Zukunft alle 32 Kerne und >3GHZ haben.

Grüße.

PS.: die anderen offenen Punkte bezüglich
- Smartpath
- HPE ssacli
- Jumbo
habe ich heute noch nicht umgesetzt oder getan.

Controllercache? <- 2GB installiert, über LI-ION Akku gesichert und aktiviert.

Wenn du nichts manuell gemacht hast, ist für das Array Smartpath aktiv.
Du kannst das jederzeit im laufenden Betrieb ausschalten und dann lässt sich auf der vDisk der Cache aktivieren. Solange Smartpath im Array an ist, geht das nicht.
Das sollte schon mal eine deutliche Entlastung bringen, vor allem beim Umbau.

 

[proxmrmomba]

Wenn du nichts manuell gemacht hast, ist für das Array Smartpath aktiv.

Zwischenbericht:
Ich habe Smartpath deaktivert und den Controller-Cache auf R20% W80% gestellt.

im Radosbenchmark habe ich danach leicht schlechtere Werte als wie zu Anfang.
Das kann möglicherweise aber auch daran liegen, dass auch schon VMs auf dem Ceph laufen.
Möglicherweise ist mein Benchmark mit den einstellungen auch gar nicht aussagekräftig.

:> rados bench -p CephPool01 20 write -b 10M -t 16 --run-name hv03 --no-cleanup
hints = 1
Maintaining 16 concurrent writes of 10485760 bytes to objects of size 10485760 for up to 20 seconds or 0 objects
Object prefix: benchmark_data_hv03_638334
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      15        77        62   619.915       620    0.203849    0.228593
    2      15       147       132   659.898       700    0.382132    0.223084
    3      15       221       206   686.568       740    0.208293    0.224184
    4      15       297       282   704.903       760    0.182625    0.220325
    5      15       365       350   699.906       680    0.222487     0.22224
    6      15       436       421   701.572       710    0.227073    0.222779
    7      15       508       493   704.191       720    0.193961    0.222325
    8      15       580       565   706.157       720     0.18657    0.222337
    9      15       651       636   706.575       710    0.185549    0.223226
   10      15       724       709   708.904       730    0.207984    0.222431
   11      15       795       780   708.992       710    0.361387    0.222249
   12      15       865       850   708.236       700    0.247819    0.223307
   13      15       937       922   709.134       720    0.165662    0.222922
   14      15      1008       993   709.189       710    0.244663     0.22285
   15      15      1083      1068   711.904       750    0.240304    0.222374
   16      15      1155      1140   712.404       720    0.162306    0.221933
   17      15      1231      1216   715.195       760    0.168114    0.222175
   18      15      1304      1289   716.013       730    0.160762    0.221929
   19      15      1375      1360   715.691       710    0.187764    0.221707
2024-01-24T07:40:27.354137+0100 min lat: 0.114213 max lat: 0.552907 avg lat: 0.221249
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
   20      15      1450      1435   717.401       750    0.208295    0.221249
Total time run:         20.1311
Total writes made:      1451
Write size:             10485760
Object size:            10485760
Bandwidth (MB/sec):     720.776
Stddev Bandwidth:       31.0983
Max bandwidth (MB/sec): 760
Min bandwidth (MB/sec): 620
Average IOPS:           72
Stddev IOPS:            3.10983
Max IOPS:               76
Min IOPS:               62
Average Latency(s):     0.221014
Stddev Latency(s):      0.0596025
Max latency(s):         0.552907
Min latency(s):         0.0724575

:> rados bench -p CephPool01 20 seq -t 16 --run-name hv03
hints = 1
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      15       110        95   949.682       950    0.230518    0.152888
    2      15       209       194   969.593       990    0.119568    0.155242
    3      15       308       293   976.338       990    0.261164    0.155401
    4      15       428       413   1032.19      1200   0.0912736    0.150218
    5      15       548       533   1065.71      1200    0.151004    0.145989
    6      15       667       652   1086.39      1190   0.0899723    0.143569
    7      15       773       758   1082.59      1060    0.183527     0.14414
    8      15       877       862   1077.25      1040   0.0812517    0.144772
    9      15       991       976    1084.2      1140    0.201599    0.143998
   10      15      1105      1090   1089.76      1140    0.204999    0.143686
   11      15      1218      1203    1093.4      1130   0.0818581    0.143276
   12      15      1335      1320   1099.76      1170   0.0726195    0.142994
   13      15      1440      1425   1095.79      1050   0.0715559    0.143447
Total time run:       13.1409
Total reads made:     1451
Read size:            10485760
Object size:          10485760
Bandwidth (MB/sec):   1104.19
Average IOPS:         110
Stddev IOPS:          8.72294
Max IOPS:             120
Min IOPS:             95
Average Latency(s):   0.142781
Max latency(s):       0.316963
Min latency(s):       0.0393588

Interessanter ist aber für mich, dass ich nun im PostgreSQL deutlich plausiblere und bessere Werte habe!

Wenn ich das nun richtig verstanden habe, dann wird beim durchreichen der Disks auf den Cache verzichtet. Das wiederrum würde also bedeuten, das ggf. meine Leistung wieder nach unten geht?

-----
Ich werde mir jetzt erstmal ein Detailplan erstellen wie ich die einzelnen SSDs in die Umgebung bringe.

 

[Falk R.]

Zwischenbericht:
Ich habe Smartpath deaktivert und den Controller-Cache auf R20% W80% gestellt.

Am besten auf 10% Read und 90% Write stellen. Lesen können die QLC SSDs schon schnell genug, das schreiben muss beschleunigt werden.

im Radosbenchmark habe ich danach leicht schlechtere Werte als wie zu Anfang.
Das kann möglicherweise aber auch daran liegen, dass auch schon VMs auf dem Ceph laufen.
Möglicherweise ist mein Benchmark mit den einstellungen auch gar nicht aussagekräftig.

Ich hätte beim Benchmark eher identische Werte erwartet, aber der Benchmark ist in diesem nicht so Optimalen Setup nicht so richtig Aussagekräftig

Interessanter ist aber für mich, dass ich nun im PostgreSQL deutlich plausiblere und bessere Werte habe!

Der echte Workload sollte vom Schreibcache profitieren.

Wenn ich das nun richtig verstanden habe, dann wird beim durchreichen der Disks auf den Cache verzichtet. Das wiederrum würde also bedeuten, das ggf. meine Leistung wieder nach unten geht?

Das kann passieren. Die schreibperformance könnte wieder einbrechen, aber wenn du viele VMs hast, verteilt sich die Last besser auf die SSDs.
Mit den QLC SSDs wird es aber nie richtig schnell werden.

-----
Ich werde mir jetzt erstmal ein Detailplan erstellen wie ich die einzelnen SSDs in die Umgebung bringe.

 

[proxmrmomba]

Rückmeldung:
Thema ist nicht eingeschlafen - Umsetzung nicht gestartet.

 

[proxmrmomba]

Für denn Fall dass dieses Thema noch interessiert, Thema ist nicht tot, ich will ein paar Fakten liefern:

CPU und RAM:
2x HPe G10 380 mit 1024GB RAM 24 Kerne Gold 6146 CPU @ 3.20GHz
1x HPe G10 380 mit 512GB RAM 32 Kerne Gold 6142M CPU @ 2.60GHz

Alle Server haben jetzt die gleiche CPU.

Bezüglich Consumer SSDs: Ceph macht primär sync writes auf die darunterliegenden Disks. Damit sind Consumer SSDs ohne PLP grundsätzlich schlecht. Die QVOs sind leider noch einmal eine Stufe schlechter und werden nie gute Schreibperformance liefern. Ich habe leider selbst ein paar davon in anderen Szenarien im Einsatz… ;-)

Es ist wie ihr es schriebt. die QVOs sind einfach mal... scheiße. Ich hab noch nie eine solche schlechte SSD in den Händen gehalten (Ich habe defintiv was gelernt). Auch in einzelnen Benchmarks sind die bis auf 13MB/s zusammen gebrochen. Das Merkt man aber leider nicht in den ersten 15 Minuten.

Fährst du etwa VM Traffic und Ceph auf den gleichen NICs?

dieser Umstand war gegeben, wurde aber abgestellt. Eine Änderung / Verbesserung blieb aus. (Einfach weil die SSDs nichts abliefern können)

Du kannst bei den Smart Array Gen10 auch einfach ein Raid für das OS bauen und alle Disks ohne Konfiguration werden automatisch im HBA Mode an das OS durchgereicht.

Das Raid wurde rausoperiert, jetzt beinhaltet jeder Server 3OSDs. Jedes OSD managed eine 8TB QVOs. Entgegen den Vermutungen gibt es dadurch keine Leistungseinbußungen als wenn der RAID-Ctrl+ RAID mit Cache dabei wäre. Das ist schon mal schön.

Aufbrechen vom RAID.
Wie wurde das gemacht: Das große Logical-Volumen auf RAID Basis wurde "Out" gesetzt. Nach dem CEPH sich dann neu organisiert hatte, wurde das Volumen "entfernt" und im RAID-Ctrl. wurde das RAID entfernt - die Disc werden einfach durchgereicht.
Im nächsten Step: 3 von den 6 QVOs wurden als einzelne DISK wieder im CEPH-Pool (Root default) aufgenommen. "Rebuild" wurde abgewartet, Vorgang wurde auf den anderen 3 Servern umgesetzt.
Das funktionierte ohne großen Kummer aber mit VIEL Wartezeit.

Tatsächlich wurde ohne Raidcontroller durchaus "leicht" bessere Werte erreicht, da es nun eben 9 OSDs gibt.
die anderen 3 SSDs bzw. die SLOTs sollen für die Enterprise SSDs freigehalten werden.

-------------------
Blauäugigkeit und Unwissenheit (durch fehlende Erfahrung) führten halt zu diesem Umstand. Kleinere Tests mit ZFS brachten halt auch keine Verbesserungen. Im großen herrsch bei uns Einigkeit: CEPH ist eh die erste Wahl.

Was mir aber bei der Suche nach professioneller Hilfe aufgefallen ist: Es gibt eine große Diskrepanz in getätigten Aussagen, u.A. wurde pauschal auf die "älteren" Server rumgehakt. Aber im Proxmox Benchmark vom 12/2023 war die Hardware nur durch schnellere RAMs und SAS / NVME besser.

Mit den Infos hier wurde daraus aber ein "rundes" Bild.

Unter'm Strich: das ganze Setup stirbt - wie es hier geschrieben wurde - wegen der QVOs, die bis auf 16MB/s runter gehen.
Was wird folgen: Es wird voller ungeduld auf eine Lieferung kleinerer SAS SSDs gewartet.

 

[proxmrmomba]

Hallo, bevor ich jetzt wieder in eine Falle trete:

Wie gehe ich am Besten vor, dass ich meine SATA-SSDs getrennt von den SAS-SSDs in versch. Pools manage?

Meine Idee wäre entsprechend der Konfig durch die CRUSH-MAP
Dabei definiere ich den physikalischen Host Server01 noch mal als sas_Server01 neu und füge da die OSD mit dem SAS hinzu.

Ich baue mir ein neuen root und eine neue rule.

In einer Testumgebung hat das soweit funktioniert, aber wie ich gelernt habe: Nur weil es am Anfang funktioniert hat, heißt es nicht, dass es dauerhaft so funktionieren wird

Warum erstelle ich mir ein Host sas_server01? Damit Proxmox mir die Hosts in der richtigen Root anzeigt. Ich weiß leider nicht ob das nur ein Anzeigefehler ist, oder generell techn. blödsinn den ich da mache.

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54

# devices
device 0 osd.0 class ssd
device 1 osd.1 class ssd
device 2 osd.2 class ssd
device 3 osd.3 class ssd
device 4 osd.4 class ssd
device 5 osd.5 class ssd #sas
device 6 osd.6 class ssd
device 7 osd.7 class ssd
device 8 osd.8 class ssd
device 9 osd.9 class ssd
device 10 osd.10 class ssd
device 11 osd.11 class ssd #sas
device 12 osd.12 class ssd #sas

# types
type 0 osd
type 1 host
[...]

# buckets
host Server01 {
        id -3           # do not change unnecessarily
        id -6 class ssd         # do not change unnecessarily
        # weight 25.32526
        alg straw2
        hash 0  # rjenkins1
        item osd.0 weight 7.27739
        item osd.8 weight 7.27739
        item osd.9 weight 7.27739
        #item osd.5 weight 3.49309
}

host sas_Server01 {
        id -33          # do not change unnecessarily
        id -36 class ssd                # do not change unnecessarily
        # weight 3.49309
        alg straw2
        hash 0  # rjenkins1
        item osd.5 weight 3.49309
}
host Server02 {
        id -37          # do not change unnecessarily
        id -10 class ssd                # do not change unnecessarily
        # weight 25.32526
        alg straw2
        hash 0  # rjenkins1
        item osd.2 weight 7.27739
        item osd.6 weight 7.27739
        item osd.7 weight 7.27739
#       item osd.11 weight 3.49309
}

host sas_Server02 {
        id -7           # do not change unnecessarily
        id -10 class ssd                # do not change unnecessarily
        # weight 25.32526
        alg straw2
        hash 0  # rjenkins1
#        item osd.2 weight 7.27739
#        item osd.6 weight 7.27739
#        item osd.7 weight 7.27739
        item osd.11 weight 3.49309
}

host Server03 {
        id -5           # do not change unnecessarily
        id -8 class ssd         # do not change unnecessarily
        # weight 26.05759
        alg straw2
        hash 0  # rjenkins1
        item osd.10 weight 7.52150
        item osd.1 weight 7.52150
        item osd.4 weight 7.52150
#       item osd.12 weight 3.49309
}

host sas_Server03 {
        id -35           # do not change unnecessarily
        id -8 class ssd         # do not change unnecessarily
        # weight 26.05759
        alg straw2
        hash 0  # rjenkins1
#        item osd.10 weight 7.52150
#        item osd.1 weight 7.52150
#        item osd.4 weight 7.52150
        item osd.12 weight 3.49309

}

root default {
        id -1           # do not change unnecessarily
        id -12 class ssd                # do not change unnecessarily
        # weight 83.98549
        alg straw2
        hash 0  # rjenkins1
        item Server01 weight 25.32526
        item Server03 weight 26.05759
        item Server02 weight 25.32526
}

root sas_default {
        id -2           # do not change unnecessarily
        id -4 class ssd         # do not change unnecessarily
        # weight 3.84000
        alg straw2
        hash 0  # rjenkins1
        item sas_Server01 weight 3.49
        item sas_Server02 weight 3.49
        item sas_Server03 weight 3.49
}
# rules
rule replicated_rule {
        id 0
        type replicated
        step take default
        step chooseleaf firstn 0 type host
        step emit
}
rule sas_replicated_rule {
        id 1
        type replicated
        step take sas_default
        step chooseleaf firstn 0 type host
        step emit
}

# end crush map

Darum zum Abschluss meine Frage: Bin ich da auf den richtigen Weg?

Wie gehts weiter:
Sollte es mit den SAS-Platten "problemlos" laufen, werden ggf. weitere Platten beschafft. Solange muss ich leider parallel SATA und SAS fahren.
Möglicherweise werden auch ein paar QVOs für ein Datengrab drin bleiben.

 

[aaron]

Neues Root ist nicht nötig AFAICT.

Du willst ja nur je einen Pool auf den SATA und einen Pool auf die SAS SSDs legen oder?

Device class specific rules reichen voll aus. https://docs.ceph.com/en/latest/rados/operations/crush-map/#device-classes

Device classes können frei vergeben werden. D.h. wenn du jetzt aktuell noch nur die SATA SSDs hast, kannst du eine Regel definieren, die diese device class als Ziel hat:

ceph osd crush rule create-replicated replicated_sata_ssd default host ssd

Diese Regel kannst du dann allen aktuellen Pools zuweisen. Das wird ein Rebalance auslösen da sich die Topologie geändert hat.

Als nächstes kannst du die erste OSD auf einer SAS OSD erstellen. Hierbei definierst du die device class aber manuell. Über die CLI mittels des entsprechendes Parameters, oder über die GUI indem du in das Feld einen anderen Namen schreibst. Z.B. "ssd-sas".

Sobald die erste OSD mit einer neuen device class vorhanden ist, kannst du eine Regel dafür erstellen:

ceph osd crush rule create-replicated replicated_sas_ssd default host ssd-sas

Du kannst diese device class dann auch über die GUI beim erstellen der restlichen OSDs auswählen. Dann noch einen Pool erstellen der die Regel "replicared_sas_ssd" oder wie du sie auch nennst hat und gut ist.

Wichtig, sobald man mit device-classes arbeitet ist, dass wirklich jeder pool eine entsprechende Regel hat. Wenn noch ein Pool die standard "replicated_rule" verwendet, welche sich nicht um device classes kümmert, gibt es einen Überlapp und der Autoscaler kann nicht ausrechnen, wie viele PGs jeder Pool bekommen soll.

 

[proxmrmomba]

Hallo Aaron,

ich danke dir für deine Hinweise und ausführliche Antwort!

Es wurde fast genauso umgesetzt wie du es beschrieben hast. Hier habe ich eine kleine Abweichung unternommen:

ceph osd crush rule create-replicated replicated_sata_ssd default host ssd

da habe ich direkt die default_rep angepasst und auf ssd beschränkt. Es scheint mir so, dass es dadurch kein Rebelance gibt. Das wollte ich bei den QVOs auf jeden Fall vermeiden - da ich hier wirklich Tage einplanen kann. (Auf Grund deren Read/Write)

Was mir besonder gut an deinem Hinweis gefällt, es ist vollständig zu der GUI kompatibel, während die "mehrere Root-Variante" mit Pseudohosts für Probleme innerhalb der GUI sorgte. (Und ob es danach zukünftig noch techn. Probleme gibt, lässt sich von mir nicht bewerten)

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54

# devices
device 0 osd.0 class ssd
device 1 osd.1 class ssd
device 2 osd.2 class ssd
device 3 osd.3 class ssd
device 4 osd.4 class ssd
device 5 osd.5 class sasssd
device 6 osd.6 class ssd
device 7 osd.7 class ssd
device 8 osd.8 class ssd
device 9 osd.9 class ssd
device 10 osd.10 class ssd
device 11 osd.11 class sasssd
device 12 osd.12 class sasssd

# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 zone
type 10 region
type 11 root

# buckets
host Server01 {
    id -3        # do not change unnecessarily
    id -6 class ssd        # do not change unnecessarily
    id -19 class sasssd        # do not change unnecessarily
    # weight 25.91116
    alg straw2
    hash 0    # rjenkins1
    item osd.0 weight 7.27739
    item osd.8 weight 7.27739
    item osd.2 weight 7.86330
    item osd.5 weight 3.49309
}
host Server03 {
    id -5        # do not change unnecessarily
    id -11 class ssd        # do not change unnecessarily
    id -20 class sasssd        # do not change unnecessarily
    # weight 26.05759
    alg straw2
    hash 0    # rjenkins1
    item osd.10 weight 7.52150
    item osd.1 weight 7.52150
    item osd.4 weight 7.52150
    item osd.12 weight 3.49309
}
host Server02 {
    id -37        # do not change unnecessarily
    id -12 class ssd        # do not change unnecessarily
    id -21 class sasssd        # do not change unnecessarily
    # weight 26.49707
    alg straw2
    hash 0    # rjenkins1
    item osd.7 weight 7.27739
    item osd.9 weight 7.86330
    item osd.6 weight 7.86330
    item osd.11 weight 3.49309
}

root default {
    id -1        # do not change unnecessarily
    id -14 class ssd        # do not change unnecessarily
    id -23 class sasssd        # do not change unnecessarily
    # weight 78.75702
    alg straw2
    hash 0    # rjenkins1
    item Server01 weight 22.41808
    item Server03 weight 26.05759
    item Server02 weight 23.00397
}

# rules
rule replicated_rule {
    id 0
    type replicated
    step take default class ssd
    step chooseleaf firstn 0 type host
    step emit
}
rule sas_replicated_rule {
    id 1
    type replicated
    step take default class sasssd
    step chooseleaf firstn 0 type host
    step emit
}

# end crush map

Für die, die hier mal über das Thema stolpern;
Ich habe ein Benchmark von 3QVOs im RAIDZ mit ZFS - vs. einer einzelnen SAS-SSD unter der Ubuntu-Disk-Gui gemacht.
Warum RaidZ? Wurde uns alt alternative zu Ceph nahegelegt - nur Blind umbauen ohne größere Tests wollte ich nicht

> Werte für den Test:

QVO im RaidZ (Also gleiche IOP-Leistung aber Vervielfachung der Bandbreite) => Dieser Vorgang hat mehrere Stunden gedauert. Schätzungsweise 4-5 Stdunden

Danach der gleiche Test auf einer einzelnen SAS-Platte (ZFS hab ich mir gespart) Der Vorgang hat wenige Minuten gedauert.

 

[aaron]

da habe ich direkt die default_rep angepasst und auf ssd beschränkt. Es scheint mir so, dass es dadurch kein Rebelance gibt. Das wollte ich bei den QVOs auf jeden Fall vermeiden - da ich hier wirklich Tage einplanen kann. (Auf Grund deren Read/Write)

Kann ich verstehen. Am besten dokumentiert ihr das aber, um nicht in Zukunft verwirrt zu sein, falls die normale replicated_rule sich nicht ganz so verhaltet wie man es glauben würde