Opções de alta disponibilidade ao usar discos permanentes 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. Além disso, o documento inclui descrições sobre os tipos de falha e ações de recuperação para você determinar se os discos permanentes regionais são a solução mais apropriada para seu serviço de HA.

O disco permanente regional é uma opção de armazenamento que fornece a replicação síncrona dos dados entre duas zonas em uma região. Ele é perfeito para ser usado ao implementar serviços de HA no Compute Engine.

Os discos permanentes regionais garantem a vantagem de forçar a anexação deles a uma instância de VM em uma zona secundária na mesma região quando ocorre uma falha zonal, o que pode causar a indisponibilidade da instância de VM. Para executar essa tarefa, você precisa 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 de hot standby nessa zona. "Hot standby" indica uma instância de VM em execução que é igual àquela que você está usando. As duas instâncias têm os mesmos dados.

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

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, o sistema de arquivos ou o sistema operacional não forem tolerantes a falhas, o uso de discos permanentes regionais ou até mesmo de snapshots de discos permanentes zonais não será apropriado. A tolerância a falhas é definida como a capacidade de se recuperar de uma interrupção repentina sem perder ou corromper dados que já foram confirmados em um disco permanente.

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 falha zonal e entenda os requisitos de SLA.
  3. Determine o custo para criar uma arquitetura de serviço resiliente e confiável. Nesse quesito, a opção disponível de replicação síncrona e assíncrona de aplicativos é esta:

    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 alta disponibilidade com um disco permanente regional, use os mesmos componentes do disco permanente e da instância de VM, mas também inclua um disco permanente regional. O custo por byte dos discos permanentes regionais é o dobro em comparação com os discos permanentes zonais, já que eles 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 como hot standby.

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
ao usar 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/VM em execução + custo de manutenção e configuração da replicação de aplicativos + rede entre zonas
$$
Duas instâncias do banco de dados/VM em execução + custo de manutenção e configuração da replicação de aplicativos + rede entre zonas
$ e meio – $$
Os custos serão os mesmos da replicação de aplicativos se você usar um hot standby. Para ter custos menores, ative uma VM de back-up sob demanda durante o failover.
Desempenho do aplicativo
Sem impacto

Compensação no desempenho do aplicativo com replicação síncrona

Sem impacto

Sem impacto na maioria dos aplicativos
Adequada para aplicativos com poucos requisitos de RPO (sem tolerância à perda de dados)
Perda de dados dependendo de quando o snapshot foi criado

Sem perda de dados3

Há perda de dados porque a replicação é assíncrona

Sem perda de dados
Tempo de recuperação de desastres do armazenamento4 O (minutos) O (segundos) O (segundos) O (segundos): para forçar a anexação do disco à 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 ("quiesce") [em inglês].

2 Na replicação de alguns aplicativos, é feita a mitigação de determinadas corrupções neles. Por exemplo, se o aplicativo mestre MySQL estiver corrompido, as instâncias de réplica dele não estarão. 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. Os dados não confirmados também são perdidos.

4 O desempenho do failover não inclui a verificação do sistema de arquivos, além do carregamento e da recuperação 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.

Esta página inclui informações sobre a mitigação de interrupções de uma zona. O aplicativo ainda pode ficar indisponível no 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 pelo menos dois discos permanentes: um de inicialização e outro permanente regional. O disco permanente regional contém os dados do banco de dados e outros dados mutáveis que precisam ser preservados em uma zona diferente no caso de 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 "hot standby". No Cenário de recuperação de desastres de dados, você vê a 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á em 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 primária e de VM 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. Ao fornecer replicação no nível do disco, o disco permanente regional fornece outro elemento importante para arquitetar soluções de HA.

Modos de falha

Veja na tabela a seguir os diferentes modos de falha e as ações recomendadas para os serviços que usam discos permanentes regionais.

Categoria da falha e probabilidade Tipos de falha Ação
Falha na zona (média) Falhas que ocorrem apenas no disco na zona local. Elas podem ser temporárias ou ter longa duração.



Plano de controle do Compute Engine
Falha de energia
Falha de rede

As falhas temporárias nas operações de discos regionais são processadas com transparência por um disco permanente regional, sem a necessidade de fazer o failover. O disco permanente regional detecta erros e lentidão automaticamente, além de alternar entre os modos de replicação e atualizar os dados replicados apenas para uma zona.

No caso de problemas de armazenamento em uma zona primária, o disco permanente regional executa automaticamente leituras em uma zona secundária. Isso pode aumentar a latência das operações de leitura. Nessas circunstâncias, o aplicativo pode acionar o failover com base no impacto no desempenho.



O plano de controle do aplicativo pode acionar o failover com base nos limites da verificação de integridade.
Falha no aplicativo (alta) O aplicativo não responde
Ações do administrador do aplicativo (por exemplo, upgrade)Erro humano
(por exemplo, configuração incorreta de parâmetros como certificado SSL, ACLs etc.)
O plano de controle do aplicativo pode acionar o failover com base nos limites da verificação de integridade.
Falha na VM (média) Falha na infraestrutura/hardware
A VM não responde devido à contenção de CPU ou interrupção de rede intermediária
As VMs geralmente se recuperam automaticamente. O plano de controle do aplicativo pode acionar o failover com base nos limites da verificação de integridade.
Aplicativo corrompido (baixa a média) Dados do aplicativo corrompidos
(por exemplo, devido a bugs ou a um upgrade de sistema operacional incorreto)
Recuperação do aplicativo:

Desafios da replicação do banco de dados

Veja na tabela a seguir alguns desafios comuns da 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 mestre 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 do mestre.
  2. Carga pesada na instância mestre 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 do failover completo é maior do que o pretendido. O tempo gasto na operação de failover não tem um limite máximo. Aguardar a repetição de todas as transações (etapa 2 acima) pode demorar 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 hot standby disponível.
  2. Anexação à força de um disco permanente regional.
  3. Inicialização do aplicativo.
Dupla personalidade Ambas as abordagens exigem provisões para garantir que haja apenas um mestre de cada vez, evitando a dupla personalidade (em inglês).

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine