Wiederherstellung kritischer Cloud-Dienste
Der beherrschbare Ernstfall
Die Cloud-Dienste von Amazon, Google, Microsoft und IBM sind ausfallsicher, skalierbar und einfach zu buchen. Diese Qualität im Betrieb ist Segen und Fluch zugleich: Unternehmen binden die Ressourcen der Cloud heute wie selbstverständlich in wichtige Prozesse und Applikationen ein. Das wirft Fragen auf: Wie wirkt sich ein Ausfall der Cloud auf kritische Applikationen aus? Ist so ein Szenario überhaupt beherrschbar?
Deutsche Kunden denken inzwischen "Cloud first", wenn sie neue Services aufsetzen. Heute haben 75 Prozent der deutschen Unternehmen einen Cloud-Provider im Einsatz, 67 Prozent nutzen bereits zwei und 42 Prozent schon drei Cloud-Dienstleister, so ein Ergebnis aus der "Truth in Cloud"-Umfrage von Veritas. Jeder Provider betont dabei, mit seinen Kunden ein sogenanntes "Shared-Responsibility-Modell" (Modell mit geteilter Verantwortung) zu etablieren. Je komplexer der Dienst, desto mehr Verantwortung hat der Dienstleister, aber das Anwenderunternehmen bleibt immer für seine Daten und deren Compliance verantwortlich, auch bei Datenlecks oder Ausfällen. Amazon formuliert dieses Verhältnis so: Während der Provider für die Sicherheit der Cloud zuständig ist, bleibt es der Kunde für die Sicherheit der Daten in der Cloud.
Doch das Modell der geteilten Verantwortung scheint in den Köpfen mancher IT-Leiter auf Unternehmensseite zu wenig verankert zu sein. So zeigte zum Beispiel die genannte Umfrage, dass 83 Prozent der deutschen Unternehmen, die IaaS nutzen oder planen, Verantwortung für die Datensicherung in der Cloud in den Händen des Cloud-Service-Providers sehen. So wächst die Gefahr, dass IT-Leiter völlig unterschätzen, wie sich der Ausfall der Cloud-Ressourcen auf ihre kritischen Applikationen auswirkt. Für Cloud-Service-Provider gelten strenge Service-Level-Vorgaben - die sich in der Regel aber nur auf die Infrastruktur beziehen. Die Anbieter sind bei einem Cloud-Ausfall nur dafür verantwortlich, ihre Infrastruktur zum Laufen zu bringen. Sobald diese wieder online ist, gilt es, auch die Anwendungen wieder in Betrieb zu nehmen - und hier kommen ausschließlich die Anwenderunternehmen ins Spiel.
Je komplexer die Anwendungen strukturiert, je enger sie verzahnt sind und je mehr Daten während des Ausfalls verloren gingen, desto länger wird ihre Wiederherstellung dauern - im Regelfall sogar weitaus länger als die Wiederherstellung der zugrunde liegenden Infrastruktur. Denn IT-Abteilungen setzen meist isolierte Tools und manuelle Prozesse ein, um ihr Infrastrukturkonglomerat zu überwachen. Hier setzt keine übergreifende Instanz die wichtigen Parameter, mit denen der Failover im Ernstfall festgezurrt wird, Ende zu Ende durch. Vielmehr sind sie nur in den Inselwelten wie dem Management der virtuellen Systeme etabliert.
Der gesamte Vorgang ist in Einzelteile zerfranst - in diverse Hypervisoren und Plattformen wie Hyper-V, vSphere oder OpenStack. Es existieren unterschiedliche Disaster-Recovery-Ziele, verschiedene Replizierungen und eigene SLAs für unterschiedliche Applikations-Stacks, ohne dass jemand einen Gesamtüberblick über den aktuellen Zustand der kritischen Dienste geben könnte. Für die Übergänge zwischen Verantwortungsbereichen greifen Unternehmen dann auf die erwähnten manuellen Abläufe zurück, die träge, fehleranfällig und teuer sind.
Ob die RTOs (Recovery Time Objectives) und RPOs (Recovery Point Objectives) dann tatsächlich einheitlich auf alle Elemente einer kritischen Applikation Anwendung finden, ist schwierig vorherzusagen. Der Ernstfall wird immer schwerer zu kalkulieren und zu beherrschen, je komplexer die Multi-Tier-Anwendung strukturiert ist.
Wer die Hochverfügbarkeit von Diensten mit manuellen Prozessen, Excel-Tabellen oder isolierten Tools steuert, wird es schwer haben, Ausfälle vorhersehbar und kontrolliert zu überbrücken. Solche Ansätze leiden an fehlendem Überblick, Ineffizienz und Unberechenbarkeit. Vor allem schaffen sie ein höheres Ausfallrisiko. Die Enterprise Strategy Group erklärte, dass 51 Prozent der Unternehmen weniger als eine Stunde Ausfallzeit erlauben - doch nur 22 Prozent erreichen in eigenen Wiederherstellungstests eine Erfolgsrate von 90 Prozent.
Es ist unabdingbar, Multi-Cloud-Applikationsarchitekturen und deren Verfügbarkeit mit Business-Continuity-Konzepten zu kontrollieren. Solche Konzepte müssen mit den führenden Cloud-Anbietern eng interagieren und deren Data Mover (Datenbereitstellungsmechanismen) nutzen; oder sie nutzen eigene Mechanismen und sind vom Cloud-Provider entsprechend zertifiziert, damit die Daten und Workloads direkt in den jeweiligen Cloud-Welten bewegt werden. Außerdem legt die Zertifizierung die Grundlage dafür, dass das Business-Continuity-Konzept die Struktur der Applikation lokal beim Anwender sowie in der Cloud automatisch mit geringer Fehlerquote per Autodiscovery erfassen kann. So lässt sich jedes Element in der Applikationsarchitektur von der Datenbank über die Frontend-Web-Applikation und die virtuellen Maschinen bis hin zum Storage identifizieren.
Alle Ergebnisse sollten in einer zentralen grafischen Oberfläche zusammenlaufen, die es dem Anwenderunternehmen erlaubt, den gesamten Disaster-Recovery-Prozess der Dienststruktur per Drag and Drop zu modellieren. Dann lässt sich der große Vorteil einer solchen übergreifenden Instanz klar ausspielen: Per Automatismus wickelt sie in der Krisensituation einen komplexen Prozess ab, für den die IT-Leitung klar messbare Kriterien für Failback und Failover vorgegeben hat.
Außerdem ist es essenziell, dass man mit dem übergeordneten Business-Continuity-Konzept den gesamten Disaster-Recovery-Vorgang testen kann, ohne den laufenden Betrieb zu stören. So können IT-Leiter genau untersuchen, wie lang es dauert, wichtige Geschäftsanwendungen wiederherzustellen. Solche Tests können belastbare Zahlen für den Ernstfall generieren. Die Ergebnisse sollten in einem zentralen Dashboard erfasst sein, damit die Verantwortlichen auf einen Blick sehen, ob alle Geschäftsanwendungen die wichtigen Vorgaben einhalten - unabhängig davon, wie komplex der Dienst ist und auf wie vielen unterschiedlichen internen und externen Ressourcen er läuft.
Synergien im Alltag
Je mehr externe und interne Ressourcen mit unterschiedlichen Verantwortlichen zusammenspielen, um einen komplexen Dienst zu betreiben, desto schwieriger ist es, allgemein etwas zu dessen Gesamtzustand zu sagen. Schließlich sind Monitoring-Tools auf die jeweiligen Systemwelten beschränkt. Eine übergeordnete Business-Continuity-Instanz hat jedoch direkt Zugriff auf alle Elemente der Multi-Tier-Applikation und kann beispielsweise schneller auf Probleme hinweisen. So lassen sich IT-Probleme, die bislang nur dem Server- oder Storage-Team bekannt waren, in den Kontext setzen und mit dem wichtigen Dienst verknüpfen. Das Problem wird mit dem angemessenen Risiko und entsprechender Priorität gekennzeichnet, statt in den jeweiligen Inselwelten zu bleiben. Dies macht Krisen und IT-Probleme besser beherrschbar.
Auch bei Wartungsarbeiten kann ein solches Konzept helfen. So könnte man eine Gruppe von virtuellen Maschinen per Mausklick auf eine Disaster-Recover-Site in der Cloud verschieben. In ihrer ursprünglichen Umgebung ließen sich dann Modifikationen am DNS-Dienst oder andere grundlegende Wartungsarbeiten durchführen. Solche Operationen verlangen heute viele zeitaufwändige und kraftraubende Abstimmungen zwischen unterschiedlichen Abteilungen.
Berechenbarkeit im Ernstfall
IT-Leiter sollten die Anatomie eines Cloud-Ausfalls verstehen und wissen, dass nur der Cloud-Service-Provider und das Unternehmen gemeinsam die Wiederherstellung nach dem Ausfall bewältigen können. Richten Unternehmen für ihre Anwendungen bereits im Vorfeld Multi-Cloud-Ausfallmechanismen ein, haben sie im Ernstfall nicht nur die volle Verantwortung, sondern auch die volle Kontrolle über die Wiederherstellung ihrer kritischen Services.
Lesen Sie mehr zum Thema
