Fencing verhindert Chaos im Cluster

© © kobra78, Fotolia.com

Eingezäunt

Manchmal hilft nur die Keule: Damit defekte Knoten in einem Pacemaker-Cluster keinen Schaden anrichten, können sie sich gegenseitig ausschalten. Doch Brutalität alleine ist noch nicht die Lösung, ein paar Feinheiten sind von großer Bedeutung.

Das englische Wort Fence steht für Zaun. Im Kontext von Hochverfügbarkeits-clustern bezeichnet es eine Methode, die es einem Knoten des Clusters erlaubt, einen anderen Knoten – notfalls gewaltsam – aus dem Cluster auszugrenzen, um so zu verhindern, dass gleichzeitiger Schreibzugriff auf sensible Daten zu Inkonsistenz führt.

Tut der Cluster, was er soll?

Fencing-Mechanismen sind im Clusterkontext immer dann wichtig, wenn es um die Integrität von Daten einerseits und um die Verfügbarkeit von Diensten andererseits geht. Fencing hat stets den Zweck, durch das Entfernen einzelner Ressourcen oder Knoten aus dem Cluster die Funktionstüchtigkeit des gesamten Clusters zu gewährleisten.

Grundsätzlich geht die Software, die in einem Cluster das Management übernommen hat – im Beispiel also Pacemaker – davon aus, dass ihr die Hoheit über alle Aktionen obliegt, die im Cluster passieren. Pacemaker nimmt an, dass Befehle innerhalb des Clusters ausschließlich von ihm kommen, dass die Kommunikation der Knoten des Clusters reibungslos funktioniert und dass sichergestellt ist, dass die im Cluster konfigurierten Dienste so funktionieren, wie sie sollen.

Fencing muss in einem Cluster dann aktiv werden, wenn einer dieser Punkte nicht mehr erfüllt ist. Wie soll der Clustermanager beispielsweise mit Knoten umgehen, die plötzlich von alleine aus dem Cluster-Verbund verschwinden? Im Ernstfall wäre es durchaus denkbar, dass auf dem verschwundenen Knoten lediglich Pacemaker selbst abgestürzt ist und sich dort nun noch laufende Ressourcen tummeln, auf die Pacemaker aber keinen Einfluss mehr hat. Der auf dem noch funktionierenden Knoten laufende Pacemaker kann in diesem Beispiel seine Vorrechte nur durchsetzen, indem er den anderen Rechner fenced, sprich ihn rebootet. Ähnlich verhält es sich mit Ressourcen, die sich nicht ordnungsgemäß stoppen lassen: Befiehlt Pacemaker beispielsweise MySQL, sich auf einem Knoten zu beenden, erwartet er, dass MySQL genau das tut. Schlägt diese Aktion aber fehl, muss Pacemaker davon ausgehen, dass auf dem jeweils betroffenen Knoten nunmehr ein MySQL-Zombie läuft, der unkontrollierbar ist. Auch dann kann er dem Treiben bloß ein Ende bereiten, indem er den Rechner gewaltsam rebootet.

Fencing-Levels

Wie immer gibt es mehrere Wege nach Rom: Fencing lässt sich in Pacemaker einerseits auf Ressourcen-Ebene durchführen. Wenn die eingesetzte Lösung zur Datenverwaltung diese Option bietet, dann ist das sogenannte Resource Level Fencing die sanftere Methode. Sie zielt darauf ab, dass Pacemaker im Falle eines Falles lediglich eine bestimmte Ressource so konfiguriert, dass Datenkorrumpierung ausgeschlossen ist. In der Praxis relevant ist hier besonders DRBD, das Resource Level Fencing in Kooperation mit Pacemaker beherrscht.

Variante B führt andererseits zum sprichwörtlichen Tabula Rasa: Node Level Fencing versetzt einen Pacemaker-Knoten in die Lage, einen anderen Knoten des Clusters zu rebooten oder auch einen kompletten Shutdown herbeizuführen. Im Cluster-Sprech nennt sich diese Methode STONITH, die Abkürzung für Shoot The Other Node In The Head.

comments powered by Disqus