19.6    Dienste hochverfügbar machen

Jetzt können Sie darangehen, eine erste Ressource zu konfigurieren. Die Auswahl ist groß: Pacemaker kann auf vorgefertigte Routinen für fast alle gängigen Ressourcen zurückgreifen. In den nächsten Abschnitten werden Sie sehen, wie Sie diese Routinen nutzen können. Wenn Sie neugierig sind, welche Ressourcen Ihnen zur Verfügung stehen, geben Sie einmal folgendes Kommando ein:

crm ra list ocf

Listing 19.34    Ressourcen-Namespaces anzeigen

Sie erhalten eine längere Liste von OCF-Ressourcen (unter CentOS mit pcs liefert der Befehl pcs resource agents eine ähnliche Ausgabe), die Sie konfigurieren und einsetzen können (OCF steht dabei für Open Cluster Framework, ein Standardisierungsregelwerk für Clusterressourcen):

ASEHAagent.sh       AoEtarget           AudibleAlarm        CTDB
ClusterMon          Delay               Dummy               EvmsSCC
Evmsd               Filesystem          HealthCPU           HealthSMART
ICP                 IPaddr              IPaddr2             IPsrcaddr
IPv6addr            LVM                 LVM-activate        LinuxSCSI
MailTo              ManageRAID          ManageVE            NodeUtilization
Pure-FTPd           Raid1               Route               SAPDatabase
SAPInstance         SendArp             ServeRAID           SphinxSearchDaemon
Squid               Stateful            SysInfo             SystemHealth
VIPArip             VirtualDomain       WAS                 WAS6
WinPopup            Xen                 Xinetd              ZFS
anything            apache              apache.sh           asterisk
attribute           aws-vpc-move-ip     aws-vpc-route53     awseip
awsvip              bind-mount.sh       clusterfs.sh        clvm
conntrackd          controld            db2                 db2.sh
dhcpd               dnsupdate           docker              drbd
drbd.sh             eDir88              ethmonitor          exportfs
fio                 fs.sh               galera              garbd
iSCSILogicalUnit    iSCSITarget         ids                 iface-bridge
iface-vlan          ifspeed             ip.sh               iscsi
jboss               kamailio            ldirectord          lvm.sh
lvm_by_lv.sh        lvm_by_vg.sh        lvmlockd            lxc
minio               mysql               mysql-proxy         mysql.sh
nagios              named               named.sh            netfs.sh
nfsclient.sh        nfsexport.sh        nfsnotify           nfsserver
nfsserver.sh        nginx               o2cb                ocf-shellfuncs
openldap.sh         oraasm              oracle              oracledb.sh
oradg.sh            orainstance.sh      oralistener.sh      oralsnr
ovsmonitor          pgagent             pgsql               ping
pingd               portblock           postfix             postgres-8.sh
pound               proftpd             rabbitmq-cluster    redis
remote              rkt                 rsyncd              rsyslog
samba.sh            script.sh           scsi2reservation    service.sh
sfex                sg_persist          slapd               smb.sh
svclib_nfslock      symlink             syslog-ng           tomcat
tomcat-5.sh         tomcat-6.sh         varnish             vm.sh
vmware              vsftpd              zabbixserver

Listing 19.35    Verfügbare OCF-Ressourcen

Als erste Ressource benötigen Sie eine IP-Adresse, an die Sie später einen hochverfügbaren Dienst binden können.

19.6.1    Die erste Ressource: eine hochverfügbare IP-Adresse

Da die IP-Adresse, die wir hier als Ressource definieren wollen, zwischen den Knoten »wandern« kann, darf sie natürlich nicht auf einem der beiden Knoten bereits in Benutzung sein. Für das Beispiel muss die IP-Adresse 10.0.0.10 herhalten. Da wir ja schon über einen lauffähigen Cluster verfügen, genügt es im Übrigen, diese Konfiguration auf einem Knoten durchzuführen.

So konfigurieren Sie die Ressource auf der Kommandozeile:

### Debian/Ubuntu/openSUSE Leap
crm configure primitive myMIP ocf:heartbeat:IPaddr2 params ip=10.0.0.10 \
cidr_netmask=32

### CentOS
pcs resource create myMIP ocf:heartbeat:IPaddr2 ip=10.0.0.10 cidr_netmask=32

Listing 19.36    IP-Adresse als Ressource hinzufügen

Geben Sie den Befehl auf einer Zeile ohne den Backslash ein. Der Name der Ressource ist frei wählbar, solange Sie auf Umlaute und Leerzeichen verzichten. Das »MIP« in myMIP steht hier für Migrating IP, also »wandernde IP-Adresse«. In der Ausgabe von crm status sehen Sie, dass die Adresse bereits aktiv ist:

[…]
2 nodes configured
1 resource configured

Online: [ node1 node2 ]

Full list of resources:

 myMIP	(ocf::heartbeat:IPaddr2):	Started node1

Listing 19.37    Die IP-Ressource ist aktiv.

Hier können Sie auch erkennen, auf welchem Clusterknoten die IP-Adresse gerade beheimatet ist: Started node1.

Wenn Sie diesen Knoten jetzt auf Standby schalten, migriert die Ressource automatisch auf den zweiten Knoten:

### Debian/Ubuntu/openSUSE Leap
root@node2:~# crm node standby node1 && sleep 1 && crm status
### CentOS
[root@node2 ~]# pcs cluster standby node1 && sleep 1 && pcs status

### Ausgabe:
Node node1: standby
Online: [ node2 ]

Full list of resources:

 myMIP	(ocf::heartbeat:IPaddr2):	Started node2

Listing 19.38    Knoten im Standby: Die Ressource migriert.

Die Ressource starten, stoppen und migrieren

Wenn Sie eine Ressource zeitweilig deaktivieren möchten, lautet der passende Befehl crm resource stop <RESOURCE>[ 25 ].

### Ressource myMIP stoppen ...
# Debian/Ubuntu/openSUSE Leap
crm resource stop myMIP

# CentOS
pcs resource disable myMIP

### ... und wieder starten
#Debian/Ubuntu/openSUSE Leap
crm resource start myMIP

# CentOS
pcs resource enable myMIP

Listing 19.39    Eine Ressource stoppen und wieder starten

Sie können eine Ressource anweisen, auf einen anderen Knoten umzuziehen. Am Beispiel der Ressource myMIP lautet das Kommando dazu:

# Debian/Ubuntu/openSUSE Leap
crm_resource --resource myMIP --move

# CentOS
pcs resource move myMIP

Listing 19.40    Die Ressource »myMIP« zur Migration zwingen

Migration ohne Wiederkehr

Der Knoten, auf dem die Ressource bisher lief, ist nach der Zwangsmigration für sie tabu. Die Ressource würde nicht einmal auf diesen Knoten zurückmigrieren, wenn er der letzte verbleibende Node im Cluster wäre.

Um die Rückmigration wieder zu erlauben, geben Sie das folgende Kommando ein:

# Debian/Ubuntu/openSUSE Leap
crm_resource --resource myMIP --un-move

# CentOS
pcs constraint remove cli-ban-myMIP-on-<NODE>

Listing 19.41    Rückmigration der Ressource erlauben

Wenn Sie einen Cluster mit einer größeren Zahl von Knoten haben, können Sie die Ressource anweisen, auf einen bestimmten Knoten zu migrieren. Im folgenden Beispiel ist das Node2:

# Debian/Ubuntu/openSUSE Leap
crm_resource --resource myMIP --move --node node2

# CentOS
pcs resource move myMIP node2

Listing 19.42    Ressource auf einen bestimmten Knoten migrieren

Unnötige Rückmigrationen verhindern

Nach einem Ausfall und der dadurch bedingten Migration der Ressourcen kann es sinnvoll sein, die Ressourcen nicht wieder zurückzumigrieren, sondern sie in ihrer neuen Heimat zu belassen. Das liegt daran, dass jeder Umzug mit einem gewissen Aufwand verbunden ist. Dieser Aufwand ist für manche Ressourcen, etwa eine IP-Adresse, vernachlässigbar gering, aber im Falle einer großen Datenbank kann die Rückmigration eine Zeit lang dauern.

Um die Rückmigration zu verhindern, passen Sie die Resource Stickiness an. Sie ist ein Gradmesser für den Aufwand, den eine Migration für das System bedeutet, und steht per Default auf dem Wert 0 (Null). Erhöhen Sie diesen Wert, so scheut Pacemaker vor der Migration zurück, solange kein zwingender Grund dafür vorliegt.

Ein zwingender Grund ist zum Beispiel der Ausfall eines Knotens oder ein direktes Kommando des Administrators. So ändern Sie den Default-Wert für die Resource Stickiness: 

# Debian/Ubuntu/openSUSE Leap
crm configure rsc_defaults resource-stickiness=100

# CentOS
pcs resource defaults resource-stickiness=100

Listing 19.43    Resource Stickiness erhöhen

19.6.2    Hochverfügbarkeit am Beispiel von Apache

Ihre erste Ressource, die IP-Adresse 10.0.0.10, ist jetzt konfiguriert, aber das ist natürlich noch nicht abendfüllend. Als Nächstes erweitern Sie den Cluster um einen ApacheWebserver, der auf Ihre Cluster-IP-Adresse »hört«.

Installieren Sie, falls es bisher noch nicht geschehen ist, den ApacheWebserver, und ändern Sie in der Konfigurationsdatei /etc/apache2/ports.conf unter Debian und Ubuntu, in /etc/apache2/listen.conf unter openSUSE Leap und in /etc/httpd/conf/httpd.conf unter CentOS, die Zeile Listen 80. Diese sollte anschließend so aussehen wie in Listing 19.44:

#vorher:
Listen 80

#nachher:
Listen 127.0.0.1:80
Listen 10.0.0.10:80

Listing 19.44    Apache auf die Cluster-IP- und »localhost«-Adresse konfigurieren

Wenn Sie Apache jetzt testweise auf beiden Knoten manuell (neu) starten, wird er auf einem Knoten funktionieren und auf dem anderen nicht – weil natürlich nur einer von beiden die Adresse 10.0.0.10 aktiviert haben kann.

Zusätzlich muss sichergestellt sein, dass das Modul status aktiviert ist und der Zugriff von 127.0.0.1 erlaubt ist; unter Debian und Ubuntu ist dies der Standard. Unter openSUSE Leap müssen Sie den Befehl a2enmod status ausführen.

Stoppen Sie auf beiden Knoten den Apache wieder (systemctl stop apache2), und entfernen Sie ihn aus dem automatischen Start (Runlevel) mittels systemctl disable apache2, denn das Starten und Stoppen des Dienstes soll von nun an Pacemaker übernehmen.

Debian/Ubuntu

Konfigurieren Sie mit dem folgenden Befehl auf einem Ihrer Clusterknoten die Apache-Ressource. Der Befehl steht eigentlich in einer einzigen Zeile, wurde aber hier aus Platzgründen mit »\« umbrochen:

daniel@node1:~$ sudo crm configure primitive Webserver \
ocf:heartbeat:apache \
params configfile=/etc/apache2/apache2.conf \
statusurl="http://localhost/server-status" \
op monitor interval=1m

Listing 19.45    Webserver-Ressource zur Clusterkonfiguration hinzufügen

Wenn Sie sich nun die Ausgabe von crm status anzeigen lassen, gibt es zwei Möglichkeiten. Hier sehen Sie die erste Möglichkeit:

[…]
 myMIP  (ocf::heartbeat:IPaddr2):       Started node1
 Webserver      (ocf::heartbeat:apache):        Started node1

Listing 19.46    Cluster mit zwei Ressourcen

Der Webserver wurde, wie die IP-Adresse, auf Node1 gestartet und konnte deshalb seine Arbeit aufnehmen.

Die zweite Möglichkeit ist, dass Sie eine Fehlermeldung sehen. In diesem Fall hat Pacemaker versucht, den Apache auf dem Knoten zu starten, auf dem die IP-Adresse myMIP gerade nicht lief. Pacemaker weiß noch nicht, dass der Apache nur in Kombination mit der IP-Adresse auf dem gleichen Knoten sinnvoll einsetzbar ist.

CentOS

Bevor Sie die Clusterressource anlegen, müssen Sie noch eine Besonderheit von CentOS ausgleichen. Die Ressource prüft nämlich den Status des ApacheWebservers und setzt dafür das Apache-Modul mod_status voraus. Dieses wird zwar von CentOS standardmäßig geladen, allerdings ohne Konfiguration. Um dies zu ändern, erzeugen Sie die Datei /etc/httpd/conf.d/status.conf mit dem Inhalt aus Listing 19.47:

<Location /server-status>
   SetHandler server-status
   Order Deny,Allow
   Deny from all
   Allow from 127.0.0.1
</Location>

Listing 19.47    Inhalt der Datei »/etc/httpd/conf.d/status.conf«

Nun kann die Clusterressource erzeugt werden. Führen Sie dafür den nachstehenden Befehl in einer Zeile aus:

daniel@node1:~$ sudo pcs resource create Webserver \
ocf:heartbeat:apache \
configfile=/etc/httpd/conf/httpd.conf \
statusurl="http://localhost/server-status" \
op monitor interval=1m

Listing 19.48    Webserver-Ressource zur Clusterkonfiguration hinzufügen

Bitte beachten Sie, dass Sie bei der Übersetzung von Befehlen von crmsh nach pcs nicht nur die Pfadekorrektur vornehmen, sondern auch die Direktive params entfernen müssen.

openSUSE Leap

Leider besteht ein Bug in der von openSUSE Leap ausgelieferten OCF-Ressource. Wenn zusätzliche Parameter übergeben werden, verhindert dieser Bug, dass sie korrekt genutzt werden. Da standardmäßig aber bereits der Pfad zur Konfigurationsdatei und auch die Prüfung des Status enthalten sind, ist dies kein Problem. Führen Sie einfach den folgenden Befehl aus, um die Clusterressource zu erstellen:

daniel@leap:~> sudo crm configure primitive Webserver \
ocf:heartbeat:apache \
op monitor interval=1m

Listing 19.49    Webserver-Ressource zur Clusterkonfiguration hinzufügen

Constraints: Abhängigkeiten im Cluster

Pacemaker muss lernen, dass die Ressource Webserver von der Ressource myMIP abhängig ist. Webserver kann nur gestartet werden, wenn myMIP auf dem gleichen Knoten läuft. Und nicht nur das: Die IP-Adresse muss auch bereits gestartet sein, bevor Apache an der Reihe ist. Es gibt also zwei Abhängigkeiten:

  1. Die Ressourcen dürfen nicht auf unterschiedlichen Knoten gestartet werden. Wird eine Ressource migriert, muss automatisch auch die andere umziehen.

  2. Eine Ressource (myMIP) muss immer vor der anderen (Webserver) gestartet werden.

Damit Pacemaker diese Abhängigkeiten beachtet, definieren Sie Constraints. Das sind Abhängigkeitsregeln, mit denen Sie Pacemaker die Beziehungen der einzelnen Ressourcen zueinander erklären.

Für die Regel, dass beide Ressourcen immer auf dem gleichen Clusterknoten laufen sollen, erstellen Sie einen Colocation-Constraint. Damit die IP-Adresse immer vor dem Webserver gestartet wird, benötigen Sie einen Order-Constraint. Beginnen Sie zunächst mit dem Colocation-Constraint:

# Debian/Ubuntu/openSUSE Leap
crm configure colocation WebserverMitIPAdresse INFINITY: Webserver myMIP

#CentOS
pcs constraint colocation add Webserver myMIP INFINITY

Listing 19.50    Colocation-Constraint

Der Constraint erhält einen eigenen, möglichst sprechenden Namen, im Beispiel lautet er WebserverMitIPAdresse. Danach konfigurieren Sie, wie stringent Pacemaker diese Regel handhaben soll. Das Schlüsselwort INFINITY bedeutet dabei, dass keine Ausnahme zulässig ist. Hinter dem Doppelpunkt stehen die Namen der Ressourcen, für die der Constraint gelten soll, in beliebiger Reihenfolge. Jetzt kommt der Order-Constraint an die Reihe:

# Debian/Ubuntu/openSUSE Leap
crm configure order IPAdresseVorWebserver mandatory: myMIP Webserver

# CentOS
pcs constraint order myMIP then Webserver

Listing 19.51    Order-Constraint

Hier übergeben Sie unter Debian, Ubuntu und openSUSE Leap nach dem Doppelpunkt die Ressourcen in der Reihenfolge, in der Pacemaker sie starten soll. Auf CentOS mit pcs ist dies intuitiver mit dem Schlagwort then gelöst. Wenn Sie nun eine der beiden Ressourcen auf einen anderen Knoten migrieren, zieht die andere Ressource ebenfalls um. Auf dem Zielsystem wird immer die IP-Adresse zuerst gestartet, danach der Webserver.

19.6.3    DRBD integrieren

Bevor es an die Clusterkonfiguration ging, hatten Sie das gespiegelte Filesystem bereits so weit konfiguriert, dass Sie die DRBD-Ressource mydrbd jetzt nur noch in den Cluster einbinden müssen.

In der folgenden Schritt-für-Schritt-Anleitung erstellen Sie die benötigten Ressourcen und Constraints. Geben Sie zunächst die beiden folgenden Befehle ein (jeweils auf einer Zeile, die Befehle sind aufgrund der Seitenbreite umbrochen):

# Debian/Ubuntu/openSUSE Leap
crm configure primitive WebDRBD ocf:linbit:drbd params drbd_resource=mydrbd \
op monitor interval=1m role=Master op monitor interval=59s role=Slave

crm configure ms WebDaten WebDRBD meta master-max=1 master-node-max=1 \
clone-max=2 clone-node-max=1 notify=true

# CentOS
pcs resource create WebDRBD ocf:linbit:drbd drbd_resource=mydrbd \
op monitor interval=1m role=Master op monitor interval=59s role=Slave

pcs resource master WebDaten WebDRBD meta master-max=1 master-node-max=1 \
clone-max=2 clone-node-max=1 notify=true

Listing 19.52    DRBD-Ressource einbinden und Master-Slave-Verhältnis konfigurieren

Der erste der beiden Befehle integriert unter dem Namen WebDRBD grundlegend das gespiegelte Dateisystem myDRBD in den Cluster. Der zweite erzeugt eine Master/Slave-Ressource namens WebDaten. Pacemaker weiß nun, dass die DRBD-Ressource nur auf einem der beiden Knoten den Status primary haben darf.

Die Ausgabe von crm status (CentOS: pcs status) sieht nun so aus:

[…]
 myMIP	(ocf::heartbeat:IPaddr2):	Started node1
 myMIP2	(ocf::heartbeat:IPaddr2):	Started node1
 Webserver	(ocf::heartbeat:apache):	Started node1
 Master/Slave Set: WebDaten [WebDRBD]
     Masters: [ node1 ]
     Slaves: [ node2 ]

Listing 19.53    Die Master/Slave-Ressourcen wurden eingebunden.

Die Ressource WebDRBD wird in dieser Übersicht nicht eigens angezeigt, da sie integraler Bestandteil der Master/Slave-Ressource Webdaten ist.

[+]  Neustart?

Es kann vorkommen, dass sich das Setup verschluckt. Ein Neustart von Corosync und Pacemaker hilft dabei, die Konfusionen zu entwirren (manchmal darf es auch ein Reboot sein). Verzagen Sie also nicht zu lange, sondern versuchen Sie, die Nodes mit einem kräftigen Tritt vors Schienbein davon zu überzeugen, das zu tun, was Sie wollen – im Zweifelsfall auch mit einem Reboot der Nodes.

Pacemaker kennt jetzt das Dateisystem, aber es ist noch nicht gemountet. Dafür ist eine weitere Ressource – in diesem Beispiel heißt sie WWWMount – zuständig. So legen Sie sie an (geben Sie den folgenden Befehl auf einer einzigen Zeile ein):

# Debian/Ubuntu/openSUSE Leap
crm configure primitive WWWMount ocf:heartbeat:Filesystem params \
device="/dev/drbd0" directory="/srv/www-data" fstype="ext4"

# CentOS
pcs resource create WWWMount ocf:heartbeat:Filesystem \
device="/dev/drbd0" directory="/srv/www-data" fstype="ext4"

Listing 19.54    Filesystem-Ressource zum Mounten des DRBD-Dateisystems anlegen

Damit haben Sie festgelegt, dass das Device /dev/drbd0, das mit dem Dateisystem Ext4 formatiert ist, im Mountpunkt /srv/www-data eingehängt werden soll. Wenn Pacemaker diese Ressource auf dem Knoten startet, auf dem DRBD gerade den Status secondary hat, erhalten Sie nun eine Fehlermeldung.

Ignorieren Sie die Meldung für den Moment, denn das Problem wird nach der Konfiguration der Constraints verschwinden. Startet die Mountpoint-Ressource zufällig auf dem Knoten, auf dem DRBD primary ist, wird das Dateisystem gemountet, wie Sie mit dem Befehl df -h schnell herausfinden können:

root@node1:~# df -h
Dateisystem                 Grö"se Benutzt Verf. Verw% Eingehängt auf
[…]
/dev/drbd0                   7,8G     18M  7,4G    1% /srv/www-data

Listing 19.55    Das DRBD-Filesystem ist gemountet.

Auch mit crm status können Sie die Mountpoint-Ressource WWWMount nun sehen:

[…]
 myMIP	(ocf::heartbeat:IPaddr2):	Started node1
 myMIP2	(ocf::heartbeat:IPaddr2):	Started node1
 Webserver	(ocf::heartbeat:apache):	Started node1
 Master/Slave Set: WebDaten [WebDRBD]
     Masters: [ node1 ]
     Slaves: [ node2 ]
 WWWMount	(ocf::heartbeat:Filesystem):	Started node1
[…]

Listing 19.56    Auch in der CRM-Statusübersicht wird nun das DRBD-Filesystem angezeigt.

Sie haben jetzt alle Ressourcen definiert, die Sie benötigen. Der letzte Schritt besteht darin, Pacemaker über die Abhängigkeiten zu informieren. Dabei gibt es zwei Colocation-Constraints und zwei Order-Constraints:

  1. Das Dateisystem darf nur auf dem Knoten gemountet werden, auf dem das DRBD-Device als Master, das heißt im primary-Modus, läuft. Das Kommando für diesen Colocation-Constraint lautet:

    # Debian/Ubuntu/openSUSE Leap
    crm configure colocation WebMitDRBD INFINITY: WWWMount WebDaten:Master
    #CentOS
    pcs constraint colocation add WWWMount WebDaten INFINITY with-rsc-role=Master

    Listing 19.57    Colocation-Constraint: Dateisystem und DRBD-Master auf dem gleichen Knoten

  2. Auch beim Mounten ist die Reihenfolge wichtig: Erst wenn das DRBD-Device in den primary-Modus geschaltet wurde, darf das Filesystem eingebunden werden. Diesen Order-Constraint legen Sie mit dem folgenden Kommando fest:

    # Debian/Ubuntu/openSUSE Leap
    crm configure order MountenNachDRBDPrimary INFINITY: WebDaten:promote \
    WWWMount:start

    # CentOS
    pcs constraint order promote WebDaten then start WWWMount

    Listing 19.58    Order-Constraint: erst DRBD auf Master schalten, dann mounten

  3. Das DRBD-Dateisystem muss auf dem Knoten gemountet werden, auf dem der ApacheWebserver läuft. Der Befehl für diesen Colocation-Constraint lautet:

    # Debian/Ubuntu/openSUSE Leap
    crm configure colocation WebServerUndDateisystem INFINITY: Webserver WWWMount

    # CentOS
    pcs constraint colocation add Webserver WWWMount INFINITY

    Listing 19.59    Colocation-Constraint: Mount auf gleichem Knoten wie Webserver

  4. Erst wenn das Filesystem gemountet ist, darf der ApacheWebserver gestartet werden:

    # Debian/Ubuntu/openSUSE Leap
    crm configure order WebServerNachDateisystem INFINITY: WWWMount Webserver

    # CentOS
    pcs constraint order WWWMount then Webserver

    Listing 19.60    Order-Constraint: erst mounten, dann Webserver starten

Spätestens jetzt laufen alle Ressourcen auf dem gleichen Knoten:

root@node1:~# crm status      ### CentOS: pcs status
[…]
Online: [ node1 node2 ]

 myMIP  (ocf::heartbeat:IPaddr2):       Started node1
 Webserver      (ocf::heartbeat:apache):        Started node1
 Master/Slave Set: WebDaten
     Masters: [ node1 ]
     Slaves: [ node2 ]
 WWWMount       (ocf::heartbeat:Filesystem):    Started node1

Listing 19.61    Alle Ressourcen sind auf dem gleichen Knoten gestartet.

Wenn Sie jetzt eine beliebige Ressource zwangsmigrieren, schwenken die IP-Adresse, das DRBD-Filesystem und der Apache – und zwar in genau dieser Reihenfolge, denn dafür sorgen die Order-Constraints – auf den anderen Clusterknoten um:

# Debian/Ubuntu/openSUSE Leap
root@node1:~# crm_resource --resource Webserver --move --node node2; crm status

# CentOS
[root@node1 ~]# pcs resource move Webserver node2 ; pcs status

# Ausgabe:
[…]
Online: [ node1 node2 ]

Full list of resources:

 myMIP	(ocf::heartbeat:IPaddr2):	Started node2
 myMIP2	(ocf::heartbeat:IPaddr2):	Started node2
 Webserver	(ocf::heartbeat:apache):	Started node2
 Master/Slave Set: WebDaten [WebDRBD]
     Masters: [ node2 ]
     Slaves: [ node1 ]
 WWWMount	(ocf::heartbeat:Filesystem):	Started node2

Listing 19.62    Die Migration einer Ressource führt zur Migration aller abhängigen Ressourcen.

Jetzt ist es an der Zeit, auch dem Webserver mitzuteilen, dass er doch bitte die Webseiten von /srv/www-data ausliefern soll.

Damit der Apache die neue Konfiguration auch verwendet, müssen wir, da wir ja auf einem Cluster arbeiten, entweder die Ressource verschieben oder folgenden Befehl absetzen, damit die Ressource (also der Apache) neu gestartet wird:

# Debian/Ubuntu/openSUSE Leap
crm resource restart Webserver

# CentOS
pcs resource restart Webserver

Listing 19.63    Neuladen der Webserver-Konfiguration im Cluster

19.6.4    Fencing

Vielleicht ist Ihnen im Node-Menü der CRM-Shell der Punkt fence aufgefallen. Fencing ist ein Prozess, einen Knoten im Fehlerfall sicher aus dem Cluster herauszuseparieren. Stellen Sie sich folgende Situation vor:

  1. Sie haben einen Datenbank-Cluster aus drei Knoten, die auf dem gleichen Datenbestand arbeiten.

  2. Einer der Knoten antwortet nicht mehr. Der Cluster schwenkt auf die verbliebenen beiden Knoten um und arbeitet weiter.

  3. Der ausgefallene Knoten hatte nur einen »Hänger«, arbeitet nach einigen Minuten aber weiter. Da er nicht mehr zum Cluster gehört, aber noch Zugriff auf den Datenbestand hat (Shared Filesystem!), wird er mit hoher Wahrscheinlichkeit beim nächsten schreibenden Zugriff die Datenbank in die Inkonsistenz und den Admin in den Wahnsinn treiben.

Einen solchen Fall nennt man eine Split-Brain-Situation. Um sie zu entschärfen, gibt es die Fencing-Prozesse. Fencing soll die Beschädigung von Datenbeständen verhindern. Wenn Sie keinen Datenbestand in Ihrem Cluster haben, der in einer Split-Brain-Situation Schaden nehmen könnte, können Sie auf ein Fencing verzichten, aber solche Szenarien sind selten. Stellen Sie sich zur Kontrolle einfach die Frage: »Was kann ein Amok laufender Clusterknoten im schlimmsten Fall anrichten?«

Die bekannteste Fencing-Maßnahme ist STONITH (»Shoot The Other Node In The Head«). Dabei versuchen die beiden Teile des Split Brains jeweils, die andere Hälfte vollständig zu deaktivieren. Diese Deaktivierung wird fast immer auf der Hardwareebene gelöst, etwa mit fernschaltbaren Stromanschlüssen. Sie trennen auf ein Softwarekommando hin die Spannungsversorgung und sorgen so für einen zweifelsfrei definierten Zustand des abtrünnigen Clusterknotens. Da diese STONITH-Devices auf der Hardwareseite sehr variantenreich und herstellerspezifisch sind, können wir hier keine allgemeingültigen Aussagen zum »richtigen« Fencing-Prozess machen. Denken Sie aber beim Bau Ihres Clusters daran, dass Sie sehr wahrscheinlich ein funktionierendes Fencing benötigen, und ziehen Sie die Dokumentation Ihrer Hardware zurate.