Hochverfügbarkeit mit Linux

Des Servers Herzschlag

Wer sein Geld mit Onlinediensten verdient, ist auf hohe Verfügbarkeit dringend angewiesen. Das Linux-HA-Projekt befindet sich in einem tiefgreifenden Wandel. Wohin geht die Reise?
High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Hochverfügbarkeit oder High Availability (HA) hat sich in den letzten Jahren vom Nischenthema zum wichtigen Faktor für IT-Entscheider entwickelt. Wenn das Geschäftsmodell ausschließlich auf einer Website oder einem anderen Onlinedienst beruht, kostet ein Ausfall Geld und Nerven.

Ein solides High-Availability-Setup schafft in solchen Szenarien Abhilfe: Wurden beim Konzept HA-Faktoren beachtet, sind einzelne Komponenten und verschiedene Anbindungen (Netzwerk, Strom) redundant ausgelegt. Selbst beim Ausfall eines Anbieters oder einer Hardwarekomponente steht ein Ersatz zur Verfügung – Endbenutzer merken von den Problemen im Hintergrund nichts.

Dass das Thema Hochverfügbarkeit immer stärker an Bedeutung gewinnt, zeigen auch die großen Distributoren: Novell beschäftigt eine Vielzahl von Entwicklern, die ausschließlich an HA-relevanten Themen arbeiten, darunter insbesondere Pacemaker sowie das passende GUI. Novell bietet für den Suse Linux Enterprise Server sogar eine eigene HA-Extension an.

Bei Red Hat Enterprise Linux (RHEL) sind HA-Komponenten ab Werk integriert, der Hersteller steckt Manpower in die Weiterentwicklung von Pacemaker und anderen Clusterkomponenten. Schließlich unterstreicht auch die jüngst erfolgte Aufnahme von DRBD in den Linux-Kernel die Relevanz des Themas, denn DRBD kommt fast ausschließlich in HA-Szenarien zum Einsatz.

Clustermanager

Das schönste HA-Konzept bringt nichts ohne passende Software, die die Zusammenarbeit der einzelnen Komponenten steuert. Sie trägt im Fachjargon die Bezeichnung Clustermanager. Für Linux existierten bis vor einigen Monaten zwei zentrale HA-Implementationen: erstens Heartbeat [1] , zweitens die Red Hat Cluster Suite, kurz RHCS [2] .

Daneben gibt es diverse proprietäre und eng an Hersteller gebundene Lösungen wie beispielsweise Steeleyes Lifekeeper, die sich allerdings niemals nennenswert weit verbreitet haben.

Was genau ist aber eigentlich die Aufgabe eines solchen Clustermanagers? Zentral ist zweifellos das gegenseitige Testen auf Lebenszeichen der einzelnen Clusterknoten. Ein Clustermanager läuft auf jedem einzelnen Knoten eines Clusters. Er kommuniziert mit den anderen Knoten und prüft in regelmäßigen Abständen, ob diese noch funktionieren. Das tut er über mehrere Kommunikationspfade, um sicherzustellen, dass eine ausgefallene Netzwerkleitung nicht zu der falschen Annahme führt, ein Clusterknoten sei ausgefallen.

Durch die regelmäßigen Checks bemerkt der Clustermanager, wenn ein Knoten im Clusterverbund nicht mehr verfügbar ist. Für diesen Fall kennt er Sofortmaßnahmen: Eine solche könnte es zum Beispiel sein, ein Programm, das unbedingt laufen muss und das bisher auf dem nun nicht mehr verfügbaren Clusterknoten lief, auf einem anderen Knoten zu starten. Diesen Vorgang bezeichnet man als Failover. Nach außen hin muss ein typischer HA-Cluster nach dem Ausfall eines Knotens genauso aussehen wie zuvor.

Heartbeat

Ein zuverlässiger Failover war das Kernfeature von Heartbeat 1. Der Amerikaner Alan Robertson hatte bereits 1998 mit der Entwicklung dieses Clustermanagers angefangen. Am Anfang war Heartbeat 1 nicht mehr als eine große Sammlung von Skripten, die beim Ausfall eines Clusterknotens sicherstellte, dass alle konfigurierten Dienste auf dem intakten Knoten gestartet wurden.

Weitergehende Features suchte man bei Heartbeat 1 allerdings vergebens. Wenn beispielsweise ein Programm auf einem Knoten abstürzte, der Server selbst aber prinzipiell noch erreichbar war, dann hatte Heartbeat 1 keine Möglichkeit, das zu bemerken. Wirklich produktiv einzusetzen war Heartbeat 1 im HA-Umfeld damit nicht, davon abgesehen, dass Alan Robertson neuen Ideen gegenüber eher unzugänglich war.

Abbildung 1: So funktioniert Failover mit Heartbeat: In der oberen Reihe laufen die Dienste auf dem linken Rechner, der seinem Partner per Heartbeat mitteilt, dass er wohlauf ist. Fällt er aus (untere Reihe), übernimmt der rechte Rechner Dienste und IP-Adresse. (Quelle: Linbit.com)

Red Hat begann 2001 mit der Entwicklung eines eigenen Werkzeugs zum Clustermanagement, das seither auf den Namen Red Hat Cluster Suite, kurz RHCS, hört. Die RHCS war ein Fork der Load-Balancer-Software Piranha [3] und besaß erstmals so etwas wie einen Resource-Manager. Dieser weiß nicht nur jederzeit, welches Programm gerade auf welchem Knoten des Clusters läuft, sondern er prüft – bei entsprechender Konfiguration – auch regelmäßig, ob das Programm tatsächlich noch seinen Dienst wie vorgesehen verrichtet. In Red Hat Enterprise Linux 2 war die RHCS erstmals enthalten; sie ist nach vielen Updates und Facelifts bis heute fester Bestandteil von RHEL.

Im Jahre 2005 bekam Heartbeat mit dem aufkeimenden Interesse von Suse endlich ebenfalls einen eigenen Cluster Resource Manager (CRM). Heartbeat 2 beherrschte zwar ganz ähnliche Funktionen wie die RHCS, schleppte allerdings noch einige Altlasten von Heartbeat 1 mit sich herum. Dazu gehörte insbesondere der von Heartbeat 1 übernommene Cluster Communication Layer – also der Teil der Implementierung, der es den einzelnen Komponenten eines Cluster Managers erst ermöglicht, miteinander zu kommunizieren.

Bei Heartbeat 2 bauten die Entwickler den CRM kurzerhand um den alten Clustermanager herum und übernahmen auf diese Weise viele Designschwächen von Heartbeat 1. Außerdem war der CRM von Heartbeat 2 erst in der Version 2.1.4 vom August 2008 so stabil, dass Administratoren ihn ruhigen Gewissens auf Produktivsystemen einsetzen konnten.

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