CEPH Hochverfügbarkeit funktioniert nicht

[nugzarg]

Hallo,

Wir haben ein relative großes Hyperkonvergentes Cluster. 17 server jeweils mit 8 NVMe OSDs. Proxmox Version ist 7.4.17, Kernel ist
5.15.126-1-pve. CEPH Version ist 17.2.6 (quincy).
CEPH cluster/public Netzwerke nutzen zwei eigene 40Gb/s Interfaces gebündelt in LACP bond. MTU ist 9000. CEPH ist ziemlich ausgelastet:

1.4 GiB/s rd, 345 MiB/s wr, 44.85k op/s rd, 20.07k op/s wr

Wenn ein Server für mehr als 10 Minuten nicht erreichbar ist (letzter Zeit weil Mainboard in einem Server den Geist aufgegeben hat), ist CEPH nicht wie erwartet voll funktionsfähig. Klar, recovery wird angestoßen (das ist ja auch zu erwarten), aber das eigentliche Problem sind mehrere tausend slow ops. Sehr viele VMs sind deswegen nicht mehr ansprechbar. Das Problem löst sich irgendwann selbst, aber es dauert manchmal 20-30 Minuten.
Ich habe es an gesundem CEPH cluster ausprobiert. Einfach mal von einem der Server Netzwerkkabels gezogen und 10 Minuten gewartet. Das gleiche wie beim Serverausfall. CEPH blockt tausende von OPS wegen slow ops und viele VMs sind nicht mehr ansprechbar. Sollte CEPH den Ausfall eines der Server nicht einfach wegstecken? So dass VMs gar nichts davon mitbekommen?

Ich wäre für jede Hilfe dankbar.

 

[aaron]

Was für Modelle sind die OSDs?
Wie ausgelastet ist das Netz und die Nodes (CPU, IO delay) im Normalbetrieb? Wenn da nicht ausreichend Reserven vorhanden sind, kann das beim Recovery zu Problemen führen.

Ihr könnt versuchen, die Recovery stärker zu bremsen, damit es den Produktivbetrieb nicht zu sehr beeinträchtigt: https://pve.proxmox.com/wiki/Ceph_mClock_Tuning

 

[nugzarg]

Hallo @aaron ,

Die OSDs sind Samsung pm9a3 Datacenter NVMes. Keine Desktop NVMes. Sowohl CPU, als auch RAM ist ausreichend vorhanden. Etwa 30 % von CPU und 50 % vom RAM ist in jedem Server immer frei. Jeder Server hat 128 CPU cores und 512 GB bis 1 TB RAM. IO delay ist in Normalbetrieb nahe 0 % und steigt während recovery bis etwa 1 %.

über mClock tuning wusste ich nichts. Ich werde es testen und poste die Ergebnisse. Danke für den Tipp.

 

[Falk R.]

Wie ausgelastet ist denn das Netzwerk wenn der Rebuild läuft?
Für so einen großen Cluster mit NVMe SSDs ist das Netzwerk etwas schmal.
Unter 2x 100GBit würde ich nicht anfangen. Eventuell lohnt es sich das Clusternetzwerk vom Clientnetzwerk zu trennen. Wenn man das Client auf 2x 40G lässt und für Cluster 2x 100G dazu baut, wäre deutlich besser.
Ich habe beim kleinsten Cluster mit 3 Hosts und nur je 3 NVMe, einen Host neu machen müssen und beim Recovery hatte ich da 60GBit Netzwerkauslastung.

 

[nugzarg]

Nachtrag:

Während recovery Netzwerk ist nur minimal ausgelastet. Nicht mal 1 Gb/s. Es ist eher unwahrscheinlich, dass Netzwerk in in diesem Fall die Ursache ist.

Ich habe mclock scheduler Parameter geändert (wie @aaron empfohlen hat). Nämlich osd_mclock_scheduler_background_recovery_lim und
osd_mclock_scheduler_background_recovery_res Parameter deutlich reduziert. Nun ist recovery etwas langsamer, aber keine slow ops mehr. Aber nur wenn ein Server komplett ausfällt. Komplett heißt Server hat keine Netzwerkverbindung UND alle OSDs in diesem Server sind ausgeschaltet. So etwas wie server crash, oder Stromausfall. Aber wenn die Netzwerkverbindung fuer einen Server unterbrochen wird, ohne dass OSDs aus sind, und dann Netzwerkverbindung wiederhergestellt wird, passiert das gleiche. Slow ops eben.

 

[Falk R.]

Wenn du nur so wenig Netzwerkauslastung hast, scheint da etwas faul zu sein. Selbst in meinem Homelab habe ich mit Consumer SSDs bis zu 20GBit Traffic.
Hast du mal das Netzwerk mit iperf durchgemessen?

 

[nugzarg]

Wenn du nur so wenig Netzwerkauslastung hast, scheint da etwas faul zu sein. Selbst in meinem Homelab habe ich mit Consumer SSDs bis zu 20GBit Traffic.
Hast du mal das Netzwerk mit iperf durchgemessen?

Ja. Mehrmals. 4 Server Prozesse an einem Server gestartet (da ein Prozess nicht 40Gb/s voll nutzen kann) und 4 client Prozesse an anderem Server. Testergebnis liegt bei etwa 38-39 Gb/s.

 

[Falk R.]

Wenn du die slow ops hast, siehst du da Latenzen auf den OSDs?
Habt ihr die NVMe direkt onboard angeschlossen oder über einen PCI Switch, oder HBA?

 

[nugzarg]

Wenn du die slow ops hast, siehst du da Latenzen auf den OSDs?
Habt ihr die NVMe direkt onboard angeschlossen oder über einen PCI Switch, oder HBA?

Ja, an OSDs in Server mit unterbrochener Verbindung sind die OSD Latenzen etwas mehr als an anderen. Etwa 4-7 ms an Server welches kurz nicht erreichbar war. 1-3 ms an anderen.
Könnte die Ursache zu wenige PGs per OSD sein? Es sind ungefähr 60 pro OSD.