Hochverfügbarkeit und Disaster-Recovery für IBM Cloud VPC
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. 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 der Service-Instanz in einen funktionierenden Zustand.
IBM Cloud® Virtual Private Cloud ist ein hochverfügbarer Dienst, der auf die Erfüllung der Service Level Objectives(SLO ) ausgerichtet ist. Sie besteht aus zonalen und regionalen Diensten.
Weitere Informationen über die verfügbaren Regionen und Rechenzentrumsstandorte finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.
Architektur für hohe Verfügbarkeit
VPC-Ressourcen sind in Control Plane- und Data Plane-Services unterteilt, damit Kunden hochverfügbare Anwendungen auf Basis von VPC erstellen können. Die Steuerebene dient zur Bereitstellung und Verwaltung von VPC-Ressourcen (Erstellen, Aktualisieren, Löschen) und zur Bereitstellung von Kontrollfunktionen. Die Datenebene ist die Sammlung der bereitgestellten VPC-Ressourcen wie virtuelle Serverinstanzen, schwebende IP-Adressen, Sicherheitsgruppen, Blockspeicher und mehr.
Die Steuerebene wird zonenübergreifend auf redundanter Hardware gehostet, was die Ausfallsicherheit bei Hardware- und Zonenausfällen gewährleistet. Die Steuerebene und die Datenebene befinden sich in unterschiedlichen Fehlerdomänen. Ein Ausfall der Steuerungsebene hat beispielsweise keine Auswirkungen auf die Verfügbarkeit der Datenebene. Alle bestehenden Kundenressourcen laufen ohne jegliche Beeinträchtigung weiter. Um die Ausfallsicherheit zu erhöhen, können Benutzer Anwendungen aus redundanten Datenebenenressourcen erstellen.
Die VPC-Ressourcen werden je nach ihrem Umfang in zonale und regionale Ressourcen unterteilt. Einige Ressourcen, wie z. B. VPC, erstrecken sich über mehrere Zonen und werden als regionale Ressourcen betrachtet. Die meisten Ressourcen sind zonenabhängig und stehen in einer bestimmten Zone zur Verfügung. So existieren beispielsweise Subnetze, Zugriffskontrolllisten, Sicherheitsgruppen, Routing-Tabellen, öffentliche Gateways und Virtual Private Endpoint-Gateways in der Zone, in der sie erstellt wurden.
Weitere Informationen zum Schutz der Datenebene vor Fehlern in der Steuerungsebene, zur Unabhängigkeit von zonalen Diensten und zur Redundanz regionaler Dienste finden Sie unter IBM Cloud service architecture for high availability and resiliency.
Zonenfehler
Bei einem vollständigen Ausfall einer Zone sind sowohl die Steuerebene als auch die Datenebene in dieser Zone betroffen. Die Kontrollfunktionen in den betroffenen Zonen sind nicht verfügbar, und alle zonalen Ressourcen sind ausgefallen. So sind beispielsweise virtuelle Serverinstanzen in der betroffenen Zone nicht verfügbar und werden nicht in eine andere gesunde Zone verschoben. Alle Änderungen, die an den regionalen Ressourcen vorgenommen werden, werden in der ausgefallenen Zone erst wirksam, wenn die Zone wiederhergestellt ist.
Die Datenebene in anderen Zonen ist davon nicht betroffen, und alle zonalen Ressourcen in den nicht betroffenen Zonen funktionieren weiterhin ohne Unterbrechung. Regionale Ressourcen wie VPC laufen in den gesunden Zonen weiter. Die Steuerungsebene ist hochverfügbar und ermöglicht es den Diensten, die Ressourcen in den anderen nicht betroffenen Zonen zu verwalten.
Kunden sollten Mechanismen zur Verwaltung der Hochverfügbarkeit ihrer Anwendungen entwickeln, indem sie die Ressourcen über Zonen (Ausfalldomänen) verteilen und eine Notfallwiederherstellung planen.
Regionales Versagen
Im ungewöhnlichen Fall einer regionalen Katastrophe werden alle zugrunde liegenden Probleme gelöst und die VPC-Kontrollebene wiederhergestellt, wobei der Schwerpunkt auf der Verringerung des Datenverlusts für Ressourcen liegt. Die Datenebene wird ebenfalls wiederhergestellt, indem der Zustand der Kundendaten aus dem Speicher mit dem Ziel wiederhergestellt wird, das Wiederherstellungspunktziel (RPO) und das Wiederherstellungszeitziel (RTO) zu erreichen.
In einer Region mit nur einem Campus und mehreren Zonen (SC-MZR) kann sich ein Ausfall des Rechenzentrums auf die gesamte Region auswirken, da die Zonen enger miteinander verbunden sind. Die Dienste sollten Sicherungs- und Wiederherstellungsstrategien für ein anderes MZR anwenden, um Datenverluste zu vermeiden.
Hardware-Ausfälle
Die Ressourcen werden von zuverlässiger und oft redundanter Hardware bereitgestellt, aber ein unvorhergesehener Hardwareausfall könnte diese Ressourcen zum Erliegen bringen. So kann beispielsweise eine virtuelle Serverinstanz ausfallen, wenn
die zugrunde liegende Hardware ausfällt. In dieser Situation bestimmt die Wiederherstellungsrichtlinie für Host-Ausfälle, wie der virtuelle Server wiederhergestellt wird. Wenn
der Fehler auftritt und die Wiederherstellungsrichtlinie für Hostfehler auf die Standardeinstellung restart gesetzt ist, erkennt die Steuerungsebene den Hardwarefehler und migriert den virtuellen Server auf verfügbare Hardware
in derselben Zone und startet den virtuellen Server neu. Ephemerer Plattenspeicher wird nicht auf dem Boot-Volume wiederhergestellt. Datenvolumina sind verfügbar, aber es fehlen möglicherweise Schreibzugriffe von Anwendungen oder des Betriebssystems,
die zum Zeitpunkt des Ausfalls nicht gespeichert wurden.
Blockvolumina werden durch redundante Hardware mit fortschrittlichen Replikationstechniken gesichert, um die Ausfallsicherheit zu erhöhen. Eine zonale Katastrophe oder ein Multi-Hardware-Ausfall kann jedoch zu einem Ausfall des Blockvolumens führen. Sicherung und Wiederherstellung sind ein geeigneter Ansatz zur Eindämmung von Datenverlusten oder -beschädigungen. Dieser Ansatz kann auch verwendet werden, um eine regionale Katastrophe abzufedern, indem Daten in andere IBM Cloud Regionen repliziert werden. Die Snapshot-Funktion kann zur Unterstützung von Sicherung und Wiederherstellung verwendet werden. Kunden können ihre Anwendungen auch auf andere Zonen verteilen, um Unterbrechungen zu vermeiden und RPO/RTO zu verbessern.
Es kann eine starke Ausfallkorrelation zwischen der Speicherung von Datenträgern und dem Ausfall der zugehörigen Serveranwendung bestehen. Stellen Sie sicher, dass Sie Arbeitslasten untersuchen und testen, um das Anwendungsverhalten bei einem ausgefallenen Speichergerät zu bestimmen.
Informationen zu Bare-Metal-Servern und dem zugehörigen Speicher finden Sie unter Speicherübersicht für Bare Metal Servers for VPC. Snapshots sind für lokale Festplatten auf Bare-Metal-Servern nicht verfügbar. Die Kunden müssen die Hochverfügbarkeit und Notfallwiederherstellung für diese Geräte verwalten.
Aufbau von HA-Anwendungen
Sie können einen VPC-Loadbalancer verwenden, um eingehende Anforderungen auf mehrere virtuelle Server und Bare-Metal-Server zu verteilen. Virtuelle Server und Bare-Metal-Server, die nicht mehr verfügbar sind, reagieren nicht mehr auf Zustandsprüfungen; der Load Balancer gleicht dann die Last auf den verfügbaren Ressourcen aus. Sie können einen Application Load Balancer (ALB) verwenden, um den Datenverkehr eines Workloads auf virtuelle Server in mehreren Zonen zu verteilen und Workloads zu erstellen, die auch dann verfügbar sind, wenn eine ganze Zone nicht verfügbar ist.
Wenn der ALB selbst auf zonenübergreifenden Subnetzen konfiguriert ist, ist er gegen den Ausfall einer einzelnen Zone gewappnet. Der Network Load Balancer ist ein zonaler Dienst, der auf mehrere zugrunde liegende virtuelle Server verteilt ist und auch bei einem Ausfall eines einzelnen virtuellen Servers stabil bleibt.
Die grundlegende Strategie zur Verbesserung der Verfügbarkeit von Workloads, die aus VPC-Ressourcen aufgebaut sind, besteht darin, den Workload auf mehrere Ressourcen zu verteilen. Es ist möglich, Ressourcen innerhalb einer Zone, über mehrere Zonen in einer Multizonenregion (MZR) oder über mehrere Regionen zu verteilen. Weitere Informationen finden Sie unter Bereitstellung isolierter Workloads über mehrere Standorte und Zonen hinweg; diese Strategie verwendet IBM Cloud Internet Services (CIS) und einen Global Load Balancer.
Funktionen für hohe Verfügbarkeit
IBM Cloud VPC unterstützt die folgenden Hochverfügbarkeitsfunktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Application Load Balancer | Ein ALB verteilt die Last über Zonen hinweg auf IP-Adressen. | Die Arbeitslast muss skalierbar sein. |
| Netzlastausgleichsfunktion | Ein NLB verteilt die Last auf IP-Adressen innerhalb einer Zone. | Die Arbeitslast muss skalierbar sein. |
| Auto Scale for VPC | Verbessern Sie Leistung und Kosten durch die dynamische Erstellung virtueller Serverinstanzen, um den Anforderungen Ihrer Umgebung gerecht zu werden. | Die Arbeitslast muss skalierbar sein. |
| Load Balancer und Instanzgruppe | Skalierbare Workloads, die von einem Load Balancer gesteuert werden, verteilen die Last auf mehrere Instanzen in verschiedenen Zonen. | Die Arbeitslast muss skalierbar sein. |
Als Kunde können Sie die HA erstellen und unterstützen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Skalierbare Arbeitsbelastung | Erstellen Sie einen virtuellen Server oder einen Bare-Metal-Server-basierten Workload, der horizontal mit weiteren Servern skaliert werden kann. | Nicht alle Workloads können horizontal skaliert werden. |
Skalierbare Arbeitsbelastung
Skalierbare Workloads können durch Hinzufügen weiterer Server, auf denen dasselbe Image ausgeführt wird, eine erhöhte Nachfrage bewältigen. Die skalierbare Arbeitslast kann durch den Einsatz von Load Balancern und Auto Scale für VPC realisiert werden.
Architektur zur Wiederherstellung im Katastrophenfall
Die Strategie für Disaster Recovery besteht darin, eine Skriptautomatisierung zur Wiederherstellung eines VPC-Workloads an einem Wiederherstellungsstandort bereitzustellen. Wenn zum Beispiel eine Region nicht mehr verfügbar ist, liegt es in der Verantwortung des Kunden, die Arbeitslast und die damit verbundenen Daten in eine verfügbare Region zu migrieren. IBM bietet Unterstützung für das Terraform-Infrastruktur-als-Code-System, das zur Definition von Arbeitslasten mit parametrisierten Standorten und Leistungen verwendet werden kann. Die VPC-API, das SDK und die Befehlszeilenschnittstelle können von Kunden zur Erstellung von Skripten für die Wiederherstellung von Ressourcen an einem verfügbaren Standort während einer Katastrophe verwendet werden. Weitere Informationen finden Sie unter Planung der Notfallwiederherstellung.
Weitere Informationen über die Verwendung von IBM Cloud Object Storage, IBM Cloud Schematics, die Terraform-as-a-Service und einsatzfähige Architekturen bieten, finden Sie unter Verwendung von IBM Cloud services in Ihrer Disaster Recovery.
Funktionen zur Wiederherstellung im Katastrophenfall
IBM Cloud VPC unterstützt die folgenden Disaster-Recovery-Funktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Einzelne Volume-Snapshots | Ein Snapshot ist eine zeitpunktgenaue Kopie Ihres Boot- oder Datenvolumes. Block Storage snapshots werden in der regionalen Instanz Cloud Object Storage gespeichert. | Ein Snapshot ist unabhängig von seinem Quellvolume. Wenn die Zone des Quellvolumens nicht verfügbar ist, kann der Snapshot verwendet werden, um ein neues Volume in einer anderen Zone der Region zu erstellen. Snapshots können bei Bedarf in der Konsole, über die CLI, mit der API oder Terraform erstellt werden. Sie können auch mit Hilfe des Dienstes Backup für VPC geplant werden. |
| Überregionale Snapshot-Kopien | Sie können regionsübergreifende Snapshot-Kopien verwenden, die unabhängig von ihren Quell-Snapshots sind, um neue Volumes zu erstellen. | Snapshots können manuell in der Konsole, über die Befehlszeilenschnittstelle (CLI) oder programmatisch mit der API oder Terraform in eine andere Region kopiert werden. Sie können auch die Erstellung einer Kopie in einer anderen Region in Ihre Sicherungsrichtlinie aufnehmen. |
| Schnappschüsse der Konsistenzgruppe | Eine Snapshot-Konsistenzgruppe enthält Snapshots von mehreren Block Storage Volumes, die an dieselbe virtuelle Serverinstanz angeschlossen sind. | Wenn Sie einen Snapshot einer Konsistenzgruppe anfordern, erstellt das System Snapshots von allen gekennzeichneten Block Storage Volumes, die gleichzeitig an die virtuelle Serverinstanz angeschlossen sind. Sie können Boot-Volumes ein- oder ausschließen. Der Instanzenspeicher ist nicht enthalten. |
| Schnappschüsse schnell wiederherstellen | Schnelle Wiederherstellungs-Snapshots sind Snapshots, die in der Zone mit dem übergeordneten Block-Volume zwischengespeichert werden. Wenn Sie einen virtuellen Server mit einem bootfähigen Schnellwiederherstellungs-Snapshot erstellen, ist der Server schneller voll funktionsfähig, als wenn Sie sein Boot-Volume aus einem normalen Snapshot bereitstellen. | |
| Dateifreigabe-Replikation | Wenn die Quellfreigabe nicht mehr verfügbar ist, können Sie einen Replikations-Failover auf die Replikatfreigabe initiieren. | Sie können eine Replikatfreigabe in einer anderen Zone der gleichen Region erstellen. Sie können auch eine Replik in einer anderen Region in derselben Geografie erstellen. Sie können Ihre Daten alle 15 Minuten replizieren. |
Die Wiederherstellung eines Volumes oder einer Freigabe aus einem Snapshot ist ein manueller Vorgang, der Zeit in Anspruch nimmt. Wenn Sie ein höheres Serviceniveau für Disaster Recovery benötigen, finden Sie unter IBM Cloud die Backup- und Recovery-Services.
Als Kunde können Sie zusätzliche Disaster-Recovery-Optionen erstellen und unterstützen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Externe Quelle der Wahrheit für die VPC-Konfiguration | Aufbau von VPC, Netzwerk und Servern, die in vom Kunden verwalteten Konfigurationsdateien wie Terraform-Skripten, Shell-Skripten oder Programmen erfasst werden. | Der Kunde muss das Skript erstellen und die Konfiguration an einem Ort aufbewahren, an dem sie im Falle einer möglichen Katastrophe verwendet werden kann. |
| Vom Kunden erstellte Skripte für die Sicherung und das Kopieren von Dateien | Kopieren Sie den Inhalt einer Dateifreigabe, um ihn an einem anderen Ort verfügbar zu machen. | Der Kunde muss das Skript erstellen oder die vom Kunden verwaltete kontinuierliche Sicherung und Wiederherstellung verwenden. |
| Vom Kunden verwaltete kontinuierliche Sicherung und Wiederherstellung für Blockvolumes und Dateispeicher | Kunden können Agenten und Betriebssystemtreiber von Drittanbietern auf Servern installieren, die mit Sicherungs- und Wiederherstellungssystemen wie Veeam integriert werden können. | Der Kunde muss die Sicherungs- und Wiederherstellungslösung des Drittanbieters installieren und verwalten. |
Disaster-Recovery planen
Die Wiederherstellungsmaßnahmen müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.
| Fehler | Lösung |
|---|---|
| Ausfall des Startvolumens | Sie können ein neues Volume aus einem benutzerdefinierten Image erstellen, das Sie aus Ihrem Volume erstellt haben. Oder Sie können ein Volume aus einem Snapshot in der Konsole, über die CLI, mit der API, Terraform oder mithilfe einer vom Kunden verwalteten Lösung zur kontinuierlichen Sicherung und Wiederherstellung wiederherstellen. Wenn Sie ein Boot-Volume aus einem Snapshot wiederherstellen, müssen Sie mit Leistungseinbußen rechnen, während die Daten vom Snapshot auf das Boot-Volume kopiert werden. Durch die Verwendung von Fast Restore-Snapshots können Sie die Recovery Time ObjectivesIn der Notfallwiederherstellungsplanung die Zeitspanne, die ein Geschäftsprozess nach einem Notfall benötigt, um wiederhergestellt zu werden. (RTO) schneller erreichen als bei der Wiederherstellung von einem regulären Snapshot, da alle Daten verfügbar sind und die Leistung nicht beeinträchtigt wird. |
| Ausfall des Datenträgers oder Datenbeschädigung | Stellen Sie ein Volume aus einem Snapshot in der Konsole, über die CLI, mit der API, Terraform oder mithilfe einer vom Kunden verwalteten Lösung zur kontinuierlichen Sicherung und Wiederherstellung wieder her. Snapshots zur schnellen Wiederherstellung sind auch für Datenvolumes verfügbar. |
| Beschädigung von Dateifreigabe-Daten | Sie können Dateifreigabe-Snapshots erstellen, um Daten auf Ihrer Dateifreigabe zu einem bestimmten Zeitpunkt zu erhalten. Dann können Sie Daten aus einem Dateifreigabe-Snapshot wiederherstellen, wenn der Inhalt der Dateifreigabe versehentlich gelöscht oder überschrieben wird. |
| Ausfall der Dateifreigabe | Abhilfe durch Initiierung eines Failover auf eine vorhandene Replik in einer anderen Zone. Testen Sie den Failover-Prozess, um zu sehen, wie lange er dauert. |
| Ausfall eines virtuellen Servers | Durch die Verwendung der Hochverfügbarkeitsfunktionen eines Load Balancers und Auto Scale für VPC, die eine skalierbare Arbeitslast schaffen, wird dies gemildert. Ein Neustart des virtuellen Servers kann erforderlich sein. Möglicherweise ist eine Auflösung des Blockvolumendefekts erforderlich. |
| Ausfall eines Bare-Metal-Servers | Vom Kunden verwaltete Sicherungs- und Wiederherstellungslösung. |
| Zonenfehler | Durch die Verwendung der Hochverfügbarkeitsfunktionen eines Load Balancers und Auto Scale für VPC, die eine skalierbare Arbeitslast schaffen, wird dies gemildert. Verwenden Sie eine externe Wahrheitsquelle für die VPC-Zonenkonfiguration, um Ressourcen in einer verfügbaren Zone zu erstellen, indem Sie die Auflösung von Serverausfällen und die Auflösung von Blockvolumenausfällen verwenden. |
| Regionales Versagen | Verwenden Sie eine externe Wahrheitsquelle für die Konfiguration der VPC-Region, um Ressourcen in einer verfügbaren Region zu erstellen. Wiederherstellung der Volumes und des Dateispeichers auf die vorherigen Werte mit Hilfe der Serverfehlerbehebung. |
Ihre Verantwortung für Hochverfügbarkeit und Notfallwiederherstellung
Hintergrundinformationen finden Sie unter Verantwortung bei der Nutzung von Virtual Private Cloud. Es liegt in Ihrer Verantwortung, Ihren Plan für HA und DR kontinuierlich zu testen. Weitere Informationen finden Sie unter Disaster-Recovery-Tests.
Es kann zu Unterbrechungen der Netzanbindung und kurzen Zeiten der Nichtverfügbarkeit eines Dienstes kommen. Es liegt in Ihrer Verantwortung, sicherzustellen, dass der Quellcode der Anwendung eine Logik zur Wiederholung der Client-Verfügbarkeit enthält, um eine hohe Verfügbarkeit der Anwendung zu gewährleisten.
Die folgenden Checklisten können Ihnen bei der Erstellung und Umsetzung Ihres Plans helfen.
-
Block-Datenträger-Snapshot
-
Dateispeicher-Replikation
-
Externe Quelle der Wahrheit für die VPC-Konfiguration
Änderungsmanagement
Die Änderungsverwaltung umfasst Aufgaben wie Upgrades, Konfigurationsänderungen und Löschungen.
Gewähren Sie Benutzern und Prozessen die IAM-Rollen und -Aktionen mit den geringsten Privilegien, die für ihre Arbeit erforderlich sind. Weitere Informationen finden Sie unter Wie kann ich ein versehentliches Löschen von Diensten verhindern?
Erwägen Sie die Erstellung eines manuellen Backups, bevor Sie Änderungen an der Infrastrukturkonfiguration vornehmen.
Wie IBM® die Wiederherstellungsplanung im Katastrophenfall unterstützt
IBM® ergreift im Katastrophenfall spezifische Wiederherstellungsmaßnahmen für IBM Cloud VPC.
Wenn ein einzelner Host unerwartet ausfällt, können die virtuellen Server auf dem ausgefallenen Host automatisch auf einem gesunden Host neu gestartet werden. Weitere Informationen darüber, wie IBM die Infrastruktur überwacht und auf Hostausfälle reagiert, finden Sie unter Richtlinien zur Wiederherstellung bei Hostausfällen.
Wie IBM sich von Zonenausfällen erholt
Zonenausfälle können durch Naturkatastrophen, Infrastrukturprobleme wie Stromausfälle, versehentliche oder böswillige Aktionen, die Informationen löschen, oder software-Updates, die einen Bug oder Fehler enthalten. Im Falle eines Zonenausfalls arbeitet IBM an der Wiederherstellung von Einrichtungen und Rechenzentren, physischen Netzwerken und Geräten, physischen Speicher, physische Server und Speicher sowie Hypervisoren. Weitere Informationen finden Sie unter Gemeinsame Verantwortung für die Verwendung von IBM Cloud Produkten.
Wie IBM sich von regionalen Ausfällen erholt
Im Falle eines Ausfalls einer ganzen Region arbeitet IBM an der Wiederherstellung von Einrichtungen und Rechenzentren, physischen Netzwerken und Geräten, physischem Speicher, physische Server und Speicher sowie Hypervisoren. Weitere Informationen finden Sie unter Gemeinsame Verantwortung für die Verwendung von IBM Cloud Produkten und FAQs zur Notfallwiederherstellung.
Wenn IBM die Dienstinstanz nicht wiederherstellen kann, müssen Sie den Dienst wie in der Disaster-Recovery-Architektur beschrieben wiederherstellen.
Wie IBM Dienste unterhält
Bei der routinemäßigen Wartung von virtuellen Servern, Hosts und Rechenzentren werden Routineprotokolle befolgt. Weitere Informationen enthält der Abschnitt mit Informationen zu Cloud-Wartungsoperationen.
Alle Upgrades erfolgen nach den bewährten Verfahren von IBM, einschließlich Wiederherstellungsplänen und Rollback-Prozessen. Regelmäßige Wartungsarbeiten können zu kurzen Unterbrechungen führen, die durch eine Logik zur Wiederholung der Client-Verfügbarkeit gemildert werden. Die Änderungen werden nacheinander ausgerollt, Region für Region und Zone für Zone innerhalb einer Region. IBM macht Aktualisierungen bei den ersten Anzeichen eines Fehlers rückgängig.
Komplexe Änderungen werden mit Funktionskennzeichen aktiviert und deaktiviert, um die Exposition zu steuern.
Änderungen, die sich auf die Arbeitslast der Kunden auswirken, werden in den Benachrichtigungen von IBM Cloud detailliert aufgeführt. Weitere Informationen zu geplanten Wartungsarbeiten, Ankündigungen und Versionshinweisen, die sich auf diesen Dienst auswirken, finden Sie unter Überwachung von Benachrichtigungen und Status.