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. Note que, 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.

Antes de começar

Para usar a replicação de blocos assíncrona, o operador de infraestrutura (IO) precisa primeiro configurar a infraestrutura de armazenamento entre as duas zonas em que a replicação é necessária. Especificamente, primeiro é necessário fazer o peering dos clusters de armazenamento relevantes de cada zona. Em seguida, é preciso fazer peering com a máquina virtual de armazenamento associada à organização em que o armazenamento em blocos é provisionado.

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 CR 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 o 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 assíncrona de blocos 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 permanece somente leitura e não pode 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 fique 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 o 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 em algum momento 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 de VM ou Expandir capacidade de 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 não estiver disponí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.