Replique volumes de forma assíncrona

Esta página descreve como configurar e realizar a replicação assíncrona de volumes de armazenamento de blocos isolados do Google Distributed Cloud (GDC).

A replicação assíncrona é usada para replicar dados de uma zona do GDC para outra. Os dados replicados podem ser usados para a comutação por falha se os dados da zona de origem ficarem indisponíveis. Tenha em atenção que, depois de criar uma alternativa, não é possível replicar o volume original para o mesmo volume de destino. Em alternativa, tem de ser criada uma nova relação de replicação.

Para os administradores da plataforma que gerem PVCs através da API KRM, consulte o artigo Replique volumes de forma assíncrona.

Antes de começar

Para usar a replicação de blocos assíncrona, o operador de infraestrutura (IO) tem de configurar primeiro duas zonas para a replicação assíncrona.

Em seguida, certifique-se de que tem a função app-volume-replication-admin-global para administrar o recurso VolumeReplicationRelationship. Nos casos em que a API global não está disponível, a função volume-replication-admin pode ser usada para modificar diretamente o recurso zonal VolumeReplicationRelationshipReplica.

Configure a replicação

O recurso personalizado (CR) VolumeReplicationRelationship serve a API de replicação de blocos assíncrona. Esta CR existe na API de gestão global. Para ativar a replicação para um determinado dispositivo de bloco, tem de criar um CR VolumeReplicationRelationship na API de gestão global:

API PVC de replicação

Nota: a associação de projetos é obrigatória. Certifique-se de que associou o seu projeto a cada recurso de cluster em cada zona participante.

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    pvc:
      clusterRef: SOURCE_USER_CLUSTER_NAME
      pvcRef: PVC_NAME
    zoneRef: SOURCE_ZONE_NAME
destination:
    pvc:
      clusterRef: DESTINATION_USER_CLUSTER_NAME
    zoneRef: DESTINATION_ZONE_NAME
EOF

Substitua o seguinte:

• MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
• VRR_NAME: o nome do recurso VolumeReplicationRelationship.
• PROJECT: o espaço de nomes do recurso Project.
• SOURCE_USER_CLUSTER_NAME: o nome do recurso de cluster do utilizador de origem a ser associado.
• PVC_NAME: o nome do recurso PersistentVolumeClaim.
• SOURCE_ZONE_NAME: o nome do recurso de zona de origem.
• DESTINATION_USER_CLUSTER_NAME: o nome do recurso de cluster do utilizador de destino a ser associado.
• DESTINATION_ZONE_NAME: o nome do recurso da zona de destino.

Este exemplo pressupõe que é criado um projeto com o nome PROJECT numa organização com o nome my-org e que já foi aprovisionado um PVC com o nome PVC_NAME. SOURCE_USER_CLUSTER_NAME é o nome do cluster de origem no qual o PVC existe e DESTINATION_USER_CLUSTER_NAME é o nome do cluster de destino no qual vai existir um novo PVC.

Os campos source e destination da especificação indicam a origem de e o destino para, respetivamente, da replicação dos dados. Neste exemplo, os dados são replicados de SOURCE_ZONE_NAME para DESTINATION_ZONE_NAME.

Nota: o serviço de replicação de blocos assíncrono cria automaticamente um PVC na zona de destino para escrever os dados replicados. Por predefinição, este PVC tem o mesmo nome que o PVC de origem. No entanto, pode usar o campo volumeOverrideName para especificar o nome do PVC criado. No entanto, até ser criado um VolumeReplicationFailover, o PVC de destino permanece só de leitura e não pode ser montado por nenhuma carga de trabalho.

Replique discos de máquinas virtuais

O VolumeReplicationRelationship também presta serviços à API de replicação assíncrona de discos de máquinas virtuais (discos de VMs). O disco de origem que está a ser replicado chama-se disco principal. O disco de destino para o qual está a ser feita a replicação chama-se disco secundário. O início da replicação assíncrona num disco principal cria automaticamente o disco secundário.

Pedir autorizações e acesso

Para replicar discos de máquinas virtuais, tem de ter a função de administrador de máquinas virtuais do projeto. Siga os passos para confirmar que tem a função de administrador de máquinas virtuais do projeto (project-vm-admin) no espaço de nomes do projeto onde reside o disco da VM.

Para operações de máquinas virtuais com a CLI gdcloud, peça ao administrador de IAM do projeto para lhe atribuir a função de administrador de máquinas virtuais do projeto e a função de visualizador do projeto (project-viewer).

gdcloud

gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE \
  --secondary-disk SECONDARY_DISK_NAME --secondary-zone SECONDARY_ZONE

Substitua o seguinte:

Variável	Definição
PRIMARY_DISK_NAME	O nome do disco de origem que está a ser replicado.
PROJECT	O projeto do GDC do disco principal.
PRIMARY_ZONE	A zona onde o disco principal reside.
SECONDARY_DISK_NAME	O nome do disco de destino para o qual replicar.
SECONDARY_ZONE	A zona onde o disco secundário tem de residir.

API VM Disk

Inicie a replicação assíncrona

Inicie a replicação assíncrona num disco de VM com kubectl.

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  destination:
    volumeOverrideName: VIRTUAL_MACHINE_DESTINATION_DISK_NAME
    zoneRef: DESTINATION_ZONE_NAME
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: VIRTUAL_MACHINE_SOURCE_DISK_NAME
    zoneRef: SOURCE_ZONE_NAME
EOF

Substitua o seguinte:

• MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
• VRR_NAME: o nome do recurso VolumeReplicationRelationship.
• PROJECT: o espaço de nomes do recurso Project.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: o nome do recurso VirtualMachineDisk no destino.
• DESTINATION_ZONE_NAME: o nome do recurso da zona de destino.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: o nome do recurso VirtualMachineDisk na origem.
• SOURCE_ZONE_NAME: o nome do recurso de zona de origem.

Este exemplo pressupõe que um projeto com o nome PROJECT é criado numa organização com o nome my-org e que um VirtualMachineDisk com o nome VIRTUAL_MACHINE_SOURCE_DISK_NAME já foi aprovisionado para o recurso VirtualMachine.

Os campos source e destination da especificação indicam a origem de e o destino para da replicação dos dados, respetivamente. Neste exemplo, os dados são replicados de SOURCE_ZONE_NAME para DESTINATION_ZONE_NAME.

Nota: o serviço de replicação de blocos assíncrono cria automaticamente um VirtualMachineDisk na zona de destino para escrever os dados replicados. Por predefinição, este VirtualMachineDisk tem o mesmo nome que o VirtualMachineDisk de origem. No entanto, pode usar o campo volumeOverrideName para especificar o nome do VirtualMachineDisk criado. No entanto, até ser criado um VolumeReplicationFailover, o VirtualMachineDisk de destino permanece só de leitura e não pode ser montado por nenhuma carga de trabalho.

Validação

Verifique o estado da relação de replicação obtendo o VolumeReplicationRelationship CR da API global. Consulte o exemplo seguinte. Tenha em atenção que o resultado foi truncado para simplificação:

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
        -n PROJECT -o yaml

O resultado é semelhante ao seguinte:

API PVC

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been established. Please check the destination
        zone for relationship state
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Established
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been successfully established
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Idle

API VM Disk

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been established. Please check the destination
        zone for relationship state
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Established
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been successfully established
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Idle

Crie uma comutação por falha

Caso a zona de origem esteja indisponível por qualquer motivo, pode criar um VolumeFailover CR no plano de gestão da organização da zona de destino. Para uma organização v2, este seria o servidor da API de gestão. Para uma organização v1, este seria o cluster de administrador da organização. Por exemplo, se for criado um VolumeReplicationRelationship que especifique zone2 como a zona de destino e existir um PVC ou VirtualMachineDisk na organização my-org, o CR VolumeFailover é criado no plano de gestão my-org em zone2. Isto interrompe a relação de replicação entre as duas zonas e permite que uma carga de trabalho monte o PVC ou o VirtualMachineDisk na zona de destino:

  kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
  apiVersion: storage.gdc.goog/v1
  kind: VolumeFailover
  metadata:
    name: FAILOVER_NAME
    namespace: PROJECT
  spec:
    volumeReplicationRelationshipRef: VRR_NAME
  EOF

Substitua o seguinte:

• FAILOVER_NAME: o nome do recurso VolumeFailover.
• MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
• VRR_NAME: o nome do recurso VolumeReplicationRelationship.
• PROJECT: o espaço de nomes do recurso Project.

Posteriormente, uma comutação por falha bem-sucedida reflete-se no estado do CR:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumefailover FAILOVER_NAME \
          -n PROJECT -o yaml

• O resultado é semelhante ao seguinte:

  apiVersion: storage.gdc.goog/v1
  kind: VolumeFailover
  metadata:
    name: my-failover
    namespace: my-project
  spec:
    volumeReplicationRelationshipRef: my-vrr-repl
  status:
      state: Completed
  

• Após a criação da comutação por falha, o my-vrr-repl VolumeReplicationRelationship passa para o estado Broken Off. O PVC ou o VirtualMachineDisk em zone2 já pode ser montado.

• Neste ponto, o VolumeReplicationRelationship tem um aspeto semelhante ao seguinte exemplo. Mais uma vez, este resultado foi truncado para simplificação:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
          -n PROJECT -o yaml
  

• O resultado é semelhante ao seguinte:

API PVC

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vrr-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off

API VM Disk

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off

• Agora, pode eliminar o VolumeReplicationRelationship em segurança, uma vez que é a única ação restante que pode ser realizada neste CR.

  kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationship VRR_NAME \
          -n PROJECT
  

Redimensione volumes

Se, em qualquer altura, o volume de origem for redimensionado, também tem de redimensionar o volume correspondente na zona de destino para corresponder. O volume da zona de destino é criado quando cria o VolumeReplicationRelationship.

Consulte a documentação Expanda os discos da VM ou Expanda a capacidade do volume para redimensionar o armazenamento nas zonas de origem e de destino.

Liste relações de replicação assíncronas

Liste as relações de replicação assíncronas num projeto com kubectl.

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

Substitua o seguinte:

• PROJECT: O projeto GDC do disco principal.
• MANAGEMENT_API_SERVER: o ficheiro kubeconfig para o servidor da API de gestão zonal.

O resultado tem um aspeto semelhante ao seguinte:

NAME       AGE     SOURCE ZONE   SOURCE PVC   SOURCE PVC CLUSTER   SOURCE VM DISK      DEST. ZONE   DEST. PVC CLUSTER   DEST. VOLUME OVERRIDE     STATE
my-vrr     3m21s   zone1                                           my-vm-boot-disk     zone2                            my-vm-boot-disk-replica
test-vrr   7s      zone1                                           test-vm-boot-disk   zone2

Pare a replicação assíncrona

Pare a replicação assíncrona num disco de VM principal através do gdcloud ou kubectl.

gdcloud

gdcloud compute disks stop-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE

Substitua o seguinte:

Variável	Definição
PRIMARY_DISK_NAME	O nome do disco de origem que está a ser replicado.
PROJECT	O projeto do GDC do disco principal.
PRIMARY_ZONE	A zona onde o disco principal reside.

API

1. Encontre as relações de replicação de volumes correspondentes ao disco da VM principal.

   kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships \
     -n PROJECT -o json | \
     jq -r '.items[] | select(.spec.source.virtualMachineDisk.virtualMachineDiskRef == "PRIMARY_DISK_NAME"
     and .spec.source.zoneRef == "PRIMARY_ZONE") | .metadata.name'
   

2. Elimine cada uma das relações de replicação de volumes indicadas no passo anterior. Substitua VRR_NAMES pelos nomes das relações de replicação de volumes.

   kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationships \
     -n PROJECT VRR_NAMES
   

   Substitua o seguinte:

   Variável	Definição
   MANAGEMENT_API_SERVER	O ficheiro kubeconfig para o servidor da API de gestão global.
   PROJECT	O projeto do GDC do disco principal.
   PRIMARY_DISK_NAME	O nome do disco de origem que está a ser replicado.
   PRIMARY_ZONE	A zona onde o disco principal reside.

Se a zona de origem estiver indisponível por qualquer motivo, crie uma comutação por falha de volume para parar a replicação.

Anexe o disco replicado a uma VM

Enquanto a replicação estiver ativada, não é possível anexar o disco secundário a uma VM. Depois de a replicação ser interrompida, pode anexar o disco secundário a uma VM criada recentemente ou a uma VM existente.