Eine wirksame Hochverfügbarkeitslösung muss mit dem gesamten IT-System eng verzahnt sein. Es ist daher unerlässlich, so früh wie möglich eine Strategie zur Steigerung der Zuverlässigkeit zu wählen. Werden fehlertolerante Aspekte zu spät berücksichtigt, kann sich im schlimmsten Fall herausstellen, dass der erwünschte Grad an Zuverlässigkeit mit der existierenden Architektur nicht erreichbar ist. Dann ist ein Überarbeiten des gesamten Systemdesigns unvermeidlich.

Der erste Schritt für eine wirkungsvolle Lösung ist das Erfassen der Anforderungen. In bestimmten Bereichen sind diese von Regulierungsbehörden vorgegeben, die im Allgemeinen präzise formulieren. Die zweite Klasse von Anforderungen wird von ökonomischen Sachverhalten abgeleitet. Ausfallzeiten werden Kosten zugeordnet: Sie beinhalten die unmittelbaren Kosten des Ausfalls, den entgangenen Gewinn von Geschäften, die während der Ausfallzeit nicht getätigt werden konnten, sowie Imageverlust. Die dritte Kategorie bilden die von Kunden gestellten Anforderungen, die üblicherweise nicht präzise formuliert sind. Kunden verlangen, dass ein System so zuverlässig arbeitet wie möglich. Marktstudien können helfen, einen Preis für diese Anforderung zu ermitteln.

Kosten steigen exponentiell

Hochverfügbarkeit ist teuer. Die Kosten dafür steigen exponentiell mit der benötigten Betriebssicherheit. Die Steigerung der Betriebslaufzeit von 99,99 Prozent (Ausfallzeit von 53 Minuten pro Jahr) auf 99,999 Prozent (Ausfallzeit von 5,3 Minuten pro Jahr) ist oft ein Vielfaches teurer als die Steigerung der Rate von 99,9 (8,8 Stunden pro Jahr) auf 99,99 Prozent, obwohl letztere Maßnahme die Ausfallzeit um fast acht Stunden reduziert, während die erstere Reduzierung nur 47 Minuten beträgt. Nicht alles, was technisch machbar ist, ist aus betriebswirtschaftlicher Sicht erstrebenswert. Die Verfügbarkeitsanforderungen müssen zwischen technischen, marktwirtschaftlichen und betriebswirtschaftlichen Gesichtspunkten abgestimmt sein.

Sobald die allgemeinen Anforderungen definiert sind, müssen alle möglichen Fehlerursachen identifiziert werden. Für jede dieser Ursachen muss die Eintrittswahrscheinlichkeit ermittelt oder abgeschätzt werden. Anhaltspunkte hier sind Erfahrungswerte mit den existierenden Systemen, eine andere Möglichkeit besteht in Messungen. Von Zulieferern mitgeteilte Werte sollten nur dann übernommen werden, wenn sie von zuverlässigen Herstellern stammen.

Der Entwickler muss nun entscheiden, wie das System auf jeden möglichen Fehler reagieren soll. Welche Fehler müssen vom System toleriert werden können, unter welchen Umständen darf das System ausfallen - das sind die wichtigen Fragen. Die Suche nach möglichen Fehlerursachen muss sehr sorgfältig geschehen. Denn der Ausfall eines hochverfügbaren Systems ist oft auf eine Fehlerquelle zurückzuführen, die in der Fehlerspezifikation nicht berücksichtigt wurde.

Fehler treten meist in Gruppen auf:

- Eine defekte Klimaanlage führt zur Überhitzung mehrerer CPUs.

- Eine Spannungsspitze im Netz beschädigt mehrere Computer.

- Spitzenlast führt zum Ausfall einer Softwarekomponente.

- Durch den Ausfall einer Komponente steigt die Last im Rest des Systems an, was zu einer Kettenreaktion von weiteren Ausfällen führt.

Man sollte deshalb, wann immer möglich, auf vorgefertigte Module zurückgreifen, die die Implementierung eines zuverlässigen Systems erleichtern. Beispiele für solche Module sind Fehlerdetektoren (Failure Detectors), zuverlässige Datenübertragungprotokolle (Reliable Communication Protocols), Alarm- und Ereignismelder (Alarm and Event Notification) sowie Group-Communication-Systeme.

Fehlerdetektoren überwachen alle Komponenten eines Systems. Der Detektor bemerkt den Eintritt eines Fehlers, prüft das System und identifiziert die schadhafte Komponente. Es ist mathematisch beweisbar, dass es unmöglich ist, einen perfekten Fehlerdetektor für ein verteiltes Computersystem zu konstruieren. Der Benutzer muss einen Kompromiss wählen zwischen Geschwindigkeit und Korrektheit. Je schneller der Detektor reagiert, desto unzuverlässiger ist seine Diagnose. Außerdem lassen sich bestimmte Fehler nicht eindeutig diagnostizieren: Ob ein per Netz angebundener Computer ausfällt oder die Netzverbindung unterbrochen ist, lässt sich aus der Ferne nicht unterscheiden. Auch aus Sicht des Systems macht dies keinen Unterschied. Es zählt die Tatsache, dass der fragliche Computer nicht mehr reagiert und die ihm zugewiesene Aufgabe nicht erfüllen kann. Trotz aller Einschränkungen sind Fehlerdetektoren nützliche Werkzeuge, die das Design von hochverfügbaren Systemen erheblich vereinfachen.

Prozesse laufen synchron

Group-Communication-Systeme erlauben es, Objekte auf einfache Art und Weise auf mehreren Computern zu replizieren. Ein Group-Communication-System ersetzt dabei die gewöhnliche Datenübertragung mit einem Multicast, der alle Daten zu allen Mitgliedern einer Gruppe von Computern schickt. Die Datenpakete werden bei allen Teilnehmern zuverlässig und in der gleichen Reihenfolge ausgeliefert. Wenn ein Computer zu der Gruppe hinzukommt oder aus ihr herausgenommen wird, werden die Mitglieder informiert. Somit laufen sämtliche Prozesse quasi synchron (virtual synchrony). Diese Synchronisation erlaubt die Konstruktion von replizierten Datenbanken ohne zusätzliche Synchronisierungsmechanismen.

Moderne Standardsoftware verwendet oft eigene Mechanismen zur Behandlung von Fehlern. Datenbanken zum Beispiel verfügen über eingebaute Failover-Funktionen, die im Fehlerfall von der primären Datenbank auf ein sekundäres System umschalten. In den meisten Fällen sind diese Mechanismen von außen nicht zugänglich, und es ist schwierig, sie in das fehlertolerante Gesamtkonzept eines Systems zu integrieren.

Es liegt in der Natur der meisten Fehler, dass sie nur sporadisch auftreten. Dies stellt eine Herausforderung an die Testbarkeit der gewählten Lösung dar. Fehler-Injektion ist ein nützliches Werkzeug zur Erzeugung von Fehlern. Ein derartiger Generator erlaubt es, den Zustand des Systems bei Eintreffen bestimmter Ereignisse oder zu festgelegten Zeiten zu ändern. Diese Änderungen können genau definiert werden und ermöglichen es, ein bestimmtes Experiment beliebig oft zu wiederholen. Der Fehlergenerator muss in der Lage sein, den Verlust von Daten zu emulieren, die über eine Netzwerkverbindung ausgetauscht werden. Er muss in den gesamten Code des Systems eingebettet werden.

Ein effektiver Fehlergenerator sollte außerdem die Fähigkeit besitzen, mehrere Fehler in zuvor festgelegter Reihenfolge zu erzeugen. Dabei kann der Entwickler auf eine Reihe von kommerziellen und quelloffenen Produkten zurückgreifen (siehe Kasten "Fehlergeneratoren: eine Auswahl").

Da die Erzeugung geeigneter Fehler von Projekt zu Projekt verschieden ist, kommt der Entwickler in den meisten Fällen jedoch nicht umhin, zusätzliche Fehlergeneratorfunktionalität selbst zu implementieren. Zudem sollte der Generator so früh wie möglich in die Planung einbezogen werden, im Idealfall bereits in das Designdokument der Hochverfügbarkeitslösung.

Mit Hilfe des Fehlergenerators sollte das System jenseits seiner Spezifikationen betrieben werden, denn hier wird es aller Wahrscheinlichkeit nach zum Ausfall des gesamten Systems kommen. Der Entwickler kann die Reaktionen beobachten:

- Wird das System kontrolliert heruntergefahren?

- Kommt es zur Beschädigung wichtiger Daten?

- Kann der Schaden repariert werden?

- Kann die Reparatur automatisch erfolgen, oder muss Servicepersonal angefordert werden?

Eine hundertprozentige Ausfallsicherheit gibt es nicht. Kein System kann mit allen Fehlern fertig werden. Deshalb ist es wichtig, den Schaden einzugrenzen, der zu einem Systemausfall führt. Dann lässt sich die Zuverlässigkeit mit moderatem Aufwand erheblich steigern. (ue)