Erläuterungen zu Hochverfügbarkeit und Disaster-Recovery für Code Engine

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, trotz unerwarteter Ausfälle betriebsbereit und zugänglich zu bleiben. 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. ist der Prozess der Wiederherstellung des Dienstbetriebs nach einer größeren Störung.

Code Engine ist ein hochverfügbarer regionaler Dienst, der für die Aufrechterhaltung der Verfügbarkeit bei zonalen Ausfällen ausgelegt ist. Code Engine erfüllt die Service Level Objectives(SLO) mit dem Standardplan.

Weitere Informationen zu den Standards für Hochverfügbarkeit und Notfallwiederherstellung in „ IBM Cloud “ finden Sie unter „ So gewährleistet ‚ IBM Cloud ‘ Hochverfügbarkeit und Redundanz “. Darüber hinaus stehen Informationen zu Service-Level-Agreements zur Verfügung.

Verfügbarkeit von Code Engine-Instanzen

IBM Cloud® Code Engine wird an mehreren Standorten (Regionen) angeboten. Jede Region enthält drei Rechenzentren (Zonen) zur Redundanz.

Beim Bereitstellen eines Code Engine-Projekts wählen Sie den Standort (MZR) aus, in dem die Instanz erstellt wird. Die Region legt fest, wo Ihre Workloads – wie beispielsweise Anwendungen, Jobs, Funktionen und Flotten – gehostet werden.

Standardmäßig wird Ihre Workload in einer einzigen Zone bereitgestellt. Fällt die Hosting-Zone aus, wird die Workload automatisch in einer der verbleibenden Zonen neu erstellt.

Der Dienst führt kontrollierte Workload-Transfers zwischen den Zonen während des normalen Betriebs durch, z. B. für Wartungsarbeiten und Software-Upgrades. Diese Rollout-Neustarts werden sorgfältig durchgeführt, um Unterbrechungen zu minimieren. Ungeplante Failover können bei unerwarteten Ereignissen in der Betriebsumgebung auftreten.

Code Engine speichert Metadaten (einschließlich Ihrer Projekt-, Anwendungs-, Funktions-, Auftrags-, Flotten- und Image-Build-Definitionen) und repliziert sie in allen Zonen innerhalb einer Region, um die Verfügbarkeit zu gewährleisten. Da es sich um einen reinen Rechendienst handelt, ist Code Engine nicht für die Sicherstellung der Hochverfügbarkeit Ihrer Workload-Daten oder Container-Images verantwortlich. Konsultieren Sie die Dokumentation der jeweiligen Cloud-Dienste, um Anleitungen zur Gewährleistung einer hohen Verfügbarkeit zu erhalten. Befolgen Sie für die Verfügbarkeit von Container-Images die Anleitung in IBM Cloud Container Registry um sicherzustellen, dass Ihr Workload während eines zonalen Ausfalls betriebsbereit bleibt. Wenn Sie Daten in IBM Cloud Object Storage oder einem anderen IBM Cloud Datenbank- oder Speicherdienst lesen oder speichern, lesen Sie die Dokumentation des jeweiligen Dienstes für Hochverfügbarkeitsfunktionen.

Code Engine regionaltopologie Regionaltopologie Regionaltopologie — Code Engine

Code Engine Regionen

In der folgenden Tabelle sind die Regionen, in denen Code Engine verfügbar ist, und ihr Hochverfügbarkeitsstatus aufgeführt.

Hochverfügbare Code Engine Regionen
Geografische Region	Bereich	Hochverfügbarkeit (HA)
Asien/Pazifik	Australien, Sydney (`au-syd`)	MZR
Asien/Pazifik	Indien, Chennai (`in-che`)	MZR
Asien/Pazifik	Japan, Osaka (`jp-osa`)	MZR
Asien/Pazifik	Japan, Tokio (`jp-tok`)	MZR
Europa	Deutschland, Frankfurt (`eu-de`)	MZR
Europa	Spanien, Madrid (`eu-es`)	MZR
Europa	Großbritannien, London (`eu-gb`)	MZR
Nordamerika	Kanada, Toronto (`ca-tor`)	MZR
Nordamerika	USA, Dallas (`us-south`)	MZR
Nordamerika	USA, Washington (`us-east`)	MZR
Südamerika	Brasilien, São Paulo (`br-sao`)	MZR

Eine Geografie ist ein geografisches Gebiet, das eine oder mehrere Regionen umfasst. Jede Region umfasst mehrere Verfügbarkeitszonen, um den Anforderungen hinsichtlich lokalem Zugriff, geringer Latenz und Sicherheit gerecht zu werden. Jede Multizonen-Region(MZR) besteht aus drei oder mehr unabhängigen Zonen, wodurch sichergestellt wird, dass einzelne Fehlerereignisse nur eine Zone betreffen.

Disaster-Recovery für Code Engine-Instanzen

Bei einer großen regionalen Katastrophe – wie beispielsweise einem Erdbeben, einer Überschwemmung oder einem Unwetter – kann eine ganze Region betroffen sein. Um sicherzustellen, dass Ihre Workloads gegenüber solchen Ereignissen widerstandsfähig sind, sollten Sie diese über mehrere MZRs verteilen und mithilfe eines Edge-Proxy-Dienstes einen automatischen Failover-Mechanismus implementieren. Sie können zum Beispiel Folgendes verwenden IBM Cloud® Internet Services. Weitere Informationen zum Bereitstellen einer Anwendung in mehreren Regionen finden Sie im Thema Anwendung mit einem angepassten Domänennamen in mehreren Regionen bereitstellen.

Code Engine globale Topologie globale Topologie globale Topologie — Code Engine

Wie IBM die Wiederherstellung im Katastrophenfall unterstützt

Code Engine-Instanzen sichern

IBM Cloud erstellt automatisch eine Sicherungskopie der Code Engine Projekt-Metadaten und speichert sie in einem überregionalen Speicher für Disaster Recovery-Zwecke.

Regionenübergreifende Endpunkte
Code Engine-Region	Regionsübergreifender Endpunkt
`au-syd`	`AP`
`br-sao`	`BR`
`ca-tor`	`CA`
`eu-de`	`EU`
`eu-es`	`EU`
`eu-gb`	`EU`
`jp-osa`	`AP`
`jp-tok`	`AP`
`us-east`	`US`
`us-south`	`US`

Um unbeabsichtigte Auswirkungen auf Ihre Workloads zu vermeiden - wie etwa die Duplizierung von Aufträgen oder die Bereitstellung unerwünschter Anwendungsinstanzen - stellt Code Engine Ihre Workloads nicht automatisch wieder her. Die Wiederherstellung Ihrer Arbeitsbelastung liegt in Ihrer Verantwortung. Weitere Informationen finden Sie unter Informationen zu den Verantwortlichkeiten des Kunden bei der Verwendung von Code Engine.

Wiederherstellungszeit-Ziel (RTO) und Wiederherstellungspunkt-Ziel (RPO)

Das Wiederherstellungszeitziel (Recovery Time Objective, RTO) ist die maximal akzeptable Zeit, die ein System, eine Anwendung oder ein Geschäftsprozess offline sein kann, bevor es zu erheblichen geschäftlichen Auswirkungen kommt.
Das Recovery Point Objective (RPO) definiert den maximal akzeptablen Datenverlust (gemessen in Zeit) nach einem HA- oder DR-Ereignis.

IBM führt regelmäßig HA/DR-Tests durch, die HA-Failover, isolierte DR-Szenarien (ohne kundeneigene Daten und Workload-Definitionen), Datenwiederherstellung und die Simulation nichttechnischer Parameter umfassen.

Während dieser Tests werden die RTO- (Wiederherstellungszeit) und RPO- (Wiederherstellungspunkt) Ziele gemessen und überprüft.

RTO/RPO-Ziele
Ziel	Ziel
Automatisches Failover bei zonalem Ausfall	RTO = Sekunden, RPO = 0
Disaster Recovery mit Ausnahme der Wiederherstellung von kundeneigenen Artefakten	RTO = Stunden, RPO = 1 Tag

Disaster-Recovery planen

Zusätzlich zu den HA/DR-Tests von IBM müssen Sie Ihre Disaster-Recovery-Verfahren regelmäßig üben. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.

HA/DR-Ereignisse und Auflösung
Ereignis	Lösung
Hardware-Ausfall (Recheninfrastruktur)	IBM stellt eine Infrastruktur zur Verfügung, die gegenüber einzelnen Hardwareausfällen innerhalb einer Zone widerstandsfähig ist - keine Konfiguration erforderlich.
Zonenfehler	Automatisches Failover (siehe Verfügbarkeit von Code Engine Instanzen ). Die Arbeitslast wird automatisch in eine verfügbare Zone verschoben.
Datenbeschädigung	Sie sind für die Erstellung von Sicherungskopien Ihrer Daten verantwortlich.
Regionales Versagen	Keine automatische Ausfallsicherung. Wie in Disaster Recovery für Code Engine Instances beschrieben, sollten Sie Ihren Workload in einer zweiten Multizonen-Region bereitstellen.
Verfügbarkeit der Arbeitslast	Sie sind dafür verantwortlich, Ihre Geschäftsanwendungen so zu implementieren, dass der Zustand von externen Speichern oder Datenbanken wiederhergestellt werden kann.
HA/DR-Belastbarkeit	Sie sind dafür verantwortlich, dass geschultes Personal für die Verwaltung Ihrer Komponenten und die Wiederherstellung Ihrer Arbeitslasten und kundeneigenen Daten während eines Ausfalls zur Verfügung steht.

Ihre Verantwortlichkeiten für HA und DR

Verwenden Sie die folgenden Checklisten, die zu jedem Merkmal gehören, um Ihren Plan zu erstellen und zu üben.

Container-Images, die für IBM Cloud® Code Engine Anwendungen, Aufträge und Flotten verwendet werden

Überprüfen Sie, ob Ihre Container-Images in Ihrer IBM Cloud Container Registry Backup-Region verfügbar sind.
Codebündel für IBM Cloud® Code Engine Funktionen

Überprüfen Sie, ob Ihre Code-Bundles in Ihrer IBM Cloud Container Registry Backup-Region verfügbar sind.

Ein umfassender Testplan für Hochverfügbarkeit (HA) und Disaster Recovery (DR) beinhaltet die Definition Ihrer RTO- und RPO-Ziele, die Identifizierung kritischer Systeme und die Überprüfung der Integrität von Backups, Netzwerk-Failover und Datensynchronisation. Zu den wichtigsten Schritten gehören die Simulation von Ausfällen (z. B. Knotenausfälle oder Standortausfälle), die Ausführung von Failover-Verfahren, die Überprüfung der Systemfunktionalität und die Dokumentation des Fallback-Prozesses.

Testvorbereitung
- Definieren Sie Ziele: Bestätigen Sie Ihr Recovery Time Objective (RTO) und Recovery Point Objective (RPO).
- Identifizieren Sie kritische Systeme: Listen Sie alle Systeme, Daten und Anwendungen auf, die eine Ausfallsicherung erfordern.
- Legen Sie die Rollen des Teams fest: Legen Sie die Zuständigkeiten für das DR-Team fest und bestimmen Sie einen Hauptansprechpartner.
- Überprüfung der Backups: Bestätigen Sie, dass die Backups gültig und zugänglich sind.
- Isolierung der Umgebung: Isolierung von Testsystemen, um unbeabsichtigte Auswirkungen auf die Produktionsumgebung zu verhindern.
Durchführung des Tests
- Ausfallszenario simulieren: Initiieren Sie einen geplanten Ausfall, z. B. die Unterbrechung der Netzwerkverbindung, das Anhalten eines Dienstes oder das Herunterfahren eines Primärservers.
- Failover-Ausführung: Führen Sie das dokumentierte Failover-Verfahren zum sekundären/DR-Standort aus.
- Überprüfen Sie die Datenintegrität: Verwenden Sie Prüfsummen oder Hash-Werte, um sicherzustellen, dass die Daten nicht beschädigt sind.
- Anwendungsvalidierung: Testen Sie die Funktionalität der Anwendungen auf der DR-Site.
- DNS/Verkehrsumleitung: Bestätigen Sie, dass der Benutzerverkehr zum neuen aktiven Knoten umgeleitet wird.
Post-Test und Dokumentation
- Failback durchführen: Bringen Sie die primäre Site wieder online und synchronisieren Sie die Daten erneut.
- Dokumentieren Sie die Ergebnisse: Halten Sie Zeiten, Erfolge und eventuelle Abweichungen vom Plan fest.
- Lücken aufdecken: Stellen Sie Mängel im Plan fest und aktualisieren Sie die Verfahren entsprechend.
- Kommunikationsprüfung: Überprüfen Sie, ob die Benachrichtigungen an alle Beteiligten versandt wurden.
Allgemeine Testszenarien
- HA-Test: Lokaler Failover auf einen Standby-Knoten (z. B. im selben Rechenzentrum).
- DR-Test: Vollständige Ausfallsicherung an einem geografisch getrennten Standort.
- Datenwiederherstellung: Vollständige Wiederherstellung der kundeneigenen Daten und Workload-Artefakte von einem Backup-Datenspeicher zum primären oder ausgewählten Backup-Speicherort.
- Verfügbarkeit des Personals: Testen Sie die betrieblichen Auswirkungen, wenn wichtige Mitarbeiter nicht verfügbar sind oder keine Verbindung zu Ihren Systemen herstellen können.