Redundanzen erhöhen die Verfügbarkeit
Im umgekehrten Falle erhöht sich die Verfügbarkeit über Redundanzen. Das funktioniert rechnerisch so: Existieren zwei Systeme, die das Gleiche leisten, jeweils eine Verfügbarkeit von 98 Prozent haben und sich sofort voll ersetzen können, multiplizieren sich die Ausfallrisiken miteinander: 0,02 x 0,02. Denn es kommt nur dann zu einem kompletten Ausfall, wenn die zweite Ressource zur gleichen Zeit ausfällt wie die erste Ressource. Daraus ergibt sich die hohe Verfügbarkeit von 99,9996 Prozent.
Die Tücke liegt jetzt in der praktischen Umsetzung. Wenn wir in diesem Beispiel über Dateien reden, die in zwei unterschiedlichen Rechenzentren liegen (zum Beispiel Sicherheitskopien), diese nicht abgeglichen oder verändert werden müssen und der Zugriff völlig unabhängig erfolgen kann, dann hat man eine Verfügbarkeit von 99,9996 Prozent auf diese Daten. Das kommt in der Praxis allerdings sehr selten vor.
Ein typischer Einsatz von Redundanzen ist beispielsweise ein Datenbank-Cluster. Um die Verfügbarkeit eines Datenbankservers zu erhöhen, wird ein zweiter Server danebengestellt. Gehen wir hier von einer einfachen Aktiv/Passiv-Lösung aus. Wenn der aktive Datenbankserver (DB-Server) ausfällt, übernimmt der passive und wird so zum aktiven DB-Server. Damit das Konstrukt funktionieren kann, müssen die Daten kontinuierlich synchronisiert werden.
Dieser Prozess ist nun aber selber eine Fehlerquelle und bringt eine zusätzliche Ausfallwahrscheinlichkeit für das System mit sich. Außerdem benötigt man einen Failover-Mechanismus, der den Übergang von dem einen auf den anderen Server regelt. Auch dieser hat wieder eine Ausfallwahrscheinlichkeit. Dazu kommen Ausfallrisiken, die von den gemeinsamen Umgebung geprägt sind, beispielsweise Stromversorgung, internes und externes Netz oder Klima. Man sieht hier, dass die Bestimmung der wirklichen Verfügbarkeit der redundanten Lösung alles andere als trivial ist.
Im nächsten Schritt könnte man nun sagen: Wir packen den zweiten Server in ein anderes Rechenzentrum und haben damit eine viel höhere Verfügbarkeit, weil die gemeinsamen Risiken dann entfallen. Das ist grundsätzlich richtig, aber die Synchronisation der Daten wird erheblich schwieriger, da es zwischen den beiden Rechenzentren zu Latenzen kommt. Außerdem muss die Verbindung zwischen den beiden Rechenzentren absolut stabil sein. Tauchen jetzt kleine Problemen auf, weil die Verbindung abbricht oder die Latenzen zu groß sind, hat das wieder massive Auswirkungen auf die Verfügbarkeit der Lösung.
Gerade bei großen Datenbank-Clustern, die als zentrale Lösung für Unternehmensdatenbanken dienen, kann es sein, dass die höhere Verfügbarkeit mittels Redundanzen durch eine deutlich höhere Komplexität der Gesamtarchitektur und den dadurch entstehenden Fehlern konterkariert wird. Im Problemfall kann die Fehlersuche bei einer großen und komplexen zentralen Lösung sehr viel länger dauern als bei einfachen Architekturen. Das kann zu längeren Ausfällen und somit zu einer schlechteren Verfügbarkeit führen, auch wenn die Lösung redundant ausgelegt ist.
Umgang mit SLAs
In der Praxis werden häufig im Rahmen von Service Level Agreements (SLA) Aussagen zu Verfügbarkeiten gemacht, die technisch nicht verifiziert sind. Die gelten in der Praxis dann nur so lange, wie alles rundläuft, und sind nicht an Worst-Case-Szenarien ausgerichtet. Sowohl Kunden als auch Provider müssen also sehr genau hinterfragen, unter welchen Bedingungen die Verfügbarkeit gilt und welche Risiken berücksichtigt werden.
Katastrophenszenarien werden häufig nicht mit berücksichtigt. Sollte ein Flugzeug auf das Rechenzentrum stürzen, hat man keine 99,9 Prozent Verfügbarkeit mehr, sondern eher für lange Zeit einen 100-prozentigen Ausfall. Zugegeben, das passiert auch selten, genauso wie starke Erdbeben in Deutschland oder Terrorangriffe. Aber man sollte im Hinterkopf behalten, dass solche Totalausfallrisiken nicht abgedeckt sind. Es sei denn, der Anbieter betreibt das Projekt komplett verteilt an zwei Standorten, was in der Regel im Standard aus Kostengründen nicht gemacht wird.
Häufig werden SLAs auch einfach aus einer kaufmännischen Überlegung heraus definiert, und der Anbieter lebt damit, dass bei jedem x-ten Kunden die SLAs nicht eingehalten werden können. Solange keine empfindlichen Vertragsstrafen vereinbart sind, ist das meistens kein großes Problem für den Anbieter. Insofern ist immer zu hinterfragen, wie belastbar die SLAs in der Praxis sind. (hal)