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.
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.