Hochverfügbarkeit und Disaster-Recovery für IBM Cloud Logs

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, bei unerwarteten Ausfällen betriebsbereit und zugänglich zu bleiben. Bei der NotfallwiederherstellungDie 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. wird die Serviceinstanz in einen funktionsfähigen Zustand versetzt.

IBM Cloud Logs ist ein hochverfügbarer, mandantenfähiger, regionaler Dienst. Die verfügbaren Regionen und Rechenzentrumsstandorte finden Sie in der Dokumentation zu den Standorten. Als regionaler Dienst erfüllt IBM Cloud Logs die definierten Service Level Objectives(SLO) mit dem Standardplan. Service-Level-Ziele stellen keine Gewährleistung dar und es werden von IBM keine Gebühren erstattet, wenn ein Ziel nicht erreicht wird.

Die Service Level Objectives (SLOs) beschreiben die Designpunkte, die die IBM Cloud Dienste erfüllen sollen. IBM Cloud Logs ist darauf ausgelegt, das folgende Verfügbarkeitsziel zu erreichen.

SLO für IBM Cloud Logs
Verfügbarkeitsziel Zielwert
Verfügbarkeit in % 99.99%

Hochverfügbarkeitsarchitektur

Diagramm zur Darstellung der Hochverfügbarkeitsarchitektur für IBM Cloud Logs
Hochverfügbarkeitsarchitektur

Eine Verfügbarkeitszone ist eine logisch und physisch isolierte Position innerhalb einer IBM Cloud-Region, in der Ihre Daten verarbeitet und gehostet werden.

  • Eine Verfügbarkeitszone besitzt unabhängige Stromversorgungs-, Kühlungs- und Netzinfrastrukturen, die von anderen Zonen isoliert sind, um die Fehlertoleranz durch die Vermeidung von Single Points of Failure zwischen Zonen zu stärken.
  • Eine Verfügbarkeitszone bietet innerhalb einer Region eine hohe Bandbreite und eine niedrige zonenübergreifende Latenz.

Eine Region (Standort) ist eine geografisch und physisch getrennte Gruppe von einer oder mehreren Verfügbarkeitszonen mit unabhängigen Elektrizitäts- und Netzinfrastrukturen, die von anderen Regionen isoliert sind.

  • Regionen entfernen konzeptionsgemäß gemeinsame Single Points of Failure mit anderen Regionen und garantieren eine niedrige zonenübergreifende Latenz innerhalb der Region.
  • Jede Region ist zur Redundanz mit drei verschiedenen Rechenzentren ausgestattet.

Hochverfügbarkeitsfunktionen

IBM Cloud Logs unterstützt die folgenden Hochverfügbarkeitsfunktionen:

HA-Funktionen für IBM Cloud Logs
Feature Beschreibung
Einsatz in einer Region mit mehreren Zonen IBM Cloud Logs wird nur in Regionen mit mehreren Zonen (MZR) eingesetzt, und innerhalb einer MZR erstreckt sich der Datenebenencluster über alle drei Zonen, wodurch sichergestellt wird, dass der Verlust einer Zone keine Auswirkungen auf die Dienstverfügbarkeit hat.
IBM Cloud Logs ressourcenreplikation über Zonen hinweg Alle IBM Cloud Logs-Ressourcen, wie z. B. Warnmeldungen, Metriken und Protokolle, werden in drei Zonen innerhalb der MZRs repliziert. Dadurch wird sichergestellt, dass die Daten im Falle eines Zonenverlustes erhalten bleiben.
Überwachung der Betriebsbereitschaft Alle Mikrodienste werden über Kubernetes-Liveness- und -Bereitschaftstests überwacht.

Architektur zur Wiederherstellung nach Katastrophen

Diagramm zur Darstellung der Notfallwiederherstellungsarchitektur für IBM Cloud
Notfallwiederherstellungsarchitektur

IBM Cloud Logs basiert auf Red Hat OpenShift on IBM Cloud auf VPC, das Multi-Zone-Regionen verwendet und alle Arbeitsknoten auf drei Zonen verteilt. VPC-Load-Balancer verarbeiten den eingehenden Datenverkehr und leiten ihn an das im Cluster ausgeführte Service-Netz weiter.

Es gibt keine automatische überregionale Ausfallsicherung oder überregionale Notfallwiederherstellung. Wenn alle Verfügbarkeitszonen in einer Region ausfallen, ist IBM Cloud Logs in dieser Region nicht mehr verfügbar.

Funktionen zur Notfallwiederherstellung

IBM Cloud Logs unterstützt die folgenden Funktionen zur Wiederherstellung nach Katastrophen:

DR-Funktionen für IBM Cloud Logs
Feature Beschreibung
Alternative Region Der Gottesdienst kann in einer anderen Region abgehalten werden, getrennt vom Hauptgottesdienst
Datenbanksicherung Eine Kopie des aktuellen Datensatzes wird gespeichert

Katastrophenplanung

Die Schritte der DR müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.

DR-Szenarien für IBM Cloud Logs
Fehler Lösung
Hardwareausfall (einzelner Punkt) IBM stellt eine Datenbank bereit, die gegen den Ausfall eines einzelnen Hardware-Punktes innerhalb einer Zone resistent ist – es ist keine Konfiguration erforderlich.
Zonenfehler IBM Cloud Logs verwendet eine mehrzonige regionale Bereitstellung, die bei einem Ausfall einer Zone widerstandsfähig ist.
Datenbeschädigung Im Falle einer Datenbeschädigung wird die Datenbank auf den letzten stabilen Zustand zurückgesetzt, der auf der Backup-Site verfügbar ist. Wir verwenden IBM Cloud Object Storage-Backups für die Wiederherstellung, siehe Backups
Regionalversagen Folgen Sie den Schritten unter "Ihre Verantwortung für humanitäre Hilfe und Katastrophenhilfe "

Ihre Verantwortung für humanitäre Hilfe und Katastrophenhilfe

IBM Cloud verfügt über GeschäftskontinuitätspläneDie Fähigkeit eines Unternehmens, Ausfallzeiten zu kompensieren und geschäftskritische Services normal und unterbrechungsfrei den vordefinierten Service-Level-Agreements entsprechend zu betreiben., die im Falle einer Katastrophe die Wiederherstellung der Dienste innerhalb weniger Stunden ermöglichen. Sie sind für die Sicherung Ihrer Daten und die zugehörige Wiederherstellung Ihrer Inhalte verantwortlich.

Bei größeren regionalen Katastrophen, z. B. bei einem Erdbeben, bei Hochwasser oder durch Tornados, kann eine gesamte Region betroffen sein.

Um eine IBM Cloud Logs-Instanz wiederherzustellen, müssen Sie eine neue IBM Cloud Logs-Instanz bereitstellen und die IBM Cloud Logs-Ressourcen neu erstellen. Sie müssen auch eine DR-Strategie für die IBM Cloud Object Storage-Buckets haben, die mit der Instanz verknüpft sind, und für die IBM Cloud Event Notifications-Instanz, die Sie möglicherweise so konfiguriert haben, dass sie Benachrichtigungen auslöst.

Um sicherzustellen, dass Ihre Arbeitslasten solchen Ereignissen standhalten, führen Sie die folgenden Schritte aus:

  1. Definieren Sie die regionale Strategie, mit der Sie die ausgefallene Konfiguration wiederherstellen können.

    Überprüfen Sie bei der Auswahl der Wiederherstellungsregion die Datenlokalisierung und die Compliance-Anforderungen.

    Weitere Informationen zu den Standorten finden Sie unter:

  2. Wenn Sie Konfigurationen haben, die Terraform nicht verwenden, sichern Sie Ihre aktuellen Konfigurationen mithilfe der API. Wenn Sie Terraform verwenden, speichern Sie Ihre Terraform-Skripte, um die ausgefallene Region neu erstellen zu können. Erwägen Sie die Verwendung eines Versionskontrollsystems zum Speichern der Sicherungsdateien oder Terraform-Skripte.

    Sie können Terraform verwenden, um IBM Cloud Logs-Instanzen zu erstellen. Siehe Ressourcenverwaltung Terraform-Ressourcen.

    Sie können Terraform verwenden, um die IBM Cloud Logs-Ressourcen zu erstellen. Siehe IBM Cloud Logs Terraform-Ressourcen.

    Sie können Terraform verwenden, um Ihren Daten-Bucket, Ihren Metrik-Bucket oder beides mit regionsübergreifender Ausfallsicherheit zu erstellen, um Daten über mehrere geografische Regionen hinweg zu speichern und darauf zuzugreifen und eine hohe Verfügbarkeit, Langlebigkeit und Disaster-Recovery-Fähigkeiten sicherzustellen. Siehe IBM Cloud Object Storage Terraform-Ressourcen.

    Sie können Terraform verwenden, um Ihre IBM Cloud Event Notifications-Ressourcen zu erstellen. Siehe IBM Cloud Event Notifications Terraform-Ressourcen.

    Sie können Terraform verwenden, um Ihre IAM-Berechtigungen und -Erlaubnisse zu erstellen. Siehe IAM Terraform-Ressourcen.

    Testen Sie immer, ob Sie die Backup-Konfiguration in einer alternativen Region wiederherstellen können.

Im Falle einer regionalen Katastrophe müssen Sie die folgenden Schritte ausführen, um Ihre Instanz in einer neuen Region wiederherzustellen:

  1. Ermitteln Sie eine alternative Region, in der die IBM Cloud Logs-Instanz wiederhergestellt werden kann.

  2. Erstellen Sie die neue IBM Cloud Logs-Instanz. Weitere Informationen finden Sie unter Instanz bereitstellen.

  3. Wenn in Ihrer Instanz Daten- oder Metrik-Buckets konfiguriert sind, führen Sie die folgenden Schritte aus:

    Wenn Ihre Instanz in der von der Katastrophe betroffenen Region nicht mit IBM Cloud Object Storage-Buckets konfiguriert wurde, gehen die Protokoll- und Metrikdaten verloren.

  4. Wenn in Ihrer Instanz Warnmeldungen konfiguriert sind, führen Sie die folgenden Schritte aus:

  5. Erstellen Sie die Ressourcen in der neuen IBM Cloud Logs-Instanz neu.

    Ansichten erstellen.

    Ein Benutzer mit dieser Berechtigung kann Dashboards erstellen.

    Benachrichtigungen erstellen.

    Erstellen Sie TCO-Richtlinien.

    Erstellen Sie Parsing-Regeln.

    Erstellen Sie Ereignisse zu Metriken.

    Datennutzung aktivieren.

    Datenregeln konfigurieren.

    Konfigurieren Sie Richtlinien zur Datenanreicherung.

Um die Wiederherstellung einer IBM Cloud Logs-Instanz zu erleichtern, verwenden Sie Terraform, um Ihre Instanzen, Konfigurationen und den IAM-Zugriff zu verwalten. Durch die Verwendung von Terraform entfallen manuelle Schritte bei der Konfiguration von Instanzen in einer anderen Region.

Nachdem Sie die Instanz wiederhergestellt haben, müssen Sie Ihre Datenquellen neu konfigurieren, um Protokolle an die neue Instanz zu senden:

  1. Wenn in der neuen Region ein IBM Cloud Logs Routing-Mandant konfiguriert ist, müssen Sie das aktuelle Ziel verwenden, das dieser Region zugeordnet ist, um Plattformprotokolle anzuzeigen und zu überwachen. Wenn in der neuen Region kein IBM Cloud Logs Routing-Mandant konfiguriert ist, erstellen Sie einen IBM Cloud Logs Routing-Mandanten, der auf Ihre neue IBM Cloud Logs-Instanz verweist. Siehe Erstellen eines IBM Cloud Logs Routing-Mandanten und Verstehen von Hochverfügbarkeit und Notfallwiederherstellung für IBM Cloud Logs Routing.

  2. Wenn die neue Region über eine IBM Cloud Activity Tracker Event Routing-Konfiguration verfügt, die Aktivitätsverfolgungsereignisse aus der ausgefallenen Region sammelt, können Sie die vorhandene Konfiguration verwenden, um Ereignisse anzuzeigen und zu verwalten. Wenn die neue Region nicht über eine IBM Cloud Activity Tracker Event Routing-Konfiguration verfügt, die Aktivitätsverfolgungsereignisse aus der ausgefallenen Region sammelt, müssen Sie eine Regel hinzufügen, die angibt, wo und wie Sie Ereignisse sammeln möchten. Weitere Informationen finden Sie unter Erstellen einer Routing-Konfiguration, die gegen regionale Katastrophen gewappnet ist.

  3. Konfigurieren Sie Ihre Protokollierungsagent so um, dass sie auf den Aufnahmeendpunkt der IBM Cloud Logs-Wiederherstellungsregion verweist.

Weitere Informationen zu den Verantwortlichkeiten zwischen Ihnen und IBM Cloud für die Nutzung von IBM Cloud Logs finden Sie unter "Verständnis Ihrer Verantwortlichkeiten bei der Nutzung von IBM Cloud Logs ".

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

IBM Cloud Logs bietet Möglichkeiten zum Schutz Ihrer Daten und zur Wiederherstellung der Dienstfunktionen. Es gibt Pläne zur Aufrechterhaltung des Geschäftsbetriebs, um die angestrebten Ziele für den WiederherstellungspunktBei der Planung der Notfallwiederherstellung wird die Zeit, in der Daten wiederhergestellt werden, in Zeit gemessen (Sekunden, Minuten, Stunden), beginnend mit der wiederhergestellten Instanz und endend am Punkt des Notfalls. (RPO) und die WiederherstellungszeitIn der Notfallwiederherstellungsplanung die Zeitspanne, die ein Geschäftsprozess nach einem Notfall benötigt, um wiederhergestellt zu werden. (RTO) für den Dienst zu erreichen. In der folgenden Tabelle sind die Ziele für IBM Cloud Logs aufgeführt.

RPO und RTO für IBM Cloud Logs
Disaster-Recovery-Ziel Zielwert
RPO Innerhalb von 4 Stunden
RTO Innerhalb von 24 Stunden

Änderungsmanagement

Die Änderungsverwaltung umfasst Aufgaben wie Upgrades, Konfigurationsänderungen und Löschungen.

Es wird empfohlen, Benutzern und Prozessen die IAM-Rollen und -Aktionen mit den geringsten für ihre Arbeit erforderlichen Berechtigungen zuzuweisen. Siehe Wie kann ich das versehentliche Löschen von Diensten verhindern?

Erwägen Sie, vor dem Upgrade auf eine neue Version von IBM Cloud Logs mithilfe der API ein Backup zu erstellen, wenn Sie Konfigurationen haben, die Terraform nicht verwenden.

Wie IBM® die Planung der Notfallwiederherstellung unterstützt

  • IBM® führt jährliche Tests verschiedener Katastrophenszenarien durch und verbessert unsere Wiederherstellungsdokumentation kontinuierlich auf der Grundlage der bei diesen Tests gewonnenen Erkenntnisse.

  • kunden steht ein globaler 24/7-Support zur Verfügung. IBM®-Experten stehen auf Abruf bereit, um im Katastrophenfall zu helfen.

    Alle IBM®-Fachexperten werden jährlich in den Richtlinien und Verfahren für Geschäftskontinuität und Notfallwiederherstellung geschult, um im Katastrophenfall vorbereitet zu sein.

IBM Cloud Logs ist ein hoch verfügbarer, regionaler Service.

  • Weitere Informationen zu den Regionen, in denen IBM Cloud Logs verfügbar ist, finden Sie unter Standorte.
  • Jede Region verfügt über drei verschiedene Rechenzentren für die Redundanz, die im Modus active/active konfiguriert sind.
  • Wenn alle Rechenzentren an einem Standort fehlschlagen, ist IBM Cloud Logs an diesem Standort nicht verfügbar.
  • In jeder unterstützten Region wird der Datenverkehr über die Infrastruktur in mehreren Verfügbarkeitszonen verteilt, ohne dass ein einzelner Punkt des Fehlers aufgetreten ist.

In der folgenden Tabelle ist der Hochverfügbarkeitsstatus für die Regionen (Standorte) aufgeführt, in denen der IBM Cloud Logs-Service verfügbar ist:

Liste der Standorte, an denen der Dienst verfügbar ist
Geografische Region Bereich EU-unterstützt HA-Status
Asien/Pazifik Osaka (jp-osa) Nicht zutreffend MZR
Asien/Pazifik Sydney (au-syd) Nicht zutreffend MZR
Asien/Pazifik Tokio (jp-tok) Nicht zutreffend MZR
Europa Frankfurt (eu-de) JA MZR
Europa London (eu-gb) NEIN MZR
Europa Madrid (eu-es) JA MZR
Nordamerika Toronto (ca-tor) Nicht zutreffend MZR
Nordamerika Montreal (ca-mon) Nicht zutreffend MZR
Nordamerika Dallas (us-south) Nicht zutreffend MZR
Nordamerika Washington (us-east) Nicht zutreffend MZR
Südamerika Sao Paulo (br-sao) Nicht zutreffend MZR

Wo

  • Eine Geografie ist ein geografischer Bereich oder ein größerer politischer Körper, der eine oder mehrere Regionen enthält.
  • Eine Region ist ein definiertes geografisches Gebiet.
  • Eine Region kann ein bestimmtes Postleitzahlengebiet, eine Stadt, ein Bundesland, eine Gruppe von Bundesländern oder sogar eine Gruppe von Ländern sein.
  • Eine Region enthält mehrere Verfügbarkeitszonen, um die Anforderungen an lokalen Zugang, niedrige Latenzzeiten und Sicherheit für die Region zu erfüllen.
  • MZR steht für "multi-zone region" und bedeutet "Mehrzonenregion". Weitere Informationen.

Weitere Informationen zur Serviceverfügbarkeit in Regionen und Rechenzentren finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.

Die Daten, die von IBM Cloud Logs in einer Region verwaltet werden, werden in den Rechenzentren in der Nähe dieser Region aufbewahrt.

Eine Multizonenregion (MZR) besteht aus drei oder mehr Verfügbarkeitszonen, die voneinander unabhängig sind, um sicherzustellen, dass einzelne Fehlerereignisse nur eine einzige Zone betreffen.

Standardmäßig wird IBM Cloud Logs in 3 Zonen eingesetzt. Jede Zone ist mit active/active/active eingerichtet:

  • Jede Zone befindet sich in einem anderen Rechenzentrum in der Region.
  • Die Daten in jeder Zone werden automatisch mit geringer Latenzzeit in die anderen Zonen repliziert. Sie müssen nichts tun, um die Replikation zu aktivieren.
  • Der Service übersteht einen Fehler in einer einzigen Zone konzeptionsgemäß ohne Unterbrechung.

Die MZR-Architektur bietet ein automatisches Failover zwischen den Zonen innerhalb der Region und eine hohe Verfügbarkeit für die Bereitstellung von IBM Cloud Logs innerhalb einer Region.

Die von IBM Cloud Logs verwalteten Metadaten umfassen Kunden-Metadaten wie Informationen über kritische Einstellungen – Schlüssel, Warnmeldungsdefinitionen, e2m-Definitionen, Metrikdaten usw.

IBM Cloud Logs sichert regelmäßig die Daten in jeder Region:

  • Regelmäßige Backups werden täglich erstellt und 30 Tage lang aufbewahrt und in regionsübergreifenden IBM Cloud Object Storage-Buckets gespeichert
  • Kontinuierliche Teilsicherungen werden für die letzten 7 Tage aufbewahrt.

Bei einem vollständigen Ausfall der Region bleiben die Sicherungsdaten verfügbar, die dann im Rahmen der Wiederherstellung des IBM Cloud Logs-Dienstes wiederhergestellt werden.

Wie IBM sich von Zonenausfällen erholt

Bei einem Ausfall der Zone wird IBM Cloud den Ausfall beheben. Da sich die Datenebene über alle drei Zonen in einer Region erstreckt, hat dies keine Auswirkungen auf die Verfügbarkeit der Dienste, und der globale Lastverteiler wird die Daten wieder an die wiederhergestellte Zone senden. Zu diesem Zeitpunkt besteht für den Kunden kein Handlungsbedarf.

Wie IBM regionale Ausfälle kompensiert

Wenn eine Region nach einem Ausfall wiederhergestellt wird, versucht IBM, die Service-Instanz aus dem regionalen Status wiederherzustellen. Wenn der regionale Staat beschädigt ist, wird der Dienst auf den Stand der letzten internen Sicherung zurückgesetzt, die kontinuierlich an einen alternativen Datenstandort in einem regionsübergreifenden IBM Cloud Object Storage-Bucket gestreamt wird, der vom Dienst verwaltet wird. Wenn die Sicherungsdaten beschädigt wurden, besteht die Gefahr eines Datenverlusts im Umfang von 24 Stunden. Diese Sicherungen stehen nicht für die vom Kunden verwaltete Notfallwiederherstellung zur Verfügung.

Wenn IBM die Serviceinstanz nicht wiederherstellen kann, muss der Kunde die Wiederherstellung wie in der Disaster-Recovery-Architektur beschrieben durchführen.

Wie IBM Dienste aufrechterhält

Alle Upgrades folgen den bewährten Verfahren des IBM-Dienstes und verfügen über einen Wiederherstellungsplan und einen Rollback-Prozess. Regelmäßige Upgrades für neue Funktionen und Wartungsarbeiten sind Teil des normalen Betriebs. Eine solche Wartung kann gelegentlich zu kurzen Unterbrechungsintervallen führen, die durch die Wiederholungslogik der Client-Verfügbarkeit behandelt werden. Änderungen werden nacheinander eingeführt, Region für Region und Zone für Zone innerhalb einer Region. Updates werden beim ersten Anzeichen eines Defekts rückgängig gemacht.

Änderungen, die sich auf die Arbeitsbelastung der Kunden auswirken, werden in Benachrichtigungen detailliert beschrieben. Weitere Informationen finden Sie unter "Überwachungsbenachrichtigungen und -status " für geplante Wartungsarbeiten, Ankündigungen und Versionshinweise, die sich auf diesen Dienst auswirken.