Ratgeber für Cloud- und Hosting-Projekte

Fallstricke bei der Berechnung von Verfügbarkeiten

12.09.2013

Redundanzen erhöhen die Verfügbarkeit

Im umgekehrten Falle erhöhen wir die Verfügbarkeit über Redundanzen. Das funktioniert rechnerisch so: Habe ich zwei Systeme, die das gleiche leisten und jeweils eine Verfügbarkeit von 98 Prozent haben und sich sofort voll ersetzen können, multipliziere ich die Ausfallrisiken miteinander 0,02 x 0,02. Denn es kommt nur zu einem kompletten Ausfall, wenn die zweite Ressource ebenfalls zur gleichen Zeit wie die erste Ressource ausfällt. Daher 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) und 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 passiert in der Praxis allerdings sehr selten.

Ein typischer Einsatz von Redundanzen ist beispielsweise ein Datenbank-Cluster. Um die Verfügbarkeit eines Datenbankservers zu erhöhen, wird ein zweiter Server daneben gestellt. Gehen wir hier von einer einfachen Aktiv/Passiv-Lösung aus.

Wenn der aktive Datenbank-Server (DB-Server) ausfällt, übernimmt der passive und wird 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 noch Ausfallrisiken, die durch die gemeinsame Umgebung geprägt sind: Stromversorgung, internes und externes Netz, Klima, usw.

Man sieht hier, dass die Bestimmung der wirklichen Verfügbarkeit der redundanten Lösung alles andere als trivial ist.

Im nächsten Schritt kann man dann 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.

Dies 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. Kommt es jetzt zu kleinen Problemen, 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 SLAs Aussagen zu Verfügbarkeiten gemacht, die technisch nicht verifiziert sind. Die gelten in der Praxis dann nur solange wie alles rund lä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.

Katastrophen-Szenarien 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. (rb)
*) Thomas Wittbecker ist CEO von Adacor Hosting

Zur Startseite