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
.
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
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'
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.