Informationen zu Hochverfügbarkeit und Disaster-Recovery für App ID

HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. Für Dienstleistungen ist die Verfügbarkeit im Service Level Agreement definiert. Die Verfügbarkeit umfasst sowohl geplante als auch ungeplante Ereignisse wie Wartungsarbeiten, Ausfälle und Katastrophen. (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 Kapazitäten des Hochverfügbarkeitsdesigns. versteht man die Wiederherstellung eines funktionierenden Zustands der Service-Instanz.

IBM Cloud® App ID ist ein regionaler Dienst, der die mit dem Standardplan definierten Service Level Objectives(SLO ) erfüllt. Weitere Informationen über die verfügbaren IBM Cloud Regionen und Rechenzentren für App ID finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.

Architektur für hohe Verfügbarkeit

Eine App ID Service-Instanz wird über mehrere Zonen in einer Multi-Zonen-Region ohne Single Point of Failure bereitgestellt. Bei einem Ausfall eines Instanzknotens oder einer Verfügbarkeitszone läuft der Dienst weiter, wobei die API-Anforderungen über einen globalen Load Balancer an die überlebenden hochverfügbaren Instanzknoten weitergeleitet werden. Zwischen dem Ausfall und dem Erkennen des Fehlers durch den globalen Load Balancer kann eine kurze Zeitspanne (Sekunden) liegen, in der Anfragen an die ausgefallene Instanz gesendet werden. Workloads, die programmatisch auf die Service-Instanz zugreifen, sollten der Wiederholungslogik für die Client-Verfügbarkeit folgen, um die Verfügbarkeit aufrechtzuerhalten. Bei einem zonalen Ausfall kommt es zu keiner spürbaren Beeinträchtigung des Dienstes.

Architektur zur Wiederherstellung im Katastrophenfall

Zur Wiederherstellung nach einem Ausfall einer Service-Instanz sollte eine Recovery-Service-Instanz in einer Recovery-Region eingerichtet werden. Im Allgemeinen sollte die Wiederherstellungsdienstinstanz mit denselben Daten wie die Quelldienstinstanz konfiguriert werden. Stellen Sie sicher, dass Sie vor einer möglichen Katastrophe Sicherungsinstanzen in einer Wiederherstellungsregion erstellen und diese regelmäßig warten, um sicherzustellen, dass sie mit der Quellinstanz synchronisiert sind.

Funktionen zur Wiederherstellung im Katastrophenfall

Planen Sie den Aufschwung in einer Aufschwungregion. Die Wiederherstellungsinstanz sollte mit den Workload-Disaster-Recovery-Ansätzen innerhalb von IBM Cloud übereinstimmen Die Wiederherstellungsinstanz sollte Datenänderungen an der primären Serviceinstanz für Daten einschließlich Kennwortrichtlinien, Benutzer und SAML Konfigurationen verfolgen.

Sichern und Wiederherstellen Ihrer Instanzen

Das Sichern und Wiederherstellen Ihrer App ID-Instanz, um die regionsübergreifende Verfügbarkeit sicherzustellen, erfordert einige grundlegende Schritte. Sie müssen wie folgt vorgehen:

  1. Definieren Sie die Richtlinien für die Konfiguration des Speichers für die Sicherung Ihrer App ID-Instanz. Diese Konfiguration umfasst die Planung, wie die Daten (z. B. die Benutzerprofile und Cloud Directory-Benutzer) in der Sicherung Ihrer Instanz gespeichert werden sollen.

    Erstellen Sie das Ausweichsystem, bevor ein Ausfall an Ihrem primären Standort auftritt. Um einen unterbrechungsfreien Schutz zu gewährleisten, wie empfohlen, automatisieren Sie den Prozess, um die Sicherung zu generieren und in regelmäßigen Abständen auszuführen.

  2. Erstellen und konfigurieren Sie eine Instanz von App ID in einer anderen Region.

  3. Richten Sie einen Prozess ein, um die Sicherung zu speichern und in der Instanz App ID wiederherzustellen, die sich an der sekundären Position befindet.

Instanz mithilfe der API sichern

Um Ihre App ID Instanz mit Hilfe der Verwaltungs-API zu sichern, schreiben Sie ein Skript, das eine Anfrage an die App ID API sendet, um Dateien zu erzeugen, die die Setup-Informationen für Ihre App ID Instanz enthalten. Speichern Sie diese Dateien an einer sicheren Position, da sie für die Wiederherstellung der App ID-Instanz in einer sekundären Region erforderlich sind.

Definieren Sie die Einstellungen Ihrer Sicherung auf der Basis der Konfiguration in Ihrer App ID-Instanz, z. B. was für Ihren Anwendungsfall erforderlich ist. Im folgenden Beispiel konfigurieren Sie Ihre App ID-Instanz mit den folgenden Einstellungen:

  • Kennwortrichtlinien, wie z. B. das Sperren des Benutzerprofils für 60 Minuten, wenn der Benutzer dreimal hintereinander ein falsches Kennwort eingibt
  • SAML-Konfiguration

Senden Sie Folgendes, um diese Benutzereinstellungen mit der Management-API abzurufen:

curl -X 'GET' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/cloud_directory/advanced_password_management' \
  --header 'accept: application/json' \
  --header 'Authorization: Bearer <IAM_Token>'

curl -X 'GET' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/idps/saml' \
  --header 'accept: application/json' \
  --header 'Authorization: Bearer <IAM_Token>'

Zusätzlich zur Sicherung der Konfigurationseinstellungen Ihrer App ID-Instanz müssen Sie eine Sicherung Ihrer Cloud Directory-Benutzer-und Benutzerprofile generieren. Für diese Task wird empfohlen, die Management-API zu verwenden.

  • Verwenden Sie zum Exportieren von Cloud Directory-Benutzern den API-Endpunkt cloud_directory/export/all. Verwenden Sie zum Herunterladen des Exports die API cloud_directory/export/download. Weitere Details zum Exportieren von Cloud Directory-Benutzern mit der Management-API finden Sie in der Dokumentation Alle Benutzer exportieren.
  • Verwenden Sie zum Exportieren von Benutzerprofilen den Endpunkt users/export.
  • Diese beiden Export-APIs generieren zwei Sicherungsdateien, die Sie sicher speichern müssen, um später im Wiederherstellungsprozess verwendet zu werden.

Instanz mithilfe von Terraform und der API sichern

Um Ihre App ID-Einstellungen mit Terraform zu sichern, können Sie Terraform-Scripts schreiben, um Dateien zu generieren, die die Konfigurationsinformationen für Ihre App ID-Instanz enthalten. Speichern Sie diese Dateien an einer sicheren Position, da Sie sie verwenden müssen, um die App ID-Instanz in einer sekundären Region wiederherzustellen.

Definieren Sie die Einstellungen Ihrer Sicherung auf der Basis der Konfiguration in Ihrer App ID-Instanz, z. B. was für Ihren Anwendungsfall erforderlich ist. Im folgenden Beispiel konfigurieren Sie Ihre App ID-Instanz mit den folgenden Einstellungen:

  • Kennwortrichtlinien, wie z. B. das Sperren des Benutzerprofils für 60 Minuten, wenn der Benutzer dreimal hintereinander ein falsches Kennwort eingibt
  • SAML-Konfiguration

Mit dem folgenden Terraform-Script können Sie Ihre aktuelle Konfiguration abrufen und in Dateien speichern.

terraform {
  required_providers {
    ibm = {
      source = "IBM-Cloud/ibm"
      version = ">= 1.12.0"
    }
  }
}

variable "tenant_id" {
  type = string
  default = "<<YOUR TENANT ID>>"
}

variable "region" {
  type = string
  default = "<<THE REGION YOUR TENANT IS LOCATED>>"
}

provider "ibm" {
  region = var.region
  ibmcloud_api_key = "<<API KEY TO ACCESS APP ID INSTANCE>>"
}

##### ---------- Getting the configuration from your App ID instance ---------- #####

# Get Settigs about Password's rules
data "ibm_appid_apm" "app" {
    tenant_id = var.tenant_id   
}

# Get SAML config
data "ibm_appid_idp_saml" "saml" {
    tenant_id = var.tenant_id
}

##### ---------- Saving the App ID configuration to files ---------- #####

resource "local_file" "app_config" {
    content  = jsonencode(data.ibm_appid_apm.app)
    filename = "${path.module}/backup_configurations/app_config.json"
}

resource "local_file" "saml_config" {
    content  = jsonencode(data.ibm_appid_idp_saml.saml)
    filename = "${path.module}/backup_configurations/saml_config.json"
}

Im vorherigen Szenario werden die Dateien, die die Sicherungen enthalten, lokal gespeichert. Sie können sie aber auch an jedem anderen Ort aufbewahren, den Sie bevorzugen, z. B IBM Cloud Object Storage.

Um eine Sicherung von Cloud Directory-Benutzern und -Benutzerprofilen zu generieren, wird empfohlen, die Management-API zu verwenden.

  • Verwenden Sie zum Exportieren von Cloud Directory-Benutzern den API-Endpunkt cloud_directory/export/all. Verwenden Sie zum Herunterladen des Exports die API cloud_directory/export/download. Weitere Informationen zum Exportieren von Cloud Directory-Benutzern mit der Management-API finden Sie unter Alle Benutzer exportieren.
  • Verwenden Sie zum Exportieren von Benutzerprofilen den Endpunkt users/export.
  • Diese beiden Export-APIs generieren zwei Sicherungsdateien, die Sie speichern müssen, um später im Wiederherstellungsprozess verwendet zu werden.

App ID-Instanz mithilfe der API wiederherstellen

Zunächst müssen Sie manuell eine neue Instanz von App ID in der sekundären Region einrichten. Anschließend können Sie Ihre Einstellungen für App ID wiederherstellen, indem Sie die Sicherungsdateien lesen und die Management-API-Anforderung verwenden, um die App ID-Instanz in der sekundären Region einzurichten.

Wenn Sie mit dem Szenario aus dem Abschnitt "Backup" fortfahren, können Sie die Konfiguration von SAML und die Kennwortrichtlinien wiederherstellen, indem Sie Folgendes an die Verwaltungs-API senden:

curl -X 'PUT' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/cloud_directory/advanced_password_management' \
  --header 'accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <IAM_Token>' \
  -d '<Data_from_your_backup_file>'
  • eine PUT-Anfrage an den /management/v4/<tenantId>/config/idps/saml endpunkt, um die Konfiguration von SAML IdP zu aktualisieren. Übergeben Sie die in der Sicherungskopie gespeicherten Daten als HTTP request body.
curl -X 'PUT' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/idps/saml' \
  --header 'accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <IAM_Token>' \
  -d '<Data_from_your_backup_file>'

Zum Wiederherstellen der Sicherungen Ihrer Cloud Directory-Benutzer und ihrer Profile (falls verfügbar) wird empfohlen, die Management-API zu verwenden:

  • Verwenden Sie zum Importieren von Cloud Directory-Benutzern den API-Endpunkt cloud_directory/import/all. Weitere Informationen zum Importieren von Cloud Directory-Benutzern mit der Management-API finden Sie in der Dokumentation Alle Benutzer importieren.
  • Verwenden Sie zum Importieren der Benutzerprofile den Endpunkt users/import.

App ID-Instanz mithilfe von Terraform und der API wiederherstellen

Wenn Sie eine Kombination aus Terraform und der Management-API verwenden, um Ihre App ID-Instanz wiederherzustellen, besteht der erste Schritt darin, Ihr Terraform-Script zu schreiben, um eine neue Instanz von App ID in der sekundären Region bereitzustellen. Anschließend können Sie Ihre App ID-Einstellungen wiederherstellen, indem Sie die Sicherungsdateien lesen und mithilfe der Terraform-Befehle die App ID-Instanz in der sekundären Region einrichten.

In Anlehnung an das Szenario im Abschnitt " Backup" können Sie die Konfiguration von SAML und die Kennwortrichtlinien mit dem folgenden Skript wiederherstellen:

terraform {
  required_providers {
    ibm = {
      source = "IBM-Cloud/ibm"
      version = ">= 1.12.0"
    }
  }
}

variable "backup_region" {
  type = string
  default = "<<REGION WHERE TO CREATE THE NEW APPID INSTANCE>>"
}

variable "backup_appid_instance_name" {
  type = string
  default = "<<THE NAME OF THE NEW APPID INSTANCE>>"
}

provider "ibm" {
  region = var.backup_region
  ibmcloud_api_key = "<<API KEY TO ACCESS APP ID INSTANCE>>"
}

##### ---------- Creating an AppID instance in a secondary location ---------- #####

data "ibm_resource_group" "group" {
  name = "Default"
}

resource "ibm_resource_instance" "backup_appid_instance" {
  name              = var.backup_appid_instance_name
  service           = "appid"
  plan              = "graduated-tier"
  location          = var.backup_region
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["backup_instance", "backup_of_appid_from_primary_region"]
}

##### ---------- Getting the configuration from the local backups ---------- #####

locals {
	app_config = jsondecode(file("${path.module}/backup_configurations/app_config.json"))
	saml_config = jsondecode(file("${path.module}/backup_configurations/saml_config.json"))
}


##### ---------- Restoring the App ID configuration into the new App ID instance ---------- #####


# Setting SAML config in the new App ID Instance
resource "ibm_appid_idp_saml" "saml" {
  tenant_id = resource.ibm_resource_instance.backup_appid_instance.guid
  is_active = local.saml_config.is_active
  config {
    entity_id = local.saml_config.config[0].entity_id
    sign_in_url = local.saml_config.config[0].sign_in_url
    display_name = local.saml_config.config[0].display_name
    encrypt_response = local.saml_config.config[0].encrypt_response
    sign_request = local.saml_config.config[0].sign_request
    certificates = [local.saml_config.config[0].certificates[0]]
  }
}

# Setting password policies config in the new App ID Instance
resource "ibm_appid_apm" "apm" {
  tenant_id = resource.ibm_resource_instance.backup_appid_instance.guid
  enabled = local.app_config.enabled
  prevent_password_with_username = local.app_config.prevent_password_with_username

  password_reuse {
    enabled = local.app_config.password_reuse[0].enabled
    max_password_reuse = local.app_config.password_reuse[0].max_password_reuse
  }

  password_expiration {
    enabled = local.app_config.password_expiration[0].enabled
    days_to_expire = local.app_config.password_expiration[0].days_to_expire
  }

  lockout_policy {
    enabled = local.app_config.lockout_policy[0].enabled
    lockout_time_sec = local.app_config.lockout_policy[0].lockout_time_sec
    num_of_attempts = local.app_config.lockout_policy[0].num_of_attempts
  }

  min_password_change_interval {
    enabled = local.app_config.min_password_change_interval[0].enabled
    min_hours_to_change_password = local.app_config.min_password_change_interval[0].min_hours_to_change_password
  }
}

Um Cloud Directory-Benutzer und -Benutzerprofile wiederherzustellen, wird die Verwendung der Management-API empfohlen:

Ihre Verantwortlichkeiten für HA und DR

Die folgenden Informationen können Ihnen dabei helfen, Ihren Plan für HA und DR zu erstellen und kontinuierlich zu üben. Die Schritte zur Wiederherstellung im Katastrophenfall müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.

Kundenerholung bei BYOK-Verlust

Wenn Ihre Service-Instanz mit dem Root-Schlüssel von IBM® Key Protect for IBM Cloud® oder Hyper Protect Crypto Services bereitgestellt wurde und Sie den Root-Schlüssel versehentlich gelöscht haben, öffnen Sie einen Support-Fall für den entsprechenden Service und fügen Sie die folgenden Informationen bei:

  • Die CRN Ihrer Dienstinstanz
  • Die CRN Ihrer Backup Key Protect oder HPCS-Instanz
  • Die neue Key Protect oder HPCS Root Key ID
  • Die CRN und die Schlüssel-ID der ursprünglichen Key Protect oder HPCS-Instanz, falls verfügbar

Siehe Wiederherstellung nach einem versehentlichen Schlüsselverlust für die Autorisierung in den Key Protect und HPCS-Dokumenten.

Ä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 Berechtigungen zu gewähren, die für ihre Arbeit erforderlich sind. Schränken Sie zum Beispiel die Möglichkeit ein, Produktionsressourcen zu löschen.

Wie IBM® die Wiederherstellung im Katastrophenfall unterstützt

IBM® spezifische Wiederherstellungsmaßnahmen im Falle einer Katastrophe.

Wie IBM® sich von Zonenausfällen erholt

Im Falle eines Zonenausfalls behebt IBM Cloud den Ausfall der Zone. Sobald die Zone wieder online ist, sendet der globale Load Balancer wieder API-Anfragen an den wiederhergestellten Instanzknoten, ohne dass der Kunde eingreifen muss.

Wie IBM® sich von regionalen Ausfällen erholt

Wenn eine Region nach einem Ausfall wiederhergestellt wird, versucht IBM, die Dienstinstanz aus dem regionalen Zustand wiederherzustellen, was zu keinem Datenverlust führt und die Dienstinstanz mit denselben Verbindungszeichenfolgen wiederherstellt.

Wenn der regionale Status beschädigt ist, wird der Dienst auf dem Stand der letzten internen Sicherung wiederhergestellt. Alle mit dem Dienst verbundenen Daten werden zweimal täglich vom Dienst in einem vom Dienst verwalteten, regionsübergreifenden Cloud Object Storage Bucket gesichert. Es besteht die Gefahr eines Datenverlustes im Wert von 24 Stunden. Diese Backups sind nicht für die vom Kunden verwaltete Notfallwiederherstellung verfügbar. Wenn ein Dienst aus Backups wiederhergestellt wird, wird auch die Instanz-ID wiederhergestellt, so dass Clients, die den Endpunkt verwenden, nicht mit neuen Verbindungszeichenfolgen aktualisiert werden müssen.

  • RTO = 4 Stunden
  • RPO = maximal 12 Stunden

Für den Fall, dass IBM die Service-Instanz nicht wiederherstellen kann, muss der Kunde die Wiederherstellung wie im Abschnitt Disaster Recovery beschrieben durchführen.

Wie IBM® Dienste unterhält

Alle Upgrades werden nach den bewährten Verfahren von IBM® durchgeführt 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.