Fallstricke bei der Berechnung von IT-Verfügbarkeit

Während der Angebotsphase stellt sich bei Hosting-Projekten in kleinen und mittelständischen Unternehmen oft die Frage nach der Verfügbarkeit einzelner Services. Doch viele Verantwortliche haben nur eine vage Vorstellung von der Problematik der IT-Verfügbarkeit. Meistens wird die Verfügbarkeit eines Services mit einer Prozentzahl beschrieben. Dabei wird jedoch häufig außer Acht gelassen, dass bei der Berechnung dieser Prozentzahl, die dann in den Service Level Agreements (SLA) festgeschrieben wird, einige Fallstricke lauern.

Solche Fallstricke sind beispielsweise der Bezugspunkt der Berechnung der Ausfallzeiten (Jahr oder Monat), die Definition des zugrunde liegenden Services (Server, Firewall, Netzanbindung) oder die potenzielle Verknüpfung von Verfügbarkeiten. Wie lässt sich die Verfügbarkeit von IT-Plattformen sinnvoll berechnen?

Beispiel Server-Verfügbarkeit

Häufig bekommen IT-Anbieter Kundenanfragen mit der Aussage "Wir hätten gerne einen Server mit der Verfügbarkeit von 99,5 Prozent". In solchen Fällen wird diese Anforderung in ein Angebot aufgenommen; dabei wird unterstellt, dass sich die gewünschte Verfügbarkeit auf das Jahr und ausschließlich auf den Server bezieht.

Dem Kunden ist jetzt wahrscheinlich nicht klar, 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.

Möglichkeiten für die Berechnung der Ausfallzeiten

Eine gute Übersicht darüber, wie sich die prozentuale Verfügbarkeit eines Service in der Praxis auswirkt, erhält man mit einer Tabelle der auf das Jahr gerechneten möglichen Ausfallzeiten.

Berechnung der Ausfallzeiten

Verfügbarkeit Prozentual	Minimale erwartete Verfügbarkeit (Stunden)	Maximale erlaubte Ausfallzeit (Stunden)
99,0%	8672,40	87,60
99,1%	8681,16	78,84
99,2%	8689,92	70,08
99,3%	8698,68	61,32
99,4%	8707,44	52,56
99,5%	8716,20	43,80
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,99%	8759,124	0,876

Alternativ kann man die Verfügbarkeit bei kritischen Projekten auch auf den Monat bezogen angeben. So bedeutet zum Beispiel 99,9 Prozent Verfügbarkeit auf den Monat gerechnet einen Maximalausfall von 43:48 Minuten pro Monat. Wenn man über die Verfügbarkeit eines Services spricht und prozentual ausdrückt, muss man sich also überlegen, ob man mit der maximal möglichen Ausfallzeit leben kann.

Eine weitere Variante besteht darin, zusätzlich die maximale Ausfalldauer zu beschränken. Gerade bei nicht ganz 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 betragen. Also definiere ich beispielsweise 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 so lange verfügbar, wie er einwandfrei läuft. Das kann auch dann der Fall sein, wenn der Webserver aus irgendeinem Grund kein http mehr ausliefert, sprich, die Website nicht mehr erreichbar ist.

Checkliste Cloud-SLAs
Um zu beurteilen, ob ein Cloud-Provider kundenfreundliche SLAs anbietet, lassen sich folgende Kriterien anlegen und überprüfen:

Punkt 1:
Kurze und klare Gestaltung von Inhalt, Struktur und Formulierung.

Punkt 2:
Version in der Landessprache des Kunden.

Punkt 3:
Klare Definitionen von Fach- und Produktbegriffen zu Beginn.

Punkt 4:
Detaillierte Ankündigung und Planung der Wartungsfenster (Beispiel: "Viermal im Jahr an vorangemeldeten Wochenenden").

Punkt 5:
Leistungsbeschreibung in Tabellenform (Übersicht!).

Punkt 6:
Klar definierte Bereitstellungszeiträume für neue Ressourcen (Beispiele: Bereitstellung virtueller Server bei Managed Cloud in maximal vier Stunden; Bereitstellung kompletter Umgebungen oder dedizierter Server in fünf bis zehn Tagen).

Punkt 7:
Bereitstellung von klar abgegrenzten Konfigurationsoptionen für Ressourcen (Beispiel: Konfiguration von Servern nach Gigahertz, Gigabyte).

Punkt 8:
Einfach unterscheidbare Service-Levels (Beispiel: Silber, Gold, Platin); Abgrenzungskriterien können sein: Verfügbarkeit, Bereitstellungszeiten, fest reservierte Kapazitäten ja/nein, Support-Level (Telefon, E-Mail).

Punkt 9:
Bei IaaS-Angeboten unbedingt auf Netzwerk-Konfigurationsmöglichkeiten und Bandbreite achten (Volumen? Im Preis inkludiert ja/nein?).

Punkt 10:
Kundenfreundlicher Reporting- beziehungsweise Gutschriftenprozess (am besten aktive Gutschriften auf Kundenkonto; kein bürokratischer, schriftlicher Prozess; möglichst einfache Beweis- und Nachweispflicht für Kunden).

Punkt 11:
Reaktionszeiten und Serviceverfügbarkeit klar beschreiben (zentrale Hotline; Reaktionszeiten auf Incidents in Stunden).

Punkt 12:
Nennung der Rechenzentrumsstandorte mit Adresse und sonstigen Informationen wie Zertifizierungen und Tier.

Punkt 13:
Definition der Verfügbarkeiten: Unterschiede hinsichtlich Verfügbarkeit Server/VM und Verfügbarkeit Admin-Konsole definieren.

Punkt 14:
Erläuterung zu Möglichkeiten der SLA-Überwachung beziehungsweise des Incident-Reportings für den Anwender (Beispiel: Link auf Monitoring-Dashboard).

Wer haftet für die Verfügbarkeit?

Aus Kundensicht ist der Server dann aber nicht mehr verfügbar, weil seine Website "weg" ist. Da jedoch eine Agentur die Website betreibt und auch für die Konfiguration zuständig ist, kann der Hoster keine Verfügbarkeit oberhalb des reinen Betriebssystems garantieren.

Als Webagentur oder Softwaredienstleister, die der der als Generalunternehmer gegenüber dem Kunden auftritt, 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 und zu den Ausfallrisiken auf der Seite 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, der betrieben werden soll, vereinbart wird.

Dies ist bei etwas komplexeren Projekten allerdings nicht mehr so einfach. Häufig wird hier dann ein Kompromiss geschlossen, und der Dienstleister garantiert die Verfügbarkeit des gesamten Projektes, so wie der Kunde es möchte, obwohl zu diesem Zeitpunkt eigentlich niemand weiß, wie hoch die Verfügbarkeit wirklich ist.

Versäumnisse im SLA-Management
Schwachstellen im Umgang mit business-bezogenen Service-Level-Agreements (SLAs) wiederholen sich. Ursache ist oft, dass eine sauber definierte Schnittstelle zwischen Geschäftsprozess und IT-Infrastruktur zu wenig Wertschätzung erfährt

Verzicht auf SLAs:
Ohne SLAs wissen Anwender und Dienstleister nicht genau, welche Leistungen eingekauft und geliefert werden. Der Provider tut, was seine Infrastruktur hergibt. Die Unzufriedenheit des Kunden ist vorhersehbar.

SLAs sind unbekannt:
Missverständnisse entstehen, wenn die Details zwar schriftlich vereinbart, den betroffenen Personen aber nicht mitgeteilt wurden. Mitarbeiter des Providers wissen nicht, was sie liefern müssen, und dem Anwender ist unklar, was er erwarten darf.

SLAs werden ignoriert:
Kunden können keine hundertprozentige Leistung erwarten, wenn sie nicht vereinbart wurde. Umgekehrt muss der Lieferant bei Bedarf investieren, um die vereinbarten Güten zu gewährleisten.

SLAs sind schwammig:
Begriffe wie maximale Kundenzufriedenheit oder höchste Verfügbarkeit sind keine Seltenheit. SLAs müssen messbar sein. Ein Reporting sollte die Leistung dokumentieren. So lassen sich Schwachstellen aufspüren und beseitigen.

Die IT bestimmt die SLAs:
Qualitätsvereinbarungen sollten davon abgeleitet werden, was Anwender benötigen, und nicht, was die IT liefern kann.

Aufwendiges Management:
Was nicht automatisiert wird, braucht zu viel Zeit. Das Reporting hilft nur, Vergangenes zu bewältigen. Zeitnahe Steuerung kann Leistung auf hohem Niveau gewährleisten.

Keine Detailkontrolle:
Trotz hoher Gesamtverfügbarkeit kann es in einzelnen Bereichen zu übermäßigen Ausfällen kommen. Wichtig ist ein Management auf allen relevanten SLA-Ebenen.

Einflüsse bei der Verknüpfung von Verfügbarkeiten am Beispiel einer VMware-Umgebung

Wenn wir über die Verfügbarkeit eines kompletten Dienstes reden, müssen wir uns Gedanken über die Verknüpfung und die 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. Durch die Möglichkeiten, die VMware in verteilten Umgebungen bietet, haben wir bei den einzelnen virtuellen Servern eine sehr hohe Verfügbarkeit bei rund 99,99 Prozent auf das Jahr.

Dabei ist allerdings zu beachten, dass bei der Miete einer nackten VMware-Ressource die Verfügbarkeit der auf der virtuellen Maschine laufenden Projekte noch von weiteren Parametern beeinflusst wird.

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 die Failover-Technologien innerhalb weniger Minuten wieder verfügbar. Nun booten die Server bei einem Failover einmal neu. Je nach Installation kann es einige Zeit dauern, bis alle Dienste wieder verfügbar sind. Dies ist dabei nicht in der Verfügbarkeit der VM abgebildet.

2. Die Verfügbarkeit der Applikationen auf dem virtuellen Server hängt in der Regel 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 aber letztendlich absolute Verfügbarkeit von Applikationen kann dabei maximal bei 99,97 Prozentliegen.

Bei der Verknüpfung von Verfügbarkeiten sprechen wir von einer Addition des Ausfallrisikos. Diese liegt bei einer Verfügbarkeit von 99,99 Prozent bei 0,01 Prozent.

Haben wir drei Services, die für die Gesamtverfügbarkeit verfügbar sein müssen, liegt das Ausfallrisiko bei 3 x 0,01 Prozent = 0,03 Prozent. Das ergibt eine Gesamtverfügbarkeit von 100 Prozent - 0,03 Prozent = 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, sicher nicht über 99,95 Prozent liegen.

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)