Eine clevere IPtables-Funktion und Linux-HA verwandeln gewöhnliche Server in einen starken Cluster. Dessen Knoten teilen die Last untereinander und springen im Fehlerfall gegenseitig ein - ganz ohne zentrale Steuerung. Hardwarefehler oder Wartungsfenster verlieren ihren Schrecken.

© impala441, photocase.com

Vor vier Monaten erklärte ein Artikel im Linux-Magazin [1] das »CLUSTERIP«-Target von IPtables: Mehrere Rechner kooperieren als Cluster, in dem ein Hash-Verfahren anhand der Verbindungsdaten die Last der Serverapplikation verteilt. Jeder Knoten des Clusters berechnet selbstständig, ob er für eine Verbindung zuständig ist. Zentrale Instanzen (Loadbalancer) sind hier unnötig, die Knoten müssen nicht einmal untereinander aushandeln, wer sich um welchen Request kümmert - der Hash sagt es ihnen. Je nach Modus berücksichtigt der Hash die Quell-IP, den Quell-Port und den Ziel-Port (siehe Kasten "Cluster-IP").

Ohne eine Verständigung ist jedoch kein automatisiertes Umschalten im Fehlerfall zwischen den Knoten möglich. Der erwähnte Artikel enthält ein einfaches Skript, das den Gesundheitszustand des lokalen Knotens überwacht und im Fehlerfall einen anderen Knoten beauftragt. Das greift allerdings nicht, wenn der Knoten spontan ausfällt.

In einem Gespräch auf dem Linux-Park der Cebit 2007 erhielt der Autor beider Artikel die Anregung, Linux-HA 2 [2] mit Cluster-IP zu kombinieren. Die Lastverteilung bleibt in diesem Ansatz bei Netfilter, um Überwachung und Failover kümmert sich Linux-HA. Es stellte sich heraus, dass diese Kombination einfacher war als gedacht.

Ressourcen

Der Heartbeat-Dienst von Linux-HA behandelt alles, was er überwacht, als Ressource, egal ob es sich um einen Dienst handelt (etwa Apache) oder eine IP-Adresse. Zu jeder Ressource gehört ein Skript zum Starten, Stoppen und Überwachen. Im einfachsten Fall genügt ein Init-Skript aus »/etc/init.d«. Unter Linux-HA heißen solche Skripte Resource Agents. Ideal für Heartbeat sind Agenten, die sich an die OCF-Vorgaben halten (Open Cluster Framework, [3]). Vereinfacht handelt es sich um Init-Skripte, die zusätzlich zu den üblichen Kommandos »start« und »stop« noch auf »monitor« hören und den Erfolgs- oder Fehlerstatus zurückgeben. Außerdem enthalten OCF-Agenten eine Dokumentation.

Eine Suche in den mitgelieferten Agenten zeigte, dass Lars Marowsky-Brée (aktiv bei OCF und Linux-HA) bereits die Idee zu der Kombination hatte und die Grundzüge des »CLUSTERIP«-Targets im OCF-Agenten »IPaddr2« implementierte. Dieser Agent verwaltet gewöhnlich eine IP-Adresse. Dank der GPL war es für den Artikel möglich, die Gedankengänge aufzugreifen und zu Ende zu führen. Nach ein paar schlaflosen Nächten stand die neue Version des Agenten und nach ein paar Tests lief sie auch stabil.

Rahmen

Unter dem Schirm von Linux-HA arbeitet eine Ressource im Regelfall unbehelligt. Erkennt Heartbeat einen Ausfall, dann versetzt es die fehlerhafte Ressource auf einen anderen Knoten. Dazu stoppt der HA-Dienst die Ressource auf dem bisherigen Knoten, soweit das noch möglich ist, und startet sie anschließend auf dem neuen. Die Ressource selbst muss sich um nichts kümmern.

Ob ein Knoten noch erreichbar ist, prüft Heartbeat mit Hilfe der OCF-Ressource »pingd« [7]. Jeder Knoten pingt eine Reihe von Hosts an. Wenn diese nicht antworten, geht es dem Knoten oder dem dazwischen liegenden Netzwerk nicht gut. Über Co-Lokation in der Konfiguration stellt der Admin ein, dass der Dienst, für den er den Cluster aufbaut (hier »IPaddr2«), nur auf einem gesunden Knoten laufen darf. Einfacher gesagt: Die »IPaddr2«-Ressource darf nur auf einem Knoten laufen, auf dem »pingd« arbeitet und Ergebnisse liefert. Reagiert »pingd« nicht mehr, verlagert Heartbeat auch den anderen Dienst. Beispiele für eine solche Überwachung haben frühere Linux-Magazin-Ausgaben dargestellt ([4], [5] und [6]).

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Eine clevere IPtables-Funktion und Linux-HA verwandeln gewöhnliche Server in einen starken Cluster. Dessen Knoten teilen die Last untereinander und springen im Fehlerfall gegenseitig ein - ganz ohne zentrale Steuerung. Hardwarefehler oder Wartungsfenster verlieren ihren Schrecken.