Gerenciar falhas em discos regionais

O Disco permanente regional e o Hyperdisk Balanced High Availability são opções de armazenamento que fornecem replicação síncrona de dados entre duas zonas em uma região. É possível usar o Persistent Disk regional ou o Hyperdisk Balanced High Availability como elemento básico ao implementar serviços de alta disponibilidade (HA) no Compute Engine.

Neste documento, explicamos os vários cenários que podem interromper o funcionamento dos discos regionais e como gerenciar esses cenários.

Antes de começar

  • Analise os conceitos básicos sobre discos regionais e failover. 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 selecionando uma das seguintes opções:

    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.

      3. 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 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 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 disco regionais 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 de disco 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 disco regional a partir do snapshot padrão: compute.disks.create no projeto em que você quer criar o 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.

Cenários de falha

Com os discos 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 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 um estado degradado, recomendamos fazer backup dos discos regionais 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 regionais 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.

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 discos 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ções incorretas da VM, falha no upgrade do SO ou outras falhas do aplicativo, é possível force-attach o disco regional em uma instância de computação na mesma zona que a réplica íntegra.

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 de um disco regional 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 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 grave no disco regional. 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:

Console

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

    Acessar instâncias de VM

  2. Selecione o projeto.

  3. Clique no nome da instância a ser modificada.

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

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

  6. Selecione o disco regional ou replicado de forma síncrona 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 resolução da falha, é possível seguir as mesmas etapas para force-attach um disco na instância de computação original.

gcloud

Na gcloud CLI, use o comando instances attach-disk para anexar o disco de réplica a uma instância de computação. 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 computação na região.
  • DISK_NAME: o nome do disco regional

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

REST

Crie uma solicitação POST para o método compute.instances.attachDisk e inclua o URL do disco regional que você acabou de criar. Para anexar o disco à nova instância de computação, o parâmetro de consulta forceAttach=true será necessário se a instância de computação principal ainda tiver o disco anexado.

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 computação
  • VM_NAME: o nome da instância de computação em que você está adicionando o disco regional.
  • REGION: a região em que o disco regional está localizado.
  • DISK_NAME: o nome do disco regional

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

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 regional, use um dos seguintes métodos, de acordo com a existência ou não da instância de computação secundária:

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

Um checkpoint de recuperação de réplica representa o ponto no tempo de falha mais recente de um volume totalmente replicado do Persistent Disk regional ou do Hyperdisk Balanced High Availability. 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 regional usando o checkpoint de recuperação de réplica, siga estas etapas:

  1. Crie um snapshot padrão do volume do Persistent Disk regional ou do Hyperdisk Balanced High Availability afetado 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 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 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 nova instância com um disco de inicialização regional.

  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.

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 regional. 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 regional. 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