1. Einrichtung

Die folgenden Schritte müssen jeweils auf den Knoten durchgeführt werden. Am einfachsten ist es, wenn man einen Knoten konfiguriert und dann klont. So erspart man sich z.B. das Kopieren der Schlüssel für die Totem-Verbindung.

1.1. Netzwerk

Alle Knoten müssen über ihre Hostnamen auch ohne DNS erreichbar sein, also entsprechende Einträge in /etc/hosts:

1.2. Zeitdienst

Knoten eines Clusters müssen dringend zeitsynchronisiert sein, also ntp auf den Knoten einrichten "/etc/ntp.conf":

Neustart von ntpd:

Status von ntp inklusive Zeitdifferenz zwischen den beiden Knoten prüfen:

1.3. Corosync

Basis Corosync-Konfiguration "/etc/corosync.conf":

rrp_mode passive bewirkt, dass die Informationen vom anderen Knoten abgerufen werden (Poll). Im Vergleich dazu werden bei active die Informationen aktiv an die anderen Knoten übertragen (Push). passive ist die schnellere Übertragungsvariante zwischen den Knoten, active erkennt dafür Fehler schneller.

Direkt auf der Maschine (nicht per SSH) Keys für Totem erstellen:

Hacluster Benutzerpasswort für crmgui setzen:

1.4. Inbetriebnahme

Cluster starten:

1.5. Übersicht der Test-Umgebung

1.5.1. System

Die Arbeits/Testumgebung besteht aus zwei VMWare Server 1 virtualisierten OpenSuSE 11.3 x86 Systemen, Kernel 2.6.34.7:

Die Hosts heißen 'jake3' (erster Knoten) und 'elwood3' (zweiter Knoten).

1.5.2. Netzwerk

Netzwerkkonfiguration für jake3:

Für elwood:

1.5.3. Versionen

Versionen des Cluster-Stack:

DRBD wird in Version 8.3.7 verwendet:

OCFS2 liegt in Version 1.4.3 vor:

LVM in Version 2.02.84:

2. Konfiguration

2.1. Cluster-Konfiguration prüfen

Prüfen der Cluster-Konfiguration:

2.2. Globale Einstellungen (Pacemaker Parameter)

• Bei einem Cluster mit nur 2 Knoten macht ein Quorum kein Sinn: no-quorum-policy=ignore
• default-resource-stickiness=100 ist vergleichbar mit autofailback=false aus den alten heartbeat-Systemen, die Dienste bleiben bei einem Failover beim aktuellen Knoten förmlich "kleben". default-resource-stickiness=0 entspricht autofailback=true.
• stonith-action=poweroff bewirkt, dass der über STONITH abgeschossene Server auch aus bleibt (standardmäßig fährt der Server wieder hoch = sinnlos).

2.3. Dokumentation der Agenten Parameterisierung

Die verfügbaren Parameter für Agenten bei der Konfiguration von Primitiven (nächster Abschnitt) lassen sich wie folgt ermitteln:

2.4. Primitive

IP-Primitive (floating-IP) erstellen:

(SUSE-spezifisch) Apache Status-Modul aktivieren in /etc/sysconfig/apache2:

Primitive Apache (ocf:heartbeat:apache) anlegen:

2.5. Migration-Threshold und on-fail Action

Für jede Ressource lassen sich ein Grenzwert (Threshold) für eine forcierte Migration und eine Aktion bei einem Fehler festlegen:

In diesem Fall versucht der Cluster, den Apache 2x neuzustarten (on-fail="restart") , wenn ein Fehler auftritt. Beim dritten Mal wird der Apache dann auf einen anderen Knoten migriert (migration-threshold="3").

2.6. Order

Der Apache-Dienst soll nach der IP gestartet werden (order)

2.7. Colocation

Die IP-Adresse soll immer auf dem selben Knoten laufen, auf dem auch der Apache-Dienst betrieben wird (colocation):

2.8. Clone-Sets

Der Apache soll als "Clone-Set" maximal 2x im Cluster laufen (Knoten=2) und maximal 1x pro Server laufen:

globally-unique="true" bedeutet, dass der Dienst auf beiden Serverknoten identisch konfiguriert ist.

Vorteil der Clone-Sets ist, dass der Apache nun auf beiden Server schon läuft und im Fehlerfall nur noch die IP-Adresse umgezogen werden muss.

2.9. Groups (am Beispiel von Samba)

In diesem Abschnitt soll an Hand des Samba-Dienstes die Gruppen in Pacemaker veranschaulicht werden. Die folgenden Schritte sind auf beiden Knoten durchzuführen.

Samba konfigurieren mit /etc/samba/smb.conf:

Vorbereitungen auf dem System:

Zwei neue Primitive als LSB-Agenten für die Samba-Dienste einrichten:

Diese Dienste mit der IP-Adresse in eine Gruppe setzen:

Alle Dienste in einer Gruppe werden in der angegebenen Reihenfolge gestartet (IP, nmb, smb) und gestoppt (smb, nmb, IP). Zudem werden alle Dienste in einer Gruppe auf einem Knoten gestartet, sie sind also mit colocations miteinander verbunden.

2.10. Multi-State-Resource (am Beispiel von DRBD/Samba)

Eine Multi-State-Resource verhält sich wie ein Clone-Set (Klonen von Diensten auf mehreren Knoten gleichzeitig), jedoch unterstützt sie neben den Start- und Stop-Status zusätzlich noch die Status Master und Slave, daher auch der Name "Multi-State".

In diesem Beispiel bereiten wir zunächst eine DRBD-Resource auf beiden Knoten ein.

DRBD auf beiden Knoten mit /etc/drbd.conf konfigurieren:

Auf beiden Knoten nacheinander DRBD-Metadaten anlegen, DRBD-Modul laden und DRBD-Resource starten:

DRBD-Status abrufen. Knoten sind verbunden, jedoch noch inkonsistent, da die Devices noch nicht synchronisiert sind:

Initialen Sync überspringen, da noch keine Daten auf den Devices vorhanden sind, die gesynced werden müssten:

DRBD-Primary auf einem Knoten setzen:

Dort ein Dateisystem auf dem DRBD-Device erstellen:

Mounten und Test-Datei anlegen:

Die DRBD-Resourcre "r0" als Pacemaker Multi-State-Resource anlegen:

Resource für das Mounten und Unmounten des darauf befindlichen Dateisystem erstellen:

Eine Gruppe aus IP und Dateisystem erstellen:

Diese Gruppe immer auf dem Knoten mounten, auf dem die DRBD-Resource als Master gesetzt ist:

Schließlich noch eine Reihenfolge definieren, die besagt, dass erst das DRBD-Device auf Master gesetzt werden muss (promoten), bevor die Samba-Gruppe gestartet werden darf:

2.11. Konfiguration eines STONITH-Device

Das externe SSH-STONITH-Plugin muss in den meisten Fällen nachinstalliert werden:

Wie folgt lassen sich alle STONITH Plugins auflisten:

Parameter eines Plugins abfragen:

SSH-Key auf den Knoten erstellen:

STONITH Daemon testen - es sollte "Connection to STONITH successful" erscheinen:

Kommunikation zwischen den STONITH Daemons prüfen:

Nun kann man ein STONITH manuell durchführen:

Abschließend wird das STONITH als Klone auf allen Knoten wie folgt im Cluster konfiguriert:

2.12. Spezielle Resourcen und andere Beispiele

2.12.1. Ping-Resource

Ping-Resource erstellen und auf allen Serverknoten klonen:

Regel definieren: "Auf dem Serverknoten, auf dem pingd gar nicht läuft oder nur eine Punktzahl <= 1000 erreicht, darf Apache2 niemals (-inf) gestartet werden":

Aktuellen Punktstand im Cluster ermitteln:

Wenn wir nun mittels netfilter die ICMP-Pakete auf einem Knoten sperren...:

...fallen auch entsprechend die Werte und die Dienste werden auf den Knoten mit in diesem Beispiel 2000 Punkten umgezogen:

2.12.2. Dual-Primary-DRBD mit OCSF2 Cluster-Dateisystem

DRBD-Konfiguration für Multi-Primary-Setup in /etc/drbd.conf:

Auf beiden Knoten DRBD-Device erstellen, aktivieren und auf Primary setzen:

Beide sind verbunden, auf dem aktuellsten Stand und Primary:

DRBD-Primitive und Multi-State-Resource anlegen (master-max="2" bewirkt, dass die DRBD-Resource auf beiden Knoten auf den Master-Status gesetzt werden darf):

Nun erstellen wir eine Primitive für den dlm (distributed lock manager):

Aus der Primitiven wird ein Clone-Set erzeugt, so dass der Dienst auf allen Knoten läuft:

Über die Colocation definieren wir, dass der dlm Dienst nur auf den Knoten betrieben wird, auf dem die DRBD-Resource im Master-Status läuft:

Schließlich bestimmen wir noch mit einem order, dass erst die DRBD-Resource zum Master promoten sein muss, bevor der dlm gestartet werden kann:

Parallel zur Einrichtung des dlm wird nun noch der o2cb-Dienst im Pacemaker konfiguriert. Hier gilt, der o2cb wird auf den Knoten gestartet, auf dem auch dlm betrieben wird und o2cb wird nach dlm gestartet:

In OpenSUSE kann es zu Problemen mit einer zu hohen cluster local id kommen, die dann nicht vom ocfs2 Kernel-Modul unterstützt wird. Folgende Fehlermeldung erscheint in der /var/log/messages:

Dann sollte in der "corosync.conf"-Konfiguration folgender Parameter innerhalb der totem-section eingefügt werden, der bewirkt, dass mit einem führendem Nullbit die cluster local id kleiner ausfällt:

Schließlich kann das OCFS2-Dateisystem mit 2 Knoten (-N 2) erstellt werden:

Zum Mounten des Cluster-Dateisystems erstellen wir eine neue Pacemaker-Primitive. Das Clone-Set stellt wieder sicher, dass es auf allen Knoten gleichzeitig gestartet, sprich gemounted wird:

Mit der folgenden colocation und order wird wieder sichergestellt, dass es auf den selben Knoten gestartet wird, wie die o2cb-Dienste und auch nach dem erfolgreichen Start von o2cb:

2.12.3. Samba-HA mit OpenLDAP auf OCFS2

Auf Basis des im vorherigen Abschnitt eingerichteten Clusterdateisystem OCFS setzen wir nun eine hochverfügbares Samba mit OpenLDAP ein. Die Daten, die von Samba bereitstellt werden, liegen im Clusterdateisystem. Der Inhalt der OpenLDAP-Datenbank wird per OpenLDAP-Replikation zwischen den beiden Knoten abgeglichen.

Floating-IP für ldapmirror3 im Pacemaker einrichten:

Die folgenden Änderungen auf beiden Knoten durchführen:

/etc/slapd.conf:

/etc/openldap/ldap.conf:

Zusätzlicher Eintrag in der /etc/hosts für die floating-IP:

Konfigurationsorder initialisieren:

/etc/sysconfig/openldap:

Rechte für den Konfigurationsordner anpassen:

OpenLDAP starten und offenen LDAP-Port prüfen:

Erste Datensätze importieren:

samba-base.ldif:

Mittels Replikation müssten jetzt auf beiden Knoten die selben Daten verfügbar sein:

Nun wird der Samba in *"/etc/samba/smb.conf" konfiguriert:

/etc/ldap.conf:

Passwort für die Kommunikation zwischen Samba und OpenLDAP konfigurieren:

Name Service Cache Daemon stoppen und Winbind starten:

Rudimentäre NT4 PDC-Struktur erstellen:

Passwort für den Administrator erstellen, dieses wird im OpenLDAP abgelegt und zwischen den beiden Knoten repliziert:

Samba starten:

Wir gewähren dem Administrator volle Domainadminrechte:

Nun erstellen wir für unsere 4 Dienste neue Primitiven, setzen diese in eine Gruppe und klonen sie auf alle Clusterknoten:

2.12.4. DRBD Dual Primary mit OCFS2 und CLVM

/etc/lvm/lvm.conf:

Lock-Manager und Cluster LVM-Daemon in Gruppe, geklont auf beiden Knoten erstellen. Mit order sicherstellen, dass DRBD zu erst als Master promotet wurde:

LVM-PV auf DRBD-Device, geclusterte VG1 auf PV und schließlich 5GB große LV in VG1 erstellen:

VG1 im Cluster geklont auf allen Knoten konfigurieren:

Oracle Pacemaker Clusterstack hinzufügen, Reihenfolge der Dienste dlm, clvm, o2cb und vg1 konfigurieren:

Oracle Cluster Filesystem erstellen:

Schließlich noch das Dateisystem ins Cluster aufnehmen:

Alternativ kann auch folgende einfachere Konfiguration mit einer Gruppe angewendet werden:

Live Vergößern des Clustered LVMs und des OCFS2-Dateisystems:

2.12.5. HA ISCSI-Target

Wieder eine Standard Master/Slave-DRBD-Konfiguration auf beiden Knoten mit /etc/drbd.conf:

Auf beiden Knoten Metadaten erstellen, aktivieren, sync überspringen:

Auf einem Knoten Master setzen und Dateisysteme erstellen:

DRBD in typischer Master/Slave-Konfiguration in Pacemaker hinterlegen:

Auf beiden Knoten ISCSI-Pakete unter OpenSUSE nachinstallieren:

Wieder auf beiden Knoten die ISCSI-Target-Konfiguration "/etc/ietd.conf" anpassen:

Clone-Set für den ISCSI-Target Daemon einrichten:

Primitiven für floating IP, ISCSI-Konfiguration (itarget und ilun) erstellen, diese in eine Gruppe setzen. Über colocation und order sicherstellen, dass der ISCSI-Dienst auf dem Knoten betrieben wird, auf dem DRBD auf Master läuft und die richtige Start- und Stopreihenfolge (drbd -> ietd -> iscsi) eingehalten wird:

2.12.6. Snapshots eines OCFS2-Dateisystems unter LVM und Dual-Primary DRBD

Dual-Primary /etc/drbd.conf:

Dual-Primary DRBD in Pacemaker konfigurieren:

LVM auf DRBD erstellen:

Dienste für Locking und OCFS2 als geklonte Gruppe in Pacemaker konfigurieren:

Falls auf einem der Knoten die LVs nicht verfügbar sind, folgende Schritte durchführen:

OCFS2 erstellen:

Dateisystem erstellen und mit in die Gruppe dp_group aufnehmen:

Testdaten erzeugen

Snapshot erzeugen:

Weitere Testdaten erzeugen

Status des OCFS2-Dateisystem kann wie folgt geprüft werden:

Das Problem ist nun, dass der OCFS2-Snapshot nicht gemounted werden kann:

Dafür muss die UUID des Snapshot angepasst und als geklont markiert werden:

2.12.7. Xen Live-Migration mit DRBD

Folgende Anleitung basiert auf dem vorherigen Kapitel mit OCFS2.

Netzwerkkartenreihenfolge und -belegung auf beiden Knoten angleichen:

System mit Xen-Kernel neustarten.

LVM deaktivieren:

DRBD-Module automatisch laden lassen in /etc/sysconfig/kernel:

Primitive für LVM einrichten und in Gruppe einfügen:

Die Gruppe sollte nach dem Editieren wie folgt ausschauen:

/etc/xen/xend-config.sxp:

Xen-Daemon neustarten:

Pakete nachinstallieren:

Wir legen eine vorbereite OpenSUSE11-VM als Xen-VM ab:

Und verlinken die dortige Konfiguration aus dem OCFS2-Dateisystem (/daten) in das lokale "etc"-Verzeichnis:

Die Xen-Konfiguration oss113xen stellt sich wiefolgt dar:

Melden die neue Xen-Konfiguration an:

Live-Migration testen, indem wir die VM auf jake3 starten und dann auf elwood3 livemigrieren:

Schließlich können wir eine Primitive für das Management der Xen Domain in Pacemaker einrichten:

3. Verwaltung

3.1. Resourcen migrieren

Resource Service_IP von aktuell Knoten elwood3 auf jake3 migrieren:

Migration wird an Hand einer automatisch eingetragenen Location-Regel durchgeführt:

Rückgängig machen mit dem Befehl "unmigrate" oder dem Löschen der Location-Regel.

3.2. Manuellen Failover durchführen

Knoten deaktivieren und damit Failover aller Dienste auf andere Knoten durchführen:

Wieder reaktivieren, Dienste bleiben aber auf den anderen Knoten (s. default-resource-stickiness):

3.3. Fehlerstand kontrollieren und zurücksetzen

Fehlerstand (fail-count) des Clusterknotens jake3 ermitteln:

Hier ist z.B. der max-failcount erreicht:

Fehlerstand zurücksetzen:

3.4. Kopie der CIB erstellen und damit arbeiten

Neue erstellen:

oder bestehende benutzen:

Shadow-Konfiguration commiten, die Shadow- und Live-Konfiguration werden dann gemergt:

3.5. Konfigurationsanpassungen grafisch prüfen

3.6. CIB-Templates

3.7. Status der Corosync-Ringe prüfen

3.8. Corosync-Ringe zurücksetzen

Falls ein Ring als fehlerhaft (faulty) markiert wurde und damit nicht mehr genutzt wird, kann man diese wie folgt versuchen zu restorieren:

3.9. Debug-Informationen von Corosync/Totem abrufen

4. Management-Tools

4.1. Pacemaker CRM-Shell

CRM-Shell aufrufen:

Clusterkonfiguration bearbeiten:

Verschiedene Befehle:

4.2. CRM Kommandozeilentools

Gut zum Scripten sind die Kommandozeilentools, die teilweise über bestimmte Parameter zusätliche Möglichkeiten der Verwaltung bieten:

4.3. Grafische Pacemaker GUI

Die grafische Pacemaker GUI verbindet sich über folgenden, auf allen IPs lauschenden TCP-Port mit dem Managementdienst (mgmtd):

4.4. CRM-Monitor

CRM-Monitor aufrufen (-n gruppiert Ressourcen nach Cluster-Knoten):

Nützliche Parameter:

4.5. Andere Tools

• HAWK
• DRBD MC

5. Hinweise

• Änderungen an der Clusterkonfiguration niemals über cib(admin) durchführen
  • Höchstens für vollständige Backups und Wiederherstellung kann es verwendet werden.
  • Lieber die crmshell oder crmgui nutzen. Beide werden von den Pacemaker-Machern entwickelt und sind am aktuellsten. Die Shell hat jedoch die meisten Funktionen.
• Man sollte keine laufenden Resourcen löschen, da es sonst zu "orphaned resource" (verweiste Einträge) kommen kann. CIB-Status prüfen mit "crm_verify -LV"
• Jede Änderung wird erst von der policy engine an Hand der globalen Regeln geprüft (Prozess: pengine), dann geht die Änderung zur transition engine auf dem designated coordinator (DC), schließlich wird die Änderung vom local resource manager (Prozess: lrmd) auf dem entsprechenden Knoten propagiert. Der ganze Vorgang kann etwas dauert. In dieser Zeit sollte nicht unnötig refresh oder cleanup durchgeführt werden.
• Bei Problemen als erstes die Cluster-Konfiguration mit "crm_verify -LV" prüfen. Hier gibt es häufig Hinweise auf die Ursache der Probleme.

6. Wichtige Pfade

• Agent-Skripte (heartbeat, OCF, stonith): /usr/lib/ocf/resource.d
• CIB-Datenbank: /var/lib/heartbeat/crm/

7. Backup der Cluster-Konfiguration

Aktueller Stand der Konfiguration aus dem Speicher:

XML-Konfigurationen im Verzeichnissen (nicht manuell bearbeiten!):

8. Weitere Dokumentationen

9. Quellen

• GFU Schulung über Linux-HA-Cluster mit Pacemaker und OpenAIS-Corosync
• Fachliteratur "Linux Hochverfügbarkeit: Einsatzszenarien und Praxislösungen" von Oliver Liebel