Wenn in einer IT-Infrastruktur einer der zentralen Server ausfällt, kommt ziemlich schnell Panik auf. Die Reparatur erfolgt unter dem Druck der Nichtverfügbarkeit des dort laufenden Dienstes wie zum Beispiel eines Apache-Webservers, d.h. unter Zeitdruck. Das ist keine gute Voraussetzung für ein besonnenes Arbeiten, wie es sich der Administrator eigentlich wünscht. Wenn man anstelle eines Einzelservers zwei Rechner aufgebaut hat, die sich gegenseitig überwachen, kann schon eher einer kaputt gehen: Der andere Server springt ein, die Benutzer können den Dienst weiter in Anspruch nehmen und der Administrator kann in Ruhe den Fehler gründlich untersuchen und beheben. Dieser Artikel von unserem Autor Michael Schwartzkopff soll kurz die einschlägigen Begriffe aus dem Bereich der Hochverfügbarkeit zusammenfassen und die üblichen Konzepte für Server-Cluster vorstellen.
MBTF, MTTR, AFR und so weiter – die wichtigsten Begriffe
Damit ein Benutzer einen Dienst nutzen kann, müssen viele Komponenten zusammenspielen. Ein Server benötigt Strom und einen Netzwerkanschluss, die Datenpakete werden von Routern und Switches transportiert, und die Server- und Client-Applikation müssen funktionieren. Der Server selbst besteht wiederum aus Einzelteilen wie Netzteil, Festplatte, CPU und RAM. Alle Komponenten müssen einwandfrei arbeiten, damit das Datenpaket richtig erzeugt, transportiert und interpretiert wird. Fällt nur eine der Komponenten aus, ist es auch nichts mehr mit der Nutzung des Dienstes.
Jede Komponente weist eine durchschnittliche Wahrscheinlichkeit auf, dass sie in einem bestimmten Zeitintervall ausfällt. In Datenblättern findet man häufig die Annual Failure Rate (AFR), die angibt, wie wahrscheinlich ein Ausfall der Komponente in einem Jahr Betrieb ist. Wenn die Komponente für einen Dauerbetrieb ausgelegt ist kann man die AFR einfach in eine andere Kenngröße umrechnen: Die mittlere Zeit, bis die Komponente ausfällt (Mean Time Before Failure, MTBF), beträgt (8766 Stunden/Jahr) / AFR. Für eine Festplatte mit einer AFR von 0.34% berechnet sich also die mittlere Lebenserwartung zu knapp 2,6*106 Stunden. Natürlich gelten die Angaben der Hersteller immer nur im Garantiezeitraum. Danach steigen die Fehlerzahlen meist drastisch an. ;-)
Für den Kunden ist eine weitere Kennzahl aber noch wichtiger: Wie lange dauert es (im Mittel), bis er seinen Dienst wieder nutzen kann? Diese Kennzahl Mean Time To Repair (MTTR) gibt an, wie lange es von der Entdeckung eines Fehlers bis zum Wiederanlaufen des Dienstes dauert. Diese Zeit hängt bei Softwarefehlern (z.B. Programmabsturz) stark davon ab, ob es einen Automatismus für die Entdeckung und die Behebung von Fehlern gibt. Am längsten und unangenehmsten ist es, wenn erst der Kunde den Fehler entdeckt und diesen bei der Hotline meldet. Am besten ist es, ein automatisches Überwachungssystem entdeckt das Problem und löst es automatisch, zum Beispiel durch Neustart des Dienstes. Für Hardwarefehler hängt die MTTR hauptsächlich davon ab, wie schnell ein Ersatzteil verfügbar ist und eingebaut werden kann.
Die Verfügbarkeit (engl. Availability) A lässt sich aus den beiden Kennzahlen oben einfach berechnen: A=MTBF/(MTBF+MTTR), also das Verhältnis der Zeit, in der der Dienst verfügbar ist, zur gesamten Zeit.
Zusammengesetzte Systeme
Die Verfügbarkeit zusammengesetzter Systeme, deren Funktionieren von mehreren Einzelkomponenten abhängt, lässt sich einfach aus den einzelnen Verfügbarkeiten berechnen. Bei einer seriellen Kopplung von zwei Komponenten, also zum Beispiel Stromkabel und Netzteil, ist die Gesamtverfügbarkeit A=A1*A2. Die Mathematik zeigt, dass die Verfügbarkeit des Gesamtsystems stets niedriger sein wird als der Wert der schlechtesten Einzelkomponente. Eine Kette ist also immer nur so stark wie ihr schwächstes Glied.
Um die Verfügbarkeit eines Gesamtsystems zu verbessern, müssen anfällige Komponenten redundant, also mehrfach verbaut werden. Bei einer parallelen Kopplung, zum Beispiel von zwei Netzteilen, multiplizieren sich die Nichtverfügbarkeiten oder anders ausgedrückt: Die Gesamtverfügbarkeit A=1-(1-A1)*(1-A2) verbessert sich. Deshalb lautet die 3R-Regel für hochverfügbare Systeme:
Redundanz, Redundanz und noch einmal Redundanz.
Mechanik versus Elektronik
Jedes mechanische Bauteil unterliegt einem wesentlich stärkeren Verschleiß als elektronische Komponenten. So fallen zum Beispiel Lüfter und Festplatten meistens als erstes aus. Gerade der Ausfall einer Festplatte beendet den Computerspaß dann ziemlich schnell. Deshalb waren diese Komponenten auch eine der ersten, die redundant eingebunden wurden. Die Lösung heißt Redundant Array of Inexpensive Drives oder kurz RAID. Diese Technik ist heute aus keinem Betriebssystem oder Serveraufbau mehr wegzudenken.
Tauscht der Administrator eine ausgefallene Festplatte aus, muss er natürlich auch alle Daten rekonstruieren. Und diese Wiederherstellung der Daten dauert oft noch einmal ein Vielfaches der Zeit, die nötig ist, um einfach die Festplatte auszutauschen. Eine Ausfallzeit, die man sich in heutiger Zeit nicht leisten will und kann. Dem kann man mit Redundanz begegnen: Auch wenn eine einzelne Festplatte eine Verfügbarkeit von nur 98% hat, ist ein RAID1-System aus diesen Festplatten immerhin zu 99,96% verfügbar.
Elektronische Bauteile haben meist eine längere Lebensdauer. Doch wenn viele einzelne Komponenten zusammenspielen müssen, ist die Lebensdauer eines Server eben auch nicht unbegrenzt. Die Datenblätter einfacher Server geben eine MTBF von 50.000 Stunden an. Nicht gerade extrem zuverlässig, wenn man an den zentralen Mailserver der Firma denkt! Ein Stillstand solch zentraler Dienste kann pro Arbeitstag schnell einen Schaden von 100.000 EUR oder mehr verursachen. Deshalb gehen die Überlegungen schon seit längerem dahin, diese Dienste auf sogenannten Clustern laufen zu lassen.
Cluster für Hochverfügbarkeit
Anstatt einzelne Komponenten eines Computers redundant vorzuhalten, werden in einem Cluster zwei oder mehr komplette Rechner zusammengefasst. Eine Clustersoftware überwacht dauernd die Funktion der Rechner und verteilt die Dienste nach den Wünschen des Administrators auf die verschiedenen Rechner. Die Rechner werden in diesem Zusammenhang auch Knoten genannt. Alle Dienste, die der Cluster anbietet und die die Clustersoftware verwaltet, heißen dann auch Ressourcen.
Das Buch „Clusterbau: Hochverfügbarkeit mit pacemaker, OpenAIS, heartbeat und LVS“ beschreibt die Grundlagen der Architektur solcher Clustersysteme unter Linux, erklärt die Komponenten der Software und bietet vor allem eine Fülle von Beispielen. Jeder Planer, Architekt oder Administrator, der hochverfügbare Linux-Cluster betreibt, sollte dieses Standardwerk zur Hand haben.
Dr. Michael Schwartzkopff wuchs in München auf und hat dort auch seine Ausbildung bis zur Promotion in Physik an der TU München absolviert. Das Interesse für Computer wurde schon früh mit einem Commodore 3032 geweckt und hielt über den ersten eigenen Apple ][ bis zum jetzigen Tag an. Mit dem Linux-Virus wurde er als Administrator in der Universität 1994 infiziert. Nach einem kurzen beruflichen Intermezzo im Kaukasus machte er sein Hobby zum Beruf und arbeitet nun als Berater bei der Firma MultiNET Services GmbH zu allen Themen rund um Linux, IT-Sicherheit und Netzwerk-Management.