Nesta página, mostramos 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. Esses dados replicados podem ser usados em um cenário de failover caso os dados na zona de origem estejam indisponíveis. Depois que um failover é criado, não é possível configurar o volume original para replicar no 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.
Depois, verifique se você 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.
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.
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 não estiver disponí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 uma VolumeReplicationRelationship foi criada especificando xx-xxxx-zone2 como a zona de destino e o PVC existe 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 VolumeReplicationRelationship my-pvc-repl 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.