Neste documento, explicamos 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 usado para monitorar e orquestrar um failover zonal implantando discos permanentes regionais.
Este documento é destinado aos desenvolvedores de aplicativos como acompanhamento para Opções de alta disponibilidade que usam discos permanentes regionais, ampliando o design e a arquitetura descritos na seção Como criar serviços de banco de dados de alta disponibilidade usando discos permanentes 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 de máquina virtual (VM, na sigla em inglês) secundária em execução em uma zona diferente do Compute Engine. Quando a instância da VM principal falha, o aplicativo continua em execução na instância de secundária. Um aplicativo com estado pode manter seu estado de aplicativo para um disco permanente zonal a fim de recuperar o estado de uma reinicialização da instância de VM. Para ser resiliente, um aplicativo com estado também precisa manter o estado do aplicativo para uma instância de VM secundária.
No diagrama a seguir, ilustramos um aplicativo típico com estado de dois nós que é replicado em duas zonas. O aplicativo em cada regional tem um disco permanente regional para capturar o estado do aplicativo e uma conexão de rede entre as instâncias de VM para sincronizar as alterações de estado do aplicativo entre os nós.
Como adicionar um disco permanente regional
Outra maneira de sincronizar o estado de um aplicativo com estado é adicionar um disco permanente regional. Quando um aplicativo grava o estado dele em um disco permanente regional, o Google Cloud sincroniza automaticamente o armazenamento em blocos com outra zona. O armazenamento em disco permanente regional também ajuda a garantir que apenas uma instância de VM entre as duas zonas seja anexada ao disco permanente regional por vez.
No diagrama a seguir, mostramos a arquitetura de um aplicativo de banco de dados com estado.
Como mostrado no diagrama anterior, ainda há duas instâncias de VM do aplicativo, uma secundária e uma secundária, implantadas em duas zonas. Além do uso de um disco permanente regional para armazenamento de estado de aplicativos, 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 de VM tem o disco permanente regional anexado e qual instância de VM é a instância de VM principal atual. Essa arquitetura é uma configuração ativa-passiva, porque somente a instância de VM primária pode confirmar um estado do aplicativo para o disco permanente regional.
Instâncias de VM e o aplicativo com estado
O diagrama de arquitetura anterior ilustra um aplicativo de banco de dados ativo e passivo. 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 de VM secundária, você poderá economizar nos custos do Compute Engine executando apenas a instância de VM ativa. Em um failover, o plano de controle regional específico do aplicativo inicia a instância de VM secundária e anexa o disco permanente regional.
- Cargas de trabalho de processamento em lote ou stream que direcionam o progresso para o disco permanente regional. Em um failover, o aplicativo retoma o processamento a partir do último ponto de verificação.
Como gerenciar as inicializações de instâncias de VM
Como apenas uma instância de VM pode ter um disco permanente regional anexado por vez, é preciso iniciar as instâncias da VM e anexar o disco permanente regional sistematicamente. Uma prática recomendada é separar a instância da VM e a inicialização do aplicativo do anexo do disco permanente regional. Os scripts de inicialização da instância de VM não podem iniciar o anexo de disco permanente 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 permanente regional.
Na inicialização, a instância de VM precisa executar as seguintes etapas sequenciais:
- Iniciar o agente de verificação de integridade.
- Aguardar o disco permanente regional ser anexado.
- Depois que o disco permanente regional for anexado, montar 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 permanente regional é anexado à instância de VM secundária. O disco permanente regional também é removido à força da instância principal da VM, e as operações de E/S para o sistema de arquivos falham. Neste ponto, é preciso encerrar ou reiniciar a instância de VM.
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 VM aguarda a anexação do disco permanente regional antes de iniciar o aplicativo. O plano de controle regional específico do aplicativo anexa o disco permanente regional, mas somente a uma instância de VM 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 VM tem um dos seguintes estados:
- Vertical
- Inicial
- Aguardando um disco
- Aplicativo em execução
O agente de verificação de integridade informa o estado atual da instância de VM. 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 VM estiver pronta para ter o disco permanente regional anexado ou se o disco permanente regional estiver conectado e gravável, a verificação de integridade da instância da VM relatará um status íntegro. Se o aplicativo estiver em execução e for capaz de gravar o estado do aplicativo no disco permanente regional, a verificação de integridade do aplicativo relatará 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, na sigla em inglês) pode monitorar a verificação de integridade da instância e recuperar automaticamente uma instância de VM 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 VM 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 de VM secundária está em execução e está aguardando o disco permanente regional ser anexado.
- Força o anexo do disco permanente regional à instância de VM secundária.
- Monitora e reinicia a instância da VM principal com falha. Quando a instância da VM é 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 VM é a instância de VM principal e orquestrar o failover. Essa abordagem geralmente usa ferramentas de monitoramento de alta disponibilidade, como Heartbeat, Pacemaker ou Keepalived (links em inglês).
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 Cloud Functions, que são fáceis de gerenciar e implantar.
- Verificações de integridade gerenciadas que descarregam o monitoramento das instâncias do aplicativo.
- Grupos de instâncias gerenciadas que gerenciam o ciclo de vida das instâncias do servidor.
O diagrama a seguir ilustra o uso do Cloud Functions 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.
O diagrama anterior mostra duas instâncias de VM do aplicativo, primária e secundária. Cada instância de VM é executada em uma zona separada e é gerenciada por um MIG regional com estado. Um disco permanente 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 de VM 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 começar a anexar o disco permanente regional à instância de VM íntegra atual.
A seguir
- Leia Como provisionar discos permanentes regionais no 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.