Leitfaden zur Planung der Notfallwiederherstellung

Last reviewed 2024-07-05 UTC

Dieses Dokument ist der erste Teil einer Reihe, in der die Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloudbehandelt wird. Dieser Teil bietet einen Überblick über den DR-Planungsprozess und vermittelt, was Sie wissen müssen, um einen DR-Plan zu entwerfen und zu implementieren. In den folgenden Abschnitten werden spezifische Anwendungsfälle von DR mit Beispiel-Implementierungen für Google Clouderörtert.

Die Reihe besteht aus folgenden Teilen:

Vorfälle, die den Dienst unterbrechen, können jederzeit geschehen. Ihr Netzwerk könnte von einem Ausfall betroffen sein, mit Ihrem letzten Anwendungs-Push könnte ein kritischer Fehler eingeführt worden sein oder Sie könnten mit einer Naturkatastrophe konfrontiert werden. Für alle möglichen Zwischenfälle es wichtig, einen soliden, zielgerichteten und erprobten DR-Plan zu haben.

Mit einem gut konzipierten und getesteten DR-Plan können Sie gewährleisten, dass im Notfall die Auswirkungen auf das Geschäftsergebnis Ihres Unternehmens minimal sind. Unabhängig von Ihren Anforderungen an die Notfallwiederherstellung bietet Google Cloud eine robuste, flexible und kostengünstige Auswahl an Produkten und Funktionen, mit denen Sie die für Sie passende Lösung erstellen oder erweitern können.

Grundlagen der DR-Planung

DR ist ein Teilbereich der Geschäftskontinuitätsplanung. Die DR-Planung beginnt mit einer Geschäftsauswirkungsanalyse, die zwei Schlüsselmesswerte definiert:

  • Ein Recovery Time Objective (RTO), d. h. die maximal zulässige Zeitspanne, in der Ihre Anwendung offline sein kann. In der Regel wird dieser Wert im Rahmen eines erweiterten Service Level Agreement (SLA) definiert.
  • Ein Recovery Point Objective (RPO), d. h. die maximal zulässige Dauer, während der Daten aufgrund eines größeren Zwischenfalls bei der Anwendung verloren gehen können. Dieser Messwert variiert je nach Verwendungszweck der Daten. Beispielsweise können häufig geänderte Nutzerdaten ein RPO von nur wenigen Minuten haben. Im Gegensatz dazu könnten weniger kritische, selten geänderte Daten ein RPO von mehreren Stunden haben. Dieser Messwert beschreibt nur die Dauer und nicht die Menge oder Qualität der verlorenen Daten.

In der Regel gilt: Je kleiner die RTO- und RPO-Werte sind (d. h. je schneller die Anwendung nach einer Unterbrechung wiederhergestellt werden muss), desto höher sind die Kosten für die Ausführung der Anwendung. Die folgende Grafik zeigt das Verhältnis zwischen den Kosten und den Messwerten RTO/RPO.

Diagramm zur Veranschaulichung, dass kleine RTO-/RPO-Werte hohe Kosten verursachen.

Da kleinere RTO- und RPO-Werte oft mit einer größeren Komplexität einhergehen, folgt der damit verbundene Verwaltungsaufwand einer ähnlichen Kurve. Bei einer Anwendung mit hoher Verfügbarkeit müssen Sie unter Umständen die Verteilung zwischen zwei räumlich voneinander getrennten Rechenzentren, die Replikation und vieles mehr verwalten.

RTO- und RPO-Werte werden in der Regel in einem anderen Messwert zusammengefasst: dem Service Level Objective (SLO), einem wichtigen messbaren Element eines SLA. SLAs und SLOs werden häufig nicht richtig voneinander unterschieden. Ein SLA ist die gesamte Vereinbarung. Sie regelt, welche Dienste erbracht werden sollen, wie sie unterstützt werden, die Zeiten, Orte, Kosten, Leistungen, Strafen sowie die Verantwortlichkeiten der beteiligten Parteien. SLOs hingegen sind spezifische, messbare Eigenschaften des SLA, wie Verfügbarkeit, Durchsatz, Häufigkeit, Reaktionszeit oder Qualität. Ein SLA kann viele SLOs enthalten. RTOs und RPOs sind messbar und sollten als SLOs betrachtet werden.

Weitere Informationen zu SLOs und SLAs finden Sie im Buch „Site Reliability Engineering“ von Google.

Möglicherweise planen Sie auch eine Architektur für Hochverfügbarkeit. HA überschneidet sich nicht vollständig mit DR, muss aber häufig in Überlegungen zu RTO- und RPO-Werten einbezogen werden. HA hilft dabei, eine vereinbarte Betriebsleistung zu gewährleisten, die in der Regel länger als die Standardverfügbarkeit ist. Wenn Sie Produktionsarbeitslasten inGoogle Cloudausführen, verwenden Sie möglicherweise ein global verteiltes System. Wenn dann in einer Region etwas schiefgeht, ist die Anwendung weiterhin verfügbar, auch wenn sie weniger weit verbreitet ist. Im Wesentlichen ruft diese Anwendung hier ihren DR-Plan auf.

Warum Google Cloud?

Google Cloud kann die Kosten im Zusammenhang mit RTO und RPO im Vergleich zur Erfüllung von RTO- und RPO-Anforderungen vor Ort erheblich senken. Bei der DR-Planung müssen Sie beispielsweise eine Reihe von Anforderungen berücksichtigen, darunter:

  • Kapazität: Bereitstellung von ausreichenden Ressourcen für die bedarfsgerechte Skalierung
  • Sicherheit: physische Sicherheit zum Schutz von Assets
  • Netzwerkinfrastruktur: Softwarekomponenten wie Firewalls und Load-Balancer
  • Support: Einsatz qualifizierter Ingenieure für Wartungsarbeiten und zur Problembehebung
  • Bandbreite: Angemessene Bandbreite für Spitzenlasten
  • Anlagen: Physische Infrastruktur wie Ausrüstung und Stromversorgung

Mit einer hochgradig verwalteten Lösung auf einer erstklassigen Produktionsplattform hilft IhnenGoogle Cloud , die meisten oder alle dieser Komplikationen zu vermeiden und dabei viele Geschäftskosten zu senken. Darüber hinaus bedeutet der Fokus von Google Cloudauf die administrative Einfachheit, dass auch die Kosten für die Verwaltung einer komplexen Anwendung reduziert werden.

Google Cloud bietet mehrere Funktionen, die für die Notfallplanung relevant sind, darunter:

  • Ein globales Netzwerk. Google hat eines der größten und fortschrittlichsten Computernetzwerke der Welt. Das Backbonenetzwerk von Google nutzt ein modernes softwarebasiertes Netzwerk und Edge-Caching-Dienste, um eine hohe, konsistente und skalierbare Leistung zu bieten.
  • Redundanz. Zahlreiche Points of Presence (POPs) auf der ganzen Welt sorgen für hohe Redundanz. Ihre Daten werden automatisch auf Speichergeräten an mehreren Standorten gespiegelt.
  • Skalierbarkeit. Google Cloud ist so konzipiert, dass es wie andere Google-Produkte (z. B. die Google Suche und Gmail) skaliert werden kann, selbst wenn es zu einem enormen Traffic-Anstieg kommt. Verwaltete Dienste wie Cloud Run, Compute Engine und Firestore bieten automatisches Skalieren, sodass Ihre Anwendung nach Bedarf wachsen und schrumpfen kann.
  • Sicherheit. Das Sicherheitsmodell von Google basiert auf jahrzehntelanger Erfahrung im Schutz von Kunden in Google-Anwendungen wie Gmail und Google Workspace. Darüber hinaus sorgen die Site-Reliability-Engineering-Teams bei Google für eine hohe Verfügbarkeit und helfen, den Missbrauch von Plattformressourcen zu verhindern.
  • Einhaltung des festgelegten Nutzungsumfangs. Google lässt regelmäßig unabhängige Prüfungen durch Dritte durchführen, um zu bestätigen, dass Google Cloud den Sicherheits-, Datenschutz- und Compliance-Vorschriften sowie den Best Practices entspricht. Google Cloud erfüllt Zertifizierungen wie ISO 27001, SOC 2/3 und PCI-DSS 3.0.

DR-Muster

Bei DR-Mustern wird zwischen sogenannten kalten, warmen und heißen Mustern unterschieden. Diese Mustertypen geben an, wie schnell das System nach einem Fehler wiederhergestellt werden kann. Dies wäre beispielsweise mit dem vergleichbar, was Sie zur Behebung einer Reifenpanne tun würden.

Wie Sie eine solche Reifenpanne beheben, hängt davon ab, wie gut Sie darauf vorbereitet sind:

  • Kalt: Sie haben kein Reserverad, Sie müssen also jemanden anrufen, der mit einem neuen Rad kommt und dieses montiert. Ihre Fahrt ist unterbrochen, bis Hilfe für die Reparatur eintrifft.
  • Warm: Sie haben ein Reserverad und ein Werkzeugset, können also das Rad selbst wechseln und danach weiterfahren. Sie müssen jedoch Ihre Fahrt unterbrechen, um das Problem zu beheben.
  • Heiß: Sie haben Notlaufreifen. Möglicherweise müssen Sie etwas langsamer fahren, aber es hat keine unmittelbaren Auswirkungen auf die Fahrt. Ihre Reifen laufen gut genug, um weiterfahren zu können (obwohl Sie das Problem später beheben müssen).

Detaillierten DR-Plan erstellen

Dieser Abschnitt enthält Empfehlungen zur Erstellung eines DR-Plans.

Entwicklung im Hinblick auf die Wiederherstellungsziele

Beim Entwurf eines DR-Plans müssen Sie Ihre Techniken für die Anwendungs- und Datenwiederherstellung kombinieren und das Gesamtbild betrachten. Als Best Practice gilt im Allgemeinen, hierbei von den RTO- und RPO-Werten sowie dem DR-Muster auszugehen, das Sie verwenden können, um diese Werte zu erreichen. Bei Compliance-relevanten Verlaufsdaten benötigen Sie beispielsweise wahrscheinlich keinen schnellen Zugriff auf die Daten. Daher sind ein hoher RTO-Wert und ein kaltes DR-Muster angemessen. Wenn Ihr Onlinedienst jedoch unterbrochen wird, möchten Sie sowohl die Daten als auch den für Nutzer sichtbaren Teil der Anwendung so schnell wie möglich wiederherstellen können. In diesem Fall wäre daher ein heißes Muster geeigneter. Für Ihr E-Mail-Benachrichtigungssystem, das normalerweise nicht geschäftskritisch ist, reicht wahrscheinlich ein warmes Muster aus.

Anleitungen zur Verwendung von Google Cloud für gängige DR-Szenarien finden Sie in den Szenarien zur Anwendungswiederherstellung. Diese Szenarien bieten gezielte DR-Strategien für eine Vielzahl von Anwendungsfällen und enthalten jeweils Beispielimplementierungen inGoogle Cloud .

Entwicklung im Hinblick auf eine durchgängige Wiederherstellung

Ein Plan für die Sicherung oder Archivierung der Daten allein reicht nicht aus. Der DR-Plan muss den vollständigen Wiederherstellungsprozess abdecken, von der Sicherung über die Wiederherstellung bis zur Bereinigung. Dies wird in den verwandten Dokumenten zu DR-Daten und zur Wiederherstellung noch näher erläutert.

Spezifische Aufgaben gestalten

Wenn der DR-Plan zum Einsatz kommen muss, haben Sie keine Zeit, darüber nachzudenken, was jeder einzelne Schritt bedeutet. Gliedern Sie daher jeden Schritt des DR-Plans im Vorfeld in konkrete, unmissverständliche Befehle oder Aktionen. Die Aktion "Wiederherstellungsskript ausführen" ist beispielsweise zu allgemein formuliert. „Öffnen Sie eine Shell und führen Sie /home/example/restore.sh aus“ ist dagegen präzise und konkret.

Kontrollmaßnahmen umsetzen

Setzen Sie Steuerelemente ein, um Notfällen vorzubeugen und Probleme zu erkennen, bevor sie auftreten. Implementieren Sie beispielsweise ein Überwachungsobjekt, das bei unerwarteten Spitzen oder ungewöhnlicher Aktivität eines datenzerstörenden Flusses, wie etwa einer Lösch-Pipeline, eine Warnmeldung ausgibt. Diese Überwachungsfunktion könnte auch Pipeline-Prozesse beenden, wenn beim Löschen ein bestimmter Grenzwert erreicht wird, um so möglichen Schäden vorzubeugen.

Software vorbereiten

Als weiterer Bestandteil der DR-Planung müssen Sie gewährleisten, dass die Software Ihrer Wahl für ein Wiederherstellungsereignis bereit ist.

Prüfen, ob die Software installiert werden kann

Achten Sie darauf, dass die Anwendungssoftware von der Quelle oder von einem vorkonfigurierten Image installiert werden kann. Achten Sie darauf, dass Sie für jede Software, die Sie in Google Cloudbereitstellen, die entsprechende Lizenz haben. Wenden Sie sich an den Anbieter der Software, um weitere Informationen zu erhalten.

Achten Sie darauf, dass in der Wiederherstellungsumgebung die erforderlichen Compute Engine-Ressourcen verfügbar sind. Dazu müssen Instanzen möglicherweise vorab zugewiesen oder reserviert werden.

Kontinuierliche Bereitstellung für die Wiederherstellung entwerfen

Das Toolset für die kontinuierliche Bereitstellung (Continuous Deployment – CD) ist für die Bereitstellung von Anwendungen eine wichtige Komponente. Berücksichtigen Sie als Teil Ihres Wiederherstellungsplans, wo in der wiederhergestellten Umgebung Artefakte bereitgestellt werden. Planen Sie, wo Sie die CD-Umgebung und Artefakte hosten möchten, diese müssen im Notfall verfügbar und einsatzbereit sein.

Sicherheits- und Compliancekontrollen einrichten

Wenn Sie einen DR-Plan erstellen, ist Sicherheit wichtig. Die Kontrollen, die Sie in Ihrer Produktionsumgebung haben, müssen auch für die wiederhergestellte Umgebung gelten. Compliancevorschriften gelten auch für wiederhergestellte Umgebungen.

Sicherheit für DR- und Produktionsumgebungen identisch konfigurieren

Achten Sie darauf, dass die Netzwerkkontrollen dieselben Trenn- und Sperrfunktionen bieten wie die der Quellproduktionsumgebung. Informieren Sie sich, wie Sie eine gemeinsam genutzte VPC und Firewalls konfigurieren, um eine zentrale Netzwerk- und Sicherheitskontrolle für die Bereitstellung einzurichten, Subnetze zu konfigurieren und eingehenden und ausgehenden Traffic zu steuern. Informieren Sie sich ferner, wie Sie Dienstkonten nutzen, um die jeweils nur geringsten Berechtigungen für Anwendungen zu implementieren, die auf Google Cloud -APIs zugreifen. Achten Sie auch darauf, die Dienstkonten als Teil der Firewallregeln zu verwenden.

Gewähren Sie Nutzern den gleichen Zugriff auf die DR-Umgebung, den sie auch in der Quellproduktionsumgebung haben. In der folgenden Liste werden Möglichkeiten zum Synchronisieren von Berechtigungen zwischen Umgebungen beschrieben:

  • Wenn Ihre Produktionsumgebung Google Cloudist, ist das Replizieren von IAM-Richtlinien in der DR-Umgebung unkompliziert. Sie können Infrastruktur als Code (IaC)-Tools wie Terraform verwenden, um IAM-Richtlinien für die Produktion bereitzustellen. Dieselben Tools verwenden Sie, um die Richtlinien mit den entsprechenden Ressourcen beim Aufbau der DR-Umgebung zu verknüpfen.

  • Bei einer lokalen Produktionsumgebung ordnen Sie die funktionalen Rollen, wie die des Netzwerkadministrators und Prüfers, den IAM-Richtlinien mit den entsprechenden IAM-Rollen zu. In der IAM-Dokumentation finden Sie einige Beispiele für funktionale Rollenkonfigurationen, z. B. die Dokumentation zum Erstellen von funktionalen Rollen für Netzwerke und Audit-Logging.

  • Sie müssen IAM-Richtlinien konfigurieren, um den Produkten die korrekten Berechtigungen zu gewähren. Beispielsweise möchten Sie möglicherweise den Zugriff auf bestimmte Cloud Storage-Buckets beschränken.

  • Wenn Ihre Produktionsumgebung von einem anderen Cloud-Anbieter gehostet wird, ordnen Sie die IAM-Berechtigungen des Anbieters den IAM-Richtlinien von Google Cloud zu.

DR-Sicherheit prüfen

Testen Sie alles, nachdem Sie die Berechtigungen für die DR-Umgebung konfiguriert haben. Erstellen Sie eine Testumgebung. Achten Sie darauf, dass die Berechtigungen, die Sie Nutzern gewähren, mit den Berechtigungen übereinstimmen, die die Nutzer lokal haben.

Zugriff von Nutzern auf DR-Umgebung sicherstellen

Warten Sie nicht, bis ein Notfall tatsächlich eintritt, sondern prüfen Sie vorher, ob Nutzer auf die DR-Umgebung zugreifen können. Achten Sie darauf, dass Sie Nutzern, Entwicklern, Betreibern, Data Scientists, Sicherheitsadministratoren, Netzwerkadministratoren und anderen Rollen in Ihrer Organisation die entsprechenden Zugriffsrechte erteilt haben. Wenn Sie ein alternatives Identitätssystem verwenden, müssen die Konten mit Ihrem Cloud Identity-Konto synchronisiert werden. Da die DR-Umgebung für eine Weile Ihre Produktionsumgebung sein wird, sollten Sie die Nutzer, die Zugriff auf die DR-Umgebung benötigen, bitten, sich anzumelden, und alle Authentifizierungsprobleme beheben. Beziehen Sie Nutzer, die sich in der DR-Umgebung anmelden, in die regelmäßigen DR-Tests ein, die Sie implementieren.

Wenn Sie zentral verwalten möchten, wer Administratorzugriff auf gestartete virtuelle Maschinen (VMs) hat, aktivieren Sie die Funktion OS Login für die Google Cloud -Projekte, die Ihre DR-Umgebung bilden.

Nutzer schulen

Nutzer müssen wissen, wie sie die Aktionen in Google Cloud ausführen, die sie in der Produktionsumgebung gewohnt sind, z. B. sich anmelden und auf VMs zugreifen. In der Testumgebung können Sie Ihren Nutzern zeigen, wie sie diese Aufgaben so ausführen, dass die Sicherheit Ihres Systems gewährleistet ist.

Prüfen, ob die DR-Umgebung die Complianceanforderungen erfüllt

Achten Sie darauf, dass nur die Personen Zugriff auf die DR-Umgebung erhalten, die ihn effektiv benötigen. Die PII-Daten müssen geändert und verschlüsselt werden. Wenn Sie in Ihrer Produktionsumgebung regelmäßig Penetrationstests durchführen, sollten Sie auch die DR-Umgebung in dieses Verfahren einbeziehen und während des Aufbaus der DR-Umgebung regelmäßige Tests machen.

Achten Sie darauf, dass Logs, die während des Betriebs der DR-Umgebung erstellt werden, auch in das Log-Archiv Ihrer Produktionsumgebung übertragen werden. Achten Sie außerdem darauf, dass Sie im Rahmen Ihrer DR-Umgebung Audit-Logs, die über Cloud Logging erfasst werden, in Ihr Hauptarchiv für Logsenken exportieren können. Verwenden Sie hierzu die Funktionen für Exportsenken. Spiegeln Sie die Anwendungs-Logs aus der lokalen Logging- und Überwachungsumgebung. Wenn Ihre Produktionsumgebung von einem anderen Cloud-Anbieter gehostet wird, ordnen Sie das Logging und Monitoring dieses Anbieters den entsprechenden Diensten von Google Cloud zu. Implementieren Sie ein Verfahren zum Formatieren von Eingaben in der Produktionsumgebung.

Wiederhergestellte Daten wie Produktionsdaten behandeln

Die Sicherheitskontrollen, die Sie an Produktionsdaten vornehmen, müssen auch auf die wiederhergestellten Daten angewendet werden. Für Berechtigungen, Verschlüsselung und Überwachung gelten die gleichen Berechtigungen.

Ermitteln Sie, wo sich Ihre Sicherungskopien befinden und wer berechtigt ist, Daten wiederherzustellen. Der Wiederherstellungsprozess muss überprüfbar sein. Nach einer Notfallwiederherstellung müssen Sie sehen können, wer auf die Sicherungsdaten zugreifen konnte und wer die Wiederherstellung durchgeführt hat.

DR-Plan auf korrekte Funktion prüfen

Achten Sie darauf, dass der DR-Plan wie vorgesehen funktioniert.

Mehr als einen Datenwiederherstellungspfad pflegen

Im Notfall ist Ihre Verbindungsmethode zu Google Cloud möglicherweise nicht mehr verfügbar. Implementieren Sie eine alternative Zugriffsmethode aufGoogle Cloud , damit Sie Daten anGoogle Cloudübertragen können. Testen Sie regelmäßig, ob der Sicherungspfad funktioniert.

Plan regelmäßig testen

Nachdem Sie einen DR-Plan erstellt haben, sollten Sie diesen regelmäßig testen, eventuell aufgetretene Probleme beachten und den Plan entsprechend anpassen. Mit Google Cloudkönnen Sie Wiederherstellungsszenarien besonders kostengünstig testen. Folgende empfohlene Maßnahmen unterstützen Sie beim Testen:

  • Infrastrukturbereitstellung automatisieren. Sie können IaC-Tools wie Terraform verwenden, um die Bereitstellung Ihrer Google Cloud-Infrastruktur zu automatisieren. Bei einer lokalen Produktionsumgebung benötigen Sie ein Monitoringverfahren, das bei Erkennung eines Fehlers den DR-Prozess starten und die entsprechenden Wiederherstellungsaktionen auslösen kann.
  • Umgebungen mit Google Cloud Observability überwachen. Google Cloud bietet hervorragende Logging- und Monitoring-Tools, auf die Sie über API-Aufrufe zugreifen können. So können Sie die Bereitstellung von Wiederherstellungsszenarien automatisieren, indem Sie auf Messwerte reagieren. Achten Sie auch beim Entwurf der Tests darauf, dass Überwachungs- und Benachrichtigungsfunktionen verfügbar sind, die geeignete Wiederherstellungsaktionen auslösen können.

  • Den zuvor beschriebenen Test machen:

    • Testen Sie, ob Berechtigungen und Nutzerzugriff in der DR-Umgebung wie in der Produktionsumgebung funktionieren.
    • Führen Sie Penetrationstests in der DR-Umgebung durch.
    • Führen Sie einen Test durch, bei dem Ihr üblicher Zugriffspfad auf Google Cloudnicht funktioniert.

Nächste Schritte

Beitragende

Autoren: