Considerações de design para cargas de trabalho resilientes com discos regionais

Last reviewed 2020-09-23 UTC

Este documento explica os comportamentos e as interações entre um aplicativo com estado, um agente de verificação de integridade e um plano de controle regional específico do aplicativo que é usado para monitorar e orquestrar um failover zonal por meio da implantação de discos regionais replicados de forma síncrona .

Este documento é destinado a desenvolvedores de aplicativos como uma continuação do Construir serviços de HA usando discos regionais , expandindo o design e a arquitetura descritos na seção Construindo serviços de banco de dados de HA usando discos regionais . Recomendamos que você leia esse documento primeiro, especialmente as seções sobre considerações de design e comparação de custos, desempenho e resiliência .

Um aplicativo sem estado aumenta a resiliência ao ter pelo menos uma instância secundária do Compute Engine em execução em uma zona diferente. Quando a instância primária falha, o aplicativo continua em execução na instância secundária. Um aplicativo com estado pode persistir seu estado de aplicativo em um disco zonal ou em um disco que esteja disponível apenas em uma única zona, para recuperar seu estado após uma reinicialização da instância. Para ser resiliente, um aplicativo com estado também deve persistir o estado do aplicativo em uma instância secundária.

A Figura 1 ilustra um aplicativo típico com estado de dois nós que é replicado em duas zonas. O aplicativo em cada zona possui um disco zonal para capturar o estado do aplicativo e uma conexão de rede entre as instâncias para sincronizar as alterações de estado do aplicativo entre os nós.

Um balanceador de carga é usado para replicar o estado de um aplicativo para uma instância primária e uma instância secundária, que estão em zonas diferentes.

Figura 1. Aplicativo com estado de dois nós sem discos regionais

Adicionando um disco regional

Outra maneira de sincronizar o estado de um aplicativo com estado é adicionar um disco regional . Quando um aplicativo grava seu estado em um disco regional,Google Cloud sincroniza automaticamente o armazenamento em bloco com outra zona.

A Figura 2 mostra a arquitetura de um aplicativo de banco de dados com estado.

Um disco regional é anexado a duas instâncias de VM em duas zonas.

Figura 2. Aplicativo de banco de dados com estado

Como mostra a figura 2, ainda existem duas instâncias de computação de aplicativos — uma instância primária e uma instância secundária — implantadas em duas zonas. Além de usar um disco regional para armazenamento de estado do aplicativo, há agora uma entidade extra, o plano de controle regional específico do aplicativo. O plano de controle regional específico do aplicativo decide qual instância tem o disco regional anexado e qual instância é a instância primária atual. Essa arquitetura é uma configuração ativa-passiva porque somente a instância primária pode confirmar um estado de aplicativo no disco regional.

Instâncias de computação e o aplicativo com estado

A Figura 2 ilustra um aplicativo de banco de dados quente e ativo-passivo. As seguintes configurações também são possíveis:

  • Se seu objetivo de tempo de recuperação (RTO) puder suportar a latência adicional de iniciar uma instância secundária, você poderá economizar nos custos do Compute Engine executando apenas a instância ativa. Num failover, o plano de controlo regional específico da aplicação inicia a instância secundária e anexa o disco regional a essa instância.
  • Cargas de trabalho de processamento em lote ou fluxo que verificam seu progresso no disco regional. Num failover, a aplicação retoma o processamento a partir do último ponto de verificação.

Gerenciar inicializações de instâncias do Compute Engine

Como apenas uma única instância de computação pode ter um disco regional anexado por vez, é necessário inicializar as instâncias e anexar o disco regional sistematicamente. Uma prática recomendada é separar a instância de computação e a inicialização do aplicativo do anexo do disco regional. Os scripts de inicialização da instância não devem iniciar o anexo do disco regional. Em vez disso, os scripts de inicialização devem iniciar o agente de verificação de integridade e aguardar a conexão do disco regional.

Na inicialização, a instância de computação precisa executar as seguintes etapas sequenciais:

  1. Inicie o agente de verificação de funcionamento.
  2. Aguarde até que o disco regional seja anexado.
  3. Depois que o disco regional for anexado, monte o sistema de arquivos.
  4. Após a montagem do sistema de arquivos, inicie o aplicativo.

Essas etapas abrangem a inicialização do sistema, mas também há um failover. Durante um failover, o disco regional é anexado à instância secundária. O disco regional também é removido à força da instância primária e as operações de E/S para o sistema de arquivos falham. Neste ponto, você precisa desligar ou reiniciar a instância de computação.

Executando o agente de verificação de funcionamento e as verificações de funcionamento

Conforme descrito na seção anterior, a instância de computação aguarda a anexação do disco regional antes de iniciar o aplicativo. O plano de controle regional específico do aplicativo anexa o disco regional, mas apenas a uma instância de computação que está aguardando a anexação do disco. Quando um disco é anexado, o plano de controle específico do aplicativo monitora a integridade do aplicativo e inicia um failover se o aplicativo não estiver íntegro.

Cada instância de computação tem um dos seguintes estados:

  • Abaixo
  • Começando
  • Esperando por um disco
  • Aplicativo em execução

O agente de verificação de integridade informa o estado atual da instância. Em vez de relatar esses dois estados por meio de uma única verificação de integridade, você pode executar duas verificações de integridade binárias. Se a instância de computação estiver pronta para ter o disco regional anexado ou se o disco regional estiver conectado e for gravável, a verificação de integridade da instância reportará um status íntegro. Se o aplicativo estiver em execução e for capaz de gravar o estado do aplicativo no disco regional, a verificação de integridade do aplicativo reportará um status íntegro.

Usar duas verificações de integridade binárias tem várias vantagens:

Você pode evitar que o sistema reaja a uma falha transitória diminuindo a frequência dos relatórios de verificação de integridade ou aumentando o limite dos sinais repetidos necessários para a transição de um nível para outro. Ambas as abordagens atrasam a reação do sistema a uma interrupção e aumentam o tempo de recuperação. Ao testar e medir esses parâmetros, você pode ajustar os parâmetros de verificação de integridade para equilibrar o tempo de recuperação do sistema.

Compreender o plano de controle regional específico da aplicação

A peça final da arquitetura é o plano de controle regional específico da aplicação, responsável pelas duas funções a seguir:

  • Gerenciar o ciclo de vida das instâncias de computação primárias e secundárias.
  • Decidir se um failover é necessário monitorando o status da verificação de integridade do aplicativo.

Se for necessário um failover, o plano de controle regional específico do aplicativo orquestra o failover com as seguintes etapas:

  1. Verifica se uma instância secundária está em execução e aguardando a conexão do disco regional.
  2. Força a anexação do disco regional à instância secundária.
  3. Monitora e reinicia a instância primária com falha. Quando a instância primária é reiniciada, o plano de controle inicia um failback conforme necessário.

O próprio plano de controle regional específico do aplicativo deve estar altamente disponível nas duas zonas onde o aplicativo está em execução. Em data centers locais, a alta disponibilidade (HA) geralmente é alcançada com a implantação de servidores adicionais para criar um quorum, decidir qual instância de computação é a instância primária e orquestrar o failover. Essa abordagem geralmente usa ferramentas de monitoramento de HA, como Heartbeat , Pacemaker ou Keepalived .

Embora você possa usar o plano de controle regional específico do aplicativo em qualquer lugar da nuvem, Google Cloud oferece os seguintes serviços gerenciados e disponíveis regionalmente que simplificam a implementação desta abordagem:

A Figura 3 ilustra o uso de funções do Cloud Run para o plano de controle regional específico do aplicativo, juntamente com um grupo de instâncias gerenciadas com estado e verificações de integridade gerenciadas.

Um plano de controle regional específico do aplicativo gerencia as VMs primárias e secundárias.

Figura 3. Plano de controle regional específico do aplicativo

A Figura 3 mostra duas instâncias de computação do aplicativo, primária e secundária. Cada instância é executada em uma zona separada e gerenciada por um MIG regional com estado. Um disco regional está disponível nas mesmas duas zonas. Dois serviços gerenciados de verificação de integridade estão em execução. Um serviço gerenciado de verificação de integridade monitora o status de integridade da instância e é usado pelo MIG com estado. O outro serviço de verificação de funcionamento monitora o status de funcionamento do aplicativo e é usado pelo pool de destino do balanceador de carga.

Um plano de controle regional específico do aplicativo interage com o status de integridade do aplicativo do pool de destino e com o MIG regional com estado para monitorar o status do aplicativo e iniciar a anexação do disco regional à atual instância de computação íntegra.

O que vem a seguir