Descrizione di alta disponibilità e di ripristino di emergenza per App ID

L' alta disponibilitàLa capacità di un servizio o di un carico di lavoro di resistere ai guasti e di continuare a fornire capacità di elaborazione secondo un livello di servizio predefinito. Per i servizi, la disponibilità è definita nell'Accordo sul livello dei servizi. La disponibilità comprende sia gli eventi pianificati che quelli non pianificati, come manutenzione, guasti e disastri. (HA) è la capacità di un servizio di rimanere operativo e accessibile in presenza di guasti imprevisti. Il disaster recoveryLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. è il processo di ripristino dell'istanza di servizio in uno stato funzionante.

IBM Cloud® App ID è un servizio regionale che soddisfa gli obiettivi di livello di servizio(SLO) definiti con il piano standard. Per ulteriori informazioni sulle regioni e sui data center IBM Cloud disponibili per App ID, vedere Disponibilità del servizio e dell'infrastruttura per località.

Architettura ad alta disponibilità

Un'istanza del servizio App ID viene fornita su più zone in una regione multizona senza un singolo punto di guasto. In caso di guasto di un nodo di istanza o di una zona di disponibilità, il servizio continua a funzionare e le richieste API vengono instradate attraverso un bilanciatore di carico globale verso i nodi di istanza altamente disponibili sopravvissuti. Può trascorrere un breve periodo di tempo (secondi) tra l'interruzione e il riconoscimento del guasto da parte del bilanciatore di carico globale, durante il quale le richieste possono essere inviate all'istanza guasta. I carichi di lavoro che accedono programmaticamente all'istanza del servizio devono seguire la logica di retry della disponibilità del client per mantenere la disponibilità. Non si nota alcun degrado del servizio durante un guasto zonale.

Architettura di disaster recovery

Per recuperare un'istanza di servizio interrotta, è necessario creare un'istanza di servizio di recupero in una regione di recupero. In generale, l'istanza del servizio di recupero deve essere configurata con gli stessi dati dell'istanza del servizio di origine. Assicuratevi di creare istanze di backup in una regione di ripristino prima di un potenziale disastro e di mantenerle regolarmente per garantire la sincronizzazione con l'istanza di origine.

Funzionalità di disaster recovery

Pianificare il recupero in una regione di recupero. L'istanza di ripristino deve essere allineata con gli approcci di ripristino di emergenza del carico di lavoro all'interno IBM Cloud. L'istanza di ripristino deve tenere traccia delle modifiche apportate ai dati dell'istanza di servizio primaria, compresi i criteri di password, gli utenti e le configurazioni di SAML.

Backup e ripristino delle istanze

Il backup e il ripristino della tua istanza App ID per assicurare la disponibilità interregionale richiede alcuni passi di base. È necessario:

  1. Definisci le politiche per la configurazione dell'archiviazione del backup della tua istanza App ID. Questa configurazione include la pianificazione di come i dati, come i profili utente e gli utenti Cloud Directory, devono essere archiviati nel backup dell'istanza.

    Creare il sistema di backup prima che si verifichi un incidente di interruzione nell'ubicazione principale. Per mantenere una protezione continua, come consigliato, automatizzare il processo per generare il backup ed eseguirlo periodicamente.

  2. Creare e configurare un'istanza di App ID in un'altra regione.

  3. Imposta un processo per memorizzare il backup e ripristinarlo nell'istanza App ID che si trova nell'ubicazione secondaria.

Backup della tua istanza utilizzando l'API

Per eseguire il backup dell'istanza App ID utilizzando l'API di gestione, scrivere uno script che invii una richiesta all'API App ID per generare i file che contengono le informazioni di configurazione dell'istanza App ID. Archivia questi file in un'ubicazione sicura perché sono necessari per ripristinare l'istanza App ID in una regione secondaria.

Definisci le impostazioni del tuo backup in base alla configurazione nella tua istanza App ID, ad esempio ciò che è necessario per il tuo caso di utilizzo. Ad esempio, nel seguente scenario, configuri la tua istanza App ID con le seguenti impostazioni:

  • politiche di password, come il blocco del profilo utente per 60 minuti se l'utente immette una password errata per tre volte di seguito
  • Configurazione SAML

Per recuperare queste impostazioni utente con l'API di gestione, inviare:

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>'

Oltre a mantenere un backup delle impostazioni di configurazione della tua istanza App ID, devi generare un backup dei tuoi utenti e profili utente Cloud Directory. Per eseguire questa attività, si consiglia di utilizzare l'API di gestione.

  • Per esportare gli utenti Cloud Directory, utilizzare l'endpoint API cloud_directory/export/all. Per scaricare l'esportazione, utilizza l'API cloud_directory/export/download. Per ulteriori dettagli su come esportare gli utenti Cloud Directory con l'API di gestione, leggi la documentazione Esportazione di tutti gli utenti.
  • Per esportare i profili utente, utilizzare l'endpoint users / export.
  • Queste due API di esportazione generano due file di backup, che è necessario memorizzare in modo sicuro per utilizzarli successivamente nel processo di ripristino.

Backup dell'istanza utilizzando Terraform e l'API

Per eseguire il backup delle tue impostazioni App ID con Terraform, puoi scrivere script Terraform per generare file che contengono le informazioni di impostazione per la tua istanza App ID. Archivia tali file in un'ubicazione sicura perché devi utilizzarli per ripristinare l'istanza di App ID in una regione secondaria.

Definisci le impostazioni del tuo backup in base alla configurazione nella tua istanza App ID, ad esempio ciò che è necessario per il tuo caso di utilizzo. Ad esempio, nel seguente scenario, configuri la tua istanza App ID con le seguenti impostazioni:

  • politiche di password, come il blocco del profilo utente per 60 minuti se l'utente immette una password errata per tre volte di seguito
  • Configurazione SAML

Con i seguenti script terraform, puoi recuperare la configurazione corrente e memorizzarla in file.

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"
}

Nello scenario precedente, i file che contengono i backup vengono memorizzati localmente. Ma è possibile conservarli in qualsiasi altro luogo di conservazione che si preferisce, come ad esempio IBM Cloud Object Storage.

Per generare un backup degli utenti Cloud Directory e dei profili utente, si consiglia di utilizzare l'API di gestione.

  • Per esportare gli utenti Cloud Directory, utilizzare l'endpoint API cloud_directory/export/all. Per scaricare l'esportazione, utilizza l'API cloud_directory/export/download. Per ulteriori dettagli su come esportare gli utenti Cloud Directory con l'API di gestione, vedi Esportazione di tutti gli utenti.
  • Per esportare i profili utente, utilizzare l'endpoint users / export.
  • Queste due API di esportazione generano due file di backup, che è necessario memorizzare per utilizzarli successivamente nel processo di ripristino.

Ripristino della tua istanza App ID utilizzando l'API

Per prima cosa, devi eseguire manualmente il provisioning di una nuova istanza di App ID nella regione secondaria. Puoi quindi ripristinare le tue impostazioni App ID leggendo i file di backup e utilizzando la richiesta dell'API di gestione per configurare l'istanza App ID nella regione secondaria.

Continuando con lo scenario incluso nella sezione backup, è possibile ripristinare la configurazione di SAML e i criteri di password inviando quanto segue all'API di gestione:

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>'

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>'

Per ripristinare i backup dei tuoi utenti Cloud Directory e dei relativi profili, se disponibili, ti consigliamo di utilizzare l'API di gestione:

Ripristino della tua istanza App ID utilizzando Terraform e l'API

Quando utilizzi una combinazione di Terraform e dell'API di gestione per ripristinare la tua istanza di App ID, il primo passo è scrivere il tuo script Terraform per eseguire il provisioning di una nuova istanza di App ID nella regione secondaria. Puoi quindi ripristinare le tue impostazioni App ID leggendo i file di backup e utilizzando i comandi terraform per impostare l'istanza App ID nella regione secondaria.

Continuando con lo scenario incluso nella sezione backup, è possibile ripristinare la configurazione di SAML e i criteri delle password con il seguente script:

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
  }
}

Per ripristinare gli utenti e i profili utente Cloud Directory, si consiglia di utilizzare l'API di gestione:

Le vostre responsabilità per HA e DR

Le seguenti informazioni possono aiutarvi a creare e a mettere in pratica costantemente il vostro piano per l'HA e il DR. Le fasi di disaster recovery devono essere praticate regolarmente. Quando costruite il vostro piano, prendete in considerazione i seguenti scenari di fallimento e le relative soluzioni.

Recupero dei clienti dalla perdita di BYOK

Se l'istanza del servizio è stata fornita utilizzando la chiave principale di IBM® Key Protect for IBM Cloud® o Hyper Protect Crypto Services e la chiave principale è stata accidentalmente cancellata, aprire un caso di assistenza per il servizio in questione e includere le seguenti informazioni:

  • Il CRN dell'istanza di servizio
  • Il CRN dell'istanza di backup di Key Protect o HPCS
  • Il nuovo ID della chiave root Key Protect o HPCS
  • Il CRN e l'ID chiave dell'istanza originale di Key Protect o HPCS, se disponibili

Vedere Ripristino da una perdita accidentale di chiavi per l'autorizzazione nella documentazione di Key Protect e nei documenti HPCS.

Gestione delle modifiche

La gestione delle modifiche comprende attività quali aggiornamenti, modifiche alla configurazione e cancellazioni.

Si consiglia di assegnare agli utenti e ai processi i ruoli e le azioni IAM con il minor numero di privilegi necessari per il loro lavoro. Ad esempio, limitare la possibilità di eliminare le risorse di produzione.

Come IBM® aiuta a garantire il ripristino di emergenza

IBM® intraprende azioni specifiche di ripristino in caso di disastro.

Come IBM® recupera i guasti di una zona

In caso di guasto di una zona, IBM Cloud risolverà l'interruzione della zona e, quando questa tornerà in linea, il bilanciatore di carico globale riprenderà a inviare le richieste API al nodo di istanza ripristinato senza bisogno di interventi da parte del cliente.

Come IBM® si riprende dai fallimenti regionali

Quando una regione viene ripristinata dopo un guasto, IBM tenterà di ripristinare l'istanza del servizio dallo stato regionale, senza perdita di dati e ripristinando l'istanza del servizio con le stesse stringhe di connessione.

Se lo stato regionale è danneggiato, il servizio verrà ripristinato allo stato dell'ultimo backup interno. Tutti i dati associati al servizio vengono sottoposti a backup due volte al giorno dal servizio in un bucket Cloud Object Storage gestito dal servizio stesso. È possibile che si verifichi una perdita di dati di 24 ore. Questi backup non sono disponibili per il disaster recovery gestito dal cliente. Quando un servizio viene ripristinato dai backup, viene ripristinato anche l'ID dell'istanza, in modo che i client che utilizzano l'endpoint non debbano essere aggiornati con nuove stringhe di connessione.

  • RTO = 4 ore
  • RPO = 12 ore al massimo

Nel caso in cui IBM non sia in grado di ripristinare l'istanza del servizio, il cliente deve ripristinare il servizio come descritto nella sezione Disaster Recovery.

Come IBM® mantiene i servizi

Tutti gli aggiornamenti seguono le best practice del servizio IBM® e prevedono un piano di ripristino e un processo di rollback. Gli aggiornamenti regolari per le nuove funzionalità e la manutenzione fanno parte delle normali operazioni. Tale manutenzione può occasionalmente causare brevi intervalli di interruzione che vengono gestiti dalla logica di riprova della disponibilità del client. Le modifiche vengono introdotte in modo sequenziale, regione per regione e zona per zona all'interno di una stessa regione. Gli aggiornamenti vengono annullati al primo segno di difetto.

Le modifiche complesse vengono attivate e disattivate con flag di funzione per controllare l'esposizione.

Le modifiche che hanno un impatto sui carichi di lavoro dei clienti sono dettagliate nelle notifiche. Per ulteriori informazioni, consultare le notifiche e lo stato di monitoraggio della manutenzione programmata, gli annunci e le note di rilascio che hanno un impatto su questo servizio.