Gerenciar falhas no Persistent Disk regional

O disco permanente regional é uma opção de armazenamento que fornece a replicação síncrona dos dados entre duas zonas em uma região. É possível usar o Persistent Disk regional como elemento básico ao implementar serviços de alta disponibilidade (HA, na sigla em inglês) no Compute Engine.

Neste documento, explicamos os vários cenários que podem interromper o funcionamento do volume de Persistent Disk regional e como gerenciar esses cenários.

Antes de começar

  • Analise as informações básicas sobre a replicação e failover zonal do Persistent Disk regional. Para mais informações, consulte Sobre o Persistent Disk regional.
  • 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.

    Selecione a guia para como planeja usar as amostras nesta página:

    gcloud

    1. Instale a Google Cloud CLI e inicialize-a executando o seguinte comando: 

      gcloud init
    2. Defina uma região e uma zona padrão.

    REST

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

      Instale a Google Cloud CLI e inicialize-a executando o seguinte comando: 

      gcloud init

Cenários de falha

Com os discos permanentes regionais, quando o dispositivo é totalmente replicado, os dados são replicados automaticamente para duas zonas em uma região. Uma gravação é confirmada em uma instância de máquina virtual (VM) quando é persistida 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 anteriormente desde que o dispositivo 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/ou disponibilidade em caso de falha de um disco operando em um estado degradado, recomendamos que você faça backup dos discos permanentes regionais regularmente usando instantâneos padrão. É possível recuperar um disco ao restaurar o snapshot.

Falhas zonais

Um volume regional de disco permanente é replicado de maneira síncrona para réplicas de disco nas zonas primária e secundária. As falhas zonais ocorrem quando uma réplica zonal fica inativa e fica indisponível. Falhas zonais podem ocorrer em qualquer uma das zonas 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.

Na tabela a seguir, apresentamos os vários cenários de falha de zona que podem ser encontrados no Persistent Disk regional e a ação recomendada para cada um deles. Em cada um desses cenários, supõe-se que a réplica zonal principal está íntegra e sincronizada durante o estado inicial.

Estado inicial do disco Falha em Novo estado do disco Consequências das falhas Ação

Réplica primária: sincronizada

Réplica secundária: sincronizada

Status do disco: totalmente replicado

Disco anexado em:zona principal

 Zona principal

Réplica primária:fora de sincronia ou indisponível

Réplica secundária: sincronizada

Status do disco: degradado

Disco anexado em:zona principal
  • A réplica na zona secundária permanece íntegra e tem os dados mais recentes do disco.
  • A réplica na zona principal não está íntegra e pode não ter todos os dados do disco.
Faça failover do disco com a anexação forçada a uma VM na zona secundária íntegra.

Réplica primária: sincronizada

Réplica secundária: sincronizada

Status do disco: totalmente replicado

Disco anexado em:zona principal

 Zona secundária

Réplica primária: sincronizada

Réplica secundária:fora de sincronia ou indisponível

Status do disco: degradado

Disco anexado em:zona principal
  • A réplica na zona principal permanece íntegra e tem os dados mais recentes do disco.
  • A réplica na zona secundária não está íntegra e pode não ter todos os dados do disco.
Nenhuma ação é necessária. O Compute Engine sincroniza novamente a réplica não íntegra na zona secundária quando ela estiver disponível novamente.

Réplica primária: sincronizada

Réplica secundária:fora de sincronia e indisponível

Status do disco: degradado

Disco anexado em:zona principal

 Zona principal

Réplica primária:sincronizada, mas indisponível

Réplica secundária:fora de sincronia

Status do disco: indisponível

Disco anexado em:zona principal
  • As duas réplicas zonais estão indisponíveis e não podem veicular tráfego. O disco ficará indisponível.
  • Se a falha temporária na zona ou a falha na réplica for temporária, nenhum dado será perdido.
  • Se a falha na zona ou na réplica for permanente, todos os dados gravados na réplica íntegra enquanto o disco estava degradado serão perdidos permanentemente.
O Google recomenda que você use um snapshot padrão atual e crie um novo disco para recuperar seus dados. Como prática recomendada, faça backup dos volumes de Persistent Disk regionais regularmente usando snapshots padrão.

Réplica primária: sincronizada

Réplica secundária:acompanhando, mas disponível

Status do disco: em atualização

Disco anexado em:zona principal

 Zona principal

Réplica primária:indisponível

Réplica secundária:acompanhando, mas disponível

Status do disco: indisponível

Disco anexado em:zona principal
  • As duas réplicas zonais não podem veicular tráfego. O disco ficará indisponível.
  • Se a falha temporária na zona ou na réplica for temporária, o disco retomará as operações depois que a réplica primária estiver disponível novamente.
  • Se a interrupção na zona ou a falha na réplica for permanente, o disco vai ficar inutilizável.

Réplica primária: sincronizada

Réplica secundária:fora de sincronia, mas disponível

Status do disco: degradado

Disco anexado em:zona principal

 Zona principal

Réplica primária:indisponível

Réplica secundária:fora de sincronia, mas disponível

Status do disco: indisponível

Disco anexado em:zona principal
  • As duas réplicas zonais não podem veicular tráfego. O disco ficará indisponível.
  • Se a falha temporária na zona ou na réplica for temporária, o disco retomará as operações depois que a réplica primária estiver disponível novamente.
  • Se a interrupção na zona ou a falha na réplica for permanente, o disco vai ficar inutilizável.

Falhas no aplicativo e na VM

No caso de interrupções causadas por configuração incorreta da VM, uma falha no upgrade do SO ou outras falhas do aplicativo, é possível force-attach do seu disco permanente regional para uma instância de VM na mesma zona.

Categoria da falha e probabilidade Tipos de falha Ação
Falha no aplicativo (alta)
  • Aplicativos que não respondem
  • Falha devido a ações administrativas do aplicativo (por exemplo, upgrade)
  • Erro humano (por exemplo, configuração incorreta de parâmetros, como certificado SSL ou ACLs)
 O plano de controle do aplicativo pode acionar o failover com base nos limites da verificação de integridade.
Falha na VM (média)
  • Falha na infraestrutura ou no hardware
  • A VM não responde devido à contenção de CPU ou interrupção de rede intermediária
 As VMs geralmente se recuperam automaticamente. O plano de controle do aplicativo pode acionar o failover com base nos limites de verificação de integridade.
Aplicativo corrompido (baixa a média) Dados do aplicativo corrompidos
(por exemplo, devido a bugs ou a um upgrade de sistema operacional malsucedido) 		Recuperação do aplicativo:

Fazer failover do disco permanente regional usando force-attach

Em caso de falha na zona principal, é possível fazer o failover do volume Persistent Disk regional para uma VM em outra zona usando uma operação de anexação forçada. Quando há uma falha na zona principal, talvez não seja possível remover o disco da VM porque não é possível acessá-la para executar a operação de remoção. A operação de anexação forçada permite anexar um volume de disco permanente regional a uma VM, mesmo que esse volume esteja anexado a outra. Depois de concluir a operação de anexação forçada, o Compute Engine impedirá que a VM original grave no volume regional do Persistent Disk. Usar a operação de anexação forçada permite que você recupere com segurança o acesso aos seus dados e 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 VM, execute as seguintes etapas:

Console

  1. Acesse a página Instâncias da VM.

    Acessar instâncias de VM

  2. Selecione o projeto.

  3. Clique no nome da VM que você quer alterar.

  4. Na página de detalhes, clique em Editar.

  5. Na seção Discos extras, clique em Anexar disco extra.

  6. Selecione o disco permanente regional na lista suspensa.

  7. Para forçar a anexação do disco, marque a caixa de seleção Forçar anexação de disco.

  8. Clique em Concluído e depois em Salvar.

Após a falha ser resolvida, execute as mesmas etapas para force-attach um disco na VM original.

gcloud

Na CLI gcloud, use o comando instances attach-disk para anexar o disco de réplica a uma instância de VM. Inclua a sinalização --disk-scope e defina-a como regional.

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

Substitua:

  • VM_NAME: o nome da nova instância de VM na região;
  • DISK_NAME: o nome do disco.

Depois de force-attach o disco, ative os sistemas de arquivos no disco se necessário. A instância de VM pode usar o disco de anexação forçada para continuar as operações de leitura e gravação.

REST

Crie uma solicitação POST para o método compute.instances.attachDisk e inclua o URL no disco permanente que você acabou de criar. Para anexar o disco à nova instância de VM, o parâmetro de consulta forceAttach=true é necessário, mesmo que a instância de VM primária ainda tenha o disco.

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"
}

Substitua:

  • PROJECT_ID: ID do projeto
  • ZONE: o local da instância de VM.
  • VM_NAME: o nome da instância da VM em que você está adicionando o novo volume do disco permanente.
  • REGION: a região em que o novo disco permanente regional está localizado;
  • DISK_NAME: o nome do novo disco

Depois de anexar o disco de réplica, ative os sistemas de arquivos nos discos se necessário. A instância de VM pode usar o disco de réplica para continuar as operações de leitura e gravação.

Use o checkpoint de recuperação da réplica para recuperar volumes degradados do Persistent Disk regional

Um checkpoint de recuperação de réplica representa o ponto no tempo de falha mais recente de um volume de disco permanente regional totalmente replicado. O Compute Engine permite criar snapshots padrão do checkpoint de recuperação da réplica para discos degradados.

Em cenários raros, quando o disco sofre degradação, a réplica zonal que é sincronizada com os dados mais recentes do disco também pode falhar antes que a réplica fora de sincronia alcance a conexã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 poderá recuperar os dados do disco da réplica incompleta usando um snapshot padrão criado a partir do ponto de verificação de recuperação de réplica. Consulte Procedimento para migrar e recuperar dados do disco para ver as etapas detalhadas.

Funções exigidas

Para receber as permissões necessárias para migrar dados do Persistent Disk regional usando um checkpoint de recuperação de réplica, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

Esses papéis predefinidos contêm as permissões necessárias para migrar dados do Persistent Disk regional 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:

Permissões necessárias

As permissões a seguir são necessárias para migrar dados do Persistent Disk regional usando um checkpoint de recuperação de réplica:

  • Para criar um snapshot padrão do checkpoint de recuperação da réplica:
    • compute.snapshots.create no projeto
    • compute.disks.createSnapshot no disco
  • Para criar um novo disco permanente regional a partir do snapshot padrão: compute.disks.create no projeto em que você quer criar o novo disco
  • Para migrar VMs para o novo disco:
    • compute.instances.attachDisk na instância de VM
    • compute.disks.use permission no disco recém-criado

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

Procedimento para migrar e recuperar dados do disco

Para recuperar e migrar os dados de um volume de Persistent Disk regional usando o checkpoint de recuperação de réplica, execute as seguintes etapas:

  1. Crie um snapshot padrão do volume do Persistent Disk regional afetado no checkpoint de recuperação de réplica. Só é possível criar o snapshot padrão de um disco a partir do checkpoint de recuperação de réplica usando a Google Cloud 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 PADRÃO 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 PADRÃO 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 novo volume de disco permanente regional usando este snapshot. Ao criar o novo disco, você recupera todos os dados do checkpoint de recuperação de réplica mais recente movendo os dados para o novo disco. Para ver as etapas detalhadas, consulte Criar uma nova VM com discos de inicialização de disco permanente regionais.

  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 volume de disco permanente regional recém-criado, será possível retomar suas operações.

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

Nesta seção, explicamos como determinar o RPO fornecido pelo checkpoint de recuperação de réplica mais recente de um volume de disco permanente regional.

As réplicas zonais estão totalmente sincronizadas

O Compute Engine atualiza o ponto de verificação de recuperação de réplica do volume de disco permanente regional 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 conseguir essas informações usando os dados regionais do Cloud Monitoring do Persistent Disk para a métrica replica_state. Verifique os dados de métrica replica_state da réplica fora de sincronização para determinar quando a réplica saiu de sincronização. À medida que 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 mais recente da operação de gravação: é possível conseguir essas informações usando os dados do Cloud Monitoring do disco permanente para a métrica write_ops_count. Verifique os dados de métricas 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