Einrichtung der Ressourcen

Nachdem wir in Teil 2 die Grundlagen für den Cluster (Netzwerkkonfiguration, Corosync-Ring) geschaffen haben, können wir uns nun den einzelnen Ressourcen im Cluster zuwenden.

Was sind Ressourcen?

Ressourcen sind im Cluster-Jargon die Teile eines geclusterten Dienstes, welche auf einem oder mehreren Nodes zu laufen haben. Dahinter verbirgt sich mehr als nur der Aufruf von “omd start/stop” – der Cluster hat z.B. dafür zu sorgen, dass die virtuelle IP-Adresse, unter der der Server immer ansprechbar sein soll, immer nur auf einem Node aktiv ist. Das Filesystem, in welche OMD die Laufzeitdaten schreibt, darf bzw. kann nur auf dem Node gemountet werden, auf dem auch der DRBD zum Master promoted ist – und wenn, dann nur nach dem Promoten. Einen solch “atomaren” Bestandteil wie z.b. den Mountvorgang des DRBD-Devices nennt man Ressource. Wie in unserem OMD-Cluster die Ressourcen konstruiert und in Abhängigkeit zueinander gebracht werden müssen, lesen Sie im folgenden Absatz.

Definition von Ressourcen

Pacemaker bietet zur Definition von Ressourcen die komfortable crm-Shell (CRM= Cluster Resource Manager), die sogar die Vervollständigung von Schlüsselwörtern per Tabulator-Taste versteht. Kommandos in der crm-Shell sind immer nur auf einem Node abzusetzen, da die dadurch konfigurierte CIB (Cluster Information Base, eine XML-Datei, die Sie besser gar nicht erst suchen, geschweige denn von Hand editieren) automatisch auf alle Clusternodes repliziert. Starten Sie die crm-Shell:

Durch Eingabe von “configure” gelangen Sie eine Ebene tiefer, um die live-CIB zu konfigurieren, “help” liefert allerlei nützliche Infos, “up” befördert Sie wieder eine Ebene höher, während “quit” die Shell verlässt.

Globale Parameter

Zunächst definieren wir im “configure”-Modus die Parameter, welche für den ganzen Cluster gelten sollen:

Die crm-Shell schluckt so lange alle Kommandos, bis Sie diese committen. Das Schlüsselwort “show” zeigt Ihnen die nun aktuelle Konfiguration:

ping – die erste Cluster-Ressource

Mit ping steht dem Cluster ene einfache aber wirksame Methode zur Verfügung, seine, nennen wir es “Netzwerkgesundheit” festzustellen: verinfacht gesagt, lassen wir jeden Node eine Reihe Hosts im LAN pingen. Der Node mit dem besseren Resultat gewinnt. Würden wir diesen Ping nur als “primitive” definieren, liefe er jeweils nur auf einem Node – deshalb wird der Cluster mit der Direktive “clone” angewiesen, diese Ressource auf allen Nodes laufen zu lassen:

“Multiplier” gehört hier das Augenmerk: mit diesem Wert wird die Anzahl der erfolgreich gepingten Hosts multipliziert. Der hieraus errechnete Score sollte bei jedem Host 3000 betragen (3×1000):

Weil wir uns nicht mit der GUI zufrieden geben, sondern auch auf der Konsole prüfen wollen, wie es dem Cluster geht, rufen wir auf einem der beiden Nodes das Kommando crm_mon auf – achten Sie auf die Scores, die sollten beiden 3000 betragen (bzw. entsprechend der Anzahl der Hosts, die Sie ihren Cluster pingen lassen):

Mit diesem Score werden wir nun Regeln verknüpft werden. Wir möchten, dass der Node, der den „besseren“ Ping-Score hat, gewinnt – alle Ressourcen sollen zu ihm umgezogen werden.

DRBD-Synchronisation

Zunächst werden wir das logical Volume lvomd zum Blockdevice des DRBDs ernennen, sowie ein Filesystem darauf einrichten. Diese Aufgabe nimmt einem die DRBD-MC in so kompakter Weise ab, dass wir diesmal – ausnahmsweise – die Shell meiden:

Im Abschnitt „Storage (DRBD)“ sehen Sie alle Blockdevices der beiden Nodes untereinander. Klicken Sie mit der rechten Maustaste auf das logical volume “lvomd” von nagios1 und wählen Sie

Im folgenden Assistenten definieren wir die DRBD-Ressource “romd” (‘r’ wie ‘resource’, ich bin ein Freund von Prefixen):

• Name: romd
• Device: /dev/drbd0
• Protocol: C/Synchronous
• On io error: detach

Im nächsten Dialog möchte der Assistent wissen, über welche Interfaces Sie das Device synchronisieren möchten. Für Nagios 1 und 2 ist jeweils anzugeben

• Interface: eth1 (10.1.1.10) bzw. (10.1.1.20)
• DRBD Meta disk: internal
• Port: 7788

Im darauffolgenden Fenster wählen wir “Create new meta-data & destroy data” und klicken auf “Create Meta-Data”. Nach einem klick auf “Next” können Sie in der im unteren Bildschirmrand eingeblendeten Kommandozeilen-Leiste sehen, dass DRBD-MC die Ressource bereits mittels “drbdadm up romd” hochgefahren hat.

Klicken wir auf “Next”, und lassen auf der DRBD-Ressource gleich ein ext4-Filesystem erzeugen:

Nach einer Weile ist das Filesystem auf dem Blockdevice erzeugt – und nach einem Click auf „Finish“ sollte das Endresultat sollte in etwa so aussehen:

Wie Sie an der Prozentangabe unter der Verbindungslinie erkennen können, ist die Synchronisation der beiden Devices bereits in vollem Gange. Auf der Shell lässt sich dies überprüfen, in dem Sie ‘/proc/drbd’ per ‘cat’ auslesen:

Wie Sie vielleicht erkennen können, ist die Syncer rate nicht gerade schnell. Der Artikel “Configuring the rate of synchronisation” auf der DRBD-Seite erläutert detailliert, wie man die für sein System passende Syncer rate errechnet. Sie können diesen Wert nun entweder auf beiden Nodes in die Datei “/etc/drbd.d/romd.res” eintragen, oder hierzu einmal die GUI verwenden (=> Optionsleiste auf der rechten Seite), die dies gleich auf beiden Nodes für Sie erledigt:

Derzeit sind beide DRBD-Volumes im Status “secondary”:

Lassen Sie uns nun eine Cluster-Ressource einrichten, die das Volume auf einem Node zum “primary” promoted. Wechseln Sie in die crm-shell und definieren Sie:

Die “primitive”-Deklaration definiert zunächst einmal die Cluster-Ressource vom Typ ocf:linbit:drbd und weist sie an, die DRBD-Ressource “romd” zu verwenden. Alle 5 Sekunden soll der Status überprüft werden. Die “ms”-Deklaration weist pri_drbd_omd als MultiState-Ressource aus, soll heißen: starte die Ressource zwar auf mehreren Nodes, wobei

• im ganzen Cluster nur 1 Master existieren darf (master-max)
• im ganzen Cluster genau zwei Instanzen dieses primitives laufen dürfen (clone-max)
• pro Node nur eine Instanz dieses primitives laufen darf (clone-node-max)
• pro Node nur 1 Master existieren darf (master-node-max)

In der DRBD-MC werden Sie nach dem commit nun unter “Cluster Manager”-”Services” eine neue Ressource entdecken:

Dort, wo DRBD im Status Primary (bzw. die Multistate-Ressource im Status “Master”) läuft, wollen wir außerdem, dass das DRBD-Device gemountet wird. Legen Sie auf beiden Nodes einen Mountpunkt an:

Der Mount-Vorgang ist eine eigene Cluster-Ressource, die Sie in der crm-Shell anlegen:

Und schon zeigt die GUI eine weitere Ressource an:

Falls “crm_mon” meldet, dass die Filesystem-Ressource auf keinem Node gestartet werden konnte…

…sollten Sie prüfen, ob die fuse-utils tatsächlich installiert sind.
Es kann durchaus sein, dass sich die Filesystem-Ressource rot färbt, wenn pacemaker versucht hat, sie vor DRBD zu starten. Das sollte auch nicht verwundern – schließlich liegt das zu mountende Filesystem ja im DRBD. Setzen Sie in diesem Fall den Fehlerzähler der Filesystem-Ressource zurück:

bzw. per Rechtsklick in der GUI > „Reset Fail-Count“. Damit startet Pacemaker einen neuen Versuch, die Ressource – diesmal natürlich erfolgreich mit darunterliegendem DRBD – noch einmal zu starten.
Der aktuelle Zustand ist, das sollte nicht vergessen werden, momentan noch ein „Zufallsprodukt“. Pacemaker muss noch lernen, in welchen Abhängigkeiten die Ressourcen zueinander stehen.

Service-IP

Natürlich wollen wir unseren Cluster nicht je nach aktivem Node mit unterschiedlicher IP-Adresse ansprechen müssen, und spendieren ihm deshalb eine Service-IP, die immer auf dem aktiven Node aktiviert werden soll. Dies bewerkstelligt die Ressource IPaddr2, welche auch gleich noch per ARP-Broadcast veranlasst, dass alle Clients ihren ARP-Cache mit der neuen MAC-Adresse aktualisieren. Die Parameter sollten weitgehend selbsterklärend sein:

Apache2

Der eingangs installierte Apache ist ebenfalls eine Cluster-Ressource, denn er nimmt als Proxy alle Anfragen an und weiß, an welchen der pro Site gestarteten Schwesterprozesse er den Request weiterleiten muss. Stoppen Sie ihn und unterbinden Sie ebenfalls seinen Start wenn das System bootet:

Nun legen wir ihn als Cluster-Ressource an:

Pacemaker überwacht Apache, indem er seine status-Page aufruft. Per regex “body” prüft er, ob eine gültige HTML-Seite zurückgeliefert wird (natürlich können Sie den regex verfeinern).
Wieder ein Blick in die DRBD-MC – Ihr Cluster sollte mittlerweile so aussehen:

Wie Sie sehen, hat Pacemaker die Service-IP auf nagios2 gestartet. Im übernächsten Kapitel werden wir diesem Zustand mit constraints zuleibe rücken und die Ressourcen in ihrer Zusammengehörigkeit und Startreihenfolge so verzurren, dass sie in einem für uns konsistenten Zusammenhang laufen. Zunächst aber wenden wir uns OMD zu, welches wir fürs Clustering vorbereiten müssen.

Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 1
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 2
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 4
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 5
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 6