O disco permanente regional e a alta disponibilidade balanceada de hiperdisco são opções de armazenamento que permitem implementar serviços de alta disponibilidade (HA) no Compute Engine. O disco permanente regional e a alta disponibilidade balanceada de hiperdisco replicam dados de forma síncrona entre duas zonas na mesma região e garantem alta disponibilidade para dados de disco em até uma falha zonal.
Construindo serviços de alta disponibilidade com discos regionais
Esta seção explica como você pode criar serviços de alta disponibilidade comDisco permanente regional ouDiscos de alta disponibilidade balanceados de hiperdisco.
Considerações de projeto
Antes de começar a projetar um serviço de alta disponibilidade, entenda as características do aplicativo, do sistema de arquivos e do sistema operacional. Essas características são a base do projeto e podem descartar diversas abordagens. Por exemplo, se um aplicativo não suportar replicação em nível de aplicativo, 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, então usarDisco permanente regional ouDiscos de alta disponibilidade balanceada de hiperdisco, ou mesmo instantâneos de disco zonais, podem não ser uma opção. A tolerância a falhas é definida como a capacidade de recuperação de um encerramento abrupto sem perder ou corromper dados que já estavam comprometidos em um disco antes da falha.
Considere o seguinte ao projetar para alta disponibilidade:
- O efeito na aplicação do uso de Hyperdisk Balanced High Availability, disco permanente regional, ou outras soluções.
- Desempenho de gravação em disco.
- O objetivo do tempo de recuperação do serviço – a rapidez com que o seu serviço deve recuperar de uma interrupção zonal e os requisitos do SLA.
- O custo para construir uma arquitetura de serviço resiliente e confiável.
- Para obter mais informações sobre considerações específicas da região, consulte Geografia e regiões .
Em termos de custo, use as seguintes opções para replicação de aplicativos síncrona e assíncrona:
Use duas instâncias do banco de dados e da VM. Neste caso, os seguintes itens determinam o custo total:
- Custos da instância de VM
- Disco permanente ouCustos do hiperdisco
- Custos de manutenção da replicação de aplicativos
Use uma única VM com discos replicados de forma síncrona. Para obter alta disponibilidade com umDisco permanente regional ou Disco de alta disponibilidade balanceada de hiperdisco, usa a mesma instância de VM e componentes de disco da opção anterior, mas também inclui um disco replicado de forma síncrona. Discos Permanentes Regionais e Os discos Hyperdisk Balanced High Availability têm o dobro do custo por byte em comparação com os discos zonais porque são replicados em duas zonas.
No entanto, o uso de discos replicados de forma síncrona pode reduzir o custo de manutenção porque os dados são gravados automaticamente em duas réplicas sem a necessidade de manter a replicação do aplicativo.
Não inicie a VM secundária até que o failover seja necessário. Você pode reduzir ainda mais os custos do host iniciando a VM secundária somente sob demanda durante o failover, em vez de manter a VM como uma VM em espera ativa.
Compare custo, desempenho e resiliência
A tabela a seguir destaca as compensações em custo, desempenho e resiliência para as diferentes arquiteturas de serviço.
| Serviço de alta disponibilidade arquitetura | Disco zonal instantâneos | Nível de aplicação síncrono | Nível de aplicação assíncrono | Discos regionais |
|---|---|---|---|---|
| Protege contra falhas de aplicativos, VMs e zonas * | ||||
| Mitigação contra corrupção de aplicativos (exemplo: intolerância a falhas de aplicativos) | † | † | ||
| Custo | $ | $$
|
$$
| US$ 1,5x - $$
|
| Desempenho do aplicativo |
|
|
|
|
| Adequado para aplicações com baixa exigência de RPO (tolerância muito baixa para perda de dados) |
|
|
|
|
| Tempo de recuperação de armazenamento após desastre # |
|
|
|
|
* Usar discos regionais ou instantâneos não é suficiente para proteger e mitigar falhas e corrupções. Seu aplicativo, sistema de arquivos e possivelmente outros componentes de software devem ser consistentes com falhas ou usar algum tipo de quiescing .
† A replicação de alguns aplicativos fornece mitigação contra algumas corrupções de aplicativos. Por exemplo, a corrupção do aplicativo primário do MySQL não faz com que suas réplicas de instâncias de VM também sejam corrompidas. Revise a documentação do seu aplicativo para obter detalhes.
‡ Perda de dados significa perda irrecuperável de dados comprometidos com armazenamento persistente. Quaisquer dados não confirmados ainda serão perdidos.
# O desempenho do failover não inclui verificação do sistema de arquivos e recuperação e carregamento de aplicativos após o failover.
Construindo serviços de banco de dados HA usando discos regionais
Esta seção aborda conceitos de alto nível para a criação de soluções de alta disponibilidade para serviços de banco de dados com estado (MySQL, Postgres etc.) usando o Compute Engine comDiscos Permanentes Regionais e Discos de alta disponibilidade balanceados de hiperdisco.
Se houver interrupções amplas em Google Cloud, por exemplo, se uma região inteira ficar indisponível, seu aplicativo poderá ficar indisponível. Dependendo das suas necessidades, considere técnicas de replicação entre regiõesou replicação assíncrona para uma disponibilidade ainda maior.
As configurações de alta disponibilidade do banco de dados normalmente têm pelo menos duas instâncias de VM. De preferência, essas instâncias de VM fazem parte de um ou mais grupos de instâncias gerenciadas:
- Uma instância de VM primária na zona primária
- Uma instância de VM em espera em uma zona secundária
Uma instância de VM primária tem pelo menos dois discos: um disco de inicialização e um disco regional. O disco regional contém dados do banco de dados e quaisquer outros dados mutáveis que devem ser preservados em outra zona em 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, que podem resultar de uma atualização do sistema operacional, por exemplo. Além disso, você não pode forçar a anexação de um disco de inicialização a outra VM durante um failover.
As instâncias de VM primária e de espera são configuradas para usar um balanceador de carga com o tráfego direcionado para a VM primária com base em sinais de verificação de integridade. O cenário de recuperação de desastres para dados descreve outras configurações de failover, que podem ser mais apropriadas para o seu cenário.
Desafios com replicação de banco de dados
A tabela a seguir lista alguns desafios comuns na configuração e no gerenciamento da replicação síncrona ou semissíncrona de aplicativos (como MySQL) e como eles se comparam à replicação síncrona de disco comDisco Permanente Regional e Discos de alta disponibilidade balanceados de hiperdisco.
| Desafios | Aplicativo síncrono ou replicação semissíncrona | Replicação de disco síncrono |
|---|---|---|
| Manter a replicação estável entre a réplica primária e a réplica de failover. | Há uma série de coisas que podem dar errado e fazer com que uma instância de VM saia do modo HA:
| Falhas de armazenamento são tratadas por Disco Permanente Regional e Discos de alta disponibilidade balanceados de hiperdisco. Isto acontece de forma transparente para a aplicação, exceto por uma possível flutuação no desempenho do disco. Deve haver verificações de integridade definidas pelo usuário para revelar quaisquer problemas de aplicativo ou VM e acionar o failover. |
| O tempo de failover de ponta a ponta é maior que o esperado. | O tempo necessário para a operação de failover não tem um limite superior. Esperar que todas as transações sejam reproduzidas (etapa 2 acima) pode levar um tempo arbitrariamente longo, dependendo do esquema e da carga no banco de dados. | Disco Permanente Regional e Os discos de alta disponibilidade balanceada de hiperdisco fornecem replicação síncrona, portanto, o tempo de failover é limitado pela soma das seguintes latências:
|
| Cérebro dividido | Para evitar a divisão do cérebro , ambas as abordagens exigem disposições que garantam que haja apenas um primário de cada vez. | |
Sequência de operações de leitura e gravação em discos
Ao determinar as sequências de leitura e gravação, ou a ordem em que os dados são lidos e gravados no disco, a maior parte do trabalho é realizada pelo driver de disco na sua VM. Como usuário, você não precisa lidar com a semântica de replicação e pode interagir com o sistema de arquivos normalmente. O driver subjacente lida com a sequência de leitura e gravação.
Por padrão, uma VM do Compute Engine comDisco permanente regional ouO Hyperdisk Balanced High Availability opera no modo de replicação completa, onde as solicitações de leitura ou gravação do disco são enviadas para ambas as réplicas.
No modo de replicação completa, ocorre o seguinte:
- Ao escrever, uma solicitação de gravação tenta gravar em ambas as réplicas e reconhece quando ambas as gravações são bem-sucedidas.
- Durante a leitura, a VM envia uma solicitação de leitura para ambas as réplicas e retorna os resultados daquela que for bem-sucedida. Se a solicitação de leitura expirar, outra solicitação de leitura será enviada.
Se uma réplica ficar para trás ou não reconhecer que as solicitações de leitura ou gravação foram concluídas, o estado da réplica será atualizado.
Verificações de saúde
As verificações de funcionamento usadas pelo balanceador de carga são implementadas pelo agente de verificação de funcionamento. O agente de verificação de saúde tem dois propósitos:
- O agente de verificação de integridade reside nas VMs primárias e secundárias para monitorar as instâncias de VM e se comunicar com o balanceador de carga para direcionar o tráfego. Isso funciona melhor quando configurado com grupos de instâncias .
- O agente de verificação de integridade sincroniza com o plano de controle regional específico do aplicativo e toma decisões de failover com base no comportamento do plano de controle. O plano de controle deve estar em uma zona diferente da instância de VM cuja integridade está sendo monitorada.
O próprio agente de verificação de integridade deve ser tolerante a falhas. Por exemplo, observe que, na imagem a seguir, o plano de controle está separado da instância de VM primária, que reside na zona us-central1-a , enquanto a VM em espera reside na zona us-central1-f .
O que vem a seguir
- Aprenda como criar e gerenciar discos regionais .
- Saiba mais sobre replicação assíncrona .
- Saiba como configurar uma instância de cluster de failover do SQL Server para discos no modo multigravador .
- Aprenda como construir aplicativos web escaláveis e resilientes em Google Cloud .
- Revise o guia de planejamento de recuperação de desastres .