O Hyperdisk Balanced High Availability é uma opção de armazenamento que permite implementar serviços de alta disponibilidade no Compute Engine. o Hyperdisk Balanced High Availability replica os dados de forma síncrona entre duas zonas na mesma região e garante alta disponibilidade para dados de disco de até uma falha zonal.
Os volumes do Hyperdisk Balanced High Availability foram projetados para cargas de trabalho que demandam um objetivo do ponto de recuperação (RPO) e objetivo do tempo de recuperação (RTO) menores. Para saber mais sobre RPO e RTO, consulte Noções básicas do planejamento de recuperação de desastres. Hyperdisk Balanced High Availability foram projetados para funcionar com grupos gerenciados de instâncias.
Este documento fornece uma visão geral de como criar serviços de alta disponibilidade com volumes do Hyperdisk Balanced High Availability.
Quando você decidir usar o Hyperdisk Balanced High Availability, compare as diferentes opções para aumentar a disponibilidade do serviço e o custo, desempenho e resiliência para diferentes arquiteturas de serviço.
Sobre a replicação síncrona de disco
Um volume do Hyperdisk Balanced High Availability (Pré-lançamento), também conhecido como disco replicado, tem uma zona primária e uma secundária na região onde armazena dados do disco:
- Zona primária é a mesma zona em que a instância da computação a que você anexa o disco está localizada.
- A zona secundária é uma zona alternativa de sua escolha dentro da mesma região.
O Compute Engine mantém réplicas dos seus discos nessas zonas. Quando você grava dados no disco, o Compute Engine replica esses dados de maneira síncrona nas réplicas do disco em ambas as zonas para garantir alta disponibilidade. Os dados de cada réplica zonal são distribuídos por várias máquinas físicas na zona para garantir a durabilidade. As réplicas zonais garantem que os dados do disco permaneçam disponíveis e oferecem proteção contra interrupções temporárias em uma das zonas do disco.
Estado da réplica de réplicas zonais
O estado da réplica do Hyperdisk Balanced High Availability (Pré-lançamento) mostra o estado de uma réplica zonal em comparação com o conteúdo do disco. Réplicas zonais para seus discos estão sempre em um dos seguintes estados de réplica de disco:
- Sincronizada: a réplica está disponível, recebe de maneira síncrona todas as gravações executadas no disco e está atualizada com todos os dados no disco.
- Sincronizando: a réplica está disponível, mas ainda está recebendo os dados do disco da outra réplica.
- Fora de sincronia: a réplica está temporariamente indisponível e fora de sincronia com os dados no disco.
Para aprender a verificar e acompanhar os estados das réplicas zonais, consulte Monitorar os estados da réplica do disco.
Estados de replicação de discos replicados de forma síncrona
Dependendo do estado das réplicas zonais individuais, o volume do Hyperdisk Balanced High Availability (Pré-lançamento) pode estar em um dos os seguintes estados de replicação:
- Totalmente replicada: as réplicas em ambas as zonas estão disponíveis e são sincronizadas com os dados de disco mais recentes.
- Atualizando: suas réplicas zonais estão disponíveis, mas uma das réplicas zonais está sendo atualizada com os dados mais recentes do disco.
- Degradada: uma das réplicas zonais tem o status
out of syncdevido a uma falha ou interrupção do serviço.
Se o status de replicação do disco for catching up ou degraded, uma das
réplicas zonais não foi atualizada com todos os dados. Qualquer interrupção durante esse período
na zona da réplica íntegra resulta na indisponibilidade do
disco até que a zona de réplica íntegra seja restaurada.
Quando seu volume do Hyperdisk Balanced High Availability estiver sendo atualizado,
o Google Cloud começará a corrigir a réplica zonal que está sendo atualizado.
O Google recomenda esperar até que a réplica zonal afetada atualize com
os dados no disco, e o status vai mudar para Synced. Após a
a réplica zonal passar para o estado sincronizada, o status do disco replicado
volta para o estado Fully replicated.
Se o disco replicado tiver um status catching up ou degraded por um
período prolongado e não atender aos requisitos de RPO da sua organização,
recomendamos que você tire snapshots da réplica principal de uma
das seguintes maneiras:
- Ativar snapshots programados.
- Crie um snapshot manual do disco do Hyperdisk Balanced High Availability.
Depois de criar um snapshot, é possível criar um novo disco do Hyperdisk Balanced High Availability usando o snapshot como origem. Isso restaurará o snapshot para o novo disco. O novo disco também começa em um estado totalmente replicado com replicação de dados íntegra.
Para saber como verificar o estado de replicação do Hyperdisk Balanced High Availability, consulte Determinar o estado de replicação dos discos.
Checkpoint de recuperação da réplica
Um checkpoint de recuperação de réplica é um atributo do disco que
representa o ponto
consistente de falhas
mais recente de um disco totalmente replicado. O Compute Engine cria
e mantém automaticamente um único checkpoint de recuperação de réplica para cada disco replicado.
Quando um disco é totalmente replicado, o Compute Engine
continua atualizando o checkpoint aproximadamente a cada 10 minutos para garantir que
o checkpoint permanece atualizado. Quando o status de replicação do disco for
degraded, o Compute Engine permitirá criar um snapshot padrão do
do checkpoint da recuperação de réplica do disco. O snapshot padrão resultante
captura os dados da versão consistente de falhas mais recente do disco
totalmente replicado.
Em cenários raros, quando o disco sofre degradação, a réplica zonal que está sincronizada com os dados mais recentes do disco também pode falhar antes que a réplica fora de sincronia faça a sincronização. Não será possível forçar a anexação do disco à instância da computação em nenhuma das zonas. O disco replicado ficará indisponível e você deverá migrar os dados para um novo disco. Nesses cenários, se você não tiver snapshots padrão disponíveis para o disco, ainda será possível recuperar os dados do disco da réplica incompleta usando um snapshot padrão criado com base no checkpoint de recuperação de réplica.
O Compute Engine cria automaticamente pontos de verificação de recuperação de réplicas para cada disco do Hyperdisk Balanced High Availability (pré-lançamento) montado. Não há cobranças extras pela criação desses checkpoints. No entanto, haverá cobranças de armazenamento aplicáveis para criação de snapshots e instâncias de computação quando esses checkpoints forem usados para migrar o disco replicado para as zonas em funcionamento.
Saiba mais sobre como recuperar os dados do disco replicado usando um checkpoint de recuperação da réplica.
Failover de disco replicado
No caso de uma interrupção em uma zona, ela fica inacessível e a instância de computação nela não pode executar operações de leitura ou gravação no disco. Para permitir que a instância continue executando operações de leitura e gravação no disco, replicado, o Compute Engine permite a migração dos dados do disco para a outra zona em que o disco tem uma réplica. Esse processo é chamado de failover.
O failover envolve a desanexação da réplica zonal da instância em a zona afetada e anexar a réplica zonal a uma nova instância na zona secundária. O Compute Engine replica os dados do disco de maneira síncrona na zona secundária para garantir um failover rápido em caso de uma única falha de réplica.
Failover por plano de controle regional específico do aplicativo
O plano de controle regional específico do aplicativo não é um serviço do Google Cloud. Ao projetar arquiteturas de serviço de alta disponibilidade, você precisa criar seu próprio plano de controle regional específico do aplicativo. Este plano de controle do aplicativo decide qual instância deve ter o disco replicado anexado e qual é a instância principal atual.
Quando uma falha é detectada na instância primária ou no banco de dados do disco replicado, o plano de controle regional específico do aplicativo da arquitetura de serviço de alta disponibilidade pode iniciar automaticamente o failover para a instância em espera na zona secundária. Durante o failover, o plano de controle regional específico do aplicativo reanexa o disco replicado à instância em espera na zona secundária. Em seguida, o Compute Engine direciona todo o tráfego para essa instância 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 seguintes latências:
- Menos de 1 minuto para anexar um disco replicado a uma instância em espera
- Tempo necessário para a inicialização do aplicativo e a recuperação de falhas
Para mais informações, consulte Noções básicas sobre o plano de controle regional específico do aplicativo.
A página Elementos básicos da recuperação de desastres aborda os elementos básicos disponíveis no Compute Engine.
Failover por anexação forçada
Um dos benefícios do Hyperdisk Balanced High Availability (Pré-lançamento) é que, no caso improvável de uma interrupção do serviço zonal, é possível fazer o failover para outra zona manualmente. Quando a zona original tem uma interrupção, não é possível concluir a operação de remoção do disco até que a réplica zonal seja restaurada. Neste cenário, talvez seja necessário anexar a réplica zonal secundária a uma nova instância de computação sem remover a réplica zonal principal da instância principal instância. Esse processo é chamado de force-attach.
Quando a instância de computação na zona primária ficar indisponível, será possível forçar a anexação do disco a uma instância na zona secundária. Para executar essa tarefa, é preciso seguir um destes procedimentos:
- Iniciar outra instância de computação na mesma zona do disco replicado sendo anexado.
- Manter uma instância de computação de espera ativa nessa zona. A espera ativa é uma instância em execução idêntica à da zona principal. As duas instâncias têm os mesmos dados.
O Compute Engine executa a operação de anexação forçada em menos de um minuto. O objetivo do tempo de recuperação (RTO) total depende não apenas do failover de armazenamento, que é a anexação forçada do disco replicado, mas também de outros fatores, como:
- se é preciso criar uma instância secundária;
- o tempo que o sistema de arquivos subjacente leva para detectar um disco anexado ativo;
- O tempo de recuperação dos aplicativos correspondentes
Para mais informações sobre como fazer failover da instância de computação
usando a anexação forçada, consulte
Fazer failover do disco replicado usando force-attach.
Limitações
As seções a seguir listam as limitações que se aplicam ao Hyperdisk Balanced High Availability (Prévia).
Limitações gerais para discos replicados
- Você pode anexar o Hyperdisk Balanced High Availability somente a arquivos tipos de máquina compatíveis.
- Só é possível aumentar o tamanho do volume do Hyperdisk Balanced High Availability; não é possível diminuir o tamanho.
- Hyperdisk Balanced High Availability têm desempenhos diferentes do que os discos zonais correspondentes. Para mais informações, consulte Desempenho do armazenamento em blocos.
- Se você criar um disco replicado clonando um disco zonal, as duas réplicas zonais não estarão totalmente sincronizadas no momento da criação. Após a criação, é possível usar o clone de disco regional em média em até três minutos. No entanto, talvez seja necessário aguardar diversos minutos até que o disco atinja um estado totalmente replicado e o objetivo de ponto de recuperação (RPO) esteja próximo de zero. Saiba como Verificar se o disco replicado foi totalmente replicado.
Limitações dos checkpoints de recuperação de réplicas
- Um checkpoint de recuperação de réplica faz parte dos metadados do dispositivo e não mostra nenhum dado do disco por si só. Só é possível usar o checkpoint como um mecanismo para criar um snapshot do disco degradado. Depois de criar o snapshot com base no checkpoint, é possível usá-lo para restaurar os dados.
- Só é possível criar snapshots com base em um checkpoint de recuperação de réplica quando o disco está degradado.
- O Compute Engine só atualiza o checkpoint de recuperação de réplica do disco quando o disco está totalmente replicado.
- O Compute Engine só mantém um checkpoint de recuperação de réplica para cada disco e mantém apenas a versão mais recente desse checkpoint.
- Não é possível visualizar os carimbos de data/hora exatos de criação e atualização de um checkpoint de recuperação de réplica.
- Só é possível criar um snapshot com base no checkpoint de recuperação da réplica usando a API Compute Engine.
A seguir
- Saiba mais sobre preços de discos.
- Saiba como criar e gerenciar discos replicados.
- Saiba como monitorar os estados de réplica dos discos.
- Saiba como determinar o estado de replicação de um disco.
- Saiba como gerenciar falhas de discos replicados.
- Saiba como criar um snapshot de um disco replicado.
- Saiba como criar serviços de alta disponibilidade usando discos replicados.
- Saiba como criar aplicativos da Web escalonáveis e resilientes no Google Cloud.
- Consulte o guia de planejamento de recuperação de desastres.