Notfallwiederherstellung mit Umgebungs-Snapshots

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

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

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. Die Ursache einer Katastrophe kann natürlicher oder von Menschen verursachter Natur sein. Dazu gehören sowohl Ausfallzeiten von Google Cloud Regionen als auch Ausfälle Ihrer eigenen Infrastruktur.
  • Die Notfallwiederherstellung (Disaster Recovery, DR) im Kontext von Cloud Composer ist ein Prozess, bei dem der Betrieb der Umgebung nach einem Notfall wiederhergestellt wird. Dazu muss die Umgebung möglicherweise in einer anderen Region neu erstellt werden. 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 Notfallwiederherstellung aktivieren möchten.
  • Eine Failover-Umgebung ist eine Cloud Composer-Umgebung, die Aktivitäten aus der primären Umgebung übernehmen soll.
  • Ein Warm-DR-Szenario ist eine Variante der Notfallwiederherstellung, bei der Sie eine Standby-Failover-Umgebung verwenden, die Sie vor einem Notfall erstellen.
  • Ein Cold-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 Warm- oder Cold-Site-Wiederherstellung, bei der sich die primäre und die Failover-Umgebung in verschiedenen Regionen befinden.

Notfallwiederherstellung

Mit der Notfallwiederherstellung wird das Problem behoben, wenn Ihre primäre Umgebung aufgrund eines Notfalls nicht mehr funktioniert (defekt ist oder anderweitig nicht zugänglich ist).

Bei diesem Verfahren wird davon ausgegangen, dass die primäre Umgebung nicht vor Ort repariert wird, um das Problem zu beheben. Stattdessen erstellen Sie parallel eine zweite (Failover-)Umgebung. Diese Umgebung wird anstelle der primären Umgebung verwendet. 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. Zu den Änderungen zwischen der primären und der Failover-Umgebung gehören (nicht vollständige Liste):

  • 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.

Hinweis

  • Die Airflow-Datenbank darf weniger als 20 GB Daten enthalten, um Snapshots zu erstellen.

  • 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 aus und kann zu Fehlern beim Laden von Snapshots oder beim Upgraden Ihrer Umgebung führen. Für die Übertragung großer Datenmengen können Sie Alternativen wie Cloud Storage verwenden.

Vorbereitung – Übersicht

Für beide Notfallwiederherstellungsszenarien sind die folgenden Vorbereitungsschritte erforderlich:

  1. Erstellen Sie eine Failover-Umgebung.

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

  2. Erstellen Sie einen Bucket für Snapshots.

    • Der Bucket muss in der Region „DR“ 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. 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 folgenden 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:

  • In Ihrer primären und Ihrer Failover-Umgebung muss dieselbe Airflow-Version und dasselbe Build verwendet werden.

  • Achten Sie beim Warm-DR-Szenario darauf, dass Sie beide Umgebungen synchron aktualisieren und umstellen. Wenn Sie beispielsweise die primäre Umgebung auf einen neueren Airflow-Build aktualisieren oder PyPI-Pakete installieren, müssen diese Änderungen auch in der Failover-Umgebung vorgenommen werden.

  • Wir empfehlen, die Failover-Umgebung in einer anderen Region als der primären Umgebung zu erstellen. So können mehr mögliche Notfallszenarien abgedeckt werden, z. B. eine Katastrophe, die die Verfügbarkeit der gesamten Region beeinträchtigt.

  • 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 hängt möglicherweise von der Konfiguration der Umgebung ab, z. B. von Berechtigungen, die dem Dienstkonto, der Netzwerkkonfiguration oder dem Projekt der Umgebung 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 im Vergleich zur 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 der Aufbewahrungsrichtlinie und des Lebenszyklus auf Bucket-Ebene angewendet wird.

Achten Sie darauf, dass dieser Speicher-Bucket IAM-Berechtigungen, eine Aufbewahrungsrichtlinie und eine Lebenszykluskonfiguration hat, die versehentliches Löschen oder unbefugten Zugriff verhindert. 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

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 Umgebung ein.

Snapshots können nur in einer fehlerfreien Umgebung erstellt werden. Sie müssen also vor dem Notfall gespeichert 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.

(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 Cloud Monitoring verwenden, um benachrichtigt zu werden, wenn ein Snapshot nicht automatisch erstellt wird.

Bei Zeitplänen mit geringerer Häufigkeit können Sie die Ergebnisse von Snapshot-Vorgängen mit der Google Cloud CLI prüfen. Weitere Informationen finden Sie unter 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 Cloud Composer-Umgebung aus.
    3. Wählen Sie als Messwertkategorie 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.
    Label überwachen > Ergebnis = SUCCEEDED

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

      Empfohlener Wert für die geplante Snapshot-Überwachung: 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 gleitende Fenster von 1 Tag verwenden und die Häufigkeit Ihres Zeitplans alle zwei 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 Zeitraums von 24 Stunden mindestens 11 Snapshots haben. Andernfalls wurde ein Snapshot-Vorgang nicht erfolgreich abgeschlossen und Cloud Monitoring löst diese Benachrichtigung aus.

    Condition name Der benutzerdefinierte 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 den Notfallwiederherstellungsvorgang nach der Einrichtung und dann regelmäßig. So können Sie potenzielle Probleme beheben, die sich auf den eigentlichen Notfallwiederherstellungsprozess auswirken könnten.

Im Cold-DR-Szenario können Sie die Failover-Umgebung löschen, nachdem Sie den Notfallwiederherstellungsvorgang getestet haben.

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 gespeicherte Snapshots prüfen möchten, sollten Sie Cloud Monitoring-Benachrichtigungen konfigurieren. Weitere Informationen finden Sie unter Monitoring für geplante Snapshot-Vorgänge einrichten.

gcloud

Listet 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 Regions-IDs, in denen sich die Umgebung befindet
  • PROJECT_ID durch die Kennung des Projekts, in dem sich die Umgebung befindet
  • ENVIRONMENT_ID durch die Kennung 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 Umgebung wiederherzustellen.

(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

Verhindern Sie nach Möglichkeit, dass in der primären Umgebung DAGs ausgeführt werden:

  • 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.

Nachdem der Snapshot in die Failover-Umgebung geladen wurde, werden Aufgaben so geplant und ausgeführt, als wäre nach dem Erstellen eines Snapshots nichts von der primären Umgebung 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 als auch in der Failover-Umgebung. Wir empfehlen, dass alle Aufgaben idempotent sind und dass die geplanten Snapshots alle zwei Stunden erstellt werden.

(falls erforderlich) Konfiguration der Failover-Umgebung anpassen

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

In einem Cold-DR-Szenario müssen Sie beispielsweise möglicherweise eine andere Gruppe von Airflow-Umgebungsvariablen in der Failover-Umgebung verwenden. 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-Script mit Befehlen erstellen, die die Konfiguration der Failover-Umgebung ändern, indem gcloud composer environment update-Befehle ausgeführt werden.

Entscheiden, was mit der primären Umgebung geschehen soll

Einige Notfallsituationen können auftreten, weil die primäre Umgebung nicht erreichbar, aber noch in Betrieb oder nicht ordnungsgemäß funktioniert. Angenommen, Sie können aufgrund eines Infrastrukturfehlers nicht über das Netzwerk auf die primäre Umgebung zugreifen. 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, können Kosten direkt für Cloud Composer oder andere Dienste anfallen, auf die über die DAGs zugegriffen wird, auch wenn eine neue Umgebung als Ersatz erstellt wurde. In dieser Umgebung können noch 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.

Die primäre Umgebung ist vorhanden, funktioniert aber nicht richtig

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 erreichbar und intakt ist

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 weiter:

  1. Wenn in der primären Umgebung noch DAGs ausgeführt werden, pausieren Sie sie so schnell 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. 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