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 replicação no mesmo volume de destino. Em alternativa, tem de ser criada 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) tem de configurar primeiro a infraestrutura de armazenamento entre as duas zonas nas quais a replicação é necessária. Especificamente, têm de estabelecer ligação ponto a ponto com os 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 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:
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.
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 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
Caso a zona de origem não esteja disponível por qualquer motivo, pode ser criado um CR VolumeFailover 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 foi criada uma VolumeReplicationRelationship que especifica xx-xxxx-zone2 como a zona de destino e existe 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 o 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.