Notfallwiederherstellung mit Umgebungs-Snapshots

Cloud Composer 1 Cloud Composer 2

Auf dieser Seite wird beschrieben, wie Umgebungs-Snapshots für die Notfallwiederherstellung verwendet werden.

Definitionen

In diesem Leitfaden werden die folgenden Definitionen verwendet:

• Ein Notfall ist ein Ereignis, bei dem Cloud Composer oder andere Komponenten, die für den Betrieb Ihrer Umgebung wichtig sind, nicht verfügbar sind. Dieses Ereignis erfordert ein Failover zu einer anderen Region und anderen Cloud Composer-Umgebungen. Die Ursache einer Katastrophe kann natürliche oder von Menschen verursachte Probleme sein, einschließlich Ausfallzeiten von Google Cloud-Regionen und Ausfällen Ihrer eigenen Infrastruktur.
• Die Notfallwiederherstellung (Disaster Recovery, DR) ist im Kontext von Cloud Composer ein Prozess zur Wiederherstellung des Betriebs der Umgebung nach einem Notfall. Dabei wird die Umgebung neu erstellt, möglicherweise in einer anderen Region. Weitere Informationen zur Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
• Die primäre Umgebung ist eine Cloud Composer-Umgebung, für die Sie eine Notfallwiederherstellungsfunktion aktivieren möchten.
• Die Failover-Umgebung ist eine Cloud Composer-Umgebung, die Aktivitäten aus der primären Umgebung übernehmen soll.
• Das Szenario der warmen Notfallwiederherstellung ist eine Variante der Notfallwiederherstellung, bei der Sie eine Standby-Failover-Umgebung verwenden, die Sie vor dem Notfall erstellen.
• Das Kalte DR-Szenario ist eine Variante der Notfallwiederherstellung, bei der Sie nach einem Notfall eine Failover-Umgebung erstellen.
• Die regionenübergreifende Notfallwiederherstellung ist eine Variante der warmen oder kalten Notfallwiederherstellung, bei der sich die primäre und die Failover-Umgebung in verschiedenen Regionen befinden.

Notfallwiederherstellungsverfahren

Das Notfallwiederherstellungsverfahren löst das Problem, wenn Ihre Primärumgebung aufgrund eines Notfalls nicht mehr betriebsbereit (defekt oder anderweitig nicht zugänglich) ist.

Bei diesem Verfahren wird davon ausgegangen, dass Ihre primäre Umgebung nicht an Ort und Stelle repariert wird, um den Notfall zu beheben. Stattdessen erstellen Sie parallel eine zweite Umgebung (Failover). Diese Umgebung wird anstelle der primären Umgebung betrieben. Später können Sie sich dafür entscheiden, zur primären Umgebung zurückzukehren oder weiterhin die Failover-Umgebung zu verwenden.

Da bei diesem Verfahren eine Failover-Umgebung verwendet wird, werden Änderungen eingeführt, wenn Sie von der primären Umgebung wechseln. Zu den Änderungen zwischen der primären Umgebung und der Failover-Umgebung gehören (die Liste ist nicht vollständig):

• Die Webserver-URL wird anders sein. Dadurch wird die Adresse der Airflow-UI und des Airflow REST API-Endpunkt geändert.

• Die Bucket-URL der Umgebung wird anders lauten.

• Die Konfiguration der Netzwerk- und Zugriffsberechtigungen muss möglicherweise angepasst werden.

Wenn Sie das Szenario mit der warmen Notfallwiederherstellung verwenden, kennen Sie die Werte für den Webserver, die Bucket-Adressen der Umgebung und die Netzwerkkonfiguration im Voraus.

Hinweise

• Cloud Composer unterstützt geplante Snapshots ab Version 2.0.32. Umgebungs-Snapshots werden ab Version 2.0.9 unterstützt.

Vorbereitung

Beide DR-Szenarien umfassen die folgenden Vorbereitungsschritte:

1. Erstellen Sie eine Failover-Umgebung.

   • Im Szenario der warmen Notfallwiederherstellung halten Sie diese Umgebung verfügbar.
   • Im kalten DR-Szenario erstellen Sie diese Umgebung nur, um das Notfallwiederherstellungsverfahren zu testen. Nachdem Sie die Vorbereitung abgeschlossen haben, löschen Sie diese Umgebung und erstellen sie nach einem Notfall neu.

2. Bucket für Snapshots erstellen

   • Der Bucket muss in der DR-Region verfügbar sein. Für die regionsübergreifende Notfallwiederherstellung muss der Snapshot-Bucket entweder multiregional sein oder sich in einer anderen Region als die primäre Umgebung befinden.

   • Prüfen Sie, ob DAGs auf regionale Ressourcen zugreifen können.

3. DB-Wartung einrichten

4. Geplante Snapshots einrichten

5. Testen Sie das Notfallwiederherstellungsverfahren.

Notfallwiederherstellung – Übersicht

Nach einem Notfall:

1. (Nur bei der kalten Notfallwiederherstellung) Erstellen Sie eine Failover-Umgebung.
2. Stoppen Sie nach Möglichkeit die Ausführung von DAGs in der primären Umgebung.
3. Laden Sie einen Snapshot aus dem Snapshot-Bucket in die Failover-Umgebung.
4. Passen Sie bei Bedarf die Konfiguration der Failover-Umgebung an.
5. Entscheiden Sie, was mit der primären Umgebung geschehen soll.

Vorbereitungsschritte

Führen Sie die unten beschriebenen Schritte aus, um die Notfallwiederherstellung für Ihre Umgebung einzurichten.

Failover-Umgebung erstellen

Erstellen Sie eine Umgebung, die als Failover-Umgebung dient.

Beachten Sie folgende Richtlinien:

• Die primäre Umgebung und die Failover-Umgebung müssen dieselbe Version von Cloud Composer und Airflow verwenden.

  Achtung: Führen Sie kein Failover zu einer neueren Version von Cloud Composer oder Airflow aus, da dies möglicherweise zusätzliche Änderungen in Bezug auf die Kompatibilität erfordert.

• Achten Sie im Szenario der warmen Notfallwiederherstellung darauf, dass Sie beide Umgebungen synchron aktualisieren und aktualisieren. Wenn Sie beispielsweise die primäre Umgebung auf eine höhere Cloud Composer-Version aktualisieren oder PyPI-Pakete installieren, müssen diese Änderungen auch in der Failover-Umgebung vorgenommen werden.

• Es empfiehlt sich, die Failover-Umgebung in einer anderen Region als der primären Umgebung zu erstellen. Dadurch kann ein breiteres Spektrum möglicher Katastrophenszenarien abgedeckt werden, z. B. eine Katastrophe, die die Verfügbarkeit der gesamten Region beeinträchtigt.

• Wir empfehlen die Verwendung von Terraform zum Erstellen einer primären Umgebung und einer Failover-Umgebung, sodass beide eine konsistente Konfiguration haben. Achten Sie darauf, dass die Terraform-Definitionen für die primäre Umgebung und die Failover-Umgebung synchronisiert sind.

• Es empfiehlt sich, die Konfiguration der Failover-Umgebung (z. B. Umgebungsgröße, Anzahl der Planer und IAM-Berechtigungen) an die Konfiguration der primären Umgebung anzupassen. IAM-Berechtigungen für beide Umgebungen müssen den entsprechenden Zugriff auf Nutzer und Snapshots ermöglichen.

Ressourcenverfügbarkeit prüfen

DAGs können mit externen Ressourcen ausgeführt werden. Der Zugriff auf diese Ressourcen kann von der Konfiguration der Umgebung abhängig sein (z. B. Berechtigungen, die dem Dienstkonto der Umgebung, der Netzwerkkonfiguration oder dem Projekt gewährt wurden). Achten Sie darauf, dass diese Ressourcen für die Failover-Umgebung verfügbar sind.

Eine Umgebung kann über in Airflow gespeicherte Verbindungen mit einigen externen Ressourcen interagieren. Prüfen Sie, ob diese Ressourcen in der Failover-Umgebung und nicht in der primären Umgebung angepasst werden sollten.

Storage-Bucket für Snapshots erstellen

Erstellen Sie einen neuen Storage-Bucket für Umgebungs-Snapshots. Verwenden Sie keine Umgebungs-Buckets für die Notfallwiederherstellung, da die Konfiguration für die Aufbewahrungsrichtlinie und den Lebenszyklus auf Bucket-Ebene angewendet wird.

Achten Sie darauf, dass für diesen Storage-Bucket IAM-Berechtigungen, eine Aufbewahrungsrichtlinie und eine Lebenszykluskonfiguration festgelegt sind, die versehentliches Löschen oder unbefugten Zugriff verhindern. Weitere Informationen zum Konfigurieren eines Buckets für Snapshots finden Sie unter Geplante Snapshots konfigurieren.

Sie können:

• Erstellen Sie einen Bucket in einer anderen Region.
• Erstellen Sie einen multiregionalen Bucket.

Achtung :Wenn Sie einen Bucket in derselben Region wie Ihre primäre Umgebung erstellen, können einige Notfallszenarien nicht abgedeckt werden, z. B. eine Katastrophe, die sich auf die Verfügbarkeit der gesamten Region auswirkt.

Datenbankwartung einrichten

Halten Sie die Airflow-Metadatendatenbank klein, indem Sie den Datenbankwartungs-DAG ausführen. Dies beschleunigt das Speichern und Laden von Snapshots. Die Airflow-Metadatendatenbank muss weniger als 20 GB an Daten haben, um Snapshots zu unterstützen.

Geplante Snapshots einrichten

Richten Sie geplante Snapshots für die primäre Umgebung ein.

Snapshots können nur in einer fehlerfreien Umgebung erstellt werden. Daher müssen Snapshots vor dem Notfall gespeichert werden.

Weitere Informationen zur Funktionsweise von Snapshots finden Sie unter Umgebungs-Snapshots speichern und laden. Informationen zum Speicherort der gespeicherten Snapshots finden Sie im Abschnitt Umgebungs-Snapshot speichern der Dokumentation.

Hinweis: Kontingentlimits ermöglichen bis zu 52 Snapshot-Speichervorgänge pro Tag für eine einzelne Umgebung. Wenn in regelmäßigen Abständen geplante Snapshots erstellt werden sollen, sollte das Intervall zwischen ihnen mindestens 30 Minuten betragen.

(Optional) Monitoring für geplante Snapshot-Vorgänge einrichten

Bei geplanten Snapshots mit einer Häufigkeit von mindestens einmal alle 12 Stunden können Sie Cloud Monitoring verwenden, um Sie zu benachrichtigen, wenn ein Snapshot nicht automatisch erstellt wird.

Bei Zeitplänen mit niedrigerer Häufigkeit prüfen Sie mit der Google Cloud CLI die Ergebnisse von Snapshot-Vorgängen. Weitere Informationen finden Sie unter Speichervorgänge für das Speichern von Snapshots überprüfen.

1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

   Zu Monitoring

2. Wählen Sie im Navigationsbereich „Monitoring“ die Option Benachrichtigungen aus.
3. Wenn Sie keine Benachrichtigungskanäle erstellt haben und Benachrichtigungen erhalten möchten, klicken Sie auf Benachrichtigungskanäle bearbeiten und fügen Sie Benachrichtigungskanäle hinzu. Kehren Sie nach dem Hinzufügen der Kanäle zur Seite Benachrichtigungen zurück.
4. Klicken Sie auf der Seite Benachrichtigungen auf Richtlinie erstellen.
5. Maximieren Sie zum Auswählen des Messwerts das Menü Messwert auswählen und gehen Sie dann so vor:
   1. Um das Menü auf relevante Einträge zu beschränken, geben Sie in die Filterleiste Composer Snapshot ein. Wenn nach dem Filtern des Menüs keine Ergebnisse angezeigt werden, deaktivieren Sie die Option Nur aktive Ressourcen und Messwerte anzeigen.
   2. Wählen Sie als Ressourcentyp die Option Cloud Composer-Umgebung aus.
   3. Wählen Sie als Messwertkategorie die Option Umgebung aus.
   4. Wählen Sie als Messwert die Option Anzahl der Snapshot-Erstellungen aus.
   5. Klicken Sie auf Apply (Anwenden).
6. Klicken Sie auf Filter hinzufügen und fügen Sie über das Drop-down-Menü die folgenden Filter hinzu:

   Filtern	Vergleichsoperator	Wert
   Ressourcenlabel > Umgebungsname	=	Der Name der Umgebung, in der Sie geplante Snapshots überwachen möchten.
   „Monitoring-Label“ > „Ergebnis“	=	SUCCEEDED

7. Legen Sie im Abschnitt Daten transformieren die folgenden Attribute fest:
   • Wählen Sie unter Rollierendes Fenster das Monitoringfenster für diese Benachrichtigung aus. Dieser Wert wirkt sich auf die Schwellenwertkonfiguration im nächsten Schritt aus.

     Empfohlener Wert für das geplante Snapshot-Monitoring: 1 Tag.

   • Wählen Sie für Funktion für rollierende Fenster die Option delta aus.
8. Klicken Sie auf Next (Weiter).
9. Die Einstellungen auf der Seite Benachrichtigungstrigger konfigurieren bestimmen, wann die Benachrichtigung ausgelöst wird. Legen Sie auf dieser Seite die Einstellungen aus der folgenden Tabelle fest.
   

   Feld	Wert
   Condition type	Threshold
   Alert trigger	Any time series violates
   Threshold position	Below threshold
   Threshold value	Die Anzahl der geplanten Snapshots, die voraussichtlich innerhalb des Zeitraums gespeichert werden, der als Rollierendes Fenster für die Benachrichtigung konfiguriert ist. Berechnen Sie diesen Wert mithilfe der folgenden Formel: (rolling window in hours / schedule frequency in hours) - 1 Hinweis: Wenn Sie in der Formel 1 Stunde abziehen, können variierende Zeiten für die Snapshot-Fertigstellung berücksichtigt werden. So wird verhindert, dass falsch positive Ergebnisse ausgegeben werden, wenn der neueste Snapshot während einer Monitoring-Prüfung noch ausgeführt wird. Beispiel: Wenn Sie das empfohlene rollierende Zeitfenster von 1 Tag verwenden und die geplante Häufigkeit einmal alle zwei Stunden beträgt, legen Sie diesen Wert auf 11 fest (Berechnung: 24 / 2 - 1 = 11). Wenn Ihr Zeitplan korrekt ausgeführt wird, sollten Sie in einem 24-Stunden-Fenster mindestens 11 Snapshots haben. Andernfalls wurde ein Snapshot-Vorgang nicht erfolgreich abgeschlossen und Cloud Monitoring löst diese Benachrichtigung aus.
   Condition name	Ihr benutzerdefinierter Name für die Bedingung.

10. Klicken Sie auf Next (Weiter).
11. Optional: Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
12. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
13. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
14. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
15. Klicken Sie auf Richtlinie erstellen.

Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien.

Notfallwiederherstellungsverfahren testen

Testen Sie das Notfallwiederherstellungsverfahren nach der Einrichtung und dann regelmäßig. Auf diese Weise können Sie potenzielle Probleme beheben, die sich auf den tatsächlichen Notfallwiederherstellungsprozess auswirken könnten.

Im kalten DR-Szenario können Sie die Failover-Umgebung löschen, nachdem Sie das Testen des Notfallwiederherstellungsverfahrens abgeschlossen haben.

Snapshot-Speichervorgänge prüfen

Mit der Google Cloud CLI können Sie die Liste der Vorgänge zum Speichern von Snapshots abrufen und überprüfen, ob Ihre Snapshots für Notfallwiederherstellungsszenarien bereit sind.

Diese Methode ist nützlich, wenn Sie Snapshots seltener als einmal alle 12 Stunden speichern. Wenn Sie häufiger gespeicherte Snapshots prüfen möchten, sollten Sie Cloud Monitoring-Benachrichtigungen konfigurieren. Siehe Monitoring für geplante Snapshot-Vorgänge einrichten.

gcloud

Listen Sie alle Snapshot-Vorgänge für eine bestimmte Umgebung auf. Die vollständige Befehlsreferenz finden Sie unter gcloud composeroperations list.

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

Ersetzen Sie:

• LOCATIONS durch die Liste der Regionskennungen, in denen sich die Umgebung befindet
• PROJECT_ID durch die ID des Projekts, in dem sich die Umgebung befindet
• ENVIRONMENT_ID durch die ID der Umgebung, in der Sie Snapshot-Vorgänge prüfen möchten

Beispiel:

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

Nach einer Katastrophe

Führen Sie nach einem Notfall die unten beschriebenen Schritte aus, um Ihre primäre Umgebung wiederherzustellen.

(Nur bei der kalten Notfallwiederherstellung) Eine Failover-Umgebung erstellen

Folgen Sie der Anleitung im Abschnitt Failover-Umgebung erstellen.

Ausführung von DAGs durch die primäre Umgebung beenden

Beenden Sie nach Möglichkeit die Ausführung von DAGs in der primären Umgebung:

• Wenn die primäre Umgebung noch zugänglich ist, pausieren Sie alle DAGs.
• Wenn der Bucket der primären Umgebung zugänglich ist, verschieben Sie alle DAGs aus dem Bucket der Umgebung oder in einen Ordner außerhalb von /dags im Bucket der primären Umgebung.

Snapshot in die Failover-Umgebung laden

Laden Sie einen Snapshot aus der primären Umgebung in die Failover-Umgebung.

Sobald der Snapshot in die Failover-Umgebung geladen wurde, werden Aufgaben so geplant und ausgeführt, als wäre nach dem Erstellen eines Snapshots von der primären Umgebung nichts ausgeführt worden. Einige dieser Aufgaben wurden jedoch möglicherweise bereits von der primären Umgebung ausgeführt. Die Failover-Umgebung kann nicht erkennen, welche Aufgaben nach dem Erstellen des Snapshots und vor einem Notfall ausgeführt wurden. Daher werden einige Aufgaben möglicherweise zweimal ausgeführt (sowohl in der primären Umgebung als auch in der Failover-Umgebung). Wir empfehlen, dass alle Aufgaben idempotent sind und die geplanten Snapshots alle zwei Stunden erstellt werden.

Falls erforderlich: Konfiguration der Failover-Umgebung anpassen

In einigen Fällen möchten Sie möglicherweise die Konfiguration der Failover-Umgebung ändern, nachdem Sie den Snapshot der primären Umgebung in diese geladen haben.

Beispielsweise müssen Sie in einem kalten DR-Szenario möglicherweise einen anderen Satz von Airflow-Umgebungsvariablen in der Failover-Umgebung verwenden. Ein weiteres Beispiel: In einem Szenario der warmen Notfallwiederherstellung müssen Sie Nutzern möglicherweise in der Airflow-UI Berechtigungen erteilen, damit sie auf die Failover-Umgebung zugreifen können.

Sie können diese Änderungen entweder manuell vornehmen oder ein Shell-Skript mit Befehlen vorbereiten, die die Konfiguration der Failover-Umgebung ändern, indem Sie gcloud composer environment update-Befehle ausführen.

Entscheiden Sie, was mit der primären Umgebung geschehen soll

Einige Notfälle können auftreten, wenn die primäre Umgebung nicht erreichbar ist, aber trotzdem funktionsfähig ist oder nicht ordnungsgemäß funktioniert. Sie können beispielsweise aufgrund eines Infrastrukturfehlers nicht über das Netzwerk auf die primäre Umgebung zugreifen. Ein weiteres Beispiel: Die Umgebung arbeitet mit einigen Fehlern oder mit reduzierter Kapazität, aber einige DAGs werden trotzdem ausgeführt.

Wenn die ursprüngliche Umgebung noch ausgeführt wird, können Kosten in direktem Zusammenhang mit Cloud Composer oder anderen Diensten entstehen, auf die über die DAGs zugegriffen wird, obwohl als Ersatz eine neue Umgebung erstellt wurde. Diese Umgebung kann dennoch einige DAGs ausführen. Daher werden einige Vorgänge möglicherweise zweimal ausgeführt: in der primären Umgebung, die noch ausgeführt wird, und in der Failover-Umgebung, nachdem der Snapshot geladen wurde.

Wenn die primäre Umgebung vorhanden ist, aber nicht ordnungsgemäß funktioniert

Die primäre Umgebung kann gelöscht werden, wenn alle relevanten Daten wiederhergestellt wurden. Sie können beispielsweise Daten wiederherstellen, die nicht in den Umgebungs-Snapshots enthalten sind, wie etwa die Netzwerkkonfiguration oder Inhalte des Umgebungs-Buckets außerhalb der Ordner /dags und /plugins.

Wenn die primäre Umgebung wieder zugänglich und fehlerfrei ist

Wenn die primäre Umgebung nur vorübergehend nicht zugänglich war und wieder erreichbar und fehlerfrei war, können Sie einen Ansatz wählen:

• Verwenden Sie weiterhin die Failover-Umgebung.
• Kehren Sie zur primären Umgebung zurück.

So verwenden Sie die Failover-Umgebung weiterhin:

1. Wenn die primäre Umgebung weiterhin DAGs ausführt, pausieren Sie sie so schnell wie möglich.
2. Prüfen Sie, ob alle relevanten Daten wiederhergestellt sind, und löschen Sie dann die primäre Umgebung.
3. Wiederholen Sie die Schritte zur Vorbereitung der Notfallwiederherstellung für die Failover-Umgebung, z. B. das Einrichten geplanter Snapshots.

So kehren Sie zur primären Umgebung zurück:

1. Halten Sie alle DAGs in der Failover-Umgebung an.
2. Warten Sie, bis alle DAG-Ausführungen in der Failover-Umgebung abgeschlossen sind, oder beenden Sie sie.
3. Speichern Sie einen Snapshot der Failover-Umgebung.
4. Laden Sie diesen Snapshot in die primäre Umgebung.
5. Heben Sie die Pausierung der DAGs in der primären Umgebung auf.
6. Löschen Sie bei Bedarf die Failover-Umgebung.

Nächste Schritte

• Geplante Snapshots konfigurieren
• Umgebungen erstellen