Opções de alta disponibilidade usando DPs regionais

Neste documento, você aprende a usar discos permanentes regionais para criar serviços de alta disponibilidade (HA, na sigla em inglês). Você verá comparações entre as diferentes opções para aumentar a disponibilidade do serviço e entre o custo, desempenho e resiliência de arquiteturas de serviço distintas.

O disco permanente regional é uma opção de armazenamento que oferece replicação síncrona dos dados entre duas zonas em uma região. São uma ótima opção para usar durante a implementação de serviços de HA no Compute Engine.

A vantagem desses discos é que, caso haja uma interrupção de zona, em que a instância da máquina virtual (VM) ficar indisponível, será possível forçar a anexação de um disco permanente regional a uma instância de VM em uma zona secundária na mesma região. Para executar essa tarefa, é necessário iniciar outra instância de VM na mesma zona do disco permanente regional que está sendo anexado à força ou manter uma instância de VM em espera ativa nessa zona. A instância em espera ativa é uma instância de VM em execução que é igual à que você está usando. As duas instâncias têm os mesmos dados.

A operação de anexação forçada leva menos de um minuto para ser executada. O objetivo do tempo de recuperação (RTO, na sigla em inglês) total depende não apenas do failover de armazenamento (o anexo de força do disco permanente regional), mas também se a instância de VM secundária precisa ser criada primeiro, o período de tempo em que o sistema de arquivos subjacente detecta um disco anexado, o tempo de recuperação dos aplicativos correspondentes e outros fatores.

O disco permanente regional favorece a disponibilidade da carga de trabalho. Isso significa que há concessões para a proteção de dados no caso improvável de ambas as réplicas de disco ficarem indisponíveis ao mesmo tempo. Para mais informações, consulte Failover de disco permanente regional.

Como criar serviços de alta disponibilidade com discos permanentes regionais

Considerações sobre o design

Antes de começar a projetar um serviço de HA, você precisa entender as características do aplicativo, do sistema de arquivos e do sistema operacional. Elas são a base do design e servem para você determinar as abordagens apropriadas. Por exemplo, se um aplicativo não é compatível com a replicação no nível dele, algumas opções de design correspondentes não serão aplicáveis.

Da mesma forma, se o aplicativo ou o sistema operacional/de arquivos não for tolerante a falhas, o uso de discos permanentes regionais ou até mesmo de snapshots de discos permanentes zonais não será uma opção. A tolerância a falhas é definida como a capacidade de se recuperar após uma interrupção repentina sem perder ou corromper dados que já foram confirmados em um disco permanente antes da falha.

Considere o seguinte:

  1. Saiba qual será o impacto no desempenho da gravação e do aplicativo.
  2. Determine o objetivo de tempo de recuperação do serviço. Determine a velocidade em que seu serviço precisa se recuperar de uma interrupção de zona e entenda os requisitos do SLA.
  3. Determine o custo para criar uma arquitetura de serviço resiliente e confiável. Em termos de custo, as seguintes opções valem para as replicações síncrona e assíncrona de aplicativos:

    Usar duas instâncias do banco de dados e da VM. Nesse caso, o custo total é determinado pelos itens a seguir:

    • Custos da instância de VM
    • Custos do disco permanente
    • Custos de manutenção da replicação de aplicativos

    Para garantir uma alta disponibilidade com um disco permanente regional, use os mesmos componentes do disco permanente e da instância de VM. Além disso, inclua um disco permanente regional. O custo por byte dos discos permanentes regionais é o dobro se comparado ao dos discos permanentes zonais, já que são replicados em duas zonas

    No entanto, o uso de discos permanentes regionais reduz os custos de manutenção porque os dados são copiados automaticamente para duas réplicas, sem a necessidade de manter a replicação do aplicativo.

    Para reduzir ainda mais os custos do host, inicie a VM de backup sob demanda durante o failover, em vez de manter a VM em espera ativa.

Comparar custo, desempenho e resiliência

Veja na tabela a seguir comparações relacionadas ao custo, desempenho e resiliência de diferentes arquiteturas de serviço.

Arquitetura de serviço
de HA
Snapshots de discos
permanentes zonais
Replicação síncrona
no nível do aplicativo
Replicação assíncrona
no nível do aplicativo
Solução de HA
com um
disco permanente regional
Protege contra falhas no aplicativo, VM e zona1
Mitigação contra corrupção do aplicativo (por exemplo: intolerância a falhas)2
Custo $ $$

  • Duas instâncias do banco de dados ou da VM em execução, configuração e manutenção de replicação de aplicativos, rede entre zonas.
$$

  • Duas instâncias do banco de dados ou da VM em execução, configuração e manutenção de replicação de aplicativos, rede entre zonas.
$1,5x - $$

  • Os custos são iguais aos da replicação do aplicativo se você usar uma espera ativa. Para ter custos menores, ative uma VM de backup sob demanda durante o failover. Não há cobrança pela rede entre zonas entre réplicas de discos permanentes regionais.
Desempenho dos aplicativos

  • Nenhum efeito


  • Compensação no desempenho dos aplicativos com replicação síncrona
">

  • Nenhum efeito


  • Nenhum efeito na maioria dos aplicativos
Adequado para aplicativos com poucos requisitos de RPO (tolerância muito baixa para perda de dados)

  • Perda de dados dependendo de quando o snapshot foi criado


  • Sem perda de dados3


  • Perda de dados porque a replicação é assíncrona


  • Sem perda de dados
Tempo de recuperação de desastres do armazenamento4
  • 0 minuto
  • 0 segundo
  • 0 segundo
  • 0 segundo: para forçar a anexação do disco a uma instância de VM em espera

1 O uso de snapshots ou discos permanentes regionais não é suficiente para evitar e mitigar falhas e dados corrompidos. O aplicativo, o sistema de arquivos e, possivelmente, outros componentes de software precisam ser consistentes nas falhas ou usar algum tipo de encerramento.

2 Na replicação de alguns aplicativos, é feita a mitigação de determinadas corrupções neles. Por exemplo, a corrupção principal do aplicativo MySQL não faz com que as instâncias de réplica também sejam corrompidas. Consulte a documentação do seu aplicativo para mais detalhes.

3 A perda de dados significa o desaparecimento irrecuperável de dados confirmados no armazenamento permanente. Todos os dados não confirmados ainda serão perdidos.

4 O desempenho do failover não inclui a verificação do sistema de arquivos e a recuperação e o carregamento do aplicativo após o failover.

Como criar serviços de banco de dados de HA usando discos permanentes regionais

Nesta seção, você vê conceitos detalhados da criação de soluções de HA relacionadas a serviços de banco de dados com estado (MySQL, Postgres etc.) ao usar discos permanentes regionais e o Compute Engine. Ela inclui a mitigação de interrupções de uma zona. Um aplicativo ainda poderá ficar indisponível em caso de interrupções maiores, por exemplo, se uma região inteira ficar indisponível. Dependendo das suas necessidades, use técnicas de replicação entre regiões para garantir uma disponibilidade ainda maior.

Geralmente, as configurações de HA do banco de dados têm pelo menos duas instâncias de VM. De preferência, essas instâncias fazem parte de um ou mais grupos de instâncias gerenciadas:

  • Uma instância de VM principal na zona primária
  • Uma instância de VM em espera em uma zona secundária

Uma instância de VM principal tem dois discos permanentes, no mínimo: um de inicialização e um permanente regional. O disco permanente regional contém as informações do banco de dados e outros dados mutáveis que precisam ser preservados em uma zona diferente no caso de uma interrupção.

Uma instância de VM em espera requer um disco de inicialização separado para poder se recuperar de interrupções relacionadas à configuração. Por exemplo, como resultado de um upgrade do sistema operacional. Não é possível forçar a anexação de um disco de inicialização a outra VM durante um failover.

As instâncias de VM principal e em espera são configuradas para usar um balanceador de carga com o tráfego direcionado à VM primária, com base nos sinais da verificação de integridade. Essa configuração também é conhecida como espera ativa. Em "Cenário de recuperação de desastres para dados", há uma descrição de outras configurações de failover que podem ser mais apropriadas para seu caso.

Verificações de integridade

As verificações de integridade são implementadas pelo agente relacionado e têm duas finalidades:

  1. O agente de verificação de integridade está localizado nas VMs primária e secundária. Ele monitora as instâncias e se comunica com o balanceador de carga para direcionar o tráfego. Isso é muito útil com os grupos de instâncias.
  2. O agente de verificação de integridade é sincronizado com o plano de controle regional específico do aplicativo. Ele toma decisões de failover com base no comportamento desse plano de controle, que precisa estar em uma zona diferente da instância que está tendo a integridade verificada.

O próprio agente de verificação de integridade precisa ser tolerante a falhas. Por exemplo, veja na imagem a seguir que o plano de controle está separado da instância primária. Essa instância está na zona us-central1-a, enquanto a VM em espera está na zona us-central1-f.

Papel do agente de verificação de integridade
                                               na VM.

O papel do agente de verificação de integridade nas instâncias de VM primária e em espera.

Failover

Quando uma falha é detectada em um banco de dados ou VM primária, o plano de controle do aplicativo inicia o failover para a VM em espera na zona secundária. Durante esse processo, o plano de controle do aplicativo anexa à força o disco permanente regional que foi replicado de forma síncrona para a zona secundária à VM em espera. Além disso, todo o tráfego é direcionado para essa VM com base nos sinais da verificação de integridade.

A latência geral do failover, excluindo o tempo de detecção de falhas, é a soma das latências a seguir:

  • Zero segundo para forçar a anexação de um disco permanente regional a uma VM em espera
  • Tempo necessário para a inicialização do aplicativo e a recuperação de falhas

Veja os elementos da recuperação de desastres disponíveis no Compute Engine nesta página.

Desafios da replicação do banco de dados

Veja na tabela a seguir alguns desafios comuns de configuração e gerenciamento da replicação síncrona ou semissíncrona de aplicativos (como MySQL). Isso inclui uma comparação com a replicação em blocos que usam discos permanentes regionais.

Desafios Replicação síncrona
ou semissíncrona do aplicativo
Replicação em blocos com
discos permanentes regionais
Manter a estabilidade entre a réplica primária e de failover. Muitas coisas podem dar errado e fazer uma instância sair do modo de HA:
  1. Configuração incorreta dos parâmetros de replicação, como incompatibilidade do certificado SSL ou falta de ACL no lado principal.
  2. Carga pesada na instância principal que a réplica de failover não consegue acompanhar.
  3. Bugs que causam problemas de replicação, como erros no aplicativo, configuração incorreta do SO ou falha no Docker.
  4. Falhas na infraestrutura, como contenção da CPU, VM congelada ou interrupção de rede intermediária.
As falhas no armazenamento são processadas pelos discos permanentes regionais. Isso acontece com transparência no aplicativo, exceto se ocorrer uma possível flutuação no desempenho do disco.

É necessário ter verificações de integridade definidas pelo usuário para revelar problemas no aplicativo ou na VM e acionar o failover.
O tempo total do failover é maior do que o pretendido. O tempo necessário para a operação de failover não tem um limite superior. Aguardar a repetição de todas as transações (etapa 2 acima) pode demorar bastante dependendo do esquema e da carga no banco de dados. Os discos permanentes regionais fornecem replicação síncrona. Portanto, o tempo de failover é delimitado pela soma destas latências:
  1. Criação de uma VM secundária, a menos que você já tenha uma instância de VM de espera ativa disponível.
  2. Anexação à força de um disco permanente regional.
  3. Inicialização do aplicativo
Dupla personalidade Para evitar dupla personalidade (em inglês), as duas abordagens requerem ações para garantir que haja apenas um primário por vez.

A seguir