Auf Ubuntu 10.04 und Debian Squeeze sowie auf SLES sind wie erwähnt die "alten" Daemons zu verwenden, die diesen Distributionen beiliegen. Sie finden sich in den Paketen
»gfs-pcmk
«
und
»dlm-pcmk
«
, die auf dem System vorhanden sein sollten. In SLES finden sich die benötigten Pakete über die Paketsuche. Der Artikel geht im Folgenden davon aus, dass DRBD installiert und mindestens eine DRBD-Ressource vorhanden ist.
Diese Ressource sollte so eingerichtet sein, dass sie im Dual-Primary-Modus laufen darf (
Abbildung 1
). Ausgehend von einer "normalen" Ressource, wie sie im Artikel zu DRBD in der HA-Serie
[3]
beschrieben ist, sind in der Konfiguration der Ressource dazu zwei Dinge zu ändern. Einerseits ist dem
»net
«
-Absatz in der Ressourcen-Konfiguration der Eintrag
»allow-two-primaries yes;
«
hinzuzufügen. Andererseits sollte DRBD auch erfahren, was es tun soll, falls eine Split-Brain-Situation eintritt. Das passiert mit
after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect;
ebenfalls im
»net
«
-Absatz der Ressource.Überdies sollte Pacemaker installiert und grundlegend konfiguriert sein. Es sei an dieser Stelle darauf hingewiesen, dass Pacemaker unbedingt über eine funktionierende STONITH-Konfiguration verfügen sollte; nur diese gibt dem Cluster-Manager die Möglichkeit, amoklaufende Cluster-Knoten aus dem Cluster zu schießen. Schließlich setzt der Artikel voraus, dass die vormals erwähnte DRBD-Ressource bereits als solche in Pacemaker konfiguriert ist und als
»ms_drbd_gfs
«
zur Verfügung steht. Zu beachten ist dabei, dass die
»ms
«
-Ressource etwas anders anzulegen ist, als bei einem DRBD, das im Primary-Secondary-Modus läuft:
ms ms_drbd_gfs p_drbd_gfs meta master-max=2 clone-max=2notify=true
Wenn diese Voraussetzungen erfüllt sind, sollte die DRBD-Ressource auf beiden Clusterseiten mit
»drbdadm primary
Ressource
«
in den Modus
»Primary
«
geschaltet werden (
Abbildung 2
).
Dann folgt die Ressourcen-Konfiguration in Pacemaker. Für GFS braucht der Cluster zwei Dienste:
»dlm_controld
«
, der die Kommunikation mit dem Distributed Lock Manager übernimmt, und
»gfs_controld.pcmk
«
, der die Steuerung des GFS2-Daemons übernimmt. Die beiden Dienste werden über den Ressource-Agent
»ocf:pacemaker:controld
«
gesteuert. Die Konfiguration in der CRM-Shell für dieses Beispiel sollte also so aussehen wie in
Listing 1
. Die genannten Einträge sorgen dafür, dass der Pacemaker grundsätzlich weiß, dass die Control-Daemons laufen sollen und dass sie stets auf allen Knoten des Clusters laufen – dies stellen die
»clone
«
-Einträge sicher. Durch die Constraints ist sichergestellt, dass der DLM-Daemon immer bloß dort gestartet wird, wo die jeweilige DRBD-Ressource im Primary-Modus läuft und dass erst im Anschluss an den DLM-Start auch der GFS-Controld startet.
Listing 1
Ressourcen-Konfiguration
Wenn der DLM und der GFS-Controld laufen, dann kann auch das GFS-Dateisystem auf der DRBD-Ressource landen:
sudo mkfs.gfs2 -p lock_dlm -j2 -t pcmk:pcmkRessource
Ressource
ist der Device Node der DRBD-Ressource, zum Beispiel
»/dev/drbd/by-res/disk0/0
«
.
Dann fehlt noch die Dateisystem-Ressource in Pacemaker, die das GFS auf den Clusterknoten mountet.
»ocf:heartbeat:Filesystem
«
kommt mit GFS2 zurecht, die passende Ressourcen-Konfiguration sieht dann so aus wie in
Listing 2
.
Listing 2
GFS2-Dateisystem-Ressource
Die Primitive-Ressource sorgt in Kombination mit dem Clone-Eintrag dafür, dass das Dateisystem auf allen Clusterknoten läuft. Durch die Constraints ist aber festgelegt, dass die Ressourcen nur laufen dürfen, wenn der GFS-Controld einsatzbereit ist.
Nach einem
»commit
«
in der CRM-Shell sollte der Cluster aussehen wie im
Abbildung 3
.