AWS Germany – Amazon Web Services in Deutschland

AWS-Architekturen und Verfahren zur Notfallwiederherstellung, Teil II: Backup und schnelle Wiederherstellung durch Automatisierung

Von Seth Eliot, übersetzt durch Dirk Stahlecker

In einem früheren Blogbeitrag habe ich vier Strategien zur Notfallwiederherstellung (engl. «Disaster Recovery – DR») vorgestellt und dargelegt, wie man sie mit AWS-Services umsetzen kann. Diese Strategien ermöglichen es, sich auf ein Desaster systematisch vorzubereiten, Auswirkungen zu minimieren und den Geschäftsbetrieb aufrechtzuerhalten. Wenn Sie zum Entwurf und zur Umsetzung Ihrer Notfallwiederherstellungsstrategie die im Kapitel Zuverlässigkeit des AWS Well-Architected-Frameworks beschriebenen Best Practices verwenden, bleiben Ihre IT-Workloads trotz Desastern wie Naturkatastrophen, technischen Ausfällen oder menschlichen Eingriffen verfügbar.

In diesem Blogbeitrag wird die Strategie «Backup und Wiederherstellen» detailliert beschrieben. Durch Verwendung von Automatisierung wird die Ausfallzeit reduziert.

Gewählte Strategie: «Backup und Wiederherstellung»

Wie in Abbildung 1 dargestellt, ist die Strategie «Backup und Wiederherstellung» mit einem angestrebten Wiederherstellungszeitpunkt (engl. «Recovery Point Objective – RPO») und einer angestrebten Wiederherstellungsdauer (engl. «Recovery Time Objective – RTO») verbunden, die im Bereich von Stunden liegen. Im Vergleich zu den anderen Strategien führt dies zu größeren Datenverlusten und längeren Ausfallzeiten Ihrer IT-Workloads. Backup und Wiederherstellung kann jedoch immer noch die richtige Strategie für Ihre IT-Workload sein, weil sie einfach und kostengünstig zu implementieren ist und weil nicht alle IT-Workloads einen RPO und RTO-Wert von Minuten oder weniger benötigen.

Abbildung 1: Vier Notfallwiederherstellungsstrategien.

«Backup und Wiederherstellung» Implementieren

In Abbildung 2 zeigen wir eine Auswahl an AWS-Ressourcen die von Ihrer IT-Workload als Cloud-Speicher genutzt werden können:

Eine vollständige Übersicht finden Sie hier: Cloud-Speicher auf AWS.

Um die Strategie «Backup und Wiederherstellung» zu implementieren, wird der AWS Service AWS Backup verwendet. Der Service bietet eine zentrale Ansicht, in der Sie Backups für Ihre Speicher-Ressourcen konfigurieren, planen und überwachen. Wenn Sie «Backup und Wiederherstellung» verwenden, hängt Ihr RPO-Wert, ein Mass für den Datenverlust, davon ab, wie oft Backups erstellt werden.

Abbildung 2: Die Strategie «Backup und Wiederherstellung».

Backup innerhalb einer AWS-Region

Jede AWS-Region besteht aus mehreren Verfügbarkeitszonen (engl. «Availability Zones – AZs»). Um Hochverfügbarkeit (engl. «High Availability – HA») zu gewährleisten ist eine Multi-AZ-Strategie notwendig, die Ressourcen auf mehrere AZs einer Region redundant verteilt. Die regionale Hochverfügbarkeitsstrategie deckt dadurch bereits viel von dem ab, was zur Notfallwiederherstellung Ihrer IT- Workload in einer einzigen Region benötigt wird.

Desaster können allerdings auch durch menschliche Eingriffe und Softwarefehler ausgelöst werden, sodass Ihre Daten gelöscht oder beschädigt werden. Wenn das eintreten sollte, dann werden durch Hochverfügbarkeitsstrategien diese Datenfehler über alle AZs verteilt, wodurch gespeicherte Daten unbrauchbar werden. Um das zu vermeiden, müssen Sie Ihre Daten zusätzlich durch Backups bzw. Snapshots innerhalb der Region sichern (s. Abbildung 2). Wenn Sie AWS-Services verwenden, die eine Wiederherstellung zu einem bestimmten Zeitpunkt unterstützen (engl. «point-in-time recovery»), z.B. Amazon DynamoDB   oder Amazon Relational Database Service oder wenn Sie die Versionierung von Amazon S3 – Buckets aktivieren, dann lässt sich der letzte bekannte und funktionsfähige Zustand wiederherstellen.

Backups in einer anderen AWS-Region sichern

Zusätzlich zur zentralen Kontrolle von Backups innerhalb einer Region, können Sie die mit AWS Backup erstellten Backups auch in eine andere Region und in anderes AWS-Konto kopieren (s. Abbildung 2). Dadurch bewältigen Sie Desaster mit grosser geographischer Auswirkung. Falls ein Desaster dazu führt, dass Ihre IT-Workload in einer Region nicht mehr verfügbar ist, dann kann sie in einer Wiederherstellungsregion wiederhergestellt werden und von dort aus betrieben werden (s. Abbildung 3).

In der Wiederherstellungsregion sollten Sie für die Wiederherstellung ein anderes AWS-Konto mit anderen Passwörtern und Zugangsschlüsseln (engl. «access keys») als in der Hauptregion verwenden. Dadurch wird verhindert, dass sich mögliches menschliches Versagen oder Fehlverhalten im AWS-Konto einer Region auch auf eine andere Region auswirkt.

Abbildung 3: Failover und regionsübergreifende Wiederherstellung durch eine multi-regionale Backup und Wiederherstellungsstrategie.

«Backup und Wiederherstellung» – Und wie optimieren?

Wenn es zu einem Desaster kommt, wird Ihre Wiederherstellungsstrategie durch folgende 3 Schritte umgesetzt:

  1. Erkennung: Das Desaster wird Erkannt, die Auswirkungen auf Ihre IT-Workloads werden analysiert und Wiederherstellungsentscheidungen werden getroffen.
  2. Wiederherstellung: Wiederherstellen und Zusammenführen (engl. «re-integration») von IT–Infrastruktur und Daten, damit Ihre IT-Workload wieder betreibbar ist.
  3. Failover: Umleitung von Anfragen an die Wiederherstellungsregion.

1. Erkennung

Die Wiederherstellungsdauer (RTO) wird oft nur als die Zeit angesehen, die für die Wiederherstellung der IT-Workload und für das Failover benötigt wird. Aber wie in Abbildung 4 dargestellt, trägt die Zeitdauer von der Detektion bis zur Entscheidung zur Wiederherstellung zusätzlich und mitunter erheblich zur Wiederherstellungsdauer bei.

Abbildung 4: Relevante Einflussgrössen auf die gesamte Wiederherstellungsdauer (RTO) nach einem Desaster.

Um die Wiederherstellungsdauer (RTO) zu reduzieren, sollte die Erkennung des Desasters automatisiert werden. Denn: warten Sie nicht, bis Ihre Mitarbeiter das Problem bemerken, und warten Sie niemals, bis es Ihre Kunden bemerken.

In Abbildung 5 zeigen wir eine lose gekoppelte und ereignisgesteuerte Architektur, um Probleme früh zu erkennen und um darauf automatisiert und schnell zu reagieren.

Abbildung 5: Automatisierte Desaster- bzw. Problemerkennung und Reaktion mit Amazon EventBridge.

Durch den AWS Service Amazon EventBridge, erhält man Zugang zu Ereignissen bzw. Zustandsänderungen von mehr als 90 AWS-Services und als Reaktion darauf lassen sich spezifische Workflows auslösen. In diesem Beispiel werden die folgenden zwei Ereignisquellen verwendet:

  • Amazon CloudWatch stellt CloudWatch-Alarme zur Verfügung, die durch individuell konfigurierte und definierten Metriken bzw. Indikatoren ausgelöst werden. Ein Indikator kann aus mehreren anderen Indikatoren aufgebaut sein, er kann mathematische Ausdrücke verwenden oder auf verschiedenen Alarmen basieren. Dadurch lassen sich Sie ausgeklügelte Zustandsprüfungen («Health-Checks») Ihrer IT-Workloads konfigurieren. Darüber hinaus stellen Sie mithilfe von CloudWatch-Anomalieerkennung fest, ob z.B. Webseitenaufrufe, Bestellungen oder andere wichtige Leistungsindikatoren (engl. «KPIs») Ihrer IT-Workload gesunken sind. Das ist ein Hinweis darauf, dass Ihre IT-Workload durch ein Ereignis negativ beeinflusst wird.
  • Der Service AWS Health warnt Sie, wenn bei Amazon Web Services Ereignisse auftreten, die Ihre IT-Workloads oder AWS Accounts betreffen könnten. Sie können das AWS Personal HealthDashboard in der AWS-Managementkonsole aufrufen und EventBridge so konfigurieren, dass es diese AWS Health Ereignisse überwacht und darauf reagiert. Im folgenden JSON-Beispiel ist EventBridge so konfiguriert, dass es auf Ereignisse reagiert, die zu erhöhten Fehlerraten bei Amazon S3 PUT- und GET-Vorgängen führen.
{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "service": ["S3"],
    "eventTypeCategory": ["issue"],
    "eventTypeCode": ["AWS_S3_INCREASED_GET_API_ERROR_RATES", "AWS_S3_INCREASED_PUT_API_ERROR_RATES"]
  }
}

Abbildung 5 zeigt, dass wir auf Basis dieser Ereignisse verschiedene Maßnahmen ergreifen können. Beispielsweise kann ein Ereignis durch ein OpsItem in AWS Systems Manager (SSM) verfolgt werden. Oder wir können Entwickler und Betreiber benachrichtigen, indem wir Amazon Simple Notification Service (Amazon SNS) verwenden, um eine E-Mail oder Textnachricht zu senden. Es gibt mehrere Optionen eine automatische Antwort auszulösen. Z.B. kann AWS Lambda Code ausführen oder AWS Systems Manager-Automatisierung kann aktiviert werden, um Runbooks zu starten, die Aufgaben wie das Hochfahren von EC2 Instanzen oder sogar eine Sammlung von AWS-Ressourcen (engl. «Stacks») in AWS CloudFormation bereitstellen.

2. Wiederherstellen

Während der Datenwiederherstellung (engl. «restore») aus dem Backup werden auch die zugrunde liegenden Ressourcen für diese Daten wie z.B. EBS Volumes, RDS-DB Instanzen und DynamoDB Tabellen neu erstellt. Abbildung 6 zeigt, wie Sie AWS Backup verwenden, um Daten eines EBS Volumes in der Wiederherstellungsregion wiederherstellen. Der Wiederaufbau der Infrastruktur beinhaltet die Bereitstellung von Ressourcen wie EC2 Instanzen und auch des logisch isolierten virtuellen Netzwerks (Amazon VPC) mit den benötigten Subnetzen und Sicherheitsgruppen.

Für die Wiederherstellung der Infrastruktur in der Wiederherstellungsregion und um eine konsistente Infrastruktur in allen Regionen zu erstellen, sollten Sie konsequent Infrastructure as Code (IaC) verwenden. Dazu nutzen Sie AWS CloudFormation und das AWS Cloud Development Kit (AWS CDK). Die benötigten EC2 Instanzen für ihre IT-Workloads werden aus Amazon Machine Images (AMIs) aufgebaut, die das erforderliche Betriebssystem und die benötigten Pakete beinhalten. Die AMI’s, die benutzt werden um konsistent Server einzurichten werden auch als „goldene AMIs“ bezeichnet. Sie werden mit dem Amazon EC2 Image Builder erstellt und in die Wiederherstellungsregion transferiert.

Abbildung 6: Wiederherstellung von Daten aus dem Backup und Aufbau der nötigen Infrastruktur in der Wiederherstellungsregion.

In einigen Fällen müssen Sie Ihre Infrastruktur und Daten zusammenführen bzw. verbinden (engl. «re-integration»). In Abbildung 6 haben wir zum Beispiel statusbehaftete Daten in ein EBS Volume wiederhergestellt (1B). Dieses Volume musss wieder an die durch AWS CloudFormation wiederhergestellte EC2 Instanz angehängt werden (1A). Die Architektur in Abbildung 7 zeigt einen möglichen Weg, dies mit Amazon EventBridge und Lambda Funktionen serverlos zu automatisieren.

Abbildung 7: Automatische Verbindung Zusammenführung Integration von Infrastruktur und Daten als Teil der Wiederherstellung einer IT-Workload.

Der Ablauf ist wie folgt: (2) AWS Backup publiziert nach Abschluss der Datenwiederherstellung und Bereitstellung des EBS Volume (1B) ein Ereignis (engl. «event») das von Amazon EventBridge registriert wird. Als Reaktion darauf startet EventBridge zwei Aktionen: Ein OpsItem wird im OpsCenter zur Nachverfolgung erstellt (3A) und eine Lambda-Funktion wird aufgerufen (3B). Durch Amazon Event Bridge erhält AWS Lambda die ID des EBS Volume, das in der Wiederherstellungsregion erstellt wurde, sowie die ID des für die Wiederherstellung verwendeten Snapshots bzw. Backups. Damit ist auch der Wiederherstellungspunkt (engl. «recovery point») bekannt. Durch die APIs von Amazon EBS ruft eine Lambda-Funktion «Tags» (bzw. Metadaten) vom neu erstellten EBS Volume ab, die für die Verbindung von EBS Volume und EC2 Instanz nötig sind. Diese Tags befanden sich auf dem ursprünglichen EBS Volume (in der primären Region) und wurden durch AWS Backup automatisch auf den Snapshot und auf das wiederhergestellte EBS Volume übertragen. Durch die APIs von AWS CloudFormation ruft eine Lambda-Funktion die ID der EC2 Instanz ab. Im letzten Schritt (5) nutzt eine weitere Lambda-Funktion die Amazon EC2 APIs, um das EBS Volume anzuhängen.

Diese Automatisierung nur durch Lambda-Funktionen ist lediglich eine Möglichkeit. Andere Möglichkeiten, um die Wiederherstellung und das Failover mit AWS zu automatisieren sind zum Beispiel:

1/ Das Datenwiederherstellungsereignis aktiviert über Amazon EventBridge anstelle einer AWS Lambda Funktion ein Runbook im AWS Systems Manager. Dadurch wird ein wiederhergestelltes Amazon Elastic File System (EFS) oder Amazon FSx-Dateisystem mit einer oder mehreren EC2 Instanzen automatisch verbunden.

2/ Für umfassendere Automatisierungen wird der Service AWS Step Functions verwendet. Durch AWS Step Functions wird die Bereitstellung der Infrastruktur mit AWS CloudFormation, die Datenwiederherstellung mit AWS Backup und die Durchführung der nötigen Integrationsschritte veranlasst. Mit AWS Step Functions konfigurieren Sie einen visuellen Workflow, der durch Lambda-Funktionen jede Aktivität in der richtigen Reihenfolge und unter Einhaltung der erforderlichen Abhängigkeiten startet und überwacht.

3. Failover

Durch den dritten Schritt «Failover» werden die Systemanfragen von der primären Region (in der die IT-Workload nicht mehr ausgeführt werden kann) zur Wiederherstellungsregion umgeleitet. Der detaillierte Ablauf wird in einem zukünftigen Blogbeitrag behandelt.

Fazit

Geschäfts- und IT-Teams sollten gemeinsam die IT-Workloads analysieren, RPO und RTO-Werte festlegen und die Wiederherstellungsstrategien auswählen. Dabei sollte auch geprüft werden, für welche IT-Workloads die Strategie «Backup und Wiederherstellung» geeignet ist. Die niedrigen Kosten und die relativ einfache Implementierung dieser Strategie machen sie zu einer guten Wahl für viele AWS Workloads. Zusätzlich lässt sich durch Automatisierung die Wiederherstellungsdauer (RTO) und die Ausfallzeit minimieren, wodurch die Auswirkungen eines Desasters verringert werden.

Lernen Sie mehr:

Weitere Blogbeträge dieser Serie

Weiterführende Informationen

Über den Autor

Seth Eliot

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.