OSD crash blockiert gaanzen Ceph Kluster

[Winet.maier]

Wir betreiben einen Proxmox-VE-Cluster mit 9 Hosts, insgesamt rund 800 CPU-Kernen und 8 TB Arbeitsspeicher. Als Storage setzen wir einen NFS-Storage auf Basis von Jovian DSS sowie einen Ceph-Cluster mit ca. 30 TB nutzbarem Speicher ein.


Innerhalb des letzten Monats ist das gleiche Problem bereits zweimal aufgetreten.


In beiden Fällen ist jeweils eine einzelne OSD hängen geblieben bzw. nicht mehr reagiert. Dadurch wurde der gesamte Ceph-Cluster nahezu vollständig blockiert und war praktisch nicht mehr nutzbar.


Leider ist es mir in beiden Fällen nicht gelungen, die entsprechenden Fehlermeldungen oder Logs zu sichern, bevor ich die betroffene OSD neu gestartet habe.


Auffällig ist, dass nicht dieselbe OSD betroffen war, sondern bei jedem Vorfall eine andere OSD. Das Problem scheint daher nicht auf eine einzelne Festplatte oder OSD beschränkt zu sein.


Die Behebung war jeweils identisch:

• Die betroffene OSD wurde beendet bzw. neu gestartet.
• Unmittelbar danach arbeitete der gesamte Ceph-Cluster wieder ohne erkennbare Probleme.

Die Auswirkungen auf unsere virtuellen Maschinen waren jedoch erheblich. Insbesondere mehrere Windows-Server-VMs reagierten auf den Storage-Ausfall mit einer extrem hohen CPU-Auslastung und wurden schließlich instabil bzw. stürzten ab.


Die zugrunde liegende SSD der betroffenen OSD wurde überprüft. Es wurden weder SMART-Fehler noch andere Auffälligkeiten festgestellt. Die SSD war zum Zeitpunkt des Vorfalls lediglich zu etwa 50 % ausgelastet, sodass wir derzeit nicht von einem Hardwaredefekt ausgehen.


Wir bitten um Unterstützung bei folgenden Fragen:

• Welche Ursachen können dazu führen, dass eine einzelne OSD ohne erkennbare Hardwareprobleme hängen bleibt?
• Ist ein solches Verhalten in Verbindung mit unserer Proxmox- bzw. Ceph-Version bekannt?

PVE Version 9.2.3, Ceph Version Squid

 

[LnxBil]

Ich nehme an ihr habt keine Support-Subskription, da ihr hier im Forum postet?

Generell bitte wie immer pveversion -v in CODE tags posten.

 

[Falk R.]

Wir bitten um Unterstützung bei folgenden Fragen:

• Welche Ursachen können dazu führen, dass eine einzelne OSD ohne erkennbare Hardwareprobleme hängen bleibt?
• Ist ein solches Verhalten in Verbindung mit unserer Proxmox- bzw. Ceph-Version bekannt?

PVE Version 9.2.3, Ceph Version Squid

Ich hätte auch erst einmal auf den Support von Proxmox verwiesen, der sehr gut ist.

Das sollte nicht passieren und habe ich noch nie gesehen. Ich habe schon ein paar Crashes von OSDs gesehen und die haben nie Auswirkungen gehabt.
Wenn es sich durch einen Neustart beheben lässt, liegt es garantiert nicht an der Disk sondern am Deamon.
Wenn ein Dienst Hängen Bleibt und alles herunter zieht, klingt nach Designfehler. Es könnte an CPU oder Netzwerk liegen was sich am leichtesten erklären lässt, aber es sind auch andere Ursachen möglich.
Ohne den Cluster und das ganze Design im Detail zu kennen, kann dir niemand sagen woran es liegt.

 

[Winet.maier]

Ich hätte auch erst einmal auf den Support von Proxmox verwiesen, der sehr gut ist.

Das sollte nicht passieren und habe ich noch nie gesehen. Ich habe schon ein paar Crashes von OSDs gesehen und die haben nie Auswirkungen gehabt.
Wenn es sich durch einen Neustart beheben lässt, liegt es garantiert nicht an der Disk sondern am Deamon.
Wenn ein Dienst Hängen Bleibt und alles herunter zieht, klingt nach Designfehler. Es könnte an CPU oder Netzwerk liegen was sich am leichtesten erklären lässt, aber es sind auch andere Ursachen möglich.
Ohne den Cluster und das ganze Design im Detail zu kennen, kann dir niemand sagen woran es liegt.

Da wir keinen Supportvertrag haben, wenden wir uns ja an die Community. Ich bin jedoch überzeugt, dass so was eigentlich nicht passieren dürfte. Unsere Systeme sind alle aktuell und gut gepflegt. Ceph gilt ja als extrem robust und fehlertolerant. Deshalb ist es umso schlimmer, dass eine OSD den ganzen Cluster in Mitleidenschaft ziehen kann.
Wir werden das beobachten und ich halte Euch auf dem Laufenden.

 

[Falk R.]

Da wir keinen Supportvertrag haben, wenden wir uns ja an die Community. Ich bin jedoch überzeugt, dass so was eigentlich nicht passieren dürfte. Unsere Systeme sind alle aktuell und gut gepflegt. Ceph gilt ja als extrem robust und fehlertolerant. Deshalb ist es umso schlimmer, dass eine OSD den ganzen Cluster in Mitleidenschaft ziehen kann.
Wir werden das beobachten und ich halte Euch auf dem Laufenden.

Mit beobachten wirst du auch nicht weiter kommen.
Ich gehe stark davon aus, dass es irgend ein kleiner Sizing/Konfigurationsfehler ist.
Ich habe schon Kunden gesehen, die beim POC mit aller Macht versucht haben das Ceph kaputt zu machen und das lief einfach so wie geplant, aber ich habe auch schon schlechte Sizings gesehen wo der komplette Ceph Cluster ausgefallen ist. Am Ende wegen Kleinigkeiten die nicht beachtet wurden beim Design.
Am besten holst du dir einmal professionelle Hilfe von einem Dienstleister oder buchst eine Subscription.

 

[Winet.maier]

Mit beobachten wirst du auch nicht weiter kommen.
Ich gehe stark davon aus, dass es irgend ein kleiner Sizing/Konfigurationsfehler ist.
Ich habe schon Kunden gesehen, die beim POC mit aller Macht versucht haben das Ceph kaputt zu machen und das lief einfach so wie geplant, aber ich habe auch schon schlechte Sizings gesehen wo der komplette Ceph Cluster ausgefallen ist. Am Ende wegen Kleinigkeiten die nicht beachtet wurden beim Design.
Am besten holst du dir einmal professionelle Hilfe von einem Dienstleister oder buchst eine Subscription.

Wir haben professionelle Leute bei uns, wir sind keine Bastler!

 

[cwt]

Wir haben professionelle Leute bei uns, wir sind keine Bastler!

Das hat niemand im Thread behauptet. Es gibt hier glaube ich keinen im Forum, der zu speziellen Fragen nicht schon mal den Support eines Herstellers bemühen musste. Dafür ist IT einfach zu komplex, egal wie breit der Wissensstand ist. Man bricht sich dabei keinen Zacken aus der Krone.

Und zum eigentlichen Problem: wie @LnxBil und @Falk R. schon schrieben - ohne das Design bzw. die Topologie zu kennen, kann keiner Marke Glaskugel verlässlich Aussagen treffen.

Ohne konkrete Ceph-Version, OSD-Anzahl, Pool-Konfiguration, CRUSH-Struktur, Hardwaretopologie und aussagekräftige Logs ist eine seriöse Ursachenanalyse praktisch nicht möglich. Die Tatsache, dass die SSD laut SMART unauffällig ist und nur zu etwa 50 % belegt war, schließt ein Storageproblem keineswegs aus. SMART erkennt längst nicht alle Fehler. Auch eine SSD ohne SMART-Auffälligkeiten kann aufgrund von Firmwareproblemen, internen Timeouts, PCIe-/Controller-Problemen oder kurzzeitigen Latenzspitzen eine OSD zum Stillstand bringen.

 

[Falk R.]

Wir haben professionelle Leute bei uns, wir sind keine Bastler!

Was hat diese Aussage mit dem Problem zu tun? Auch ich bin zwar Profi, kann dir aber keinen Mailserver aufsetzen. Jeder hat seine Stärken und wenn du "den" Ceph Spezialisten im Team hättest, dann hättest du hier nicht gefragt.

Ich mache ständig Designs neuer Umgebungen und musste einige Installationen von Dienstleistern, die angeblich nichts anderes machen als Ceph, troubleshooten müssen, welche auch keine Bastler sind.

 

[gurubert]

Sind die OSDs mit Version 19 erstellt worden?

https://docs.clyso.com/docs/kb/known-bugs/squid/

Wobei in der Fehlerbeschreibung kein Hängen sondern ein Crash erwähnt wird.

 

[florian-n]

Wir betreiben einen Proxmox-VE-Cluster mit 9 Hosts, insgesamt rund 800 CPU-Kernen und 8 TB Arbeitsspeicher. Als Storage setzen wir einen NFS-Storage auf Basis von Jovian DSS sowie einen Ceph-Cluster mit ca. 30 TB nutzbarem Speicher ein.


Innerhalb des letzten Monats ist das gleiche Problem bereits zweimal aufgetreten.


In beiden Fällen ist jeweils eine einzelne OSD hängen geblieben bzw. nicht mehr reagiert. Dadurch wurde der gesamte Ceph-Cluster nahezu vollständig blockiert und war praktisch nicht mehr nutzbar.


Leider ist es mir in beiden Fällen nicht gelungen, die entsprechenden Fehlermeldungen oder Logs zu sichern, bevor ich die betroffene OSD neu gestartet habe.


Auffällig ist, dass nicht dieselbe OSD betroffen war, sondern bei jedem Vorfall eine andere OSD. Das Problem scheint daher nicht auf eine einzelne Festplatte oder OSD beschränkt zu sein.


Die Behebung war jeweils identisch:

• Die betroffene OSD wurde beendet bzw. neu gestartet.
• Unmittelbar danach arbeitete der gesamte Ceph-Cluster wieder ohne erkennbare Probleme.

Die Auswirkungen auf unsere virtuellen Maschinen waren jedoch erheblich. Insbesondere mehrere Windows-Server-VMs reagierten auf den Storage-Ausfall mit einer extrem hohen CPU-Auslastung und wurden schließlich instabil bzw. stürzten ab.


Die zugrunde liegende SSD der betroffenen OSD wurde überprüft. Es wurden weder SMART-Fehler noch andere Auffälligkeiten festgestellt. Die SSD war zum Zeitpunkt des Vorfalls lediglich zu etwa 50 % ausgelastet, sodass wir derzeit nicht von einem Hardwaredefekt ausgehen.


Wir bitten um Unterstützung bei folgenden Fragen:

• Welche Ursachen können dazu führen, dass eine einzelne OSD ohne erkennbare Hardwareprobleme hängen bleibt?
• Ist ein solches Verhalten in Verbindung mit unserer Proxmox- bzw. Ceph-Version bekannt?

PVE Version 9.2.3, Ceph Version Squid

Hallo @Winet.maier ,

auf den ersten Blick sehe ich hier zwei Probleme:

1. Die OSD muss neu gestartet werden (ist mir in der Praxis noch nie vorgekommen) und
2. der Cluster bleibt "stehen" sobald eine OSD vom Netz geht.

Um letzteres wirklich beurteilen zu können, ist es wichtig mehr über den Aufbau zu wissen, insbesondere zu den PGs (Placement Groups) und den OSDs.

Generell müssen verschiedene Faktoren in Betracht gezogen werden, um einen Stillstand zu erklären. Was beispielsweise sein kann, dass eine Anzahl minimaler Placements (min_size) definiert wurde, die erst wiederhergestellt werden muss, bevor die PG allgemein wieder genutzt werden kann.

Zu deinem ersten Problem empfehle ich dringend die Logs zu prüfen - meiner Erfahrung nach ist es sehr wichtig, dass Ceph exklusiven und direkten Zugriff auf die OSDs hat, also kein Hardware-Raid dazwischen und auch keine anderen Prozesse, die irgendwelche Sachen machen.

Melde dich gerne wenn du das Thema weiter diskutieren magst, ich freu' mich dazuzulernen - Florian

 

[Falk R.]

Ich würde auch das Netzwerk nicht vernachlässigen. Hängende OSDs kenne ich nur von defekten Switches die das LACP nicht mehr sauber bedienen und zu viele Pakete verloren gehen oder fehlerhafte Konfigurationen die zu ähnlichen Phänomenen führen.
Selbst in Testumgebungen mit RAID Controller habe ich es noch nicht geschafft eine OSD zum hängen zu bekommen.

 

[florian-n]

Falk hat absolut recht - Netzwerkprobleme können zu einer OSD-degradierung (OSD = out) führen, die nur manuell aufgelöst werden kann. Siehe https://docs.ceph.com/en/latest/rados/configuration/mon-osd-interaction

Ursachen hierfür kann sein, dass der CEPH-Traffic nicht über dedizierte Netzwerkports läuft und deshalb beispielsweise die Bandbreite abgegraben wird. Aber das ist reine Spekulation.

Ich meine das ist sowieso eine potenzielle Achillesferse eines HCI HA-Clusters: es ist mE unerlässlich mindestens drei dedizierte physikalische Netzwerkports für Corosync, Ceph und App-Traffic zu haben, um zu verhindern, dass bspw. gestörter Corosync-Traffic zu einer ungewollten Migration führt, die dann den Ceph-Traffic lahmlegt und umgekehrt.