Strategien zur Notfallwiederherstellung für Aktiv/Inaktiv-Konfigurationen

In diesem Dokument wird beschrieben, wie Sie die Aktiv/Inaktiv-Notfall wiederherstellung für OpenShift-Bereitstellungen Google Cloud inplanen und implementieren, damit Sie bei einem Notfall für eine schnelle Wiederherstellung mit minimaler Ausfallzeit sorgen können. Es enthält Best Practices für das Sichern von Daten, das Verwalten von Konfigurationen als Code und den Umgang mit Secrets, damit Sie Ihre Anwendungen im Notfall schnell wiederherstellen können.

Es richtet sich an Systemadministratoren, Cloud-Architekten und Anwendungsentwickler, die für die Aufrechterhaltung der Verfügbarkeit und Ausfallsicherheit von Anwendungen auf der Red Hat OpenShift Container Platform verantwortlich sind, die in bereitgestellt wird Google Cloud.

Das Dokument ist Teil einer Reihe, in der es um Strategien auf Anwendungsebene geht, mit denen Sie sicherstellen, dass Ihre Arbeitslasten hochverfügbar bleiben und sich nach einem Ausfall schnell wiederherstellen lassen. Es wird davon ausgegangen, dass Sie die Best Practices für die Notfallwiederherstellung gelesen haben. Die Dokumente in dieser Reihe sind:

Architektur für die Notfallwiederherstellung

Bei der Aktiv/Inaktiv-Notfallwiederherstellung wird eine sekundäre Region als Standby-Region verwendet, die nur bei Notfällen aktiviert wird. Im Gegensatz zu Aktiv/Passiv-Einrichtungen, bei denen Daten kontinuierlich repliziert werden, basiert diese Strategie auf regelmäßigen Sicherungen, die in Cloud Storage gespeichert werden. Die Infrastruktur wird bereitgestellt und die Daten werden während des Failovers wiederhergestellt. Sie können Tools wie Velero verwenden, das in die OpenShift API for Data Protection (OADP) integriert ist, um regelmäßige Sicherungen durchzuführen. Dieser Ansatz minimiert die Kosten und ist daher ideal für Anwendungen, die längere Wiederherstellungszeiten tolerieren können. Er kann Unternehmen auch dabei helfen, längere Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) einzuhalten.

In einem Aktiv/Inaktiv-Notfallwiederherstellungsszenario werden Daten regelmäßig in der Standby-Region gesichert, aber nicht aktiv repliziert. Die Infrastruktur wird im Rahmen des Failover-Prozesses bereitgestellt und die Daten werden aus der letzten Sicherung wiederhergestellt. Sie können die OpenShift API for Data Protection (OADP) verwenden, die auf dem Open-Source-Projekt Velero basiert, um regelmäßige Sicherungen durchzuführen. Wir empfehlen, diese Sicherungen in Cloud Storage-Buckets mit aktivierter Versionierung zu speichern. Im Falle eines Notfalls können Sie mit OADP die Inhalte des Clusters wiederherstellen. Dieser Ansatz minimiert die laufenden Kosten, führt aber im Vergleich zu Aktiv/Passiv zu längeren RTO und potenziell höheren RPO. Diese Einrichtung eignet sich für Anwendungen mit längeren Recovery Time Objectives.

Das folgende Diagramm zeigt eine Aktiv/Inaktiv-Bereitstellung und den Failover-Prozess:

Failover-Vorgang

Der Failover-Prozess läuft so ab:

  1. Ein Notfallwiederherstellungsereignis wird ausgelöst, wenn ein überwachter Dienst nicht mehr verfügbar ist.
  2. Eine Pipeline stellt automatisch die Infrastruktur in der Notfallwiederherstellungsregion bereit.
  3. Ein neuer OpenShift-Cluster wird bereitgestellt.
  4. Anwendungsdaten, Secrets und Objekte werden über OADP aus der letzten Sicherung wiederhergestellt.
  5. Der Cloud DNS-Eintrag wird aktualisiert und verweist auf die regionalen Load-Balancer in der Notfallwiederherstellungsregion.

Wie im vorherigen Diagramm dargestellt, werden zwei separate regionale OpenShift Cluster bereitgestellt, jeweils in einer anderen Google Cloud Region, z. B. und us-central1 und europe-west1. Jeder Cluster muss in seiner Region hochverfügbar sein und mehrere Zonen verwenden, um Redundanz zu ermöglichen.

Beschreibung der Komponenten in einem Aktiv/Inaktiv-Notfallwiederherstellungsszenario

Die Architektur hat die folgende Konfiguration:

  • Primäre Region (Region A): Enthält den voll funktionsfähigen OpenShift Cluster, der den Produktions-Traffic verarbeitet.
  • Sekundäre Region (Region B): Enthält anfangs nur minimale Ressourcen (VPC und Subnetze). Die Infrastruktur (Compute Engine-Instanzen und OCP) wird während des Failovers bereitgestellt.
  • Sicherungsspeicher: In Google Cloud Storage-Buckets werden regelmäßige Sicherungen gespeichert (OADP oder Velero für Anwendungsobjekte sowie PVs und Datenbanksicherungen). Wir empfehlen, die Versionsverwaltung und die regionsübergreifende Replikation für den Bucket zu verwenden.
  • Konfigurationsverwaltung: Im Git-Repository werden Infrastruktur als Code (IaC, z. B. Terraform) und Kubernetes- oder OpenShift-Manifeste (für GitOps) gespeichert.
  • Sicherungstools: OADP (Velero) ist im primären Cluster konfiguriert, um geplante Sicherungen in Cloud Storage durchzuführen.
  • Orchestrierung: Skripts oder Automatisierungstools lösen während des Failovers die Bereitstellung der Infrastruktur und die Wiederherstellungsprozesse aus.

Verwendete Produkte

Anwendungsfälle

Die Aktiv/Inaktiv-Notfallwiederherstellung wird für die folgenden Anwendungsfälle empfohlen:

  • Anwendungen, die längere RTOs tolerieren können (z. B. mehrere Minuten bis Stunden).
  • Umgebungen, in denen die Kostenoptimierung wichtig ist und die Kosten für einen kontinuierlich ausgeführten Standby-Cluster zu hoch sind. Die primären laufenden Kosten fallen für den Objektspeicher an, nicht für die Ausführung von Compute-Instanzen.
  • Arbeitslasten für Entwicklung, Tests oder weniger kritische Produktionsarbeitslasten.
  • Archivierungs- oder Batchverarbeitungssysteme, bei denen die Wiederherstellungszeit weniger kritisch ist.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Kosten und Leistung entspricht.

Anwendungskonfiguration als Code (GitOps)

Wir empfehlen, einen GitOps-Ansatz zu verwenden, um alle Cluster- und Anwendungskonfigurationen in einem Git-Repository zu speichern. Dieser Ansatz ermöglicht eine schnelle Wiederherstellung in einem Notfallwiederherstellungsszenario, indem die Synchronisierung mit einem Zustand ermöglicht wird, der bekanntermaßen zuverlässig in einem anderen Cluster ausgeführt wird. Sicherungen sorgen dafür, dass Sie Snapshots Ihres Laufzeitstatus haben. Sie benötigen jedoch auch eine zuverlässige Möglichkeit, die Anwendungslogik, Manifeste und Infrastrukturdefinitionen nach einem Notfall schnell neu bereitzustellen.

OpenShift GitOps Operator verwenden

Der OpenShift GitOps Operator, der auf Argo CD basiert, bietet eine von Red Hat unterstützte Möglichkeit, GitOps-Muster direkt in einer OpenShift-Umgebung zu implementieren. Er automatisiert den Prozess der kontinuierlichen Abstimmung des Clusterstatus mit der von Ihnen ausgewählten Konfiguration und speichert ihn in einem Git-Repository.

Der Controller des OpenShift GitOps Operator sorgt kontinuierlich dafür, dass der Status des Clusters mit der in diesem Repository definierten Konfiguration übereinstimmt. Wenn Ressourcen abweichen oder fehlen, werden sie automatisch abgestimmt. Weitere Informationen finden Sie unter About Red Hat OpenShift GitOps.

Ausführung des Notfallwiederherstellungsszenarios

Im Falle einer Katastrophe gehen Sie wie folgt vor:

  • Richten Sie einen neuen OpenShift-Cluster in einer anderen Region ein.
  • Installieren Sie den OpenShift GitOps Operator.
  • Wenden Sie dasselbe Anwendungsmanifest an, das auf Ihr Git-Repository verweist.

Der Operator synchronisiert den Clusterstatus mit Ihrem Repository und stellt Bereitstellungen, Dienste, Routen, Operatoren und alle anderen Ressourcen, die in Ihrem Code definiert sind, schnell neu bereit.

Um Probleme während der Notfallwiederherstellung zu vermeiden, empfehlen wir Folgendes:

  • Verwenden Sie strenge Verzweigungs- und Tagging-Strategien in Ihrem Git-Repository, damit Sie stabile Konfigurationen identifizieren können, die für die Notfallwiederherstellung geeignet sind.
  • Prüfen Sie, ob Ihr Notfallwiederherstellungscluster eine Netzwerkverbindung und die entsprechenden Berechtigungen für den Zugriff auf das Git-Repository hat.
  • Fügen Sie alle Ressourcentypen als Code ein, um manuelle Eingriffe während des Failovers zu vermeiden (z. B. Infrastrukturkomponenten, Arbeitslasten von Anwendungen und Konfigurationen).

Firewallregeln

Definieren Sie einheitliche Firewallrichtlinien und wenden Sie sie konsistent auf beide Cluster an, um den Trafficfluss zu steuern und die Sicherheit zu erhöhen.

Beachten Sie das Prinzip der geringsten Berechtigung. Das bedeutet, dass Sie den eingehenden und ausgehenden Traffic auf das beschränken, was für die Anwendungsfunktionalität erforderlich ist.

Bereitstellung

Informationen zum Bereitstellen einer Topologie, die auf dieser Referenzarchitektur basiert, finden Sie in der Red Hat-Dokumentation.

Nächste Schritte