Einblicke in die Hochverfügbarkeit und die Disaster-Recovery für Red Hat OpenShift on IBM Cloud

HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. (HA) ist die Fähigkeit eines Dienstes, auch bei unerwarteten Ausfällen betriebsbereit und zugänglich zu bleiben. Unter Disaster RecoveryDie Fähigkeit eines Dienstes oder einer Arbeitslast, sich von seltenen, schwerwiegenden Vorfällen und großflächigen Ausfällen, wie z. B. Dienstunterbrechungen, zu erholen. Dies umfasst eine Naturkatastrophe, die eine ganze Region betrifft, die Beschädigung einer Datenbank oder den Verlust eines Dienstes, der zu einer Arbeitsbelastung beiträgt. Die Auswirkungen übersteigen die Fähigkeit des Hochverfügbarkeitsdesigns, sie zu bewältigen. versteht man die Wiederherstellung eines funktionierenden Zustands der Service-Instanz.

Red Hat OpenShift on IBM Cloud ist ein hochverfügbarer regionaler oder zonaler Dienst, der für die Verfügbarkeit während eines regionalen oder zonalen Ausfalls ausgelegt ist. Red Hat OpenShift on IBM Cloud ist darauf ausgelegt, die Service Level Objectives (SLO) mit dem Standardplan zu erfüllen.

Weitere Informationen zu den verfügbaren Regionen und Rechenzentrumsstandorten finden Sie unter "Verfügbarkeit von Diensten und Infrastruktur nach Standort".

Hochverfügbarkeitsarchitektur

Red Hat OpenShift on IBM Cloud die Architektur schafft eine hohe Verfügbarkeit auf regionaler, Zonen- und Cluster-Ebene.

Verfügbarkeit in den Regionen: Jede Region wird mit einer hoch verfügbaren Lastausgleichsfunktion konfiguriert, auf die von einem regionsspezifischen API-Endpunkt aus zugegriffen werden kann. Die Lastausgleichsfunktion leitet eingehende und ausgehende Anforderungen an Cluster in den Regionszonen weiter. Die Wahrscheinlichkeit eines vollständigen regionalen Ausfalls ist gering. Um diesem Fehler jedoch vorzubeugen, können Sie mehrere Cluster in verschiedenen Regionen einrichten und sie mithilfe einer externen Lastausgleichsfunktion verbinden. Fällt eine ganze Region aus, kann der Cluster in der anderen Region die Arbeitslast übernehmen.
Verfügbarkeit von Clustern und Zonen: Ein Zonenfehler wirkt sich auf alle physischen Datenverarbeitungshosts und den NFS-Speicher aus. Fehler umfassen Ausfälle bei Stromversorgung, Kühlung, Netzbetrieb oder Speicherausfälle sowie Naturkatastrophen wie Überschwemmungen, Erdbeben und Stürme. Um sich vor einem Zonenfehler zu schützen, müssen Sie über Cluster in zwei unterschiedlichen Zonen verfügen, wobei eine externe Lastausgleichsfunktion den Lastausgleich zwischen den Zonen vornimmt. Erstellen Sie einen Cluster an einem Standort mit mehreren Zonen, an dem der Master auf mehrere Zonen verteilt ist. Oder erwägen Sie die Einrichtung eines zweiten Clusters in einer anderen Zone.
Verfügbarkeit in mehreren Zonen: Mehrzonen-Cluster verteilen die Arbeitslast auf mehrere Arbeitsknoten und Zonen und bieten so zusätzlichen Schutz vor Zonenausfällen. Arbeitsknoten werden automatisch mit drei Replikaten bereitgestellt, die über mehrere Zonen verteilt sind. Wenn in einer ganzen Zone ein Ausfall auftritt, wird Ihre Arbeitslast auf Arbeitsknoten in den anderen Zonen verteilt, wodurch Ihre Anwendung vor dem Ausfall geschützt wird.
Globaler Lastausgleich: Um Ihre Anwendung vor einem Master-Ausfall zu schützen oder für klassische Cluster, die sich in einer der unterstützten Multizonen-Regionen befinden müssen, können Sie mehrere Cluster in verschiedenen Zonen innerhalb einer Region erstellen und sie mit einem globalen Load Balancer verbinden.

Ressourcenverteilung für hohe Verfügbarkeit.

Die Wahrscheinlichkeit, dass Ihre Benutzer Ausfallzeiten verzeichnen, ist geringer, wenn Sie Ihre Apps auf mehrere Workerknoten, Zonen und Cluster verteilen. Integrierte Funktionen wie Lastausgleich (Load Balancing) und Isolation erhöhen die Ausfallsicherheit gegenüber möglichen Fehlerbedingungen mit Hosts, Netzen oder Apps. Betrachten Sie diese potenziellen Clusterkonfigurationen, die nach zunehmendem Grad der Verfügbarkeit angeordnet sind. Weitere Informationen darüber, wie die Ressourcen von IBM Cloud auf geografische Zonen und Regionen verteilt werden, finden Sie in der Dokumentation zu den Standorten.

Einzelzonencluster: Nur klassisch; Cluster mit einer Zone verfügen über Arbeitsknoten, die auf separate physische Hosts innerhalb derselben Zone verteilt sind. Diese Option schützt vor bestimmten Ausfällen, z. B. während eines Master-Updates, und ist einfacher zu verwalten. Allerdings schützt es Ihre Apps nicht, wenn in einer ganzen Zone ein Ausfall auftritt.
Mehrzonen-Cluster: Klassisch VPC; Mehrzonen-Cluster verfügen über automatisch bereitgestellte Arbeitsknoten mit drei Replikaten, die über mehrere Zonen verteilt sind. Wenn in einer ganzen Zone ein Ausfall auftritt, wird Ihre Arbeitslast auf Arbeitsknoten in den anderen Zonen verteilt, wodurch Ihre Anwendung vor dem Ausfall geschützt wird.
Mehrere Cluster, die mit Lastverteilern verbunden sind: Klassisch VPC; Mehrere Cluster können in derselben Zone oder in verschiedenen Zonen eingerichtet und über einen globalen Lastverteiler verbunden werden. Diese Option ist nützlich, wenn Sie einen Cluster in einer Region mit nur einer Zone bereitstellen müssen, aber dennoch die Vorteile der Verfügbarkeit in mehreren Zonen nutzen möchten.

Hochverfügbarkeitsfunktionen

Sehen Sie sich die Funktionen an, die Ihnen zur Verfügung stehen, um eine hohe Verfügbarkeit Ihrer Apps und Dienste zu gewährleisten.

HA-Funktionen für Red Hat OpenShift on IBM Cloud
Feature	Beschreibung
Anti-Affinitätsoptionen	Verwenden Sie Anti-Affinitätsregeln, um die Pod-Bereitstellung auf Arbeitsknoten zu verteilen, anstatt die Bereitstellung auf bestimmte Knoten zu beschränken. Dies bietet zusätzliche Flexibilität für Ihre Arbeitsbelastung.
Replikatgruppen	Wenn Sie die Verfügbarkeit der App erhöhen möchten, können Sie eine Replikatgruppe in der Bereitstellung angeben. Wenn eine App-Instanz inaktiv wird, wird von Kubernetes automatisch eine neue Instanz der App aktiviert, damit die angegebene Anzahl der App-Instanzen erhalten bleibt.
Lastverteilung in mehreren Zonen (Classic)	Wenn Sie einen klassischen Multizone-Cluster erstellen, wird automatisch ein Multizone-Lastenausgleich in jeder Zone erstellt, in der sich Ihr Cluster befindet, um alle eingehenden Anfragen an Ihre Apps zu bearbeiten und Anfragen zwischen Anwendungslastenausgleichsmodulen (ALBs) in den Zonen Ihres Clusters auszugleichen. Sie aktiviert außerdem Statusprüfungen für die öffentlichen Ingress-IP-Adressen.
VPC-Lastverteilung (VPC)	Wenn Sie einen VPC-Cluster erstellen, wird automatisch ein VPC-Lastenausgleich erstellt, mit dem Sie alle eingehenden Anfragen an Ihre Apps bearbeiten und Anfragen auf die Anwendungslastenausgleichsmodule (ALBs) in den Zonen Ihres Clusters verteilen können. Sie aktiviert außerdem Statusprüfungen für die öffentlichen Ingress-IP-Adressen.
Cluster-Autoscaler	Das Cluster-Autoscaler-Add-on skaliert die Worker-Pools in Ihrem Cluster automatisch, um die Anzahl der Worker-Knoten im Worker-Pool entsprechend den Größenanforderungen Ihrer geplanten Workloads zu erhöhen oder zu verringern.

Funktionen zur Notfallwiederherstellung

Die allgemeine Strategie für die Wiederherstellung nach einer Katastrophe besteht darin, die Speicherung und Sicherung Ihrer Daten mit Lösungen wie Portworx zu konfigurieren.

Red Hat OpenShift on IBM Cloud unterstützt die folgenden Disaster-Recovery-Funktionen:

DR-Funktionen für Red Hat OpenShift on IBM Cloud
Feature	Beschreibung
Portworx	Eine hochverfügbare softwaredefinierte Speicherlösung eines Drittanbieters, die Sie zur Verwaltung von lokalem, beständigem Speicher für Ihre containerisierten Datenbanken und andere zustandsabhängige Anwendungen oder zur gemeinsamen Nutzung von Daten durch Pods in mehreren Zonen verwenden können. Überprüfen Sie die Voraussetzungen
OpenShift Regionale Katastrophenhilfe der Data Foundation(ODF)	Eine Wiederherstellungslösung, die im Falle einer regionalen Katastrophe eine automatische Wiederherstellung mit nur einem Klick ermöglicht. Anwendungen werden automatisch an eine bestimmte OpenShift Container Platform mit einem ODF-Cluster weitergeleitet, der in einer anderen Region verfügbar ist.
Cloud Object Storage (COS)	Eine persistente, hochverfügbare Speicheroption, die als Plug-in in Ihre Apps eingebunden werden kann. Überprüfen Sie die Einschränkungen.
Automatische Wiederherstellung	Das System verwendet verschiedene Prüfungen zum Abfragen des allgemeinen Zustands von Workerknoten. Wenn die automatische Wiederherstellung mit den konfigurierten Prüfungen einen nicht ordnungsgemäß funktionierenden Workerknoten erkennt, löst sie eine Korrekturmaßnahme aus, wie das erneute Laden eines VPC-Workerknotens bzw. bei einem klassischen Workerknoten das erneute Laden des Betriebssystems.
Datenportabilität mit Velero	Eine Drittanbieteroption für den Export von Daten aus Ihrem Cluster in eine IBM-COS-Instanz oder einen anderen s3-Anbieter.
Datenportabilität über die CLI `kubectl`	Exportieren Sie Daten mithilfe der CLI `kubectl`.

Prüfen Sie weitere Optionen für den Export von Daten, wie rclone oder OADP.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO)

RTO/RPO-Funktionen für Red Hat OpenShift on IBM Cloud
Feature	RTO und RPO	Hinweise
Portworx	RTO = <60s, RPO = <60s- 15m	Die Werte unterscheiden sich zwischen asynchronen und synchronen (auch als Metro-DR bezeichnet) Konfigurationen. Weitere Informationen finden Sie unter Disaster-Recovery mit Portworx einrichten.
ODF Regionaler Katastrophenschutz	RTO = 0, RPO = 0	Diese Werte gelten nur auf der Cluster-Ebene. Regional und U-Bahn DR ist derzeit nicht verfügbar.
Cloud Object Storage	Siehe die Dokumente zur Objektspeicherung.

Wie IBM® zur Sicherstellung der Katastrophenhilfe beiträgt

IBM® ergreift im Katastrophenfall spezifische Wiederherstellungsmaßnahmen für Red Hat OpenShift on IBM Cloud.

Wie IBM sich von Fehlschlägen erholt

Bei einem Ausfall einer Zone oder Region ist IBM für die Wiederherstellung der Komponenten verantwortlich. IBM wird versuchen, den Cluster in derselben Region basierend auf dem letzten Status im internen persistenten Speicher wiederherzustellen. IBM aktualisiert und stellt operative Komponenten innerhalb des Clusters wieder her, wie den Ingress Application Load Balancer und das File Storage Plug-in.

IBM bietet auch die Möglichkeit der Integration mit anderen Diensten von IBM Cloud, z. B. mit Speicheranbietern, so dass Daten gesichert und wiederhergestellt werden können. Es liegt in Ihrer Verantwortung, diese Integrationen umzusetzen.

Wie IBM Dienste aufrechterhält

Alle Upgrades folgen den bewährten Verfahren des IBM-Dienstes, einschließlich Wiederherstellungsplänen und Rollback-Prozessen. Regelmäßige Wartungsarbeiten können zu kurzen Unterbrechungen führen, die durch die Wiederholungslogik der Client-Verfügbarkeit gemildert werden. Änderungen werden nacheinander, Region für Region und Zone für Zone innerhalb einer Region, eingeführt. IBM macht Aktualisierungen beim ersten Anzeichen eines Fehlers rückgängig.

Komplexe Änderungen werden mit Feature-Flags aktiviert und deaktiviert, um die Belichtung zu steuern.

Änderungen, die sich auf die Arbeitsbelastung der Kunden auswirken, werden in IBM Cloud-Benachrichtigungen detailliert beschrieben. Weitere Informationen zu geplanten Wartungsarbeiten, Ankündigungen und Versionshinweisen, die sich auf diesen Dienst auswirken, finden Sie unter "Überwachungsbenachrichtigungen und Status ".

Ihre Verantwortung für Hochverfügbarkeit und Notfallwiederherstellung

Es liegt in Ihrer Verantwortung, Ihren Plan für HA und DR kontinuierlich zu testen.

Es kann zu Unterbrechungen der Netzwerkverbindung und zu kurzen Ausfällen eines Dienstes kommen. Es liegt in Ihrer Verantwortung, sicherzustellen, dass der Quellcode der Anwendung eine Logik zur Wiederholung von Client-Verfügbarkeitsprüfungen enthält, um eine hohe Verfügbarkeit der Anwendung zu gewährleisten.

Sie sind dafür verantwortlich, Ihren Cluster so zu konfigurieren, dass die entsprechende Verfügbarkeit für Ihre Apps und Dienste erreicht wird. Der Verfügbarkeitsgrad, den Sie für Ihren Cluster einrichten, hat Auswirkungen auf Ihre Abdeckung in Bezug auf die Bedingungen des IBM Cloud-HA-Service-Level-Agreements. Um beispielsweise eine vollständige HA-Abdeckung gemäß den SLA-Bedingungen zu erhalten, müssen Sie einen Cluster mit mehreren Zonen mit insgesamt mindestens 6 Workerknoten einrichten, zwei Workerknoten pro Zone, die gleichmäßig auf drei Zonen verteilt sind.

Die Zuständigkeit für die Wiederstellung der im Cluster ausgeführten Workloads und der Anwendungsdaten obliegt Ihnen. Weitere Informationen zu Ihren Verantwortlichkeiten für die Wiederherstellung im Notfall finden Sie unter Ihre Verantwortlichkeiten bei der Verwendung von Red Hat OpenShift on IBM Cloud.

Änderungsmanagement

Die Änderungsverwaltung umfasst Aufgaben wie Upgrades, Konfigurationsänderungen und Löschungen. Beachten Sie die folgenden Punkte, um Ausfallzeiten oder Datenverluste für Ihre Arbeitslast zu reduzieren.

Es wird empfohlen, Benutzern und Prozessen die IAM-Rollen und -Aktionen mit den geringsten für ihre Arbeit erforderlichen Berechtigungen zuzuweisen. Schränken Sie beispielsweise die Möglichkeit ein, Produktionsressourcen zu löschen.
Verwenden Sie die API-, CLI- oder Konsolen-Tools, um die bereitgestellten Worker-Node-Updates, die Betriebssystem-Patches enthalten, anzuwenden oder um anzufordern, dass Worker-Nodes neu gestartet, neu geladen oder ersetzt werden.
Verwenden Sie die API-, CLI- oder Konsolentools, um die bereitgestellten Haupt- und Nebenupdates für Kubernetes und die Haupt-, Neben- und Patch-Arbeitsknotenupdates anzuwenden. Lesen Sie sich die Informationen und Anforderungen für jede Versionsaktualisierung durch, um Probleme oder Ausfallzeiten zu vermeiden.
Stellen Sie sicher, dass Ihre Cluster-Arbeitsknoten mit der neuesten Ubuntu version laufen.
Vergewissern Sie sich, dass Sie die Veröffentlichungspläne für alle Add-ons, die Sie in Ihrem Cluster ausführen, verstehen.

Überlegungen zur Bereitstellung von Apps und Diensten

Die Art und Weise, wie Sie Ihren Cluster konfigurieren, wirkt sich auf die Verfügbarkeit aus, die Sie für Ihre Apps und Dienste erreichen. Je breiter gefächert Sie Ihre Containerkonfiguration auf mehrere Workerknoten und Cluster verteilen, umso geringer ist die Wahrscheinlichkeit, dass Ihre Benutzer Ausfallzeiten mit Ihrer App verzeichnen.

Betrachten Sie die folgenden potenziellen App-Konfigurationen, die nach zunehmendem Grad der Verfügbarkeit angeordnet sind.

Stufen der Hochverfügbarkeit für eine App

Eine Bereitstellung mit n+2 Pods, die von einem Replikatsatz auf einem einzelnen Knoten verwaltet werden.
Bereitstellung mit n+2 Pods, deren Verwaltung durch eine Replikatgruppe erfolgt und die auf mehrere Knoten (Anti-Affinität) in einem einzelnen Cluster mit einer Zone verteilt sind.
Bereitstellung mit n+2 Pods, deren Verwaltung durch eine Replikatgruppe erfolgt und die auf mehrere Knoten (Anti-Affinität) in einem Cluster mit mehreren Zonen verteilt sind.

In der folgenden Dokumentation finden Sie Informationen zur Erstellung eines hochverfügbaren Workloads.