HA-Serie, Teil 1: Grundlagen von Pacemaker und Co.

© Artem Merzlenko, 123RF

Der Cluster-Leitstand

Unverzichtbarer Bestandteil eines Hochverfügbarkeits-Clusters ist ein Cluster-Manager, der im Problemfall weiß, was zu tun ist. Mit Pacemaker liegt zum ersten Mal überhaupt ein brauchbarer Cluster-Manager für Linux auf der Grundlage von Open Source vor.
Was das Backup wert war, erweist sich, sobald man es versucht ganz oder teilweise wiederherzustellen. Spätestens dann macht sich die Wahl des richtigen Tools ... (mehr)

Der Failover, also die Übernahme von Diensten eines havarierten Systems auf ein überlebendes, ist das wichtigste Prinzip eines Hochverfügbarkeits-Clusters. Damit der Failover funktioniert, benötigt man eine zentrale Software, die die Steuerung des Clusters übernimmt. Im Fachjargon heißt diese Software Cluster Manager. Ihre Hauptaufgabe ist es, alle Knoten eines Clusters auf Verfügbarkeit zu überprüfen. Darüber hinaus soll sie auch erkennen, wenn womöglich nur einzelne Programme auf einem ansonsten noch erreichbaren Knoten abgestürzt sind.

Ressourcen-Management und Kommunikation

Klassischerweise unterteilt sich das Cluster-Management in die beiden Komponenten Cluster Communication Management (CCM) und Cluster Resource Management (CRM). Für Linux steht mit Pacemaker ein reinrassiger Cluster Resource Manager zur Verfügung, der wahlweise mit den Cluster Communication Managern Corosync oder Heartbeat 3 betrieben werden kann (siehe auch Kasten "Die Geschichte von Pacemaker" ). Pacemaker empfängt im Zusammenspiel von Heartbeat oder Corosync Informationen über die zwei oder mehr Knoten, überwacht deren Ressourcen und greift im Falle eines Fehlers ein.

Die Geschichte von Pacemaker

Wenn Sie sich schon mit dem Thema Cluster-Management unter Linux auseinandergesetzt haben, sind Ihnen vermutlich diverse Begriffe begegnet. Heartbeat, Pacemaker, Corosync, OpenAIS – Einsteigern fällt es oft schwer, zwischen den einzelnen Lösungen zu unterscheiden ( Abbildung 6 ). Welche Komponente beherrscht welche Funktionen? Der folgende historische Abriss gibt einen Überblick über die wichtigsten Stationen von HA-Lösungen unter Linux.

Abbildung 6: Wie aus Heartbeat 1 Pacemaker wurde: Die Grafik gibt einen Überblick über rund elf Jahre Entwicklungsarbeit.

Grundsätzlich gilt: Linux hinkte sehr lange hinter anderen Systemen her, wenn es um das Thema Clustering ging. So steht beispielsweise Suns Cluster Suite für Solaris seit über 15 Jahren zur Verfügung. Andere Cluster-Manager wie Veritas haben eine ähnlich lange Versionsgeschichte. Linux hingegen konnte erst 1998 zum ersten Mal auf so etwas Ähnliches wie einen Cluster-Manager zurückgreifen: Heartbeat 1. Ursprünglich kam die Initiative von Alan Robertson, einem IBM-Entwickler. Dieser hatte sich bereits mit dem Thema Clustering beschäftigt und eine beachtliche Sammlung von Shellscripts verfasst. Für Heartbeat 1 fügte er diese zu einem Paket zusammen und schrieb einige Zeilen C-Code dazu, der diese Scripts in passender Reihenfolge aufrief und dafür sorgte, dass die Clusterknoten miteinander kommunizieren konnten.

Heartbeat 1 war allerdings in vielerlei Hinsicht sehr beschränkt. Zum einen war die im Artikel angesprochene Trennung zwischen den zwei Cluster-Komponenten – Ressourcen-Management und Cluster-Kommunikation – bei Heartbeat 1 auf Code-Ebene nicht umgesetzt. Stattdessen war die erste Heartbeat-Version ein großer monolithischer Code-Block. Auch im Hinblick auf die unterstützten Features war Heartbeat 1 als Lösung für Cluster-Management im Enterprise-Einsatz praktisch uninteressant. Denn es merkte zwar, wenn einer der vorhandenen Cluster-Knoten ausfiel, und konnte einen Failover initiieren. Ging dabei aber etwas schief, dann stoppte der Cluster-Manager alle Cluster-Ressourcen, und ein Eingreifen des Administrators war unvermeidlich. Außerdem fehlten überaus wichtige Features wie die Möglichkeit, einen Dienst innerhalb des Clusters zu überprüfen (Monitoring) und ihn neu zu starten, sollte er abgestürzt sein.

Red Hat war an Heartbeat 1 übrigens überhaupt nicht beteiligt; die Red Hat Cluster Suite, die bis heute Bestandteil von Red Hat Enterprise Linux ist, lag in Alpha-Versionen bereits 1996 vor und wurde seither konsequent weiterentwickelt.

Die technischen Unzulänglichkeiten von Heartbeat 1 glich später in den Augen vieler Admins ein neues Heartbeat 2 aus. Das kam allerdings erst 2005. Denn besonders dadurch, dass es immer wieder zu Meinungsverschiedenheiten zwischen Robertson und der Linux-HA Community kam, war es schwierig, einen gemeinsamen Nenner zu finden. Heartbeat 2 war letztlich in einer Art feindlicher Übernahme zu großen Teilen von Mitgliedern der HA-Community erarbeitet worden, Robertson spielte bei der Entwicklung letztendlich nur noch eine Nebenrolle.

Heartbeat 2 räumte zwar einige der Probleme aus, die Heartbeat 1 das Leben schwer gemacht hatten. Denn Heartbeat 2 führte die Trennung von Ressourcen- und Kommunikationsmanagement auf Code-Ebene ein und hatte erstmals Enterprise-Funktionen wie das Überwachen von Diensten. Das vermag aber nicht darüber hinwegzutäuschen, dass Heartbeat 2 bei seinem Erscheinen bereits veraltet war. Denn in den 6 Jahren zwischen den beiden Releases war in Sachen Hochverfügbarkeit einiges fernab von Linux-HA passiert.

Bereits 2001 hatte sich das Service Availability Forum gegründet, ein Industrie-Konsortium verschiedener großer Anbieter, das einen grundlegenden Standard für die Kommunikation in Multi-Node-Clustern schaffen wollte. Die erste Definition dieses Standards lag 2003 vor, gemeint ist die »Application Interface Specification« , kurz »AIS« .

Außerdem hatte Novell Ende 2003 den deutschen Linux-Distributor SUSE gekauft und wollte SUSE-Linux als Enterprise-Produkt in seine eigene Produktpalette einbauen. Schlagartig war damit auch bei SUSE ein sehr großes Interesse an HA-Diensten entstanden.

Zunächst lag nach der Veröffentlichung des AIS-Standards aber der Ball bei Red Hat. Red Hat stellte einen Entwickler ab, der den nunmehr verfügbaren Standard auf Code-Ebene umsetzen sollte. 2005 erschien die erste freie Implementierung von AIS, die auf den Namen »OpenAIS« hört. Schon damals war das Ziel, die Red Hat Cluster Suite auf den neuen Standard umzurüsten.

Schließlich ergriff Novell die Initiative: Mit Heartbeat 2 hatte man einen Cluster-Manager, der mittlerweile im Enterprise-Umfeld zu gebrauchen war. Obendrein war Heartbeat 2 auf Code-Ebene sinnvoll zu trennen – der Cluster Resource Manager und der Cluster Communication Manager waren separate Teile und leicht voneinander abzukoppeln. Das Unternehmen gab dem Australier Andrew Beekhof den Auftrag, den CRM aus Heartbeat 2 auf OpenAIS lauffähig zu machen. Das Resultat dieser Arbeit ist Pacemaker.

Durchaus bemerkenswert ist, dass Beekhof Pacemaker von Anfang an so konzipiert hat, dass er auch heute noch mit dem Cluster Communication Manager von Heartbeat 2 arbeiten kann. Dieser firmiert mittlerweile als Heartbeat 3. Bei Heartbeat 3 handelt es sich also nicht mehr um einen vollständigen Cluster-Manager.

Die letzte Wendung der Geschichte vom Clustering unter Linux wurde von Red Hat im Jahre 2007 initiiert, hat aber eher geringe Auswirkungen: Der Distributor beschloss, dass ihm OpenAIS als einzelnes Projekt zu groß ist, und spaltete OpenAIS nochmals auf – aus dem Projekt wurden die Komponenten, die sich ausschließlich mit der Cluster-Kommunikation beschäftigen, in ein eigenes Projekt namens Corosync ausgelagert. Als Ironie der Geschichte muss gelten, dass die übrigen Teile von OpenAIS nicht mehr weiterentwickelt werden – OpenAIS ist praktisch tot.

Damit steht fest: Wer gegenwärtig mit Linux-Systemen einen Cluster konstruieren möchte, nimmt dafür eine Kombination aus Pacemaker (Cluster Resource Manager) und entweder Corosync oder Heartbeat (Cluster Communication Manager).

Die Installation von Pacemaker fällt je nach Linux-Version unterschiedlich aus. Debian und Ubuntu liegen fertige Pakete bei. Wer RHEL 6 nutzt, braucht Red Hats HA-Addon; ganz ähnlich verhält es sich mit SLES: Auch hier ist der Erwerb der SUSE Linux High Availability Extension notwendig. Für andere Distributionen ist vermutlich Handarbeit angesagt. In allen Fällen heißt das Paket, das Pacemaker enthält, allerdings »pacemaker« – es installiert benötige Software gleich mit.

Admins stehen zu Beginn der Installation vor der Entscheidung: Soll Pacemaker mit dem Heartbeat-3-CCM oder dem Corosync-CCM laufen? Im Alltag gibt es zwar kaum Funktionsunterschiede, doch beide Ansätze haben ihr Für und Wider.

Soll eine Applikation zum Einsatz kommen, die den DLM, also den Distributed Locking Manager, verwendet, ist Corosync Pflicht, denn Heartbeat unterstützt die Kommunikation mit dem DLM nicht. Auch wer ein Cluster-Setup auf Grundlage von RHEL oder SLES mit dem entsprechenden HA-Addon konstruiert, kommt nicht an Corosync vorbei; denn hier ist Corosync die einzige offiziell unterstützte Lösung. Wer aber Ubuntu oder Debian nutzt, kann sich zwischen Heartbeat und Corosync entscheiden.

Andere Gründe sprechen für Heartbeat: Es unterstützt seit jeher das Unicast-Protokoll für die Cluster-Kommunikation. Corosync kann das erst seit der aktuellen Version 1.3.0 – frühere Versionen kommunizierten nur per Multicast, was zu Naserümpfen bei Netzwerkern führt.

Außerdem bietet Corosync keine Unterstützung für den automatischen Wiederaufbau des Kommunikationspfads zwischen zwei Knoten. Das Feature heißt Automatic Link Recovery und ist bei Heartbeat Standard. Corosync dagegen merkt nichts davon, wenn der Kommunikationspfad zwischen zwei Knoten ausfällt und später wieder in Gang kommt. Es bedarf händischer Intervention.

Cluster-Praxis

Grau ist alle Theorie – der beste Weg, um Pacemaker zu verstehen, besteht darin, mit ihm zu arbeiten. Das Konfigurationsbeispiel dieses Artikels dreht sich um einen Zwei-Knoten-Cluster. Zwar sind theoretisch bis zu 255 Knoten möglich, real dürfte die Grenze des Machbaren aber bei rund 40 liegen.

Wenn man sich noch nicht für Corosync oder Heartbeat entschieden hat, ist diese Entscheidung jetzt fällig. Denn Pacemaker lässt sich nicht direkt von der Kommandozeile aus starten. Stattdessen handelt es sich bei ihm immer um ein Plugin, das entweder von Heartbeat oder von Corosync nachgeladen wird. Zuvor sind also immer Corosync oder eben Heartbeat zu installieren.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023