Linux High Availability
From RADION OpenLab
1 High-Availability-Lösungen: Linux-HA
2 Übersicht
3 Zielsetzung
Dieses Dokument beschäftigt sich mit der Software [[1]], mit deren Hilfe die Hochverfügbarkeit von Diensten, die von einem aus mindestens zwei Servern bestehenden Cluster angeboten werden, gewährleistet werden kann. Neben dem Aufbau und der Beschreibung der einzelnen Komponenten des Softwarepakets steht vor allem die Installation und Konfiguration im Vordergrund. Zusätzlich dazu wird der Funktionsumfang sowie die Leistung der betrachteten HA-Lösung bewertet.
- Anmerkung zu Versionschritt von Heartbeat (Version 1 -> Version 2)**
\\ Vor kurzem wurde der Schritt zu [Version 2] (aktuell: Version 2.0.7) vollzogen. Die neue Version kann mit einer stark erweiterten Funktionalität sowie grundlegenden Änderungen an Aufbau und Architektur aufwarten. Da sich die Dokumentation dazu leider noch im Aufbau befindet und momentan einige Lücken aufweist, ist eine detailierte Beschreibung aller neu hinzugekommener Merkmale noch nicht möglich. Auf die wichtigsten Neuerungen wird im Kapitel Heartbeat Version 2 eingegangen.
4 Aufbau und Funktionsweise
Mit //Linux-HA// können beliebige Dienste hochverfügbar gemacht werden. Mehrere Knoten bilden einen Cluster und tauschen untereinander ping-ähnliche Pakete, sog. Heartbeats, aus, um so Ausfälle erkennen zu können. Hochverfügbare Dienste werden unter speziell dafür vorgesehenen, virtuellen Cluster-IP-Adressen angeboten. Diese IP-Adressen dürfen von keinem Host besetzt sein - sie werden von //Linux-HA// zur Laufzeit dynamisch für bestimmte Knoten des Clusters allokiert. Im Normalbetrieb werden die IP-Adressen dem für die jeweiligen Dienste designierten Master-Knoten zugewiesen. Fällt ein solcher Master-Knoten bzw. dessen Netzwerkanbindung aus, sorgt //Linux-HA// dafür, dass ein anderer Knoten als Failover einspringt und die zwischenzeitlich ausgefallenen Dienste fortan anstelle des Masters unter der selben Cluster-IP anbietet. Für Anfragen von außen ist der HA-Betrieb transparent - die Dienste sind jederzeit unter der gleichen Cluster-IP erreichbar.
//Offizielle Einführung in Linux-HA: [Started], [Started Version 2]//
5 Schlüsselmerkmale
Nachfolgend werden die Schlüsselmerkmale von //Linux-HA// zusammengefasst:
* Gewährleistung der Hochverfügbarkeit beliebiger Dienste * eine Anpassung der Dienste ist in der Regel //nicht// notwendig * active-active- oder active-standby-Konfigurationen möglich * vollautomatische Migration von Diensten zwischen den Knoten * kontrolliertes Abschalten/Neustarten von Knoten durch //STONITH// (Fencing-Mechanismus) * Überwachung von Netzwerkverbindungen mittels //IPFail/////pingd// * GUI für Konfiguration, Administration und Monitoring
\\ Erweiterte Funktionen (ab Version 2):
* Anzahl der Knoten eines Clusters theoretisch unbegrenzt (*) * Überwachung des korrekten Betriebs der Dienste (sofern von dem jeweiligen Dienst unterstützt) * feingranulare Konfiguration für die Anpassung an beliebige Szenarien * neues, XML-basiertes Konfigurationsschema für Cluster-Resourcen * Konfigurationsparameter werden in der sog. //Central Information Base (CIB)// gespeichert. Diese Datenbank wird innerhalb des Clusters vollautomatisch repliziert, wodurch die Administation von einem zentralen Punkt aus erfolgen kann.
//(*) Test mit bis zu 16 Knoten wurden den Entwicklern zufolge erfolgreich durchgeführt.//
\\ //Vollständige Aufstellung aller Funktionen: [FactSheet], [FactSheet Version 2]//
6 Kommunikation
Die Knoten eines Clusters können über //serielle Direktverbindungen// und/oder über //UDP/IP-fähige Netzwerke// mittels Unicast, Multicast oder Broadcast miteinander kommunizieren. Im laufenden Betrieb werden Heartbeats über alle konfigurierten Schnittstellen gleichzeitig versendet. Im Folgenden werden die Verbindungen, die für die Kommunikation der Knoten untereinander zum Einsatz kommen, unter dem Begriff //Kommunikationsnetzwerk// zusammengefasst. Das Netzwerk, über das die Knoten bzw. der Cluster Dienste nach außen hin anbietet, wird als //Dienstnetzwerk// bezeichnet. Selbstverständlich kann dasselbe Netzwerk sowohl für die Kommunikation zwischen den Knoten als auch für das Bereitstellen der Dienste nach außen hin verwendet werden - davon ist jedoch abzuraten, da bei HA-Clustern generell möglichst keine //single points of failure// vorhanden sein sollten.
7 Voraussetzungen für HA-Dienste
Es gelten folgende Voraussetzungen:
* innerhalb eines Cluster müssen mindestens zwei Knoten existieren, die den selben Dienst bei Bedarf gleichermaßen bereitstellen können * es müssen unbelegte IP-Adressen vorhanden sein, die //Linux-HA// als Cluster-IPs verwenden kann * jeder Knoten des Clusters muss in der Lage sein, diese IP-Adressen bei Bedarf anzunehmen * die Dienste, deren Hochverfügbarkeit gewährleistet werden soll, müssen über Initskripte steuerbar sein
8 Komponenten von Linux-HA
//Linux-HA// besteht aus folgenden Komponenten:
- //Heartbeat// (Hauptprogramm) - //IPFail/////pingd// (Erweiterung, Verwendung optional) - //STONITH// (Erweiterung, Verwendung optional) - //GUI// (graphische Administrationsoberfläche, Verwendung optional)
9 1. Heartbeat
[[2]] ist das Herzstück von //Linux-HA//. Es wird auf allen Knoten eines Clusters installiert und überwacht dort mittels ping-ähnlicher Pakete die Verfügbarkeit der anderen Cluster-Knoten. Wird der Ausfall eines Knotens festgestellt, sorgt //Heartbeat// dafür, dass die Dienste des ausgefallenen Knotens, deren Hochverfügbarkeit gewünscht ist, von einem anderen Mitglied der Clusters übernommen werden. Die Intervalle der Erreichbarkeitsüberprüfung, die Umverteilung von Diensten sowie das Verhalten bei erneuter Erreichbarkeit eines zuvor ausgefallenen Knotens lassen sich dabei weitreichend konfigurieren.
10 2. IPFail / pingd
Neben dem Ausfall von Knoten kommen Ausfälle von Netzverbindungen als Ursache für die Nichterreichbarkeit von Diensten infrage. Die Heartbeat-Erweiterung [[3]] kann eingesetzt werden, um dieses Problem zu lösen. //IPFail// prüft den Zustand von Netzwerkverbindungen durch pingen definierter IP-Adressen (bspw. Gateways oder externe Server). Stellt ein Knoten eine Beeinträchtigung seiner Verbindung fest, versucht dieser, die für seine Dienste konfigurierten Failover-Knoten über das Kommunikationsnetzwerk zu kontaktieren. Ist ein Failover-Knoten mit unbeeinträchtigter Konnektivität verfügbar, wird dieser mit der Übernahme der vom Ausfall betroffenen Dienste beauftragt.
Bei Konfigurationen der 2. Generation wird anstelle von //IPFail// der Daemon [[4]] eingesetzt. Dieser besitzt weitaus mehr Fähigkeiten als //IPFail// und kann detailierter konfiguriert werden, die Grundfunktionalität bleibt jedoch gleich.
11 3. STONITH
Die Erweiterung [[5]] (Shoot The Other Node In The Head) sorgt dafür, dass ein einmal als nicht mehr verfügbar deklarierter Knoten durch Steuerung der Stromversorgung dauerhaft außer Betrieb genommen oder neu gestartet wird. Dadurch wird verhindert, dass sich ein im Fehlerzustand befindlicher Knoten unkontrolliert zurückmeldet und wieder Dienste anbietet, die zwischenzeitlich bereits von Failover-Knoten übernommen wurden. Dieser Fall kann bspw. dann eintreten, wenn ein Knoten durch einen fehlerhaften Prozess unter Volllast läuft und seine Dienste dadurch sporadisch verfügbar sind. //STONITH// stellt also sicher, dass ein als "tot" angenommener Knoten auch wirklich tot ist und bleibt, bis ein Neustart oder ein manueller Eingriff durch einen Administrator erfolgt. //STONITH// ist für die Beeinflussung der Stromversorgung auf [Geräte] angewiesen.
Durch den Einsatz von //STONITH// kann außerdem das Eintreten des sogenannten [[6]] weitgehend verhindert werden kann. In diesem Zustand können sich die Knoten des Clusters durch einen Ausfall des Kommunikationsnetzwerkes gegenseitig nicht mehr erreichen und erklären sich daher nach einer definierten Wartezeit gegenseitig als tot. Dies führt dazu, dass jeder Knoten des Clusters entsprechend seiner Konfiguration automatisch als Failover für bestimmte Dienste einspringt. Infolgedessen bieten mehrere Knoten die gleichen Dienste unter der selben Cluster-IP-Adresse innerhalb des Dienstnetzwerkes an, was unter Umständen in der Nichterreichbarkeit der Dienste bis hin zum Ausfall des gesamten Dienstnetzwerkes resultieren kann.
Anders als bei dem an anderer Stelle untersuchten RedHat Cluster Manager (RHCM) wird der Einsatz von STONITH zwar empfohlen, ist aber für den korrekten Hochverfügbarkeitsbetrieb nicht zwingend erforderlich.
12 4. GUI
Für //Linux-HA// ist eine [Benutzeroberfläche] verfügbar, mit deren Hilfe sich die auf den Knoten laufenden Linux-HA-Komponenten komfortabel administrieren und überwachen lassen. Das GUI ist als eigenständige Python-GTK-Anwendung realisiert und kann auf jedem beliebigen Rechner ausgeführt werden, vorausgesetzt, dieser kann eine IP-Verbindung zu den zu überwachenden Knoten aufbauen.
12.1 Installation
Die Installation wird anhand der zum Zeitpunkt der Erstellung dieses Dokuments aktuellen Version //Heartbeat 2.0.7 (stable)// beschrieben. Im [[7]] von //Linux-HA// sind neben den Quellen auch RPMs für zahlreiche Platformen und Architekturen sowie plattformspezifische Installationshinweise erhältlich. Nachfolgend dienen die Quellen als Basis für eine systemweite Installation. Von einer Userspace-Installation durch Beeinflussung der configure-Parameter prefix, with-initdir und with-ocf-root wird ausdrücklich abgeraten - diese Installationsart ist zwar möglich, erwies sich bei Tests aber als unpraktikabel, da sie Probleme mit sich brachte, die nur durch Workarounds gelöst werden konnten.
Sowohl für die systemweite Installation selbst als auch für die spätere Ausführung der Applikation sind root-Rechte erforderlich!
- Herunterladen der Quellen:**
# wget http://linux-ha.org/download/heartbeat-2.0.7.tar.gz
- Installation:**
# tar xvfz heartbeat-2.0.7.tar.gz # cd heartbeat-2.0.7 # ./configure --enable-crm --enable-lrm --enable-mgmt # make install
- Anmerkungen:**
* Alle dem configure-Skript übergebenen Parameter sind für Konfigurationen der zweiten Generation sowie die Installation der Managementdienste (inklusive GUI) vonnöten. Selbst wenn der Einsatz der nur damit nutzbaren erweiterten Funktionen nicht geplant ist, sollte //Heartbeat// mit diesen Optionen kompiliert werden, da sonst der Einsatz des GUIs sowie die zentrale Konfiguration des Clusters von einem beliebigen Host aus nicht möglich ist.
* Die Entwickler von //Linux-HA// empfehlen die Verwendung des beiligenden Skripts ConfigureMe anstelle von configure. Dieses Skript versucht, mittels plattformspezifischen Wissens bezüglich zu verwendender Programmpfade, dem Nutzer die Installation zu erleichtern.
* //Heartbeat// ist von einer Reihe von Paketen abhängig, von denen aber nur das Paket libnet zwingend erforderlich ist. Das Nichtvorhandsein der restlichen Pakete resultiert lediglich in einem eingeschränkten Funktionsumfang (bspw. keine Verschlüsselung der Kommunikation).
* Während der Installation wird der unprivilegierte Nutzer hacluster angelegt. Dieser wird später für die sichere Ausführung einiger Dienste sowie für das Management eingesetzt.
12.2 Konfiguration
Die Konfiguration von //Heartbeat// ist insgesamt sehr anspruchsvoll und stark von dem angestrebten Einsatzgebiet abhängig. Da dies den Entwurf einer allgemeingültigen Konfigurationsanleitung stark erschwert, wird im weiteren Verlauf dieses Kapitels die Konfiguration für einen konkreten, beispielhaften Anwendungsfall beschrieben. Ziel dabei ist, die grundlegenden Funktionen der Applikation zu vermitteln und eine Wissensgrundlage für die Anpassung an komplexere Szenarien zu schaffen.
- Anmerkung:**
\\ Mit //Linux-HA Version 2// wurde ein [Konfigurationsschema] eingeführt. Es muss verwendet werden, wenn die mit dieser Version hinzugekommenen erweiterten Funktionen (u.a. Cluster mit mehr als zwei Knoten, Überwachung des Betriebs der Dienste) zum Einsatz kommen sollen. Von dieser Neuerung ist hauptsächlich die Konfigurationsdatei haresources betroffen - sie entfällt gänzlich und wird durch die sog. [Information Base (CIB)] ersetzt. Die Beschreibung des neuen Konfigurationsschemas wurde nachträglich ergänzt und ist im Kapitel Heartbeat Version 2 zu finden.
Das alte (nachfolgend beschriebene) Schema kann weiterhin eingesetzt werden - die neuen Versionen von //Heartbeat// sind abwärtskompatibel. Es ist sogar empfehlenswert, selbst bei geplantem Einsatz der erweiterten Funktionen zunächst Konfigurationsdateien der ersten Generation zu entwerfen und diese anschließend wie in dem oben erwähnten Kapitel von Hand oder automatisch mit Hilfe des beiligenden [[8]] in das Schema der Version 2 zu überführen. Der Grund für diese Vorgehensweise liegt im Aufbau der neuen Konfigurationsdateien - diese setzen teilweise auf XML und sind von Hand weitaus schwieriger zu erstellen, während die erste Generation auf gewöhnliche, einfach strukturierte Textdateien setzt. Praktisch als "Nebenprodukt" entsteht die Möglichkeit, den Cluster zunächst mit einer "abgespeckten" Konfiguration zu testen. Durch die eingeschränkte Funktionalität lassen sich grundlegende Konfigurationsfehler dabei viel schneller aufdecken als bei den ungleich komplexeren Konfigurationen der 2. Generation.
//Offizielle Konfigurationsanleitung: [Heartbeat]//
12.3 Konfigurationsdateien
Bevor //Heartbeat// gestartet werden kann, müssen drei Konfigurationsdateien erstellt und angepasst werden. Diese drei Dateien werden bei der Installation //nicht// erzeugt. Auf der [[9]] sind [[10]] erhältlich, welche durch ausführliche Kommentierung nahezu selbsterklärend sind.
Konfigurationsdateien von //Linux-HA//:
* /etc/ha.d/ha.cf (Dokumentation [[11]]) * /etc/ha.d/haresources (Dokumentation [[12]]) * /etc/ha.d/authkeys (Dokumentation [[13]])
12.4 Konfigurationsdatei: /etc/ha.d/ha.cf
In der Datei ha.cf werden allgemeine Einstellungen der Betriebsparameter von //Heartbeat// vorgenommen. Die wichtigsten sind:
* Konfiguration von Logdateien * Intervalle und Wartezeiten (Heartbeats, 'Aufgeben' von unerreichbaren Hosts, ...) * Kommunikation über serielle Verbindungen (Baudrate, Devices, ...) * Netzwerkkommunikation (Interfaces, Ports, Uni- und Multicastadressen, Fibre-Channel-Devices, ...) * Festlegung, aus welchen Knoten der Cluster besteht * Konfiguration der Erweiterungen //IPFail/////pingd// und //STONITH//
12.5 Konfigurationsdatei: /etc/ha.d/haresources
Die Angaben in der Datei haresources legen fest, welche Dienste unter welcher Cluster-IP angeboten werden. Weiterhin wird festgelegt, welche Rolle (Master/Failover) die beteiligten Knoten bezüglich eines Dienstes einnehmen.
- Achtung!**
\\ Die Datei haresources muss für alle Knoten exakt gleich sein! Bei Missachtung führt in der Regel zu einem indeterministischen (Fehl-)Verhalten der Software.
12.6 Konfigurationsdatei: /etc/ha.d/authkeys
Durch Änderung der Parameter in der Datei authkeys wird //Linux-HA// mitgeteilt, wie sich die Hosts des Clusters gegenseitig authentifizieren. Zur Verfügung stehen:
* CRC (keine Authentifizierung, lediglich Sicherung der Integrität) * MD5 (Auth. und Integritätssicherung) * SHA1 (Auth. und Integritätssicherung)
- Anmerkung:**
\\ Gilt das für die Kommunikation der Knoten verwendete Netzwerk als sicher (bspw. stand-alone-Netzwerke), kann CRC verwendet werden. Es sichert die Kommunikation gegen Übertragungsfehler und verzichtet auf eine Authentifizierung der Kommunikationspartner, wodurch der Overhead gering gehalten wird.
Die Rechte der Datei authkeys müssen angepasst werden, da //Heartbeat// sonst den Start verweigert:
# chmod 600 /etc/ha.d/authkeys
\\
12.6.1 Beispielanwendungsfall: hochverfügbarer Apache-Webserver
Betrachtet wird folgendes Szenario:
* die Knoten //node1// und //node2// bilden gemeinsam einen Cluster * //Heartbeat// und Apache sind auf beiden Knoten installiert * der Apache-Webserver soll jederzeit unter der Adresse http:/<cluster-ip>:<port> verfügbar sein * Initskript des Apache-Webservers: /etc/init.d/apache2 * beide Knoten sind über eine serielle Leitung verbunden * beide Knoten sind über ein Netzwerk verbunden * zwei externe Hosts, //host1// und host2, dienen als Ziele für die Überprüfung der Netzwerkkonnektivität durch //IPFail//
- Anmerkungen:**\\
* Die für die Verbindungsprüfung verwendeten Hosts dürfen keine Knoten des Clusters sein! Am besten sind Netzwerkelemente wie Server oder Gateways geeignet, deren Erreichbarkeit gleichzeitig die Verfügbarkeit der Netzanbindung signalisiert.
* Eine Beschreibung der Apache-Installation findet sich hier. Um den vorliegenden Fall nachzustellen, sollte auf die in der Anleitung beschriebene Userspace-Installation durch Setzen des prefix-Parameters verzichtet werden!
* //Linux-HAs// Fencing-Mechanismus //STONITH// konnte mangels geeigneter Hardware nicht in die Tests einbezogen werden.
12.7 Anpassung von /etc/ha.d/ha.cf
Für den vorliegenden Anwendungsfall ergibt sich folgende Konfiguration:
# Debug-Ausgaben in Dateien umleiten für Überprüfung des Betriebs debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 # Die Einheit aller folgenden Zeitangaben ist Sekunden! # Heartbeatintervall keepalive 2 # Zeit, nach der Warnungen ausgegeben werden, # wenn Hosts nicht mehr antworten warntime 10 # Zeit, nach der nicht erreichbare Hosts als tot gelten deadtime 30 # Wartezeit, bis Heartbeat nach dem Start mit der Überprüfung # der Erreichbarkeit anderer Hosts beginnt. Dies ist wichtig, # da Heartbeat ggf. auf anderen Hosts auch erst noch gestartet # werden muss. initdead 90 # Konfiguration des Kommunikationsnetzwerkes # Broadcasts über eth0 bcast eth0 udpport 694 # Kommunikation über serielle Schnittstelle serial /dev/ttyS0 baud 19200 # Konfiguration des Clusters # Ein zuvor ausgefallener Master-Knoten übernimmt # wieder seine Dienste, wenn er sich zurückmeldet auto_failback on # Cluster besteht aus node node1 node node2 # Konfiguration von IPFail # IPFail aktivieren # Sollte der Prozess beendet werden (bspw. durch kill # oder Absturz), wird er automatisch neu gestartet. respawn hacluster /usr/lib/heartbeat/ipfail # Externe Hosts für Verbindungsprüfung festlegen # # Die für die Verbindungsprüfung verwendeten Hosts dürfen keine # Knoten des Clusters sein! Am besten sind Netzwerkelemente wie # Server oder Gateways geeignet, deren Erreichbarkeit gleichzeitig # die Verfügbarkeit der Netzanbindung signalisiert. ping host1 ping host2
12.8 Anpassung von /etc/ha.d/haresources
Konfiguration für zugrundeliegendes Szenario:
# Der Cluster soll den Dienst "Apache-Webserver" unter # der IP-Adresse 192.168.1.11 anbieten # # Master-Knoten ist node1 # Sofern node1 verfügbar und seine Verbindung nach außen # unbeeinträchtigt ist, wird dieser den Apache-Webserver # ausführen. # # Der hier nicht erwähnte Knoten node2 übernimmt implizit # die Rolle des Failovers node1 192.168.1.11 apache2
12.9 Anpassung von /etc/ha.d/authkeys
SHA1 bietet die höchste Sicherheit gegen Spoofing-Attacken und kommt daher hier zum Einsatz:
# Verwende SHA1 für die Authentifizierung # Das Schlüsselwort wird zufällig gewählt auth 1 1 sha1 Ajv672HJ672G219fgjn2s7n
12.9.1 Inbetriebnahme
Nach Abschluss der Konfiguration ist die Software prinzipiell einsatzbereit. Vor dem Starten sollten jedoch einige Tests durchgeführt werden, um sicherzustellen, dass alle konfigurierten Resourcen vorhanden und für alle Knoten erreichbar sind. Für die Tests reichen einfache Unix-Bordmittel aus.
\\ **Testen der Netzwerkverbindungen:**
\\ Die Netzwerkverbindungen können mittels ping getestet werden. Jeder Knoten des Clusters muss jeden anderen Knoten und die für die Verbindungsüberprüfung durch //IPFail// verwendeten Hosts erreichen können.
\\ **Testen der seriellen Verbindungen:**
\\ Kommen serielle Verbindungen zum Einsatz, sollte vorher geprüft werden, ob eine Datenübertragung möglich ist. Zum Testen der in der Beispielanwendung verwendeten seriellen Verbindung /dev/ttyS0 können folgende Befehle genutzt werden:
Auf node1: # cat /dev/ttyS0 Auf node2: # echo "test" > /dev/ttyS0
Bei node1 sollte der von node2 gesendete String "test" im Terminal erscheinen.
\\ **Testen der Dienste:**
\\ Keinesfalls fehlen darf ein Test der Dienste, die mittels //Linux-HA// hochverfügbar gemacht werden sollen. Dabei gilt zu prüfen, ob sich die Dienste über die zugehörigen Initskripte starten und stoppen lassen und nach dem Start wie erwartet arbeiten. Nachfolgend wird der im Beispielanwendungsfall betrachtete Apache-Webserver auf beiden Knoten des Clusters getestet:
# /etc/init.d/apache2 start # wget localhost:<port> # /etc/init.d/apache2 stop
Der Apache-Webserver sollte sich auf beiden Knoten starten und stoppen lassen und bei Ausführen von wget die Startseite ausliefern.
\\ **Starten von Heartbeat:**
\\ Wenn alle Tests erfolgreich erfolgreich verlaufen sind, kann //Heartbeat// gestartet werden. Nach dem Start nimmt der Dienst erst nach Ablauf der bei der Konfiguration eingestellten Wartezeit initdead seine eigentliche Arbeit auf - davor wird weder die Erreichbarkeit von Hosts geprüft noch werden Dienste angeboten. Um zu verhindern, dass einzelne Knoten andere Mitglieder der Clusters vorschnell als tot deklarieren und mit der Resourcenumverteilung beginnen, muss //Heartbeat// möglichst zeitnah auf allen Knoten gestartet werden.
# /etc/init.d/heartbeat start
\\ **Überwachen des Betriebs:**
\\ Für die Überwachung des Betriebs eignen sich die Logdateien, in die //Linux-HA// aussagekräftige Informationen und Fehlermeldungen schreibt. Die Position der Logdateien ergibt sich aus der Konfiguration. Der Inhalt der im Beispielanwendungsfall verwendetene Logdateien lässt sich wie folgt anzeigen:
# tail -f /var/log/ha-log bzw. # tail -f /var/log/ha-debug
Debugging-Informationen werden so in Echtzeit auf der Konsole angezeigt. Anhand der Ausgaben sollte zunächst geprüft werden, ob alle beteiligten Hosts (sowohl externe als auch Cluster-Knoten) und Interfaces als //up// angezeigt werden. Externe Hosts, die korrekt auf Anfragen antworten, müssen mit dem Status //ping// versehen sein. Nach Ablauf der Zeit initdead muss auf den Master-Knoten das Starten der konfigurierten Dienste beobachtbar sein.
Der Cluster sollte nun wie gewünscht die konfigurierten Dienste hochverfügbar anbieten. Zum Testen des Apache-Webservers des Beispielanwendungsfalls kommt wieder wget zum Einsatz. Es gilt darauf zu achten, dass für diesen Test auch wirklich die Cluster-IP und nicht etwa die Adresse eines Knotens verwendet wird!
# wget <cluster-ip>:<port>
12.9.2 Testläufe / Verhalten der Software
//Linux-HA// wurde zahlreichen Tests unterzogen, um die Funktionsweise und die Stabilität überprüfen und bewerten zu können. Grundlage für die Test war die im Abschnitt Konfiguration eingeführte Beispielanwendung (zwei Knoten, Apache-Webserver). Sofern nicht anders lautend beschrieben, gelten für alle Tests folgende Voraussetzungen:
* alle Verbindungen sind verfügbar und störungsfrei * jeder Knoten kann jeden anderen Knoten erreichen * alle externen Hosts sind verfügbar und für die Knoten erreichbar * alle Dienste lassen sich starten, stoppen und arbeiten zur Laufzeit störungsfrei * alle Reaktionen treten zeitnah, d.h. ohne nennenswerte Verzögerung ein
12.9.3 Tests bei Inbetriebnahme
13 Testszenario 1: Zeitnahes Starten von Heartbeat auf beiden Knoten
* //Heartbeat// startet korrekt auf beiden Knoten * die Knoten erkennen einander und beginnen zu kommunizieren * node2 signalisiert seine Bereitschaft, bei Bedarf als Failover einzuspringen * nach Ablauf der Zeit initdead startet node1 den Apache-Webserver\\ und bietet ihn fortan unter der konf. Cluster-IP an
//**Ergebnis:** \\ Heartbeat nimmt wie erwartet seinen Dienst auf.// \\ \\
14 Testszenario 2: Starten von Heartbeat zunächst nur auf Master
* //Heartbeat// startet korrekt auf node1 * node1 erklärt node2 nach Ablaub von initdead für tot * node1 startet Apache und bietet diesen unter der konf. Cluster-IP an
Nach Starten von //Heartbeat// auf Failover node2:
* node1 erkennt node2 * node2 signalisiert Bereitschaft, bei Bedarf Dienste von node1 übernehmen zu können * node1 bietet seinen Dienst weiterhin und ohne Unterbrechung an
//**Ergebnis:** \\ Das verspätete Hinzukommen des Failovers bereitet Heartbeat keinerlei Probleme.// \\ \\
15 Testszenario 3: Starten von Heartbeat zunächst nur auf Failover
* //Heartbeat// startet korrekt auf node2 * nach Ablauf von initdead wird node1 für tot erklärt * node2 springt unverzüglich als Failover ein und startet Apache
Nach Starten von //Heartbeat// auf Master node1:
* node2 erkennt node1 (direkt nach Start) * node2 stoppt Apache und gibt Cluster-IP frei * node1 übernimmt Cluster-IP und startet Apache
//**Ergebnis:** \\ Der Dienst wird zunächst durch den Failover bereitgestellt und nach Hinzukommen den Masters wie erwartet von diesem übernommen.// \\ \\
15.1 Tests im laufenden Betrieb
16 Testszenario 4: Stören der seriellen Verbindung
* die serielle Verbindung wird durch Abziehen eines Steckers gestört * beide Knoten erkennen den Ausfall der serielle Verbindung nach Ablauf von deadtime
* die Wiederherstellung der Verbindung wird von beiden Knoten sofort erkannt, Heartbeats werden fortan auch wieder über die serielle Leitung ausgetauscht.
//**Ergebnis:** \\ Es kommt zu keinerlei Beeinflussung der Dienste, da Heartbeats während des Ausfalls weiterhin über das Netzwerk ausgetauscht werden können.// \\ \\
17 Testszenario 5: Stören der Netzwerkverbindungen
- Stören der Netzwerkverbindung des Masters node1:**
* die Netzwerkverbindung von node1 wird durch Abziehen eines Steckers gestört * node1 stellt fest, dass die externen Hosts sowie node2 nicht mehr über das Netzwerk erreichbar sind (nach Zeit deadtime) * node1 kommuniziert mit node2 über die serielle Verbindung * node2 signalisiert, dass er über eine funktionierende Netzwerkverbindung verfügt und als Failover einspringen kann * node1 übergibt die Ausführung von Apache an node2
Wiederherstellung der Netzwerkverbindung:
* node1 erkennt erneute Konnektivität * node2 übergibt Ausführung von Apache zurück an node1
//**Ergebnis:** \\ Der Dienst ist vom Auftreten der Störung bis zur Übernahme durch node2 nicht verfügbar. Die Dauer beträgt (deadtime + x), wobei x die für den Diensttransfer benötigte Zeit bezeichnet. x hängt logischerweise vom zu transferierenden Dienst sowie von der Leistung der verwendeten Platform ab und wird daher an dieser Stelle nicht näher spezifiziert.//
\\ **Stören der Netzwerkverbindung des Failovers node2:**
* node2 signalisiert seinen Verlust über die serielle Leitung\\ und steht bis auf weiteres nicht mehr als Failover zur Verfügung * der Apache-Webserver wird weiterhin von node1 ausgeführt
//**Ergebnis:** \\ Keinerlei Beeinträchtigung des Dienstes.//
\\ **Stören beider Netzwerkverbindungen (node1 und node2):**
* verliert node2 seine Netzwerkverbindung vor node1, passiert nichts. node2 signalisiert seinen Verlust über die serielle Verbindung und kommt somit für node1 nicht mehr als Failover in Frage. Verliert nun auch node1 seine Netzwerkverbindung, verbleibt die Ausführung von Apache bei diesem.
* verliert node1 seine Netzwerkverbindung zuerst, wird der Dienst zu node2 transferiert. Verliert nun auch node2 seine Anbindung, verbleibt der Dienst bei diesem.
* bei Wiederherstellung der Netzwerkverbindungen wird derjenige Knoten mit der Dienstausführung betraut, der zuerst die Konnektivität wiedererlangt. Sind beide Anbindungen wiederhergestellt, erhält der Master das Dienstausführungsrecht.
//**Ergebnis:** \\ Der Apache-Webserver ist maximal für die Dauer (deadtime + x) nicht erreichbar.//
\\ **Stören der Netzwerkverbindung zu externen Hosts:**
* die Netzwerkverbindungen zu den externen Hosts werden getrennt. Die Knoten können sich aber untereinander nach wie vor erreichen. * es passiert nichts, da keiner der beiden Hosts eine "bessere" Anbindung vorweisen kann. Die Dienstausführung verbleibt beim Master.
* verliert nur einer der beiden Knoten die Verbindung zu den externen Hosts, sieht er seine Verbindung nach außen als gestört an. Die Dienstausführung wird dem jeweils anderen Knoten übertragen. Bei Wiedererreichbarkeit der externen Hosts übernimmt der Master die Ausführung des Webservers.
//**Ergebnis:** \\ Der Dienst ist maximal für die Dauer (deadtime + x) nicht erreichbar.// \\ \\
18 Testszenario 6: Gleichzeitiges Stören beider Verbindungsarten
* die serielle Verbindung sowie die Netzwerkverbindung der beiden Knoten wird getrennt * es kommt zum //split-brain-Zustand//: beide Knoten erklären sich gegenseitig nach der Zeit deadtime für tot und übernehmen beide die Ausführung von Apache * bei Wiederherstellung einer oder beider Verbindung erkennen die Knoten den //split-brain-Zustand// und veranlassen einen kompletten Neustart der Anwendung. Nach dem Neustart bietet wie gehabt nur der Master den Dienst an.
//**Ergebnis:** \\ Wird für das Anbieten des Dienstes ein Netzwerk verwendet, welches //Linux-HA// unbekannt, d.h. nicht Teil des Kommunikationsnetzes ist und folglich nicht für die Übertragung von Heartbeats verwendet wird, kann es im [[14]] zu einer Beeinträchtigung dieses Netzes kommen, da beide Knoten gleichzeitig versuchen, die selbe Cluster-IP zu belegen. Ob der Dienst unter diesen Umständen verfügbar ist oder nicht, ist nicht vorauszusehen. Durch den Einsatz des Fencing-Mechanismus //STONITH// kann der split-brain-Zustand vermieden werden.// \\ \\
19 Testszenario 7: Stören der Dienste
- Stören des Apache-Webservers:**
* der Apache-Webserver wird mittels kill beendet * eine Reaktion bleibt aus. Bei Konfigurationen der Version 1 erfolgt keine Überwachung der korrekten Ausführung der hochverfügbaren Dienste durch //Linux-HA//.
//**Ergebnis:** \\ Der Dienst geht verloren und kann nur durch manuellen Eingriff wiederhergestellt werden.// \\
\\ **Stören von Heartbeat:**
* //Heartbeat// wird mittels kill -9 auf dem Master node1 beendet * der Apache-Webserver ist zunächst nicht betroffen und wird weiterhin von node1 angeboten * nach der Zeit deadtime erkennt node2 den Ausfall von node1 und startet seinerseits Apache
* beide Knoten bieten nun den Apache-Webserver unter der selben Cluster-IP an (!). Im Test beantwortete node2 fortan die Anfragen von außen. * nach Neustarten von //Heartbeat// auf node1 übernimmt dieser wieder die Ausführung von Apache. Im Test war der Dienst nun reproduzierbar nicht mehr erreichbar, erst das Löschen des ARP-Caches auf dem für die Inanspruchnahme des Dienstes verwendeten Hosts schaffte Abhilfe.
//**Ergebnis:** \\ Der Dienst geht unter Umständen verloren und kann nur durch manuellen Eingriff wiederhergestellt werden. Weiterhin gilt das unter Testszenario 6 Gesagte.// \\
\\ **Stören von //IPFail// oder //STONITH//:**
* bei Beenden von //IPFail// oder //STONITH// mittels kill wird diese Störung sofort von //Heartbeat// erkannt und durch erneutes Starten umgehend behoben.
//**Ergebnis:** \\ Es kommt zu keiner Beeinträchtigung des Dienstes.// \\ \\
19.1 Heartbeat Version 2
In der Einleitung dieses Dokuments kam der kürzlich vollzogene Versionschritt von //Heartbeat// und die damit einhergehenden Neuerungen bereits zur Sprache. Dieses Kapitel beschreibt nun die Vorgehensweise, mittels derer Konfigurationen nach dem neuen Schema entworfen und somit die mit der [2] eingeführten erweiterten Funktionen eingesetzt werden können. Offizielle Einführung in //Linux-HA Version 2//: [Started Version 2]
Ausgehend von einer nach dem Schema der [1] vollständig eingerichteten und konfigurierten Installation von //Heartbeat// sind nur wenige Änderungen notwendig, um die Migration zu Version 2 zu vollziehen. Aufgrunddessen baut die nachfolgende Beschreibung auf den vorangegangenen Kapiteln auf. Diese sollten unbedingt durchgegangen und verstanden werden, bevor die nachstehenden Anpassungen durchgeführt werden.
19.2 Änderungen bzgl. der Installation
Für die Bereitstellung der neu hinzugekommenen Funktionen ist //Heartbeat// auf eine Vielzahl ebenfalls neu in Erscheinung getretener Dienste angewiesen. Diese werden bei der Installation nur dann berücksichtigt, wenn das configure-Skript entsprechende Anweisungen erhält. Im Kapitel Installation wurde bereits auf die erforderlichen Parameter eingegangen. Sollten diese bei der Installation vergessen oder bewusst weggelassen worden sein, ist eine Neuinstallation notwendig, bevor mit dem nächsten Abschnitt fortgefahren werden kann.
19.3 Migration der Konfiguration
Nachdem sichergestellt ist, dass die notwendigen Komponenten korrekt installiert wurden, muss nun die bereits vorhandene Konfiguration auf das neue Schema umgestellt werden. Die aus der Version 1 bekannten Konfigurationsdateien behalten auch weiterhin ihre Gültigkeit, müssen aber teilweise angepasst werden. Um die durchzuführenden Änderungen und deren Auswirkungen leichter verständlich zu machen, sind nachstehend die in das neue Schema konvertierten Konfigurationsdateien der bekannten Beispielanwendung aufgeführt.
19.4 Konfigurationsdatei: /etc/ha.d/ha.cf
Für den Beispielanwendungsfall ergibt sich folgende, leicht veränderte Konfiguration:
# Debug-Ausgaben in Dateien umleiten für Überprüfung des Betriebs debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 # Die Einheit aller folgenden Zeitangaben ist Sekunden! # Heartbeatintervall keepalive 2 # Zeit, nach der Warnungen ausgegeben werden, # wenn Hosts nicht mehr antworten warntime 10 # Zeit, nach der nicht erreichbare Hosts als tot gelten deadtime 30 # Wartezeit, bis Heartbeat nach dem Start mit der Überprüfung # der Erreichbarkeit anderer Hosts beginnt. Dies ist wichtig, # da Heartbeat ggf. auf anderen Hosts auch erst noch gestartet # werden muss. initdead 90 # Konfiguration des Kommunikationsnetzwerkes # Broadcasts über eth0 bcast eth0 udpport 694 # Kommunikation über serielle Schnittstelle serial /dev/ttyS0 baud 19200 # Konfiguration des Clusters # Ein zuvor ausgefallener Knoten übernimmt wieder seine Dienste, # sobald er sich zurückmeldet und seine Arbeit im Cluster wieder- # aufnimmt auto_failback on # autojoin-Funktion aktivieren: # Die Festlegung der am Cluster beteiligten Knoten ist nicht # mehr erforderlich, sie finden sich automatisch. Sind innerhalb # eines Subnetzes mehrere HA-Cluster geplant, kann die Zuweisung # der Knoten zu einem Cluster wie zuvor manuell erfolgen: # # node node1 # node node2 # ... ... autojoin any # Konfiguration von pingd # (ersetzt IPFail in den Konfigurationen der 2. Generation) # pingd aktivieren apiauth pingd uid=hacluster respawn hacluster /usr/lib/heartbeat/pingd -m 100 -d 5s # Externe Hosts für Verbindungsprüfung durch pingd festlegen # # Die für die Verbindungsprüfung verwendeten Hosts dürfen keine # Knoten des Clusters sein! Am besten sind Netzwerkelemente wie # Server oder Gateways geeignet, deren Erreichbarkeit gleichzeitig # die Verfügbarkeit der Netzanbindung nach außen hin signalisiert. ping host1 ping host2 # optional: Festlegung ganzer ping-Gruppen anstelle einzelner Hosts # ping_group <Name> <IP1> <IP2> <...> # # Bsp.: ping_group group1 192.168.1.10 192.168.13.12 # Content Resource Management (CRM) aktivieren # # Der CRM-Daemon ist das Herzstück des neuen Linux-HA. Er sorgt # für die Verwaltung aller Ressourcen (Hosts, Dienste, STONITH- # devices etc.) Weitere für die erweiterten Funktionen benötige # Dienste wie ccm, cib, lrmd und mgmtd werden durch Aktivieren des # CRMs automatisch geladen. crm yes
19.5 Konfigurationsdatei: /etc/ha.d/haresources
Die Datei haresources wird in der neuen Version von der [(Cluster Information Base)] abgelöst und daher nicht mehr verwendet. Auf manchen Systemen mislang der Start von //Linux-HA// (Abbruch mit Fehlermeldung), wenn die Datei gänzlich gelöscht wurde. Sollte dies der Fall sein, kann ein Dummy angelegt werden:
# Die Datei haresources wird bei Konfigurationen der Version 2 nicht # mehr benötigt, muss aber existieren, da der Start von Heartbeat # sonst u.U. mit einer Fehlermeldung abgebrochen wird.
19.6 Konfigurationsdatei: /etc/ha.d/authkeys
An der Konfigurationsdatei authkeys müssen keine Änderungen vorgenommen werden, sie bleibt in ihrer Ursprungsform bestehen.
19.6.1 Erforderliche Patches
Auf den für die Bewertung von //Linux-HA// eingesetzten Testsystemen konnten die Unterstützung für die erweiterten Funktionen sowie die [Benutzeroberfläche] erst nach langwieriger Analyse der Logdateien sowie den Einsatz von Debuggern erfolgreich aktiviert werden. Bei Aktivierung des //CRM// über die entsprechende direktive in der Datei ha.cf kam es zunächst während des Betriebes zu Ausfällen von Diensten, einige starteten erst gar nicht. Der Fehler konnte letztendlich lokalisiert werden: die betroffenen Dienste müssen auf Dateien und Verzeichnisse zugreifen können, für die sie standardmäßig aber keinerlei Rechte besitzen. Folgende Anpassung der Rechte schaffte Abhilfe (root-Rechte erforderlich):
# chown -R hacluster:hacluster /var/lib/heartbeat # chown -R hacluster:hacluster /var/run/heartbeat
\\ Die nächste Hürde stellte die Inbetriebnahme des GUIs dar. Zwar ließ sich dieses problemlos starten, ein Einloggen auf den HA-Cluster wurde jedoch stets mit der Begründung abgelehnt, die Kombination aus Benutzer und Passwort sei falsch. Tief in der Dokumentation verborgen lag der Hinweis, dass die für das Management verwendeten Benutzer Mitglieder der Gruppe haclient sein müssen. Diese Gruppe wird bei der Installation von //Linux-HA// jedoch nicht angelegt. Mittels folgender Befehle kann dies nachgeholt werden (root-Rechte erforderlich):
# groupadd haclient # gpasswd -a hacluster haclient
- Anmerkung:**
\\ Es darf nicht vergessen werden, dem Benutzer hacluster ein Passwort zu geben, da ein Loginversuch ohne gesetztes Passwort fehlschlägt. Mit der Anweisung passwd hacluster kann ein Passwort vergeben werden. Natürlich muss kann für das Management ein beliebiger Nutzer-Account verwendet werden. Voraussetzung ist lediglich die oben erwähnte Gruppenmitgliedschaft.
19.6.2 Konfiguration des HA-Clusters mit Hilfe des GUIs
Ähnlich wie bei der HA-Lösung RedHat Cluster Manager (RHCM) wird bei //Linux-HA// ab der Version 2 die Verwendung der graphischen Benutzeroberfläche für die Konfiguration des HA-Clusters ausdrücklich empfohlen. Zwar kann nach wie vor durch das manuelle Editieren von Dateien Einfluss auf die Konfiguration genommen werden, deren XML-basierter Aufbau macht dies jedoch wenig praktikabel.
- Position der Cluster-Konfiguration (verwaltet von CIB):**
# /var/lib/heartbeat/crm/cib.xml
20 Inbetriebnahme
Im Unterschied zu //RHCM// kann das GUI von //Linux-HA// nur dann verwendet werden, wenn //Heartbeat// in Betrieb ist. Nach dessen Start (s. Kapitel Inbetriebnahme) kann die eigentliche Konfiguration des Clusters und der von diesem bereitzustellenden Dienste erfolgen. Die graphische Administrationsoberfläche wird durch den Befehl
# /usr/lib/heartbeat/haclient.py
aufgerufen. Root-Rechte sind //nicht// erforderlich, da der innerhalb des Programms für das Einloggen auf den HA-Cluster verwendete Account die Rechte bestimmt. Es gilt zu beachten, dass das Einloggen nach dem (Neu-)Start von //Heartbeat// erst nach Verstreichen der Zeit initdead möglich ist, da vorher der für die Administration zuständige Daemon mgmtd nicht ausgeführt wird.
21 Benutzung
Das graphische Administrationsinterface unterscheidet sich, abgesehen von dem notwendigen Einloggen, nicht sonderlich von dem des //RedHat Cluster Managers//. Wie bei diesem auch kann die Benutzung intuitiv geschehen, die Konfiguration der für den Beispielanwendungsfall notwendigen Ressourcen und Dienste ist mit wenigen Mausklicks erledigt. Auf Grund dieser Tatsache wird auf die Verwendung des GUIs an dieser Stelle nur stichpunktartig eingegangen. Auch hier wird auf die bereits in den vorherigen Kapiteln als Anschauungsmaterial verwendete Beispielanwendung Bezug genommen.
\\ **//Einloggen//** \\ Der Menüpunkt Connection -> Login... öffnet das Loginfenster. In das Eingabefeld //Server// ist die Adresse des Knotens einzutragen, der für die Administration genutzt werden soll. Der verwendete Account muss auf diesem Rechner logischerweise als Nutzer vorhanden sein!\\ \\ Linux-ha 2.jpg
\\ **//Hauptfenster//**
\\ Ist der Loginvorgang erfolgreich abgeschlossen, erscheint das Hauptfenster. Die Statusanzeige ist in die Konfiguration integriert und wird für jedes Element durch ein Icon und ggf. zusätzlichen Text repräsentiert (im Beispiel gut an den Elementen //node1// und //node2// zu erkennen). Angezeigte Elemente (Auswahl):
* Hosts: Knoten sowie die von //IPFail// verwendeten Hosts. Letztere erscheinen stets als offline, was den Betrieb aber nicht weiter beeinflusst. Das Hinzufügen bzw. Entfernen von Knoten erfolgt ausschließlich durch manuelles editieren von ha.cf * Ressourcen: Initskripte, IP-Adressen, Mounts, STONITH-Devices uvm. * Gruppen: Gruppierung von Ressourcen
\\ **//Hinzufügen von Ressourcen//**
\\
Mittels Rechtsklick auf Resources -> Add New Item -> Ok (Item Type: native auswählen) können Ressourcen hinzugefügt werden. Es erscheint ein weiteres Fenster für die Konfiguration der hinzuzufügenden Ressource. Im Feld Type werden neben einigen integrierten Diensten wie IP-Adressen und Filesystemen praktischerweise auch alle auf dem System vorhandenen Initskripte eingeblendet. Im Screenshot sind die für die Konfiguration des Apache-Webservers notwendigen Eingaben zu sehen. Ein Klick auf Add fügt die neue Ressource hinzu.\\ \\ Linux-ha 4.jpg
\\ Nach Hinzufügen des Apache-Webservers muss nun noch die Cluster-IP, unter der der Dienst später angeboten werden soll, ergänzt werden. Um dies zu erreichen, wird die Adresse als weitere Ressource angelegt:\\ \\ Linux-ha 5.jpg
\\ //Wichtig://
\\ Nur wenn alle im Hauptfenster aufgelisteten Knoten verfügbar sind, können Ressourcen problemlos hinzugefügt werden. Ist dies nicht der Fall, kann es zum Absturz bzw. Stehenbleiben von //Heartbeat// kommen!
\\ **//Ausführen der Cluster-Dienste//**
\\ Sind alle Ressourcen konfiguriert, kann der Cluster seinen Dienst aufnehmen. Ein Rechsklick auf resource_ipapache2 -> Start veranlasst //Linux-HA//, alle Dienste der Gruppe einem der Knoten zuzuweisen und darauf zu starten. Gelegentlich bleibt der Anklicken der IP-Ressource ohne Wirkung, in diesem Fall sind die gleichen Schritte mit der Dienst-Ressource bzw. dem Gruppeneintrag durchzuführen. Das Ergebnis sollte so aussehen: \\ \\
Linux-ha 6.jpg
\\ Mit Abschluss des letzten Schritts ist die Konfiguration vervollständigt und der Cluster einsatzbereit.\\
21.1 Testläufe / Verhalten der Software (Cluster mit mehr als zwei Knoten)
Ebenso wie der //RedHat Cluster Manager// unterstützt //Linux-HA// Cluster mit mehr als zwei Knoten. Voraussetzung dafür ist eine Konfiguration der 2. Generation. Prinzipiell ist die Anzahl an Knoten sogar unbegrenzt, wobei nach Aussagen der Entwickler bislang Tests mit bis zu 16 Knoten erfolgreich durchgeführt werden konnten. Um das Verhalten der Software bei größeren Clustern untersuchen zu können, wurde folgender, leicht erweiterter Versuchsaufbau verwendet:
* prinzipiell gleicher Aufbau wie zuvor, jedoch hier nun mit vier Knoten (node1 - node4) * jeder Knoten besitzt zwei voneinander unabhängige Netzwerk-Interfaces (eth0, eth1) * zwei gleichwertige, physikalisch getrennte Netzwerke durch Einsatz zweier Switches (Switch1, Switch2) * jeweils ein Interface jedes Knotens ist mit Switch1, das andere mit Switch2 verbunden * beide Switches sind mit einem Switch der nächsthöheren Hierarchieebene verbunden. Dies stellt die Gleichwertigkeit der beiden Netze sicher, wodurch im Fehlerfall Dienste auf dem jeweils noch intakten Netz bereitgestellt werden können, ohne dass sich dabei für die "Außenwelt" etwas ändert.
- Anmerkung:**
\\ Der Einsatz von seriellen Verbindungen ist auch bei mehr als zwei Knoten prinzipiell möglich. Da Knoten empfangene Heartbeats nicht an andere weiterleiten, müsste ein vollständiges Netzwerk allerdings mittels Vollvermaschung realisiert werden. Ob dies möglich und/oder sinnvoll ist, sollte im Einzelfall geklärt werden.
21.2 Zusammenfassung der Testergebnisse
Leider konnte //Linux-HA// mit dem oben beschriebenen Versuchsaufbau so gut wie gar nicht betrieben werden. Der Cluster verhielt sich äußerst instabil. Auf Änderungen der Konfiguration oder Störungstests wie die zuvor beschriebenen reagierte die Applikation reproduzierbar mit Abstürzen, Einfrieren oder ähnlichem, nicht tolerierbaren Fehlverhalten. Unverhältnismäßig oft konnten Knoten, deren Heartbeat-Client nicht mehr reagierte, nur noch durch einen kompletten Neustart wieder in den Cluster eingefügt werden. Die Tests wurden nach zahlreichen Versuchen, die Software durch verschiedenartigste Konfigurationen doch noch zum stabilen Arbeiten zu bewegen, erfolglos eingestellt.
In Kürze erfolgen Tests mit anderer Hardware, um abschließend klären zu können, ob wirklich //Linux-HA// oder doch etwaige Hardwareinkompatibilitäten die Störungen verursachen. Solange diese Testergebnisse noch nicht vorliegen, fließen die oben beschriebenen Erfahrungen nicht in die Bewertung ein. Es sei jedoch angemerkt, dass aufgrund des frühen Entwicklungsstadiums der Funktionen der zweiten Generation im laufenden Betrieb noch keine allzuhohe Stabilität der Applikation zu erwarten ist.
21.2.1 Bewertung
- Installation und Inbetriebnahme:**
\\ Die Installation von //Linux-HA// erweist sich als weitgehend unproblematisch. Praktisch ist vor allem, dass die Kernapplikation //Heartbeat// sowie alle Komponenten und Erweiterungen von den Entwicklern in einem Komplettpaket zusammengestellt sind - die oft langwierige Installation vieler Einzelpakete kann so entfallen. Die Inbetriebnahme der mit der Version 2 eingeführten Funktionen sowie der graphischen Benutzeroberfläche brachte zunächst einige Probleme mit sich, ist mit dem notwendigen (in diesem Dokument vermittelten) Hintergrundwissen aber kein unüberwindbares Hindernis.
- Funktionsumfang:**
\\ Der Funktionsumfang von //Linux-HA// lässt kaum Wünsche offen. Zu den Schlüsselmerkmalen zählt die Unterstützung von Clustern mit nahezu beliebig vielen Knoten sowie die Überwachung der vom Cluster angebotenen Dienste zur Laufzeit. Ein System zur vollautomatischen Propagierung von Konfigurationsänderungen fehlt ebensowenig wie eine graphische Administrationsoberfläche, die zumindest für die Konfiguration der Cluster-Resourcen das Editieren von Dateien überflüssig macht. Im Bereich Storage steht //Linux-HA// dem //RedHat Cluster Manager (RHCM)// in nichts nach und kann genauso Cluster-Dateisysteme, Shared Storage und Netzwerkressourcen wie NFS- oder Samba-Freigaben umgehen. Fencing zum kontrollierten Abschalten von Knoten wird durch die Komponente //STONITH// bereitgestellt. Besondere Erwähnung verdient die Erweiterung //IPFail/////pingd//, welche die Verfügbarkeit von Netzwerkverbindungen überwacht und so zusätzlich sicherstellt, das die von einem Cluster angebotenen Dienste für die Außenwelt erreichbar sind. Ein Pendant dazu sucht man beim //RedHat Cluster Manager// leider vergebens.
- Konfiguration:**
\\ Wie im Verlauf dieses Dokuments mehrfach erwähnt ist die Konfiguration von //Linux-HA// alles andere als einfach. Als Entschädigung dafür gibt sich //Linux-HA// allerdings äußerst flexibel und gestattet Anpassungen bis ins kleinste Detail. Ein absoluter Pluspunkt sind die Optionen bzgl. der Gestaltung des Kommunikationsnetzwerkes. Dieses kann aus beliebig vielen seriellen Verbindungen und Netzwerk-Interfaces zusammengestellt werden. Intervalle und Timeouts, zu verwendende Ports sowie die Art der Kommunikation in IP-Netzwerken (Unicast, Multicast, Broadcast) sind vom Anwender frei definierbar. Neben der Vermeidung von single-points-of-failure ist so vor allem die Erfüllung von (technischen) Vorgaben oder Einschränkungen ein leichtes. Flexibilität in diesem Maße ist dem //RHCM// leider unbekannt - der Anwender ist dort auf starre Kommunikationsmuster festgelegt und muss sogar manuell für die Hochverfügbarkeit des Kommunikationsnetzwerkes (bspw. mittels Channel-Bonding) sorgen.
- Stabilität und Robustheit:**
\\ Bei Konfigurationen der Version 1 und dem damit einhergehenden Verzicht auf die erweiterten Funktionen gibt es in puncto Stabilität und Robustheit wenig zu bemängeln. Zahlreiche Tests mit simulierten Problemen absolvierte die Applikation zufriedenstellend. Lediglich der Absturz von //Heartbeat// selbst kann für die Hochverfügbarkeit des Clusters bzw. dessen Dienste gefährlich werden - allerdings auch nur dann, wenn auf Fencing via //STONITH// verzichtet wird. Selbst ohne Fencing sollte sich dieses Problem durch die (noch zu untersuchende) Einbindung in eine Monitoring-Lösung wie Nagios oder Ganglia entschärfen lassen. Bei Einsatz der erweiterten Funktionen (genauer: Aktivierung des CRM und Verwendung des GUIs) ist derzeit noch Vorsicht geboten. Vor allem die Verwendung der graphischen Administrationsoberfläche verlangt Fingerspitzengefühl, da bestimmte damit ausgeführte Aktionen hin und wieder zum Einfrieren von //Heartbeat// führen. Das Debuggen von Konfigurationen der zweiten Generation wird durch die erhöhte Komplexität und die Flut von Ausgaben in den Logs leider einiges anspruchsvoller. Allgemein zeigt sich //Linux-HA// mit aktivierten erweiterten Funktionen anfälliger gegenüber Störungen. Es bleibt abzuwarten, inwieweit kommende Versionen hierbei Abhilfe schaffen können.
- Dokumentation:**
\\ Leider stellt die Dokumentationen einer der wenigen Schachpunkte von //Linux-HA// dar. Diese leidet vor allem unter ihrer Unvollständigkeit. Funktionen, die bereits in früheren Versionen der Software enthalten waren, werden umfangreich erläutert. Mit der Version 2 eingeführte Neuerungen sind hingegen nur teilweise bis überhaupt nicht dokumentiert, was deren Einsatz logischerweise erschwert - an einigen Stellen des vorliegenden Dokuments ist dies sicherlich bereits deutlich geworden. Das zweite große Problem der als Wiki realisierten Dokumentation besteht in der schlechten Strukturierung der Inhalte. Ein Inhaltsverzeichnis fehlt, ein logischer, linearer Aufbau ist nicht erkennbar. Oftmals verliert man sich in den zu oft untereinander verlinkten Einzelbeschreibungen und findet die benötigten Informationen gar nicht oder erst nach langwieriger Suche.
\\ **__Zusammenfasssung__**\\
\\ //Pro://
* weitreichender Funktionsumfang * problemlose Installation * sehr stabil (vorrangig bei Konfigurationen der 1. Generation) * bis in das kleinste Detail konfigurierbar * //IPFail/////pingd// prüft Netzwerkverbindungen * Kommunikation frei definierbar (serielle Verbindungen, beliebige Netzwerk-\\ Interfaces, Unicast, Multicast, Broadcast, Ports, Timeouts, Intervalle) * Hohes Maß an Transparenz:\\ die Entwickler bemühen sich, innere Abläufe zu beschreiben und zu erklären * abgesicherte Kommunikation durch Authentifizierung * Debugging durch Logeinträge stark erleichtert
\\ //Contra://
* aufwendige manuelle Konfiguration * GUI noch nicht komplett fehlerbereinigt * schlecht strukturierte, teilweise unvollständige Dokumentation * nur systemweite Installation praktikabel * erweiterte Funktionen (Version 2) noch nicht vollends ausgereift
\\
21.2.2 ToDo
- //Geplante Ergänzungen://**
* **Messung der Bandbreitennutzung durch //Linux-HA//**
* **Möglichkeiten der Einbindung von //Linux-HA// in Monitoring-Lösungen:** * Fokus: [[15]], Ganglia * Überwachung von //Linux-HA// (Applikation selbst, Status Dienste/Knoten) * Auslösen von Ereignissen im Fehlerfall (bspw. autom. Benachrichtigung eines Administrators) * Quelle: http://www.nagiosexchange.org/Search_Projects.43.0.html?tx_netnagext_pi1%5Bphrase%5D=heartbeat&tx_netnagext_pi1%5Bsubmit%5D=search&tx_netnagext_pi1%5Bsearch%5D=1
* **Untersuchung und Test von //Linux-HA// in Verbindung mit //Lustre//:** * Primär: Absicherung der //MDS// * Sekundär: Absicherung der //OSS// * Quelle: [Manual, Kapitel II-6]
\\ \\ //(c) 2006 Andreas Aßmann (Autor), The-Duy Nguyen (Co-Autor)//
