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.

Antes de começar

Para ativar a replicação de blocos assíncrona entre duas zonas, o operador de infraestrutura (IO) tem de estabelecer primeiro a infraestrutura de armazenamento necessária através da interligação dos clusters de armazenamento relevantes de cada zona. Em seguida, tem de estabelecer uma relação de intercâmbio com a máquina virtual de armazenamento associada à organização na qual o armazenamento em blocos é aprovisionado.

Depois, certifique-se de que 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 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:

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

Este exemplo pressupõe que um projeto denominado my-project é criado numa organização denominada my-org e que já foi aprovisionado um PVC denominado my-block-pvc. O clusterRef é o nome do cluster no qual o PVC existe.

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

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.

Verifique o estado da relação de replicação obtendo o CR da API global.VolumeReplicationRelationship Consulte o exemplo seguinte. Tenha em atenção 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

Crie uma comutação por falha

Se a zona de origem estiver indisponível por qualquer motivo, é possível 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 xx-xxxx-zone2 como a zona de destino e existir um PVC na organização my-org, o CR VolumeFailover é criado no plano de gestão my-org em xx-xxxx-zone2. Isto interrompe a relação de replicação entre as duas zonas e permite que o PVC na zona de destino seja montado 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

Posteriormente, uma comutação por falha bem-sucedida reflete-se no estado 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

Após a criação da comutação por falha, o my-pvc-repl VolumeReplicationRelationship passa para um estado Broken Off. O PVC em xx-xxxx-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:

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, pode eliminar a VolumeReplicationRelationship em segurança, uma vez que é a única ação restante que pode ser realizada neste CR.

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 é criada uma VolumeReplicatioRelationship, também deve ser redimensionado para corresponder.

Replique discos de máquinas virtuais

VolumeReplicationRelationship também serve a 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.

Peça 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 reside o disco da VM.

Para operações de VMs 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 leitor do projeto (project-viewer).

Inicie a replicação assíncrona

Inicie a replicação assíncrona num disco de VM através do 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 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

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 o seguinte:

Variável	Definição
GLOBAL_MANAGEMENT_API	O ficheiro kubeconfig para o servidor da API de gestão global.
VRR_NAME	O nome da relação de replicação de volumes. Tem de usar o mesmo nome quando parar a replicação assíncrona.
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.
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.

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

Apresenta relações de replicação assíncronas num projeto através de kubectl.

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

Substitua o seguinte:

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

O resultado terá o seguinte aspeto:

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 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. Elimine cada uma das relações de replicação de volume indicadas no passo anterior. Substitua VRR_NAMES pelos nomes das relações de replicação de volumes.

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

   Substitua o seguinte:

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