OpenShift in Cloud de Confiance by S3NS: Strategien zur Notfallwiederherstellung für Aktiv/Passiv- und Aktiv/Inaktiv-Setups

In diesem Dokument wird beschrieben, wie Sie die Aktiv/Passiv- und Aktiv/Inaktiv-Notfallwiederherstellung für OpenShift-Bereitstellungen in Cloud de Confiance by S3NS planen und implementieren, um bei einem Notfall für eine schnelle Wiederherstellung mit minimaler Ausfallzeit zu sorgen. Es enthält Best Practices für die Datensicherung, die Verwaltung der Konfiguration als Code und den Umgang mit Secrets, damit Sie Ihre Anwendungen im Katastrophenfall 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 einer OpenShift Container Platform verantwortlich sind, die aufCloud de Confiancebereitgestellt wird.

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 mit OpenShift gelesen haben. Die Dokumente in dieser Reihe sind:

Architekturen für die Notfallwiederherstellung

In diesem Abschnitt werden Architekturen für Aktiv-Passiv- und Aktiv-Inaktiv-Szenarien für die Notfallwiederherstellung beschrieben.

Verwendete Produkte

Aktiv/Passiv-Bereitstellungen

Das folgende Diagramm zeigt ein Aktiv/Passiv-Bereitstellungsszenario für OpenShift auf Cloud de Confiance.

Aktiv-passiv-Bereitstellung (im folgenden Text erläutert)

Wie im obigen Diagramm dargestellt, wird bei einer Aktiv-Passiv-Bereitstellung für die Notfallwiederherstellung der gesamte Produktionsverkehr von einem OpenShift-Cluster in der primären Region verarbeitet. Ein sekundärer Cluster in einer anderen Region wird bereitgehalten, um im Falle eines Ausfalls des primären Clusters zu übernehmen. Diese Einrichtung sorgt für minimale Ausfallzeiten, da der sekundäre Cluster vorab bereitgestellt wird und sich in einem Warm-Standby befindet. Das bedeutet, dass er mit der erforderlichen Infrastruktur und den erforderlichen Anwendungskomponenten eingerichtet ist, aber erst bei Bedarf aktiv Traffic verarbeitet. Anwendungsdaten werden in den passiven Cluster repliziert, um Datenverlust zu minimieren und die RPO einzuhalten.

Einer der regionalen Cluster fungiert als primärer (aktiver) Standort und verarbeitet den gesamten Produktions-Traffic. Ein sekundärer Cluster in einer anderen Region ist der Standby-Cluster für die Notfallwiederherstellung. Der sekundäre Cluster wird in einem warmen Zustand gehalten und ist bereit, im Falle eines Fehlers im primären Cluster mit minimaler Verzögerung die Verarbeitung zu übernehmen.

Beschreibung der Komponenten in einem Aktiv/Passiv-DR-Szenario

Die Architektur hat die folgende Konfiguration:

  • Primärer OpenShift-Cluster (aktiv): Dieser Cluster befindet sich in der primärenCloud de Confiance -Region und führt die Produktionsarbeitslast aus. Unter normalen Betriebsbedingungen wird der gesamte Nutzer-Traffic aktiv über diesen Cluster bereitgestellt.
  • Sekundärer OpenShift-Cluster (passiv): Dieser Cluster befindet sich in einer separatenCloud de Confiance -Region zur Fehlerisolation und dient als Warm-Standby-Cluster. Es ist teilweise eingerichtet und läuft und ist bereit, die Aufgaben zu übernehmen, wenn das primäre System ausfällt. Sie verfügt über die erforderliche Infrastruktur, OpenShift-Konfiguration und Anwendungs-Komponenten, die darauf bereitgestellt werden. Sie verarbeitet jedoch erst dann Live-Produktions-Traffic, wenn ein Failover-Ereignis ausgelöst wird.
  • Cloud de Confiance by S3NS Regionen: Geografisch isolierte Standorte, die die Grundlage für die Notfallwiederherstellung bilden. Durch die Verwendung separater Regionen wird sichergestellt, dass sich ein groß angelegtes Ereignis, das sich auf eine Region auswirkt, nicht auf den Standby-Cluster auswirkt.
  • Globaler externer HTTPS-Load-Balancer: Dient als einziger globaler Einstiegspunkt für Anwendungs-Traffic. Unter normalen Umständen ist sie so konfiguriert, dass der gesamte Traffic an den primären (aktiven) Cluster weitergeleitet wird. Die Systemdiagnosen überwachen die Verfügbarkeit des primären Clusters.
  • Mechanismus zur Datenreplikation: Kontinuierlicher Prozess oder Tools, die für das Kopieren wichtiger Anwendungsdaten vom primären in den sekundären Cluster verantwortlich sind (z. B. Datenbanken oder der Status von persistenten Volumes). So wird die Datenkonsistenz gewährleistet und Datenverlust während eines Failovers minimiert. Das hilft Ihnen, Ihr RPO zu erreichen.
  • Monitoring und Systemdiagnosen:Systeme, die kontinuierlich den Zustand und die Verfügbarkeit des primären Clusters und seiner Anwendungen bewerten, z. B. Cloud Monitoring, Load Balancer-Systemdiagnosen, internes Clustermonitoring. Diese Systeme sind wichtig, um Fehler schnell zu erkennen.
  • Failover-Mechanismus:Ein vordefinierter Prozess (manuell, halbautomatisch oder vollautomatisch), um den Traffic vom primären zum sekundären Cluster umzuleiten, wenn im primären Cluster ein nicht behebbarer Fehler erkannt wird. Dazu muss in der Regel die Back-End-Konfiguration des Global Load Balancer aktualisiert werden, damit der sekundäre Cluster als Ziel verwendet wird. Dadurch wird er zur neuen aktiven Website.
  • VPC-Netzwerk: Die zugrunde liegende Cloud de Confiance Netzwerkinfrastruktur, die die erforderliche Konnektivität zwischen Regionen für die Datenreplikation und ‑verwaltung schafft.

Aktive und inaktive Bereitstellungen

Bei der Aktiv-Inaktiv-Notfallwiederherstellung wird eine sekundäre Region als Standby-Region verwendet, die nur bei Katastrophen aktiviert wird. Im Gegensatz zu Active-Passive-Konfigurationen, 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 Back-ups durchzuführen. Dieser Ansatz minimiert die Kosten und ist daher ideal für Anwendungen, die längere Wiederherstellungszeiten tolerieren können. Außerdem kann es Organisationen helfen, sich an erweiterte Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) anzupassen.

In einem Aktiv/Inaktiv-DR-Szenario 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 dem letzten Backup wiederhergestellt. Sie können die OpenShift API for Data Protection (OADP) verwenden, die auf dem Open-Source-Projekt Velero basiert, um regelmäßige Backups durchzuführen. Wir empfehlen, diese Back-ups in Cloud Storage-Buckets mit aktivierter Versionsverwaltung zu speichern. Im Notfall können Sie mit OADP den Inhalt des Clusters wiederherstellen. Dieser Ansatz minimiert die laufenden Kosten, führt aber im Vergleich zu aktiv-passiv zu einem längeren RTO und möglicherweise zu einem höheren RPO. Diese Einrichtung eignet sich für Anwendungen mit längeren RTOs (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 Infrastruktur in der DR-Region bereit.
  3. Ein neuer OpenShift-Cluster wird bereitgestellt.
  4. Anwendungsdaten, Secrets und Objekte werden über OADP aus dem letzten Backup wiederhergestellt.
  5. Der Cloud DNS-Eintrag wird aktualisiert, sodass er auf die regionalen Load Balancer in der DR-Region verweist.

Wie im obigen Diagramm dargestellt, werden zwei separate regionale OpenShift-Cluster bereitgestellt, jeweils in einer anderen Cloud de Confiance -Region, z. B. us-central1 und europe-west1. Jeder Cluster muss in seiner Region hochverfügbar sein und mehrere Zonen für Redundanz nutzen.

Beschreibung der Komponenten in einem Active-Inactive-DR-Szenario

Die Architektur hat die folgende Konfiguration:

  • Primäre Region (Region A): Enthält den voll funktionsfähigen OpenShift-Cluster, der 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, für den Bucket die Versionsverwaltung und die regionsübergreifende Replikation zu verwenden.
  • Konfigurationsverwaltung: Im Git-Repository werden Infrastructure as 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 und Wiederherstellung der Infrastruktur aus.

Anwendungsfälle

In diesem Abschnitt finden Sie Beispiele für die verschiedenen Anwendungsfälle für Aktiv/Passiv- und Aktiv/Inaktiv-Bereitstellungen.

Anwendungsfälle für Aktiv/Passiv-DR

Aktiv/Passiv-DR wird für die folgenden Anwendungsfälle empfohlen:

  • Anwendungen, die einen niedrigeren RTO (z. B. Minuten bis Stunden) erfordern, als mit Cold-Restores möglich wäre, bei denen Daten aus einer Sicherung wiederhergestellt werden, auf die nicht sofort zugegriffen werden kann.
  • Systeme, in denen eine kontinuierliche Datenreplikation möglich ist und das RPO minimiert werden muss (z. B. auf Minuten oder Sekunden).
  • Regulierte Branchen mit strengen Ausfallzeitbegrenzungen und kritische Geschäftsanwendungen, bei denen die Kosten für die Wartung eines Warm-Standby-Clusters durch die geschäftlichen Auswirkungen von Ausfallzeiten gerechtfertigt sind.

DR-Anwendungsfälle für Aktiv/Inaktiv

Active-Inactive DR 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 eines kontinuierlich ausgeführten Standby-Clusters zu hoch sind. Die primären laufenden Kosten fallen für den Objektspeicher an, nicht für die Ausführung von Compute-Instanzen.
  • Entwicklungs-, Test- 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.

Überlegungen zum Aktiv/Passiv-Design

In diesem Abschnitt werden die Designüberlegungen für ein Active-Passive-DR-Szenario beschrieben.

Anwendungsstatus und -konfiguration schützen

Die OpenShift Container Platform bietet OADP und umfassenden Schutz für die Notfallwiederherstellung für Anwendungen, die in Clustern ausgeführt werden. Damit können Sie die Kubernetes- und OpenShift-Objekte sichern, die sowohl von containerisierten Anwendungen als auch von virtuellen Maschinen verwendet werden, z. B. Bereitstellungen, Dienste, Routen, PVCs, ConfigMaps, Secrets und CRDs. OADP unterstützt jedoch keine vollständige Sicherung und Wiederherstellung von Clustern. Informationen zum Konfigurieren und Planen von Sicherungen sowie zum Wiederherstellen von Vorgängen finden Sie in der Red Hat-Dokumentation.

OADP bietet Sicherungs- und Wiederherstellungsprozesse für nichtflüchtige Volumes, die auf dem von den Anwendungen verwendeten Blockspeicher und NFS-Speicher basieren. Sie können diese Prozesse mit den Tools Restic oder Kopia ausführen, um Snapshots zu erstellen oder Sicherungen auf Dateiebene durchzuführen.

OADP ist nützlich, um Objektdaten zu sichern, die Konfigurationskonsistenz zu gewährleisten und bei Bedarf bestimmte Anwendungen oder Namespaces wiederherzustellen. So wird die Datenreplikation ergänzt.

Um RPO und RTO in einer Aktiv/Passiv-Konfiguration weiter zu reduzieren, empfehlen wir, die Datenreplikation zwischen primären und sekundären Regionen zu konfigurieren.

Die Datenreplikation ist wichtig, damit der sekundäre Cluster nahtlos übernehmen kann. Wie im folgenden Abschnitt beschrieben, hängt die Implementierung der Datenreplikation vom primären zum sekundären Cluster vom Speichertyp ab, den die Anwendung verwendet.

Blockspeicher (nichtflüchtige Volumes)

Verwenden Sie die asynchrone Replikation von Google Persistent Disk, um Daten von der primären in die sekundäre Region zu kopieren. Bei diesem Ansatz erstellen Sie ein primäres Laufwerk in der primären Region, ein sekundäres Laufwerk in der sekundären Region und richten die Replikation zwischen den beiden ein. Durch die Verwendung von Konsistenzgruppen wird sichergestellt, dass beide Laufwerke Replikationsdaten von einem gemeinsamen Zeitpunkt enthalten, die dann für die Notfallwiederherstellung verwendet werden. Weitere Informationen finden Sie unter Asynchrone Replikation nichtflüchtiger Speicher konfigurieren.

PersistentVolumes-Objekte

Erstellen Sie in OpenShift PersistentVolumes-Objekte in beiden Clustern, die mit diesen Laufwerken verknüpft sind, und sorgen Sie dafür, dass Anwendungen in beiden Clustern dieselben PersistentVolumeClaims (PVCs) verwenden.

Replikation auf Anwendungsebene

Einige Anwendungen (z. B. Datenbanken und Message Queues) haben integrierte Replikationsfunktionen, die Sie clusterübergreifend konfigurieren können. Sie können auch einen verwalteten Dienst wie Pub/Sub verwenden, um die Replikation für bestimmte Arten von Anwendungsdaten oder Ereignissen zu vereinfachen. (z. B. Datenbanken und Nachrichtenwarteschlangen).

Datenbanksicherungen

Anwendungen können von verschiedenen Arten von Datenbankprodukten abhängen. Um die Designüberlegungen für Datenbanksicherungen zu veranschaulichen, wird in diesem Dokument PostgreSQL als Beispieldatenbank verwendet.

Selbst gehostete Sicherungen mit einem In-Cluster-Datenbankoperator

Datenbankoperatoren wie der CloudNative PostgreSQL Operator können geplante Sicherungen und die Notfallwiederherstellung für PostgreSQL-Cluster erleichtern. Der CloudNative PostgreSQL-Operator lässt sich nativ in Tools wie pg_basebackup einbinden und unterstützt Sicherungen der Streamingreplikation. Sie können Sicherungen in Cloud Storage-Diensten wie Google Cloud Storage (Cloud Storage) speichern, um sie zu schützen und wiederherzustellen.

Sie können die Streamingreplikation zwischen primären und sekundären regionalen Clustern einrichten, um sicherzustellen, dass Daten auch bei einem Ausfall in der primären Region verfügbar sind. Diese Streamingreplikation ist in der Regel synchron innerhalb einer Region und asynchron über Regionen hinweg. Ausführliche Konfigurationsschritte finden Sie in der CloudNativePG-Dokumentation.

Im Katastrophenfall können Sie Sicherungen in einem neuen PostgreSQL-Cluster wiederherstellen, um Ausfallzeiten und Datenverlust zu minimieren. Das folgende Beispiel zeigt einen Konfigurationsausschnitt zum Aktivieren geplanter Sicherungen mit dem CloudNative PostgreSQL-Operator:

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

Verwaltete Dienste

Verwaltete Datenbanken wie Cloud SQL haben integrierte Sicherungs- und Replikationsfunktionen. Wir empfehlen, die asynchrone Replikation von der primären Datenbankinstanz zu einem Replikat in der sekundären Region einzurichten. Weitere Informationen finden Sie unter Replikation in Cloud SQL. Konfigurieren Sie in OpenShift Secrets oder ConfigMaps, damit sie auf die richtigen Datenbankverbindungsstrings für die einzelnen Cluster verweisen.

Da die asynchrone Replikation zu einem RPO ungleich null führt, besteht die Möglichkeit, dass die letzten Datenveränderungen verloren gehen. Sie müssen Ihre Anwendung so konzipieren, dass Datenverlust verhindert wird. Alternativ können Sie eine andere Replikationsmethode verwenden.

Wir empfehlen außerdem, automatische Cloud SQL-Sicherungen zu aktivieren. Weitere Informationen finden Sie unter On-Demand- und automatische Sicherungen erstellen und verwalten.

Failover-Vorgang

Bei einem Ausfall des primären Clusters leitet Cloud DNS den Traffic automatisch auf Grundlage von Systemdiagnosen und Failover-Richtlinien an den sekundären regionalen Cluster weiter.

Wenn der sekundäre Cluster von einem Lesereplikat zu einem primären Cluster hochgestuft wird, übernimmt er die Rolle einer aktiven Website und verarbeitet Produktions-Traffic. Dieses Angebot ist erforderlich, um Datenbankschreibvorgänge akzeptieren zu können.

Wenn Sie die Notfallwiederherstellung für Cloud SQL einrichten möchten, folgen Sie der Anleitung in der Dokumentation zur Notfallwiederherstellung für Google Cloud SQL. Wenn Sie die asynchrone Datenbank- oder Speicherreplikation verwenden, ist das RPO ungleich null. So wird sichergestellt, dass Ihre Anwendung den Verlust der letzten Schreibvorgänge tolerieren kann. Alternativ können Sie eine andere Replikationsmethode verwenden.

Sichere Secret-Verwaltung

Secrets wie Datenbankpasswörter, API-Schlüssel und TLS-Zertifikate sind wichtige Aspekte der Notfallwiederherstellung. Sie müssen diese Secrets sicher und zuverlässig in einem neuen Cluster wiederherstellen können.

Gängige Ansätze für die Verwaltung von Secrets:

  • Externe Secrets verwenden: Verwenden Sie ein Tool wie den Operator für externe Secrets , um Secrets aus Google Secret Manager abzurufen.
  • Secrets mit dem OADP-Operator sichern: Wenn Sie keinen externen Speicher verwenden, müssen Secrets in Ihren Sicherungen enthalten sein.
  • Regelmäßige Rotation: Rotieren Sie Secrets regelmäßig und sorgen Sie dafür, dass Ihre Strategie zur Verwaltung von Secrets auch DR-Szenarien berücksichtigt.
  • Testen: Testen Sie die Wiederherstellung von Secrets in einer Staging-Umgebung, um zu bestätigen, dass alle Dienste mit den bereitgestellten Anmeldedaten gestartet werden können.
  • Validierung: Prüfen Sie, ob Ihr DR-Cluster die erforderlichen IAM-Rollen oder Authentifizierungsmethoden hat, um Secrets aus externen Speichern abzurufen.

Netzwerk und Traffic-Verwaltung

Verwenden Sie den globalen externen HTTPS-Load-Balancer von Cloud de Confianceals primären Ingress-Punkt, um Traffic zwischen mehreren OpenShift-Clustern (z. B. primären und sekundären Clustern) zu verteilen. Dieser globale Dienst leitet Nutzeranfragen basierend auf Nähe, Status und Verfügbarkeit an den entsprechenden Backend-Cluster weiter.

Sie haben zwei Möglichkeiten, den Global Load Balancer mit Ihren OpenShift-Clustern zu verbinden:

  • Regionale Load Balancer (Internet-NEGs) verwenden: Konfigurieren SieCloud de Confiance Internet-Netzwerk-Endpunktgruppen (NEGs), die auf die externen IP-Adressen der regionalen Load Balancer verweisen, die die Ingress-Dienste (OCP-Router) der einzelnen OpenShift-Cluster bereitstellen. Der globale Load Balancer leitet den Traffic dann an diese regionalen Load Balancer-IPs weiter. Dieser Ansatz bietet eine Abstraktionsebene, beinhaltet aber einen Hop zu einem zusätzlichen Netzwerk.
  • Direktes Pod-Routing (Compute Engine_VM_IP_PORT NEGs): Konfigurieren Sie die OpenShift Ingress Controller-Integration so, dass Cloud de Confiance-Netzwerk-Endpunktgruppen (NEGs) vom Typ Compute Engine_VM_IP_PORT verwendet werden. Mit diesem Ansatz kann der Global Load Balancer die OpenShift Ingress Controller-Pods (Router) direkt über ihre interne PodIP:TargetPort ansteuern. Bei dieser Methode wird der zusätzliche Hop und das zusätzliche Proxying des Knotens umgangen. Dies führt in der Regel zu einer geringeren Latenz und ermöglicht eine direktere Systemdiagnose durch den globalen Load Balancer.

In beiden Setups kann der globale Load-Balancer die Trafficverteilung effektiv über Cluster in verschiedenen Regionen hinweg verwalten. Weitere Informationen finden Sie unter Globalen externen Application Load Balancer mit einem externen Backend einrichten.

VPCs

Wir empfehlen die folgenden Ansätze für die VPC-Verwaltung:

  • Freigegebene VPC: Verwenden Sie eine freigegebene VPC, um die Netzwerkverwaltung für primäre und sekundäre Cluster zu zentralisieren. Dieser Ansatz vereinfacht die Verwaltung und sorgt für einheitliche Netzwerkrichtlinien in allen Regionen.
  • Globales dynamisches Routing: Aktivieren Sie das globale dynamische Routing in Ihren VPCs, um Routen automatisch zwischen Regionen weiterzugeben und so eine nahtlose Verbindung zwischen Clustern zu ermöglichen.
  • VPCs im benutzerdefinierten Modus: Verwenden Sie VPCs im benutzerdefinierten Modus und erstellen Sie bestimmte Subnetze in den Regionen, in denen Ihre Cluster ausgeführt werden. Dies ist häufig für das VPC-native Pod-Netzwerk erforderlich, das für Methoden wie das Compute Engine_VM_IP_PORT-Routing benötigt wird.
  • VPC-Netzwerk-Peering: Wenn Sie separate VPC-Netzwerke für jede Region und jeden Cluster verwenden müssen, verwenden Sie VPC-Netzwerk-Peering, um die Regionen und Cluster zu verbinden.

Subnetze und IP-Adressen

Erstellen Sie regionale Subnetze in jeder Region, um die Netzwerksegmentierung aufrechtzuerhalten und IP-Adresskonflikte zu vermeiden.

Achten Sie darauf, dass es keine sich überschneidenden IP-Bereiche zwischen Regionen gibt, um Routing-Probleme zu vermeiden.

Clusterübergreifender Traffic mit Red Hat Service Mesh

OpenShift unterstützt die Service Mesh-Föderation, die die Kommunikation zwischen Diensten ermöglicht, die in mehreren OpenShift-Clustern bereitgestellt werden. Diese Funktion ist besonders nützlich für DR-Szenarien, in denen Dienste während des Failovers oder der Datenreplikation clusterübergreifend kommunizieren müssen.

Informationen zum Einrichten der Service Mesh-Föderation zwischen primären und sekundären Clustern finden Sie in der Red Hat-Dokumentation.

Überlegungen zum Design für aktive und inaktive Referenzen

In diesem Abschnitt werden die Designüberlegungen für eine DR-Lösung mit aktivem und inaktivem Standort beschrieben.

Anwendungskonfiguration als Code (GitOps)

Wir empfehlen, alle Cluster- und Anwendungskonfigurationen in einem Git-Repository zu speichern. Dieser Ansatz ermöglicht eine schnelle Wiederherstellung in einem DR-Szenario, da die Synchronisierung mit einem Zustand möglich ist, der in einem anderen Cluster zuverlässig ausgeführt wird. Sicherungen sorgen dafür, dass Sie Snapshots Ihres Laufzeitzustands haben. Sie benötigen jedoch auch eine zuverlässige Möglichkeit, 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. Es automatisiert den Prozess des kontinuierlichen Abgleichs des Clusterstatus mit der ausgewählten Konfiguration und speichert ihn in einem Git-Repository.

Der Controller des OpenShift GitOps-Operators 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 abgeglichen. Weitere Informationen zu Red Hat OpenShift GitOps

Ausführung von DR-Szenarien

Gehen Sie im Katastrophenfall so 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 Deployments, Dienste, Routen, Operatoren und alle anderen in Ihrem Code definierten Ressourcen schnell neu bereit.

Damit bei der Notfallwiederherstellung keine Probleme auftreten, empfehlen wir Folgendes:

  • Halten Sie in Ihrem Git-Repository strenge Verzweigungs- und Tagging-Strategien ein, damit Sie stabile Konfigurationen für die Notfallwiederherstellung identifizieren können.
  • Prüfen Sie, ob Ihr DR-Cluster eine Netzwerkverbindung und die erforderlichen Berechtigungen für den Zugriff auf das Git-Repository hat.
  • Nehmen Sie alle Ressourcentypen als Code auf, um manuelle Eingriffe während des Failovers zu vermeiden (z. B. Infrastrukturkomponenten, Anwendungs-Workloads und Konfigurationen).

Firewallregeln

Einheitliche Firewallrichtlinien definieren und konsistent auf beide Cluster anwenden, um den Trafficfluss zu steuern und die Sicherheit zu erhöhen.

Halten Sie sich an das Prinzip der geringsten Berechtigung. Das bedeutet, dass Sie den eingehenden und ausgehenden Traffic auf das beschränken, was für die Anwendungsfunktionen erforderlich ist.

Bereitstellung

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

Nächste Schritte