Verfügbarkeit von IT-Systemen berechnen

Wie wird die Verfügbarkeit eines IT Systems berechnet? Bei Adacor erhalten wir häufig Anfragen mit der Aussage “Wir hätten gerne einen Server mit einer Verfügbarkeit von 99,9 Prozent.” Doch was bedeutet 99,99 % Verfügbarkeit? Dieser Artikel gibt Ihnen Antwort auf die Frage und zeigt, wie Sie Ihre Verfügbarkeit ganz leicht berechnen können.

Wer eine derart hohe Verfügbarkeit in ein Angebot aufnimmt und unterstellt, dass es pro Jahr gemeint ist und sich ausschließlich auf den Server bezieht, der vergisst, dass dem Kunden wahrscheinlich nicht klar ist, dass der Server durchaus einen ganzen Tag am Stück ausfallen kann und die Verfügbarkeit trotzdem eingehalten wird. Oder, dass die Verfügbarkeit des Servers nicht berührt ist, wenn die Firewall oder die Netzanbindung weg ist, der Server noch läuft, aber von außen nicht mehr erreichbar ist. Das ist ein wichtiger Aspekt bei der Bewertung von Angeboten für Managed Hosting und Cloud Hosting.

Tabelle mit Ausfallzeiten und Systemverfügbarkeiten

Eine gute Übersicht über die prozentuale Systemverfügbarkeit in der Praxis zeigt die folgende Tabelle mit auf das Jahr gerechneten möglichen Ausfallzeiten:

Verfügbarkeit Prozentual	Minimale erwartete Verfügbarkeit (Stunden)	Maximale erlaubte Ausfallzeit (Stunden)
95 %	8394	366
98 %	8584,8	175,2
99 %	8672,4	87,6
99,5 %	8716,2	43,8
99,6 %	8724,96	35,04
99,7 %	8733,72	26,28
99,8 %	8742,48	17,52
99,9 %	8751,24	8,76
99,95 %	8755,62	4,38
99,99 %	8759,124	0,876

Alternativ kann die Verfügbarkeit bei kritischen Projekten auf den Monat bezogen angegeben werden. Zum Beispiel bedeuten 99,9 Prozent Verfügbarkeit auf den Monat gerechnet einen Maximalausfall von 43:48 Minuten/Monat.

Wenn man die Verfügbarkeit eines Services prozentual ausdrückt, muss man sich überlegen, ob man mit der maximal möglichen Ausfallzeit leben kann. Eine weitere Variante ist die zusätzliche Beschränkung der maximalen Ausfalldauer. Gerade bei nicht so kritischen Projekten kann es sein, dass zwei oder drei Ausfälle pro Jahr nicht ins Gewicht fallen. Sie sollten jedoch nicht länger als vier Stunden am Stück dauern. Also definiere ich z. B. 99,5 Prozent Verfügbarkeit pro Jahr, bei maximal vier Stunden Ausfall am Stück.

Worauf bezieht sich die Verfügbarkeit konkret?

Eine weitere Quelle von Missverständnissen ist die Definition des Services. Nehmen wir an, einem Kunden wird die Verfügbarkeit eines Servers garantiert und er lässt von einer Webagentur eine Website auf diesem Server betreiben. Aus der Sicht des Betreibers ist der Server solange verfügbar, wie er einwandfrei läuft. Das kann sogar der Fall sein, wenn der Webserver aus irgendeinem Grund kein http mehr ausliefert. Sprich, die Website nicht mehr erreichbar ist.

Aus Kundensicht ist der Server dann aber nicht mehr verfügbar, weil die Website weg ist. Da eine Agentur die Website betreibt und für die Konfiguration zuständig ist, kann der Hoster keine Verfügbarkeit oberhalb des reinen Betriebssystems garantieren. Als Webagentur oder Softwaredienstleister, die als Generalunternehmer gegenüber dem Kunden auftreten, ist zu beachten, dass die SLAs des Hosters nicht einfach an den Kunden für das Gesamtsystem weitergegeben werden können. Die Ausfallrisiken auf Applikationsebene müssen ebenfalls bestimmt werden und zu den Ausfallrisiken von Seiten des Hosters hinzugerechnet werden.

Dieses Beispiel zeigt, dass es wichtig ist, sich genau darüber zu verständigen, worauf sich die Verfügbarkeit bezieht. Aus Kundensicht ist es am sinnvollsten, wenn die Verfügbarkeit des kompletten Dienstes vereinbart wird, der betrieben werden soll. Dies ist bei etwas komplexeren Projekten allerdings nicht mehr so einfach. Häufig wird dann ein Kompromiss geschlossen und der Dienstleister garantiert die Verfügbarkeit des gesamten Projektes, so wie der Kunde es möchte. Aber eigentlich weiß zu diesem Zeitpunkt niemand wie hoch die Verfügbarkeit wirklich ist.

Einflüsse bei der Verknüpfung von Verfügbarkeiten

Wenn wir über die Verfügbarkeit eines kompletten Dienstes reden, müssen wir uns Gedanken über die Verknüpfung und den Abhängigkeiten von verschiedenen Verfügbarkeiten machen. Ein kompletter Dienst setzt sich meistens aus mehreren Services zusammen. Ein einfaches Beispiel ist unsere hochverfügbare VMware-Umgebung für die Cloud-Lösung. Durch die Möglichkeiten, welche die VMware in verteilten Umgebungen bietet, haben wir bei den einzelnen virtuellen Servern eine sehr hohe Verfügbarkeit in Höhe von etwa 99,99 Prozent auf das Jahr gesehen. Dabei ist zu beachten, dass bei der Miete einer nackten VMware-Resource weitere Einflüsse auf die Verfügbarkeit der auf der VM laufenden Projekte bestehen.

1. Die Verfügbarkeit bezieht sich nur auf die virtuelle Hardware. Bei einem Ausfall eines VMware-Knotens ist die virtuelle Hardware durch die Redundanzen und der Failover-Technologien innerhalb weniger Minuten wieder verfügbar. Nun booten die Server bei einem Failover einmal neu. Je nach Installation kann das einige Zeit dauern, bis alle Dienste wieder verfügbar sind. Dies ist nicht in der Verfügbarkeit der VM abgebildet.
2. Die Verfügbarkeit der Applikationen auf dem virtuellen Server hängt nicht nur von der virtuellen Hardware, sondern auch von der Verfügbarkeit des internen und externen Netzes ab.

In unserem Beispiel sind beide mit ebenfalls 99,99 Prozent sehr hoch verfügbar. Die für den Kunden letztendlich absolute Verfügbarkeit von Applikationen kann maximal nur bei 99,97 Prozent liegen.

Bei der Verknüpfung von Verfügbarkeiten reden wir von einer Addition des Ausfallrisikos. Bei einer Verfügbarkeit von 99,99 Prozent liegt diese bei 0,01 Prozent. Haben wir drei Services, die für die Gesamtverfügbarkeit verfügbar sein müssen, gibt es ein Ausfallrisiko von drei mal 0,01 Prozent, gleich 0,03 Prozent. Daraus ergibt eine Gesamtverfügbarkeit von 100 minus – 0,03 Prozent, gleich 99,97 Prozent.

Wenn in unserem Beispiel noch Risiken aus den betriebenen Applikationen hinzukommen, wird die realistische Verfügbarkeit einer Applikation, auch unter optimalen Bedingungen, nicht über 99,95 Prozent liegen.

Redundanzen erhöhen die Verfügbarkeit

Im umgekehrten Fall erhöhen wir die Verfügbarkeit über Redundanzen. Das funktioniert rechnerisch so: Habe ich zwei Systeme, die das gleiche leisten, 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 zur gleichen Zeit ausfällt wie die erste Ressource. Daher ergibt sich die hohe Verfügbarkeit von 99,9996 Prozent.

Die Tücke liegt in der praktischen Umsetzung. Wenn wir in diesem Beispiel über Dateien reden, die in zwei unterschiedlichen Rechenzentren liegen (z. B. 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 passiert in der Praxis allerdings selten.

Ein typischer Einsatz von Redundanzen ist ein Datenbank-Cluster. Um die Verfügbarkeit eines Datenbankservers zu erhöhen, wird ein zweiter Server daneben gestellt. Wir gehen von einer einfachen Aktiv-/Passiv-Lösung aus. Wenn der aktive Datenbankserver ausfällt, übernimmt der Passive und wird zum Aktiven. Damit das Konstrukt funktionieren kann, müssen die Daten kontinuierlich synchronisiert werden. Dieser Prozess ist selbst eine Fehlerquelle und bringt eine zusätzliche Ausfallwahrscheinlichkeit für das System mit. 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, dass die Bestimmung der wirklichen Verfügbarkeit der redundanten Lösung alles andere als trivial ist.

Im nächsten Schritt kann man sagen, dass wir den zweiten Server in ein anderes Rechenzentrum packen. Dann haben wir eine viel höhere Verfügbarkeit, weil die gemeinsamen Risiken 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. Kommt es zu kleinen Problemen, weil die Verbindung abbricht oder die Latenzen zu groß sind, hat das massive Auswirkungen auf die Verfügbarkeit der Lösung.

Video zur Berechnung der Verfügbarkeit von IT-Systemen

In der Episode #7 meiner Videoreihe „Things To Say“ erkläre ich, wie genau man die Verfügbarkeiten von IT-Systemen berechnet:

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 viel länger dauern als bei einfachen Architekturen. Das kann zu längeren Ausfällen und einer schlechteren Verfügbarkeit führen – selbst bei einer redundant ausgelegten Lösung.

SLA und Verfügbarkeit

In der Praxis werden im Rahmen von SLAs oft Aussagen zu Verfügbarkeiten gemacht, die technisch nicht verifiziert sind. Sie gelten in der Praxis nur so lange wie alles rund läuft und sie sind nicht an Worst-Case-Szenarien ausgerichtet. Der Kunde muss genau hinterfragen, unter welchen Bedingungen die Verfügbarkeit gilt und welche Risiken berücksichtigt werden. Katastrophenszenarien werden häufig nicht berücksichtigt. Sollte ein Flugzeug auf das Rechenzentrum stürzen, hat man keine 99,9 Prozent Verfügbarkeit mehr, sondern gegebenenfalls für lange Zeit einen hundertprozentigen Ausfall. Zugegeben, dass passiert so gut wie, genauso wie starke Erdbeben in Deutschland oder Terrorangriffe. Aber man muss im Hinterkopf haben, dass solche Totalausfallrisiken nicht abgedeckt sind. Es sei denn, der Anbieter betreibt das Projekt verteilt an zwei Standorten, was standardmäßig aus Kostengründen nicht gemacht wird.

Auswirkungen von rein kaufmännischen SLA

Häufig werden SLAs 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.

In Episode #6 der Videoreihe „Things To Say“ lege ich die Unterschiede zwischen kaufmännischen und technisch belastbaren SLA dar:

Mehr darüber erfahren Sie in einem weiteren Blogartikel von mir.

Whitepaper SLA downloaden

Das zum Thema Service-Level-Agreements und Verfügbarkeit passende Whitepaper erhalten Sie hier zum kostenlosen Download.

Welche Erfahrungen haben Sie bei der Angabe von Verfügbarkeiten in SLAs und Angeboten gemacht?
Wie können wir Ihnen helfen? Kontaktdaten finden Sie hier oder senden Sie mir persönlich eine Mailnachricht.

Dieser Beitrag erschien als Gastbeitrag in folgenden Fachmagazinen: ChannelPartner, CIO, TechChannel, Computerwoche.