© Lars Kunze, Pixelio.de

Zero Downtime ist angesichts globaler Zusammenarbeit über Kontinente und Zeitzonen hinweg keine ungewöhnliche Forderung mehr. Daran gebunden ist der Ruf nach Hochverfügbarkeit. Um ihm unter Linux nachzukommen, bietet sich der neue Cluster-Resource-Manager Pacemaker mit weiteren Komponenten an.

Dieser Beitrag zeigt beispielhaft, wie sich eine klassische LAMP-Umgebung ausfallsicher gestalten lässt. Dabei berücksichtigt er auch das so genannte Chaining, also die Verkettung diverser Dienste, die im Worst-Case-Szenario in der richtigen Reihenfolge neu zu starten sind, weil sie voneinander abhängen.

Die großen Distributoren bieten mit RHCS (Red Hat Cluster Suite) und SLES HAE (Suse Linux Enterprise Server, High Availability Extension) bereits gehärtete und getestete und vor allem auch supportete Produkte an. Das vorliegende Beispiel realisierte der Autor mit Open Suse, es lässt sich aber auch an andere Distributionen anpassen. Die Dienste, die der Cluster schützen soll, müssen selbst keine eingebauten Clustering-Fähigkeiten mitbringen.

Netzwerksetup

Im Beispiel kommt ein Active/Active-DRBD-Setup [1] zur blockbasierten Replikation von Festplattendaten über das Netzwerk zum Einsatz, da hier eine sofortige Übernahme (auch mit Schreibmöglichkeiten) nötig ist. Die eigentliche Cluster-Konfiguration folgt im Unterschied dazu dem Schema Active/Passiv. Der Admin benötigt zwei Netzwerkkarten in jeder Maschine: Eine für den internen Verkehr, also die Replikation der Daten und das Heartbeat-Signal des Clusters, die andere für die Kommunikation mit der Außenwelt über eine stets gleichbleibende Failover-IP-Adresse.

Abbildung 1: Der Überblick zeigt, wie DRBD und Heartbeat-Signale über ein internes LAN oder Crossover-Kabel übertragen werden, wohingegen der Nutzdatenverkehr über ein eigenes Interface läuft.

Diese Netzwerkadresse wird dann durch Clients angesprochen (Applikationen, Browser und so weiter). DRBD überträgt die Nutzdaten über das interne Netz, OCFS2 [2] mit seinem Distributed Lock Manager (DLM) sorgt dafür, dass das Locking bei gleichzeitigen Schreibvorgängen funktioniert. Damit durch das Ethernet-Interface kein Single Point of Failure entsteht, lässt sich mittels Bonding den Folgen des Ausfalls eines Netzwerk-Interface vorbeugen.

Installation

Die benötigten Komponenten für Open Suse stellt der Build Service der Distribution bereit, von wo sie sich direkt zur Installation einbinden lassen (siehe Listing 1). Dabei sollte der Admin auch die Standard-Repositories aktivieren, damit er etwa MySQL ebenfalls gleich installieren kann.

01 zypper ar http://download.opensuse.org/repositories/network:/ha-clustering/OpenSuse_11.3/network:ha-clustering.repo
02 zypper ref
03 zypper in pacemaker corosync heartbeat drbd ocfs2-tools ocfs2-tools-o2cb openais resource-agents mysql-community-server mysql-community-server-client apache2 apache2-mod_php5

Jede Maschine muss eine freie, zur ausschließlichen Verwendung durch DRBD reservierte Partition oder eine ganze Festplatte bereitstellen. Die notwendige Konfiguration von DRBD findet sich in der Datei »/etc/drbd.conf«. Sie ist auf beiden Maschinen identisch. Besonders zu beachten ist der Abschnitt in Listing 2, der bei der Initialisierung zunächst noch nicht eingetragen werden soll, sondern erst dann, wenn die initiale DRBD-Synchronisation der beiden Systeme beendet ist. Erst im Anschluss daran schaltet man in den Active/Active-Mode um.

01 global {
02         usage-count no;
03 }
04 common {
05         protocol C;
06         startup {
07                 wfc-timeout 60;
08                 degr-wfc-timeout 60;
09         }
10         syncer {
11                 rate 1G;
12         }
13         disk {
14                 on-io-error detach;
15         }
16 }
17 resource r0 {
18         device /dev/drbd0;
19         meta-disk internal;
20         ### ERST NACH ERFOLGREICHER INITIALISIERUNG (SYNC) ###
21         disk {
22                 fencing dont-care;
23         }
24         startup {
25                 become-primary-on both;
26         }
27         net {
28                 allow-two-primaries;
29                 after-sb-0pri discard-older-primary;
30                 after-sb-1pri discard-secondary;
31                 after-sb-2pri disconnect;
32         }
33         ### ENDE ###
34         on SERVER1 {
35                 disk /dev/sdb;
36                 address 10.0.0.1:7789;
37         }
38         on SERVER2 {
39                 disk /dev/sdb;
40                 address 10.0.0.2:7789;
41         }
42 }

Nach der erfolgreichen Konfiguration der »drbd.conf« auf beiden Systemen ist nun dafür Sorge zu tragen, dass das Raid-1 initialisiert (Listing 3).

01 drbdadm create-md r0
02 drbdadm attach r0
03 drbdadm syncer r0
04 drbdadm connect r0
05 # Folgender Befehl darf nur auf einem der beiden Systeme laufen, da er die Initialisierung des DRBD-Volumes anstößt
06 drbdadm -- --overwrite-data-of-peer primary r0

Mit »watch cat /proc/drbd« lässt sich die Synchronisation des DRBD-Volume in stilechter Ascii-Art betrachten. Nach einiger Wartezeit steht ein Netzwerk-basiertes, synchronisiertes Raid-1 zur Verfügung. Der Admin sollte bestrebt sein, die Syncer-Rate der Leitungsgeschwindigkeit anzupassen. Der Syncer rechnet in MByte, nicht in MBit. Die Einstellung »1G« sorgt dafür, dass selbst auf einem 10-GBit-Netz die Synchronisation auf schnellstem Wege erfolgt.

Das Dateisystem OCFS2

Damit der Server das OCFS2-Dateisystem auch von Anfang an benutzen kann, braucht er folgende Mountpunkte in »/etc/fstab«:

/dev/drbd0   /data   ocfs2  noatime  0 0
none    /dlm   ocfs2_dlmfs defaults  0 0
none    /config configfs   defaults  0 0

Nach dem Einrichten der Verzeichnisse mountet der Admin folgende Filesysteme: »mkdir /config /dlm && mount /config && mount /dlm«. Darauf folgt die OCFS2-Konfiguration (Listing 4). Danach wiederum formatiert der Admin das Dateisystem nun auf nur einem der beiden Systeme endgültig mit OCFS2:

01 node:
02         number = 0
03         name = SERVER1
04         ip_address = 10.0.0.1
05         ip_port = 7777
06         cluster = r0
07 
08 node:
09         number = 1
10         name = SERVER2
11         ip_address = 10.0.0.2
12         ip_port = 7777
13         cluster = r0
14 
15 cluster:
16         node_count = 2
17         name = r0

/etc/init.d/ocfs2 start
mkfs.ocfs2 -N 2 -L r0 /dev/drbd0

Nun ist der richtige Zeitpunkt, DRBD in den Modus Active/Active umzuschalten und den zuvor ausgelassenen Konfigurationsabschnitt in die »/etc/drbd.conf« einzutragen. Nach einem Neustart mittels »/etc/init.d/drbd restart && /etc/init.d/ocfs2 restart« steht ein vollsynchronisiertes Active/Active-Storage-Setup mit einem Cluster-fähigen Dateisystem bereit, das sich mit »mount /data« mounten lässt.

Clusteraufbau

Pacemaker [3] ist die zentrale Komponente, die das gesamte Ressourcenmanagement übernimmt, also bestimmt, welche Nodes im Cluster zur Verfügung stehen und welche Dienste sie anbieten sollen. Corosync bringt das Cluster Messaging mit, also die Kommunikationsmöglichkeiten für die Cluster-Nodes. Open AIS [4] bringt für die Cluster-Engine Corosync das notwendige API als Plugin mit. Dank dieser modularen Aufteilung lassen sich für alle Komponenten bei Bedarf Erweiterungen schreiben oder auch Updates installieren, die nur einen minimalen Einfluss auf das Gesamtsystem haben.

Die zentrale Konfigurationsdatei von Corosync (Listing 5) regelt, wie die Cluster-Dienste über das interne Netz miteinander sprechen: In diesem vereinfachten Setup deaktiviert der Admin mittels »crm configure property stonith-enabled=false« den “Shoot The Other Node In The Head”-Mechanismus (STONITH), der normalerweise verhindert, dass zwei Cluster-Nodes gleichzeitig auf dieselben Ressourcen zugreifen. Konfigurationsmöglichkeiten dafür zeigt [5]. Nach »/etc/init.d/corosync start« auf beiden Nodes lässt sich dann per »crm status« die Kommunikation beobachten.

01 compatibility: whitetank
02 
03 totem {
04         version: 2
05         secauth: off
06         threads: 0
07         interface {
08                 ringnumber: 0
09                 bindnetaddr: 10.0.0.0
10                 mcastaddr: 226.94.1.1
11                 mcastport: 5405
12         }
13 }
14 
15 logging {
16         fileline: off
17         to_stderr: yes
18         to_logfile: yes
19         to_syslog: yes
20         logfile: /var/log/corosync.log
21         debug: off
22         timestamp: off
23         logger_subsys {
24                 subsys: AMF
25                 debug: off
26         }
27 ]
28 
29 amf {
30         mode: disabled
31 }
32 
33 service {
34         name: pacemaker
35         ver: 0
36 }

Wichtig ist, dass der normale Init-Mechanismus ab sofort nicht mehr jene Dienste steuern darf, die der Cluster verwaltet. Deswegen sollte der Admin die Init-Skripte deaktivieren. Für Dienste, für die bereits die Distribution passende Startskripte mitbringt, lässt sich ein Wrapper [6] verwenden.

Failover-IP-Mechanismus

Der hier vorgestellte Aufbau beinhaltet eine eigene IP-Adresse »10.0.1.10«, mit der sich alle Systeme im Netz verbinden sollen, um immer auf den aktiven Knoten des Clusters zu landen. Dafür erzeugt der folgende Aufruf die Ressource »ipaddr10«, die er auf »eth0« bindet. Diese Befehle sind lediglich auf einem Cluster-Node abzusetzen:

crm configure primitive ipaddr10 
ocf:heartbeat:IPaddr2 params ip=10.0.1.10 
cidr_netmask=32 nic=eth0 op monitor 
interval=30s

Damit der Cluster-Manager nun auch MySQL und Apache2 als Dienst verwalten kann, bedarf es folgender Befehle:

crm configure primitive mysql 
ocf:cluster:initd params service=mysql 
op monitor interval=5s
crm configure primitive apache2 
ocf:cluster:initd params service=apache2 
op monitor interval=5s

Nun kann es passieren, dass diese Dienste gerade auf dem anderen Host laufen, wo die IP-Adresse »ipaddr10« nicht vorhanden ist. Um diesem Problem zu begegnen, erzeugt der Admin eine Colocation-Definition, die beide Dienste aneinander bindet. Die Dienste-Reihenfolge lässt sich damit ebenfalls steuern (IP-Adresse vor MySQL vor Apache2):

crm configure colocation mysql-all inf: 
ipaddr10 mysql apache2
crm configure order srvorder-0 mandatory: 
ipaddr10 mysql
crm configure order srvorder-1 mandatory: 
mysql apache2

Damit der Cluster jederzeit zur Verfügung steht, ist er per »insserv openais« zu aktivieren. Sollen Dienste wie etwa MySQL auf den zentralen Datenbestand zugreifen, ist die Konfiguration der Dienste selbst ebenfalls erforderlich. Hier lässt sich gut mit Symlinks arbeiten, die dafür sorgen, dass beim Failover auch die Konfiguration übernommen wird.

Fazit

Die gesamte HA-Cluster-Konfiguration in der Linux-Welt hat sich seit Heartbeat 1 erheblich verändert und ist um einiges komplexer geworden. Mit der neuen modularen Architektur mit Pacemaker ergibt sich aber eine nahezu unschlagbare Kombination, die selbst schwierigste Aufgaben bewältigt. Zudem ist sie nun auch einfacher erweiterbar. (jcb)