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. 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 ativar a replicação assíncrona de blocos entre duas zonas, o operador de infraestrutura (IO) precisa primeiro estabelecer a infraestrutura de armazenamento necessária fazendo 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.

Depois, verifique se você tem a função app-volume-replication-admin-global para administrar o recurso VolumeReplicationRelationship. Se a API global não estiver disponível, a função volume-replication-admin poderá 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:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
 destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2

Neste exemplo, presumimos que um projeto chamado my-project foi criado em uma organização chamada my-org e que um PVC chamado my-block-pvc já foi provisionado. O clusterRef é o nome do cluster em que o PVC existe.

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 xx-xxxx-zone1 para xx-xxxx-zone2.

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, o campo VolumeOverrideName pode ser usado 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.

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:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-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: xx-xxxx-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

Se a zona de origem estiver indisponível por qualquer motivo, um CR VolumeFailover poderá ser criado no plano de gerenciamento da organização da 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 xx-xxxx-zone2 como a zona de destino e o PVC existir na organização my-org, o CR VolumeFailover será criado no plano de gerenciamento my-org em xx-xxxx-zone2. Isso interrompe a relação de replicação entre as duas zonas e permite que a PVC na zona de destino seja montada por uma carga de trabalho:

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

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

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

Depois que o failover é criado, o my-pvc-repl VolumeReplicationRelationship passa para o estado Broken Off. O PVC em xx-xxxx-zone2 agora pode ser montado.

Neste ponto, o VolumeReplicationRelationship será semelhante ao exemplo a seguir. Para simplificar, a saída foi truncada:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: xx-xxxx-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, é seguro excluir o VolumeReplicationRelationship, já que é a única ação restante que pode ser feita nesse CR.

Redimensionar volumes

Se o volume de origem for redimensionado a qualquer momento, o volume correspondente na zona de destino, que é criado em nome do usuário quando uma VolumeReplicatioRelationship é criada, também será redimensionado para corresponder.

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 de VM, você precisa ter o papel de administrador de máquina virtual do projeto. Siga as etapas para verificar se você tem o papel de administrador de máquinas virtuais do projeto (project-vm-admin) no namespace do projeto em que o disco da VM reside.

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

Iniciar replicação assíncrona

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

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

kubectl --kubeconfig GLOBAL_MANAGEMENT_API \
  apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: PRIMARY_DISK_NAME
    zoneRef: PRIMARY_ZONE
  destination:
    volumeOverrideName: SECONDARY_DISK_NAME
    zoneRef: SECONDARY_ZONE
EOF

Substitua:

Variável	Definição
GLOBAL_MANAGEMENT_API	O arquivo kubeconfig do servidor da API de gerenciamento global.
VRR_NAME	O nome da relação de replicação de volume. O mesmo nome precisa ser usado ao interromper a replicação assíncrona.
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.
SECONDARY_DISK_NAME	O nome do disco de destino para replicação.
SECONDARY_ZONE	A zona em que o disco secundário precisa estar.

Listar relacionamentos de replicação assíncrona

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

kubectl --kubeconfig GLOBAL_MANAGEMENT_API get volumereplicationrelationships -n my-project

Substitua:

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

A saída será 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

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 GLOBAL_MANAGEMENT_API 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 GLOBAL_MANAGEMENT_API delete volumereplicationrelationships \
     -n PROJECT VRR_NAMES
   

   Substitua:

   Variável	Definição
   GLOBAL_MANAGEMENT_API	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.