Strategien zur Notfallwiederherstellung für Aktiv/Passiv-Einrichtungen

In diesem Dokument wird beschrieben, wie Sie die Aktiv/Passiv -Notfall wiederherstellung für OpenShift-Bereitstellungen auf Google Cloud zur schnellen Wiederherstellung mit minimaler Ausfallzeit im Notfall planen und implementieren. 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

Das folgende Architekturdiagramm zeigt ein Aktiv/Passiv-Bereitstellungsszenario für OpenShift in Google Cloud:

Aktiv-passives Deployment (im folgenden Text erläutert)

Wie im vorherigen Diagramm dargestellt, wird bei einer Aktiv/Passiv-Bereitstellung für die Notfallwiederherstellung der gesamte Produktions-Traffic von einem OpenShift-Cluster in der primären Region verarbeitet. Ein sekundärer Cluster in einer anderen Region ist bereit, die Verarbeitung zu übernehmen, wenn der primäre Cluster ausfällt. Diese Einrichtung sorgt für minimale Ausfallzeiten, da der sekundäre Cluster vorab bereitgestellt und in einem warmen Zustand gehalten wird. Das bedeutet, dass er mit der erforderlichen Infrastruktur und den Anwendungskomponenten eingerichtet ist, aber erst bei Bedarf aktiv Traffic verarbeitet. Anwendungsdaten werden in den passiven Cluster repliziert, um Datenverluste 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, die Verarbeitung bei einem Ausfall des primären Clusters mit minimaler Verzögerung zu übernehmen.

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

Diese Architektur hat die folgende Konfiguration:

  • Primärer OpenShift-Cluster (aktiv): Dieser Cluster befindet sich in der primären Google Cloud Region, führt die Produktionsarbeitslast aus und verarbeitet unter normalen Betriebsbedingungen den gesamten Nutzertraffic.
  • Sekundärer OpenShift-Cluster (passiv): Dieser Cluster befindet sich in einer separaten Google Cloud Region, um Fehler zu isolieren, und fungiert als warmer Standby-Cluster. Er ist teilweise eingerichtet und wird ausgeführt und ist bereit, die Verarbeitung zu übernehmen, wenn das primäre System ausfällt. Er enthält die erforderliche Infrastruktur, OpenShift-Konfiguration und Anwendungskomponenten, verarbeitet aber erst dann Live-Produktions-Traffic, wenn ein Failover-Ereignis ausgelöst wird.
  • Google Cloud Regionen: Geografisch isolierte Standorte, die die Grundlage für die Notfallwiederherstellung bilden. Durch die Verwendung separater Regionen wird sichergestellt, dass ein groß angelegtes Ereignis, das sich auf eine Region auswirkt, den Standby-Cluster nicht beeinträchtigt.
  • Globaler externer HTTPS-Load-Balancer: Fungiert als einziger globaler Einstiegspunkt für Anwendungs-Traffic. Unter normalen Bedingungen ist er so konfiguriert, dass der gesamte Traffic an den primären (aktiven) Cluster weitergeleitet wird. Seine 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 Status von nichtflüchtigen Volumes). Dieser Ansatz sorgt für Datenkonsistenz und minimiert Datenverluste während eines Failovers, sodass Sie Ihre RPO einhalten können.
  • Monitoring und Systemdiagnosen:Systeme, die den Zustand und die Verfügbarkeit des primären Clusters und seiner Anwendungen kontinuierlich bewerten, z. B. Cloud Monitoring, Systemdiagnosen für Load Balancer, internes Cluster-Monitoring. Diese Systeme sind wichtig, um Fehler schnell zu erkennen.
  • Failover-Mechanismus:Ein vordefinierter Prozess (manuell, halbautomatisch oder vollständig automatisiert), um Traffic vom primären zum sekundären Cluster umzuleiten, wenn ein nicht behebbarer Fehler im primären Cluster erkannt wird. Dieser Prozess umfasst in der Regel das Aktualisieren der Backend-Konfiguration des globalen Load Balancers, um den sekundären Cluster als Ziel festzulegen und ihn zum neuen aktiven Standort zu machen.
  • VPC-Netzwerk: Die zugrunde liegende Google Cloud Netzwerkinfrastruktur, die die erforderliche Verbindung zwischen Regionen für die Datenreplikation und ‑verwaltung herstellt.

Verwendete Produkte

Anwendungsfälle

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

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

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.

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. Sie können damit 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 Cluster-Sicherung und ‑Wiederherstellung. 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 den von den Anwendungen verwendeten Blockspeicher- und NFS-Speichern basieren. Sie können diese Prozesse mit Tools wie 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. Es ergänzt die Datenreplikation.

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 von den primären zu den sekundären Clustern 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. Dabei 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 ihnen 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 von Persistent Disk konfigurieren.

PersistentVolumes-Objekte

Erstellen Sie in OpenShift in beiden Clustern PersistentVolumes-Objekte, die mit diesen Laufwerken verknüpft sind, und sorgen Sie dafür, dass Anwendungen in beiden Clustern dieselben Persistent Volume Claims (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 erleichtern.

Datenbanksicherungen

Anwendungen können von verschiedenen Arten von Datenbankprodukten abhängen. Um Designaspekte 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 ist nativ in Tools wie pg_basebackup integriert und unterstützt Sicherungen per Streamingreplikation. Sie können Sicherungen in Cloud-Speicherdiensten wie Google Cloud Storage (Cloud Storage) speichern, um die Daten dauerhaft zu speichern und wiederherstellen zu können.

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. Eine detaillierte Konfigurationsanleitung finden Sie in der CloudNativePG-Dokumentation.

Im Falle eines Notfalls können Sie Sicherungen in einem neuen PostgreSQL-Cluster wiederherstellen, um Ausfallzeiten und Datenverluste zu minimieren. Das folgende Beispiel zeigt einen Konfigurations-Snippet 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 Informationen zur Replikation in Cloud SQL. Konfigurieren Sie in OpenShift Secrets oder ConfigMaps, um auf die richtigen Datenbankverbindungsstrings für jeden Cluster zu verweisen.

Da die asynchrone Replikation zu einer RPO ungleich null führt, besteht die Möglichkeit, dass die letzten Daten verloren gehen. Sie müssen Ihre Anwendung so konzipieren, dass Datenverluste minimiert werden. Alternativ können Sie eine andere Replikationsmethode verwenden.

Wir empfehlen außerdem, automatische Sicherungen in Cloud SQL 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 basierend auf Systemdiagnosen und Failover-Richtlinien automatisch 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 eines aktiven Standorts und verarbeitet den Produktions-Traffic. Diese Hochstufung ist erforderlich, um Datenbankschreibvorgänge akzeptieren zu können.

Informationen zum Einrichten der Notfallwiederherstellung für Cloud SQL finden Sie in der Dokumentation zur Notfallwiederherstellung in Google Cloud SQL. Durch die Verwendung der asynchronen Datenbank- oder Speicherreplikation wird eine RPO ungleich null verursacht, um sicherzustellen, 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.

Häufige Ansätze für die Secret-Verwaltung:

  • 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 Ihre Sicherungen aufgenommen werden.
  • Regelmäßige Rotation: Rotieren Sie Secrets regelmäßig und sorgen Sie dafür, dass Ihre Strategie für die Secret -Verwaltung DR-Szenarien berücksichtigt.
  • Tests: Testen Sie die Wiederherstellung von Secrets in einer Staging-Umgebung, um zu bestätigen, dass alle Dienste mit den angegebenen 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 Trafficverwaltung

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

Sie können den globalen Load Balancer mit einer der folgenden Methoden mit Ihren OpenShift-Clustern verbinden:

  • Regionale Load Balancer (Internet-NEGs) verwenden: Konfigurieren Sie Google Cloud Internet-Netzwerk-Endpunktgruppen (NEGs), um auf die externen IP-Adressen der regionalen Load Balancer zu 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-IP-Adressen weiter. Dieser Ansatz bietet eine Abstraktionsebene, erfordert 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 Google Cloud Netzwerk-Endpunktgruppen (NEGs) vom Typ Compute Engine_VM_IP_PORT verwendet werden. Mit diesem Ansatz kann der globale Load Balancer die Pods des OpenShift Ingress Controllers (Routers) direkt über ihre interne PodIP:TargetPort ansprechen. Bei dieser Methode wird der zusätzliche Hop und das zusätzliche Node-Proxying umgangen. In der Regel führt dies zu einer geringeren Latenz und ermöglicht eine direktere Systemdiagnose vom globalen Load Balancer aus.

Beide Setups ermöglichen es dem globalen Load Balancer, die Verteilung des Traffics effektiv über Cluster in verschiedenen Regionen hinweg zu 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:

  • Gemeinsam genutzte VPC: Verwenden Sie eine gemeinsam genutzte VPC um die Netzwerkverwaltung für primäre und sekundäre Cluster zu zentralisieren. Dieser Ansatz vereinfacht die Verwaltung und sorgt für konsistente 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 gewährleisten.
  • 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 oft für das VPC-native Pod-Networking erforderlich, das von Methoden wie dem Compute Engine_VM_IP_PORT-Routing benötigt wird.
  • VPC-Netzwerk-Peering: Wenn Sie für jede Region und jeden Cluster separate VPC-Netzwerke verwenden müssen, verwenden Sie VPC-Netzwerk-Peering, um die Regionen und Cluster zu verbinden.

Subnetze und IP-Adressen

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

Achten Sie darauf, dass es zwischen den Regionen keine überlappenden IP-Bereiche gibt, um Routingprobleme 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 möglicherweise clusterübergreifend kommunizieren müssen.

Informationen zum Einrichten der Service Mesh-Föderation zwischen primären und sekundären Clustern, siehe die Red Hat-Dokumentation.

Bereitstellung

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

Nächste Schritte