Este documento explica os comportamentos e as interações entre uma aplicação com estado, um agente de verificação de estado e um plano de controlo regional específico da aplicação que é usado para monitorizar e orquestrar uma comutação por falha zonal através da implementação de discos replicados regionalmente de forma síncrona.
Este documento destina-se a programadores de aplicações como seguimento do artigo Crie serviços de HA com discos regionais, desenvolvendo o design e a arquitetura descritos na secção Crie serviços de base de dados de HA com discos regionais. Recomendamos que leia primeiro esse documento, especialmente as secções sobre considerações de design e comparação de custos, desempenho e resiliência.
Uma aplicação sem estado aumenta a resiliência tendo, pelo menos, uma instância secundária do Compute Engine em execução numa zona diferente. Quando a instância principal falha, a aplicação continua a ser executada na instância secundária. Uma aplicação com estado pode persistir no respetivo estado de aplicação num disco zonal ou num disco que só está disponível numa única zona, para recuperar o respetivo estado a partir de um reinício da instância. Para ser resiliente, uma aplicação com estado também tem de persistir o estado da aplicação numa instância secundária.
A Figura 1 ilustra uma aplicação com estado de dois nós típica que é replicada em duas zonas. A aplicação em cada zona tem um disco zonal para capturar o estado da aplicação e uma ligação de rede entre as instâncias para sincronizar as alterações de estado da aplicação entre os nós.
Figura 1. Aplicação com estado de dois nós sem discos regionais
Adicionar um disco regional
Outra forma de sincronizar o estado da aplicação de uma aplicação com estado é adicionar um disco regional. Quando uma aplicação escreve o respetivo estado da aplicação num disco regional, o Google CloudGoogle Cloud sincroniza automaticamente o armazenamento de blocos com outra zona.
A Figura 2 mostra a arquitetura de uma aplicação de base de dados com estado.
Figura 2. Aplicação de base de dados com estado
Como mostra a figura 2, continuam a existir duas instâncias de computação de aplicações: uma instância principal e uma instância secundária, implementadas em duas zonas. Além de usar um disco regional para o armazenamento do estado da aplicação, existe agora uma entidade adicional, o plano de controlo regional específico da aplicação. O plano de controlo regional específico da aplicação decide qual instância tem o disco regional anexado e qual instância é a instância principal atual. Esta arquitetura é uma configuração ativa-passiva porque apenas a instância principal pode confirmar um estado da aplicação no disco regional.
Instâncias de computação e a aplicação com estado
A Figura 2 ilustra uma aplicação de base de dados ativa-passiva a quente. As seguintes configurações também são possíveis:
- Se o seu objetivo de tempo de recuperação (RTO) puder suportar a latência adicional do início de uma instância secundária, pode poupar nos custos do Compute Engine executando apenas a instância ativa. Numa comutação por falha, 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 stream que registam o respetivo progresso no disco regional. Numa comutação por falha, a aplicação retoma o processamento a partir desse último ponto de verificação.
Gerir inicializações de instâncias do Compute Engine
Uma vez que apenas uma única instância de computação pode ter um disco regional anexado de cada vez, tem de iniciar as instâncias e anexar o disco regional de forma sistemática. Uma prática recomendada é separar a instância de computação e o início da aplicação da associação do disco regional. Os scripts de arranque da instância não devem iniciar a associação do disco regional. Em alternativa, os scripts de arranque devem iniciar o agente de verificação de funcionamento e aguardar que o disco regional seja anexado.
No arranque, a instância de computação tem de executar os seguintes passos sequenciais:
- Inicie o agente de verificação de funcionamento.
- Aguarde que o disco regional seja anexado.
- Depois de o disco regional estar anexado, monte o sistema de ficheiros.
- Depois de o sistema de ficheiros estar montado, inicie a aplicação.
Estes passos abrangem o arranque do sistema, mas também existe uma alternativa. Durante uma comutação por falha, 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 no sistema de ficheiros falham. Neste ponto, tem de encerrar ou reiniciar a instância de computação.
Executar o agente de verificação de funcionamento e as verificações de funcionamento
Conforme descrito na secção anterior, a instância de computação aguarda a anexação do disco regional antes de iniciar a aplicação. O plano de controlo regional específico da aplicação anexa o disco regional, mas apenas a uma instância de computação que está à espera que o disco seja anexado. Quando um disco está associado, o plano de controlo específico da aplicação monitoriza o estado de funcionamento da aplicação e inicia uma comutação por falha se a aplicação ficar em mau estado.
Cada instância de computação tem um dos seguintes estados:
- Para baixo
- A iniciar
- A aguardar um disco
- Aplicação em execução
O agente de verificação de estado comunica o estado atual da instância. Em vez de comunicar estes dois estados através de uma única verificação de estado, pode executar duas verificações de estado binárias. Se a instância de computação estiver pronta para ter o disco regional anexado ou se o disco regional estiver anexado e gravável, a verificação de estado da instância comunica um estado de funcionamento. Se a aplicação estiver em execução e conseguir escrever o estado da aplicação no disco regional, a verificação do estado de funcionamento da aplicação comunica um estado de funcionamento.
A utilização de duas verificações de funcionamento binárias tem várias vantagens:
- Pode usar o serviço de verificação de estado gerido do Compute Engine, que sonda o agente de verificação de estado e também resolve erros transitórios através de contagens de limites.
- Um grupo de instâncias geridas (GIG) pode monitorizar a verificação de funcionamento da instância e autorreparar uma instância de computação não saudável.
- O balanceador de carga pode monitorizar a verificação do estado da aplicação e encaminhar o tráfego para a instância da aplicação ativa.
Pode impedir que o sistema reaja a uma falha transitória diminuindo a frequência de relatórios da verificação de estado ou aumentando o limite dos sinais repetidos necessários para fazer a transição de um nível para outro. Ambas as abordagens atrasam a reação do sistema a uma indisponibilidade e aumentam o tempo de recuperação. Ao testar e medir estes parâmetros, pode ajustar os parâmetros de verificação do estado para equilibrar o tempo de recuperação do sistema.
Compreender o plano de controlo regional específico da aplicação
A peça final na arquitetura é o plano de controlo regional específico da aplicação, que é responsável pelas duas funções seguintes:
- Gerir o ciclo de vida das instâncias de computação principal e secundária.
- Decidir se é necessária uma comutação por falha, monitorizando o estado da verificação de funcionamento da aplicação.
Se for necessária uma comutação por falha, o plano de controlo regional específico da aplicação coordena a comutação por falha com os seguintes passos:
- Verifica se uma instância secundária está em execução e a aguardar a anexação do disco regional.
- Força a associação do disco regional à instância secundária.
- Monitoriza e reinicia a instância principal com falhas. Quando a instância principal é reiniciada, o plano de controlo inicia uma reversão, conforme necessário.
O plano de controlo regional específico da aplicação tem de estar altamente disponível nas duas zonas onde a aplicação está a ser executada. Nos centros de dados no local, a alta disponibilidade (HA) é frequentemente alcançada através da implementação de servidores adicionais para criar um quórum, decidir qual a instância de computação que é a instância principal e orquestrar a comutação por falha. Esta abordagem usa frequentemente ferramentas de monitorização de HA, como Heartbeat, Pacemaker ou Keepalived.
Embora possa usar o plano de controlo regional específico da aplicação em qualquer lugar na nuvem, Google Cloud oferece os seguintes serviços geridos e disponíveis regionalmente que simplificam a implementação desta abordagem:
- Google Cloud produtos sem servidor, como o App Engine, Cloud Run e funções do Cloud Run, que são fáceis de gerir e implementar.
- Verificações de funcionamento geridas que descarregam a monitorização das instâncias de computação que executam a aplicação.
- Grupos de instâncias geridas que gerem o ciclo de vida das instâncias de computação.
A Figura 3 ilustra a utilização de funções do Cloud Run para o plano de controlo regional específico da aplicação, juntamente com um grupo de instâncias gerido com estado e verificações de estado geridas.
Figura 3. Plano de controlo regional específico da aplicação
A Figura 3 mostra duas instâncias de computação da aplicação, principal e secundária. Cada instância é executada numa zona separada e é gerida por um MIG regional com estado. Um disco regional está disponível nas mesmas duas zonas. Estão a ser executados dois serviços de verificação de funcionamento geridos. Um serviço de verificação de estado de funcionamento gerido monitoriza o estado de funcionamento das instâncias e é usado pelo MIG com estado. O outro serviço de verificação do estado monitoriza o estado de funcionamento da aplicação e é usado pelo conjunto de destino do equilibrador de carga.
Um plano de controlo regional específico da aplicação interage com o estado de saúde da aplicação do conjunto de destino e com o MIG regional com estado para monitorizar o estado da aplicação e iniciar a associação do disco regional à instância de computação atual em bom estado.
O que se segue?
- Leia o artigo Aprovisionar discos regionais na documentação do Google Kubernetes Engine.
- Para saber como pode adaptar as ferramentas de HA no local para utilização no Google Cloud, consulte Padrões de utilização de endereços IP flutuantes.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.