Hochverfügbarkeit mit Linux – Teil 1
Als Vorbereitung empfehle ich die Folge 41 des Heldenfunks. In knappen zwei Stunden diskutieren Constantin und Hartmut jedes notwendige Vorwissen bis ins Detail durch. Ein perfekter Einstieg in das Thema Hochverfügbarkeit. (Die zwei Stunden könnten übrigens genutzt werden um nebenher zwei Maschinen mit Debian zu deployen…)
Der Podcast von systemhelden.com
Echte Systemhelden haben immer ein offenes Ohr für echte Lösungen. Darum hört die Stimmen der Energie und Ihr werdet lernen.
Warum man hochverfügbare Dienste möchte ist nun also geklärt, klären wir noch die Begrifflichkeiten:
- Cluster
ein Verbund aus mehreren Blechen die einen oder mehrere gemeinsame Dienste anbieten - Node
ein Mitglied eines Cluster-Verbunds - aktiver Node
ein Node der aktiv einen Dienst ausführt bzw. gebunden hat - standby Node
ein Node der einspringt, sobald ein aktiver Node abgeschaltet wird oder ausfällt - Cluster-Ressource
der zu “clusternde” Dienst, also der Unix-Service, die IP-Adresse oder das Filesystem - Heartbeat
der Prozess den die Nodes nutzen um festzustellen welche anderen Nodes arbeiten (können) “lebst Du noch?“ - Takeover
ein Host wird als tot definiert und seine Ressourcen übernommen
Im “normal”-Zustand würde ein beispielhaftes, sehr simpel gehaltenes Setup in etwa so aussehen:
Es gibt einen aktiven Node der die Cluster-Ressourcen gebunden hat und ein Standby Node daneben der Strom in warme Luft umwandelt.
Sobald der aktive Node ausfällt (oder zur Wartung abgeschaltet wird) übernimmt der Standby Node die Ressourcen und der oder die angebotene(n) Dienst(e) laufen ohne nennenswerte Unterbrechnung weiter.
Im Podcast gut aufgepasst? Richtig, hier gibt es keinen Quorum-Server.
Setup der Nodes:
Die beiden Cluster-Nodes in diesem Artikel heißen “Frasier” und “Niles“:
root@frasier:~# apt-get install heartbeat
root@niles:~# apt-get install heartbeat
In /etc/ha.d/ müssen drei Dateien erstellt werden, z.B. nach den Vorgaben in /usr/share/doc/heartbeat:
/etc/ha.d/authkeys
Schlüssel zur Kommunikation zwischen den Nodes/etc/ha.d/haresources
die Liste der Cluster-Ressourcen inkl. Zuweisung der Nodes/etc/ha.d/ha.cf
Konfiguration des Heartbeat-Daemons
Wichtig: /etc/ha.d/authkeys und /etc/ha.d/haresources müssen auf allen Nodes identisch sein, /etc/ha.d/ha.cf kann spezifische Konfigurationen für jeden Node enthalten. Sehen wir uns die Dateien im Detail an.
/etc/ha.d/authkeys:
1 2 | auth 1 1 sha1 broccoli |
Hier sollten keine großen Erklärungen notwendig sein. Der gemeinsame Schlüssel der Nodes wird als SHA1-Hash des Wortes broccoli konfiguriert.
/etc/ha.d/haresources:
1 2 | frasier IPaddr2::198.18.0.1/32/eth0 \
IPaddr2::198.19.0.1/32/eth1 |
Wir definiere zwei Cluster-Ressourcen, eine IPv4-Adresse für eth0 und eine für eth1. Die Konfiguration für eth0 und eth1 in /etc/network/interfaces geben das korrekte Subnetz vor, daher sollten in den haresources nur /32-Masken genutzt werden (z.B. eth0 mit 198.18.0.0/16 und eth1 mit 198.19.0.0/16). Beide Adressen sollen beim initialen Cluster-Start auf “frasier” gebunden werden.
Eine etwas kompliziertere Version von haresources zur Veranschaulichung:
1 2 3 4 5 6 7 8 9 | frasier IPaddr2::198.18.0.1/32/eth0 \
IPaddr2::198.19.0.1/32/eth1 \
IPaddr2::10.111.222.1/32/eth2.82 \
IPv6addr::2001:db8:0:0:0:0:0:1/128/eth2.103 \
atftpd \
radvd \
isc-dhcp-server \
nfs-kernel-server \
ldirectord |
Für das Heartbeat-Setup stellen sowohl IP-Adressen als auch Unix-Services Ressourcen da. Jene Datei definiert diese Ressourcen. Für jede “Klassen” von Ressourcen gibt es entsprechende Scripte in /etc/ha.d/resource.d. Um einen konventionellen Unix-Dienst (z.B. den isc-dhcp-server in eine Cluster-Ressource zu verwandeln, genügt es das init-Script aus /etc/init.d/ nach /etc/ha.d/resource.d zu linken und den automatischen Start zu unterbinden.
root@frasier:/etc/ha.d/resource.d# update-rc.d isc-dhcp-server remove
root@frasier:/etc/ha.d/resource.d# ln -s /etc/init.d/isc-dhcp-server isc-dhcp-server
/etc/ha.d/ha.cf:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | logfile /var/log/ha-log logfacility local0 keepalive 10 deadtime 100 warntime 60 initdead 360 auto_failback on bcast eth0 mcast eth1 225.0.0.1 694 1 0 ping 198.18.0.201 node frasier node niles |
Alle Werte die in ha.cf nicht definiert werden, werden mit entsprechenden default-Werten gesetzt.
keepalivedefiniert die Zeit zwischen den Heartbeat-Paketen in Sekundendeadtimedefiniert die Zeit in Sekunden, die verstreichen muß, bis ein Node als tot definiert wird. Im Zusammenhang mitkeepalive 10müssen 10 Heartbeat-Pakete verloren gehen, bis der Node deaktiviert wird und gegebenenfalls ein Takeover stattfindet.warntimedefiniert (ebenfalls in Sekunden) die Zeit bis die ersten Log-Meldungen geschrieben werden, falls Heartbeat-Pakete verloren geheninitdeadwann soll beim initialen Start ein Node als tot definiert werden? (Ja, wieder in Sekunden)auto_failbacksoll nach einem Takeover an den Standby wieder auf den ursprünglichen Master geswitcht werden, sofern dieser wieder verfügbar ist?
Die Heartbeat-Pakete können über verschiedene Methoden verschickt werden. Aus der Praxis empfiehlt sich mindestens zwei unterschiedliche Methoden und am besten noch dazu unterschiedliche Transportwege zu nutzen.
bcastverschicke die Heartbeat-Pakete per Broadcast auf dem angegebenen Interfacemcastverschicke die Heartbeat-Pakete per Multicast auf dem angegebenen Interfaceucastverschicke die Heartbeat-Pakete per Unicast über das angebene Interface an die angegebene IP des anderen Nodesserialverschicke die Heartbeat-Pakete über eine serielle Leitung am angegebenentty
In der ping-Direktive können Maschinen angegeben werden, die von allen Cluster-Nodes gepingt werden. Hiermit wird festgestellt ob die Nodes nicht nur sich selbst (per Heartbeat) sondern auch den Rest des Netzwerks “sehen” können. Defekte NICs und LAN-Verbindungen können hiermit sinnvoll erkannt und umgangen werden. Der letzte Teil der ha.cf definiert alle verfügbaren Nodes im Cluster.
Testen des Setups:
Wenn “frasier” und “niles” korrekt konfiguriert sind ist es Zeit den Heartbeat zu starten.
root@frasier:~# /etc/init.d/heartbeat start
root@niles:~# /etc/init.d/heartbeat start
Der initiale Start dauert ein wenig, daher empfiehlt es sich auf beiden Maschinen /var/log/ha-log zu beobachten. Fehlermeldungen werden im Normalfall recht sprechend in der Log-Datei verzeichnet. Wenn alles geklappt hat, wird “frasier” die beiden IPv4-Ressourcen innerhalb von wenigen Minuten binden.
