Ansätze zur Wiederherstellung im Katastrophenfall

Verschiedene Ansätze oder Strategien für die Wiederherstellung im Katastrophenfall (Disaster Recovery, DR) können einen Disaster Recovery-Plan unterstützen. Je nach Anwendungsfall können Sie diese Ansätze auf der Grundlage der von Ihrem Unternehmen definierten Workloads, Umgebungen, Wiederherstellungszeitziele (RTO) und Wiederherstellungspunktziele (RPO) kombinieren und anpassen.

Sicherung und Wiederherstellung sind der Schlüssel zu jedem Wiederherstellungskonzept. Stellen Sie sicher, dass Sie zumindest eine Sicherungskopie Ihrer Arbeitsdaten erstellen. Gemäß dem Modell der geteilten Verantwortung von IBM Cloud müssen Sie über wiederherstellbare Backups Ihrer Daten verfügen, die im Katastrophenfall wiederhergestellt werden können. Weitere Informationen finden Sie unter Gemeinsame Verantwortung für die Verwendung von IBM Cloud Produkten. Um sicherzustellen, dass Sie wissen, wie Sie auf Sicherungsdateien zugreifen und sie wiederherstellen können, lesen Sie die Dokumentation des jeweiligen Dienstes.

Auf IBM Cloud zu warten, um eine betroffene Region oder einen betroffenen Dienst wiederherzustellen, ist ein gangbarer Weg, aber denken Sie daran, dass dies viele Stunden oder länger dauern kann. In Tabelle 1 finden Sie Informationen zu den verschiedenen DR-Ansätzen, die sich in Bezug auf Wiederherstellungsgeschwindigkeit, Komplexität und Kosten unterscheiden.

Disaster-Recovery-Ansätze und mögliche Workload-Typen, Ausfalltoleranz sowie Kosten und Komplexität der Wartung.
Ansatz	Arbeitslasttyp	Toleranz bei Ausfallzeiten	Kosten und Komplexität
Null Fußabdruck	Unkritisch	Verlängerte Ausfallzeiten	Niedrig
Basis-Standby	Semikritisch	Mehrere Stunden	Mittel
Minimale Bedienung	Semikritisch	Ein paar Stunden	Mittel
Active-Active	Kritische Systeme	Null Ausfallzeit	Hoch

Zero Footprint ist nur für Systeme geeignet, die längere Ausfallzeiten tolerieren, wie z. B. nicht kritische Entwicklungs- und Testumgebungen. Es handelt sich um eine kosteneffiziente Option, die sich auf die Fähigkeit des Cloud Computing stützt, Ressourcen bei Bedarf schnell zu erweitern, anstatt Standby-Systeme zu unterhalten. Basic Standby baut auf dem Zero-Footprint-Ansatz auf, indem einige Komponenten, deren Bereitstellung ansonsten Zeit in Anspruch nehmen kann, vorab erstellt werden. Der Minimalbetrieb ist für Arbeitslasten geeignet, bei denen einige Stunden Ausfallzeit toleriert werden können, was die Gesamtkosten senkt. Entscheidende Systeme, die keine Ausfallzeiten tolerieren, laufen in einer regionenübergreifenden aktiv-aktiv/akitiv-Konfiguration. Die Wartung von Systemen in einer Aktiv/Aktiv-Konfiguration ist mit den meisten Kosten und dem größten Aufwand verbunden. Für Ihren DR-Plan können Sie verschiedene Ansätze kombinieren, um verschiedenen Arbeitslasten gerecht zu werden, insbesondere wenn das Budget begrenzt ist.

Um sich für einen Ansatz zu entscheiden, ist es wichtig zu wissen, ob der Dienst automatisch Sicherungskopien Ihrer Daten erstellt und wie die Sicherungskopien innerhalb des Dienstes erstellt werden. Lesen Sie die Dokumentation jedes Dienstes, um zu erfahren, wo die Backups gespeichert werden, wie Sie die Backups wiederherstellen und wo Sie sie wiederherstellen können.

Wenn der Dienst automatisch Backups Ihrer Daten, einschließlich Snapshots, erstellt, überprüfen Sie, ob diese regionsübergreifend oder in Buckets, die in eine andere Region repliziert werden, gespeichert werden. Wenn ein Dienst nicht automatisch Sicherungskopien erstellt, müssen Sie einen solchen Sicherungsspeicher oder eine Replikation konfigurieren.

Berücksichtigen Sie den Umfang der Wiederherstellung, den Sie für jede spezifische Katastrophe benötigen. Eine Katastrophe kann eine ganze Region oder eine einzelne Dienstinstanz außer Gefecht setzen. Passen Sie Ihren Ansatz an die Szenarien an, für die Sie planen, und stellen Sie sich die folgenden Fragen:

Erlaubt mein Plan die Wiederherstellung eines oder mehrerer isolierter Cloud-Dienste?
Wie flexibel ist mein Arbeitspensum bei Dienststellen, die sich in verschiedenen Regionen befinden?
Wenn ich einen einzelnen Dienst wiederherstelle, wie wirkt sich das auf meine Arbeitslasten aus, muss ich etwas anderes wiederherstellen?
Welche Konfigurationsänderungen könnten innerhalb meiner Anwendungen erforderlich sein, um auf verschiedene Dienstinstanzen zu verweisen, und wie einfach ist es, solche Änderungen vorzunehmen?

Das Durchspielen verschiedener Katastrophenszenarien bereichert Ihre Planung.

Die folgenden DR-Ansätze konzentrieren sich auf VPC- und Datenbankdienste als Beispiele. Die gleichen allgemeinen Grundsätze gelten auch für andere IBM Cloud.

Ansatz 1: Null-Fußabdruck

Ein Null-Fußabdruck-Konzept hat die längste Gesamterholungszeit und das niedrigste Kostenprofil. Für viele Unternehmen ist Zero Footprint für Produktions-Workloads nicht akzeptabel, aber eine gute Wahl für Entwicklungs-, Systemtest- oder andere Workloads, die auf der Liste der Wiederherstellungsprioritäten weit unten stehen.

Zusammenfassung des Null-Fußabdruck-Ansatzes:

In einer zweiten Region gibt es keine Infrastruktur oder Dienstleistungen. Im Falle einer Katastrophe wird alles wiederhergestellt.
Die serverbasierten Daten werden mit einem regionsübergreifenden Snapshot gesichert.
Datenbankdaten werden mit Hilfe von Datenbanksicherungen wiederhergestellt.
Nutzung von Infrastructure as Code über IBM Cloud Schematics zur Bereitstellung Ihrer Umgebung.
Verwenden Sie Toolchains zur Bereitstellung von Anwendungscode.
Geeignet für die am wenigsten strengen RTO- und RPO-Vorgaben, obwohl für bestimmte Datenbanken eine gewisse Unterstützung für die Wiederherstellung zum richtigen Zeitpunkt verfügbar ist.
Ermöglicht die Wiederherstellung von beschädigten Daten.

Um einen genauen und schnelleren Neuaufbau der Umgebung zu ermöglichen, erstellen und verwenden Sie eine Toolchain, die Infrastrukturdienste unter Verwendung von IBM Cloud Schematics bereitstellt. Dann stellen Sie den Code für diese Dienste mithilfe von Git Code-Repositories bereit.

Zur Sicherung und Replikation von Daten, die auf Blockspeicher-Volumes oder Dateispeicher geschrieben werden, verwenden Sie Backup für VPC. Stellen Sie sicher, dass die Sicherung als regionsübergreifende Sicherungs-Snapshots gespeichert wird und die Dateispeicherreplikation aktiv ist.

Eine alternative Methode ist die Bereitstellung und Konfiguration eines Veeam-Agenten auf jedem Server oder eines zentralen Veeam-Backup- und Replikationsservers oder einer ähnlichen "Bring your own"-Sicherungssoftware. Je nach gewähltem Tool ist ein geeigneter Sicherungs- oder Replikationsplan zu erstellen. Wenn Sie sich für die Verwendung von Veeam entscheiden, schreiben Sie die Sicherungsdateien in einen Object Storage Bucket. Der Bucket muss regionenübergreifend sein oder, wenn dies aus Compliance-Gründen erforderlich ist, für die Replikation in einen anderen angegebenen Bucket konfiguriert werden, der in einer zweiten Region der Wahl gehostet wird.

Bei VSIs mit Linux kann der Bucket direkt gemountet werden, indem man s3fs auf der Grundlage von FUSE. Für VSIs, die unter Microsoft Windows laufen, ist Rclone das bevorzugte Tool für die direkte Montage. Rclone ist ein Open-Source-Tool für die Eingabeaufforderung, das zur Verwaltung von Dateien im Cloud-Speicher verwendet wird, einschließlich Object Storage. In jedem Fall wird der Bucket als Netzlaufwerk gemountet und funktioniert ähnlich wie ein freigegebenes Common Internet File System (CIFS) oder Network File System NFS ) Laufwerk. Die Installation des Veeam-Agenten und des Bucket-Mounts kann zum Zeitpunkt der VSI-Bereitstellung durch Skripte automatisiert werden, indem die Benutzerdateneinstellungen verwendet werden. Achten Sie darauf, dass Sie den richtigen Endpunkt für den Bucket verwenden.

Wenn Sie Databases for MySQL, IBM Cloud Databases for PostgreSQL oder IBM Cloud Databases for MongoDB verwenden, ist eine zeitpunktgenaue Wiederherstellung aus Backups möglich. Bei der Point-in-Time-Wiederherstellung werden alle Transaktionsänderungen, die nach einer vollständigen Sicherung auftreten, automatisch in Transaktionsprotokolldateien oder ähnlichem aufgezeichnet. Der Prozess beginnt erneut, wenn die nächste vollständige Sicherung durchgeführt wird. Wenn die Datenbank wiederhergestellt wird, legt der Datenbankadministrator einen Wiederherstellungspunkt innerhalb der letzten 7 Tage fest. Anschließend wird die nächste Vollsicherung vor diesem Zeitpunkt in eine neue Instanz wiederhergestellt. Schließlich werden die aufgezeichneten Transaktionsänderungen bis zu dem festgelegten Zeitpunkt wiedergegeben. Der letzte Zeitpunkt für die Wiederherstellung ist derjenige, an dem die letzte transaktionale Änderung aufgezeichnet wurde und in der Quelldatenbank verfügbar ist. Wiederherstellungen dieser Art werden immer vorwärts gerollt, nicht rückwärts. Sie können keine Sicherungskopie wiederherstellen und durch Rückgängigmachen von Transaktionen zurückgehen. Datenbanken, die keine Point-in-Time-Wiederherstellung bieten, können bis zum Zeitpunkt der letzten Sicherung wiederhergestellt werden. Transaktionsänderungen werden nicht auf sie angewendet, so dass Transaktionen, die nach der Sicherung stattfinden, bei der Wiederherstellung verloren gehen. Backups werden automatisch alle 24 Stunden erstellt, und die Sicherungsdateien werden in einem regionenübergreifenden Object Storage Bucket abgelegt, um Ausfallsicherheit zu gewährleisten. Die Wiederherstellung ist in jeder anderen Multizonenregion möglich, außer über die Grenzen der Erfüllungszone hinweg.

Die Wiederherstellung von Datenbanken kann mehrere Stunden in Anspruch nehmen.

Zusätzlich zu den automatischen Datenbanksicherungen können die Kunden auch On-Demand-Sicherungen durchführen. Alle 24 Stunden wird ein automatisches Backup erstellt. Wenn keine Point-in-Time-Wiederherstellung verfügbar ist, können bei der Wiederherstellung eines täglichen Backups bis zu 24 Stunden an Transaktionen verloren gehen. On-Demand-Backups, die während des 24-Stunden-Zeitraums durchgeführt werden, verringern den Verlust von Transaktionsdaten. On-Demand-Backups können entweder über die Konsole, einen CLI-Aufruf oder über einen API-Aufruf durchgeführt werden. Die Verwendung von CLI- oder API-Aufrufen bedeutet, dass Backups durch einen einfachen Cron-Job automatisiert werden können. Alle On-Demand-Backups werden auch in einen Multi-Region-Bucket Object Storage geschrieben.

Wenn Sie eine andere, eigene Datenbank verwenden, informieren Sie sich in der Produktdokumentation über die am besten geeignete Sicherungsmethode. Sichern Sie die Daten in der Regel in einem regionenübergreifenden Object Storage Bucket, einschließlich aller Protokolle, die eine zeitpunktbezogene Wiederherstellung ermöglichen.

Diagramm zur Darstellung einer Beispielarchitektur für eine Zero-Footprint-DR-Lösung

Ansatz 2: Grundlegende Bereitschaft

Der grundlegende Standby-Ansatz unterscheidet sich von Ansatz 1, weil einige Elemente der DR-Umgebung ausgebaut werden, insbesondere Netzwerkdienste, die eine längere Vorlaufzeit haben. Die ausgebauten Elemente verringern die Gesamt-RTO, wenn DR in Anspruch genommen wird, aber sie verursachen laufende Kosten. Die Kosten für den Basis-Standby-Betrieb sind im Vergleich zur Aufrechterhaltung einer DR-Umgebung mit minimalem Betrieb geringer.

Zusammenfassung des grundlegenden Bereitschaftsdienstkonzepts:

Eine begrenzte Infrastruktur wird in einer zweiten Region bereitgestellt und konfiguriert.
Netzwerkinfrastrukturen mit längeren Vorlaufzeiten wie globale Load Balancer, Direct Link, VPNs oder ähnliches werden bereitgestellt und konfiguriert.
Es wird eine begrenzte Anzahl von VSI-Images erstellt und heruntergefahren, um eine schnellere Wiederherstellung bei minimalen Kosten zu ermöglichen.
Verwenden Sie Autoscaling-Gruppen für eine schnelle Skalierung.
Verwenden Sie Read-Replica-Datenbanken, sofern sie unterstützt werden.
Ein schnellerer RTO im Vergleich zu Ansatz 1, da einige Dienste vorab erstellt werden.

Erwägen Sie die Implementierung von Infrastructure as Code IaC ), um sowohl die Produktions- als auch die DR-Infrastruktur und -Konfiguration bereitzustellen. Speichern und pflegen Sie den IaC in einem einzigen Repository für eine genaue Replikation in der DR-Region. Durch die Abstimmung von Diensten und Konfigurationen in der DR-Region mit der Produktionsregion werden Probleme vermieden, die durch Fehlkonfigurationen verursacht werden und deren Identifizierung und Behebung später viel Zeit in Anspruch nimmt.

Die Laufzeitkosten für Dienste - insbesondere für virtuelle Maschinen -, die bereitgestellt, konfiguriert und dann heruntergefahren werden, können gesenkt werden. Verwenden Sie Instance-Templating und Autoscaling-Techniken, um die erforderliche Workload-Kapazität schnell zu erreichen.

Um Verzögerungen im Zusammenhang mit Vorlaufzeiten zu vermeiden, werden bestimmte Netzwerkelemente bereitgestellt. Zu den Netzwerkelementen gehören Direct Link, die erhebliche Vorlaufzeiten haben können, VPN-Verbindungen und globale Load Balancer. Im Katastrophenfall kann die Konfiguration so eingerichtet werden, dass der Datenverkehr schnell in die DR-Region umgeleitet wird, ohne dass auf der Client-Seite Verbindungsänderungen vorgenommen werden müssen.

Für die Sicherung und Replikation von Daten, die auf Blockspeicher-Volumes oder Dateispeicher geschrieben werden, verwenden Sie wie zuvor Backup für VPC. Stellen Sie sicher, dass die Sicherung als regionsübergreifende Sicherungs-Snapshots gespeichert wird und die Dateispeicherreplikation aktiv ist.

Eine alternative Methode ist die Bereitstellung und Konfiguration eines Veeam-Agenten auf jedem Server oder eines zentralen Veeam-Backup- und Replikationsservers oder einer ähnlichen "Bring your own"-Sicherungssoftware. Je nach gewähltem Tool ist ein geeigneter Sicherungs- oder Replikationsplan zu erstellen. Wenn Sie sich für Veeam entscheiden, schreiben Sie die Backup-Dateien in einen IBM Cloud Object Storage Bucket. Der Bucket muss regionenübergreifend sein oder, wenn dies aus Compliance-Gründen erforderlich ist, für die Replikation in einen anderen angegebenen Bucket konfiguriert werden, der in einer zweiten Region der Wahl gehostet wird.

Für bestimmte IBM Cloud ist es möglich, eine Read-Replica-Datenbank in der für DR ausgewählten Region zu erstellen. Eine Kopie der Datenbank wird automatisch in der zweiten Region aufbewahrt, die im Katastrophenfall in eine eigenständige Kopie umgewandelt werden kann. Read-Replicas bieten einen strengeren RTO, während die asynchrone Replikation aus der Produktionsdatenbank darauf abzielt, jeglichen Verlust von Transaktionsdaten auf unter 15 Minuten zu begrenzen.

Bei anderen IBM Cloud muss die letzte Sicherung auf einer neuen Instanz in der DR-Region wiederhergestellt werden, wobei zu beachten ist, dass einige Datenbanktypen eine Point-in-Time-Wiederherstellung bieten. Bei Datenbanken, die keine Point-in-Time-Wiederherstellung bieten, sollten Sie zusätzlich zur automatischen täglichen Sicherung On-Demand-Sicherungen durchführen, um Datenverluste zu vermeiden. On-Demand-Backups können als Cron-Job geplant werden oder IBM Cloud Code Engine verwenden. Die Wiederherstellung von Datenbanken kann mehrere Stunden oder mehr in Anspruch nehmen, und der Zeitaufwand steigt mit dem Volumen der Datenbank.

In jedem dieser Fälle hängt der Datenverlust vom Zeitpunkt der letzten verfügbaren Datenbanksicherung ab, die bis zu 24 Stunden zurückliegen kann.

Diagramm, das eine Beispielarchitektur für eine grundlegende Standby-DR-Lösung darstellt

Ansatz 3: Minimaler Einsatz

Der Ansatz des Minimalbetriebs unterscheidet sich von Ansatz 2, da ein minimaler Dienst auf dem DR-Standort aufrechterhalten und ausgeführt wird, was die RTO reduziert. Dazu gehören Netzwerkkomponenten wie Direct Link, VPNs und globale Load Balancer, die sonst Vorlaufzeiten von mehreren Tagen haben könnten.

Zusammenfassung des Ansatzes der Minimaloperation:

Eine minimale Infrastruktur wird in einer zweiten Region bereitgestellt, konfiguriert und aktiviert.
Autoscaling wird zur schnellen Bereitstellung von Kapazität verwendet.
Netzwerkinfrastrukturen wie Direct Link, VPN for VPC und globale Load Balancer sind vorhanden.
Daten werden häufig in der DR-Region wiederhergestellt.
Datenbank-Lesereplikate werden, sofern verfügbar, vor Ort erstellt.
Der Minimalbetrieb bietet eine schnellere RTO, da die Dienste laufen und die Daten zumindest teilweise wiederhergestellt sind.

Datensicherungen werden in einer Häufigkeit auf die aktiven DR-Services angewendet, die ein aggressiveres RTO unterstützt. Backups können durch Jobs automatisiert werden, die IBM Cloud Code Engine ausführen.

Im Katastrophenfall wird die Wiederherstellung ausstehender, nicht angewendeter Backups durchgeführt und die Dienste werden auf ein angemessenes Niveau skaliert. Wenn ein Read Replica IBM Cloud Database verwendet wird, wird das Read Replica in eine eigenständige Kopie umgewandelt.

Diagramm, das eine Beispielarchitektur für eine DR-Lösung mit minimalem Betrieb darstellt

Ansatz 4: Aktiv/aktiv

Der Aktiv/Aktiv-Ansatz bedeutet im Grunde, dass zwei Bereitstellungen laufen, von denen jede im täglichen Betrieb verwendet wird. Mit zwei Produktionsregionen wird die Wiederherstellungszeit verkürzt, abgesehen von der Aufstockung der Ressourcen am überlebenden Standort, was jedoch aus Sicht der Daten komplexer ist.

Anwendung des aktiv/aktiv-Ansatzes:

Zwei Regionen sind ausgebaut und werden jeweils aktiv genutzt.
Die Datenbanken führen zwei Kopien, eine pro Region.
Bietet die schnellste RTO, da die Dienste in der zweiten Region ausgeführt werden.
Dieser Ansatz erhöht die Komplexität.

Die Verwaltung von sich ändernden Anwendungsdaten ist der komplexeste Aspekt bei diesem Ansatz. Bei einer echten Aktiv/Aktiv-Bereitstellung sind die Datenbanken in zwei Regionen lesbar und beschreibbar. Um beide Kopien synchron zu halten, müssen die Arbeitslasten des Kunden mithilfe von Anwendungscode verwalten und überprüfen, ob die Schreibvorgänge auf beiden Datenbankinstanzen erfolgreich sind.

Streng genommen ist aktiv/aktiv kein wirklicher Ansatz für die Notfallwiederherstellung. Stattdessen handelt es sich um einen Ansatz zur Gewährleistung einer hohen Verfügbarkeit, bei dem eine IBM Cloud als möglicher Single Point of Failure entfernt wird. Wird ein Ausfall festgestellt, sind Maßnahmen erforderlich, um die Dienste schnell zu skalieren und alle Verbindungsanfragen an die überlebende Region weiterzuleiten.

Diagramm, das eine Beispielarchitektur für eine Active/Active-Lösung darstellt