Sonderfall DRBD

Häufig kombinieren Admins Pacemaker mit DRBD. Die Lösung für replizierten Storage nimmt in Pacemaker eine Sonderrolle ein: Sie nutzt die Master-Slave-Ressourcen, sodass sie auf beiden Knoten eines Clusters DRBD verwalten kann, egal ob sich eine DRBD-Ressource gerade im »Primary« - oder »Secondary« -Modus befindet.

Das Master-Slave-Setup findet sich in der Pacemaker-Konfiguration in Gestalt einer »ms« -Regel, die eine Referenz auf die eigentliche DRBD-»primitive« -Ressource hält. Um zu funktionierenden Monitoring-Operationen zu gelangen, gilt es, einen Sonderfall zu beachten: Die »monitor« -Operation für eine »primitive« -Ressource, auf die eine »ms« -Regel verweist, sieht folgendermaßen aus:

op monitor interval="30s" role="Slave"
op monitor interval="25s" role="Master"

Für die Rollen »Master« und »Slave« sind also jeweils eigene Operationen für »monitor« notwendig. Sinnvoll ist es, die »Master« -Rolle etwas häufiger zu prüfen als die »Slave« -Rolle. Keinesfalls dürfen die beiden Intervalle identisch sein, denn dann würde die »monitor« -Operation nicht funktionieren.

Thresholds

Pacemaker kennt ein Konzept namens Migration Threshold. Gemeint ist der Vorgang, eine Ressource auf einem Clusterknoten nach einem Absturz nicht mehr zu starten, wenn ihr dort bereits eine bestimmte Anzahl von Abstürzen nachgewiesen ist. In einem solchen Falle würde der Clustermanager dann sein Glück auf einem anderen Clusterknoten versuchen.

Das Feature ist praktisch für verschiedene Dienste, zum Beispiel Datenbanken: Stürzt MySQL auf einem Server mehrere Male ab, weil der RAM der Maschine kaputt ist, bringt es nichts, die Datenbank dort wieder und wieder zu starten. Über den »migration-threshold« -Parameter lässt sich der Vorgang abkürzen. Doch bevor der Threshold-Parameter selbst ins Spiel kommt, ist auf der CRM-Shell in dem »configure« -Abschnitt noch der Block mit »property« um die folgende Zeile zu erweitern:

cluster-recheck-interval="5m"

Dies sorgt dafür, dass der Clustermanager nicht nur bei irgendwelchen Ereignissen eingreift, sondern dass er regelmäßig alle 5 Minuten den Zustand des gesamten Clusters überprüft – Monitor-Anweisungen ausgenommen, die ihre eigenen Intervalle haben.

Um für eine Ressource dann den Threshold zu aktivieren, braucht die Ressource noch den folgenden Eintrag:

meta migration-threshold=2
failure-timeout=60s

In diesem Falle würde Pacemaker den Dienst nach zwei Abstürzen auf einen anderen Clusterknoten verschieben und es nach 60 Sekunden dem Dienst wieder erlauben, auf dem ursprünglichen Clusterknoten zu laufen. Statt »60s« ist hier auch die Angabe von Minuten möglich. »1440m« würde dafür sorgen, dass die Ressource einen ganzen Tag nicht auf dem kaputten Knoten laufen darf, es sei denn, der Admin greift händisch ein.