Clusterbau: Hochverfügbarkeit mit Linux

Michael Schwarzkopff

Published by O’Reilly Media Germany

Vorwort

Hochverfügbarkeit ist eine inzwischen ganz übliche und wichtige Anforderung an die IT-Abteilung oder den Dienstleister, der im Kundenauftrag ein neues System plant und aufbaut. Dieses Buch soll den Administratoren, Planern und dem Betrieb einen Leitfaden an die Hand geben, um dieser Anforderung mithilfe der Clustersoftware aus entsprechenden Projekten der Open-Source-Community gerecht zu werden.

Der Leser soll nach der Lektüre dieses Buchs in der Lage sein, solche Clustersysteme so zu entwerfen, aufzubauen und zu betreiben, dass eine Verfügbarkeit von 99,99 % oder mehr kein schönes Versprechen ist, sondern eine belastbare Zahl, die in Vereinbarungen mit Kunden überprüft werden kann. Außerdem kann der Referenzteil dieses Buchs immer wieder Verwendung als Nachschlagewerk finden.

Viele Administratoren setzen die Version 1 von heartbeat noch heute ein und sind bisher vor der scheinbar komplexen Konfiguration mit pacemaker zurückgeschreckt, weil sie dort ihre einfachen Konfigurationsdateien vermissen. Diesen Administratoren soll das vorliegende Werk helfen, den ersten Schritt zu einer Konfiguration mit dem neuen Cluster-Manager zu wagen. Es wird sich nämlich zeigen, dass man die Einstellungen auch hier in Dateien mittels einer einfachen Skriptsprache erstellt und der Administrator somit weiterhin die volle Kontrolle über den Cluster behält. Auch soll dieses Buch dabei helfen, diverse Missverständnisse im Hinblick auf den Übergang von Linux-HA mit heartbeat hin zu pacemaker mit corosync auszuräumen. In Kapitel 2, wird sich zeigen, dass sich die Verwaltung im Cluster aus dem Manager von heartbeat entwickelt hat.

Die Motivation, dieses Buch zu schreiben, ergab sich für mich aus der schieren Notwendigkeit, selbst solche Cluster zu entwerfen und zu betreiben. Ein Großteil der verfügbaren Dokumentationen und Beispielkonfigurationen im Internet bezog sich allerdings auf die Version 1 der Software, und die entsprechenden Beschreibungen für Version 2 waren noch nicht so ausgereift, wie ich mir sie gewünscht hätte. Da die Möglichkeiten, die die Nachfolgepakete bieten, aber so interessant sind, ergab sich aus der Projektdokumentation erst ein kleinerer Artikel, der sich dann zu einem ganzen Buch entwickelte. Ich hoffe, mit diesem Buch nun die durchgehende Dokumentation liefern zu können, die notwendig ist, um alle Feinheiten von pacemaker zu nutzen.

Clusterbau ist eine hohe Kunst, vor allem wenn der Cluster auch in nicht vorhergesehenen kritischen Situationen seinen Dienst ohne Unterbrechung verrichten soll. Deshalb werden an den Leser keine geringen Ansprüche gestellt. Natürlich sollte er sich im Netzwerk hinreichend auskennen und mit tcpdump umgehen können, um auf dieser Ebene einen Fehler finden zu können. Zudem sollte er mit der Applikation, die sein Cluster hochverfügbar im Netz anbieten soll, ebenfalls gut vertraut sein. Nur ein gutes Verständnis von den Applikationen bietet die Grundlage, diese Anwendung auch im Cluster zum Leben zu erwecken. Gerade bei Applikationen, die Benutzerdaten dynamisch verwalten, also bei denen diese Daten auf alle Knoten des Clusters repliziert werden müssen, ist dieser Überblick notwendig, damit es nicht zum GAU des totalen Datenverlusts kommt. Aber damit wird natürlich nicht vorausgesetzt, dass der Leser jede der beschriebenen Applikationen beherrscht. Nicht zuletzt kann man auch die Kunst, ein Logfile richtig zu lesen und zu interpretieren, nicht hoch genug einschätzen.

In der 3. Auflage des Buchs ist ein eigenes Kapitel für die Infrastruktur um einen Cluster herum dazugekommen. Es reicht nicht, wenn der Computercluster zwar die hohe Verfügbarkeit bietet, aber die Umgebung noch einige Schwachstellen aufweist. So soll dieses Kapitel dem Administrator helfen, auch diese Probleme anzugehen.

Aufbau des Buchs

Ich habe versucht, die trockene Theorie von Ressourcen und Bedingungen mit Beispielen so weit wie möglich aufzulockern. Da diese Theorie jedoch notwendig ist, mag es mir nicht überall gelungen sein. Es lassen sich außerdem nicht alle Situationen und Probleme mit Beispielen abdecken – ich hoffe allerdings, dass ein tiefes Verständnis der vermittelten Grundlagen den Administrator befähigt, seine speziellen Aufgaben erfolgreich zu lösen.

Aus diesem Grund habe ich folgende Struktur für das Buch gewählt:

In Kapitel 1, werden die Grundlagen der Theorie von Hochverfügbarkeit dargestellt und dem Planer die Mittel an die Hand gegeben, die Verfügbarkeit eines komplexen Systems zu berechnen, indem er es in einfache Einheiten zerlegt. Am Ende des Kapitels stelle ich die zwei bekanntesten Projekte zur Hochverfügbarkeit vor.

Kapitel 2, beschreibt allgemein die Funktionsweise von Clustern und welche Probleme neu auftreten, die es bei Einzelsystemen nicht gibt. Zu nennen ist hier vor allem der eventuell notwendige Datenaustausch zwischen den Knoten eines Clusters. Dazu werden die Lösungen, die die Clustersoftware für die einzelnen Probleme bietet, dargestellt. Der zweite Teil des Kapitels beschreibt die interne Architektur des Programmpakets, die Bedeutung und das Zusammenspiel der einzelnen Server, die notwendig sind, um die hohe Verfügbarkeit zu erreichen.

In Kapitel 3, wird die Installation der Software auf den gängigsten Linux-Distributionen erklärt. Der Administrator, der die volle Kontrolle über das Programmpaket haben will, erfährt im Anschluss, wie er den Quellcode selbst übersetzen kann. Eine Anfangskonfiguration, der erste Programmstart und die Konfiguration einer Ressource bilden den Abschluss dieses Kapitels. Beim Schreiben des Abschnitts über die Konfiguration der ersten Ressource habe ich den ungeduldigen Administrator vor Augen gehabt. Deshalb erfolgt die Konfiguration an dieser Stelle ohne Erläuterung der Grundlagen. Methodisch veranlagte Leser mögen mir diesen Abschnitt bitte verzeihen und können ihn überspringen.

Kapitel 4, liefert die Grundlagen zu Ressourcen und Bedingungen. In den ersten Versionen des Buchs war dieses Kapitel relativ theoretisch gehalten, aber meine Lektorin hat mich überzeugt, den Stoff mit reichlich Beispielen aufzulockern. Diese Teile, die immer den gerade besprochenen Aspekt der Konfiguration noch einmal verdeutlichen, bilden keine komplette Konfiguration, die sofort ausprobiert werden soll. Vielmehr sind diese Beispiele kleine Abschnitte, die der Leser später zur Konfiguration seines eigenen Projekts verwenden kann. Komplette Konfigurationen stelle ich im Kapitel 9, weiter unten vor.

Kapitel 5, enthält die Beschreibung der verschiedenen Werkzeuge, die dem Administrator zu Verfügung stehen, angefangen bei der GUI. Nachdem der Leser im vorhergehenden Kapitel die textbasierte Konfiguration kennengelernt hat, kann er hier viele Aspekte grafisch konfigurieren. Den zweiten Abschnitt des Kapitels bilden die Werkzeuge der Kommandozeile. Mithilfe dieser Werkzeuge können die oben vorgestellten Konfigurationsschnipsel eingegeben werden – nun haben wir alles zusammen, was wir brauchen, um loslegen zu können.

Nachdem in den vorherigen Kapiteln die Grundlagen der Clustersoftware besprochen wurden, kann der Leser mithilfe der Ratschläge aus Kapitel 6, sein eigenes Projekt planen, umsetzen und betreiben. Hier erhält der Administrator die Mittel, seinen Aufbau zu testen und bei Problemen die Ursachen der Fehler zu suchen.

Das nächste Kapitel, Kapitel 7, beschreibt die Infrastruktur, in der sich ein Cluster richtig wohlfühlt. Nur wenn die Umgebung auch die hohe Verfügbarkeit bietet, können Server und Software ihre Arbeit verrichten.

Sogenannte Agenten bilden die Schnittstelle zwischen der Clustersoftware und den eigentlichen Applikationen. In Kapitel 8, werden die einzelnen Arten detailliert besprochen. Alle Agenten, die in der Software des Projekts enthalten sind, werden individuell behandelt.

In Kapitel 9, werden mit den bisher besprochenen Werkzeugen die Konfigurationen folgender Anwendungsfälle vollständig erklärt:

Distributed Redundant Block Devices (DRBD) als eine Grundlage der Datenspeicherung im Cluster.

Die DRBDs finden Anwendung in einem NFSv4-Dateiserver und einem iSCSISAN.

Ein Cluster als Basis für virtuelle Rechner, die im Fehlerfall als komplette Einheit auf den anderen Knoten verschoben werden.

Eine redundant aufgebaute Firewall, die im Fehlerfall die Tabelle der bestehenden Verbindungen mit übernehmen kann und somit eine echte Hochverfügbarkeit bietet. Die zwei VPN-Lösungen, die am weitesten verbreitet sind (OpenVPN und OpenS/WAN), werden im Rahmen dieses Beispiels mit einbezogen.

Das vorletzte Kapitel 10, beschreibt die Kombination von Linux-HA mit der Software des Linux Virtual Server (LVS), sodass ein hochverfügbarer, also hoch skalierbarer Servercluster aufgebaut werden kann. Da dieses Beispiel ein bisschen ausführlicher auf die Aspekte von LVS eingeht, habe ich hier ein eigenes Kapitel eingefügt.

Kapitel 11, beschäftigt sich abschließend mit der optimalen Überwachung des Clusters und einigen Sicherheitsaspekten, die im Betrieb zu beachten sind.

Im Anhang A werden alle Optionen der zentralen Konfigurationsdatei ha.cf von heartbeat bzw. corosync.conf aufgeführt und einzeln erklärt.

An dieser Stelle möchte ich den Lesern viel Vergnügen bei der Lektüre und viel Erfolg bei der Umsetzung der eigenen Projekte wünschen!

Die in diesem Buch verwendeten Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Nichtproportionalschrift

Wird innerhalb der Textabschnitte für Programmelemente wie Variablen- oder Funktionsnamen und für Programmlistings benutzt. Konfigurationsbeispiele, die einen Teil der Konfiguration eines Clusters darstellen, sind ebenfalls in dieser Schrift gesetzt.

Nichtproportionalschrift kursiv

Wird verwendet, um variable Eingaben anzuzeigen. Sie sollten sie durch einen Wert Ihrer eigenen Wahl ersetzen.

Kursiv

Wird für URLs, Hostnamen, Namen von Verzeichnissen und Dateien, und gelegentlich zur Hervorhebung eingesetzt.

Befehle werden oft mit einem Prompt dargestellt, um zu erläutern, in welchem Kontext sie verwendet werden. Unix-Benutzer sind es gewohnt, diesen Prompt zu sehen. Da Sie die meisten Befehle als root-Benutzer ausführen müssen, ist der Prompt durchgängig »#«.

Tipp

Dieses Icon zeigt einen Tipp, einen Vorschlag oder eine allgemeine Bemerkung an.

Warnung

Die Falle kennzeichnet eine Warnung oder ein Thema, bei dem man Vorsicht walten lassen sollte.

Danksagung

Für die Geduld, die meine Familie während der Zeit aufgebracht hat, in der ich an diesem Buch gearbeitet habe, möchte ich mich ganz herzlich bedanken: Danke Julia, Mark und Peter!

Die Hilfe bei Nachfragen und die Kontrolle des Texts durch Lars Marowsky-Brée und Andrew Beekhof war sehr hilfreich und hat viele Missverständnisse ausgeräumt. Deshalb an dieser Stelle auch noch mal ein herzliches Danke nicht nur für die Arbeit an der Software, sondern auch für die Hilfestellung beim Einsatz der Programme.

Kapitel 1. Einleitung

Von der modernen Informationstechnik wird erwartet, dass alle Dienste immer verfügbar sind. Ein Reisebüro will seine Flüge 24 Stunden am Tag anbieten, und der zentrale SAP-Server der Firma muss ebenfalls immer weltweit erreichbar sein. Aber was heißt »immer«? Und wie definiert sich »Dienst« genau? Was hat es mit der oft zitierten Verfügbarkeit von 99,99 % auf sich?

In dieser Einleitung werden die Grundbegriffe zur Hochverfügbarkeit eingeführt und die bekanntesten Projekte unter Linux vorgestellt. Mit einfachen Berechnungsmethoden kann ein IT-Architekt die Verfügbarkeit von einfachen und zusammengesetzten, komplexen Systemen vorhersagen und ihre Schwachstellen identifizieren, bevor Fehler auftreten. Sind diese Fragen geklärt, stellt sich für den Software-, Hardware- und Netzwerkarchitekten noch das Problem, wie er die Vorgaben mit dem immer zu knappen Budget erreicht.

Hochverfügbarkeit

Lassen Sie uns mit den eingangs aufgeworfenen Fragen beginnen.

Was heißt »immer«?

»Immer« heißt »zu jedem Zeitpunkt«. Wenn jemand einen Dienst anbietet, dann also zu jedem einzelnen Zeitpunkt. Aber wie lange dauert der Zeitpunkt? Und wie lange will der »Kunde« den Dienst nutzen? Das hängt natürlich von der Art des Diensts und von der Vereinbarung ab, die mit dem Kunden getroffen wurde. Es ist einfach, einen Dienst für die einmalige Nutzung für eine Sekunde anzubieten. Die Wahrscheinlichkeit, dass das, was den Dienst erbringt, genau zu diesem Zeitpunkt versagt, ist relativ gering. Aber in der Informationstechnik wollen die Kunden die Dienste 24 Stunden am Tag an 7 Tagen die Woche oder genauer gesagt an 365,2425 Tagen pro Jahr[1] nutzen. Deshalb ist es ebenso wichtig, zu vereinbaren, für welchen Zeitraum der Dienst erbracht werden soll. Üblicherweise beziehen sich die Angaben von Verfügbarkeit auf Zeiträume von einem Monat oder einem Jahr.

Am besten sieht man das, wenn man ein Beispiel durchrechnet: Der Anbieter will einen Dienst mit einer gewissen Verfügbarkeit A anbieten. Daraus kann man einfach folgende Tabelle 1.1 errechnen:

Tabelle 1.1 Verfügbarkeit und Auszeit pro Monat bzw. Jahr. Eine Verfügbarkeit von 99,99 % bedeutet zum Beispiel, dass der Dienst pro Jahr maximal knapp eine Stunde nicht verfügbar ist.

Verfügbarkeit

Auszeit pro Monat[a]

Auszeit pro Jahr

99,0 %

7,2 h

87,66 h

99,5 %

3,6 h

43,83 h

99,9 %

0,72 h

8,77 h

99,99 %

4,32 min

52,59 min

99,999 %

0,43 min

5,26 min

[a] Ein Monat wird hier der Einfachheit halber mit 30 Tagen angesetzt.

Damit ist aber noch nicht festgelegt, wann diese Auszeiten auftreten und wie lange sie maximal dauern dürfen. Bei der Angabe einer Verfügbarkeit von 99,5 % bezogen auf den Basiszeitraum »ein Jahr« kann eine einzelne Störung eben doch über 40 Stunden (also fast zwei Tage) dauern, wenn sonst keine weitere Störung in diesem Jahr auftritt. Die mittlere Zeit bis zur Störungsbehebung (engl. Mean Time To Repair, MTTR) ist deshalb auch eine wichtige Größe, die in einer Servicevereinbarung (Service Level Agreement, SLA) ebenfalls festgehalten werden sollte. Aus Kundensicht wäre allerdings eine Vereinbarung der maximalen Zeit zur Behebung der Störung wünschenswert.

In der folgenden Tabelle 1.2 sind Größenordnungen der MTTR für einen Ausfall der Hardware dargestellt – in Abhängigkeit vom Betriebsaufwand, mit dem man den Dienst betreibt.

Sie zeigt, dass die Wiederherstellungszeit klar von den Kosten für den Betrieb abhängt. Dasselbe gilt für Ausfälle, die durch Softwarefehler verursacht werden: Je mehr Aufwand in den Betrieb investiert wird, desto geringer ist die mittlere Zeit bis zum Wiederanlaufen des Diensts (siehe Tabelle 1.3).

Tabelle 1.2 Größenordnungen für die Wiederherstellungszeit eines Diensts beim Ausfall einer Hardwarekomponente in unterschiedlichen Betriebskonzepten. Je aufwendiger der Betrieb gestaltet wird, desto kürzer ist auch die Zeit bis zum Neustart des Diensts.

Ersatzteile

Personal

Größenordnung für die MTTR

Vor Ort

24 h/Tag

30 Minuten

Vor Ort

Rufbereitschaft

2 Stunden

Vor Ort

Normale Arbeitszeit

3 Tage (Wochenende!)

Kurierdienst

Rufbereitschaft

1 Woche

Kurierdienst

Techniker wird bestellt

2 Wochen

Das schnelle Wiederanlaufen des Diensts wird in Tabelle 1.3 durch automatisierte Systeme zur Erkennung des Fehlerfalls und zur Problembehebung durch Neustart erreicht.

Tabelle 1.3 Größenordnungen für die Wiederherstellungszeit eines Diensts bei einem Fehler der Software. Nur wenn Problemdiagnose und -behebung automatisiert sind, lassen sich wirklich kurze Zeiten erreichen.

Mechanismus zur Fehlererkennung

Mechanismus für den Neustart

Größenordnung der MTTR

Monitoring-System

Automatischer Neustart von ROM-Abbild

30 Sekunden

Monitoring-System

Automatischer Neustart des Diensts ohne Neustart des Systems

30 Sekunden

Monitoring-System

Automatischer Neustart des gesamten Systems

3 Minuten

Monitoring-System

Automatischer Neustart des Systems und Wiederherstellung durch Herunterladen von einem Zentralsystem

10 Minuten

Keine automatische Fehlererkennung

Manueller Neustart

min. 30 Minuten

Noch eine wichtige Größe in diesem Zusammenhang ist die mittlere Zeit zwischen zwei Ausfällen. Im Englischen heißt diese Zeit Mean Time Between Failures und wird mit MTBF abgekürzt. Diese MTBF ist eine übliche Größenangabe bei Hardwarekomponenten. Bei neuen Komponenten ist hier ebenfalls die Zeit bis zum erstmaligen Ausfall gemeint (engl. Mean Time To Failure, MTTF). In Datenblättern von Festplatten ist sie zum Beispiel meist mit angegeben. Der Vergleich der MTBF-Werte zeigt auch, warum eine SCSI-Festplatte (SAS) für einen Server so viel mehr kostet als eine SATA-Festplatte für einen Desktop-Rechner.

Natürlich gelten diese Angaben der mittleren Zeiten bis zum Fehler (MTBF) immer nur für eine große Anzahl von Geräten. Von dem Ausfall einer Festplatte im Rechner zu Hause kann man nicht auf einen Fehler in der Produktion oder im Design schließen. Nur wenn sich Fehler beim Test einer ganzen Charge von Festplatten häufen, muss der Hersteller aufmerksam werden.

Die Verfügbarkeit (engl. Availability) errechnet sich aus den oben gegebenen Größen als Verhältnis der Zeit, in der das System funktioniert (also kein Fehler vorliegt), zur Gesamtzeit, die betrachtet wird:

Die in Tabelle 1.1 angegebene Auszeit (engl. Downtime), die intuitiv am besten erfassbare Größe, lässt sich leicht aus der Verfügbarkeit A ableiten:

Ausszeit = (1 – A) × Basiszeitraum

Der Basiszeitraum ist dabei die Zeit, die im SLA vereinbart wurde, meistens ein Monat oder ein Jahr. Bei der konkreten Berechnung ist auch zu beachten, ob ein Kalendermonat als Abrechnungszeitraum oder »die letzten 30 Tage« betrachtet werden.

Was heißt »Dienst«?

Jeder versteht unter dem Begriff »Dienst« etwas anderes. Ein Provider (ISP) und sein Kunde werden in erster Linie an die Möglichkeit des Transports von IP-Paketen zwischen Hausanschluss und beliebigen anderen Hosts im Internet denken. Der Kunde, der einen Rootserver in einem Rechenzentrum gemietet hat, will dazu noch eine ausfallsichere Stromversorgung, eine funktionierende Klimaanlage und vielleicht ein Backup-System, wogegen der Webhoster sich auch noch um die entsprechende Applikation kümmern muss.

Der Internetnutzer, der bei seiner Bank seinen Kontostand überprüft oder gerade etwas ersteigert, will, dass sein Internetanschluss funktioniert, dass alle Router bei den verschiedenen Providern funktionieren, der Server der Gegenseite und die Applikation, die er gerade nutzen will, zum Beispiel der Webserver und die Datenbank, auf die dieser zurückgreift. Natürlich muss sein Rechner zu Hause auch noch funktionieren, damit er erfährt, dass er mit dem gerade ersteigerten Wunschtraum sein Konto endgültig in die roten Zahlen gebracht hat.

So versteht jeder Nutzer ein bisschen etwas anderes unter »Dienst«, und der Begriff wird meist erst im Kontext verständlich. Wenn das »Internet nicht geht«, kann das viele Ursachen haben, aber der Benutzer merkt nur, dass er nicht mehr surfen kann. Es kann daran liegen, dass gerade ein Bagger die Leitung vor seinem Haus durchtrennt hat oder dass der Provider ein Problem mit der Authentifizierung des Kunden hat, weil der RADIUS-Server Schwierigkeiten macht.

Im Weiteren werde ich versuchen, den Begriff »Dienst« im Sinne von »Dienst, den eine Applikation erbringt, die auf einem Rechner läuft« zu verwenden. Wenn diese Definition nicht überall durchgehalten wird, sollte zumindest der Sinn aus dem Kontext heraus klar werden.

Gekoppelte Systeme

Wie oben dargestellt wurde, müssen viele einzelne Komponenten zusammenspielen, damit ein Server einen Dienst erbringen kann und die Kommunikation zwischen Client und Server auch funktioniert.

Die Stromversorgung für den Server (oder gleich das ganze Rechenzentrum) ist ein schönes Beispiel. Die konstante Energiezufuhr ist eine der wesentlichen Voraussetzungen für das Funktionieren des Diensts. Zwar ist die Stromversorgung in Deutschland eine der sichersten der Welt, aber wie die Zahlen zeigen (siehe Tabelle 1.4), kann man sich auch nicht zu 100 % auf sie verlassen.

Tabelle 1.4 Versorgungssicherheit mit elektrischer Energie. Die Zahlen stammen vom Electric Power Research Institute (EPRI).

Durchschnittliche Ausfallzeit

Verfügbarkeit

Japan

6 Minuten

> 99,99 %

Deutschland

23 Minuten

> 99,99%

Frankreich

53 Minuten

99,99%

Großbritannien

70 Minuten

99,98%

USA

214 Minuten

99,96%

Wer im Durchschnitt einen Dienst mit mehr als den oben genannten Zahlen anbieten will, muss eine unterbrechungsfreie Stromversorgung mit einplanen. Grundsätzlich ist eine solche Stromversorgung auch deshalb sinnvoll, weil ein abrupteres Ausschalten noch keinem Server gutgetan hat und allein die Zeit zum Überprüfen der Festplatten und Anlaufen der Dienste die Zeit der meist sehr kurzen Probleme der Stromversorgung bei Weitem übersteigt.

Aber das Beispiel Stromversorgung zeigt noch etwas anderes: Der Dienst ist vom Funktionieren vieler einzelner Komponenten abhängig. Damit eine Applikation auf einem Server laufen kann, müssen zum Beispiel die Stromversorgung, die Hardware mit Prozessor, RAM und Festplatte, das Betriebssystem und die Applikation selbst funktionieren. Damit die Daten vom Client zum Server und zurück transportiert werden können, müssen die Netzwerkschnittstellen der beteiligten Rechner, die Kabel, Switches, Router, Firewalls und alle weiteren Netzwerkkomponenten dazwischen in Ordnung sein. Kann man aus der einfachen Formel von oben jetzt die Verfügbarkeit von komplexen Systemen herleiten? Grundsätzlich: Ja! Denn man kann jedes noch so komplexe System auf einfache Bausteine zurückführen, die untereinander nur auf zwei unterschiedliche Arten verschaltet sind.

Serielle Kopplung

Beginnen wir mit einer einfachen seriellen Kopplung (siehe Abbildung 1.1):

Abbildung 1.1 Serielle Kopplung zweier Teile zu einem Gesamtsystem.

Ein solches System besteht aus zwei Komponenten und das Funktionieren des Gesamtsystems hängt vom Funktionieren beider Komponenten ab. Die Verfügbarkeit Aser des Gesamtsystems berechnet sich aus der jeweiligen Verfügbarkeit der einzelnen Komponenten wie folgt:

Aser = A₁ × A₂

Die Verfügbarkeit ist also immer kleiner als die kleinste Verfügbarkeit der einzelnen Komponente. Wenn A₁ = 99% und A₂ = 99,95% ist, beträgt die gesamte Verfügbarkeit nur Aser = 98,95%. Sie wird hauptsächlich von A₁ bestimmt. Wenn man also die Verfügbarkeit dieses Systems verbessern will, muss man eine bessere Komponente 1 verwenden. Es nützt nichts, die Komponente 2 zu verbessern. Hier drängt sich natürlich der Vergleich mit einer Kette auf: Auch sie ist immer nur so stark wie ihr schwächstes Glied.

Parallele Kopplung und Redundanz

Der andere grundlegende Fall ist die parallele Kopplung, bei der zwei Komponenten den gleichen Dienst erbringen (siehe Abbildung 1.2).

Abbildung 1.2 Parallele Kopplung zweier Teile zu einem Gesamtsystem.

Dieses System besteht ebenfalls aus zwei Komponenten, aber das Funktionieren des Gesamtsystems hängt von der Funktion einer der beiden Komponenten ab. Die Verfügbarkeit Apar des Gesamtsystems berechnet sich in diesem Fall aus der jeweiligen Verfügbarkeit der einzelnen Komponenten wie folgt:

Apar = 1 –(1 – A₁)(1 – A₂)

Im Fall, dass beide Komponenten identisch sind, reduziert sich die Formel auf:

Apar = 1 –(1 – A₁)²

Man erkennt, dass die Verfügbarkeit des gesamten Systems in diesem Fall immer höher ist als die Verfügbarkeit der einzelnen Komponenten. Ein kleines Rechenbeispiel anhand einer Einzelkomponente mit einer Verfügbarkeit von 99% verdeutlicht das noch besser (siehe Tabelle 1.5). Die Redundanz gibt dabei an, wie oft eine einzelne Komponente im System vorhanden ist.

Tabelle 1.5 Verfügbarkeit bei redundanter Auslegung mit identischen Komponenten. Jede einzelne Komponente ist zu 99 % verfügbar. Je öfter diese Komponente im System vorhanden ist, desto besser ist das Gesamtsystem gegen Ausfall geschützt.

Grad der Redundanz

Verfügbarkeit Apar

Mittlere Auszeit

1

99,0 %

87,66 h/Jahr

2

99,99 %

52,6 min/Jahr

3

99,9999 %

31,6 sek/Jahr

Aus diesem Rechenbeispiel erkennt man, dass die Grundlage aller hochverfügbaren Systeme die 3R-Regel ist:

3R-Regel für hochverfügbare Systeme:

»Redundanz, Redundanz und noch einmal Redundanz!«

Jede einfache Komponente im System, von der die Funktion des gesamten Systems abhängt, nennt man auch Single-Point-of-Failure (SPoF). Die ganze Kunst der Hochverfügbarkeit ist ein Design, bei dem diese SPoF durch Einsatz von redundanten Einzelkomponenten vermieden werden.

Ein einfaches Beispiel für den erfolgreichen Einsatz des obigen Prinzips ist das »redundante Array billiger Festplatten« (Redundant Array of Inexpensive Disks, RAID). Da die Festplatten immer noch zu den anfälligsten Komponenten in einem Server gehören, ist der Einsatz von gespiegelten Festplattensystemen eine weitverbreitete Technik, um die Zuverlässigkeit zu erhöhen. Ein Beispiel dazu: Ein Server wird aus Kostengründen mit billigen Desktop-IDE-Festplatten ausgestattet. Zwei Festplatten sind als RAID1-System ausgelegt, bei dem die Daten auf zwei Festplatten redundant gespeichert werden. Der Hersteller gibt eine MTBF von 300.000 Stunden an, allerdings nur, wenn die Festplatten im Durchschnitt nicht länger als 330 Stunden pro Monat oder 11 Stunden pro Tag laufen. Diese Kennzahl findet sich in Datenblättern in der Rubrik Power-on-Hours (PoH). Aus diesem Grund kann man die tatsächliche MTBF im Betrieb als Speicher für einen Server gut mit maximal 150.000 Stunden abschätzen. Die Wahrscheinlichkeit, dass die Festplatte innerhalb der Lebensdauer des Servers von fünf Jahren ausfällt, kann man über den Umweg der Annual Failure Rate (AFR) berechnen. 300.000 Stunden ergeben bei einem Betrieb von 330 Stunden pro Monat 75,75 Jahre. Ein hypothetischer Fehler im Jahr ergibt dann:

AFR = (PoH pro Jahr / MTBF) × 100 %

In unserem Beispiel erhält man eine AFR von 1,32 %. Die Wahrscheinlichkeit, dass die Festplatte nach fünf Jahren Dauerbetrieb im Server noch immer ihren Dienst versieht, ist dann:

p = (1 – AFR)⁵ = 93,5 %

Umgekehrt (1 – p) ist die Wahrscheinlichkeit für einen Ausfall mit 6,5 % also nicht zu vernachlässigen.

Nach gut 4,5 Jahren Betrieb zeigen sich die ersten Ausfallerscheinungen bei einer Festplatte, und nach 42.000 Stunden Betrieb gibt sie ganz auf. Wahrscheinlich war die Umgebungstemperatur höher, als nach der Spezifikation zugelassen.

Der Administrator, durch die Warnsignale mittels S.M.A.R.T. (Linux: smartd) alarmiert, kann schnell eine Ersatzfestplatte einbauen. Weil IDE-Festplatten nicht Hotplug-fähig sind, hat der Server dadurch eine Auszeit von 1 Stunde und 24 Minuten. Das Teilsystem »Festplatten« des Servers hat also in den ersten 4 Jahren und 9 Monaten eine Verfügbarkeit von 99,9967 %. Ohne RAID wäre die Zeit zur Rettung und zum Wiedereinspielen der Daten (Time To Repair, TTR) wesentlich länger als die 1,4 Stunden zum Einbau der neuen Festplatte und zur Wiederherstellung des funktionsfähigen RAID gewesen.

Tipp

Bitte beachten Sie, dass in diesem Beispiel eine TTR angegeben ist. Eine mittlere Zeit (MTTR) kann nicht angegeben werden, da es sich bei diesem Server um ein Einzelbeispiel handelt und nicht um eine große Anzahl zur Berechnung der gemittelten Werte.

Komplexe zusammengesetzte Systeme

Ein komplexes System kann man in Einzelkomponenten zerlegen, die durch einfache serielle oder parallele Verknüpfungen untereinander verbunden sind. Anhand der obigen Regeln kann somit sukzessiv die Verfügbarkeit für das gesamte System berechnet werden. Betrachten wir noch ein Beispiel für die Berechnung eines solchen Gesamtsystems: Ein Webserver soll ans Internet angeschlossen werden. Die wesentlichen Komponenten, auf die der Planer Einfluss hat, sind das LAN im Rechenzentrum und der Server selbst. Es gelten die Annahmen aus Tabelle 1.6:

Tabelle 1.6 Annahmen für die Verfügbarkeit von Hard- und Software eines einfachen Webservers.

MTBF (aus Datenblättern)

MTTR (aus Tabelle 1.2)

Verfügbarkeit

Applikation

-

-

99,994 % (gemessen)

Server (ideal)

50.000 h

2 h

99,996 %

Server (real)

50.000 h

48 h

99,904 %

Server + Applikation

99,898 % (seriell)

Switch

250.000 h

2 h

99,999 %

Router + Internet

99,95 % (Vertrag mit ISP)

Gesamt

99,85%

Wie kann der Planer jetzt mit einfachen Mitteln die Verfügbarkeit erhöhen? Es ist klar, dass die Hardware des Servers das Problem ist. Anhand der Zahlen sieht man, dass es zwei Ansätze gibt, um die Verfügbarkeit des Diensts zu erhöhen:

Der Planer könnte den Prozess der Sicherung und der Wiederherstellung des Servers verbessern: Die 48 Stunden Zeit zur Wiederherstellung sind für einen Administrator mit normalen Arbeitszeiten und für die Beschaffung der Hardware im Fehlerfall gerechnet. Ein Vergleich mit Tabelle 1.2 zeigt, dass diese Werte schon günstig geschätzt sind. Maßnahmen zur Verbesserung könnten die Lagerung von Ersatzhardware und die Einführung eines Bereitschaftsdiensts für Administratoren sein. Ebenfalls ist eine automatische Sicherung der Server und schnelle Wiederherstellung von der Sicherung wichtig. Dazu wird ein professionelles Backup-System benötigt.

Alternativ sollte es möglich sein, das System »Server+Applikation« redundant auszulegen. Wenn man die Ersatzhardware vor Ort hält, kann man gleich die beiden Server dazu nutzen, einen Webserver-Cluster laufen zu lassen. Für das redundante System aus Server und Applikation ergibt sich eine Verfügbarkeit von 1 –(1 – 0,999)² = 99,9999%, das ist wesentlich besser als die Anbindung ans Internet, der nächste Schwachpunkt. Somit kann der Administrator wieder in Ruhe schlafen, und ein guter Sicherungsprozess mit schneller Wiederherstellung ist aufgrund der Verfügbarkeit nicht mehr dringend notwendig. Damit ist nicht gesagt, dass ein Backup überhaupt nicht mehr notwendig ist, aber eine so schnelle Wiederherstellung des Systems ist nicht mehr erforderlich.

Zusätzlich wird deutlich, dass eine Investition in das Netzwerk zur redundanten Auslegung des Switchs und der Kabel sowie eine doppelte Anbindung der Server ans Netz mit sogenannten bond-Schnittstellen auch nicht dringend erforderlich ist, wenn kein Systemheld im Rechenzentrum herumirrt, der willkürlich Kabel zieht. Eine nicht zu unterschätzende Fehlerquelle, die noch gar nicht in die Berechnung eingegangen ist, sind menschliche Fehler, besonders jegliche Art von Fehlern, die System-, Netzwerk- oder Firewall-Administratoren machen.

Anhand dieses kleinen Rechenbeispiels erkennt man die Notwendigkeit eines redundanten Aufbaus von Servern und Applikationen schnell. Welche Möglichkeiten gibt es dazu?

Am bekanntesten sind sicherlich die Projekte „Linux Virtual Server (LVS)“ (LVS[2]) und die „Linux-HA“[3]. Der Linux Virtual Server implementiert einen Switch auf Layer 4 des bekannten OSI-Modells (TCP bzw. UDP) als Dienst, der auf einem Server, Director genannt, läuft. Eingehende Verbindungen werden entgegengenommen und an reale Server zur Verarbeitung weitergeleitet. Der LVS fungiert hier nur als sogenannter Director, der die Verbindungen und die Last an die Server verteilt. Gleichzeitig wird mit einem Zusatzdienst gemessen, ob die Server noch leben oder ob keine Verbindungen mehr zu einem bestimmten Server weitergegeben werden sollen.

Das andere bekannte Software sind die Folgeprojekte von Linux-HA. Ein Heartbeat-Mechanismus überprüft die Erreichbarkeit von Servern, und der Cluster-Manager checkt die Verfügbarkeit von Diensten auf diesen Servern. Falls es Probleme mit der Verfügbarkeit eines Knotens im Cluster gibt, sorgt der Cluster-Manager dafür, dass die Ressourcen, die auf diesem Knoten liefen, auf andere Knoten des Clusters verschoben werden. Somit ist ein Cluster, der mit dieser Software aufgebaut wurde, in erster Linie dafür gedacht, eine hohe Verfügbarkeit durch redundanten Aufbau zu gewährleisten. Ein Skalieren des Aufbaus ist im Grunde nicht vorgesehen, da so ein Cluster als System ausgelegt ist, bei dem ein Knoten die Last übernimmt und der andere nur im Fehlerfall einspringt (Hot-Standby oder Aktiv/Passiv-System). Eine Lastverteilung, sodass mehrere Server die eingehenden Anfragen beantworten, findet in einem solchen Cluster normalerweise nicht statt. Mit welchen Mitteln das in bestimmten Fällen doch erreicht werden kann, wird später gezeigt (siehe Kapitel 8, Abschnitt „IPaddr“).

Natürlich lassen sich in großen Clustern auch viele Ressourcen auf vielen Servern ausführen, die zusammen den Cluster bilden.

Linux Virtual Server (LVS)

Der Linux Virtual Server implementiert einen Layer-4-Switch im Kernel des Betriebssystems, auf dem der LVS läuft. Über den Switch werden eingehende Verbindungen an eine Reihe von Servern verteilt, auf denen der Dienst tatsächlich läuft. Dieser sogenannte Director macht nichts anderes, als die eingehenden Verbindungen zu verteilen. Da der Switch auf Layer 4 (tcp oder udp) arbeitet, werden alle Pakete, die zu einer tcp-Verbindung gehören, an denselben Server weitergeleitet, sodass dieser die komplette Anfrage beantworten kann. Der Director kann sich aber auch um Anwendungen, die udp-Pakete verschicken, kümmern und sogar icmp-Pakete an die Server im Hintergrund verteilen.

Ein Vorteil der Verteilung auf Layer 4 ist sicherlich die hohe Geschwindigkeit, mit der der Director arbeiten kann. Es wird nur der Header des Pakets überprüft, es werden aber keine Applikationsdaten inspiziert. Das Verfahren hat natürlich den Nachteil, dass neue tcp-Verbindungen nicht notwendigerweise zum selben Server weitergeleitet werden und somit das Problem des Datenaustauschs zwischen den Applikationen auf den einzelnen Servern besteht. Dieses Problem macht sich zum Beispiel bemerkbar, wenn Cookies eines Webservers über eine längere Zeit beibehalten werden müssen.

Dieses Problem umgeht LVS mit sogenannten Persistent Connections. Bei dieser Einstellung werden Verbindungen, die vom selben Client oder Netzwerk kommen, immer an denselben Server weitergeleitet. Die Granularität der Entscheidung für die Persistent Connections lässt sich einstellen.

Die Verteilung der Verbindungen

Der einfachste Verteilungsalgorithmus des Director ist Round-Robin. Die Verbindung erhält einfach der nächste in der Reihe der verfügbaren Server. Dieser Algorithmus lässt sich noch über Wichtungen der Serverleistung verfeinern. Da der Director natürlich die Anzahl der aktuell bestehenden Verbindungen zu jedem einzelnen Server im Hintergrund kennt, können mittels eines entsprechenden Algorithmus auch neue Verbindungen an denjenigen Server weitergegeben werden, der aktuell am wenigsten verarbeitet. Bei diesem Algorithmus lassen sich ebenfalls wieder Wichtungen für einen einzelnen Server konfigurieren. Es sind noch eine Reihe weiterer Algorithmen implementiert. Insgesamt können zehn verschiedene Methoden ausgewählt werden, die aber meist nur Varianten einer grundlegenden Idee sind. Am gebräuchlichsten sind sicher (Weighted) Round-Robin und (Weighted) Least Connections.

Technisch ist die Verteilung der Pakete an die tatsächlichen Server über drei verschiedene Verfahren möglich:

Weiterleitung per Network Address Translation (NAT)

Weiterleitung durch direktes Routing

Weiterleitung per IP-Tunnel

Weiterleitung per NAT

Im ersten Fall verhält sich der Director wie ein einfacher Router, der per NAT-Mechanismus die Zieladressen der Pakete umsetzt und diese dann weiterleitet. Die Antwortpakete der Server müssen ebenfalls über den Director geroutet werden, um die Adressen wieder richtig umzuwandeln. Dieser Mechanismus ist in Abbildung 1.3 skizziert. Er hat den Vorteil, dass er relativ einfach zu implementieren ist und die tatsächlichen Server irgendwo stehen können, solange sie nur per IP-Adresse erreichbar sind. Ebenso kann auf den Servern im Hintergrund jedes beliebige Betriebssystem laufen, solange dieses eine TCP/IP-Schnittstelle bietet. Der Nachteil der Methode ist, dass alle Pakete, also auch die meistens großen Antwortpakete, über den Director geroutet werden müssen und dieser die NAT-Tabellen pflegen muss. Somit ist diese Methode nicht allzu weit skalierbar. Üblich sind Installationen mit bis zu 20 realen Servern.

Abbildung 1.3 Beim NAT-Mechanismus schickt der Client die IP-Pakete an den Director (1), der sie mit einer neuen IP-Adresse versieht und an den zuständigen Server weitersendet (2). Dieser schickt die Antwortpakete zurück an den Director (3), der wiederum die IP-Adresse austauscht und sie an den Client zurücksendet (4).

Weiterleitung durch direktes Routing

Bei der zweiten Methode schreibt der Director einfach nur die MAC-Adresse des Pakets um und schickt es so an den richtigen Server weiter. Diese Methode ist in Abbildung 1.4 dargestellt. Sie benötigt den geringsten Aufwand, allerdings müssen sich hierbei der Director und alle Server im selben Subnetz befinden, da die Verteilung im Prinzip auf Layer 2 des Netzwerks implementiert ist. Die Antwortpakete gehen wieder direkt an den Client. Damit dies zu keinem Chaos im angeschlossenen lokalen Netz führt, darf es nur auf Schnittstellen erfolgen, auf denen die ARP-Auflösung abgeschaltet werden kann, also keine Antworten auf ARP-Requests versendet werden.

Abbildung 1.4 Im DR-Modus versieht der Director das eingehende Paket mit einer neuen MAC-Adresse und schickt es an den Server weiter (1). Dieser kann die Antwort wiederum direkt an der Client schicken (2).

Weiterleitung per IP-Tunnel

Um die Aufzählung zu komplettieren, sei hier auch noch die dritte Methode erwähnt. Anstatt die eingehenden Pakete mit einer neuen MAC-Adresse zu versehen und weiterzuschicken, nutzt der Director IP-Tunnel, um die Pakete an die tatsächlichen Server weiterzuleiten. Der Director tunnelt die Pakete zum Server im Hintergrund, indem er sie mit einem neuen IP-Header versieht und an den Server weiterschickt. Dieser packt den Tunnel aus und beantwortet die Anfrage. Da die tatsächlichen Adressen der Clients auf dem Weg nicht verändert wurden und somit auf dem Server bekannt sind, kann dieser die Antwortpakete direkt an den Client senden. Diese Methode wird in Abbildung 1.5 skizziert. Das Paket muss nicht mehr über den Director zurückgeroutet werden. Somit ist diese Methode weitaus besser skalierbar als die erste Methode. Ein Fallstrick bei dieser Methode ist der Umstand, dass nicht mehr jedes beliebige Betriebssystem im Hintergrund verwendet werden kann. Die Schnittstellen müssen IP-in-IP-Tunnel beherrschen, da der Director die Pakete ja mit einem neuen IP-Header versieht. Weil die ursprüngliche Clusteradresse im weitergeleiteten Paket noch vorhanden ist, muss diese virtuelle IP-Adresse auf allen Servern im Hintergrund konfiguriert werden, damit sich die Server für dieses Paket zuständig fühlen.

Die realen Server müssen bei dieser Methode wiederum über eine Non-ARP-Schnittstelle verfügen. Mit den beiden letzten Methoden sind große Installationen mit Hunderten von Servern möglich. Begrenzt wird die Lastverteilung eigentlich nur durch die Fähigkeiten, die der Director als Router hat.

Abbildung 1.5 Beim Tunneln packt der Director alle Pakete für den Server in einen IP-in-IP-Tunnel und schickt sie so weiter (1). Der Server packt den Tunnel aus und kann dem Client direkt antworten, ohne den Umweg über den Director zu nehmen (2).

Die Tabelle 1.7 fasst noch einmal die Vor- und Nachteile der einzelnen Mechanismen zur Weiterleitung der Pakete zusammen:

Tabelle 1.7 Übersicht über die Methoden zur Weiterleitung der Pakete an die realen Server im Hintergrund. Jede Methode hat ihre Vor- und Nachteile.

NAT

Direct Routing

Tunnel

Betriebssystem der realen Server

Beliebig

Non-ARP-Schnittstelle

IP-Tunnel notwendig, Non-ARP-Schnittstelle

Servernetz

(Private Adressen)

LAN

LAN/WAN

Anzahl realer Server

Bis zu 20

> 100

> 100

Gateway der Server

Director

Eigenes Routing

Eigenes Routing

Die Entwickler von LVS haben die Fähigkeit zur Kooperation mit dem netfilter-Teil des Kernels verbessert. Ab Kernel Version 2.6.36 beherrscht LVS deshalb noch einen weiteren Trick:

Beim NAT-Mechanismus ändert LVS die Zieladresse des Pakets. netfilter kann aber gleichzeitig dazu konfiguriert werden, die Absenderadresse so zu ändern, dass es für den realen Server so aussieht, als käme das Paket vom Director selbst. Das Routing am realen Server muss nicht verändert werden. Der reale Server schickt die Antwort an den Loadbalancer zurück, und dieser stellt die ursprünglichen Absender- und Zieladressen wieder her. So erreicht das Paket den Client.

Vor- und Nachteile von LVS

Mit dem LVS-System lässt sich die Last gut auf viele Server verteilen. Allerdings verfügt das ip_vs-Kernelmodul nicht über die Fähigkeit, zu überprüfen, ob die konfigurierten Server noch leben oder nicht. Es stellt nur die Grundfunktion des Switch auf Layer 4 zur Verfügung. Für einen kompletten Cluster ist noch ein Zusatzprozess notwendig, der die Server im Hintergrund andauernd abfragt. Anhand der Antwort entscheidet dieser Daemon, ob der Server noch lebt oder der entsprechende Server aus der Konfiguration genommen werden muss und die bestehenden Verbindungen auf andere Server verteilt werden müssen. Solche Programme sind zum Beispiel ldirectord oder keepalived.

Mit einer derartigen Konfiguration können sehr hoch skalierbare Serversysteme aufgebaut werden.

Es bleibt das Problem, dass der Director selbst einen Single-Point-of-Failure darstellt, da er selbst nur einmal im System vorhanden ist und alle Verbindungen über ihn vermittelt werden. Wenn er ausfällt, steht das gesamte System. Hier kommen die Nachfolgeprojekte von Linux-HA zum Zuge. Mit dieser Software können (fast) alle beliebigen Dienste redundant angeboten werden. Über zwei separate Rechner kann auch der Director-Dienst entsprechend hochverfügbar gestaltet werden.

Eine entsprechende Konfiguration mit einem Director in einem hochverfügbaren Clustersystem wird in Kapitel 9, als Beispielanwendung gezeigt.

Linux-HA

Das Projekt Linux-HA mit dem zentralen heartbeat-Dienst entstand 1997 aus einer Designidee von Harald Milz, der die Grundzüge und Techniken eines hochverfügbaren Clusters in einem HOWTO zusammenfasste.[4] Diese Veröffentlichung inspirierte Alan Robertson, diese Ideen tatsächlich umzusetzen, und so lief der erste Linux-HA-Cluster am 18. März 1998 an. Die Software wurde dann beim ersten Kunden Ende 1999 eingesetzt, um dessen Webseite hochverfügbar anzubieten.

Obwohl die Funktionen der Version 1 der Software relativ begrenzt waren, gab es innerhalb kurzer Zeit über 30.000 Installationen. Die Version 2 wurde am 29. Juli 2005 veröffentlicht und seitdem ständig verbessert. Viele der Einschränkungen in Version 1 sind in Version 2 weggefallen. In Version 3 des Projekts hat ein Teil der Entwickler die zentrale Management-Komponente von Version 2 in ein eigenes Projekt ausgegliedert und nutzt das ursprüngliche heartbeat nur noch zur Kommunikation. Mehr zu diesem Thema finden Sie in Kapitel 2 im Abschnitt „Architektur der Software“.

Der Erfolg der Software erklärt sich auch mit der GPL-Lizenz, die es jedem erlaubt, nicht nur die Software herunterzuladen und kostenlos zu nutzen, sondern die auch den Einblick in den Sourcecode ermöglicht. So wurde die Software von vielen Nutzern verbessert, die eine allgemeingültige Lösung für ein spezielles Problem gefunden und programmiert haben. Diese Lösungen fließen wieder in das Projekt ein und helfen so, die Qualität und den Nutzen der Software ständig zu verbessern.

Unter Linux-HA sorgt ein heartbeat-Dienst dafür, dass die Mitglieder eines Clusters ständig Nachrichten austauschen, um den Status gegenseitig zu überwachen. Sogenannte Ressourcen werden vom Cluster-Manager verwaltet und auf einzelnen Knoten gestartet. Ressourcen sind deshalb im Verständnis von Linux-HA all das, was vom Cluster verwaltet wird, von IP-Adressen bis zu Diensten wie einem Apache-Webserver, von der Überwachung des eigenen Systems bis zu komplexen Mechanismen zur Datenreplikation zwischen den Knoten des Clusters. Auf der Projektseite ist dies gut zusammengefasst: »If we manage it, it is a resource.«

Der Cluster-Manager selbst bietet ab Version 2 von Linux-HA die Möglichkeit, die Überwachung des Zustands der Knoten oder ihre Erreichbarkeit im Netz zu konfigurieren. Bei Problemen eines Knotens oder eines Diensts auf einem Knoten verlagert der Manager Ressourcen, die auf diesem Knoten liefen, auf einen anderen Knoten. Somit ist diese Ressource im Gesamtsystem (Cluster) weiterhin verfügbar, obwohl ein einzelner Knoten ausfallen kann.

Im Prinzip können alle beliebigen Dienste, für die ein init-Skript im Stil von System-V existiert, mittels Linux-HA hochverfügbar angeboten werden. Zusätzlich gibt es im Projekt noch spezielle Skripte (Agenten), die weitere Funktionen wie IP-Adressen oder die Überwachung übernehmen. Für viele weitverbreitete Dienste gibt es auch spezielle Agenten, die im Gegensatz zu System-V-Skripten noch eine genauere Überwachung erlauben als nur die einfache Statusabfrage des Diensts.

Die Software des Linux-HA-Projekts ist aus verschiedenen Komponenten zusammengesetzt. Ein Teil kümmert sich um die Mitgliedschaft von Knoten im Cluster und schickt Meldungen ins System, wenn Knoten zum Cluster hinzukommen oder ihn verlassen. Ein anderer Teil macht sich aufgrund der Konfiguration und des aktuellen Zustands der Knoten im Cluster ein Bild von der Lage und verteilt die Ressourcen optimal nach den Bedingungen der Konfiguration. Falls ein Knoten stirbt, müssen die Ressourcen neu auf die verbliebenen Knoten verteilt werden. Daneben gibt es den Teil der Software, der versucht, die Idealvorstellung vom Cluster auch tatsächlich auf den einzelnen Knoten durchzusetzen. Erfolg oder Misserfolg dieser Aktionen werden wieder an das System zurückgemeldet.

Die weiteren Entwicklungen im Projekt ermöglichen der Verwaltung im Cluster, nun nicht nur heartbeat als Kommunikationsplattform zu nutzen, sondern erlauben auch die fortgeschrittene Technik von OpenAIS bzw. corosync.

Die Entwickler, die inzwischen für das Projekt verantwortlich zeichnen, stehen zum großen Teil auf den Gehaltslisten der Hersteller der großen Linux-Distributionen. Red Hat ist die treibende Kraft hinter dem Management-System im Cluster (pacemaker), und die moderne Variante des Kommunikationsdiensts zwischen den Knoten (corosync) kommt zu großen Teilen ebenfalls aus dem Hause Red Hat. Der Chef des Projekts arbeitet für SUSE. Natürlich gibt es außerdem noch viele Freiwillige, die den einen oder anderen Teil zum Erfolg des Projekts beitragen. Hier sei besonders die Firma LINBIT (Hersteller von DRBD) erwähnt, bei der viele Helfer arbeiten.

Mit dieser Architektur kann der Cluster eine hohe Verfügbarkeit der Applikationen gewährleisten, wenn der Cluster selbst ohne Fehler konfiguriert wurde. Wie der Administrator das bewerkstelligt, wird im Folgenden gezeigt.

[1] 365 Tage/Jahr + 0,25 Tage/Jahr (Schaltjahre) – 0,01 (Jahre, die glatt durch 100 teilbar sind, sind keine Schaltjahre) + 0,0025 Tage/Jahr (durch 400 teilbare Jahre sind Schaltjahre)

[2] www.linuxvirtualserver.org

[3] www.linux-ha.org

[4] http://horms.net/projects/redundant_content/related/linux-ha/High-Availability-HOWTO.html

Kapitel 2. Grundlagen

Was ist ein Cluster? Wie funktioniert ein Cluster in der Praxis? Welche Probleme kann ich damit lösen, und wo sind die verborgenen Fallstricke, die man unbedingt vermeiden muss, damit das Gesamtsystem auch in kritischen Situationen noch wie erwartet funktioniert? Wie die Linux-Clustersoftware diese Fragen angeht, soll in diesem Kapitel ebenso erklärt werden wie die Veränderungen, die Linux-HA bzw. die Nachfolgeprojekte in den letzten Jahren erfahren haben. Im letzten Teil wird noch auf die innere Architektur der Clustersoftware eingegangen.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!