Ausfallsicherheit ist heutzutage für viele Systeme ein unabdingbares Kriterium. Dies gilt besonders für Dienste, auf die man nicht verzichten kann, weil ansonsten Arbeitsabläufe behindert werden. Ein ausgefallener DHCP-, Proxy-, DNS-, Web- oder Samba-Server bereitet viel Ärger und verursacht Kosten.
Mit Hilfe von linux-ha lässt sich das allerdings sehr einfach und kostengünstig vermeiden. linux-ha steht für Linux High Availability und ist eine Open-Source-Failover-Lösung. Im günstigsten Fall erkennt das Paket einen Ausfall automatisch und fährt vom Anwender unbemerkt ein Backup-System hoch.
Allein bei dem Wort Failover beginnt in den Köpfen vieler Administratoren ein hoher Geldbetrag herumzuspuken, was dank linux-ha jedoch der Vergangenheit angehört. Manche denken vielleicht, linux-ha sei nur eine Bastellösung im Beta-Stadium. Aber auch hier folgt die beruhigende Feststellung: Dieses Projekt ist den Kinderschuhen mittlerweile entwachsen. Und sieht man sich die Webseite genauer an, springen einem sofort renommierte Firmennamen wie IBM, Intel, SUSE oder SGI ins Auge, die linux-ha unterstützen.
Theoretische Funktionsweise
Zum besseren Verständnis sind vorab noch einige Begriffe zu klären.
Ein High Availability Cluster (auch Failover-Lösung) unter linux-ha besteht aus zwei Rechnern. Fällt der Hauptrechner aus, springt der andere ein und übernimmt die konfigurierten Dienste.
Bei einem Computing Cluster oder Distributed Computing Cluster werden die eingehenden Anfragen auf n Systeme verteilt, die sich gemeinsam um diese kümmern.
Bei einem Load Balancing Cluster wird eine eingehende Anfrage jeweils einem der im Cluster befindlichen Rechner zugewiesen, der sich dann alleine um diese Anfrage kümmert. Dieses Verfahren wird gerne und oft bei Webservern mit viel Traffic eingesetzt.
Das Projekt linux-ha arbeitet als Failover-Lösung. Zwei Systeme mit je einer eigenen IP-Adresse sind über einen so genannten Heartbeat (Herzschlag) miteinander verbunden. Das Primärsystem verfügt zusätzlich über eine virtuelle Netzwerkkarte, an die eine Cluster-Adresse gebunden ist. Mit dieser wird im Netzwerk kommuniziert.
Hört das Backup-System den Herzschlag des Hauptsystems nicht mehr, erklärt es dieses für tot und leitet eine Reihe von Maßnahmen ein.
Es fährt eine virtuelle Netzwerkkarte hoch und bindet die Cluster-Adresse an sich. Somit ist eine Änderung bei den Clients nicht nötig, da die ausgefallene IP-Adresse wieder erreichbar ist.
Danach fährt es die Services hoch, die zuvor als redundant konfiguriert wurden. In der Regel geschieht dies so schnell, dass kein Ausfall zu bemerken ist.
Die abhängigen Arbeitsprozesse bleiben unbeeinflusst. Dabei ist es natürlich notwendig, die Dienste der beiden Maschinen identisch zu konfigurieren. Zudem sollten Sie die relevanten Dateien über Scripts regelmäßig abgleichen.
Voraussetzungen
linux-ha lässt sich (derzeit) nur mit zwei Systemen betreiben. Diese müssen allerdings nicht zwingend eine identische Hardware aufweisen. Allerdings sollten die Auswirkungen klar sein, wenn ein unter hoher Last betriebenes System plötzlich durch ein deutlich schwächeres ersetzt wird.
Somit macht es Sinn, ungefähr gleich performante Systeme als Cluster einzusetzen. Doch hier lässt sich Geld sparen. Da das zweite System nur im absoluten Notfall zum Einsatz kommt, können in diesem teure RAID-Komponenten außen vor bleiben.
Der Heartbeat lässt sich entweder über ein Crossover- oder ein serielles Kabel überwachen. Es spricht selbstverständlich nichts dagegen, beides gleichzeitig einzusetzen. Wird die Variante der zweiten Netzwerkkarte eingesetzt, benötigt jedes System logischerweise eine zweite Netzwerkkarte. Diese wird auf ein separates Netzwerk konfiguriert.
Was ist möglich?
linux-ha kann alle Dienste absichern, die über ein Script im Format "Skript start"/"Skript stop" gestartet und gestoppt werden. Man sollte dazu jedoch zunächst einige Überlegungen anstellen.
Es ist einfach, einen Webserver oder eine aggregierte Datenbank, also eine Datenbank, auf die nur lesend zugegriffen wird, auf ein Backup-System zu legen, wenn der Inhalt zwischen Haupt- und Backup-Server synchronisiert ist. Schwierig zu handhaben sind dagegen Dienste, bei denen sich der Inhalt ständig ändert.
Nehmen wir als Beispiel eine MySQL-Datenbank, die häufige Änderungen in Tabellen erfährt. Fällt diese nun aus und wird auf dem Backup-System ein MySQL-Daemon gestartet, fehlt jedweder geänderter Inhalt in den Tabellen. Abhilfe würde beispielsweise ein stündlicher Dump der Datenbank schaffen. Diesen könnte man automatisch per Script auf dem Sekundärsystem einspielen. Das bietet zwar keine vollständige Ausfallsicherheit, aber der Datenverlust beschränkt sich in diesem Fall auf maximal eine Stunde.
Installation
Die Installation läuft ähnlich wie bei allen Paketen unter Linux ab. Es stehen sowohl die Sourcen als auch rpm/deb-Pakete zur Verfügung. SUSE bietet sie direkt auf seiner Website an, für Debian und RedHat finden Sie die Pakete auf Ultramonkey. Natürlich können Sie sich auch selbst daran machen, ein Paket aus dem src.rpm zu erzeugen oder den Sourcecode zu übersetzen. Um aus einem src.rpm ein rpm zu erstellen, soll die Fedora-Variante als Grundlage dienen. Die Datei funktioniert mit allen Fedora-Versionen. Nach dem Herunterladen der letzten stabilen Version namens heartbeat-1.2.3-2.fr.c.1.src.rpm wird diese mit
rpm -i heartbeat-1.2.3-2.fr.c.1.src.rpm
aufgerufen. Dabei entstehen die Dateien /usr/src/redhat/SOURCES/heartbeat-1.2.3.tar.gz und /usr/src/redhat/SPECS/heartbeat.spec. Letztere benötigen Sie, um ein eigenes rpm zu basteln. Wechseln Sie in das Verzeichnis /usr/src/redhat/SPECS/ und rufen rpmbuild auf:
rpmbuild -ba heartbeat.spec
Es werden nun, sofern alle Abhängigkeiten erfüllt sind, auf das System abgestimmte Installationspakete gebaut und im Pfad /usr/src/redhat/RPMS/i386 abgelegt. Wenn Sie Fehlermeldungen über fehlende Pakete erhalten, müssen Sie zunächst diese Pakete holen und nachinstallieren.
Nun können Sie die Pakete wie gewohnt mit
rpm -i heartbeat-pils-1.2.3-2.fr.c.1.i386.rpm heartbeat-stonith-1.2.3-2.fr.c.1.i386.rpm heartbeat-1.2.3-2.fr.c.1.i386.rpm
einspielen. Wollen Sie heartbeat direkt aus den Sourcen kompilieren, nutzen Sie das Script ConfigureMe, welches sich mit den Optionen configure, make, install und package aufrufen lässt. Auch die Standardmethode funktioniert natürlich:
./configure
make
make install
Rufen Sie configure mit der Option --help auf, erhalten Sie die verschiedenen Schrauben, an denen Sie drehen können.
Konfiguration
Insgesamt benötigen Sie drei Konfigurationsdateien für heartbeat, die sich alle im Verzeichnis /etc/ha.d/ befinden müssen. Vor dem Start sind diese Dateien (ha.cf, haresources und authkeys) anzulegen und entsprechend Ihren Bedürfnissen anzupassen.
Die Datei ha.cf beinhaltet alle Konfigurationsoptionen. Hier die wichtigsten Schalter
serial /dev/ttyS0 | Der heartbeat soll über ein serielles Kabel übertragen werden. |
|---|---|
| |
bcast eth1 | Der heartbeat soll über die Netzwerkkarte eth1 übertragen werden. |
keepalive 2 | Setzt das heartbeat-Intervall auf zwei Sekunden. |
warntime 10 | Nach dieser Zeit in Sekunden wird eine "late heartbeat"-Warnung in die Logfiles eingetragen. |
deadtime 30 | Ein Node wird nach 30 Sekunden des Nichtmeldens für tot erklärt. |
initdead 120 | Manchmal braucht das Netzwerk nach einem Neustart einige Zeit, bevor es korrekt läuft. Dieser Parameter behandelt den Neustart-Fall und sollte mindestens zwei Mal so hoch sein wie die normale deadtime. |
baud 19200 | Geschwindigkeit der seriellen Verbindung |
udpport 694 | Bestimmt Portnummer 694 für die Kommunikation über das Netzwerk. Dies ist zugleich der Default-Wert und offiziell bei IANA registriert. |
auto_failback on | Dieser Schalter muss auf on oder off gesetzt sein. Ist der Parameter auf on gesetzt, wird der Master nach dem Zurückkehren wieder als solcher definiert und übernimmt alle Dienste. Ist der Schalter off, so bleibt der Slave das primäre System. |
node linuxha1.tecchannel.de | Exakter Name von Node 1 des HA-Clusters, wie "uname -n" ihn ausgibt. Muss vorhanden sein. |
node linuxha2.tecchannel.de | Exakter Name von Node 2 des HA-Clusters, wie "uname -n" ihn ausgibt. Muss vorhanden sein. |
im Überblick.
Darüber hinaus existieren noch einige optionale Parameter. Diese lassen sich in der Dokumentation von linux-ha nachlesen.
Die Datei haresources
Die Datei haresources muss zwingend auf beiden Rechnern identisch sein! Sie beschreibt die Cluster-Adresse sowie die zu startenden Dienste. Das Angeben einer Cluster-Adresse ist zwingend erforderlich und darf nicht anderweitig in der Netzwerk-Konfiguration auftauchen. Ansonsten steht in dieser Datei genau eine einzige Zeile:
linuxha1.tecchannel.de 192.168.1.100 httpd smb msqld
Diese Zeile sagt Folgendes aus: linuxha1.tecchannel.de hat die Cluster-Adresse 192.168.1.100 und startet in der angegebenen Reihenfolge Apache, Samba und MySQL. Beim Herunterfahren stoppen die Dienste in der umgekehrten Reihenfolge. Auch hier ist es zwingend erforderlich, dass Sie als Rechnernamen eintragen, was "uname -n" als Resultat ausgibt. Die Argumente httpd, smb und mysqld spiegeln die Namen der Start-Scripts für die jeweiligen Dienste wider.
Heartbeat sucht in den Verzeichnissen /etc/ha.d/resource.d und /etc/rc.d/init.d nach diesen Scripts. Sollten diese dort nicht vorhanden sein, kopieren Sie sie dorthin oder legen einen symbolischen Link an. Diese Scripts müssen zwingend nach dem Prinzip "scriptname start" und "scriptname stop" funktionieren. Sie können jedes Script, welches sich wie eben beschrieben verhält, mit linux-ha verwenden. Möchten Sie Ihrem Script zusätzlich ein bestimmtes Argument mitgeben, geschieht dies folgendermaßen.
scriptname::argument
Wollen Sie beispielsweise zusätzlich das Script myscript mit dem Parameter myargument starten, sähe die Zeile in der Datei haresources wie folgt aus:
linuxha1.tecchannel.de 192.168.1.100 httpd smb msqld myscript::myargument
Die Datei authkeys
Über die Datei authkeys legen Sie die Authentisierung zwischen den beiden heartbeat-Systemen fest. Hierfür gibt es drei verschiedene Methoden: crc, md5 und sha1. Welche Sie davon benutzen, hängt von der Einsatzumgebung ab:
Läuft der heartbeat über ein Crossover-Kabel, also ein sicheres, nicht abhörbares Netzwerk, empfiehlt sich crc. Dies ist die schnellste Methode.
Bei einer unsicheren Netzwerkverbindung sollten Sie eine verschlüsselte Übertragung verwenden. Bei md5 belasten Sie die CPU der Systeme am wenigsten, aber mit sha1 erhalten Sie eine bessere Verschlüsselung. Das prinzipielle Format der Datei sieht wie folgt aus:
auth nummer
nummer Methode [Schlüssel]
Beispielsweise stellen Sie so crc als Methode ein:
auth 2
2 crc
Bei md5 und sha1 geben Sie zusätzlich den Schlüssel an:
auth 1
1 md5 I-can-hear-your-heartbeat
auth 1
1 sha1 the-sound-of-you-sweet-to-me
Achten Sie auf die Berechtigungen dieser Datei. Sinnvollerweise sollten Sie die Rechte mit chmod 600einstellen.
Die optionale Datei ipfail
Der Vollständigkeit halber erwähnen wir hier noch die Konfigurationsdatei ipfail. Das dazugehörige Plug-in ipfail versucht, Netzwerkfehler zu erkennen und entsprechend darauf zu reagieren. Normalerweise würde der Backup-Rechner auch bei einem ausgefallenen Netzwerk versuchen, sich als neuer Master zu etablieren. Bei einer lediglich gestörten LAN-Verbindung wäre das aber nicht wünschenswert.
Also verwendet ipfail so genannte Ping-Nodes als Referenz. Sind diese erreichbar, der Master-Rechner aber nicht, ist eine Failover-Situation gegeben. Möchten Sie diese Option nutzen, so finden Sie genauere Informationen in der Dokumentation.
Dokumentation
Die Dokumentation finden Sie, nachdem Sie die Sourcen entpackt haben, im Unterverzeichnis ./doc/. Ein Blick in die gute, englischsprachige Beschreibung der Entwickler lohnt sich. Hier befinden sich die Dateien faqntips, GettingStarted, HardwareGuide und Requirements. Sinnvolle Informationen wie die Belegung eines Crossover-Kabels lassen sich hier nachlesen, anstatt Google bemühen zu müssen.
Stecker A | Stecker B |
|---|---|
| |
Pin # | Pin # |
1 | 3 |
2 | 6 |
3 | 1 |
6 | 2 |
4 | 7 |
5 | 8 |
7 | 4 |
8 | 5 |
Die Datei heartbeat_api beschreibt, wie Sie das Programm in andere Programme implementieren können. Auch finden Sie dort ein start-/stop-script für den Daemon des Programms. Am interessantesten dürfte jedoch das Beispiel-Script einer automatischen Synchronisation von zwei Nodes sein. Dies befindet sich in der Datei rsync.html. Möchten Sie ihre Synchronisation individualisieren, empfiehlt sich auch der Artikel "Automatische Backups mit Linux".
Fazit
Mit linux-ha bieten die Entwickler eine kostengünstige und flexible Lösung für die Implementation von ausfallsicheren Diensten. Allerdings sollte man sich im Vorfeld sehr genaue Gedanken machen, was im Falle eines Failovers passieren soll. Wie schon erwähnt, ist diese Lösung für eine dynamische Datenbank eher ungeeignet, da Sie hier um einen Datenverlust nicht umhinkommen. Für aggregierte Datenbanken sieht die Sache anders aus. Und für statische Dienste wie Webserver, DHCP-Server, Samba-Domain-Controller, Proxy-Server und Firewall gibt es keinen rationalen Grund, Geld für teure proprietäre Failover-Lösungen auszugeben. Der einzige Wermutstropfen ist: Heartbeat lässt sich derzeit nur mit zwei Rechnern betreiben. (jdo/mha)