Im Heartbeat-Cluster ist immer einer der Rechner für die Cluster-IP zuständig.
Armin Roehrl und Stefan Schmiedl
Spätestens seit den Ausfällen von Strato sind hochverfügbare Webserver auch für kleinere Websites ein interessantes Thema geworden. Ein ausfallsicherer Webserver vermeidet nicht nur unnötige Einkommens- und Reputationsverluste, man kann notwendige Updates auch bequem tagsüber ausführen, ein Teilsystem nach dem anderen.
Fällt ein Server aus, muß er so schnell wie möglich durch eine andere Maschine ersetzt werden, am besten transparent für die Clients im Netzwerk. Die Verfügbarkeit eines Server-Systems verbessert sich durch den Einsatz redundanter Teile, wie es bei Intranet-File-Servern mit RAIDs (Redundant Array of Independent Disks) oder auch redunanten Netzteilen praktiziert wird. Ausfälle zentraler Komponenten wie CPU oder Speicher können einen Rechner aber immer noch aus dem Verkehr ziehen.
Wir benützen das Linux-HA Heartbeat [heartbeat] Paket, um aus mehreren eigenständigen Linux-PCs einen hochverfügbaren Linux-Cluster zu machen, in dem sich die Heartbeat-Maschinen gegenseitig beobachten. Bei Versagen eines Hosts wird mittels IP-Übernahme der ausgefallene Rechner sofort durch eine Hot-Standby Maschine ersetzt. In seiner einfachsten Form funktioniert Heartbeat in 2-Node Clustern und unterstützt mehrere Interfaces je Node. Die Reaktionszeit im Sekundenbereich wird allerdings durch eine ziemlich aufwändige Installation und Konfiguration erkauft.
Anschließend wird LVS [LVS] und Eddie[EDDIE], zwei fortgeschrittenere Techniken für n-Node Cluster vorgestellt.
Man nehme:
Im Heartbeat-Cluster ist immer einer der Rechner für die Cluster-IP zuständig.
Die 192er-Adressen sind für die Anbindung an das "normale" Firmennetz gedacht, das 10er-Netzwerk wird durch das Crossover-Kabel realisiert. Die meisten Distributionen ermöglichen über ihre Installationsprogramme hier eine einfache Zuweisung der Karten zu den einzelnen Interfaces. Wenn sich beide Maschinen gegenseitig auf jeweils beiden Adressen anpingen können, sollten die Netzwerkkarten auch im wirklichen Betrieb ihren Dienst tun. Für die serielle Verbindung starten wir auf einer Maschine cat
Wir empfehlen die Installation der aktuellen Version (0.4.9) mittels rpm -ih heartbeat.rpm. Alternativ dazu kann aus dem Tarball auch der Quellcode entpackt und kompiliert werden:
tar -xzvf heartbeat-0.4.9.tar.gz
cd heartbeat-0.4.9
make install
In jedem Fall müssen noch in drei Konfigurationsdateien, die sich normalerweise in /etc/ha.d/ befinden, die lokalen Gegebenheiten eingetragen werden. ha.cf enthält die wichtigsten Parameter für die Kommunikation zwischen den Heartbeat-Maschinen. In haresources werden die Dienste festgelegt, die Heartbeat unterstützen soll. Schließlich wird in authkeys festgelegt, ob und wie die Kommunikation verschlüsselt werden soll.
Unser ha.cf enthält folgende (minimale) Einstellungen:
# Nullmodemkabel
serial /dev/ttyS0 # Anschluss
baud 19200 # Transferrate
# Crossover-Kabel
udp eth1 # Interface des 10er-Netzwerks
udpport 694 # Standard-Portnummer
# Reaktionszeiten
keepalive 2 # Zeitintervall zwischen Heartbeats
deadtime 10 # max. Ausfallzeit
# node listet alle Rechner im Cluster auf, die Namen
# müssen identisch mit dem Ergebnis von 'uname -a' sein.
node linuxha1.linux-ha.org
node linuxha2.linux-ha.org
Wenn wir Apache und Samba hochverfügbar machen wollen, tragen wir die entsprechenden Werte in haresources ein. Diese Datei muss auf allen beteiligten Systemen die gleiche sein und legt neben dem Standardserver (linuxha1) die IP-Adresse des Clusters fest sowie die Dienste, die gestartet werden sollen.
linuxha1.linux-ha.org 192.168.85.3 httpd smb
Nach dem Start des Systems operiert linuxha1 unter der Cluster-Adresse 192.168.85.3 mit Apache und Samba als Diensten. Beim Herunterfahren wird (in umgekehrter Reihenfolge) zuerst Samba und dann Apache angehalten. httpd und smb sollten Start-Skripte in den Verzeichnissen /etc/ha.d/resource.d oder /etc/rc.d/init.d bezeichnen. Diese Skripte müssen den Service mit skript start starten und skript stop beenden. Bei Bedarf können auch weitere Argumente mit meinskript::parameter1 übergeben werden.
Nach dem gleichen Schema ist es übrigens auch möglich, neben der IP-Adresse die Netmask und Broadcast-Adresse der Dienste zu ändern. Wird keine Netmask angegeben, verwendet Heartbeat den der aktuellen Route zugeordneten Eintrag. Näheres findet sich in [gettingstarted].
Heartbeat sucht aus den vorhandenen Ethernet Interfaces eines aus, um die in haresources festgelegten Dienste zu unterstützen. Dafür wird aus der Routing-Tabelle die Least-Cost-Route zur übernommenen IP-Adresse gewählt, bei gleichen Werten wird die zuerst gefundene bevorzugt. Daher wird bei den meisten Konfigurationen die Default Route nur selten verwendet.
Heartbeat ist ein low-level Service und daher sicherheitskritisch: Ein Cracker mit Kontrolle über Heartbeat kann Maschinen beliebig rebooten. Heartbeat-Messages sind im Wesentlichen ASCII-Text und sollten zur Sicherheit verschlüsselt werden.
Heartbeat unterstützt:
Wenn man eine sichere Netzwerkverbindung (wie ein Crossover-Kabel) besitzt, dann wird CRC genügen, das am wenigsten System-Ressourcen braucht. Zur Abschreckung von Gelegenheitstätern kann man sich auf MD5 verlassen. Für den professionellen Einsatz wird wohl das aufwändige SHA1 notwendig sein.
In der schützenswerten (chmod 600) Datei /etc/ha.d/authkeys steht für SHA1
auth 1
1 sha1 "E1nG4nzG3h31m3rSchlu3ss3l"
auth 1
1 md5 "E1nG4nzG3h31m3rSchlu3ss3l"
auth 2
1 crc
Heartbeat wird auf allen beteiligten Rechnern gestartet, der Standardrechner (linuxha1) sollte zuerst aktiviert werden.
Der Aufruf von Hand erfolgt mit /etc/rc.d/init.d/heartbeat start, automatisiert wird er durch folgende Befehle:
cd /etc/rc.d/rc0.d; ln -s ../init.d/heartbeat K01heartbeat
cd /etc/rc.d/rc3.d; ln -s ../init.d/heartbeat S99heartbeat
cd /etc/rc.d/rc5.d; ln -s ../init.d/heartbeat S99heartbeat
cd /etc/rc.d/rc6.d; ln -s ../init.d/heartbeat K01heartbeat
Optionale Kernel-Module, auf die wir hier nicht näher eingehen, müssen auch in /etc/rc.d/rc.sysinit eingetragen werden.
Ein erfolgreicher Start von Heartbeat wird in /var/log/ha-log vermerkt.
INFO: Running /etc/ha.d/rc.d/status status
heartbeat: info: Requesting our resources.
heartbeat: INFO: Running /etc/ha.d/resource.d/IPaddr 192.168.85.3 status
heartbeat: INFO: Running /etc/ha.d/rc.d/ip-request ip-request
heartbeat: info: node linuxha2.linux-ha.org: status up
heartbeat: INFO: Running /etc/ha.d/rc.d/status status
heartbeat: Acquiring resource group: linuxha1.linux-ha.org 192.168.85.3 httpd smb mirror
heartbeat: INFO: Running /etc/ha.d/resource.d/mirror start
heartbeat: INFO: Running /etc/rc.d/init.d/smb start
heartbeat: INFO: Running /etc/rc.d/init.d/httpd start
heartbeat: INFO: Running /etc/ha.d/resource.d/IPaddr 192.168.85.3 start
heartbeat: INFO: ifconfig eth0:0 192.168.85.3 netmask 255.255.255.0 broadcast 192.168.85.255
heartbeat: Sending Gratuitous Arp for 192.168.85.3 on eth0:0 [eth0]
Abweichungen vom gezeigten Beispiel sind natürlich möglich, da die Meldungen stark davon abhängen, welche Dienste gestartet werden und wann Heartbeat auf den anderen beteiligten Rechnern aktiviert wird.
Nach einem erfolgreichen Start sollte man die Cluster-IP-Adresse mit ping 192.168.85.3 erreichen können. Über telnet 192.168.85.3 sollte man auf den Standardrechner (linuxha1) kommen. Anschließend sollten die einzelnen Dienste getestet werden, z.B. in einem Browser als URL http://192.168.85.3 eingeben oder ein Laufwerk unter Samba ansprechen.
Es kann sein, dass jetzt noch ein Fehler wie "SIOCSIFADDR: No such device" auftritt. In diesem Fall liegt es daran, dass der eingesetzte Kernel kein "IP aliasing" unterstützt. Es kann hier auch nicht schaden, sich mit den Masquerading-Fähigkeiten des Kernels bekannt zu machen.
Nun kann der aktive Cluster-Server nach Belieben deaktiviert werden. Abschalten, Kabelbruch, Plattencrash ... Nach 5 bis 10 Sekunden sollte der Cluster wieder auf ein ping 192.168.85.3 antworten. Mit telnet 192.168.85.3 landet man jetzt allerdings auf dem Hot-Standby linuxha2. Wenn es länger als 30 Sekunden dauert, kann man davon ausgehen, dass etwas nicht in Ordnung ist.
Um hunderprozentige Gewissheit zu bekommen, sollte man noch alle Heartbeat-Wege testen. Wenn nach Entfernen des Crossover-Kabels im Heartbeat-Log auf linuxha2 ein Eintrag wie "node linuxha1.linux-ha.org: is dead" vorkommt, funktioniert der serielle Heartbeat nicht und der 2. Node übernimmt. Man sollte das Nullmodemkabel überprüfen und dann die Tests noch einmal laufen lassen. Entsprechend kann man den UDP-Heartbeat durch Entfernen des Nullmodemkabels kontrollieren.
Es wird nicht empfohlen, sowohl Crossover- als auch Nullmodemkabel gleichzeitig zu entfernen, sonst versuchen beide (ansonsten funktionsfähigen) Heartbeat-Rechner, sich mit der Cluster-IP zu identifizieren.
Interessierten Sysadmins empfehlen wir den leicht verständlichen und sehr guten Artikel über Heartbeat [robertson], der auf die technischen Feinheiten von Heartbeat eingeht. Es gibt auch eine Mailingliste [contact] zum Thema High-Availability und Linux, die durch exzellente hilfsbereite Leute glänzt, sowie ein englisches "Getting started"[gettingstarted] von Heartbeat, auf dem auch Teile dieses Artikels beruhen.
Für größere Websites wird der beschriebene Vorgang ein bisschen komplizierter, weil man über load-balancing z.B. Servlets auf mehrere Rechner verteilt und wenn ein Servlet nicht antwortet, die Anfrage automatisch noch einmal an einen anderen Rechner schicken muss. LVS [LVS] ist mit Heartbeat benützbar und versucht, skalierbare, hochverfügbare Server zu erstellen. Die Architektur ist für den Benutzer transparent: Die Aussenwelt sieht nur einen Server.
Dieser Server wird "virtuelle Server" genannt. Die individuellen Server (die wahren Server) sind untder der Kontrolle eines Direktors(praktisch ein L4 Switch) (oder Load Balancers). Der mit einem gepatchten Linux Kernel betrieben wird um den ipvs Code zu beinhalten. Dieser ips-Code ist das Hauptfeature von LVS. VIP ist die Addresse die man load-balancen will, d.h. Die Adresse der Website. Wie vorher auch ist die VIP ein alias, die zischen zwei Direktoren bei Ausfall ausgetauscht werden kann. Hierzu kann Heartbeat eingesetzt werden. Jede VIP ist mit einem oder mehreren Services verbunden. Man kann sogar Gruppen von VIPs erstellen. Falls Zustandsinformation zwischen den einzelnen Requests gespeichert werden muss, wie es z.B. bei https vorkommt ist für LVS auch kein Problem.
________
| |
| client | (local or on internet)
|________|
|
(router)
|
-- |
L Virtual IP
i ____|_____
n | | (director can have 1 or 2 NICs)
u | director |
x |__________|
|
V |
i |
r ----------------------------------
t | | |
u | | |
a | | |
l _____________ _____________ _____________
| | | | | |
S | realserver | | realserver | | realserver |
e |_____________| |_____________| |_____________|
r
v
e
r
Eddie ist ein weiteres hoch verfügbarkeits Clustering Tool das in erlang [ERLANG] geschrieben worden ist. Erlang ist eine Sprache die besonders geeignet ist verteilte Anwendungen zu erstellen.
Eddie erlaubt das automatische Traffic Management und die Konfiguration von Servern, die an geographisch versciedenen Stellen sind und aus einem oder mehreren LANs bestehen.
Für jede Site gibt es einen bestimmten Server, den sogenannten Front End Server (blau in unserer Abbildung). Sie dienen dafür, dass der einkommende Verkehr kontrolliert und vertielt wird auf sogenannte Back End Server (schwarz). Zusätzlich wird ählich wie in einem Batch system der Zustand der Nodes ständig überwacht.
Eddie besteht aus zwei Softwarepackages: Enhanced DNS server: sorg für loadblancing und monitoring von geographisch verteilten Systemen. Intelligent HTTP Gateway, welcher für eine Site
Ausführliche Installationsbeschreibung mit Beispielskonfigurationen findet man hier [EDDIE-INSTALL]. Eine gute technische Beschreibung von Eddie findet man in [whitepaper].
Kommerzielle Hochverfügbarkeits-Cluster unter Linux gibt es zum Beispiel von Linux NetworX. Im besten Fall dauert der Ersatz eines defekten Nodes hier nur zwei Sekunden. Diese kommerziellen Cluster haben den weiteren Vorteil, daß sie mit einem leicht bedienbaren GUI und praxiserprobten Tools zur Clusterkonfiguration und Systensicherheit "ready to run" ausgeliefert werden. Die Clustermanagementmodule (CMM) von NetworX fassen bis zu 4 Prozessoren zu einer Node zusammen und überwachen sogar die Temperaturen der CPUs.
Der schönste Highavailability-Server mit Notstromversorgung und RAID nützt aber nichts, wenn ein Erdbeben die Kabel in den AT&T-Backbone kappt, wie es uns vor ein paar Monaten mit einem System in Seattle passiert ist. Ebenso wirkungslos sind die gezeigten Verfahren gegen DoS Angriffe wie wir sie letzten Jahres gegen Yahoo und einige andere populäre Websites gesehen haben. Hochverfügbarket ist relativ, hilft aber nachts ruhiger zu schlafen.