AWS-Architekturen und Verfahren zur Notfallwiederherstellung, Teil I: Wiederherstellungsstrategien in der Cloud

von Seth Eliot, übersetzt durch Dirk Stahlecker

Als leitender Lösungsarchitekt betreue ich die Zuverlässigkeitssäule des AWS Well-Architected-Frameworks und helfe Kunden dabei, belastbare bzw. resiliente IT-Workloads auf AWS zu erstellen. Dadurch unterstütze ich sie bei einer ihrer größten Herausforderungen, nämlich sich auf Notfälle und Katastrophen angemessen und richtig vorzubereiten. Zu diesen Ereignissen gehören Naturkatastrophen wie Erdbeben oder Überschwemmungen, technische Ausfälle wie Strom- oder Netzwerkausfall und menschliche Eingriffe, z.B. unbeabsichtigte oder unbefugte Änderungen. Letztlich wird jedes Ereignis, das eine IT-Workload oder ein System daran hindert, seine Aufgabe am Hauptstandort zu erfüllen, als Katastrophe eingestuft. Dieser Blogbeitrag zeigt, wie man passende Architekturen für die Notfallwiederherstellung (engl. «Disaster Recovery – DR»), d.h. für den Prozess der Vorbereitung und Wiederherstellung nach einer Katastrophe, entwickelt. Die Notfallwiederherstellung Ihrer IT-Workloads ist ein entscheidender Teil zur Aufrechterhaltung des Geschäftsbetriebs.

Ziele der Notfallwiederherstellung

Weil ein Katastrophenereignis Ihre IT-Workloads möglicherweise ausfällen lässt, ist das Ziel der Notfallwiederherstellung, sie wieder schnell Verfügbar zu machen und Datenverluste zu minimieren. Daraus ergeben sich die folgenden beiden Zielindikatoren:

• Wiederherstellungszeitpunkt (engl. «Recovery Point Objective – RPO»): Die maximal zulässige Zeitspanne seit dem letzten Datenwiederherstellungspunkt. Der RPO-Wert beeinflusst den maximal akzeptablen Datenverlust.
• Wiederherstellungsdauer (engl. «Recovery Time Objective – RTO»): Die maximal zulässige Verzögerung zwischen der Unterbrechung des Dienstes und der Wiederherstellung des Dienstes. Der RTO-Wert bestimmt die akzeptable Dauer für Serviceausfälle.

Abbildung 1: Ziele: Wiederherstellungszeitpunkt (RPO) und Wiederherstellungsdauer (RTO)

Für RPO und RTO bedeuten niedrigere Zeit-Werte geringere Ausfallzeiten und einen geringeren Datenverlust. Anderseits führen niedrigere RPO- und RTO-Ziele, zu höheren Kosten durch zusätzliche IT-Ressourcen und durch eine grössere Betriebskomplexität. Deshalb müssen die gewählten RPO/RTO-Ziele und deren Kosten, in einem angemessenen Verhältnis zum Geschäftswert der IT-Workloads stehen.

Umfang und Auswirkungen eines Katastrophenereignisses

Multi-AZ-Strategie

Jede AWS-Region besteht aus mehreren Verfügbarkeitszonen (engl.: «Availability Zones – AZs») und jede AZ ist aus einem oder mehreren Rechenzentren aufgebaut. Die verschiedenen AZs einer AWS-Region befinden sich innerhalb eines Umkreises von 100 km an separaten geografischen Standorten. Dadurch wird das Risiko, dass sich ein einzelnes Ereignis auf mehr als eine AZ auswirkt, erheblich reduziert. Wenn Sie also eine Notfallwiederherstellungsstrategie entwerfen, die Ereignissen wie Stromausfälle, Überschwemmungen und anderen regional begrenzte Katastrophen abdecken muss, dann bietet die Verwendung einer Multi-AZ-Strategie innerhalb einer AWS-Region den benötigten Schutz.

Multi-Regionale Strategien

AWS stellt auch Services und Ressourcen bereit, um eine Notfallwiederherstellungsstrategie für Ihre IT-Workloads zwischen AWS-Regionen zu ermöglichen. Dies bietet Geschäftssicherheit gegen Ereignisse, die nicht regional begrenzt sind und ausreichenden Umfang haben, um sich auf mehrere AZs einer Region auswirken zu können. Für die meisten Beispiele in diesem Blogbeitrag verwenden wir einen multi-regionalen Ansatz, um die Notfallwiederherstellungsstrategien zu demonstrieren. Diese multi-regionalen Beispiele lassen sich jeweils auch in Richtung Multi-AZ-Strategien oder Hybridstrategien (Lokale Workload/Cloud-Wiederherstellung) anpassen.

Notfallwiederherstellungsstrategien

AWS stellt Ressourcen und Services zur Verfügung, um eine Notfallwiederherstellungs-strategie zu entwickeln, die Ihre Geschäftsanforderungen erfüllt.

Abbildung 2: Wiederherstellungsstrategien – Abwägung zwischen RPO/RTO und Kosten

Abbildung 2 zeigt die vier Notfallwiederherstellungsstrategien, die im AWS Disaster-Recovery-Whitepaper beschrieben werden. Von links nach rechts zeigt die Grafik, wie die verschiedenen Notfallwiederherstellungsstrategien zu unterschiedlichen Wiederherstellungszielen (RPO, RTO) führen. Sie wählen die für Ihr Unternehmen optimale Strategie indem für verschiedene Risikoszenarien und IT-Workloads eine Kosten / Nutzen Analyse mit dem Geschäftsverantwortlichen und den IT Verantwortlichen durchgeführt wird und die Wiederherstellungsziele (RPO, RTO) festlegt werden.

Aktiv/passiv und aktiv/aktiv Notfallwiederherstellungsstrategien

Abbildung 2 kategorisiert die Notfallwiederherstellungsstrategien in aktiv/passiv oder aktiv/aktiv Verfahren.

Abbildung 3: Aktiv/passiv Notfallwiederherstellung

In Abbildung 3 ist dargestellt, wie die aktiv/passiv Strategie aufgebaut ist und abläuft. Die IT-Workload wird von einem einzigen Standort aus betrieben (in diesem Fall in einer AWS-Region) und alle Anfragen werden von dieser aktiven AWS-Region bearbeitet. Sobald ein Desaster eintritt und diese aktive Region den Betrieb nicht mehr unterstützen kann, wird der bisher passive Standort aktiviert und zur Wiederherstellungsregion. Wir ergreifen dann weitere Maßnahmen, damit unsere IT-Workload vom der nunmehr aktivierten AWS-Region betrieben werden kann. Dieser Umstellungsprozess wird als «Failover» bezeichnet und nach erfolgreichem Abschluss werden alle Anfragen an die neue aktive AWS-Region geleitet. Für strengere RPO/RTO-Ziele werden die Daten live verwaltet, sodass eine Zeitaufwendige Wiederherstellung aus dem Backup entfällt. Zusätzlich wird die Infrastruktur bereits vor dem Failover ganz oder teilweise am Wiederherstellungsstandort vorgehalten. Falls Daten zuerst aus einem Backup wiederhergestellt werden müssen, kann dies den Wiederherstellungszeitpunkt (engl. «RPO») und damit den Datenverlust erhöhen. Falls zusätzliche Massnahmen nötig sind, bevor Live-Verkehr möglich wird, kann dies die Wiederherstellungsdauer (engl. «RTO») erhöhen. Eine Verschlechterung von RPO und RTO ist akzeptabel, solange damit die Geschäftsziele erreicht werden.

Abbildung 4:  Aktiv/aktiv Notfallwiederherstellung

Abbildung 4 zeigt eine aktiv/aktiv Strategie, bei der zwei oder mehr AWS-Regionen aktiv Anfragen annehmen und die Daten zwischen ihnen repliziert werden. Wenn eine Region von einem Desaster betroffen ist, bedeutet «Failover», dass Anfragen von der ausgefallenen AWS-Region an die andere aktive AWS-Region oder AWS-Regionen weitergeleitet werden. Obwohl Daten zwischen den AWS-Regionen kontinuierlich repliziert werden können, müssen wir die Daten im Rahmen der Notfallwiederherstellung trotzdem regelmässig sichern. Dadurch wird das Risiko von Datenverlust durch „menschliches Eingreifen“ oder durch technische Katastrophen reduziert. Wenn eine Katastrophe zu gelöschten oder beschädigten Daten führt, muss durch eine Point-in-Time Datenwiederherstellung vom Backup der letzte bekannte und funktionsfähige Status zurückgespielt werden.

Architektur der Wiederherstellungsstrategien

Jede einzelne im folgendem vorgestellte Notfallwiederherstellungsstrategie wird in zukünftigen Blogbeiträgen detailliert beschrieben. Die folgenden Abschnitte fassen jede Strategie zusammen.

Datensicherung und Wiederherstellung

 Abbildung 5: Architektur für Datensicherung und Wiederherstellung (engl. «Backup & Restore»)

Abbildung 5 zeigt die Datensicherungen (engl. «Backup») von verschiedenen AWS-Datenquellen. Die Backups werden in derselben AWS-Region wie ihre Quelle gespeichert und zusätzlich in eine andere Region kopiert (engl. «Cross-Region backup»). Dieses Verfahren bietet unseren Kunden den effektivsten Schutz vor Katastrophen jeglicher Tragweite. Für das »Failover» zwischen AWS-Regionen (engl. «Cross-Region Failover») müssen Sie zusätzlich zur Datenwiederherstellung aus dem Backup auch in der Lage sein, die verwendete Infrastruktur in der Wiederherstellungsregion bereitzustellen. Durch die konsequente Verwendung von Infrastruktur als Code mit AWS CloudFormation oder durch das AWS Cloud Development Kit (AWS CDK) wird eine konsistente Infrastruktur in allen AWS-Regionen bereitgestellt.

Die Datensicherungs- und Wiederherstellungsstrategie (engl. «Backup and Restore») ist die am wenigsten effiziente RTO-Strategie und führt zu den höchsten RTO-Werten. Der RTO-Wert wird verbessert indem Sie AWS-Ressourcen wie Amazon EventBridge verwenden, um eine serverlose Automatisierung zu entwickeln. Dadurch wird ein Fehler früher erkannt, und die Wiederherstellung wird schneller abgeschlossen. Das Verfahren wird in einem zukünftigen Blogbeitrag näher untersucht.

Pilot-Light

Abbildung 6: Architektur für die Pilot-Light Wiederherstellungsstrategie

In der Pilot-Light Strategie (engl. «Pilot light strategy») sind die Daten live, aber die Dienste auf der passiven Seite sind inaktiv. «Live» Daten bedeuten, dass die Datenspeicher und Datenbanken auf der passiven Seite immer bzw. fast immer auf dem neuesten Stand sind und Lesevorgänge jederzeit durchgeführt werden können. In Abbildung 6 ist dargestellt, dass durch die Amazon Aurora Global Database eine read-only Aurora Kopie (engl. «Aurora Replica») in der zunächst passiven Wiederherstellungsregion erstellt wurde. Wie bei allen Wiederherstellungsstrategien sind auch in diesem Fall Backups durch einen Aurora DB cluster snapshot nötig, die in der passiven Region gespeichert werden. Im Fall von Katastrophenereignissen, bei denen Ihre Daten gelöscht oder beschädigt werden, können Sie mit diesen Backups den letzten bekannten und funktionsfähigen Status zurückspielen.

In der Pilot-Light Architektur werden grundlegende Infrastrukturelemente wie Elastic Load Balancing und Amazon EC2 Auto Scaling auf der passiven Seite bereitgestellt. Allerdings sind Funktionselemente wie z.B. Amazon EC2 Instanzen „ausgeschaltet“. Ausgeschaltet in der Cloud bedeutet, sie erst gar nicht bereitzustellen. Konsequenterweise sind in der passiven Region in Abbildung 6, keine Compute Instanzen erkennbar. Um dort Amazon EC2 Instanzen bei Bedarf zu „aktivieren“, verwenden wir ein Amazon Machine Image (AMI), das zuvor erstellt und in alle Regionen kopiert wurde. Dieses AMI erstellt bei Bedarf Amazon EC2 Instanzen mit dem benötigten Betriebssystem und Paketen. Das ist vergleichbar mit der Zündflamme in einem Ofen, die ein Haus nicht ausreichend heizen kann, aber den Hauptgasstrom bei Bedarf entzündet. Analog stehen auf der zunächst passiven Seite Elemente bereit, die bei Bedarf alle nötigen IT-Infrastrukturelemente zügig und mit der nötigen Kapazität verfügbar machen.

Warm standby

Abbildung 7: Architektur für die Warm-Standby Notfallwiederherstellung

Wie die Pilot-Light Strategie stellt die Warm-Standby Strategie zusätzlich zu den regelmäßigen Backups die Live-Daten zur Verfügung. Der Unterschied zwischen den beiden Strategien ist, dass im Warm-Standby die IT-Workload bereits auf einer minimalen Infrastruktur vollständig läuft und somit Anfragen mit reduzierter Kapazität verarbeiten werden können. Wie in Abbildung 7 dargestellt, ist in jeder Architekturebene (engl.: «tier») bereits eine Amazon EC2-Instanz vorhanden. Weil alle Endpunkte der IT-Workload auf der passiven Seite verfügbar sind, ist es in dieser Konfiguration einfacher, die Warm-Standby IT-Workload zu testen und alle Testtransaktionen zu verarbeiten. Da die vorgehaltene Infrastruktur allerdings nur sehr geringe Kapazität aufweist, muss sie vor dem Failover skaliert werden, um die Produktionsanforderungen zu erfüllen.

Multi-Standort aktiv/aktiv

In der Multi-Standort aktiv/aktiv Anordnung (engl. «Multi-site active/active DR architecture») nehmen zwei oder mehrere AWS-Regionen aktiv Anfragen entgegen. Sollte es zu einem Failover kommen, dann müssen lediglich die Anfragen an die ausgefallene Region an die weiterhin funktionierenden AWS-Regionen umgeleitet werden. In dieser Anordnung werden Daten regionsübergreifend repliziert und aktiv verwendet, um Leseanfragen in der jeweiligen Region zu bearbeiten.

Abbildung 8: Architektur für die Multi-Standort aktiv/aktiv Notfallwiederherstellung

Für Schreibanfragen können Sie verschiedene Verfahren verwenden. Ein Beispiel ist das Schreiben in die lokale AWS-Region oder das Umleiten von Schreibvorgängen an bestimmte AWS-Regionen. Diese Verfahren werden in einem zukünftigen Blogbeitrag ausführlich besprochen. Wie immer für Notfallwiederherstellungsstrategien werden Datensicherungen durchgeführt damit sich Daten bei Verlust wiederherstellen lassen. Abbildung 8 zeigt wie in der Datenbankebene Amazon DynamoDB mit globalen Amazon DynamoDB-Tabellen verwendet werden. Das ist eine ausgezeichnete Wahl für eine Multi-Standort aktiv/aktiv Anordnung, weil in diese lokalen Tabellen von der jeweils zugeordneten Region geschrieben werden kann und die Daten normalerweise innerhalb einer Sekunde in allen anderen Regionen zur Verfügung stehen.

Fazit

Katastrophenereignisse stellen eine Gefahr für die Verfügbarkeit Ihrer IT-Workloads und Ihres Geschäftsbetriebs dar. Durch die Nutzung der AWS-Cloud-Dienste reduzieren oder eliminieren Sie diese Gefahr für Ihr Unternehmen. In einem ersten Schritt analysieren Sie Ihre IT-Workloads und legen die Geschäftsanforderungen fest. Danach wählen Sie eine geeignete Wiederherstellungsstrategie. Schliesslich entwerfen Sie mithilfe von AWS-Services eine Architektur, um den geschäftlich erforderlichen Wiederherstellungszeitpunkt- (engl. «RPO») und die Wiederherstellungsdauer (engl. «RTO») zu erreichen.

Über den Autor

Seth Eliot Als Principal Developer Advocate und vorher als Principal Reliability Solutions Architect bei AWS hilft Seth AWS-Kunden, robuste und skalierbare Systeme in der Cloud zu entwerfen und aufzubauen. Er verfügt über 11 Jahre Erfahrung in verschiedenen technischen Funktionen bei Amazon.com. Dort hat er als Principal Solutions Architect praxisnah mit Ingenieuren zusammengearbeitet, um für Amazon.com die Verwendung der AWS Cloud zu vertiefen und zu optimieren. Zuvor war er Principal Engineer für Amazon Fresh und International Technologies. Seth kam 2005 zu Amazon, wo er bald darauf die Technologie mitentwickelte, aus der Prime Video werden sollte. Sie können Seth auf Twitter @setheliot oder auf LinkedIn unter https://www.linkedin.com/in/setheliot/ folgen.