Schutz der Service-Datenebene vor Fehlern der Steuerungsebene

Die Architektur des Dienstes IBM Cloud trennt Komponenten für die Datenebene und die Steuerungsebene.

Die Komponenten der Datenebene sind für die Bereitstellung der Hauptfunktionen des Dienstes verantwortlich. Die Komponenten der Datenebene verarbeiten Anfragen von Benutzern und Client-Anwendungen, wie z. B. die Implementierung von Datenverarbeitung, Persistenz, Lastausgleich und mehr.

Die Zuständigkeiten auf der Datenebene sind zum Beispiel folgende:

• Ausführen und Hosten der virtuellen Serverinstanz (VSI)
• Lesen und Schreiben auf Blockspeicher-Volumes
• Abrufen und Einstellen von Objekten in Object Storage Buckets
• Ausführen, Verarbeiten von Abfragen und Aktualisieren von IBM Cloud Databases for PostgreSQL

Die Komponenten der Steuerebene sind für die Verwaltung und Konfiguration der Komponenten der Datenebene zuständig, damit diese funktionieren. Die Komponenten der Steuerungsebene verarbeiten Anfragen von Administratoren, um den Lebenszyklus der Datenebene durch die Phasen der Ressourcenerstellung, Konfiguration, Aktualisierung und Stilllegung von Serviceinstanzen zu verwalten.

Zu den Zuständigkeiten auf der Steuerungsebene gehören beispielsweise die folgenden:

• Auflistung der VSI im Konto und Bereitstellung einer neuen VSI, Orchestrierung der Erstellung virtueller Maschinen aus einem Betriebssystem-Image, Erstellung von Blockspeicher, Anbindung und Konfiguration der Netzwerkendpunkte
• Konfigurieren, Ändern der Größe und Einhängen von Blockspeicher-Volumes
• Erstellen neuer Object Storage Buckets

Um die Ausfallsicherheit und die Geschäftskontinuität zu verbessern, sind die Datenebenen der Dienste so konzipiert, dass sie ihre primäre Funktion auch bei einem Ausfall der Steuerungsebene weiterhin erfüllen. So ist beispielsweise der Zugriff der Datenebene auf Infrastrukturressourcen bei der Bereitstellung nicht von der Steuerungsebene abhängig und wird daher nicht von Problemen der Steuerungsebene beeinflusst.

Ein Ausfall der Steuerebene kann sich auf die Fähigkeit auswirken, Ressourcen zu erstellen, zu ändern oder zu löschen, hat aber keine Auswirkungen auf die vorhandenen Ressourcen, die weiterhin verfügbar sind.

Zonale Unabhängigkeit des Dienstes

Zonale Dienste ermöglichen die Anforderung von Dienstinstanzen, die in einer bestimmten Zone einer Multizonenregion oder einem bestimmten Rechenzentrum bereitgestellt werden.

Diese Service-Instanzen, die in einer bestimmten Zone oder einem bestimmten Rechenzentrum bereitgestellt werden, werden innerhalb ihrer Region unabhängig implementiert und betrieben, ohne Abhängigkeiten von Komponenten der Services in anderen Zonen oder Rechenzentren. Daher können sich Ausfälle in einer Zone zwar auf die Instanz auswirken, die in dieser Zone gehostet wird, nicht aber auf Instanzen in anderen Zonen in derselben oder in anderen Regionen.

Zonale Dienstarchitekturen verwenden eine zonale Datenebene, die in jeder Zone einer Region eingesetzt und von der lokalen Steuerebenenkomponente in der Region verwaltet wird.

Der Benutzer oder die Anwendung interagiert mit der Dienstinstanzfunktion, indem er einen zonalen API-Endpunkt verwendet, der sich in jeder Zielzone befindet.

Die Dienstesteuerungsebene befindet sich mit einigen Ausnahmen, die unter Globale Dienstredundanz beschrieben werden, in derselben Region wie die Datenebene und wird in drei Zonen der Regionen eingesetzt. Sie ist unabhängig von Kontrollebenen in anderen Regionen. Daher kann sich ein Ausfall der Steuerungsebene in einer Region nur auf die Dienstfunktionen in dieser Region, nicht aber auf die Dienstfunktionen in anderen Regionen auswirken.

Bei einem Ausfall der Steuerungsebene in einer Zone oder bei Nichtverfügbarkeit einer Zone werden Administratoranfragen zur Verwaltung der Lebenszyklusphasen der Datenebene, wie z. B. Erstellung, Konfiguration, Aktualisierung und Stilllegung von Ressourcen, von der Steuerungsebene in den beiden verbleibenden Zonen ausgeführt.

In Ausnahmefällen, in denen die Steuerebene global eingesetzt wird, wird sie dennoch über mehrere Regionen hinweg eingesetzt, um eine hohe Verfügbarkeit zu gewährleisten. Daher hätten Ausfälle in einer Region keine Auswirkungen auf die Dienstfunktionen in den anderen Regionen.

Weitere Informationen zu den spezifischen Optionen für die Bereitstellung Ihrer Workloads, die einen zonalen Dienst verwenden, finden Sie unter Standorte für die Ressourcenbereitstellung und Überlegungen zur hohen Verfügbarkeit.

Regionale Dienstredundanz

Regionale Dienste ermöglichen die Anforderung von Dienstinstanzen in einer bestimmten Region als Ganzes, ohne dass eine einzelne Zielzone oder ein Rechenzentrum angegeben werden muss.

Diese Service-Instanzen, die in einer Region eingesetzt werden, werden mit redundanten Komponenten implementiert und betrieben, die in mehreren Zonen innerhalb derselben Region eingesetzt werden. Auf diese Weise gibt es keinen einzigen Ausfallpunkt in einer bestimmten Zone innerhalb einer Region.

Die regionale Service-Architektur verwendet eine regionale Datenebene, die über 3 Zonen in jeder Region verteilt ist und von der lokalen Steuerungsebene in der Region verwaltet wird. Fällt die Datenebene in einer Zone aus oder ist eine Zone nicht verfügbar, werden die Anfragen von Benutzern und Client-Anwendungen automatisch an die Datenebene in den beiden anderen Zonen weitergeleitet.

Der Benutzer oder die Anwendung interagiert mit der Dienstinstanzfunktion über einen regionalen API-Endpunkt, der sich in jeder Zielregion befindet.

Die Dienststeuerungsebene befindet sich mit einigen Ausnahmen, die unter Globale Dienstredundanz beschrieben sind, in derselben Region wie die Datenebene und wird in drei Zonen der Regionen unabhängig von den Steuerungsebenen anderer Regionen eingesetzt. Auf diese Weise können sich Ausfälle der Steuerungsebene in einer Region nur auf die Dienstfunktionen in dieser Region auswirken und nicht auf die Dienstfunktionen in anderen Regionen.

Bei einem Ausfall der Steuerungsebene in einer Zone oder sogar bei einem vollständigen Verlust werden die Anforderungen der Administratoren zur Verwaltung des Lebenszyklus der Datenebene durch die Phasen der Ressourcenerstellung, Konfiguration, Aktualisierung und Außerbetriebnahme von Dienstinstanzen von der Steuerungsebene in den verbleibenden Zonen ausgeführt.

Selbst in den Ausnahmefällen, in denen die Steuerungsebene global eingesetzt wird, wird sie über mehrere Regionen hinweg eingesetzt, um eine hohe Verfügbarkeit zu gewährleisten und sicherzustellen, dass Ausfälle in einer Region keine Auswirkungen auf die Dienstfunktionen in anderen Regionen haben.

Weitere Informationen zu den spezifischen Optionen für die Bereitstellung Ihrer Workloads, die einen regionalen Dienst verwenden, finden Sie unter Standorte für die Ressourcenbereitstellung und Überlegungen zur hohen Verfügbarkeit.

Globale Dienstredundanz

Eine Untergruppe der IBM Cloud verwendet ein globales Bereitstellungsmodell mit Komponenten, die in mehreren Regionen an unterschiedlichen Standorten und Geografien eingesetzt werden. Diese Dienste bieten gemeinsame Funktionen, von denen andere zonale oder regionale Dienste abhängen. Innerhalb eines Dienstes gibt es auch spezielle Komponenten der Steuerungsebene, die globale Funktionen bereitstellen.

Dienste, die ein globales Bereitstellungsmodell verwenden, implementieren eine verteilte Architektur mit Komponenten, die in mehreren Regionen repliziert werden. Die Komponenten werden über diese Regionen hinweg mit einem automatischen Failover ausgeglichen, um die Dienste ohne Eingreifen des Betreibers am Laufen zu halten.

In den folgenden Abschnitten werden Dienste, die ein globales Bereitstellungsmodell verwenden, und ihre regionsübergreifenden Auswirkungen auf die Abhängigkeiten von anderen zonalen oder regionalen Diensten beschrieben.

Dieser Ansatz trägt dazu bei, einzelne Fehlerpunkte in Ihrer Architektur zu beseitigen, kann jedoch potenziell regionsübergreifende Auswirkungen haben, selbst wenn Sie in einer anderen Region arbeiten als dem Ort, an dem die globale Dienststeuerungsebene gehostet wird.

Redundanz des Netzwerk-Backbones

Das IBM Cloud ist so konzipiert, dass es nie zu einem einzelnen Ausfallpunkt kommt. An jedem Punkt des Netzes besteht eine vielfältige, redundante Konnektivität, indem innerhalb jeder Region möglichst verschiedene Telekommunikationsanbieter für dieselbe Dienstkonnektivität genutzt werden.

{Für die Anbindung der Edge-Standorte an alle regionalen Rechenzentren werden verschiedene IBM Cloud eingesetzt. Darüber hinaus verfügt jeder Edge-Standort über ein redundantes Backbone für die Anbindung an andere Regionen und ist direkt oder indirekt über eine lokale Vermittlungsstelle mit mehreren Anbietern verbunden.

Isolierung zonaler und regionaler Dienste von regionsübergreifenden Abhängigkeiten

Wenn ein Ereignis die Verfügbarkeit in einer Region beeinträchtigt, sind im Allgemeinen nur die zonalen und regionalen Dienste in dieser Region betroffen. Die Dienste in anderen Regionen sind davon nicht betroffen.

Die Datenebenen von zonalen und regionalen Diensten stützen sich auf Ressourcen innerhalb derselben Region, einschließlich wesentlicher Abhängigkeiten wie Infrastruktur, Container-Orchestrierung, Datenbanken, Sicherheit und mehr.

Die Datenebene eines Dienstes, der sich in einer Region befindet, hängt auch von Dienstinstanzen ab, die vom Benutzer zur Unterstützung der folgenden Dienst-zu-Dienst-Funktionen bereitgestellt werden:

• {Instanz Key Protect Bring-your-own-key (BYOK) Verschlüsselungsunterstützung.
• {Instanz für die Unterstützung der KYOK-Verschlüsselung (keep-your-own-key) Hyper Protect Crypto Services
• Object Storage Buckets zum Speichern von Backups, Security Control Center Beweisen und Ergebnissen, archivierten Protokollen, und so weiter, und im Allgemeinen für jede Funktion, die das Speichern oder Verarbeiten großer Datenmengen in oder aus Object Storage Buckets unterstützt.

Wählen Sie die Region für die Zuweisung der Dienste sorgfältig aus, um die Verfügbarkeit zu gewährleisten. Es wird empfohlen, Dienste in der gleichen Region wie abhängige Dienste zu platzieren, um die Auswirkungen eines regionsübergreifenden Ausfalls zu verhindern.

Die Dokumentation zu den einzelnen Diensten enthält klare Anweisungen, wie sie zu verwenden sind, wie sie zu platzieren und zu konfigurieren sind und wie die Architektur ihrer Anwendungen aussehen muss, um die gewünschte Ausfallsicherheit zu erreichen.