Gerenciar falhas de discos replicados de maneira síncrona

Neste documento, explicamos os vários cenários que podem interromper o funcionamento dos discos replicados de maneira síncrona e como gerenciar esses cenários.

Antes de começar

• Analise os conceitos básicos de failover e discos replicados de maneira síncrona. Para mais informações, consulte Sobre a replicação síncrona de discos.
• Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud. Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine da seguinte maneira.
  

  Select the tab for how you plan to use the samples on this page:

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

  2. Set a default region and zone.

  REST

  Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.

Funções exigidas

Para receber as permissões necessárias e migrar dados de um disco replicado de maneira síncrona usando um checkpoint de recuperação de réplica, peça ao administrador para conceder a você os seguintes papéis do IAM:

• Para migrar dados de um disco replicado de maneira síncrona usando um checkpoint de recuperação de réplica: Administrador da instância do Compute (v1) (roles/compute.instanceAdmin.v1) no projeto
• Para conferir as métricas do disco replicado (uma das seguintes opções):
  • Leitor do Monitoring (roles/monitoring.viewer) no projeto
  • Editor do Monitoring (roles/monitoring.editor) no projeto

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para migrar dados de discos replicados de maneira síncrona usando um checkpoint de recuperação de réplica. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Cenários de falha

Com os discos replicados de maneira síncrona, quando o dispositivo é totalmente replicado, os dados são replicados automaticamente em duas zonas de uma região. Uma gravação é confirmada em uma instância de computação quando é mantida de maneira durável nas duas réplicas.

Se a replicação para uma zona falhar ou ficar muito lenta por um tempo, o status de replicação do disco mudará para degradado. Nesse modo, a gravação é confirmada depois de ser mantida de maneira durável em uma réplica.

Se e quando o Compute Engine detectar que a replicação pode ser retomada, os dados gravados em uma réplica depois que a outra entrou no estado degradado serão sincronizados com as duas zonas, e o disco retornará a um estado totalmente replicado. Essa transição é totalmente automatizada.

RPO e RTO são indefinidos enquanto um dispositivo está em estado degradado. Para minimizar a perda de dados e de disponibilidade em caso de falha em um disco que está operando em estado degradado, recomendamos fazer backup dos discos replicados de maneira síncrona regularmente usando snapshots padrão. É possível recuperar um disco ao restaurar o snapshot.

Falhas zonais

Um disco replicado, ou regional, é replicado de maneira síncrona nas réplicas de disco nas zonas principal e secundária. As falhas de zona ocorrem quando uma réplica zonal fica inativa. Falhas zonais podem ocorrer na zona principal ou secundária devido a um dos seguintes motivos:

• Há uma falha temporária na zona.
• A réplica apresenta lentidão excessiva nas operações de gravação.

A tabela a seguir apresenta os vários cenários de falha de zona que podem ocorrer em discos replicados de maneira síncrona e a ação recomendada para cada cenário. Em cada um desses cenários, supõe-se que a réplica de zona principal está íntegra e sincronizada durante o estado inicial.

Falhas no aplicativo e na VM

No caso de interrupções causadas por configurações incorretas da VM, falha no upgrade do SO ou outras falhas de app, é possível force-attach o disco replicado em uma instância de computação na mesma zona que a réplica íntegra.

Fazer failover de um disco replicado usando force-attach

Em caso de falha na zona principal, é possível fazer o failover do volume do Persistent Disk regional ou do Hyperdisk Balanced High Availability (Pré-lançamento) para uma instância de computação em outra zona usando uma operação de anexação forçada.

Quando há uma falha na zona principal, pode não ser possível remover o disco da instância porque não é possível acessá-la para executar a operação de remoção. A anexação forçada permite anexar um volume do Persistent Disk regional ou do Hyperdisk Balanced High Availability a uma instância de computação, mesmo que ele já esteja anexado a outra instância.

Depois que você concluir a operação de anexação forçada, o Compute Engine vai impedir que a instância original faça gravações no disco replicado. Com a operação de anexação forçada, é possível recuperar com segurança o acesso aos dados e recuperar o serviço. Você também tem a opção de encerrar manualmente a instância de VM depois de executar a operação de anexação forçada.

Para forçar a anexação de um disco atual a uma instância de computação, selecione uma das seguintes tarefas:

gcloud compute instances attach-disk VM_NAME \
    --disk DISK_NAME --disk-scope regional \
    --force-attach

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/VM_NAME/attachDisk?forceAttach=true

{
 "source": "projects/PROJECT_ID/regions/REGION/disks/DISK_NAME"
}

Fazer failover de um disco de inicialização em uma instância secundária

Só é possível ter um disco de inicialização anexado a uma instância de computação. Ao fazer failover de um disco de inicialização replicado, use um dos seguintes métodos, de acordo com a existência ou não da instância de computação secundária:

• Se você não tiver uma VM em espera ativa, crie uma nova instância na zona secundária. Ao criar a segunda instância, use o disco replicado para o disco de inicialização, conforme descrito em Criar uma VM com um disco de inicialização replicado.

• Se você tiver uma VM em espera na zona secundária, substitua o disco de inicialização da VM em espera pelo disco de inicialização replicado, conforme descrito em Anexar um disco de inicialização replicado a uma VM.

Usar o checkpoint de recuperação de réplica para recuperar discos replicados

Um checkpoint de recuperação de réplica representa o momento mais recente consistente com falhas de um volume totalmente replicado do Persistent Disk regional ou do Hyperdisk Balanced High Availability (Pré-lançamento). O Compute Engine permite criar snapshots padrão do checkpoint de recuperação de réplica para discos regionais degradados.

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. Consulte Procedimento para migrar e recuperar dados do disco para ver as etapas detalhadas.

Procedimento para migrar e recuperar dados do disco

Para recuperar e migrar os dados de um disco replicado usando o checkpoint de recuperação de réplica, siga estas etapas:

1. Crie um snapshot padrão do volume impactado do Persistent Disk regional ou do Hyperdisk Balanced High Availability (Pré-lançamento) no checkpoint de recuperação de réplica.

   Só é possível criar o snapshot padrão de um disco com base no checkpoint de recuperação de réplica usando a gcloud CLI ou REST.

   gcloud

   Para criar um snapshot usando o checkpoint de recuperação de réplica, use o comando gcloud compute snapshots create . Inclua a flag --source-disk-for-recovery-checkpoint para especificar que você quer criar o snapshot usando um checkpoint de recuperação de réplica. Exclua os parâmetros --source-disk e --source-disk-region.

   gcloud compute snapshots create SNAPSHOT_NAME \
       --source-disk-for-recovery-checkpoint=SOURCE_DISK \
       --source-disk-for-recovery-checkpoint-region=SOURCE_REGION \
       --storage-location=STORAGE_LOCATION \
       --snapshot-type=SNAPSHOT_TYPE
   

   Substitua:

   • DESTINATION_PROJECT_ID: o ID do projeto em que você quer criar o snapshot.
   • SNAPSHOT_NAME: um nome para o snapshot.
   • SOURCE_DISK: o nome ou caminho completo do disco de origem que você quer usar para criar o snapshot. Para especificar o caminho completo de um disco de origem, use a seguinte sintaxe:

       projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME
       

     Se você especificar o caminho completo para o disco de origem, será possível excluir a flag --source-disk-for-recovery-checkpoint-region. Se você especificar apenas o nome do disco, inclua essa flag.

     Para criar um snapshot com base no checkpoint de um disco de origem em um projeto diferente, especifique o caminho completo para esse disco.

   • SOURCE_PROJECT_ID: o ID do projeto do disco de origem que tem o checkpoint que você quer usar para criar o snapshot.
   • SOURCE_REGION: a região do disco de origem que tem o checkpoint que você quer usar para criar o snapshot.
   • SOURCE_DISK_NAME: o nome do disco de origem que tem o checkpoint que você quer usar para criar o snapshot.
   • STORAGE_LOCATION (opcional): a multirregião do Cloud Storage ou a região do Cloud Storage em que você quer armazenar o snapshot. É possível especificar apenas um local de armazenamento.
     Use a flag --storage-location apenas quando quiser substituir o local de armazenamento padrão predefinido ou personalizado que está definido nas configurações de snapshot.
   • SNAPSHOT_TYPE: o tipo de snapshot, que é PADRÃO ou ARCHIVE. Se um tipo de snapshot não for especificado, um snapshot STANDARD será criado.

   Somente no caso de discos degradados é possível usar o checkpoint de recuperação da réplica para criar um snapshot. Se você tentar criar um snapshot com base em um checkpoint de recuperação de réplica quando o dispositivo estiver totalmente replicado, a seguinte mensagem de erro será exibida:

   The device is fully replicated and should not create snapshots out of a recovery checkpoint. Please
   create regular snapshots instead.
   

   REST

   Para criar um snapshot usando o checkpoint de recuperação da réplica, faça uma solicitação POST para o método snapshots.insert. Exclua o parâmetro sourceDisk e inclua o parâmetro sourceDiskForRecoveryCheckpoint para especificar que você quer criar o snapshot com base no checkpoint.

   POST https://compute.googleapis.com/compute/v1/projects/DESTINATION_PROJECT_ID/global/snapshots
   
   {
     "name": "SNAPSHOT_NAME",
     "sourceDiskForRecoveryCheckpoint": "projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME",
     "storageLocations": "STORAGE_LOCATION",
     "snapshotType": "SNAPSHOT_TYPE"
   }
   

   Substitua:

   • DESTINATION_PROJECT_ID: o ID do projeto em que você quer criar o snapshot.
   • SNAPSHOT_NAME: um nome para o snapshot.
   • SOURCE_DISK: o nome ou caminho completo do disco de origem que você quer usar para criar o snapshot. Para especificar o caminho completo de um disco de origem, use a seguinte sintaxe:

       projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME
       

     Se você especificar o caminho completo para o disco de origem, será possível excluir a flag --source-disk-for-recovery-checkpoint-region. Se você especificar apenas o nome do disco, inclua essa flag.

     Para criar um snapshot com base no checkpoint de um disco de origem em um projeto diferente, especifique o caminho completo para esse disco.

   • SOURCE_PROJECT_ID: o ID do projeto do disco de origem que tem o checkpoint que você quer usar para criar o snapshot.
   • SOURCE_REGION: a região do disco de origem que tem o checkpoint que você quer usar para criar o snapshot.
   • SOURCE_DISK_NAME: o nome do disco de origem que tem o checkpoint que você quer usar para criar o snapshot.
   • STORAGE_LOCATION (opcional): a multirregião do Cloud Storage ou a região do Cloud Storage em que você quer armazenar o snapshot. É possível especificar apenas um local de armazenamento.
     Use o parâmetro storageLocations somente quando quiser substituir o local de armazenamento padrão predefinido ou personalizado que está definido nas configurações de snapshot.
   • SNAPSHOT_TYPE: o tipo de snapshot, que é PADRÃO ou ARCHIVE. Se um tipo de snapshot não for especificado, um snapshot STANDARD será criado.

   Somente no caso de discos degradados é possível usar o checkpoint de recuperação da réplica para criar um snapshot. Se você tentar criar um snapshot com base em um checkpoint de recuperação de réplica quando o dispositivo estiver totalmente replicado, a seguinte mensagem de erro será exibida:

   The device is fully replicated and should not create snapshots out of a recovery checkpoint. Please
   create regular snapshots instead.
   

2. Crie um disco do Persistent Disk regional ou do Hyperdisk Balanced High Availability usando esse snapshot. Ao criar o disco, você recupera todos os dados do checkpoint de recuperação de réplica mais recente restaurando-os no novo disco com base no snapshot. Para conferir as etapas detalhadas, consulte Criar uma VM com um disco de inicialização replicado.

3. Migre todas as cargas de trabalho da VM para o disco recém-criado e verifique se elas estão sendo executadas corretamente. Para mais informações, consulte Mover uma VM entre zonas ou regiões.

Depois de recuperar e migrar os dados do disco e as VMs para o disco recém-criado do Persistent Disk regional ou do Hyperdisk Balanced High Availability, é possível retomar as operações.

Determinar o RPO fornecido pelo checkpoint de recuperação de réplica

Esta seção explica como determinar o RPO fornecido pelo checkpoint de recuperação de réplica mais recente de um volume do Persistent Disk regional ou do Hyperdisk Balanced High Availability (Pré-lançamento).

As réplicas zonais estão totalmente sincronizadas

O Compute Engine atualiza o checkpoint de recuperação de réplica do volume do Persistent Disk regional ou do Hyperdisk Balanced High Availability aproximadamente a cada 10 minutos. Como resultado, quando as réplicas zonais estiverem totalmente sincronizadas, o RPO terá aproximadamente 10 minutos.

As réplicas zonais estão fora de sincronia

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. No entanto, é possível estimar o RPO aproximado que seu checkpoint mais recente fornece usando os dados a seguir:

• Carimbo de data/hora mais recente do estado do disco totalmente replicado: é possível acessar essas informações usando os dados do Cloud Monitoring para a métrica replica_state do disco replicado. Verifique os dados da métrica replica_state da réplica fora de sincronia para determinar quando ela entrou nesse estado. Como o Compute Engine atualiza o checkpoint do disco a cada 10 minutos, a atualização mais recente pode ter ocorrido aproximadamente 10 minutos antes desse carimbo de data/hora.
• Carimbo de data/hora da operação de gravação mais recente: é possível acessar essas informações usando os dados do Cloud Monitoring para a métrica write_ops_count do disco replicado. Verifique os dados da métrica write_ops_count para determinar a operação de gravação mais recente no disco.

Depois de determinar esses carimbos de data/hora, use a fórmula a seguir para calcular o RPO aproximado fornecido pelo checkpoint de recuperação de réplica do disco. Se o valor calculado for menor que zero, o RPO será zero.

Approximate RPO provided by the latest checkpoint = (Most recent write operation timestamp - (Most recent timestamp of the fully replicated disk state - 10 minutes))

A seguir

• Saiba como monitorar os estados e o status de replicação de discos replicados de maneira síncrona.
• Saiba como determinar o status exato de replicação de um disco.
• Saiba como criar um snapshot de um disco.
• Saiba como criar serviços de alta disponibilidade usando discos replicados de maneira síncrona.
• Saiba como criar aplicativos da Web escalonáveis e resilientes no Google Cloud.
• Consulte o guia de planejamento de recuperação de desastres.