Visión general de la alta disponibilidad y la recuperación tras desastre para App ID

La alta disponibilidadCapacidad de un servicio o carga de trabajo para soportar fallos y seguir proporcionando capacidad de procesamiento de acuerdo con algún nivel de servicio predefinido. En el caso de los servicios, la disponibilidad se define en el Acuerdo de Nivel de Servicio. La disponibilidad incluye tanto los eventos planificados como los no planificados, como el mantenimiento, los fallos y las catástrofes. (HA) es la capacidad de un servicio de permanecer operativo y accesible ante fallos inesperados. La recuperación de desastresCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. es el proceso de recuperación de la instancia de servicio a un estado de funcionamiento.

IBM Cloud® App ID es un servicio regional que cumple los Objetivos de Nivel de Servicio(OEN ) definidos con el plan estándar. Para más información sobre las regiones y centros de datos disponibles en IBM Cloud para App ID, consulte Disponibilidad de servicios e infraestructuras por ubicación.

Arquitectura de alta disponibilidad

Una instancia de servicio de App ID se aprovisiona en varias zonas de una región multizona sin ningún punto único de fallo. En caso de fallo de un nodo de instancia o de una zona de disponibilidad, el servicio sigue funcionando y las solicitudes de API se enrutan a través de un equilibrador de carga global a los nodos de instancia de alta disponibilidad supervivientes. Puede haber un corto periodo de tiempo (segundos) entre la interrupción y que el balanceador de carga global reconozca el fallo, durante el cual, las peticiones pueden ser enviadas a la instancia que ha fallado. Las cargas de trabajo que acceden mediante programación a la instancia de servicio deben seguir la lógica de reintento de disponibilidad del cliente para mantener la disponibilidad. No hay degradación perceptible del servicio durante un fallo zonal.

Arquitectura de recuperación en caso de catástrofe

Para recuperarse de una interrupción de una instancia de servicio, debe crearse una instancia de servicio de recuperación en una región de recuperación. En general, la instancia de servicio de recuperación debe configurarse con los mismos datos que la instancia de servicio de origen. Asegúrese de crear instancias de copia de seguridad en una región de recuperación antes de un posible desastre y de mantenerlas regularmente para garantizar que están sincronizadas con la instancia de origen.

Funciones de recuperación en caso de catástrofe

Planificar la recuperación en una región de recuperación. La instancia de recuperación debe alinearse con los enfoques de recuperación ante desastres de carga de trabajo dentro de IBM Cloud. La instancia de recuperación debe realizar un seguimiento de los cambios de datos en la instancia de servicio primaria para datos que incluyan políticas de contraseñas, usuarios y configuraciones de SAML.

Copia de seguridad y restauración de las instancias

La copia de seguridad y restauración de la instancia de App ID para garantizar la disponibilidad entre regiones requiere algunos pasos básicos. Deba hacer lo siguiente:

  1. Defina las políticas para configurar el almacenamiento de la copia de seguridad de la instancia de App ID. Esta configuración incluye la planificación de cómo se van a almacenar los datos, como los perfiles de usuario y los usuarios de Cloud Directory, en la copia de seguridad de la instancia.

    Cree el sistema de copia de seguridad antes de que se produzca una incidencia de parada en la ubicación primaria. Para mantener una protección continua, tal como se recomienda, automatice el proceso para generar la copia de seguridad y ejecutarla periódicamente.

  2. Cree y configure una instancia de App ID en otra región.

  3. Configure un proceso para almacenar la copia de seguridad y restaurarla en la instancia de App ID que está en la ubicación secundaria.

Copia de seguridad de la instancia utilizando la API

Para realizar una copia de seguridad de su instancia App ID utilizando la API de gestión, escriba un script que envíe una solicitud a la API App ID para generar archivos que contengan la información de configuración de su instancia App ID. Almacene estos archivos en una ubicación segura porque son necesarios para restaurar la instancia de App ID en una región secundaria.

Defina los valores de la copia de seguridad basándose en la configuración de la instancia de App ID, como por ejemplo lo que se necesita para su caso de uso. Por ejemplo, en el escenario siguiente, puede configurar la instancia de App ID con los valores siguientes:

  • políticas de contraseñas, como bloquear el perfil de usuario durante 60 minutos si el usuario especifica una contraseña incorrecta durante tres veces seguidas
  • Configuración de SAML

Para recuperar estos valores de usuario con la API de gestión, envíe:

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

Además de mantener una copia de seguridad de los valores de configuración de la instancia de App ID, debe generar una copia de seguridad de los usuarios y perfiles de usuario de Cloud Directory. Para realizar esta tarea, se recomienda utilizar la API de gestión.

  • Para exportar usuarios de Cloud Directory, utilice el punto final de API cloud_directory/export/all. Para descargar la exportación, utilice la API cloud_directory/export/download. Para obtener más detalles sobre cómo exportar usuarios de Cloud Directory con la API de gestión, consulte la documentación de Exportación de todos los usuarios.
  • Para exportar perfiles de usuario, utilice el punto final users/export.
  • Estas dos API de exportación generan dos archivos de copia de seguridad, que debe almacenar de forma segura para utilizarlos posteriormente en el proceso de restauración.

Copia de seguridad de la instancia utilizando Terraform y la API

Para realizar una copia de seguridad de los valores de App ID con Terraform, puede escribir scripts de Terraform para generar archivos que contengan la información de configuración para la instancia de App ID. Almacene estos archivos en una ubicación segura porque debe utilizarlos para restaurar la instancia de App ID en una región secundaria.

Defina los valores de la copia de seguridad basándose en la configuración de la instancia de App ID, como por ejemplo lo que se necesita para su caso de uso. Por ejemplo, en el escenario siguiente, puede configurar la instancia de App ID con los valores siguientes:

  • políticas de contraseñas, como bloquear el perfil de usuario durante 60 minutos si el usuario especifica una contraseña incorrecta durante tres veces seguidas
  • Configuración de SAML

Con el siguiente script terraform, puede recuperar la configuración actual y almacenarla en archivos.

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

En el escenario anterior, los archivos que contienen las copias de seguridad se almacenan localmente. Pero, puede guardarlos en cualquier otro lugar de almacenamiento que prefiera, como por ejemplo IBM Cloud Object Storage.

Para generar una copia de seguridad de los usuarios y perfiles de usuario de Cloud Directory, se recomienda utilizar la API de gestión.

  • Para exportar usuarios de Cloud Directory, utilice el punto final de API cloud_directory/export/all. Para descargar la exportación, utilice la API cloud_directory/export/download. Para obtener más detalles sobre cómo exportar usuarios de Cloud Directory con la API de gestión, consulte Exportación de todos los usuarios.
  • Para exportar perfiles de usuario, utilice el punto final users/export.
  • Estas dos API de exportación generan dos archivos de copia de seguridad, que debe almacenar para utilizarlos más adelante en el proceso de restauración.

Restauración de la instancia de App ID utilizando la API

En primer lugar, debe suministrar manualmente una nueva instancia de App ID en la región secundaria. A continuación, puede restaurar los valores de App ID leyendo los archivos de copia de seguridad y utilizando la solicitud de API de gestión para configurar la instancia de App ID en la región secundaria.

Continuando con el escenario incluido en la sección de copias de seguridad, puede restaurar la configuración de SAML y las políticas de contraseñas enviando lo siguiente a la API de gestión:

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

Para restaurar las copias de seguridad de los usuarios de Cloud Directory y sus perfiles, si están disponibles, se recomienda utilizar la API de gestión:

Restauración de la instancia de App ID utilizando Terraform y la API

Cuando utiliza una combinación de Terraform y la API de gestión para restaurar la instancia de App ID, el primer paso es escribir el script de Terraform para suministrar una nueva instancia de App ID en la región secundaria. A continuación, puede restaurar los valores de App ID leyendo los archivos de copia de seguridad y utilizando los mandatos terraform para configurar la instancia de App ID en la región secundaria.

Continuando con el escenario que se incluye en la sección de copias de seguridad, puede restaurar la configuración de SAML y las políticas de contraseñas con el siguiente 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
  }
}

Para restaurar usuarios y perfiles de usuario de Cloud Directory, se recomienda utilizar la API de gestión:

Sus responsabilidades en HA y DR

La siguiente información puede ayudarle a crear y practicar continuamente su plan de HA y DR. Las medidas de recuperación en caso de catástrofe deben practicarse con regularidad. Cuando elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y su resolución.

Recuperación del cliente tras la pérdida de BYOK

Si su instancia de servicio se aprovisionó utilizando la clave raíz de IBM® Key Protect for IBM Cloud® o Hyper Protect Crypto Services y borró accidentalmente la clave raíz, abra un caso de soporte para el servicio correspondiente e incluya la siguiente información:

  • CRN de su instancia de servicio
  • CRN de su copia de seguridad Key Protect o instancia HPCS
  • El nuevo ID de la clave raíz Key Protect o HPCS
  • El CRN y el ID de clave de la instancia original de Key Protect o HPCS, si están disponibles

Consulte Recuperación de una pérdida de clave accidental para obtener autorización en los documentos Key Protect y HPCS.

Gestión de cambios

La gestión de cambios incluye tareas como actualizaciones, cambios de configuración y eliminaciones.

Se recomienda conceder a los usuarios y procesos las funciones y acciones de IAM con los menores privilegios necesarios para su trabajo. Por ejemplo, limitar la capacidad de eliminar recursos de producción.

Cómo ayuda IBM® a garantizar la recuperación en caso de catástrofe

IBM® adopta medidas específicas de recuperación en caso de catástrofe.

Cómo se recupera IBM® de los fallos de zona

En caso de fallo de una zona, IBM Cloud resolverá la interrupción de la zona y, cuando ésta vuelva a estar en línea, el equilibrador de carga global reanudará el envío de solicitudes de API al nodo de instancia restaurado sin necesidad de que intervenga el cliente.

Cómo se recupera IBM® de los fracasos regionales

Cuando se restaura una región después de un fallo, IBM intentará restaurar la instancia de servicio a partir del estado regional, con lo que no se perderán datos y la instancia de servicio se restaurará con las mismas cadenas de conexión.

Si el estado regional se corrompe, el servicio se restaurará al estado de la última copia de seguridad interna. El servicio realiza dos copias de seguridad diarias de todos los datos asociados al servicio en un bucket Cloud Object Storage gestionado por el servicio. Existe la posibilidad de perder datos durante 24 horas. Estas copias de seguridad no están disponibles para la recuperación de desastres gestionada por el cliente. Cuando se recupere un servicio de las copias de seguridad, el ID de instancia también se restaurará, por lo que los clientes que utilicen el punto final no tendrán que actualizarse con nuevas cadenas de conexión.

  • RTO = 4 horas
  • OPR = 12 horas como máximo

En caso de que IBM no pueda restaurar la instancia de servicio, el cliente deberá restaurarla tal y como se describe en la sección de recuperación ante desastres.

Cómo IBM® mantiene los servicios

Todas las actualizaciones siguen las mejores prácticas de servicio de IBM® y cuentan con un plan de recuperación y un proceso de reversión. Las actualizaciones periódicas para nuevas funciones y el mantenimiento forman parte de las operaciones normales. Este mantenimiento puede causar ocasionalmente breves intervalos de interrupción que son gestionados por la lógica de reintento de disponibilidad del cliente. Los cambios se introducen secuencialmente, región por región y zona por zona dentro de una misma región. Las actualizaciones se echan atrás a la primera señal de un defecto.

Los cambios complejos se activan y desactivan con banderas de función para controlar la exposición.

Los cambios que afectan a las cargas de trabajo de los clientes se detallan en las notificaciones. Para obtener más información, consulte las notificaciones de seguimiento y el estado del mantenimiento planificado, los anuncios y las notas de la versión que afectan a este servicio.