Wenn die Wolken brechen: Disaster Recovery in der Public Cloud

Wenn die Katastrophe eintritt

Die meisten Unternehmen sind heute zumindest teilweise in die Public Cloud umgezogen. Zu den Vorteilen der Public Cloud zählen Skalierbarkeit, Flexibilität und erfolgskritische moderne digitale Lösungen. Ein weiterer Vorteil ist zudem die Verfügbarkeit und Sicherheit von Daten, Applikationen und Geschäftskontinuität bei Katastrophen wie Infrastruktur-Sabotage (z.B. Internetausfall), Naturkatastrophen oder gar militärischen Konflikten. Ein Irrtum dabei ist jedoch, dass die Public Cloud sich automatisch um sogenannte „Disaster Recovery“ kümmert. Damit sind Strategien und Maßnahmen gemeint, die im Katastrophenfall Datenverlust und Geschäftsunterbrechung vermeiden. Es stimmt zwar, dass die bekanntesten Public-Cloud-Anbieter (Azure, AWS und GCP) mehrere geografisch verteilte Rechenzentren betreiben, um Anforderungen an Datenschutz, Geschäftskontinuität und gesetzliche Vorschriften zu ermöglichen. Sie stellen zudem auch unterstützende Services zur Verfügung, die ein Disaster Recovery zwischen entfernten Regionen ermöglichen. Allerdings ist es Aufgabe der Unternehmen eine Disaster entsprechende Strategie zu konzipieren und diese Services zu konfigurieren und einzusetzen. Wie geht das? Dieser Artikel beleuchtet die wesentlichen Aspekte und Best Practices für eine effektive regionenübergreifende Disaster-Recovery-Strategie in der Public Cloud.

Was bedeutet Disaster Recovery?

Disaster Recovery (DR) bezieht sich auf die Strategien und Maßnahmen, die ein Unternehmen ergreift, um nach einem katastrophalen Ereignis den normalen Geschäftsbetrieb wiederherzustellen. Das passiert in einem abgelegenen sogenannten Disaster-Recovery-Standort, wo die Daten und Services repliziert werden, bis der primäre IT-Standort wieder voll funktionsfähig ist. Zudem umfasst DR die Sicherung und Wiederherstellung von Daten, Systemen und Infrastruktur, um Ausfallzeiten zu minimieren und den Geschäftsbetrieb schnell wieder aufzunehmen. Um das alles zu gewährleisten, benötigen Unternehmen eine Kombination von strategischem Plan und Technologiedesign.

Was Unternehmen tun sollten

Der erste Schritt ist, zu analysieren, welche Anwendungen geschäftskritisch sind. Darauf basierend werden die benötigten Business-Anforderungen und Infrastrukturtechnologien ermittelt. Diese sind dann ausschlaggebend für die IT-Architektur des DR-Standortes. Im Folgenden finden Sie die wichtigsten Aspekte, die dabei berücksichtigt werden müssen.

RPO (Recovery Point Objective) vs. RTO (Recovery Time Objective)
Die Business-Anforderungen ergeben sich aus zwei Parametern, RTO und RPO. RPO bezieht sich auf die Menge an Datenverlusten innerhalb eines bestimmten Zeitraums, bevor ein maximal tolerierbarer Schaden entsteht, s. Abbildung 1. RTO definiert, wie schnell die IT-Systeme nach einem Ausfall laufen sollen. Diese zwei Parameter sind die Basis für die weiteren Schritte.

Disaster-Recovery-Standort

Die Lage des DR-Standortes wiederum ist von dem Business Case und gesetzlichen Vorschriften (z.B. Datenschutz-Grundverordnung) abhängig. Bei der Auswahl ist zu beachten, dass die Public-Cloud-Services SLAs (Service Level Agreements) nicht in allen Regionen identisch sind, wo ein Public-Cloud-Anbieter Rechenzentren hat. Vor allem die neuesten Cloud Services sind nicht überall in gleicher Qualität angeboten. Auch eine Multi-Cloud-Strategie des Unternehmens kann die Entscheidung beeinflussen. Die gewählte Region muss in diesem Fall Rechenzentren von allen Anbietern haben, die Teil der Multi-Cloud-Strategie des Unternehmens sind, s. Abbildung 2.

Zudem existieren für den Aufbau eines DR-Standortes drei grundlegende Ansätze: kalt, warm und heiß. Diese drei Begriffe beziehen sich auf die Einfachheit, mit der eine IT-Umgebung im Falle eines Disasters wiederhergestellt werden kann, s. Abbildung 3.

Disaster-Recovery-Plan

Der Disaster-Recovery-Plan ist ein formelles Dokument, das die zielgerichtete Wiederherstellung (z.B. Wiederherstellungsprozesse, Kommunikationsprozesse, Testprotokolle, etc.) der aus Business-Sicht benötigten Services in einer weit entfernten Region unterstützt.  Der Plan wird in der DR-Region gespeichert und in regelmäßigen Abständen, mindestens einmal im Jahr, getestet. Somit validiert und aktualisiert das verantwortliche Team den DR-Plan.

Replikationsansätze

Es gibt verschiedene Ansätze, um IT-Systeme am DR-Standort zu replizieren. Welche Technologien zum Einsatz kommen, hängt von der Art der Ressourcen (Virtuelle Maschine, Container, Platform-as-a-Service (PaaS) Datenbank, etc.) ab. Cloud-native Replikationstechniken sind gegenüber traditionellen Methoden zu bevorzugen, weil sie mehrere Vorteile bieten – z. B. vereinfachtes Management und Kosteneffizienz.

Manche Public-Cloud-Anbieter wie Azure bieten das Konzept von gepaarten Regionen. Zwei Regionen sind auf Grundlage der Nähe und anderer relevanter Faktoren als Paar gekoppelt. Spezifische cloud-native Replikationstechniken sind dann nur zwischen gepaarten Regionen möglich.

Replikationen benötigen ein kontinuierliches Monitoring, um Probleme zu erkennen. Viele Monitoring-Services der Public-Cloud-Anbieter haben dafür eingebaute KI-Algorithmen zur Anomalieerkennung (z.B. Identifikation vom Standard abweichender Replikationsmuster).

In bestimmten Fällen kann eine Anwendungs-Replikation entweder nicht nötig sein oder zu hohe Kosten verursachen. Dann bietet sich ein normales Re-Deployment – d. h. das komplett neue Aufsetzen von Anwendungen – als Alternative an.

Kapazitätsreservierung

Alle Public-Cloud-Anbieter werben mit flexibler Skalierung und nahezu unbegrenzter Kapazität. Wenn es um große Datenmengen oder Anzahl von Ressourcen geht (z.B. virtuelle Maschinen, PaaS Services, etc.) sieht es in der Realität oft anders aus. Nicht immer haben ihre Rechenzentren so viele freie Ressourcen. Deswegen empfehlen die Public-Cloud-Anbieter, Kapazität zu reservieren. In diesem Fall fallen reservierungsbedingte Kosten an, unabhängig davon, ob die reservierte Kapazität benutzt wird oder nicht.

Disaster-Recovery-Team

Was sind die perfekte IT-Architektur, Technologienauswahl und Prozesse ohne die richtigen Expert*innen wert? Unternehmen müssen ein dediziertes Team für den Disaster-Recovery-Fall trainieren und vorbereiten, um im Falle eines Disasters die nötigen Schritte zu überwachen und zu betreuen. Die Teammitglieder sollen idealerweise in der Region wohnen, in der sich der DR-Standort befindet, damit sie verfügbar sind und im Falle eines Disasters vereinfachten Zugang zu den DR-Systemen haben.

Für alle Fälle gewappnet

Die gängigen Public Clouds (Azure, AWS und GCP) bieten gegenüber herkömmlichen privaten Rechenzentren viele Vorteile wie Skalierbarkeit und Flexibilität. Dennoch ist es immer noch die Aufgabe jedes Unternehmens eine effektive Disaster-Recovery-Strategie zu entwickeln und zu implementieren. Diese ist entscheidend, um finanzielle Bereitstellungskosten zu minimieren, dynamisch auf Veränderungen zu reagieren und im Disaster-Recovery-Fall Daten und Anwendungen schnell wiederherzustellen.

Möchten Sie gerne eine auf Ihre Bedürfnisse zugeschnittene Disaster-Recovery-Strategie entwickeln, die die Besonderheiten der Public Cloud in Betracht zieht? Dann kontaktieren Sie mich gerne direkt.