Dass die Firma ORDIX dem Thema Open Source nicht abgeneigt ist, kann man der einen oder anderen ORDIX News entnehmen oder auch während eines Projektes in Form einer flexiblen Problemlösung erkennen. In diesem Beitrag berichten wir von einer Lösung für einen unserer Kunden: Hierbei wurde die Open Source Hochverfügbarkeitslösung Heartbeat erfolgreich implementiert. Zusätzlich kamen andere, freie Anwendungen zum Einsatz.

Ein weltweit operierender Kunde stellte uns die Aufgabe, mehrere Cluster für die Erfassung und Abfrage von Messergebnissen zu implementieren. Ebenso sollten die ansässigen Administratoren durch ORDIX Mitarbeiter mit der Heartbeat Software vertraut gemacht werden.

Bestandsaufnahme

Die fehlerfreie Durchführung von Messreihen ist für den Kunden von äußerster Wichtigkeit, da die Datenerfassung im Fehlerfall nicht reproduziert werden kann. Diese Messungen finden rund um die Uhr und jeden Tag in der Woche statt. Zusätzlich zur Erfassung der Daten spielt auch die Abfrage der Ergebnisse mit Hilfe von Web-Anwendungen eine große Rolle.

Diese Anforderungen bieten ein gutes Einsatzgebiet für eine Cluster-Lösung, die so konzipiert ist, dass der Ausfall eines einzelnen Systems nicht zum Problem der gesamten Messwerterfassung wird. Ebenso sollte die einzusetzende Lösung hochverfügbar gestaltet sein, damit das gesamte System permanent funktioniert.

Letztlich wurden in diesem Projekt insgesamt vier Cluster implementiert, bei denen Heartbeat in der Version 2 zum Einsatz kam:

1. Test-Cluster

Für die Schulung der Administratoren und den Test der Anwendungen baute man einen Test-Cluster aus drei Knoten auf. Die Administratoren sollten bei der Implementierung selbst Hand anlegen, um später auch die Cluster administrieren zu können.

2. Active/Active-Cluster

Der zweite Cluster war ein 2-Knoten-Active/Active-Cluster für die Web-Anwendungen.

Abb. 1: Aufbau der Cluster für Web-Anwendungen und den Loadbalancer. vergrößern

3. Loadbalancer

Daraus resultierte der dritte Cluster: ein hochverfügbarer Loadbalancer, der die ankommenden Anfragen der Clients auf den Active/Active-Cluster verteilte. Abbildung 1 zeigt den Aufbau von Webcluster und Loadbalancer.

4. Cluster aus DB- und Fileserver und Host

Zu guter Letzt entstand ein weiterer Cluster aus drei Knoten, der als Datenbankserver, Fileserver und Host für VMware-Gäste dient. Als Betriebssystem kam auf allen Systemen SuSE Linux Enterprise Server 10 zum Einsatz. Die benötigte Software wurde bei Bedarf als RPM-Paket nachinstalliert. Im Folgenden behandeln wir die Punkte 1 - 3.

Der Test-Cluster: Theorie, Implementierung und üben, üben, üben

Die Einrichtung des Clusters für die Testumgebung fand direkt im Administratorenbüro statt. Für die Testumgebung standen nur drei Systeme zu Verfügung. Dies entsprach also nicht der produktiven Umgebung. Aus diesem Grund schufen wir für die Tests eine Multiboot-Umgebung, bei der wir durch Neustart der Systeme schnell zu einer anderen Cluster-Umgebung wechseln konnten.

So wurden alle Szenarien immer erst in der Testumgebung aufgebaut und dann produktiv umgesetzt. Dadurch waren im Produktivumfeld immer nur kurze Ausfallzeiten für die Konfiguration erforderlich.

Der Active/Active-Cluster: Apache HA oder "Der Doppelte Indianer"

Danach wurde der Cluster für die Web-Anwendungen implementiert. Er bestand aus zwei Knoten. Wie auch auf allen anderen Cluster-Knoten wurde hier die Heartbeat-Version 2.0.8 [1] installiert. Während der Implementierungsphase wurde Apache hochverfügbar eingerichtet, später folgten weitere Web-Anwendungen und Tomcat.

Die Kommunikation der Cluster-Knoten besteht aus zwei dedizierten Heartbeat-Leitungen plus Unicast über das Ressourcennetzwerk. Da der Cluster gewollt auf beiden Knoten aktiv ist und es keine Gefahr beim Mounten von Dateisystemen gibt, kann man hier auf Fencing-Lösungen wie STONITH verzichten.

Auf diesem Cluster gibt es insgesamt drei Verzeichnisse, /etc/apache2, /etc/ha.d und /srv/www, die auf beiden Knoten gleich sein müssen. Deren Abgleich lässt sich mit den folgenden drei Optionen automatisieren:

• ssh/scp - Mit Hilfe von Public Key Authentifizierung kann der Abgleich automatisiert werden.
• rsync - Mit rsync können Verzeichnisse synchronisiert werden, entweder mit rsync-Daemon oder SSH als Transportmittel.
• csync2 - Mit der Open Source Lösung csync2 können Dateien bzw. Verzeichnisse zwischen beliebig vielen Systemen abgeglichen werden.

Aus funktionalen Gründen wurde in diesem Projekt die Software csync2 zum Abgleich der Dateien eingerichtet. Sie bringt den Vorteil, dass Änderungen auf jedem beliebigen System durchführbar sind.

Ein cron-Job automatisiert den Abgleich. Sobald es einen Konflikt gibt, z. B. wenn auf beiden Seiten Dateien geändert werden, bekommen die Administratoren eine E-Mail. Sie müssen dann den Konflikt manuell lösen: Sie legen individuell fest, in welche Richtung synchronisiert werden soll. Im Verlauf des Artikels gehen wir detaillierter auf diese elegante Software ein.

Nachdem Heartbeat konfiguriert und gestartet war, begannen wir mit der Konfiguration der geclusterten Anwendungen. Kernanwendung auf diesem System ist der Apache. Er soll auf beiden Systemen gestartet sein. Heartbeat selbst bietet hier die praktische Möglichkeit eines Clones. Mit einem Clone wird eine Anwendung n-mal innerhalb des Clusters gestartet. Abbildung 2 zeigt die XML-Konfiguration des Apache Clones.

<clone id="Apache_Twice"> 
 <meta_attributes id="Apache_Twice_meta_attrs">
 <attributes>
   <nvpair id="Apache_Twice_metaattr_target_role" name="clone_node_max" value="1"/>
   <nvpair id="Apache_Twice_metaattr_clone_max" name="clone_max" value="2"/>
   <nvpair id="Apache_Twice_metaattr_clone_node_max" name="clone_node_max" value="1"/>
 </attributes>
 </meta_attributes>
 <primitive id="Apache_Clone" class="lsb" type="apache2" provider="heartbeat"/>
</clone>

Die Konfiguration aus Abbildung 2 wird in eine Textdatei geschrieben und mit dem Befehl cibadmin -C -o resources -x ApacheClone.xml in den Cluster importiert. Danach wird sie durch den Cluster automatisch auf alle Cluster-Knoten repliziert. Der Eintrag name="clone_max" value="2" definiert, dass die Anwendung zweimal innerhalb des Clusters laufen darf, pro Knoten allerdings jeweils nur einmal (name="clone_node_max" value="1").

Die Ressourcenkonfiguration kann ebenfalls mit dem Befehl hb_gui, der eine grafische Oberfläche zur Konfiguration startet, durchgeführt werden. Hierbei stehen jedoch nicht alle Möglichkeiten der Kommandozeile zur Verfügung.

Für den Apache Clone wurde eine Überwachung eingerichtet: Der Cluster überwacht, ob der Dienst läuft und würde ihn neu starten, sollte dies nicht der Fall sein. Bei alten Heartbeat-Versionen musste die Überwachung mit externen Tools wie z. B. mon eingerichtet werden, da bei diesen früheren Versionen die Ressourcen nicht durch den Cluster überwacht wurden.

csync2 - Konfiguration in Synchronität

Wir wollen nun detaillierter auf das Synchronisationstool csync2 eingehen. Csync2 ist ein Cluster-Synchronisations-Tool, das auch für andere Zwecke - außerhalb einer Cluster-Umgebung - genutzt werden kann. Erhältlich ist das Programm unter [2].

Csync2 kommt auch mit komplexen Setups von mehr als zwei Hosts zurecht, kann Dateilöschungen handhaben und Konflikte erkennen. Csync2 ist für HA-Cluster, HPC-Cluster und Serverfarmen geeignet. Im Hintergrund nutzt csync2 eine sqlite-Datenbank, in der Informationen über Prüfsummen und Veränderungen der überwachten Dateien erfasst werden.

group apache
{
 host apache1 apache2;
 key /etc/csync2.key;
  
 include /etc/apache2;
 include /srv/www;
  
 action
 {
 pattern /etc/apache2/*;
 exec "/etc/init.d/apache2 reload";
 logfile "/var/log/csync2_action.log";
 }
 backup-directory /var/backups/csync2;
 backup-generations 9;
 auto none;
}

Die Konfiguration von csync2 ist nicht sonderlich schwierig. Gestartet wird es über den inetd/xinetd. Die Konfiguration erfolgt über die Datei /etc/csync2.cfg und muss auf allen beteiligten Knoten gleich gehalten werden. Somit ist die Konfigurationsdatei selbst in die Synchronisation mit aufzunehmen. Abbildung 3 zeigt eine Beispielkonfiguration.

Hieran sehen Sie, dass die Konfiguration fast selbsterklärend ist. Man kann beliebig viele Gruppen in der Datei erstellen und somit auch unterschiedliche Syncs zwischen verschiedenen Systemen konfigurieren. Mit host werden die beteiligten Systeme angegeben.

In der mit key bezeichneten Datei befindet sich ein eindeutiger Schlüssel mit dem sich die Synchronisationspartner gegenseitig authentifizieren. include gibt die zu synchronisierenden Verzeichnisse an und mit einer action können Befehle ausgeführt werden. Wenn unterhalb von /etc/apache2/ etwas synchronisiert wurde, wird Apache neu geladen. Von überschriebenen Dateien werden jeweils neun Versionen gespeichert.

Der wichtigste Schalter auto none besagt, dass Konflikte nicht automatisch, sondern vom Administrator gelöst werden müssen. Mit dem Befehl csync2 -xv startet der Administrator den manuellen Abgleich und kann ihn per cron automatisieren. Der Befehl csync2 -T zeigt mögliche Konflikte an.

Der Loadbalancer: Arbeit für die Indianer

Nachdem der Cluster mit den Apaches konfiguriert und auf Herz und Nieren getestet ist, beginnt die Arbeit am Loadbalancer. Für den Loadbalancer wurde keine eigene Hardware angeschafft. Stattdessen erweiterten wir zwei bestehende Systeme um die Heartbeat Software. Genauer betrachtet besteht die Aufgabe des hochverfügbaren Loadbalancers lediglich darin, eine IP-Adresse zu schalten und eine Portweiterleitung auf andere Server-Systeme durchzuführen.

Zunächst wurden die Heartbeat-Leitungen eingerichtet, die Cluster Software konfiguriert und gestartet. Dann haben wir die geschaltete IP-Adresse und einen speziellen Eintrag für den pingd hinzugefügt.

Wozu ein pingd? Die Idee dahinter ist einfach: In Version 1 von Heartbeat konnte man in der Konfigurationsdatei die Programme ipfail und ping Nodes eintragen. Mit diesen Programmen werden in zyklischen Abständen die eingetragenen Systeme angepingt und falls diese nicht erreichbar sind, nimmt das System an, dass der Weg über das Ressourcennetzwerk nicht verfügbar ist. Es könnte z. B. der Switch bzw. das Kabel defekt sein. Falls der Partnerknoten erfolgreich "pingen" kann, findet automatisch ein "Failover" der Ressourcen auf den anderen Knoten statt.

In der Heartbeat Version 2 kann weiterhin ipfail benutzt werden oder aber der modernere pingd.

Dazu muss ein Eintrag wie respawn root /usr/lib/heartbeat/pingd -m 100 -d 5d -a pingd und ping 192.168.14.200 in der Datei /etc/ha.d/ha.cf eingetragen werden. Bei diesem Verfahren findet allerdings bei Nicht-Erreichen des ping Nodes erst einmal noch gar nichts statt. Ist der ping Node nicht erreichbar, wird in der Cluster-Konfiguration das Attribut pingd auf 0 gesetzt.

Normalerweise wird für das Attribut pingd der Wert -m 100 erwartet. Pingt man 2 Knoten an, wird für das Attribut 200 erwartet, sofern beide Knoten erreichbar sind. Und genau dieses Attribut soll der Cluster auswerten. Bei 0 muss er einen Failover der Ressourcen auf den anderen Knoten durchführen. Abbildung 4 zeigt die Konfiguration der geclusterten IP-Adresse, Abbildung 5 die Auswertung des Attributes pingd. Mit Hilfe der dynamischen Auswertung von Attributen ergeben sich in der Version 2 von Heartbeat elegante Möglichkeiten, die Erreichbarkeit von Cluster-Knoten zu verbessern. Ein Beispiel wäre hier eine Ressource, die auf dem Knoten mit der besten Verfügbarkeit (höchster Attributwert) laufen soll.

<primitive id="IP_Apache" class="ocf" type="IPaddr" provider="heartbeat">

 <attributes>

   <nvpair name="ip" value="192.168.14.100"/>

   <nvpair name="nic" value="eth0"/>

 </attributes>

</primitive>

<rsc_location id="IP_Apache:connected" rsc="IP_Apache">

 <rule id="IP_Apache:connected:rule" score="-INFINITY" boolean_op="or">

   <expression id="IP_Apache:conn:expr:undefined" attribute="pingd" operation="not_defined"/>

   <expression id="IP_Apache:conn:expr:zero" attribute="pingd" operation="lte" value="0"/>

 </rule>

</rsc_location>

Über die konfigurierte IP-Adresse greift man auf die Apache Webserver zu. Die Aufgabe eines Loadbalancers ist nun, die Anfragen unter der konfigurierten IP-Adresse entgegenzunehmen und an andere Systeme weiterzuleiten.

Bei unserem Kunden wurde die Open Source Lösung Linux Virtual Server (LVS) [3] eingesetzt, die sich sehr gut in die Heartbeat Cluster Software integrieren lässt. Beim LVS werden die "echten" Systeme als Real Server und das System, welches die IP-Adresse schaltet, mit Virtual Server bezeichnet.

ipvsadm -A -t 192.168.14.100:80

ipvsadm -a -t 192.168.14.100:80 -r 192.168.14.11:80 -w 1 -g

ipvsadm -a -t 192.168.14.100:80 -r 192.168.14.12:80 -w 1 -g

Dazu werden das RPM-Paket ipvsadm und dessen wichtigster Befehl ipvsadm benötigt. Die Syntax der Optionen ist denen des Paketfilters iptables nachempfunden. Da die beiden Apaches als Active/Active-Cluster eingerichtet sind und keiner der beiden Knoten bevorzugt werden soll, werden die Anfragen auf den Virtual Server gleichmäßig im Round-Robin-Verfahren verteilt. Abbildung 6 zeigt eine statische Möglichkeit der Konfiguration mit Shell-Befehlen. Sie müssen auf beiden Knoten des Loadbalancers durchgeführt werden.

Mit dem ersten Befehl wird ein Virtual Server erstellt. Der zweite und dritte Befehl leiten die Anfragen über den Virtual Server an einen der beiden Real Server weiter. Diese Anfragen werden gleichmäßig (-w 1) verteilt. Sie könnten jedoch auch bevorzugt an nur einen Server weitergeleitet werden.

Interessant ist auch die Option -p, mit der die Persistenz aktiviert wird: Wenn eine Verbindung aufgebaut ist, sollen alle weiteren Pakete dieser Verbindung zum selben Server weitergeleitet werden. Dies ist vor allem bei SSL-Verbindungen wichtig, die zusätzlich eingerichtet wurden.

Die statische Einrichtung des LVS auf der Kommandozeile, wie in Abbildung 6, hat einen großen Nachteil: Fiele einer der beiden Apache Server aus, würde der Loadbalancer die Anfragen weiterhin an den toten Knoten leiten.

Die Lösung dieses Problems ist jedoch leicht: Die Loadbalancer überwachen den Port 80 der Apache Server und tragen die Einträge mit ipvsadm dynamisch ein.

virtual=192.168.14.100:80

 real=192.168.14.11:80 gate

 real=192.168.14.12:80 gate

 service=http

 request="index.html"

 scheduler=rr

 protocol=tcp

 checkport=80

Genau hierfür gibt es die fertige Lösung heartbeat-ldirectord in Form eines RPM-Paketes [4] Dieses Paket ist auf beiden Loadbalancer-Knoten installiert und kann über die Konfigurationsdatei /etc/ha.d/ldirectord.cf angepasst werden. Wieder ein Grund für die Verwendung der Software csync2. Abbildung 7 zeigt die Konfiguration des ldirectord.

Das gezeigte Beispiel beinhaltet genau die gleichen Einträge, wie die manuell durchgeführten in Abbildung 6. Nun muss der Dienst einmal mit dem Befehl /etc/init.d/ldirectord start gestartet und dauerhaft mit chkconfig ldirectord on aktiviert werden.

Zurück zum Active/Active Cluster: Indianer, einmal muss ich noch stören

Wurde der ldirectord konfiguriert, würde man wahrscheinlich den Zugriff mit einem Webbrowser testen. Hierbei wird man sehr schnell feststellen, dass es mit der bisherigen Konfiguration noch nicht funktioniert. Betreibt man den Loadbalancer wie hier im "Routing"-Modus, das bewirkt die Option -g beim Kommandozeilenbefehl bzw. gate in der Konfigurationsdatei, muss auf den Real Servern die gleiche IP-Adresse wie auf dem Virtual Server vergeben werden.

Diese bindet man am Besten als zusätzliche Adresse auf das Loopback Device. Testet man jetzt den Apache-Zugriff, funktioniert es. Aber: das Round Robin funktioniert nicht und möglicherweise benehmen sich andere Systeme im selben Subnetz ebenso wie der Apache Cluster und der Loadbalancer "etwas merkwürdig".

ifconfig lo:0 192.168.14.100 netmask 255.255.255.255 up

  sysctl -w "net.ipv4.conf.lo.arp_ignore=1"=

  sysctl -w "net.ipv4.conf.all.arp_ignore=1"

Das ist eigentlich klar, denn wir haben gerade dreimal dieselbe IP-Adresse im selben Subnetz konfiguriert. Die Lösung des Problems liegt darin, zu verhindern, dass die Apache IPs auf ARP-Anfragen aus dem Netzwerk antworten. Abbildung 8 zeigt die nötigen Befehle, die dazu auf beiden Apache-Knoten durchzuführen sind.

Resümee

Dieser Beitrag zeigt, wie Open Source Software in der Praxis eingesetzt werden kann. Die Cluster Software Heartbeat 2 unterstützt Cluster mit mehr als zwei Knoten und es gibt ein modernes GUI für eine vereinfachte Konfiguration. Sie bringt inzwischen also alles mit, was für den Einsatz in Hochverfügbarkeitsumgebungen benötigt wird.

In einer der nächsten Ausgaben berichten wir über den vierten Cluster mit Datenbank, geteiltem Dateisystem und VMware.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen