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 A_ser des Gesamtsystems berechnet sich aus der jeweiligen Verfügbarkeit der einzelnen Komponenten wie folgt:

A_ser = 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 A_ser = 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.

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 A_par des Gesamtsystems berechnet sich in diesem Fall aus der jeweiligen Verfügbarkeit der einzelnen Komponenten wie folgt:

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

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

A_par = 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.

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

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

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.

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:

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:

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.

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).

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

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 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.

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).

Tabelle 1.7

netfilter

netfilter