Notfallwiederherstellung mit Umgebungs-Snapshots

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Auf dieser Seite wird beschrieben, wie Sie Umgebungssnapshots für die Notfallwiederherstellung verwenden.

Definitionen

In diesem Leitfaden werden die folgenden Definitionen verwendet:

• Ein Desaster 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. Die Ursache einer Katastrophe kann natürlich oder vom Menschen verursacht sein, einschließlich Ausfallzeiten von Google Cloud -Regionen und Ausfällen in Ihrer eigenen Infrastruktur.
• Notfallwiederherstellung (Disaster Recovery, DR) ist im Kontext von Cloud Composer ein Prozess zur Wiederherstellung des Betriebs der Umgebung nach einem Notfall. Dazu muss die Umgebung neu erstellt werden, möglicherweise in einer anderen Region. Weitere Informationen zur Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
• Eine primäre Umgebung ist eine Cloud Composer-Umgebung, für die Sie eine DR-Funktion aktivieren möchten.
• Eine Failover-Umgebung ist eine Cloud Composer-Umgebung, die dafür vorgesehen ist, Aktivitäten aus der primären Umgebung zu übernehmen.
• Das Warm-DR-Szenario ist eine Variante der Notfallwiederherstellung, bei der Sie eine Standby-Failover-Umgebung verwenden, die Sie vor einem Notfall erstellen.
• Das Cold-DR-Szenario ist eine Variante der Notfallwiederherstellung, bei der Sie nach einem Notfall eine Failover-Umgebung erstellen.
• Regionenübergreifende Notfallwiederherstellung ist eine Variante der warmen oder kalten Notfallwiederherstellung, bei der sich die primäre Umgebung und die Failover-Umgebung in verschiedenen Regionen befinden.

Informationen zum Notfallwiederherstellungsprozess

Das Notfallwiederherstellungsverfahren löst das Problem, wenn Ihre primäre Umgebung aufgrund einer Katastrophe nicht mehr betriebsbereit ist (defekt oder anderweitig nicht zugänglich).

Bei diesem Verfahren wird davon ausgegangen, dass Ihre primäre Umgebung nicht vor Ort repariert wird, um die Katastrophe zu beheben. Stattdessen erstellen Sie eine zweite (Failover-)Umgebung. Diese Umgebung wird anstelle der primären Umgebung verwendet. Später können Sie zur primären Umgebung zurückkehren oder die Failover-Umgebung weiterhin verwenden.

Da bei dem 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 und der Failover-Umgebung gehören (die Liste ist nicht vollständig):

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

• Die Bucket-URL der Umgebung ist anders.

• Möglicherweise müssen Sie die Konfiguration der Netzwerk- und Zugriffsberechtigungen anpassen.

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

• Die Airflow-Datenbank darf nicht mehr als 20 GB Daten enthalten, damit Snapshots erstellt werden können.

• Die Gesamtzahl der Objekte in den Ordnern /dags, /plugins und /data im Bucket der Umgebung muss kleiner als 100.000 sein,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 aus und kann zu Fehlern beim Laden von Snapshots oder beim Aktualisieren Ihrer Umgebung führen. Erwägen Sie die Verwendung von Alternativen wie Cloud Storage, um große Datenmengen zu übertragen.

Übersicht zur Vorbereitung

Beide DR-Szenarien umfassen die folgenden Vorbereitungsschritte:

1. Failover-Umgebung erstellen

   • Im Warm-DR-Szenario bleibt diese Umgebung verfügbar.
   • Im kalten DR-Szenario erstellen Sie diese Umgebung nur, um Ihr Verfahren zur Notfallwiederherstellung zu testen. 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. 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. Datenbankwartung einrichten

4. Geplante Snapshots einrichten

5. Notfallwiederherstellungsverfahren testen

Notfallwiederherstellung – Übersicht

Nach einem Notfall:

1. (Nur Cold-DR) Failover-Umgebung erstellen
2. Verhindern Sie nach Möglichkeit, dass in der primären Umgebung DAGs ausgeführt werden.
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:

• Ihre primäre Umgebung und Ihre Failover-Umgebung müssen dieselbe Version und denselben Build von Airflow verwenden.

• Achten Sie im Warm-DR-Szenario darauf, dass Sie beide Umgebungen synchron aktualisieren und upgraden. Wenn Sie beispielsweise die primäre Umgebung auf einen späteren Airflow-Build aktualisieren oder PyPI-Pakete installieren, muss Ihre Failover-Umgebung diese Änderungen ebenfalls enthalten.

• Wir empfehlen, die Failover-Umgebung in einer anderen Region als die primäre Umgebung zu erstellen. So kann ein breiteres Spektrum möglicher Katastrophenszenarien abgedeckt werden, z. B. eine Katastrophe, die sich auf die Verfügbarkeit der gesamten Region auswirkt.

• Wir empfehlen, primäre und Failover-Umgebungen mit Terraform zu erstellen, damit beide eine konsistente Konfiguration haben. Achten Sie darauf, dass die Terraform-Definitionen für die primäre Umgebung und die Failover-Umgebung synchronisiert sind.

• 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 externe Ressourcen zugreifen. Der Zugriff auf diese Ressourcen hängt möglicherweise von der Konfiguration der Umgebung ab, z. B. von Berechtigungen, die dem Dienstkonto der Umgebung erteilt wurden, von der Netzwerkkonfiguration oder vom Projekt. Achten Sie darauf, dass diese Ressourcen in der 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 im Vergleich zur primären Umgebung angepasst werden müssen.

Storage-Bucket für Snapshots erstellen

Erstellen Sie einen neuen Storage-Bucket für Umgebungssnapshots. 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 Speicher-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 haben folgende Möglichkeiten:

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

Datenbankwartung einrichten

Halten Sie die Airflow-Datenbank klein und innerhalb des Größenlimits, indem Sie die Datenbankbereinigung einrichten. Dadurch wird das Speichern und Laden von Snapshots beschleunigt. Die Airflow-Datenbank darf weniger als 20 GB Daten enthalten, damit Snapshots erstellt werden können.

Geplante Snapshots einrichten

Geplante Snapshots für die primäre Umgebung einrichten.

Snapshots können nur in einer fehlerfreien Umgebung erstellt werden. Sie müssen also gespeichert werden, bevor es zu einem Notfall kommt.

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

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. Weitere Informationen finden Sie unter Vorgänge zum Speichern von Snapshots bestätigen.

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

   Zu Monitoring

2. Wählen Sie im Navigationsbereich „Monitoring“ die Option notificationsBenachrichtigungen 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 Cloud Composer Environment aus.
   3. Wählen Sie als Messwertkategorie Umgebung aus.
   4. Wählen Sie für Messwert die Option Anzahl der Snapshot-Erstellungen aus.
   5. Klicken Sie auf Anwenden.
6. Klicken Sie auf Filter hinzufügen und verwenden Sie die Drop-down-Menüs, um die folgenden Filter hinzuzufügen:

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

7. Legen Sie im Bereich Daten transformieren die folgenden Attribute fest:
   • Wählen Sie unter Rollierendes Fenster den Überwachungszeitraum 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 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 als Rolling Window für die Benachrichtigung konfigurierten Zeitraums gespeichert werden sollen. Berechnen Sie diesen Wert mit der folgenden Formel: (rolling window in hours / schedule frequency in hours) - 1 Hinweis:Das Abziehen von 1 Stunden in der Formel berücksichtigt die unterschiedlichen Zeiten, die für die Erstellung von Snapshots benötigt werden. So werden Fehlalarme vermieden, wenn der letzte Snapshot während einer Monitoring-Prüfung noch ausgeführt wird. Beispiel: Wenn Sie das empfohlene gleitende Fenster von 1 Tag verwenden und die Häufigkeit Ihres Zeitplans alle 2 Stunden beträgt, legen Sie diesen Wert auf 11 fest (gemäß Berechnung: 24 / 2 - 1 = 11). Wenn Ihr Zeitplan richtig ausgeführt wird, sollten Sie innerhalb eines beliebigen 24-Stunden-Zeitraums mindestens 11 Snapshots haben. Wenn nicht, bedeutet das, dass ein Snapshot-Vorgang nicht erfolgreich abgeschlossen wurde und Cloud Monitoring diese Benachrichtigung auslöst.
   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.

Notfallwiederherstellungsverfahren testen

Testen Sie Ihre Notfallwiederherstellungsprozedur nach der Einrichtung und dann regelmäßig. So können Sie potenzielle Probleme beheben, die sich auf den eigentlichen Prozess zur Notfallwiederherstellung auswirken könnten.

Im Cold-DR-Szenario können Sie die Failover-Umgebung löschen, nachdem Sie das Verfahren zur Notfallwiederherstellung getestet haben.

„Snapshot speichern“-Vorgänge bestätigen

Mit der Google Cloud CLI können Sie die Liste der save snapshot-Vorgänge 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 Snapshots, die häufiger gespeichert werden, prüfen möchten, ist es am besten, Cloud Monitoring-Benachrichtigungen zu konfigurieren. Weitere Informationen finden Sie unter Monitoring für geplante Snapshot-Vorgänge einrichten.

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

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 die unten beschriebenen Schritte aus, um Ihre primäre Umgebung nach einem Notfall wiederherzustellen.

(Nur Cold-DR) Failover-Umgebung erstellen

Folgen Sie der Anleitung im Abschnitt Failover-Umgebung erstellen.

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

Wenn möglich, verhindern Sie, dass in der primären Umgebung DAGs ausgeführt werden:

• Wenn die primäre Umgebung noch 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, werden Aufgaben geplant und ausgeführt, als ob nach dem Erstellen eines Snapshots nichts von der primären Umgebung ausgeführt worden wäre. Einige dieser Aufgaben wurden jedoch möglicherweise bereits von der primären Umgebung ausgeführt. In der Failover-Umgebung gibt es keine Möglichkeit, zu 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 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 kann es sinnvoll sein, die Konfiguration der Failover-Umgebung zu ändern, nachdem Sie den Snapshot der primären Umgebung geladen haben.

In einem Cold-DR-Szenario müssen Sie in der Failover-Umgebung möglicherweise einen anderen Satz von Airflow-Umgebungsvariablen verwenden. In einem Warm-DR-Szenario müssen Sie Nutzern möglicherweise Berechtigungen in der Airflow-UI gewähren, 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 durch Ausführen von gcloud composer environment update-Befehlen ändern.

Entscheiden, was mit der primären Umgebung geschehen soll

Einige Katastrophen können auftreten, weil die primäre Umgebung nicht erreichbar ist, aber weiterhin funktioniert oder nicht richtig funktioniert. Sie können beispielsweise aufgrund eines Infrastrukturausfalls nicht über das Netzwerk auf die primäre Umgebung zugreifen. Ein weiteres Beispiel: Die Umgebung funktioniert 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 anfallen, die direkt mit Cloud Composer oder anderen Diensten zusammenhängen, auf die über die DAGs zugegriffen wird, auch wenn eine neue Umgebung als Ersatz erstellt wurde. In dieser Umgebung können weiterhin einige DAGs ausgeführt werden. 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 nach dem Laden des Snapshots.

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

Die primäre Umgebung kann gelöscht werden, wenn alle relevanten Daten wiederhergestellt wurden. Möglicherweise möchten Sie Daten wiederherstellen, die nicht in den Umgebungssnapshots enthalten sind, z. B. die Netzwerkkonfiguration oder Inhalte des Bucket der Umgebung 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 zugänglich und fehlerfrei ist, haben Sie zwei Möglichkeiten:

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

So verwenden Sie die Failover-Umgebung weiterhin:

1. Wenn in der primären Umgebung weiterhin DAGs ausgeführt werden, pausieren Sie sie so schnell wie möglich.
2. Achten Sie darauf, dass alle relevanten Daten wiederhergestellt werden, und löschen Sie dann die primäre Umgebung.
3. Wiederholen Sie die Schritte zur Vorbereitung auf die Notfallwiederherstellung für die Failover-Umgebung, z. B. das Einrichten 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. Speichern Sie einen Snapshot der Failover-Umgebung.
4. Laden Sie diesen Snapshot in die primäre Umgebung.
5. Deaktivieren Sie die DAGs in der primären Umgebung.
6. Löschen Sie bei Bedarf die Failover-Umgebung.

Nächste Schritte

• Geplante Snapshots konfigurieren
• Umgebungen erstellen