Notfallwiederherstellung mit Umgebungs-Snapshots

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Auf dieser Seite wird beschrieben, wie Sie Umgebungs-Snapshots für Notfallwiederherstellung.

Definitionen

In diesem Leitfaden werden die folgenden Definitionen verwendet:

• Ein Notfall ist ein Ereignis, bei dem Cloud Composer oder andere für den Betrieb Ihrer Umgebung wichtige Komponenten nicht verfügbar sind. Für dieses Ereignis ist ein Failover zu einer anderen Region und Cloud Composer-Umgebung erforderlich. Eine Katastrophe kann natürlich oder von Menschen verursacht worden sein. einschließlich Ausfallzeiten von Google Cloud-Regionen und eigenen Ausfällen und Infrastruktur.
• Die Notfallwiederherstellung (Disaster Recovery, DR) ist im Kontext von Cloud Composer ein Prozess, bei dem der Betrieb der Umgebung nach einem Notfall wiederhergestellt wird. Dabei wird die Umgebung möglicherweise in einer anderen Region neu erstellt. Weitere Informationen zur Notfallwiederherstellung finden Sie unter Leitfaden zur Planung der Notfallwiederherstellung
• Die primäre Umgebung ist eine Cloud Composer-Umgebung, für die Sie eine Notfallwiederherstellung aktivieren möchten.
• Die Failover-Umgebung ist eine Cloud Composer-Umgebung, um Aktivitäten aus der primären Umgebung zu übernehmen.
• Ein Warm-DR-Szenario ist eine Variante der Notfallwiederherstellung, bei der Sie eine Standby-Failover-Umgebung verwenden, die Sie vor einem Notfall erstellen.
• Ein Kaltes DR-Szenario ist eine Variante der Notfallwiederherstellung, bei der Sie eine Failover-Umgebung nach einem Notfall.
• Die regionenübergreifende Notfallwiederherstellung ist eine Variante der Warm- oder Cold-Site-Wiederherstellung, bei der sich die primäre und die Failover-Umgebung in verschiedenen Regionen befinden.

Informationen zum Notfallwiederherstellungsverfahren

Das Notfallwiederherstellungsverfahren behebt das Problem, wenn Ihre primäre die Umgebung nicht mehr funktioniert (defekt oder anderweitig nicht zugänglich), bei einer Katastrophe.

Bei diesem Verfahren wird davon ausgegangen, dass Ihre primäre Umgebung nicht repariert wird. zur Bekämpfung der Katastrophe. Stattdessen erstellen Sie parallel eine zweite (Failover-)Umgebung. Diese Umgebung wird anstelle der primären Umgebung zu verbessern. Später können Sie sich entscheiden, zur primären Umgebung zurückzukehren oder die Failover-Umgebung weiter zu verwenden.

Da bei diesem Verfahren eine Failover-Umgebung verwendet wird, werden Änderungen vorgenommen, wenn Sie von der primären Umgebung wechseln. Änderungen zwischen Primär- und Folgendes enthält die Failover-Umgebung (die Liste ist nicht vollständig):

• Die Webserver-URL ist anders. Dadurch ändert sich die Adresse der Airflow-Benutzeroberfläche und des Airflow REST API-Endpunkts.

• Die Bucket-URL der Umgebung ist unterschiedlich.

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

Wenn Sie das Warm-DR-Szenario 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 in Version 2.0.9 und höher unterstützt.

• Die Airflow-Datenbank muss weniger als 20 GB Daten zum Erstellen von Snapshots.

• Die Gesamtzahl der Objekte in den Ordnern /dags, /plugins und /data im Bucket der Umgebung muss unter 100.000 liegen, damit Snapshots erstellt werden können.

• Wenn Sie den XCom-Mechanismus zum Übertragen von Dateien verwenden, achten Sie darauf, dass Sie ihn gemäß den Airflow-Richtlinien verwenden. Die Übertragung großer Dateien oder einer großen Anzahl von Dateien mit XCom wirkt sich auf Die Leistung der Airflow-Datenbank und kann zu Fehlern beim Laden führen oder ein Upgrade Ihrer Umgebung durchführen. Erwägen Sie die Verwendung von Alternativen wie wie Cloud Storage, um große Datenmengen zu übertragen.

Vorbereitung – Übersicht

Für beide Notfallwiederherstellungsszenarien sind die folgenden Vorbereitungsschritte erforderlich:

1. Failover-Umgebung erstellen

   • Im Warm-DR-Szenario halten Sie diese Umgebung verfügbar.
   • Im kalten DR-Szenario erstellen Sie diese Umgebung nur, um Disaster Recovery-Verfahren. Nachdem Sie die Vorbereitung abgeschlossen haben, löschen Sie diese Umgebung und erstellen sie nach einem Notfall wieder.

2. Bucket für Snapshots erstellen

   • Der Bucket muss in der DR-Region verfügbar sein. Bei der regionenübergreifenden Notfallwiederherstellung muss der Bucket für Snapshots 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. Datenbankwartung einrichten

4. Geplante Snapshots einrichten

5. Testen Sie Ihr Notfallwiederherstellungsverfahren.

Notfallwiederherstellung – Übersicht

Nach einem Notfall:

1. (Nur Kalt-DR) Erstellen Sie eine Failover-Umgebung.
2. Beenden 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. Falls erforderlich: Konfiguration der Failover-Umgebung anpassen
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:

• Ihre primäre und Failover-Umgebung muss dieselbe Version von Cloud Composer und Airflow.

  Achtung: Führen Sie kein Failover auf eine neuere Version von Cloud Composer oder Airflow, da hierfür möglicherweise zusätzliche Änderungen in Bezug auf die Kompatibilität.

• Bei einem warmen DR-Szenario sollten Sie Aktualisieren und Führen Sie ein Upgrade für beide Umgebungen gleichzeitig aus. Wenn Sie beispielsweise Upgrade der primären Umgebung auf eine neuere Cloud Composer-Umgebung durchführen oder PyPI-Pakete installieren, muss auch Ihre Failover-Umgebung die diese Änderungen haben.

• Wir empfehlen, die Failover-Umgebung in einer anderen Region als der Primärumgebung. Dies hat zur Folge, dass mehr und mehr Szenarien abgedeckt werden, wie etwa eine Katastrophe, die die Verfügbarkeit der gesamten Region.

• Wir empfehlen, mit Terraform primäre und Failover-Umgebungen zu erstellen, damit beide eine einheitliche Konfiguration haben. Die Terraform-Definitionen für die primäre und die Failover-Umgebung müssen synchronisiert sein.

• Die Konfiguration der Failover-Umgebung (z. B. Umgebungsgröße, Anzahl der Scheduler und IAM-Berechtigungen) sollte der Konfiguration der primären Umgebung entsprechen. IAM-Berechtigungen für beide Umgebungen müssen Nutzern und Snapshots den entsprechenden Zugriff gewähren.

Ressourcenverfügbarkeit prüfen

DAGs können auf externen Ressourcen ausgeführt werden. Der Zugriff auf diese Ressourcen ist möglicherweise von der Konfiguration der Umgebung abhängig (z. B. Berechtigungen, das Dienstkonto, die Netzwerkkonfiguration oder das Projekt der Umgebung). 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 ob diese Ressourcen in der Failover-Umgebung der primären Umgebung.

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 dieser Storage-Bucket IAM-Berechtigungen hat, Aufbewahrungsrichtlinie und eine Lebenszykluskonfiguration so festgelegt sind, dass versehentlichem Löschen oder unbefugtem Zugriff. Weitere Informationen zu Konfigurieren eines Buckets für Snapshots finden Sie unter Geplante Snapshots konfigurieren

Sie haben folgende Möglichkeiten:

• 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. ein Notfall, der sich auf die Verfügbarkeit der gesamten Region auswirkt.

Datenbankwartung einrichten

Sorgen Sie dafür, dass die Airflow-Datenbank klein bleibt und die Größenbeschränkung nicht überschreitet, indem Sie eine Datenbankbereinigung einrichten. Dadurch wird das Speichern und Laden von Snapshots beschleunigt. Die Airflow-Datenbank darf maximal 20 GB an Daten enthalten, um Snapshots zu erstellen.

Geplante Snapshots einrichten

Richten Sie geplante Snapshots für die primäre Instanz ein. zu verbessern.

Snapshots können nur in einer fehlerfreien Umgebung erstellt werden. Deshalb müssen Snapshots vor der Katastrophe gerettet werden.

Weitere Informationen zur Funktionsweise von Snapshots finden Sie unter Umgebungs-Snapshots speichern und laden. Informationen dazu, wo Sie die gespeicherten Snapshots finden, finden Sie im Abschnitt Umgebungs-Snapshot speichern der Dokumentation.

Hinweis: Mit Kontingentlimits können Sie täglich bis zu 52 Snapshot-Vorgänge speichern. für eine einzelne Umgebung. Wenn Sie geplante Snapshots in regelmäßigen Abständen erstellen möchten, sollte das Intervall zwischen ihnen mindestens 30 Minuten betragen.

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

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

Bei Zeitplänen mit geringerer Häufigkeit verwenden Sie die Google Cloud CLI, um die Ergebnisse von Snapshot-Vorgängen zu prüfen. Siehe Speichern von Snapshot-Vorgängen ü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 unter Messwertkategorie die Option Umgebung aus.
   4. Wählen Sie als Messwert Anzahl der Snapshot-Erstellungen aus.
   5. Klicken Sie auf Apply (Anwenden).
6. Klicken Sie auf Filter hinzufügen und fügen Sie über die Drop-down-Menüs die folgenden Filter hinzu:

   Filter	Vergleichsoperator	Wert
   Ressourcenlabel > environment_name	=	Der Name der Umgebung, in der Sie geplante Snapshots überwachen möchten.
   Monitor-Label > Ergebnis	=	SUCCEEDED

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

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

   • Wählen Sie für Funktion für rollierendes Zeitfenster die Option Delta aus.
8. Klicken Sie auf 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 innerhalb des für die Benachrichtigung konfigurierten Rollierenden Fensters gespeichert werden sollen. Berechnen Sie diesen Wert mit der folgenden Formel: (rolling window in hours / schedule frequency in hours) - 1 Hinweis: Durch die Abzug von 1 Stunden in der Formel werden unterschiedliche Abschlusszeiten für Snapshots berücksichtigt. So wird verhindert, dass Fehlalarme auftreten, wenn der aktuelle 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 2 Stunden festgelegt ist, legen Sie diesen Wert auf 11 fest (gemäß Berechnung: 24 / 2 - 1 = 11). Wenn Ihr Zeitplan korrekt ausgeführt wird, sollte mindestens 11 Snapshots haben. Andernfalls wurde ein Snapshot-Vorgang nicht abgeschlossen. Cloud Monitoring löst diese Benachrichtigung aus.
   Condition name	Ihr benutzerdefinierter Name für die Bedingung.

10. Klicken Sie auf 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 Einführung in Benachrichtigungen.

Verfahren zur Notfallwiederherstellung testen

Testen Sie Ihr Notfallwiederherstellungsverfahren nach der Einrichtung und dann regelmäßig. So können Sie potenzielle Probleme auf den Notfallwiederherstellungsprozess auswirken.

Im kalten DR-Szenario können Sie die Failover-Umgebung löschen, den Test der Notfallwiederherstellung abschließen.

Speichervorgänge für Snapshots prüfen

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

Diese Methode ist nützlich, wenn Sie Snapshots seltener als mindestens einmal alle 12 Stunden speichern. Wenn Sie häufiger Snapshots überprüfen möchten, die häufiger gespeichert werden, konfigurieren Sie am besten Cloud Monitoring-Benachrichtigungen Weitere Informationen finden Sie unter Monitoring für geplante Snapshot-Vorgänge einrichten

gcloud

Listen Sie alle Snapshot-Vorgänge für eine bestimmte Umgebung auf. Eine vollständige Befehlsreferenz finden Sie unter gcloud composer operations 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 gelegen
• PROJECT_ID durch die Kennung 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 einem Notfall

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

(Nur kalte Notfallwiederherstellung) Failover-Umgebung erstellen

Folgen Sie der Anleitung im Abschnitt Failover-Umgebung erstellen.

Ausführung von DAGs in der primären Umgebung beenden

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

• Wenn die primäre Umgebung weiterhin zugänglich ist, pausieren Sie alle DAGs.
• Wenn auf den Bucket der primären Umgebung zugegriffen werden kann, 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, Aufgaben so ausführen, als wäre nichts in der primären Umgebung ausgeführt worden, nachdem Erstellen eines Snapshots Einige dieser Aufgaben die in der primären Umgebung ausgeführt werden. Die Failover-Umgebung hat keine Sie erkennen, welche Aufgaben nach dem Erstellen des Snapshots ausgeführt wurden. und vor einer Katastrophe. Daher werden einige Aufgaben möglicherweise zweimal ausgeführt (in beiden der primären und der Failover-Umgebung). Wir empfehlen, dass alle Aufgaben idempotent sind und die geplanten Snapshots alle zwei Stunden erstellt.

(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 sie geladen haben.

Bei einem kalten DR-Szenario müssen Sie beispielsweise Airflow-Umgebungsvariablen in der Failover-Umgebung. In einem Warm-DR-Szenario müssen Sie Nutzern beispielsweise in der Airflow-Benutzeroberfläche Berechtigungen erteilen, damit sie auf die Failover-Umgebung zugreifen können.

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

Festlegen, was mit der primären Umgebung geschehen soll

Es kann zu Katastrophen kommen, weil die primäre Umgebung nicht erreichbar ist. funktioniert aber nicht ordnungsgemäß. Sie können beispielsweise nicht Sie greifen aufgrund einer Infrastruktur über das Netzwerk auf die primäre Umgebung zu. Fehler. Ein weiteres Beispiel: Die Umgebung funktioniert zwar mit einigen Fehlern oder mit reduzierter Kapazität, aber einige DAGs werden trotzdem ausgeführt.

Wenn die ursprüngliche Umgebung noch ausgeführt wird, Kosten generieren, die direkt mit Cloud Composer oder anderen Diensten in Verbindung stehen über die DAGs aufgerufen werden kann, obwohl eine neue Umgebung als oder ein Ersatzgerät zu erhalten. In dieser Umgebung können noch einige DAGs ausgeführt werden. Daher werden einige Vorgänge können zweimal ausgeführt werden: in der primären Umgebung, die noch nach dem Laden des Snapshots in der Failover-Umgebung ausgeführt wird.

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. Beispielsweise können Sie Daten wiederherstellen, die nicht in den Umgebungs-Snapshots enthalten sind, z. B. die Netzwerkkonfiguration oder den Inhalt des Umgebungs-Buckets außerhalb der Ordner /dags und /plugins.

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

Wenn die primäre Umgebung nur vorübergehend nicht zugänglich war und wieder zugänglich und fehlerfrei ist, haben Sie folgende Möglichkeiten:

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

So verwenden Sie die Failover-Umgebung weiterhin:

1. Wenn in der primären Umgebung noch DAGs ausgeführt werden, pausieren Sie sie so bald wie möglich.
2. Achten Sie darauf, dass alle relevanten Daten wiederhergestellt sind, und löschen Sie dann die primäre Umgebung.
3. Wiederholen Sie die Schritte zur Notfallwiederherstellung für die Failover-Umgebung, z. B. die Einrichtung geplanter Snapshots.

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

1. Pausieren Sie alle DAGs in der Failover-Umgebung.
2. Warten Sie, bis alle DAG-Ausführungen in der Failover-Umgebung abgeschlossen sind, oder beenden Sie sie.
3. Snapshot der Failover-Umgebung speichern
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