Entendendo a alta disponibilidade e a recuperação de desastre para o Code Engine

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. (HA) é a capacidade de um serviço permanecer operacional e acessível apesar 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 de lidar com ele. é o processo de restauração das operações de serviço após uma grande interrupção.

Code Engine é um serviço regional altamente disponível projetado para manter a disponibilidade durante interrupções zonais. O site Code Engine atende aos Objetivos de Nível de Serviço(SLO) com o plano Standard.

Para obter mais informações sobre os padrões de alta disponibilidade e recuperação de desastres no IBM Cloud, consulte “Como o IBM Cloud garante alta disponibilidade e redundância ”. Também é possível localizar informações sobre Acordos de Nível de Serviço.

Disponibilidade de instâncias do Code Engine

IBM Cloud® Code Engine é oferecido em vários locais (regiões). Cada região contém três data centers (zonas) para redundância.

Ao provisionar um projeto do Code Engine, você seleciona o local (MZR) no qual a instância é criada. A região determina onde suas cargas de trabalho — como aplicativos, tarefas, funções e frotas — são hospedadas.

Por padrão, sua carga de trabalho é implantada em uma única zona. Se a zona de hospedagem apresentar falha, a carga de trabalho é recriada automaticamente em uma das zonas restantes.

O serviço realiza movimentações controladas de cargas de trabalho entre zonas durante operações normais, como manutenção de serviços e atualizações de software. Essas reinicializações de distribuição são executadas de forma elegante para minimizar a interrupção. Failovers não planejados podem ocorrer durante eventos inesperados no ambiente operacional.

Code Engine armazena metadados (incluindo definições de projeto, aplicativo, função, trabalho, frota e criação de imagem) e os replica em todas as zonas de uma região para garantir a disponibilidade. Como um serviço somente de computação, o Code Engine não é responsável por garantir a alta disponibilidade dos dados da sua carga de trabalho ou das imagens de contêineres. Consulte a documentação dos respectivos serviços de nuvem para obter orientação sobre como garantir alta disponibilidade. Para a disponibilidade da imagem do contêiner, siga as orientações em IBM Cloud Container Registry para garantir que sua carga de trabalho permaneça operacional durante uma interrupção de zona. Se você ler ou armazenar dados em IBM Cloud Object Storage ou em qualquer outro banco de dados ou serviço de armazenamento de IBM Cloud, consulte a documentação de cada serviço para conhecer os recursos de alta disponibilidade.

Code Engine topologia regional topologia regional topologia regional
Code Engine

Regiões do Code Engine

A tabela a seguir lista as regiões em que o site Code Engine está disponível e seu status de alta disponibilidade.

Regiões Code Engine altamente disponíveis
Geografia Região Alta disponibilidade
Ásia-Pacífico Austrália, Sydney (au-syd) MZR
Ásia-Pacífico Índia, Chennai (in-che) MZR
Ásia-Pacífico Japão, Osaka (jp-osa) MZR
Ásia-Pacífico Japão, Tóquio (jp-tok) MZR
Europa Alemanha, Frankfurt (eu-de) MZR
Europa Espanha, Madri (eu-es) MZR
Europa Reino Unido, Londres (eu-gb) MZR
América do Norte Canadá, Toronto (ca-tor) MZR
América do Norte EUA, Dallas (us-south) MZR
América do Norte EUA, Washington (us-east) MZR
América do Sul Brasil, São Paulo (br-sao) MZR

Uma área geográfica é uma área que abrange uma ou mais regiões. Cada região conta com várias zonas de disponibilidade para atender aos requisitos locais de acesso, baixa latência e segurança. Cada região de várias zonas(MZR) consiste em 3 ou mais zonas independentes, garantindo que eventos de falha única afetem apenas uma zona.

Recuperação de desastre para instâncias do Code Engine

Em um grande desastre regional — como um terremoto, uma enchente ou um evento climático extremo —, toda uma região pode ser afetada. Para garantir que suas cargas de trabalho sejam resilientes a tais eventos, implante-as em várias MZRs e implemente um mecanismo de failover automático utilizando um serviço de Edge Proxy. Por exemplo, você pode usar IBM Cloud® Internet Services. Para obter mais informações sobre a implementação de um aplicativo em várias regiões, consulte Implementando um aplicativo em várias regiões com um nome de domínio customizado.

Code Engine topologia global topologia global topologia global
Code Engine

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

Fazendo backup de suas instâncias do Code Engine

IBM Cloud faz o backup automático dos metadados do projeto Code Engine e os armazena no armazenamento inter-regional para fins de recuperação de desastres.

Pontos finais inter-regionais
Região do Code Engine Terminal regional cruzado
au-syd AP
br-sao BR
ca-tor CA
eu-de EU
eu-es EU
eu-gb EU
jp-osa AP
jp-tok AP
us-east US
us-south US

Para evitar impactos não intencionais em suas cargas de trabalho, como duplicação de tarefas ou implantação de instâncias de aplicativos indesejadas, o site Code Engine não restaura automaticamente suas cargas de trabalho. A restauração de suas cargas de trabalho é de sua responsabilidade. Para obter mais informações, consulte Entendendo suas responsabilidades ao usar o Code Engine.

Objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO)

  • O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável que um sistema, aplicativo ou processo comercial pode ficar off-line antes de causar um impacto significativo nos negócios.

  • O objetivo do ponto de recuperação (RPO) define a quantidade máxima aceitável de perda de dados (medida em tempo) após um evento de HA ou DR.

IBM realiza testes regulares de HA/DR que incluem failover de HA, cenários de DR isolados (excluindo dados de propriedade do cliente e definições de carga de trabalho), restauração de dados e simulação de parâmetros não técnicos.

Durante esses testes, os objetivos de RTO (tempo de recuperação) e RPO (ponto de recuperação) são medidos e verificados.

Metas de RTO/RPO
Objetivo Target
Failover automático durante a interrupção da zona RTO = segundos, RPO = 0
Recuperação de desastres, excluindo a recuperação de artefatos de propriedade do cliente RTO = horas, RPO = 1 dia

Planejando a Recuperação de Desastre

Além dos testes de HA/DR do IBM, você deve praticar regularmente seus procedimentos de recuperação de desastres. Ao criar seu plano, considere os seguintes cenários de falha e resoluções.

Eventos e resolução de HA/DR
Evento Resolução
Falha de hardware (infraestrutura de computação) IBM fornece uma infraestrutura resiliente a falhas de hardware de ponto único em uma zona, sem necessidade de configuração.
falha da zona Failover automático (consulte Disponibilidade das instâncias do Code Engine ). A carga de trabalho é movida automaticamente para uma zona disponível.
Distorção de dados Você é responsável por criar backups de seus dados.
Falha regional Não há failover automático. Conforme descrito em Recuperação de desastres para instâncias do Code Engine, você deve implementar sua carga de trabalho em uma segunda região de várias zonas.
Disponibilidade de carga de trabalho Você é responsável por implementar seus aplicativos de negócios para recuperar o estado do armazenamento externo ou dos bancos de dados.
Resiliência de HA/DR Você é responsável por garantir que uma equipe treinada esteja disponível para gerenciar seus componentes e restaurar suas cargas de trabalho e dados de propriedade do cliente durante uma interrupção.

Suas responsabilidades com HA e DR

Use as seguintes listas de verificação associadas a cada recurso para ajudá-lo a criar e praticar seu plano.

  • Imagens de contêineres usadas para aplicativos, trabalhos e frotas do IBM Cloud® Code Engine

    Verifique se as imagens do contêiner estão disponíveis na região de backup IBM Cloud Container Registry.

  • Pacotes de código usados para as funções do site IBM Cloud® Code Engine

    Verifique se os pacotes de códigos estão disponíveis em sua região de backup IBM Cloud Container Registry.

Um plano de teste abrangente de alta disponibilidade (HA) e recuperação de desastres (DR) inclui a definição de suas metas de RTO e RPO, a identificação de sistemas críticos e a validação da integridade do backup, failover de rede e sincronização de dados. As principais etapas envolvem a simulação de falhas (como falha de nó ou interrupção do site), a execução de procedimentos de failover, a verificação da funcionalidade do sistema e a documentação do processo de fallback.

  • Preparação para o teste

    • Defina os objetivos: Confirme o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO).
    • Identifique os sistemas críticos: Liste todos os sistemas, dados e aplicativos que exigem failover.
    • Estabeleça as funções da equipe: Defina as responsabilidades da equipe de DR e designe uma pessoa de contato principal.
    • Verificação de backup: Confirmar se os backups são válidos e acessíveis.
    • Isolamento do ambiente: Isolar os sistemas de teste para evitar impactos acidentais nos ambientes de produção.

  • Execução de testes

    • Simular cenário de falha: inicie uma falha planejada, como corte de conectividade de rede, interrupção de um serviço ou desligamento de um servidor primário.
    • Execução de failover: Executar o procedimento de failover documentado para o site secundário/DR.
    • Verificar a integridade dos dados: Use somas de verificação ou valores de hash para garantir que os dados não estejam corrompidos.
    • Validação de aplicativos: Teste a funcionalidade dos aplicativos no site de DR.
    • Redirecionamento de DNS/tráfego: Valide se o tráfego do usuário é redirecionado para o novo nó ativo.

  • Pós-teste e documentação

    • Realizar failback: Colocar o site primário novamente on-line e ressincronizar os dados.
    • Documentar os resultados: Registre os horários, os sucessos e quaisquer desvios do plano.
    • Identificar lacunas: Identifique as deficiências no plano e atualize os procedimentos de acordo.
    • Auditoria de comunicação: Verificar se as notificações foram enviadas a todas as partes interessadas.

  • Cenários de teste comuns

    • Teste de HA: Failover local para um nó de espera (por exemplo, no mesmo data center).
    • Teste de DR: Failover completo para um local geograficamente separado.
    • Restauração de dados: Restauração completa de dados de propriedade do cliente e artefatos de carga de trabalho de um datastore de backup para o local de backup primário ou selecionado.
    • Disponibilidade da equipe: Teste o impacto operacional se o pessoal-chave não estiver disponível ou não puder se conectar aos seus sistemas.