Wartung, aber richtig

Auch Ceph-Cluster bleiben von regelmäßigen Wartungsaufgaben nicht verschont. Beipielsweise stehen Sicherheits-Updates, OS-Updates und Ceph-Updates regelmäßig an. Weil Ceph per Architektur keinen echten Single Point of Failure (SPOF) hat, ist das aber kein Problem: Jede einzelne Komponente in Ceph ist schließlich ersetzbar.

Für kurze Aufgaben haben die Ceph-Entwickler außerdem eine sinnvolle Zusatzfunktion eingebaut, die im Wartungsfalle greift: Fällt ein OSD aus, schreibt der Cluster es nicht sofort ab.

OSDs haben in Ceph bekanntlich zwei Zustände, die miteinander kombinierbar sind. »Up« und »Down« bezeichnet lediglich, ob das OSD gerade aktiv im Cluster mitarbeitet oder nicht. Hinzu gesellt sich der Zustand eines OSDs im Hinblick auf die Cluster-Replikation, hier existieren »In« und »Out« . Erst wenn Ceph ein OSD als »Out« markiert, greift seine Selbstheilung: Erst dann untersucht Ceph nämlich, ob im Cluster neue Kopien von Replikas zu erstellen sind, weil durch den Ausfall eines OSDs eventuell Replikas verloren gegangen sind. Der Clou: Zwischen dem Zeitpunkt, in dem Ceph ein OSD als Down markiert und dem »Out« -Zustand liegen 5 Minuten. Wenn das nicht reicht, ist der Wert per Konfigurationsdatei auch anpassbar: Der Parameter dafür ist »mon osd down out interval« , der Wert ist in Sekunden angegeben.

Sterbende Platten, Slow Requests

Ein Mantra der Ceph-Entwickler lautet, dass für den Einsatz mit Ceph auch SATA-Platten anstelle der viel teureren SAS-Platten geeignet sind. Soweit, so gut. Wer sich allerdings auf einen Ceph-Cluster mit SATA-Desktop-Platten einlässt, sollte ein Detail wissen: Normale Desktop-Platten sind meist darauf ausgelegt, jeden Fehler wenn irgendwie möglich automatisch zu korrigieren. In dem Augenblick, in dem die Platte einen Fehler bemerkt, beginnt sie also mit dem Versuch, diesen intern auszubügeln.

Bei SATA-Desktop-Platten kann das eine Weile dauern. Greift während eines solchen Vorgangs ein Client auf eine PG auf einem OSD zu, dessen Platte gerade im Recovery-Modus ist, merkt der Client das ebenfalls, weil der Request unter Umständen sehr lange dauert. In »ceph -w« tauchen solche Requests als »Slow Requests« auf. Ganz ähnlich wäre die Situation bei einer Platte, die im Sterben begriffen ist, aber noch nicht so kaputt ist, dass das Dateisystem bereits Fehlermeldungen generiert. Welche Methoden gibt es, den lästigen Slow Requests zu Leibe zu rücken, vor allem solchen auf Hardware-Ebene?

SATA-Enterprise-Platten zeichnen sich durch eine höhere MTBF und eine deutlich schnellere Fehlerkorrektur aus, sind aber auf der anderen Seite auch teurer als ihre Desktop-Kollegen. Wer mit Desktop-Platten arbeiten will, kann im Falle eines Slow Requests aber zumindest punktuell für Abhilfe sorgen: Durch das Kommando »ceph osd out ID« lässt sich ein OSD forciert aus dem Cluster entfernen; für seinen Schreibvorgang würde der Client danach eine Fehlermeldung kassieren und könnte im Anschluss den Vorgang wiederholen. Dabei würde er dann vom MON zu einem anderen OSD geschickt, das hoffentlich funktioniert.