Entendendo a alta disponibilidade e a recuperação de desastre para o App ID

Alta disponibilidadeA capacidade de um serviço ou carga de trabalho de resistir a falhas e continuar fornecendo capacidade de processamento de acordo com algum nível de serviço predefinido. Para serviços, a disponibilidade é definida no Contrato de Nível de Serviço. A disponibilidade inclui eventos planejados e não planejados, como manutenção, falhas e desastres. (HA) é a capacidade de um serviço permanecer operacional e acessível na presença de falhas inesperadas. A recuperação de desastresA capacidade de um serviço ou carga de trabalho de se recuperar de incidentes raros e importantes e de falhas em larga escala, como a interrupção do serviço. Isso inclui um desastre físico que afeta toda uma região, a corrupção de um banco de dados ou a perda de um serviço que contribui para uma carga de trabalho. O impacto excede a capacidade do projeto de alta disponibilidade para lidar com ele. é o processo de recuperação da instância de serviço para um estado de funcionamento.

IBM Cloud® App ID é um serviço regional que atende aos objetivos de nível de serviço(SLO) definidos com o plano padrão. Para obter mais informações sobre as regiões e os data centers disponíveis em IBM Cloud para App ID, consulte Disponibilidade de serviço e infraestrutura por local.

Arquitetura de alta disponibilidade

Uma instância de serviço App ID é provisionada em várias zonas em uma região com várias zonas sem um único ponto de falha. No caso de falha de um nó de instância ou de uma zona de disponibilidade, o serviço continua a ser executado com as solicitações de API sendo roteadas por meio de um balanceador de carga global para os nós de instância altamente disponíveis sobreviventes. Pode haver um curto período de tempo (segundos) entre a interrupção e o reconhecimento da falha pelo balanceador de carga global, durante o qual as solicitações podem ser enviadas para a instância com falha. As cargas de trabalho que acessam programaticamente a instância do serviço devem seguir a lógica de repetição de disponibilidade do cliente para manter a disponibilidade. Não há degradação perceptível do serviço durante uma falha zonal.

Arquitetura de recuperação de desastres

Para se recuperar de uma interrupção de instância de serviço, uma instância de serviço de recuperação deve ser criada em uma região de recuperação. Em geral, a instância do serviço de recuperação deve ser configurada com os mesmos dados que a instância do serviço de origem. Certifique-se de criar instâncias de backup em uma região de recuperação antes de um possível desastre e de mantê-las regularmente para garantir que estejam sincronizadas com a instância de origem.

Recursos de recuperação de desastres

Planeje a recuperação em uma região de recuperação. A instância de recuperação deve estar alinhada com as abordagens de recuperação de desastres de carga de trabalho no IBM Cloud. A instância de recuperação deve rastrear as alterações de dados na instância de serviço principal para dados, incluindo políticas de senha, usuários e configurações do SAML.

Fazendo backup e restaurando suas instâncias

Fazer backup e restaurar sua instância do App ID para assegurar a disponibilidade regional cruzada requer algumas etapas básicas. Você deve:

  1. Defina as políticas para configurar o armazenamento do backup da instância do App ID. Essa configuração inclui planejar como os dados, como os perfis do usuário e os usuários do Cloud Directory, devem ser armazenados no backup de sua instância.

    Crie o sistema de backup antes que um incidente de indisponibilidade ocorra em seu local primário Para manter a proteção contínua, conforme recomendado, automatiza o processo para gerar o backup e executá-lo periodicamente.

  2. Crie e configure uma instância do App ID em outra região.

  3. Configure um processo para armazenar o backup e restaurá-lo na instância App ID que está no local secundário.

Fazendo backup de sua instância usando a API

Para fazer backup da instância App ID usando a API de gerenciamento, escreva um script para enviar uma solicitação à API App ID para gerar arquivos que contenham as informações de configuração da instância App ID. Armazene esses arquivos em um local seguro porque eles são necessários para restaurar a instância do App ID em uma região secundária.

Defina as configurações de seu backup com base na configuração em sua instância do App ID, como o que é necessário para seu caso de uso. Por exemplo, no cenário a seguir, você configura a instância do App ID com as configurações a seguir:

  • políticas de senha, como bloquear o perfil do usuário por 60 minutos se o usuário inserir uma senha errada por três vezes em uma linha
  • Configuração de SAML

Para recuperar essas configurações do usuário com a API de gerenciamento, envie:

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

Além de manter um backup das definições de configuração de sua instância do App ID, deve-se gerar um backup de seus usuários e perfis do usuário do Cloud Directory Para atingir essa tarefa, é recomendado usar a API de gerenciamento.

  • Para exportar os usuários do Cloud Directory, use o terminal de API cloud_directory/export/all Para fazer download da exportação, use a API cloud_directory/export/download. Para obter mais detalhes sobre como exportar usuários do Cloud Directory com a API de Gerenciamento, leia a documentação Exportando todos os usuários..
  • Para exportar perfis de usuários, use o terminal users / export..
  • Essas duas APIs de exportação geram dois arquivos de backup, que você deve armazenar com segurança para usar posteriormente no processo de restauração.

Fazendo backup de sua instância usando o Terraform e a API

Para fazer backup de suas configurações do App ID com o Terraform, é possível gravar scripts do Terraform para gerar arquivos que contêm as informações de configuração para a sua instância do App ID. Armazene esses arquivos em um local seguro porque deve-se usá-los para restaurar a instância do App ID em uma região secundária.

Defina as configurações de seu backup com base na configuração em sua instância do App ID, como o que é necessário para seu caso de uso. Por exemplo, no cenário a seguir, você configura a instância do App ID com as configurações a seguir:

  • políticas de senha, como bloquear o perfil do usuário por 60 minutos se o usuário inserir uma senha errada por três vezes em uma linha
  • Configuração de SAML

Com o script do Terraform a seguir, é possível recuperar sua configuração atual e armazená-la em arquivos.

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

No cenário anterior, os arquivos que contêm os backups são armazenados localmente. No entanto, você pode armazená-los em qualquer outro local de armazenamento de sua preferência, como IBM Cloud Object Storage.

Para gerar um backup de usuários e perfis do usuário do Cloud Directory, é recomendado que você use a API de gerenciamento

  • Para exportar os usuários do Cloud Directory, use o terminal de API cloud_directory/export/all Para fazer download da exportação, use a API cloud_directory/export/download. Para obter mais detalhes sobre como exportar usuários do Cloud Directory com a API Management, consulte Exportando todos os usuários.
  • Para exportar perfis de usuários, use o terminal users / export..
  • Essas duas APIs de exportação geram dois arquivos de backup, que devem ser armazenados para serem usados posteriormente no processo de restauração

Restaurando sua instância do App ID usando a API

Primeiro, deve-se fornecer manualmente uma nova instância do App ID na região secundária. Em seguida, é possível restaurar as configurações do App ID lendo os arquivos de backup e usando a solicitação da API de gerenciamento para configurar a instância App ID na região secundária.

Continuando com o cenário incluído na seção de backup, você pode restaurar a configuração do SAML e as políticas de senha enviando o seguinte para a API de gerenciamento:

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>'
  • uma solicitação PUT para o ponto de extremidade /management/v4/<tenantId>/config/idps/saml para atualizar a configuração do SAML IdP. Passe os dados que estão armazenados no backup como o corpo da solicitação HTTP.
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 os backups de seus usuários do Cloud Directory e seus perfis, se disponíveis, é recomendado que você use a API de gerenciamento:

Restaurando sua instância do App ID usando o Terraform e a API.

Quando você estiver usando uma combinação do Terraform e da API de gerenciamento para restaurar sua instância do App ID, a primeira etapa será gravar seu script do Terraform para provisionar uma nova instância do App ID na região secundária. Em seguida, é possível restaurar as configurações do App ID lendo os arquivos de backup e usando os comandos do terraform para configurar a instância do App ID na região secundária.

Continuando com o cenário incluído na seção de backup, é possível restaurar a configuração do site SAML e as políticas de senha com o seguinte 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 usuários e perfis de usuário do Cloud Directory, recomenda-se usar a API de gerenciamento:

Suas responsabilidades com HA e DR

As informações a seguir podem ajudá-lo a criar e praticar continuamente seu plano de HA e DR. As etapas de recuperação de desastres devem ser praticadas regularmente. Ao criar seu plano, considere os seguintes cenários de falha e soluções.

Recuperação do cliente após a perda do BYOK

Se a sua instância de serviço foi provisionada usando a chave raiz de IBM® Key Protect for IBM Cloud® ou Hyper Protect Crypto Services e você excluiu acidentalmente a chave raiz, abra um caso de suporte para o respectivo serviço e inclua as seguintes informações:

  • O CRN de sua instância de serviço
  • Seu backup Key Protect ou o CRN da instância HPCS
  • A nova ID da chave raiz Key Protect ou HPCS
  • O CRN e a ID de chave da instância original do Key Protect ou do HPCS, se disponíveis

Consulte Recuperação de uma perda acidental de chave para obter autorização nos documentos Key Protect e nos documentos HPCS.

Gerenciamento de mudanças

O gerenciamento de alterações inclui tarefas como upgrades, alterações de configuração e exclusão.

Recomenda-se conceder aos usuários e processos as funções e ações do IAM com o mínimo de privilégio necessário para o trabalho deles. Por exemplo, limitar a capacidade de excluir recursos de produção.

Como o site IBM® ajuda a garantir a recuperação de desastres

IBM® adota ações de recuperação específicas no caso de um desastre.

Como o IBM® se recupera de falhas de zona

No caso de uma falha de zona, o IBM Cloud resolverá a interrupção da zona e, quando a zona voltar a ficar on-line, o balanceador de carga global retomará o envio de solicitações de API para o nó de instância restaurado sem a necessidade de ação do cliente.

Como o site IBM® se recupera de falhas regionais

Quando uma região for restaurada após uma falha, o site IBM tentará restaurar a instância de serviço a partir do estado regional, o que não resultará em perda de dados e a instância de serviço será restaurada com as mesmas cadeias de conexão.

Se o estado regional for corrompido, o serviço será restaurado para o estado do último backup interno. O serviço faz backup de todos os dados associados ao serviço duas vezes por dia em um bucket Cloud Object Storage entre regiões gerenciado pelo serviço. Há um potencial de perda de dados de 24 horas. Esses backups não estão disponíveis para recuperação de desastres gerenciada pelo cliente. Quando um serviço é recuperado de backups, o ID da instância também é restaurado, de modo que os clientes que usam o endpoint não precisam ser atualizados com novas cadeias de conexão.

  • RTO = 4 horas
  • RPO = máximo de 12 horas

Caso o site IBM não consiga restaurar a instância do serviço, o cliente deverá restaurar conforme descrito na seção de recuperação de desastres.

Como o site IBM® mantém os serviços

Todos os upgrades seguem as práticas recomendadas de serviço do site IBM® e têm um plano de recuperação e um processo de reversão em vigor. Atualizações regulares para novos recursos e manutenção ocorrem como parte das operações normais. Essa manutenção pode ocasionalmente causar curtos intervalos de interrupção que são tratados pela lógica de nova tentativa de disponibilidade do cliente. As alterações são implementadas sequencialmente, região por região e zona por zona dentro de uma região. As atualizações são canceladas ao primeiro sinal de defeito.

As alterações complexas são ativadas e desativadas com sinalizadores de recursos para controlar a exposição.

As alterações que afetam as cargas de trabalho dos clientes são detalhadas nas notificações. Para obter mais informações, consulte notificações de monitoramento e status para manutenção planejada, anúncios e notas de versão que afetam esse serviço.