Sobre o Persistent Disk regional

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 dados de maneira síncrona entre duas zonas na mesma região e garante alta disponibilidade para os dados do disco em caso de até uma falha zonal.

Os volumes do Persistent Disk regional são projetados para cargas de trabalho que exigem um objetivo de ponto de recuperação (RPO) e um objetivo de 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.

Os volumes do Persistent Disk regional foram projetados para também funcionar com grupos gerenciados de instâncias regionais.

Neste documento, você encontra uma visão geral sobre o Persistent Disk regional e compreende como usar os volumes dele para criar serviços de alta disponibilidade.

Ao decidir usar o Persistent Disk regional, compare as diferentes opções para aumentar a disponibilidade do serviço e o custo, o desempenho e a resiliência de arquiteturas de serviço distintas.

Replicação de disco zonal para Persistent Disk regional

Um volume do Persistent Disk regional tem uma zona primária e uma secundária dentro da região em que ele armazena os dados do disco:

  • A zona primária é a mesma zona da instância da máquina virtual (VM) a que o disco é anexado.
  • A zona secundária é uma zona alternativa de sua escolha dentro da mesma região.

O Compute Engine mantém réplicas do seu volume do Persistent Disk regional nessas duas 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 volume do Persistent Disk 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 mostra o estado de uma réplica zonal em comparação com o conteúdo do disco. Réplicas zonais do seu Persistent Disk regional estão sempre em um dos seguintes estados de réplica:

  • 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 saber como verificar e rastrear os estados das réplicas das réplicas zonais, consulte Monitorar os estados das réplicas de discos dos volumes regionais de Persistent Disk.

Estado de replicação do Persistent Disk regional

Dependendo do estado das réplicas zonais individuais, o volume regional do disco permanente pode estar em um dos seguintes estados de replicação:

  • totalmente replicado; Réplicas em ambas as zonas estão disponíveis e são sincronizadas com os dados mais recentes do disco.
  • 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 está fora de sincronia devido a uma falha ou interrupção.

Se o volume regional do Persistent Disk estiver aumentando ou degradado, uma das réplicas zonais não será atualizada com todos os dados. Qualquer interrupção durante esse tempo na zona da réplica íntegra resultará na indisponibilidade do volume regional do Persistent Disk até a restauração da zona da réplica íntegra.

Quando ocorre a atualização do volume do Persistent Disk, o Google Cloud começa a corrigir a réplica zonal que está no estado "Sincronizando". O Google recomenda que você aguarde até que a réplica zonal afetada receba os dados do disco. Depois que a réplica zonal passar para o estado "Sincronizada", o volume do Persistent Disk regional será revertido para um estado totalmente replicado. Se o volume do Persistent Disk regional ficar no estado "Sincronizando" ou "Degradado" por um período prolongado e não atender aos requisitos de RPO da sua organização, faça snapshots do disco de uma das seguintes maneiras:

  • Ativar snapshots programados.
  • Crie um snapshot manual para o volume regional do disco permanente.

Após a criação do snapshot, será possível criar um novo volume regional no disco permanente usando esse snapshot. Você recupera os dados no novo volume regional de discos permanentes. O novo volume 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 seu volume de disco permanente regional, consulte Determinar o estado de replicação do disco permanente regional.

Ponto de verificação de recuperação de réplica do Persistent Disk regional

Um checkpoint de recuperação de réplica é um atributo do Persistent Disk regional 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 volume do Persistent Disk regional. Quando um volume do Persistent Disk regional é totalmente replicado, o Compute Engine atualiza o checkpoint aproximadamente a cada 10 minutos para garantir que ele permaneça atualizado. Quando o volume do Persistent Disk regional fica em estado degradado, o Compute Engine permite criar um snapshot padrão do checkpoint de 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 a VMs em nenhuma das zonas. Seu volume do Persistent Disk regional ficará indisponível, e você precisará 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 checkpoints de recuperação de réplica para cada volume ativado do Persistent Disk regional. Não há cobranças extras pela criação desses checkpoints. No entanto, haverá cobranças de armazenamento aplicáveis pela criação de snapshots e VMs ao usar esses checkpoints a fim de migrar o disco para zonas em funcionamento.

Saiba como recuperar os dados do Persistent Disk regional usando um checkpoint de recuperação de réplica.

Failover do Persistent Disk regional

No caso de uma interrupção em uma zona, ela fica inacessível e a VM nela não pode executar operações de leitura ou gravação no disco. Para permitir que a VM continue executando operações de leitura e gravação no disco, 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 do Persistent Disk regional. O processo de failover envolve a desanexação da VM da réplica de disco na zona afetada e a reconexão de uma nova VM à réplica de disco na outra zona. O Compute Engine replica os dados do disco de maneira síncrona na região 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. Esse plano de controle decide qual VM precisa ter o Persistent Disk regional anexado e qual VM é a primária atual. Quando uma falha é detectada na VM primária ou no banco de dados do volume do Persistent Disk regional, o plano de controle regional específico do aplicativo da arquitetura de serviços de alta disponibilidade pode iniciar automaticamente o failover para a VM em espera na zona secundária. Durante o failover, o plano de controle regional específico do aplicativo anexa novamente o volume do Persistent Disk regional à VM em espera na zona secundária. Em seguida, o Compute Engine direciona todo o tráfego 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 seguintes latências:

  • Zero segundo para reanexar um volume do Persistent Disk regional a uma VM 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 Persistent Disk regional é que, no caso improvável de uma interrupção zonal, também é possível fazer o failover manual da carga de trabalho em execução no Persistent Disk regional para outra zona. Quando a zona original passar por uma interrupção, não será possível concluir a operação de remoção até que a réplica zonal seja restaurada. Nesse cenário, talvez seja necessário anexar a nova VM à réplica zonal secundária sem remover a VM da réplica zonal primária. Esse processo é chamado de anexação forçada.

Quando a instância de VM na zona primária fica indisponível, é possível forçar a anexação do disco a uma instância de VM na zona secundária. Para executar essa tarefa, é preciso seguir um destes procedimentos:

  • Inicie outra instância de VM na mesma zona em que você está forçando a anexação do volume do Persistent Disk regional.
  • Mantenha uma instância de VM de espera ativa nessa zona. A instância em espera ativa é uma instância de VM em execução igual àquela que você está usando. 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 de tempo de recuperação (RTO) total depende não apenas do failover de armazenamento, que é a anexação forçada do volume do do Persistent Disk regional, mas também de outros fatores, como os seguintes:

  • Se é preciso criar uma instância de VM 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 o failover da VM usando a anexação forçada, consulte Fazer failover do volume do Persistent Disk regional usando force-attach.

O Persistent Disk regional favorece a disponibilidade da carga de trabalho. Isso significa que há concessões para a proteção de dados no caso improvável de ambas as réplicas de disco ficarem indisponíveis ao mesmo tempo. Para mais informações, consulte Gerenciar falhas no Persistent Disk regional.

Limitações

As seções a seguir listam as limitações que se aplicam ao Persistent Disk regional.

Limitações gerais do Persistent Disk regional

  • Só é possível anexar Persistent Disk regionais a VMs que usam tipos de máquina E2, N1, N2 e N2D.
  • Não é possível criar um Persistent Disk regional com base em 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 de um volume do Persistent Disk regional. Não é possível diminuir o tamanho dele.
  • Os volumes de disco permanente regional têm características de desempenho diferentes dos volumes zonais. Para mais informações, consulte Desempenho do armazenamento em blocos.
  • Se você criar um disco permanente regional 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 Persistent Disk regional está totalmente replicado.

Limitações do checkpoint de recuperação de réplica do Persistent Disk regional

  • 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