Komplexe OSD-Ausfälle

Wie bereits erwähnt sind die angenehmen Situationen freilich die, in denen es dem Admin schnell gelingt, die verlorengegangenen OSDs wieder in den Cluster zu integrieren. Das klappt aber nicht immer – insbesondere dann, wenn Platten tatsächlich kaputtgegangen sind. Erwischt es in der Standardkonfiguration die beiden Platten, welche die Replikas der gleichen Placement Group hatten, so ist diese Placement Group nach Ceph-Definition verloren – wenn sie nicht von irgendwoher in Form eines Backups wiederherstellbar ist. Ceph ist per Default so konfiguriert, dass es bei Zugriffsversuchen auf unvollständige PGs nicht unmittelbar einen Fehler zurückgibt, sondern den I/O-Vorgang blockiert. Falls der Admin die Daten doch noch irgendwo auftreibt, könnte er sie also jederzeit wieder in den Cluster übernehmen. Besteht hierauf keine Hoffnung, tut der Admin gut daran, das OSD für »lost« zu erklären. Dazu muss er zunächst natürlich wissen, welche OSDs es getroffen hat: Wieder kommt die Ausgabe von »ceph -w« zur Hilfe, denn die verrät, welche Placement-Gruppen »down« sind. Ist sich der Admin sicher, dass eine Placement-Gruppe nicht wiederherstellbar ist, sorgt der Befehl

ceph pg PG-ID mark_unfound_lost revert

dafür, dass der Cluster davon erfährt. Wer gleich ein ganzes OSD für tot erklären möchte, tut das mit dem Befehl »ceph osd lost ID« . Beide Schritte gehen mit dem dauerhaften Verlust von Daten einher, doch sind es die gleichen Befehle, die den Cluster wieder in einen funktionierenden Zustand versetzen.

Zur Erinnerung: Ceph sorgt auf der Ebene der Monitoring-Server mittels eines Paxos-Algorithmus dafür, dass keine Split-Brain-Situationen entstehen. Als Split Brain bezeichnen Admins im Cluster-Kontext üblicherweise Szenarien, bei denen ein eigentlich repliziertes Storage in mehrere Teile zerfällt und Clients von außen auf die unterschiedlichen Teile des gleichen Speichers in unkoordinierter Weise gleichzeitig schreibend zugreifen. Die beiden Replikas des Clusters, die eigentlich stets synchron sein sollten, entwickeln sich in divergierender Art und Weise, und letztlich kann der Admin nur einen der beiden Datensätze retten – es sei denn, er fügt sie händisch wieder zusammen. Ceph wirkt solchen Szenarien durch eine Quorums-Entscheidung entgegen.

Die Sache mit dem Quorum

Die funktioniert so: Permanent reden sämtliche Monitoring-Server bei normalem Cluster-Betrieb miteinander. Sie stellen so fest, wieviele andere Monitoring-Server noch vorhanden sind. Erreicht ein Verbund von mehreren Monitoring-Servern mehr als die Hälfte der im Cluster insgesamt vorhandenen MONs, gilt er als »quorat« .

Im Normalfall ist ein Ceph-Cluster eine einzige, sogenannte Cluster-Partition. Solange das der Fall ist, ist alles in bester Ordnung – problematisch wird es erst in dem Moment, in dem die Monitoring-Server untereinander zwar die Verbindung verlieren, aber selbst nicht ausfallen. Das kann beispielsweise passieren, wenn die Netzwerk-Hardware, die die Knoten miteinander verbindet, ausfällt. Die Cluster-Knoten sehen sich dann gegenseitig nicht mehr. Sieht ein Monitoring-Server nur noch die Hälfte der insgesamt vorhandenen anderen MONs oder weniger, erklärt er sich für funktionsuntüchtig, weil er nicht mehr quorat ist.

Die zugreifenden Clients merken das sofort: Damit ein Client in Ceph überhaupt auf die OSDs schreiben kann, muss er sich ja zunächst im Vorfeld bei einem MON-Server über den Zustand des Clusters erkundigen, bevor er direkt mit den OSDs kommuniziert. Trifft er dabei auf einen nicht-quoraten MON, schickt der ihn weg ( Abbildung 4 ). In diesem Vorgang liegt die Erklärung eines eigenartigen Effekts, den Ceph-Admins immer wieder beobachten, ohne sich zunächst einen Reim darauf machen zu können: Wenn ein »ceph health« oder ein »ceph -w« oder auch der direkte Zugriff über einen Client nicht funktioniert und nicht unmittelbar eine Fehlermeldung liefert, sondern einfach gar nichts passiert – dann liegt das in der Regel daran, dass der Client nach einem aktiven MON sucht. Wenn ein Effekt wie der beschriebene im Ceph-Cluster auftritt, schadet also eine kurze Analyse der aktuellen Netzwerksituation nicht – oft genug lässt sich so schon das Problem beheben.