Open Source im professionellen Einsatz

Ausgebauter HA-Cluster

Mit Linux-HA in Version 2 (ab 2005, [5]) fiel die Zwei-Knoten-Grenze: Jetzt sind 16 Knoten integrierbar und alle beteiligten Dienste lassen sich unabhängig voneinander überwachen und sichern (Abbildung 3). Das Verhalten im Fehlerfall steuert ein raffiniertes Regelwerk, mit dem sich vorgeben lässt, auf welchen Knoten ein Dienst umziehen soll.

Abbildung 2: Ein einfacher Failover-Cluster detektiert Ausfälle automatisch und regelt den Zugriff auf den Shared Storage via Fencing. Im Ernstfall zieht er sogar die Notbremse und schießt den zweiten Knoten ab.

Abbildung 2: Ein einfacher Failover-Cluster detektiert Ausfälle automatisch und regelt den Zugriff auf den Shared Storage via Fencing. Im Ernstfall zieht er sogar die Notbremse und schießt den zweiten Knoten ab.

So kann der Admin beispielsweise vorgeben, dass der Webserver auf einen Knoten wandern soll, auf dem nicht bereits ein Webserver läuft (um Portkonflikte zu vermeiden) und der zusätzlich mit keiner höheren Last als einem Load Average von 2,5 belegt sein darf. Der Applikationsserver soll dagegen auf jenen Knoten umziehen, auf den die Datenbank bereits gewandert ist, was aber in keinem Fall ein Webserver sein darf und so weiter. Mit Hilfe eines Punktesystems ermittelt der Cluster automatisch die Konfiguration, die eine größtmögliche Übereinstimmung mit den vorgegebenen Regeln gewährleistet.

Der Preis für all dies ist eine wesentlich komplexere Architektur und Konfiguration. Zentrale Instanz ist jetzt ein Cluster Resource Manager (CRM), der Heartbeat-Dienst ist nunmehr alleine für die Kommunikation der Knoten zuständig und ein separater Cluster Consensus Membership Service (CCM) verwaltet Zugehörigkeit und Status von Clusterknoten. Ressourcen lassen sich jetzt gruppieren, klonen und manuell zwischen den Knoten verschieben.

Nach Querelen im HA-Projekt scheint sich gegenwärtig eine Konfiguration durchzusetzen, die Pacemaker [6] als Resource Manager und Open AIS [7] statt Heartbeat für die Kommunikation der Knoten verwendet. Dazu kommt ein Distributed Lock Manager (DLM) der den Zugriff auf den Shared Storage managt. Auf ihn verlassen sich auch Cluster-Filesysteme wie GFS [8] oder OCFS2.

Kommerzielle Konkurrenz

Alternativ zu Linux-HA (Version 2) stehen unter Linux auch einige kommerzielle Cluster-Suiten bereit. Dazu gehört beispielsweise der Veritas Cluster Server ([9], für RHEL 4 und 5, SLES 9 und 10 sowie Oracle Enterprise Linux 4), mit dem sich im Unterschied zu Linux-HA auch Crossplattform-Cluster aufbauen lassen, die Solaris-, AIX- oder HP-UX-Nodes einbeziehen. Außerdem kann man hier fertige Resource Agents für die Überwachung gängiger Business-Applikationen und Datenbanken erwerben (natürlich auch für Webserver).

Abbildung 4: Auch ein Load Balancer kann für die nötige Redundanz sorgen und ist das Mittel der Wahl, wenn aus Performancegründen ohnehin eine Lastverteilung nötig ist.

Abbildung 4: Auch ein Load Balancer kann für die nötige Redundanz sorgen und ist das Mittel der Wahl, wenn aus Performancegründen ohnehin eine Lastverteilung nötig ist.

Eine weitere Möglichkeit bietet der Lifekeeper-Cluster der Firma Steeleye [10]. Er unterstützt RHEL, SLES und Centos, kommt mit bis zu 32 Knoten klar und erleichtert die Konfiguration ebenfalls durch vorbereitete Module - darunter für Apache, etliche Datenbanken, Applikationsserver und so weiter.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook