Ein Hochverfügbarkeits-Cluster unter Linux ist auch mit einfachen Mitteln zu realisieren. Der Einstieg in die Oberliga für Server benötigt nur Standardkomponenten und die beiden freien Programme Heartbeat und DRBD - und schon steht beim Absturz des Servers ein Ersatz bereit. Diese Art Cluster stellt ein Backup-System (Hot Standby) für Dienste zur Verfügung.

Im Gegensatz zu Computing- oder Load-Balancing-Clustern ist einer der Server in diesem Fall passiv und wird erst tätig, wenn der Arbeitsserver ausfällt. Die von der Anwendung benötigten Daten werden dabei über das Netz gespiegelt, ein gemeinsamer Datenspeicher (Shared Storage) ist nicht nötig: Der Linux HA-Cluster ist ein Share Nothing Cluster. Da beide Rechner komplett ausgestattet sind und sich keine gemeinsamen Ressourcen teilen, fällt ein Single Point of Failure weg. Das sieht zunächst nach höheren Investitionen aus, aber die speziellen Komponenten für Shared Storage Cluster sind teuer, die Share Nothing Cluster kommen mit Standardkomponenten aus. Zwei einfache PCs mit jeweils zwei Netzwerkkarten, auf denen eine übliche Linux-Distribution läuft, im beschriebenen Beispiel Ubuntu 8.04 Server reichen. 

Beide Systeme bekommen die übliche Partitionsaufteilung, am besten möglichst gleichartig, also zum Beispiel »/swap« und, »/«. Für die Daten, die der Cluster zur Verfügung stellen soll, ist jeweils noch eine separate Partition notwendig. Sie sollte auf beiden Rechnern etwa gleich groß sein und darf keinen Mountpoint erhalten und nicht beim Systemstart angebunden werden. Im Beispiel ist das jeweils die primäre Partition der zweiten Festplatte /dev/sdb1.

Als Dateisystem ist ein Journaling Filesystem wie Ext 3, ReiserFS oder XFS zu empfehlen. Die beiden Netzwerkkarten bekommen feste IP-Adressen. Im Beispiel für Karte 1 (»eth0«) die 192.168.1.10 auf dem primären Knoten, auf dem anderen Server bekommt die Karte 1 (»eth0«) die Adresse 192.168.1.11 als sekundärer Knoten.

Die zweite Netzwerkkarte (»eth1«) ist für die Heartbeat-Leitung zuständig. Im vorliegenden Beispiel hat Knoten 1 als IP-Adresse 192.168.245.129 und Knoten 2 die 192.168.245.130. Die Ports beider Netzwerkkarten verbindet man mit einem Netzwerk-Crossover-Kabel oder einem separaten Hub.

Trivial, aber wichtig sind eindeutige Namen für beide Rechner. Es ist eine gute Idee, die Namen in die »/etc/hosts« einzutragen.

# more /etc/hosts
127.0.0.1    localhost
127.0.1.1    knoten2
192.168.245.129 knoten1
192.168.245.130 knoten2
....

Um dynamische Daten im Cluster auf beiden Servern redundant zu halten, ist eine Art Raid-System erforderlich, das alle Schreibzugriffe der Festplatte des aktiven Knotens über das Netzwerk auch auf dem sekundären Knoten spiegelt. Dies erledigt das Programm DRBD (Distributed Replicated Block Device), das von dem Österreicher Philipp Reisner als Diplomarbeit entwickelt wurde.

Der Kern von DRBD ist ein Daemon, der beim Booten startet, während das Mounten der Clusterpartition normalerweise später ein Heartbeat-Skript übernimmt. DRBD benötigt jeweils eine eigene Partition auf jedem Clusterknoten. Die Partition wird mit eigenen Devices z.B. /dev/drbd0 angesprochen.

Für DRBD muss nur die Datei »/etc/drbd.conf« bearbeitet werden. Der Start erfolgt wie bei Heartbeat über den Runlevel-Editor oder über »/etc/init.d/drbd start«. DRBD ist ein Programm, das unabhängig von Heartbeat arbeitet, aber als Clusterdienst von ihm verwaltet werden kann. Die Konfiguration von »/etc/drbd.conf« erfordert etwas mehr Aufwand als Heartbeat.

$ sudo -s
# apt-get install drbd8-utils
# fdisk /dev/sdb
# drbdadm create-md daten
# nano -w /etc/drbd.conf

# more /etc/drbd.conf
resource daten {
  protocol    C;

  startup { wfc-timeout    0; degr-wfc-timeout    120; }
  disk { on-io-error detach; }
  syncer {
    rate 680M;
  }
  on knoten1 {
    device    /dev/drbd0;
    disk    /dev/sdb1;
    address    192.168.245.129:7791;
    meta-disk    internal;
  }
  on knoten2 {
    device    /dev/drbd0;
    disk    /dev/sdb1;
    address    192.168.245.130:7791;
    meta-disk    internal;
  }
}

Nach der Konfiguration starte man DRBD und erstellt auf der neuen Partition ein Dateisystem.

# /etc/init.d/drbd start
# drbdadm primary daten
# mkfs.ext3 /dev/drbd0
# drbdadm secondary all

Befehl zum Überwachen von DRBD:
# watch cat /proc/drbd
version: 8.0.11 (api:86/proto:86)
GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02
-12 11:56:43
 0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
....

Wenn beide Nodes "Secondary" und "UpToDate" ist alles in Ordnung und man kann mit der Installation von Heartbeat beginnen.

Das Programm Heartbeat ist ein Dienst, der seinen Clusterpartner überwacht und im Ernstfall (Failover) die für die Anwender notwendigen Dienste startet sowie die Cluster-IP-Adresse im Netz übernimmt. Welche die notwendigen Dienste sind, hängt natürlich vom Verwendungszweck des Clusters ab. Für die gebräuchlichsten Anwendungen genügen die Start-Skripte aus »/etc/init.d« oder es werden entsprechende Skripte mit Heartbeat geliefert.

# apt-get install heartbeat-2

Für die Konfiguration von Heartbeat ist noch eine gemeinsame IP-Adresse notwendig. Unter dieser virtuellen Adresse ist später der jeweils aktive Knoten im Netz erreichbar. Im Beispiel ist 192.168.1.100 die IP-Adresse. Für diese Adresse sollte auch ein DNS-Eintrag erfolgen, der den Namen des Clusters im Netz bekannt gibt.

Heartbeat wird mit drei Dateien konfiguriert: »/etc/ha.d/ha.cf«, »/etc/ha.d/resources« und »/etc/ha.d/authkeys«. Sie sind intern ausführlich dokumentiert. Heartbeat kommt mit wenigen Einträgen in der Konfigurationsdatei »/etc/ha.d/ha.cf« aus. Die ausführlichen Kommentare im mitgelieferten Original wurden zugunsten der besseren Übersicht entfernt. Die Datei hält die grundlegenden Eigenschaften von Heartbeat fest, etwa welche Knoten wie am Cluster beteiligt sind.

# cp /usr/share/doc/heartbeat/ha.cf.gz /etc/ha.d/
# gunzip /etc/ha.d/ha.cf.gz
# nano -w /etc/ha.d/ha.cf

debugfile /var/log/ha-debug
logfile    /var/log/ha-log
logfacility    local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport    694
bcast    eth1
ucast eth1 192.168.245.129
ucast eth1 192.168.245.130
auto_failback off
node    knoten1
node    knoten2
crm yes

# nano -w /etc/ha.d/haresources

knoten1 192.168.1.100 drbddisk::daten Filesystem::/dev/drbd0::/daten::ext3

Die Ressourcendatei »/etc/haresources« legt fest, welche Dienste mit welcher IP-Adresse immer im Netz erscheinen sollen.

Die in dieser Datei stehenden Anwendungen dürfen natürlich nicht beim Systemboot geladen werden - ab jetzt ist Heartbeat für den korrekten Start der benötigten Programme zuständig. Erst wenn Heartbeat festgestellt hat, dass es selbst auf dem aktiven Knoten läuft, startet es die benötigten Programme. Die Datei »/etc/ha.d/haresources« muss unbedingt auf beiden Knoten den gleichen Inhalt haben.

Um den Cluster in Gang zu setzen, fehlt noch die »/etc/ha.d/authkeys«-Datei. Sie enthält in Klartext das Passwort für die Heartbeat-Verbindung und muss auf beiden Knoten gleich sein.

# nano -w /etc/ha.d/authkeys

auth 3
# 1 crc
3 md5 Passwort
# 2 sha1

Da ein im Klartext lesbares Passwort sicherheitskritisch ist, muss die Datei zwingend die Zugriffsrechte 600 haben.

# chown root:root /etc/ha.d/authkeys
# chmod 600 /etc/ha.d/authkeys

Die Authentifizierung nach »sha1« ist wohl die sicherste Methode unter den drei gezeigten. Bei einer sicheren Netzverbindung wie einem Crossover-Kabel ist überhaupt keine Schlüsselsignatur nötig; dann reicht »crc« völlig aus.

Verteilung der Konfigurationsdateien:
# passwd (auf den übrigen Knoten)
# /usr/share/heartbeat/ha_propagate
# scp /etc/ha.d/haresources knoten2:/etc/ha.d/

Erstellen der Konfigurationsdatei für Heartbeat V2:
# rm -f /var/lib/heartbeat/crm/*
# /usr/lib/heartbeat/haresources2cib.py /etc/ha.d/haresources

Heartbeat starten und überwachen:
# /etc/init.d/heartbeat start
# crm_mon -i 2

Ein inkonsistentes DRBD, besser bekannt als "Split Brain" bedeutet, dass beide Nodes primär sind und beide auf die Ressource "Daten" schreiben. Das Ergebnis ist eine inkonsistente Ressource eben ein sogenanntes "Split Brain". Um das System wieder in einen konsistenten Zustand zu bringen, muss man sich der Daten auf einem der Nodes entledigen und mittels DRBD wieder synchronisieren.

# /etc/init.d/heartbeat stop
# /etc/init.d/drbd stop
# modprobe drbd
# drbdadm -- --discard-my-data connect <resource> (auf dem Node mit den "schlechten" Daten)
# drbdadm connect <resource> (Auf dem Node mit den "guten" Daten)
# /etc/init.d/drbd start
# /etc/init.d/heartbeat start

Ein inkonsistentes DRBD gibt es meistens, wenn der Linuxcluster resp. heartbeat falsch konfiguriert ist. Nach der Wiederherstellung der Resource sollte man also den Grund eruieren und den Fehler beheben.

ACHTUNG unbedingt Backup erstellen.

Um ein DRBD-Device mit Partitionen zu erstellen, die bereits Daten beinhalten, muss man die Metadaten auf einer andere Partition erstellen. Diese Partition darf kein Dateisystem oder swap enthalten. Die Grösse der Metadaten-Partition richtet sich nach der Grösse des künftigen DRBD-Devices.

Hat man die Partition einmal erstellt, muss man in der drbd.conf den entsprechenden  Eintrag  machen. Hier auf die Partition /dev/sda5. Die Null in Klammer ist eine fortlaufende Zahl, da auf einer Partition mehrere "DRBD meta data" erstellt werden können.

Ausschnitt aus der drbd.conf

----schnipp

  on knoten1 {
    device    /dev/drbd0;
    disk    /dev/sdb1;
    address    192.168.245.129:7791;
    meta-disk /dev/sda5[0];
  }

----schnapp

Nachdem die drbd.conf angepasst/erstellt wurde, erstellt man wie folgt die Meta-Daten resp. den DRBD-Device.

# /etc/init.d/drbd stop
# drbdadm create-md daten
# /etc/init.d/drbd start

Falls drbd nur auf einem Knoten gestartet wird, findet drbd den zweiten Knoten nicht und wartet auf denselben. Die Frage "To abort waiting enter 'yes' []:" kann mit "yes" beantworetet werden.

Anschliessend setzen wir die Partition mit den Daten auf "primary" mit der Option -o (--overwrite-data-of-peer). Damit bleiben die Daten auf der Partition /dev/sdb1 erhalten.

# drbdsetup /dev/drbd0 primary -o

So das wars, wenn die Ausgabe von /proc/drbd UpToDate ist, kann die Partition gemountet werden.

# more /proc/drbd
version: 8.0.11 (api:86/proto:86)
GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02-12 11:56:43
 0: cs:WFConnection st:Primary/Unknown ds:UpToDate/DUnknown C r---
    ns:0 nr:0 dw:256 dr:40 al:2 bm:0 lo:0 pe:0 ua:0 ap:0
        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
        act_log: used:0/127 hits:24 misses:2 starving:0 dirty:0 changed:

# mount -t ext3 /dev/drbd0 /daten/