Hochverfügbare Dienste mit Pacemaker, OCFS2 und DRBD

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.