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
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- 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.
Install the Google Cloud CLI, then initialize it by running the following command:
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 |
|
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 |
|
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 |
|
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 |
|
|
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 |
|
|
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) |
|
O plano de controle do aplicativo pode acionar o failover com base nos limites da verificação de integridade. |
Falha na VM (média) |
|
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
Acesse a página Instâncias da VM.
Selecione o projeto.
Clique no nome da VM que você quer alterar.
Na página de detalhes, clique em Editar.
Na seção Discos extras, clique em Anexar disco extra.
Selecione o disco permanente regional na lista suspensa.
Para forçar a anexação do disco, marque a caixa de seleção Forçar anexação de disco.
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 projetoZONE
: 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 migrar dados do Persistent Disk regional usando um checkpoint de recuperação de réplica:
Administrador de instâncias do Compute (v1) (
roles/compute.instanceAdmin.v1
) no projeto
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
compute.disks.createSnapshot
-
-
Para criar um novo disco permanente regional a partir do snapshot padrão:
compute.disks.create
-
Para migrar VMs para o novo disco:
compute.instances.attachDisk
-
compute.disks.use permission
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:
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étodosnapshots.insert
. Exclua o parâmetrosourceDisk
e inclua o parâmetrosourceDiskForRecoveryCheckpoint
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âmetrostorageLocations
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.
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.
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étricareplica_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étricaswrite_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 da réplica de volumes regionais de disco permanente.
- Saiba como determinar o estado de replicação do disco permanente regional.
- Saiba como criar um snapshot de um volume de Persistent Disk regional.
- Saiba como criar serviços de alta disponibilidade usando o Persistent Disk regional.
- Saiba como criar aplicativos da Web escalonáveis e resilientes no Google Cloud.
- Consulte o guia de planejamento de recuperação de desastres.