Replique volumes de forma assíncrona

Esta página mostra 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. Estes dados replicados podem ser usados num cenário de comutação por falha caso os dados na zona de origem não estejam disponíveis. Tenha em atenção que, depois de criar uma comutação por falha, não é possível configurar o volume original para replicar para o mesmo volume de destino. Em alternativa, tem de ser criada uma nova relação de replicação.

Para os operadores de aplicações que preferem usar a CLI gdcloud, consulte o artigo Replique volumes de forma assíncrona.

Antes de começar

Para usar a replicação de blocos assíncrona, o seu 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 volume-replication-admin-global para administrar o recurso VolumeReplicationRelationship. Nos casos em que a API global não está disponível, a função app-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

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 um projeto com o nome PROJECT é criado 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 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 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, o campo VolumeOverrideName pode ser usado 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.

API VM Disk

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 que está a ser replicado é denominado 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 VMs, tem de ter a função de administrador de máquinas virtuais do projeto. Siga os passos para validar que tem a função de administrador de máquinas virtuais do projeto (project-vm-admin) no espaço de nomes do projeto onde o disco da VM reside.

Para operações de VM 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).

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.
• SOURCE_ZONE_NAME: o nome do recurso de zona de origem.
• DESTINATION_ZONE_NAME: o nome do recurso da zona de destino.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: o nome do recurso VirtualMachineDisk na origem.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: o nome do recurso VirtualMachineDisk no destino.

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, o campo volumeOverrideName pode ser usado 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 CR VolumeReplicationRelationship 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 o PVC ou o VirtualMachineDisk na zona de destino seja montado por uma carga de trabalho:

  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, o volume correspondente na zona de destino, que é criado em nome do utilizador quando é criado um VolumeReplicationRelationship, também deve ser redimensionado para corresponder.

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.