Welcher Zustand auf welchem Clusterknoten?

Master-Slave-Setups sind als Funktion in Pacemaker seit einiger Zeit vorhanden, werden aber bisher fast ausschließlich von DRBD verwendet. Sie tragen dem Umstand Rechnung, dass eine Ressource nicht automatisch auf einem Clusterknoten gestartet und auf dem anderen Clusterknoten gestoppt sein muss. Bei einem DRBD-Laufwerk ist das so: Die Ressource ist im Normalfall auf beiden Clusterknoten gestartet, hat aber auf den einzelnen Knoten jeweils unterschiedliche Zustände – nämlich »Primary« und »Secondary« . Um mit DRBD sinnvoll arbeiten zu können – Stichwort Rollentausch – muss Pacemaker wissen, welchen Zustand die Ressource auf welchem Knoten hat. Genau hier kommen die erwähnten Master-Slave-Setups ins Spiel.

DRBD fit für Pacemaker

Das folgende Beispiel geht davon aus, dass ein Cluster mit Pacemaker vorhanden ist, der anhand der Anleitung im ersten Workshop-Teil bereits grundlegend konfiguriert ist. Die CRM-Shell ist das Mittel der Wahl, um eine DRBD-Ressource in Pacemaker zu konfigurieren. Mittels »crm configure « öffnet sich das Konfigurationsmenü der CRM-Shell. Die Ressource gelangt so in die CIB:

primitive res_drbd_mysql ocf:linbit:drbd \
params drbd_resource="mysql" \
op monitor interval="10s" role="Master" \
op monitor interval="20s" role="Slave" \
op start interval="0" timeout="240" \
op stop interval="0" timeout="240"

Der Code scheint komplizierter als er ist:

• »primitive« legt fest, dass es um eine normale Ressource des Typs »primitive« geht, um welche die Clusterkonfiguration wächst.
• »res_drbd_mysql« bezeichnet den Namen der Ressource in Pacemaker.
• »ocf:linbit:drbd« bezeichnet den Resource-Agent der Ressource; es handelt sich um einen Agent der OCF-Klasse vom Anbieter »linbit« mit dem Namen »drbd« .

Die Zeile mit »params« legt die Parameter für die Ressource fest. Grundsätzlich braucht der DRBD-Resource-Agent nur den Namen der Ressource, wie er in der Konfigurationsdatei derselben steht – im Beispiel also »mysql« .

Die beiden Zeilen mit »op monitor« am Anfang definieren wie gehabt Monitoring-Operationen, die Pacemaker in regelmäßigen Abständen dazu bringen, den Zustand der Ressource zu überprüfen. Zwei Operationen sind nötig, weil sich die Intervalle für die Einträge »Master« und »Slave« bei »role« unterscheiden müssen. Pacemaker würde sonst die beiden Operationen zusammenlegen und den Parameter »role« ignorieren, was zu unzuverlässigen Resultaten führt.

»op start« und »op stop« legen schließlich längere Timeouts für das Starten und Stoppen der Ressource fest, um Problemen vorzubeugen, wenn einer der Vorgänge länger dauert als erwartet.