Replica volúmenes de forma asíncrona

En esta página, se describe cómo configurar y realizar la replicación asíncrona de volúmenes de almacenamiento en bloque aislados de Google Distributed Cloud (GDC).

La replicación asíncrona se usa para replicar datos de una zona de GDC a otra. Los datos replicados se pueden utilizar para la conmutación por error si los datos de la zona de origen dejan de estar disponibles. Ten en cuenta que, una vez que se crea una conmutación por error, el volumen original no se puede replicar en el mismo volumen de destino. En su lugar, se debe crear una nueva relación de replicación.

Antes de comenzar

Para habilitar la replicación de bloques asíncrona entre dos zonas, tu operador de infraestructura (IO) primero debe establecer la infraestructura de almacenamiento necesaria intercambiando tráfico entre los clústeres de almacenamiento pertinentes de cada zona. A continuación, deben interconectar la máquina virtual de almacenamiento asociada a la organización en la que se aprovisiona el almacenamiento en bloque.

Luego, asegúrate de tener el rol app-volume-replication-admin-global para administrar el recurso VolumeReplicationRelationship. Si la API global no está disponible, se puede usar el rol volume-replication-admin para modificar directamente el recurso VolumeReplicationRelationshipReplica zonal.

Configura la replicación

El recurso personalizado (CR) VolumeReplicationRelationship presta servicios a la API de replicación de bloques asíncrona. Este CR existe en la API de administración global. Para habilitar la replicación de un dispositivo de almacenamiento en bloques determinado, se debe crear un CR de VolumeReplicationRelationship en la API de administración 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

En este ejemplo, se supone que se creó un proyecto llamado my-project en una organización llamada my-org y que ya se aprovisionó una PVC llamada my-block-pvc. clusterRef es el nombre del clúster en el que existe el PVC.

Los campos source y destination de la especificación indican desde y hacia dónde se replican los datos, respectivamente. En este ejemplo, los datos se replican de xx-xxxx-zone1 a xx-xxxx-zone2.

Nota: El servicio de replicación de bloques asíncrono crea automáticamente un PVC en la zona de destino para escribir los datos replicados. De forma predeterminada, esta PVC tiene el mismo nombre que la PVC de origen. Sin embargo, el campo VolumeOverrideName se puede usar para especificar el nombre de la PVC creada. Sin embargo, hasta que se cree un VolumeReplicationFailover, la PVC de destino seguirá siendo de solo lectura y no podrá ser activada por ninguna carga de trabajo.

Recupera el CR de VolumeReplicationRelationship de la API global para verificar el estado de la relación de replicación. Consulta el siguiente ejemplo. Ten en cuenta que el resultado se truncó para simplificarlo:

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

Crea conmutación por error

Si la zona de origen no está disponible por algún motivo, se puede crear un CR de VolumeFailover en el plano de administración de la organización de la zona de destino. En el caso de una organización de la versión 2, este sería el servidor de la API de administración. En el caso de una organización de la versión 1, este sería el clúster de administrador de la organización. Por ejemplo, si se creó un VolumeReplicationRelationship que especifica xx-xxxx-zone2 como la zona de destino y existe un PVC en la organización my-org, el CR de VolumeFailover se crea en el plano de administración de my-org en xx-xxxx-zone2. Esto interrumpe la relación de replicación entre las dos zonas y permite que una carga de trabajo monte el PVC en la zona de destino:

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

Luego, la conmutación por error exitosa se reflejará en el estado del CR:

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

Después de crear la conmutación por error, el my-pvc-repl VolumeReplicationRelationship pasa a un estado Broken Off. Ahora se puede activar el PVC en xx-xxxx-zone2.

En este punto, el VolumeReplicationRelationship se verá similar al siguiente ejemplo. De nuevo, este resultado se truncó para simplificarlo:

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

Ahora, puedes borrar VolumeReplicationRelationship de forma segura, ya que es la única acción restante que se puede realizar en este CR.

Cambia el tamaño de los volúmenes

Si en algún momento se cambia el tamaño del volumen de origen, también se debe cambiar el tamaño del volumen correspondiente en la zona de destino, que se crea en nombre del usuario cuando se crea un VolumeReplicatioRelationship, para que coincida.

Replica discos de máquina virtual

VolumeReplicationRelationship también presta servicios a la API de replicación asíncrona de discos de máquina virtual (discos de VM). El disco de origen que se replica se denomina disco principal. El disco de destino en el que se realiza la replicación se denomina disco secundario. Si inicias la replicación asíncrona en un disco principal, se creará automáticamente el disco secundario.

Solicita permisos y acceso

Para replicar discos de VM, debes tener el rol de administrador de máquinas virtuales del proyecto. Sigue los pasos para verificar que tienes el rol de administrador de Project VirtualMachine (project-vm-admin) en el espacio de nombres del proyecto en el que reside el disco de la VM.

Para las operaciones de VM con la CLI de gdcloud, solicita a tu administrador de IAM del proyecto que te asigne el rol de administrador de máquinas virtuales del proyecto y el rol de visualizador del proyecto (project-viewer).

Cómo iniciar la replicación asíncrona

Inicia la replicación asíncrona en un disco de VM con gdcloud o 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

Reemplaza lo siguiente:

Variable	Definición
PRIMARY_DISK_NAME	Nombre del disco de origen que se replica.
PROJECT	Es el proyecto de GDC del disco principal.
PRIMARY_ZONE	Es la zona en la que reside el disco principal.
SECONDARY_DISK_NAME	Nombre del disco de destino en el que se replicará.
SECONDARY_ZONE	Es la zona en la que debe residir el disco secundario.

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

Reemplaza lo siguiente:

Variable	Definición
GLOBAL_MANAGEMENT_API	Archivo kubeconfig para el servidor de la API de administración global.
VRR_NAME	Es el nombre de la relación de replicación del volumen. Se debe usar el mismo nombre cuando se detiene la replicación asíncrona.
PROJECT	Es el proyecto de GDC del disco principal.
PRIMARY_DISK_NAME	Nombre del disco de origen que se replica.
PRIMARY_ZONE	Es la zona en la que reside el disco principal.
SECONDARY_DISK_NAME	Nombre del disco de destino en el que se replicará.
SECONDARY_ZONE	Es la zona en la que debe residir el disco secundario.

Enumera las relaciones de replicación asíncrona

Enumera las relaciones de replicación asíncrona en un proyecto con kubectl.

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

Reemplaza lo siguiente:

• PROJECT: Es el proyecto de GDC del disco principal.
• GLOBAL_MANAGEMENT_API: Es el archivo kubeconfig del servidor de la API de administración global.

El resultado se verá así:

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

Detener la replicación asíncrona

Detén la replicación asíncrona en un disco de VM principal con gdcloud o kubectl.

gdcloud

gdcloud compute disks stop-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE

Reemplaza lo siguiente:

Variable	Definición
PRIMARY_DISK_NAME	Nombre del disco de origen que se replica.
PROJECT	Es el proyecto de GDC del disco principal.
PRIMARY_ZONE	Es la zona en la que reside el disco principal.

API

1. Busca las relaciones de replicación de volúmenes correspondientes al disco de la 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. Borra cada una de las relaciones de replicación de volúmenes que se enumeran en el paso anterior. Reemplaza VRR_NAMES por los nombres de las relaciones de replicación de volúmenes.

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

   Reemplaza lo siguiente:

   Variable	Definición
   GLOBAL_MANAGEMENT_API	Archivo kubeconfig para el servidor de la API de administración global.
   PROJECT	Es el proyecto de GDC del disco principal.
   PRIMARY_DISK_NAME	Nombre del disco de origen que se replica.
   PRIMARY_ZONE	Es la zona en la que reside el disco principal.

Si la zona de origen no está disponible por algún motivo, crea una conmutación por error del volumen para detener la replicación.

Conecta el disco replicado a una VM

Mientras la replicación está habilitada, el disco secundario no se puede conectar a una VM. Después de que se detiene la replicación, puedes conectar el disco secundario a una VM recién creada o a una VM existente.