Sobre a replicação síncrona de disco

O Disco permanente regional e o Hyperdisk Balanced High Availability são opções de armazenamento que permitem implementar serviços de alta disponibilidade (HA, na sigla em inglês) no Compute Engine. O Disco permanente regional e o Hyperdisk Balanced High Availability replicam dados de maneira síncrona entre duas zonas na mesma região e garantem a alta disponibilidade para dados de disco de até uma falha na zona.

Os volumes do Disco permanente regional e do Hyperdisk Balanced High Availability foram projetados para cargas de trabalho que exigem um objetivo do ponto de recuperação (RPO, na sigla em inglês) e um objetivo do tempo de recuperação (RTO, na sigla em inglês) menores. Para saber mais sobre RPO e RTO, consulte Noções básicas do planejamento de recuperação de desastres.

Os volumes do Disco permanente regional e do 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 Disco permanente regional e do Hyperdisk Balanced High Availability.

Quando você decidir usar o Disco permanente regional ou 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 Disco permanente regional ou 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 Disco permanente regional ou 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 Disco permanente regional ou 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 sync devido 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 Disco permanente regional ou 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 permanente regional ou do disco do Hyperdisk Balanced High Availability.

Depois de criar um snapshot, é possível criar um novo Disco permanente regional ou 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 Disco permanente regional ou 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 de 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 Disco permanente regional ou 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 Disco permanente regional e 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 anexação forçada.

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.

O disco permanente regional e o Hyperdisk Balanced High Availability favorecem a disponibilidade da carga de trabalho, o que significa que há compensações para a proteção de dados no evento improvável de ambas as réplicas de disco ficarem indisponíveis ao mesmo tempo. Para mais informações, consulte Gerenciar falhas de discos replicados.

Limitações

As seções a seguir listam as limitações que se aplicam ao Disco permanente regional e ao Hyperdisk Balanced High Availability (Prévia).

Limitações gerais para discos replicados

  • Só é possível anexar Persistent Disk regionais a VMs que usam tipos de máquina E2, N1, N2 e N2D.
  • Você pode anexar o Hyperdisk Balanced High Availability somente a arquivos tipos de máquina compatíveis.
  • Não é possível criar um Persistent Disk regional a partir de uma imagem ou de um disco criado a partir de uma imagem.
  • Ao usar o modo somente leitura, é possível anexar um Persistent Disk equilibrado regional a, no máximo, 10 instâncias de VM.
  • O tamanho mínimo de um disco permanente regional padrão é 200 GB.
  • Só é possível aumentar o tamanho do volume do Disco permanente regional ou do Hyperdisk Balanced High Availability; não é possível diminuir o tamanho.
  • Os volumes do Disco permanente regional e do Hyperdisk Balanced High Availability têm desempenhos diferentes do que os discos zonais correspondentes. Para mais informações, consulte Desempenho do armazenamento em blocos.
  • Não é possível usar um volume do Hyperdisk equilibrado de alta disponibilidade que esteja no modo de vários gravadores como um disco de inicialização.
  • 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