O Persistent Disk regional é uma opção de armazenamento que permite implementar serviços de alta disponibilidade (HA) no Compute Engine. O Persistent Disk regional replica de maneira síncrona dados entre duas zonas na mesma região e garante alta disponibilidade para dados de disco no caso de até uma falha zonal.
Neste documento, explicamos como usar o Persistent Disk regional para criar serviços de alta disponibilidade.
Como criar serviços de alta disponibilidade com o Persistent Disk regional
Nesta seção, explicamos como criar serviços de alta disponibilidade com o Persistent Disk regional.
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 ao projetar para alta disponibilidade:
- O efeito do uso de discos permanentes regionais ou outras soluções no aplicativo e no desempenho de gravação do disco.
- O objetivo do 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.
- O custo para criar uma arquitetura de serviço resiliente e confiável.
Em termos de custo, as seguintes opções são para replicação de aplicativos síncrona e assíncrona:
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
Usar uma única VM com discos permanentes regionais. 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.
Não inicie a segunda VM até que o failover seja necessário. 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 |
|---|---|---|---|---|
| Proteção contra falhas de aplicativos, VMs e zonas1 | ||||
| Mitigação contra corrupção dos aplicativos (por exemplo: intolerância a falhas) | 2 | 2 | ||
| Custo | $ |
$$
|
$$
|
$1,5x - $$
|
| Desempenho dos aplicativos |
|
|
|
|
| Adequado para aplicativos com poucos requisitos de RPO (tolerância muito baixa para perda de dados) |
|
|
|
|
| Tempo de recuperação de desastres do armazenamento4 |
|
|
|
|
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 da VM de réplica também sejam corrompidas. Consulte a documentação do seu aplicativo para mais detalhes.
3 A perda de dados é a perda irreversí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.
Se houver grandes interrupções no Google Cloud, por exemplo, se uma região inteira ficar indisponível, o aplicativo poderá ficar indisponível. Dependendo das suas necessidades, considere usar técnicas de replicação entre regiões para ter 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 de VM fazem parte de um ou mais grupos gerenciados de instâncias:
- 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.
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 de VM
sair do modo de HA:
|
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:
|
| 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. | |
Verificações de integridade
As verificações de integridade usadas pelo balanceador de carga são implementadas pelo agente. O agente de verificação de integridade tem estas duas finalidades:
- O agente de verificação de integridade está localizado nas VMs primária e secundária. Ele monitora as instâncias de VM e se comunica 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 é 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 de VM 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 de VM primária. Essa instância está na zona us-central1-a, enquanto a VM em espera está na zona us-central1-f.
A seguir
- Saiba como criar e gerenciar volumes do Persistent Disk regional.
- Saiba como criar aplicativos da Web escalonáveis e resilientes no Google Cloud.
- Consulte o guia de planejamento de recuperação de desastres.