Replicar volumes de forma assíncrona

Nesta página, descrevemos como configurar e realizar a replicação assíncrona de volumes de armazenamento em 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 failover se os dados da zona de origem ficarem indisponíveis. Observação: Depois que um failover é criado, o volume original não pode ser replicado para o mesmo volume de destino. Em vez disso, é preciso criar uma nova relação de replicação.

Para administradores da plataforma que gerenciam PVCs usando a API KRM, consulte Replicar volumes de forma assíncrona.

Antes de começar

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

Em seguida, verifique se você 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".

Configurar a replicação

O recurso personalizado (CR) VolumeReplicationRelationship atende à API de replicação de blocos assíncrona. Essa resposta automática existe na API global de gerenciamento. Para ativar a replicação de um determinado dispositivo de transferência por blocos, é necessário criar um CR VolumeReplicationRelationship na API de gerenciamento global:

API Replicate PVC

Observação: a vinculação de projeto é obrigatória. Verifique se você anexou 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:

• MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
• VRR_NAME: o nome do recurso VolumeReplicationRelationship.
• PROJECT: o namespace do recurso "Project".
• SOURCE_USER_CLUSTER_NAME: o nome do recurso de cluster de usuário de origem a ser conectado.
• 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 de usuário de destino a ser conectado.
• DESTINATION_ZONE_NAME: o nome do recurso de zona de destino.

Neste exemplo, presumimos que um projeto chamado PROJECT foi criado em uma organização chamada my-org e que um PVC chamado PVC_NAME já foi provisionado. O SOURCE_USER_CLUSTER_NAME é o nome do cluster de origem em que a PVC existe, e DESTINATION_USER_CLUSTER_NAME é o nome do cluster de destino em que uma nova PVC vai existir.

Os campos source e destination da especificação indicam de onde e para onde os dados estão sendo replicados, respectivamente. Neste exemplo, os dados são replicados de SOURCE_ZONE_NAME para DESTINATION_ZONE_NAME.

Observação: o serviço de replicação de blocos assíncrona cria automaticamente uma PVC na zona de destino para gravar os dados replicados. Por padrão, esse PVC tem o mesmo nome do PVC de origem. No entanto, é possível usar o campo volumeOverrideName para especificar o nome do PVC criado. No entanto, até que um VolumeReplicationFailover seja criado, a PVC de destino vai permanecer somente leitura e não poderá ser montada por nenhuma carga de trabalho.

Replicar discos de máquina virtual

O VolumeReplicationRelationship também atende à API de replicação assíncrona de disco de máquina virtual (disco de VM). O disco de origem que está sendo replicado é chamado de disco principal. O disco de destino que está sendo replicado é chamado de disco secundário. Ao iniciar a replicação assíncrona em um disco principal, o disco secundário é criado automaticamente.

Solicitar permissões e acesso

Para replicar discos máquina virtual, você precisa ter o papel de administrador de máquinas virtuais do projeto. Siga as etapas para verificar se você tem o papel de administrador de máquina virtual do projeto (project-vm-admin) no namespace do projeto em que o disco da VM está localizado.

Para operações de máquina virtual usando a CLI gdcloud, peça ao administrador do IAM do projeto para atribuir a você o papel de administrador de máquina virtual do projeto e o papel de leitor 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:

Variável	Definição
PRIMARY_DISK_NAME	O nome do disco de origem que está sendo replicado.
PROJECT	O projeto do GDC do disco principal.
PRIMARY_ZONE	A zona em que o disco principal reside.
SECONDARY_DISK_NAME	O nome do disco de destino para replicação.
SECONDARY_ZONE	A zona em que o disco secundário precisa estar.

API VM Disk

Iniciar replicação assíncrona

Inicie a replicação assíncrona em um disco de VM usando 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:

• MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
• VRR_NAME: o nome do recurso VolumeReplicationRelationship.
• PROJECT: o namespace do recurso "Project".
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: o nome do recurso VirtualMachineDisk no destino.
• DESTINATION_ZONE_NAME: o nome do recurso de 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.

Neste exemplo, presumimos que um projeto chamado PROJECT foi criado em uma organização chamada my-org e que um VirtualMachineDisk chamado VIRTUAL_MACHINE_SOURCE_DISK_NAME já foi provisionado para o recurso VirtualMachine.

Os campos source e destination da especificação indicam de onde e para onde os dados estão sendo replicados, respectivamente. Neste exemplo, os dados são replicados de SOURCE_ZONE_NAME para DESTINATION_ZONE_NAME.

Observação: o serviço de replicação de blocos assíncrona cria automaticamente um VirtualMachineDisk na zona de destino para gravar os dados replicados. Por padrão, esse VirtualMachineDisk tem o mesmo nome do VirtualMachineDisk de origem. No entanto, é possível usar o campo volumeOverrideName para especificar o nome do VirtualMachineDisk criado. No entanto, até que um VolumeReplicationFailover seja criado, o VirtualMachineDisk de destino vai permanecer somente leitura e não poderá ser montado por nenhuma carga de trabalho.

Verificação

Verifique o status da relação de replicação recuperando o CR VolumeReplicationRelationship da API global. Confira o exemplo a seguir. Observe que a saída foi truncada para simplificação:

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

O resultado será o 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

Criar failover

Caso a zona de origem esteja indisponível por qualquer motivo, um CR VolumeFailover poderá ser criado no plano de gerenciamento da organização na zona de destino. Para uma organização v2, esse seria o servidor da API de gerenciamento. Para uma organização v1, esse seria o cluster de administrador da organização. Por exemplo, se um VolumeReplicationRelationship foi criado especificando zone2 como a zona de destino e um PVC ou VirtualMachineDisk existe na organização my-org, o CR VolumeFailover será criado no plano de gerenciamento my-org em zone2. Isso interrompe a relação de replicação entre as duas zonas e permite que uma carga de trabalho monte a PVC ou 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:

• 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 namespace do recurso "Project".

Depois, um failover bem-sucedido é refletido no status do CR:

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

• O resultado será o seguinte:

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

• Depois que o failover é criado, o my-vrr-repl VolumeReplicationRelationship passa para o estado Broken Off. O PVC ou VirtualMachineDisk em zone2 agora pode ser montado.

• Neste ponto, o VolumeReplicationRelationship será semelhante ao exemplo a seguir. De novo, essa saída foi truncada para simplificação:

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

• O resultado será o 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 você pode excluir o VolumeReplicationRelationship com segurança, porque é a única ação restante que pode ser feita nesse CR.

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

Redimensionar volumes

Se o volume de origem for redimensionado, você também precisará redimensionar o volume correspondente na zona de destino para que eles fiquem iguais. O volume da zona de destino é criado quando você cria o VolumeReplicationRelationship.

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

Listar relacionamentos de replicação assíncrona

Liste as relações de replicação assíncrona em um projeto usando kubectl.

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

Substitua:

• PROJECT: o projeto do GDC do disco principal.
• MANAGEMENT_API_SERVER: o arquivo kubeconfig do servidor da API de gerenciamento zonal.

A saída será assim:

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

Parar a replicação assíncrona

Interrompa a replicação assíncrona em um disco de VM principal usando gdcloud ou kubectl.

gdcloud

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

Substitua:

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

API

1. Encontre as relações de replicação de volume 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. Exclua cada uma das relações de replicação de volume listadas na etapa anterior. Substitua VRR_NAMES pelos nomes das relações de replicação de volume.

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

   Substitua:

   Variável	Definição
   MANAGEMENT_API_SERVER	O arquivo kubeconfig do servidor da API de gerenciamento global.
   PROJECT	O projeto do GDC do disco principal.
   PRIMARY_DISK_NAME	O nome do disco de origem que está sendo replicado.
   PRIMARY_ZONE	A zona em que o disco principal reside.

Se a zona de origem estiver indisponível por qualquer motivo, crie um failover de volume para interromper a replicação.

Anexar o disco replicado a uma VM

Enquanto a replicação está ativada, o disco secundário não pode ser anexado a uma VM. Depois que a replicação for interrompida, você poderá anexar o disco secundário a uma VM recém-criada ou a uma VM existente.