Hochverfügbarer Fileserver mit Heartbeat2 und DRBD

Einleitung

Der Begriff High Availability (abgekürzt HA) wird immer häfiger in der IT-Branche erwähnt. Dahinter verbergen sich Systeme, die ihre Dienste selbst bei Ausfall einzelner Komponenten weiterhin anbieten können.

Häuf finden sich die Anwendungsgebiete für solche HA-Cluster im Bereich File-Server (Samba, NFS), Web-Server (Apache) oder Datenbankapplikationen.

Cluster lassen sich grob in zwei Kategorien unterteilen:

• aktiv/aktiv: Load-Sharing
• aktiv/passiv: Standby

Projektziel

Ziel dieses Projektes ist es einen hochverfügbaren File-Server mit DRBD und Heartbeat zu realisieren.

Diese Anforderung deckt sich mit den Anforderungen von DRBD:

DRBD realisiert eine Art RAID1 (Mirroring) - allerdings nicht wie gewohnt mit zwei lokal im Rechner eingebauten Speichermedien. Stattdessen wird eines der Medien auf einem zweiten Rechner übers Netzwerk angesprochen. Um Inkonsistenzen auf diesem Medium zu vermeiden, darf jeweils nur einer der Rechner (der Primary) darauf schreiben.

Benötigte Hard- und Software

Hardware

• 2 Rechner
• 2 Netzwerkkarten pro Rechner

oder

• eine Netzwerkkarte pro Rechner und eine serielle Verbindung zwischen den 2 Nodes
• ein Switch
• optional: ein Masterswitch um das STONITH-Verfahren anzuwenden

Software

Das Paket „Heartbeat“ dient zur Überwachung der Knoten und es übernimmt das An-, Ab- und Umschalten der Dienste auf den Knoten. Das Paket „DRBD“ dient zum Spiegeln der benötigten Daten über ein Netzwerk.

Als Betriebssystem kam SuSE Linux Enterprise Server 9 (mit Kernel 2.6) zum Einsatz. Ab SuSE 9.0 sind die benötigten Pakete schon in der Distribution enthalten - wenn auch nicht in der Standard-Auswahl.

Will man die Funktionalität von DRBD und Heartbeat nutzen, so müssen folgende Pakete installiert sein:

• Heartbeat Version 2
• Heartbeat-stonith Version 2
• Heartbeat-pils Version 2
• Heartbeat-ldirectord Version 2
• DRBD

Konfiguration

Netzwerk

Node1:

• eth0 : 131.188.78.125 Normales Netz
• eth1 : 10.10.0.1 Privates 10x Netz für die Heartbeat-Leitung

Node2:

• eth0 : 131.188.78.126 Normales Netz
• eth1 : 10.10.0.2 Privates 10x Netz für die Heartbeat-Leitung

Um die Netzwerkkonfiguration zu testen reicht ein einfacher Aufruf von ping aus. Wenn man jedoch statt der zweiten Karte eine serielle Heartbeat-Leitung benutzt, muss man auf andere Programme ausweichen:

Auf dem Node1:

linux:~ # cat < /dev/ttyS0
        

Auf dem Node2:

linux:~ # echo hallo > /dev/ttyS0
        

Jetzt müsste der Text „hallo“ auf dem Node1 erscheinen.

Anmerkung: Das ganze funktioniert nur bei gleichen Einstellungen der seriellen Schnittstellen (Baudrate, Stopp-Bits, Parity) auf beiden Rechnern. Sollten diese unterschiedlich konfiguriert sein, so kann man das mit Hilfe des Tools setserial korrigieren.

DRBD

Um den Aufbau nicht unnötig zu komplizieren werden wir DRBD zuerst ohne Heartbeat in Betrieb nehmen.

Das Kernstück von DRBD ist ein Daemon, der beim Systemstart startet. Erst durch das Laden des Moduls drbd werden die Devices ansprechbar, hinter denen sich die Block-Geräte von DRDB verbergen. Diese Geräte-Dateien sind bei aktuellen SuSE-Distributionen schon enthalten - bei älteren kann man sie durch folgenden Kommandozeile erstellen:

linux:~ # for i in 0 1 2 3 4; do mknod /dev/nb$i b 43 $i; done
        

Anmerkung: Bei neueren DRBD Versionen (>= 0.7.0) erwarten die DRBD Tools Geräte-Dateien mit neuer Major-Nummer und neuer Bezeichnung:

linux:~ # for i in `seq 0 15`; do mknod /dev/drbd$i b 147 $i; done
        

Bei der Partitionierung der Festplatten sollte auf beiden Rechnern die gleiche Größe und das gleiche (Journaling-) Filesystem, wie Ext3 oder ReiserFS, verwendet werden. Diese Partitionen erhalten keinen Eintrag in der /etc/fstab, da später Heartbeat das Einbinden der Block-Devices in das Filesystem für uns übernehmen wird.

In der Datei „/etc/drbd.conf“ müssen die Devices konfiguriert werden. Eine einfache Ausführung ist unter dem Link nachzulesen.

Ein wichtiger Punkt ist die Wahl des zu verwendenten Übertragungsprotokolles: Hier gibt es 3 Möglichkeiten, die sich vor allem in den Punkten Sicherheit und Geschwindigkeit unterscheiden:

• A: Eine Schreiboperation ist auf dem Primärknoten beendet und bestätigt, sobald die Daten dem Netzwerk übergeben wurden. (schnell aber unsicher)
• B: Eine Schreiboperation ist dann auf dem primären Knoten beendet, wenn die Daten auf dem sekundären Knoten angekommen sind. (Kompromiss zwischen Sicherheit und Geschwindigkeit)
• C: Eine Schreiboperation ist erst dann auf dem primären Knoten beendet, wenn die Daten auf dem sekundären Knoten angekommen sind und der primäre eine Schreibbestätigung erhalten hat. (Langsam aber maximale Sicherheit)

Der „fsckcmd“ in sollte auf das eingesetzte Filesystem abgestimmt werden; momentan ist Ext3 integriert

Nun kann auch schon der erste Test folgen:

Auf Node1:

linux:~ # /etc/init.d/drbd start
        

Es erscheint die Frage ob der Knoten der Primäre sein soll, oder ob er warten soll. Wenn diese Frage erschient, gehen sie zum Node2:

linux:~ # /etc/init.d/drbd start
        

Nun müsste eine Meldung mit Statusbalken erscheinen, der den Stand der Synchronisation anzeigt.

Anmerkung: Diese Ausgabe/Frage existiert bei neueren DRBD Versionen nicht mehr

Dies ist allerdings eine statische Anzeige, wenn man eine dynamische Anzeige wünscht, so kann man das auch mit einfachen Mitteln bewerkstelligen:

linux:~ # watch cat /proc/drbd
        

Eine Ausgabe der verschiedenen Zustände kann man hier einsehen: "cat /proc/drbd" Vorsicht ist jedoch beim Neustart geboten: der Knoten mit dem neuesten Datenstand muss immer als erster gebootet werden, da DRBD keine Überprüfung der Daten vornimmt. Wenn die Daten die selben sind, dann wird nur ein Quicksync ausgeführt. Dies ist ersichtlich, wenn die Meldung erscheint: „SyncingAll, but I have the good Data. No need to wait.“

Wenn das Syncen jetzt einwandfrei funktioniert, kann man die Konfiguration von Heartbeat in Angriff nehmen.

Heartbeat Version 2

Für dieses Paket ist es jetzt wichtig, dass es 2 verschiedene Wege zwischen den Knoten gibt, entweder mit je 2 NICs oder mit je einer NIC und einer seriellen Verbindung. Der Test der seriellen Verbindung ist oben schon aufgeführt.

Als erstes ist die Datei „/etc/ha.d/ha.cf“ zu bearbeiten. Unter diesem Link ist eine Beispielkonfiguration einzusehen.

Wichtig sind dort die Werte bei bcast, und node, da sie die Verbindung der Knoten kennzeichnen. Die Optionen keepalive, deadtime, warntime, initdead können verändert werden und dadurch die Umschaltgeschwindigkeit beeinflusst werden. Um die Konfiguration für Version 2 von Heartbeat zu aktivieren, muss die Option „crm“; auf „yes“ stehen

Als nächstes muss festgelegt werden, ob eine Zugriffskontrolle zwischen den Knoten stattfindet. Dies ist in der Datei „/etc/ha.d/authkeys“ festzulegen.

Diese Datei kann erweitert werden, indem man andere Verschlüsselungsmethoden eingibt. In meinem Praxisversuch habe ich „crc“ verwendet, da ich ein Crossover-Kabel als Heartbeat-Leitung verwendet habe und ein Einfluss von Außen somit nicht möglich ist. Ein Nachteil ist jedoch, dass die Passworte im Klartext in dieser Datei stehen und deswegen sollte sie die Zugriffsrechte 600 haben. Zu ändern mit dem Befehl:

linux:~ # chmod 600 /etc/ha.d/authkeys
        

Die gravierenste Änderung zwischen Version 1 und Version 2 ist die Konfiguration der Dienste. Die dafür zuständige Konfigurationsdatei ist „/var/lib/heartbeat/crm/cib.xml“. Dort wird festgelegt auf welchem Knoten welcher Dienst mit welcher IP-Addresse laufen soll. Die Datei muss auf allen Knoten identisch sein.

Wenn man diese XML-Datei genau betrachtet, sieht man einen allgemeinen Block am Anfang der Datei. Dies ist der Block „crm_config“.

Die Sektion „nodes“ gibt die Clusterknoten an, die am Cluster beteiligt sind.

Der große Block „resources“ zeigt die konfigurierten Dienste. Diese sind zu einer Gruppe „heartbeat_group_1“ zusammengefasst.

Zuerst wird die virtuelle IP-Adresse des Clusters definiert.

Anschließend das DRBD-Device auf „primary“ gesetzt, damit es mountbar wird und anschließend das Filesystem gemountet.

Anschließend folgt die Konfiguration für die Fileserver-Dienste Samba und NFS.

Die letzte Sektion sind die „constraints“, die Regeln für die Platzierung der Dienste im Cluster.

Jetzt kann der Test des Heartbeat-Clusters erfolgen.

Auf node1:

linux:~ # /etc/init.d/rcheartbeat start
        

und dannach auf node2:

linux:~ # /etc/init.d/rcheartbeat start
        

Jetzt nochmal die Datei „/var/log/ha-log“ anschauen, ob irgendwelche Fehler aufgetreten sind. Sie ist sehr lang und teilweise sehr unübersichtlich. Wenn dies nicht der Fall ist, dann versuchen sie einen Failover-Fall auszulösen, indem sie mal die Heartbeart-Leitung kappen. Wenn der Dienst nach ungefähr 30 Sekunden wieder da ist, dann haben sie alles richtig gemacht. Ansonsten mal die Logfiles anschauen, auch die Debugfiles, und den Fehler suchen.

Letzte Änderung: 13. Maerz 2012, Historie