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 usado para monitorar e orquestrar um failover zonal implantando discos regionais replicados de forma síncrona.
Este documento é destinado aos desenvolvedores de aplicativos como acompanhamento para Criar serviços de HA usando discos regionais, ampliando o design e a arquitetura descritos na seção Como criar serviços de banco de dados de HA usando discos regionais. É recomendável ler 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 com pelo menos uma instância secundária do Compute Engine em execução em uma zona diferente. Quando a instância principal falha, o aplicativo continua em execução na instância secundária. Um aplicativo com estado pode manter o estado do aplicativo em um disco zonal, ou um disco disponível em apenas uma zona, para recuperar o estado de uma reinicialização de instância. Para ser resiliente, um aplicativo com estado também precisa manter 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 tem um disco regional 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.
Figura 1. Aplicativo com estado de dois nós sem discos regionais
Como adicionar um disco regional
Outra maneira de sincronizar o estado de um aplicativo com estado é adicionar um disco regional. Quando um aplicativo grava o estado dele em um disco regional, o Google Cloud sincroniza automaticamente o armazenamento em blocos com outra zona.
A Figura 2 mostra a arquitetura de um aplicativo de banco de dados com estado.
Figura 2. Aplicativo de banco de dados com estado
Como mostra a Figura 2, ainda há duas instâncias de computação do aplicativo, uma principal e outra secundária, implantadas em duas zonas. Além de usar um disco regional para armazenamento de estado de aplicativos, agora há 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 é a instância principal atual. Essa arquitetura é uma configuração ativa-passiva, porque somente a instância principal pode confirmar um estado do aplicativo no disco regional.
Instâncias de computação e o aplicativo com estado
A Figura 2 ilustra um aplicativo de banco de dados ativo-passivo em funcionamento. As seguintes configurações também são possíveis:
- Se o objetivo de tempo de recuperação (RTO, na sigla em inglês) puder arcar com 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. Em um failover, o plano de controle regional específico do aplicativo inicia a instância secundária e anexa o disco regional a essa instância.
- Cargas de trabalho de processamento em lote ou stream que direcionam o progresso para o disco regional. Em um failover, o aplicativo retoma o processamento a partir do último ponto de verificação.
Como gerenciar inicializações de instâncias do Compute Engine
Como apenas uma instância de computação pode ter um disco regional anexado por vez, é necessário iniciar 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 podem iniciar o anexo de disco regional. Em vez disso, os scripts de inicialização devem iniciar o agente de verificação de integridade e aguardar a anexação do disco regional.
Na inicialização, a instância de computação precisa executar as seguintes etapas sequenciais:
- Iniciar o agente de verificação de integridade.
- Aguarde o disco regional ser anexado.
- Depois que o disco regional for anexado, monte o sistema de arquivos.
- Depois que o sistema de arquivos for ativado, iniciar o aplicativo.
Essas etapas abrangem a inicialização do sistema, mas também há um failover. Durante um failover, o disco regional é anexado à força à instância secundária. O disco regional também é removido à força da instância principal, e as operações de E/S para o sistema de arquivos falham. Neste ponto, é preciso encerrar ou reiniciar a instância de computação.
Como executar o agente de verificação de integridade e as verificações de integridade
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 somente a uma instância de computação que esteja 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 se tornar não íntegro.
Cada instância de computação tem um dos seguintes estados:
- Para baixo
- Iniciando
- Aguardando 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, é possível executar duas verificações binárias de integridade. Se a instância de computação estiver pronta para ter o disco regional anexado ou se o disco regional estiver conectado e gravável, a verificação de integridade da instância vai informar um status de integridade. 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 vai informar um status de integridade.
O uso de duas verificações de integridade binária tem várias vantagens:
- Use o serviço de verificação de integridade gerenciada do Compute Engine, que pesquisa o agente de verificação de integridade e também resolve erros temporários por meio de contagens de limites.
- Um grupo de instâncias gerenciadas (MIG) pode monitorar a verificação de integridade da instância e recuperar automaticamente uma instância de computação não íntegra.
- O balanceador de carga pode monitorar a verificação de integridade do aplicativo e rotear o tráfego para a instância do aplicativo ativo.
Para evitar que o sistema reaja a uma falha temporária, diminua a frequência de geração de relatórios de verificação de integridade ou aumente 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 avaliar esses parâmetros, é possível ajustar os parâmetros da verificação de integridade para equilibrar o tempo de recuperação do sistema.
Noções básicas sobre o plano de controle regional específico do aplicativo
A última parte da arquitetura é o plano de controle regional específico do aplicativo, que é responsável pelas duas funções a seguir:
- Gerenciar o ciclo de vida das instâncias de computação primária e secundária.
- 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 o orquestra com as seguintes etapas:
- Verifica se uma instância secundária está em execução e está aguardando o disco regional ser anexado.
- Força o anexo do disco regional à instância secundária.
- Monitora e reinicia a instância principal com falha. Quando a instância principal é reiniciada, o plano de controle inicia um failback conforme necessário.
O próprio plano de controle regional específico do aplicativo precisa estar altamente disponível nas duas zonas em que o aplicativo está em execução. Nos data centers locais, a alta disponibilidade (HA, na sigla em inglês) costuma ser alcançada com a implantação de mais servidores para criar um quórum, decidir qual instância de computação é a principal e orquestrar o failover. Essa abordagem geralmente usa ferramentas de monitoramento de alta disponibilidade, como Heartbeat, Pacemaker ou Keepalived.
Embora você possa usar o plano de controle regional específico do aplicativo em qualquer lugar na nuvem, o Google Cloud oferece os seguintes serviços gerenciados e regionais disponíveis que simplificam a implementação dessa abordagem:
- Produtos do Google Cloud sem servidor, como App Engine, Cloud Run e Funções do Cloud Run, que são fáceis de gerenciar e implantar.
- Verificações de integridade gerenciadas que descarregam o monitoramento das instâncias de computação que executam o aplicativo.
- Grupos de instâncias gerenciadas que gerenciam o ciclo de vida das instâncias de computação.
A Figura 3 ilustra o uso das funções do Cloud Run para o plano de controle regional específico do aplicativo, com um grupo de instâncias gerenciadas com estado e verificações de integridade gerenciadas.
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 de verificação de integridade gerenciados estão em execução. Um serviço de verificação de integridade gerenciada monitora o status de integridade da instância e é usado pelo MIG com estado. O outro serviço monitora o status de integridade 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 à instância de computação íntegra atual.
A seguir
- Leia Como provisionar discos regionais na documentação do Google Kubernetes Engine.
- Para saber como adaptar ferramentas de HA locais para uso no Google Cloud, consulte Padrões para usar endereços IP flutuantes.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.