Computer sind fehleranfällig – eine Binsenweisheit, die schon so manchem Admin schlaflose Nächte bereitet hat. Die Antwort heißt Hochverfügbarkeit. Das ist kein Produkt, sondern vielmehr ein Konzept aus verschiedenen Komponenten. Eine häufige Ausprägung dieses Konzepts ist der sogenannte HochverfügbarkeitsCluster. Er beruht auf dem simplen Prinzip, dass ein zweiter Rechner die Aufgaben eines ausgefallenen Systems übernimmt. Dieser Prozess heißt Failover.
Damit der Failover funktionieren kann, müssen einige Bedingungen erfüllt sein. Allen voran steht die doppelte Transparenz: Der Failover muss sowohl für den Client wie auch für die betroffene Applikation transparent sein. Damit nach der Verlagerung von Diensten auf ein anderes, noch funktionierendes System nicht die IP-Adressen geändert werden müssen, unter denen die Clients die umgezogenen Dienste erreichen, gehört zu einem Failover-Setup typischerweise eine IP-Adresse, die fest mit einem Dienst statt mit einem spezifischen Server verbunden ist. Aber auch die Netzwerkprotokolle müssen mitspielen. Stateless-Protokolle wie HTTP funktionieren perfekt, denn ob eine Antwort auf einen Request von einem oder dem anderen Server zum Client wandert, ist einerlei. Stateful-Protokolle – oft geht es dabei um Datenbanken – müssen sich selbst darum kümmern, dass ihre Clients im Anschluss an einen Failover die Verbindung zu ihrem Dienst wiederherstellen. Sämtliche gängigen Datenbank-Clients haben aber entsprechende Funktionen.
Transparent ist ein Failover für eine Applikation vor allem dann, wenn es für sie keinen Unterschied macht, auf welchem Rechner eines Hochverfügbarkeitsclusters sie läuft. Idealerweise sind auf allen Servern die gleichen Versionen der Applikation vorhanden, außerdem müssen sämtliche wichtigen Konfigurationsdateien identisch sein. Der wichtigste Faktor sind aber die Daten, die die Applikation verwendet. Niemandem wäre geholfen, würde die Applikation auf dem überlebenden Knoten nicht mit denselben Daten weiterarbeiten können, die vorher der ausgefallenen Instanz zur Verfügung standen.
Die klassische Lösung für dieses Problem sind SANs. Hauptbestandteil eines SAN ist im einfachsten Fall ein einzelner Computer mit vielen Festplatten und einem speziellen Storage-Controller, der seine Daten den Clients im angrenzenden Netz direkt zur Verfügung stellt – beispielsweise mittels iSCSI oder NFS. Typische SANs sind aber auch Single Points of Failure, weil die Daten verloren sind, sollte das komplette System trotz interner Redundanz abgeschaltet werden müssen oder ein Concurrent Write stattfinden – also gleichzeitiger, unkoordinierter Schreibzugriff von zwei Seiten. Beides ist zwar nicht hochwahrscheinlich, aber auch nicht ausgeschlossen. Beispielsweise kann ein Brand im Rechenzentrum dazu zwingen, die Stromversorgung komplett zu unterbrechen.