Hochverfügbarkeit und Disaster-Recovery für IBM Cloud® Object Storage
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.
{ IBM Cloud Object Storage ist ein globaler Dienst, der es Ihnen ermöglicht, die Ausfallsicherheit von Speicherdaten zu konfigurieren und gleichzeitig die Hochverfügbarkeit zu gewährleisten. Weitere Informationen finden Sie unter Service Level Agreement(SLA). Die verfügbare Region und die Standorte der Rechenzentren finden Sie auch in der Dokumentation Service und Infrastrukturverfügbarkeit nach Ort.
Architektur für hohe Verfügbarkeit
{ Object Storage ist ein globaler Dienst, und Sie haben die Möglichkeit, die Ausfallsicherheit des Speichers zu konfigurieren. Die Ausfallsicherheit eines Buckets wird durch den Endpunkt definiert, mit dem er erstellt wurde, d. h. regionsübergreifend, regional und standortbezogen.
-
Die regionenübergreifende Ausfallsicherheit verteilt Ihre Daten auf mehrere Ballungsräume
-
Die regionale Ausfallsicherheit wird Daten über einen einzigen Ballungsraum verteilen
-
Die Ausfallsicherheit eines einzelnen Rechenzentrums verteilt Daten auf mehrere Geräte innerhalb eines einzigen Rechenzentrums
Regionale und regionsübergreifende Buckets können die Verfügbarkeit während eines Standort- oder Zonenausfalls aufrechterhalten, ohne dass Konfigurationsänderungen erforderlich sind. Es wird daher empfohlen, diese Ausfallsicherheitseinstellungen für Speicher-Buckets zu verwenden, wenn Sie Ihre Workloads für hohe Verfügbarkeit konfigurieren. Daten, die an einem einzigen Standort gespeichert sind, werden weiterhin auf viele physische Speichergeräte verteilt, befinden sich jedoch innerhalb eines einzigen Rechenzentrums ohne Zonenunterstützung.
Funktionen für hohe Verfügbarkeit
{ Object Storage Funktionen unterstützen Sie bei der Planung einer hohen Verfügbarkeit im Falle eines Ausfalls:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Ausfallsicherheit von Speichereimern | Möglichkeit zur Konfiguration spezifischer Ausfallsicherheitsoptionen für Kundendaten. | {Buckets, die an einem regionalen Endpunkt erstellt werden Object Storage verteilen die Daten auf drei oder mehr Zonen, die in einem Stadtgebiet enthalten sind. Jede dieser Zonen kann einen Ausfall oder sogar eine Zerstörung erleiden,
ohne dass dies Auswirkungen auf die Verfügbarkeit hat. Eimer, die an einem regionenübergreifenden Endpunkt erstellt werden, verteilen Daten über drei Regionen an einem geografischen Standort. In jeder dieser Regionen kann es zu einem Ausfall oder auch zu schweren Beschädigungen kommen, ohne dass hierdurch die Verfügbarkeit der Daten beeinträchtigt wird. Anfragen werden mit Hilfe von Global Server Load Balancing (GSLB) an den nächstgelegenen regionsübergreifenden Ballungsraum weitergeleitet. Weitere Informationen finden Sie unter Endpunkte und Speicherorte. |
| Replikation | Die Replikation kopiert neu erstellte Objekte und Objektaktualisierungen von einem Quellbereich in einen Zielbereich und ermöglicht es Ihnen, Regeln für das automatische, asynchrone Kopieren von Objekten zu definieren. | Um sicherzustellen, dass im Katastrophenfall eine Sicherungskopie zur Verfügung steht, empfiehlt es sich, eine Replikation zu konfigurieren und einzurichten. Erfahren Sie mehr über die Verfolgung von Replikationsereignissen. |
Architektur zur Wiederherstellung im Katastrophenfall
Regionsübergreifende, regionale und standortbezogene Buckets bieten eine unterschiedlich hohe Toleranz gegenüber bestimmten Katastrophenszenarien. Wählen Sie das richtige Ausfallsicherheitsmodell für Ihren Bucket, das mit den Disaster Recovery-Anforderungen Ihres Unternehmens übereinstimmt. Für viele Katastrophenszenarien auf Rechenzentrums- oder regionaler Ebene plant IBM eine Wiederherstellungszeit des Services und der zugehörigen Inhalte von weniger als 24 Stunden mit einem RPO von 1 Stunde.
Zusätzliche optionale Architekturen können vom Kunden implementiert werden, um die Wiederherstellungszeiten zu verbessern.
Für den unwahrscheinlichen Fall eines kompletten COS-Regionalausfalls, bei dem eine Wiederherstellung der ursprünglichen Daten nicht möglich ist, könnte beispielsweise ein duplizierter Bucket in einer anderen Region erstellt werden. Auf die Wiederherstellung einer betroffenen Region oder eines betroffenen Dienstes IBM Cloud zu warten, ist ebenfalls ein gangbarer Weg, aber bedenken Sie, dass dies viele Stunden oder länger dauern kann und je nach Katastrophenszenario ein Datenverlust auftreten kann.
Der duplizierte Bucket kann so konfiguriert werden, dass er den Produktions-Bucket spiegelt, jedoch mit aktualisierten Verweisen auf regionale Dienste. Wenn Sie beispielsweise Key Protect verwenden, sollte ein duplizierter Bucket in Madrid auf Root-Schlüssel verweisen, die in einer Madrider Key Protect gespeichert sind. Im Falle einer Katastrophe, bei der es nicht möglich ist, auf die vollständige Wiederherstellung der Region IBM zu warten, können Kunden diesen duplizierten Bucket mit einer Sicherungskopie der Originaldaten im Quell-Bucket neu befüllen. Alternativ können die Kunden vor einem Ausfall Replikationsregeln einrichten, um die Daten zwischen dem Quell-Bucket und dem duplizierten Bucket synchron zu halten. Um ein Höchstmaß an Ausfallsicherheit zu erreichen, sollte ein solcher duplizierter Bucket im Vorfeld (vor einem möglichen Desaster) erstellt und mit dem Quell-Bucket, der die Replikation nutzt, synchronisiert werden. Die Verwendung der Objektreplikationsfunktion sollte zusammen mit dem Ausfallsicherheitsmodell Ihres Quell-Buckets und Ihren allgemeinen Unternehmenszielen für die Notfallwiederherstellung in Betracht gezogen werden.
Planen Sie den Aufschwung in einer Aufschwungregion. Der replizierte Bucket sollte mit den Workload-Disaster-Recovery-Ansätzen innerhalb der IBM Cloud übereinstimmen. Wenn die Katastrophe keine Auswirkungen auf die Konfiguration oder Verfügbarkeit des Produktions-Quell-Buckets hat (z. B. nur Datenverlust), kann ein Kunde die Daten im Quell-Bucket möglicherweise an Ort und Stelle reparieren. Wenn ein Failover auf einen replizierten Bucket erforderlich ist, muss die Client-Anwendung neu konfiguriert werden, um den Endpunkt des replizierten Ziel-Buckets aufzurufen.
Funktionen zur Wiederherstellung im Katastrophenfall
IBM COS bietet die folgenden Disaster-Recovery-Funktionen, die vom Kunden konfiguriert werden können:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Objekt-Replikation | Die Replikation kopiert neu erstellte Objekte und Objektaktualisierungen von einem Quellbereich in einen Zielbereich und ermöglicht es Ihnen, Regeln für das automatische, asynchrone Kopieren von Objekten zu definieren. | Um sicherzustellen, dass im Katastrophenfall eine zweite Kopie verfügbar ist, können Sie die Replikation zwischen einem Produktions-Bucket und einem Ziel-Recovery-Bucket konfigurieren. Je nach den Anforderungen Ihres Unternehmens an die Ausfallsicherheit ist eine Replikation bei der Verwendung von regionenübergreifenden oder regionalen Buckets möglicherweise nicht erforderlich. Erfahren Sie mehr über die Verfolgung von Replikationsereignissen. |
| Objektversionssteuerung | Aktivieren Sie die Objektversionierung, um frühere Versionen von Objekten aufrechtzuerhalten, die im Falle einer Beschädigung oder Löschung von Daten wiederhergestellt werden können. | Kunden können die Objektversionierung für Buckets aktivieren und im Falle einer Datenbeschädigung alte Versionen wiederherstellen. Der Bucket muss verfügbar sein, um eine Versionswiederherstellung durchzuführen. Weitere Informationen |
| Objektsperre | Die Objektsperre verhindert das Löschen von Objektversionen während einer bestimmten Aufbewahrungsfrist. | Aktivieren Sie die Objektsperre zum Schutz vor versehentlichem oder unbefugtem Löschen oder Überschreiben von Objekten. Stellen Sie sicher, dass sichere Objektversionen für die Wiederherstellung verfügbar sind. Weitere Informationen |
Andere Wiederherstellungsoptionen werden vom Kunden erstellt und unterstützt.
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Sichern und Wiederherstellen | Verwenden Sie Skripte oder Backup-Anwendungen von Drittanbietern, um Daten in Quell-Buckets in einer Wiederherstellungsregion zu sichern. | Der Kunde muss alle Skripte oder Backup-Lösungen von Drittanbietern hosten und verwalten, um die in COS-Buckets gespeicherten Daten zu sichern. |
Planung für DR
Die DR-Schritte müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.
| Fehler | Lösung |
|---|---|
| Hardware-Ausfall (einzelner Punkt) | { Object Storage Buckets sind resistent gegen einzelne Hardwareausfälle innerhalb einer Zone. Keine Konfiguration erforderlich. |
| Ausfall des Rechenzentrums | Regionsübergreifende und regionale COS-Buckets sind widerstandsfähig gegenüber Ausfällen einzelner Rechenzentren. Eine Konfiguration oder Ausfallsicherung durch den Kunden ist nicht erforderlich. Kunden mit Buckets in einzelnen Rechenzentrumszonen können die Replikation konfigurieren oder Backup-Lösungen von Drittanbietern verwenden, um sicherzustellen, dass eine sichere Kopie der Daten außerhalb der Zone verfügbar ist. Das Warten auf „ IBM Cloud “, bis eine betroffene Region oder ein betroffener Dienst wiederhergestellt ist, ist ebenfalls ein gangbarer Weg, aber denken Sie daran, dass dies je nach Art des Ausfalls des Rechenzentrums viele Stunden oder länger dauern kann. |
| Datenbeschädigung | Verwenden Sie Objektversionierung, Objektreplikation oder Backup-Lösungen von Drittanbietern, um sicherzustellen, dass im Falle einer Datenbeschädigung oder versehentlichen Löschung unbeschädigte Versionen der Objekte zur Wiederherstellung vorhanden sind. |
| Regionales Versagen | Regionsübergreifende COS-Buckets sind widerstandsfähig gegen regionale Ausfälle. Einige integrierte regionale Dienste wie Key Protect können zusätzliche Failover-Schritte für regionsübergreifende Buckets erfordern. Kunden mit Buckets in regionalen COS-Buckets oder Buckets in einem einzelnen Rechenzentrum sollten die oben genannten Schritte zur Notfallwiederherstellung im Falle eines regionalen Totalausfalls befolgen. Auf die Wiederherstellung einer betroffenen Region oder eines betroffenen Services IBM Cloud zu warten, ist ebenfalls ein gangbarer Weg, aber bedenken Sie, dass dies je nach Art des regionalen Ausfalls viele Stunden oder länger dauern kann. |
Verwendung von IBM Cloud Key Management Service für die Hinzufügung von Verschlüsselung:
Wenn Sie eine andere IBM Cloud Service-Integration verwenden, z. B. IBM Cloud Key Management Service wie Key Protect oder Hyper Protect, um die Verschlüsselung hinzuzufügen, müssen Sie sicherstellen, dass der entsprechende Konfigurationsplan für die Schlüsselreplikation verwendet wird. Dies ist wichtig, wenn eine regionsübergreifende Konfiguration verwendet wird, die sicherstellt, dass im Falle eines Ausfalls ein Replikationsschlüssel verfügbar ist. Informationen zur Hochverfügbarkeit und Disaster Recovery finden Sie in der Key Protect.
Ihre Verantwortlichkeiten für HA und DR
| Zuständigkeit | Beschreibung |
|---|---|
| Ausfallsicherheit | Stellen Sie Object Storage mit der entsprechenden Ausfallsicherheitsoption, Speicherklasse, Datenlokalisierung und den optionalen Konfigurationen bereit, die für den jeweiligen Workload und Anwendungsfall erforderlich sind. |
| Datensicherung | Sichern Sie die Kundendaten, falls erforderlich, entsprechend den Anforderungen Ihres Unternehmens. |
| Netz | Überwachen und Verwalten von IBM, um einen angemessenen Zugang zu IBM Cloud Service-Endpunkten zu gewährleisten, einschließlich Kapazität und Verfügbarkeit. |
| Verwendung von IBM Cloud KMS zum Hinzufügen von Verschlüsselung | Wenn Sie IBM Cloud Key Protect oder Hyper Protect Crypto Services verwenden, um die Verschlüsselung hinzuzufügen, stellen Sie sicher, dass Sie die entsprechende Dokumentation zur Hochverfügbarkeit und Disaster Recovery lesen, um die Auswirkungen vollständig zu verstehen. Es kann erforderlich sein, eine Schlüsselinstanz zu verwenden, die über ein Schlüsselreplikat verfügt, das im Falle eines Failovers verwendet werden kann. Bitte beachten Sie auch die entsprechenden Informationen zu Lizenzen und Plänen. |
Weitere Informationen über die Verantwortlichkeiten zwischen dem Kunden und Object Storage finden Sie unter [Ihre Verantwortlichkeiten bei der Nutzung von Object Storage (/docs/cloud-object-storage?topic=cloud-object-storage-responsibilities)].
Wiederherstellungszeitziel (RTO) und Wiederherstellungspunktziel (RPO)
Das IBM Cloud Object Storage verfügt über Pläne für die Wiederherstellung sowohl des Cloud Service als auch der zugehörigen Inhalte, die im Falle einer entsprechenden Katastrophe innerhalb weniger Stunden erfolgt.
| Feature | RTO und RPO |
|---|---|
| Wiederherstellung nach einem Hardwareausfall (Einzelpunkt) | RTO = 0, RPO = 0 für alle Ausfallsicherheitsmodelle |
| Wiederherstellung nach Ausfall des Rechenzentrums | RTO = 0, RPO = 0 für regionenübergreifende und regionale Resilienzmodelle |
| Vorherige Objektversion wiederherstellen | RTO = Sekunden, RPO = nahe 0 |
| Wiederherstellung in einem Bucket in einer separaten Region mit aktiver Replikation | RTO = Minuten, Skripting kann die Zeit weiter verkürzen und auch die Zeit für die Anpassung der Arbeitslasten an den Wiederherstellungsbereich berücksichtigen, , RPO = fast 1 Stunde |
| Wiederherstellung in einem neuen Bucket in einer neuen Region ohne aktive Replikation | RTO = Minuten bis Tage, berücksichtigt die Zeit, die für die Neukonfiguration eines neuen Buckets und die Anpassung von Workloads an den neuen Bucket-Endpunkt benötigt wird. Berücksichtigen Sie auch die Zeit, die benötigt wird, um den Bucket mit einer Kopie der Originaldaten aufzufüllen. Das RPO unterliegt dem Sicherungs- und Wiederherstellungsplan des Kunden |
Änderungsmanagement
Das Änderungsmanagement umfasst Aufgaben wie Upgrades, Konfigurationsänderungen und Löschungen. Um sicherzustellen, dass die Benutzer den Zugriff gemäß den Rollenanforderungen erhalten, lesen Sie bitte Erste Schritte mit IAM.
Es wird empfohlen, Benutzern und Prozessen die IAM-Rollen und -Aktionen mit den geringsten Rechten zu gewähren, die für ihre Arbeit erforderlich sind. Siehe Wie kann ich ein versehentliches Löschen von Diensten verhindern?
Wie IBM® die Wiederherstellung im Katastrophenfall unterstützt
{ IBM® ergreift im Falle einer Katastrophe spezifische Wiederherstellungsmaßnahmen.
- Wiederherstellung nach Zonen- oder Regionalausfällen
Im Falle eines Zonenausfalls behebt IBM Cloud den Ausfall der Zone. Sobald die Zone wieder in Betrieb ist, sendet der globale Load Balancer wieder API-Anfragen an den wiederhergestellten Instance-Knoten, ohne dass der Kunde eingreifen muss. - { IBM® führt jährliche Tests verschiedener Katastrophenszenarien durch und verfeinert die Wiederherstellungsdokumentation kontinuierlich auf der Grundlage der bei diesen Tests gewonnenen Erkenntnisse.
- 24 × 7 globaler Support steht den Kunden mit IBM® Subject Matter Experts zur Verfügung, die im Katastrophenfall auf Abruf bereitstehen.
Alle IBM® Subject Matter Experts werden jährlich in den Richtlinien und Verfahren für Business Continuity und Disaster Recovery geschult, um im Katastrophenfall gewappnet zu sein.
Wie IBM Dienste unterhält
Alle Upgrades folgen den IBM Service Best Practices und verfügen über einen Wiederherstellungsplan und einen Rollback-Prozess. Regelmäßige Upgrades für neue Funktionen und Wartungsarbeiten sind Teil des normalen Betriebs. Solche Wartungsarbeiten können gelegentlich zu kurzen Unterbrechungen führen, die von der Wiederholungslogik für die Client-Verfügbarkeit behandelt werden. Die Änderungen werden schrittweise eingeführt, Region für Region und Zone für Zone innerhalb einer Region. Aktualisierungen werden beim ersten Anzeichen eines Fehlers zurückgezogen.
Komplexe Änderungen werden mit Funktionskennzeichen aktiviert und deaktiviert, um die Exposition zu steuern.
Änderungen, die sich auf die Arbeitsbelastung der Kunden auswirken, werden in Benachrichtigungen detailliert aufgeführt. Weitere Informationen finden Sie unter Benachrichtigungen und Statusüberwachung für geplante Wartungsarbeiten, Ankündigungen und Versionshinweise, die sich auf diesen Dienst auswirken.