Notfallwiederherstellung für OpenShift in Google Cloud

Die Notfallwiederherstellung (Disaster Recovery, DR) ist unerlässlich, um den fortlaufenden Betrieb Ihrer Anwendungen, die auf der OpenShift Container Platform inGoogle Cloudbereitgestellt wurden, sicherzustellen. Dieses Dokument bietet einen Überblick über die Architekturoptionen mit OpenShift in Google Cloudfür die Notfallwiederherstellung, damit Ihre Organisation bei einem Notfall für eine schnelle Wiederherstellung mit minimaler Ausfallzeit sorgen kann.

Es richtet sich an Systemadministratoren, Cloud-Architekten und Anwendungsentwickler, die für die Aufrechterhaltung der Verfügbarkeit und Ausfallsicherheit von Anwendungen auf der OpenShift Container Platform inGoogle Cloudverantwortlich sind.

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. Dokumente in dieser Reihe:

Notfallwiederherstellung planen

Das Planen der Notfallwiederherstellung ist ein wichtiger Bestandteil der Ausführung von Produktionsarbeitslasten in der Cloud. Obwohl OpenShift und Google Cloud eine robuste Redundanz auf Infrastrukturebene bieten, müssen Sie Ihre Anwendungen so konzipieren und konfigurieren, dass sie nach schwerwiegenden Ausfällen schnell wiederhergestellt werden können.

Für die effektive Planung der Notfallwiederherstellung ist ein mehrschichtiger Ansatz erforderlich. Zuerst müssen Sie klare Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) für Ihre Anwendung und Ihr System definieren, damit diese möglichst schnell wieder bereitgestellt werden können.

Außerdem müssen auch Ihre Secrets und Anmeldedaten wiederherstellbar sein und sicher verwaltet werden. Wenn Sie alle diese Faktoren berücksichtigen, können Sie eine DR-Sicherheitsstrategie entwickeln, mit der Sie in einer anderen Region schnell einen neuen OpenShift-Cluster erstellen oder einen Failover in einen inaktiven sekundären Cluster durchführen können. Dieser sekundäre Cluster bleibt so lange offline, bis ein Fehler auftritt. An diesem Punkt wird er gestartet und online geschaltet, um den Betrieb nach minimaler Ausfallzeit zu übernehmen.

Architekturen für die Notfallwiederherstellung

Es gibt verschiedene Optionen für Bereitstellungsarchitekturen, die Sie für die Notfallwiederherstellung mit OpenShift in Google Cloudverwenden können. Diese Optionen unterscheiden sich nach Kosten, Komplexität und Verfügbarkeit. Die folgende Tabelle bietet einen Überblick:

Architektur Beschreibung Anwendungsfall Vorteile Nachteile
Aktiv/Passiv Genau ein Cluster ist aktiv und verarbeitet den gesamten Traffic. Ein anderer ist passiv und bereit, die Verarbeitung zu übernehmen. Die Daten werden in den passiven Cluster repliziert. Geeignet für Anwendungen mit moderaten RTO- und RPO-Anforderungen Einfachere Implementierung und geringere Kosten für Stand-by-Cluster Höheres RTO aufgrund der Failover-Zeit, potenzielle Verzögerungen bei der Datensynchronisierung
Aktiv/Inaktiv Ähnlich wie bei Aktiv/Passiv, aber der inaktive Cluster kommt erst bei einem DR-Ereignis zum Einsatz. Daten werden regelmäßig gesichert. Geeignet für kostensensible Umgebungen, die höhere RTOs und RPOs zulassen Geringere Betriebskosten bei Inaktivität, geeignet für DR, bei der kein sekundäres System aktiv ausgeführt wird (kalte DR) Höheres RTO aufgrund der Aktivierungs- und Synchronisierungszeit, Daten können jedoch veralten
Aktiv/Aktiv Beide Cluster sind aktiv und verarbeiten Traffic zwischen Regionen mit Load Balancing und Datenreplikation. Kritische Anwendungen, die minimale Ausfallzeiten und hohe Verfügbarkeit erfordern Niedrigstes RTO und RPO, kontinuierliche Verfügbarkeit Höchste Komplexität und Kosten, erfordert robuste Netzwerk- und Datensynchronisierungen

Weitere Informationen