Replicar 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 bloques de Google Distributed Cloud (GDC) aislado.

La replicación asíncrona se usa para replicar datos de una zona de GDC a otra. Los datos replicados se pueden usar 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 haya creado una conmutación por error, el volumen original no se podrá replicar en el mismo volumen de destino. En su lugar, se debe crear una nueva relación de replicación.

Para los administradores de plataformas que gestionan PVCs mediante la API de KRM, consulta Replicar volúmenes de forma asíncrona para administradores de plataformas.

Antes de empezar

Para usar la replicación de bloques asíncrona, tu operador de infraestructura (IO) debe configurar primero dos zonas para la replicación asíncrona.

A continuación, asegúrate de que tienes el rol app-volume-replication-admin-global para administrar el recurso VolumeReplicationRelationship. En los casos en los que la API global no esté disponible, se puede usar el rol volume-replication-admin para modificar directamente el recurso VolumeReplicationRelationshipReplica de zona.

Configurar la replicación

El recurso personalizado (CR) VolumeReplicationRelationship ofrece la API de replicación de bloques asíncrona. Este CR existe en la API Management global. Para habilitar la replicación en un dispositivo de bloques determinado, se debe crear un recurso personalizado VolumeReplicationRelationship en la API de gestión global:

API Replicate PVC

Nota: Es obligatorio vincular el proyecto. Asegúrate de que has vinculado tu proyecto a cada recurso de clúster de cada zona participante.

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    pvc:
      clusterRef: SOURCE_USER_CLUSTER_NAME
      pvcRef: PVC_NAME
    zoneRef: SOURCE_ZONE_NAME
  destination:
    pvc:
      clusterRef: DESTINATION_USER_CLUSTER_NAME
    zoneRef: DESTINATION_ZONE_NAME
EOF

Haz los cambios siguientes:

• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API de zona.
• VRR_NAME: el nombre del recurso VolumeReplicationRelationship.
• PROJECT: el espacio de nombres del recurso de proyecto.
• SOURCE_USER_CLUSTER_NAME: el nombre del recurso de clúster del usuario de origen que se va a conectar.
• PVC_NAME: el nombre del recurso PersistentVolumeClaim.
• SOURCE_ZONE_NAME: el nombre del recurso de zona de origen.
• DESTINATION_USER_CLUSTER_NAME: el nombre del recurso de clúster de usuario de destino que se va a conectar.
• DESTINATION_ZONE_NAME: el nombre del recurso de zona de destino.

En este ejemplo, se presupone que se ha creado un proyecto llamado PROJECT en una organización llamada my-org y que ya se ha aprovisionado un PVC llamado PVC_NAME. SOURCE_USER_CLUSTER_NAME es el nombre del clúster de origen en el que se encuentra la PVC y DESTINATION_USER_CLUSTER_NAME es el nombre del clúster de destino en el que se creará una nueva PVC.

Los campos source y destination de la especificación indican desde dónde y hacia dónde se están replicando los datos, respectivamente. En este ejemplo, los datos se replican de SOURCE_ZONE_NAME a DESTINATION_ZONE_NAME.

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, este PVC tiene el mismo nombre que el PVC de origen. Sin embargo, puedes usar el campo volumeOverrideName para especificar el nombre del PVC creado. Sin embargo, hasta que se cree un VolumeReplicationFailover, la PVC de destino seguirá siendo de solo lectura y no se podrá montar en ninguna carga de trabajo.

Replicar discos de máquinas virtuales

VolumeReplicationRelationship también ofrece la API de replicación asíncrona de discos de máquinas virtuales (discos de VMs). El disco de origen que se replica se denomina "disco principal". El disco de destino en el que se replica se denomina "disco secundario". Al iniciar la replicación asíncrona en un disco principal, se crea automáticamente el disco secundario.

Solicitar permisos y acceso

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

Para realizar operaciones de máquinas virtuales con la CLI gdcloud, pide al administrador de proyectos de gestión de identidades y accesos que te asigne el rol de administrador de proyectos de máquinas virtuales y el rol de lector de proyectos (project-viewer).

Iniciar la replicación asíncrona

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

Haz los cambios siguientes:

Variable	Definición
PRIMARY_DISK_NAME	El nombre del disco de origen que se está replicando.
PROJECT	El proyecto de GDC del disco principal.
PRIMARY_ZONE	La zona donde reside el disco principal.
SECONDARY_DISK_NAME	Nombre del disco de destino en el que se replicará.
SECONDARY_ZONE	La zona donde debe residir el disco secundario.

API de disco de VM

Inicia la replicación asíncrona en un disco de VM con kubectl:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  destination:
    volumeOverrideName: VIRTUAL_MACHINE_DESTINATION_DISK_NAME
    zoneRef: DESTINATION_ZONE_NAME
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: VIRTUAL_MACHINE_SOURCE_DISK_NAME
    zoneRef: SOURCE_ZONE_NAME
EOF

Haz los cambios siguientes:

• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API de zona.
• VRR_NAME: el nombre del recurso VolumeReplicationRelationship.
• PROJECT: el espacio de nombres del recurso de proyecto.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: el nombre del recurso VirtualMachineDisk en el destino.
• DESTINATION_ZONE_NAME: el nombre del recurso de zona de destino.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: el nombre del recurso VirtualMachineDisk en la fuente.
• SOURCE_ZONE_NAME: el nombre del recurso de zona de origen.

En este ejemplo, se supone que se ha creado un proyecto llamado PROJECT en una organización llamada my-org y que ya se ha aprovisionado un VirtualMachineDisk llamado VIRTUAL_MACHINE_SOURCE_DISK_NAME en el recurso VirtualMachine.

Los campos source y destination de la especificación indican desde dónde y hacia dónde se replican los datos, respectivamente. En este ejemplo, los datos se replican de SOURCE_ZONE_NAME a DESTINATION_ZONE_NAME.

Nota: El servicio de replicación de bloques asíncrona crea automáticamente un VirtualMachineDisk en la zona de destino para escribir los datos replicados. De forma predeterminada, este VirtualMachineDisk tiene el mismo nombre que el VirtualMachineDisk de origen. Sin embargo, puedes usar el campo volumeOverrideName para especificar el nombre del VirtualMachineDisk creado. Sin embargo, hasta que se cree un VolumeReplicationFailover, el destino VirtualMachineDisk seguirá siendo de solo lectura y no se podrá montar en ninguna carga de trabajo.

Verificación

Comprueba el estado de la relación de replicación obteniendo el CR VolumeReplicationRelationship de la API global. Consulta el siguiente ejemplo. Ten en cuenta que el resultado se ha truncado para simplificarlo:

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
        -n PROJECT -o yaml

El resultado debería ser similar al siguiente:

API de PVC

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: 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: 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

API de disco de VM

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: 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: 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

Crear conmutación por error

Si la zona de origen no está disponible por cualquier motivo, se puede crear un CR de VolumeFailover en el plano de gestión de la organización de la zona de destino. En el caso de una organización de la versión 2, sería el servidor de la API de gestión. En el caso de una organización de la versión 1, sería el clúster de administración de la organización. Por ejemplo, si se ha creado un objeto VolumeReplicationRelationship que especifica zone2 como zona de destino y hay un PVC o un objeto VirtualMachineDisk en la organización my-org, se creará el CR VolumeFailover en el plano de gestión my-org de zone2. Esto rompe la relación de replicación entre las dos zonas y permite que una carga de trabajo monte el PVC o el VirtualMachineDisk en la zona de destino:

  kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
  apiVersion: storage.gdc.goog/v1
  kind: VolumeFailover
  metadata:
    name: FAILOVER_NAME
    namespace: PROJECT
  spec:
    volumeReplicationRelationshipRef: VRR_NAME
  EOF

Haz los cambios siguientes:

• FAILOVER_NAME: el nombre del recurso VolumeFailover.
• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API de zona.
• VRR_NAME: el nombre del recurso VolumeReplicationRelationship.
• PROJECT: el espacio de nombres del recurso de proyecto.

Después, se reflejará una conmutación por error correcta en el estado del CR:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumefailover FAILOVER_NAME \
          -n PROJECT -o yaml

• El resultado debería ser similar al siguiente:

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

• Una vez que se haya creado la conmutación por error, el my-vrr-repl VolumeReplicationRelationship pasará al estado Broken Off. Ahora se puede montar el PVC o el VirtualMachineDisk en zone2.

• En este punto, el VolumeReplicationRelationship tendrá un aspecto similar al del siguiente ejemplo. De nuevo, este resultado se ha truncado para simplificarlo:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
          -n PROJECT -o yaml
  

• El resultado debería ser similar al siguiente:

API de PVC

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vrr-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: 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

API de disco de VM

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: 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 eliminar VolumeReplicationRelationship de forma segura, ya que es la única acción que queda por hacer en esta solicitud de cambio.

  kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationship VRR_NAME \
          -n PROJECT
  

Cambiar el tamaño de los volúmenes

Si en algún momento se cambia el tamaño del volumen de origen, también debes cambiar el tamaño del volumen correspondiente en la zona de destino para que coincida. El volumen de la zona de destino se crea cuando creas el VolumeReplicationRelationship.

Consulta la documentación sobre cómo ampliar discos de máquinas virtuales o ampliar la capacidad de volumen para cambiar el tamaño del almacenamiento en las zonas de origen y de destino.

Mostrar relaciones de replicación asíncrona

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

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

Haz los cambios siguientes:

• PROJECT: el proyecto de GDC del disco principal.
• MANAGEMENT_API_SERVER: el archivo kubeconfig del servidor de la API de gestión de zonas.

El resultado debería ser similar al siguiente:

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 la CLI gdcloud o kubectl:

gdcloud

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

Haz los cambios siguientes:

Variable	Definición
PRIMARY_DISK_NAME	El nombre del disco de origen que se está replicando.
PROJECT	El proyecto de GDC del disco principal.
PRIMARY_ZONE	La zona donde se encuentra el disco principal.

API

1. Busca las relaciones de replicación de volumen que correspondan al disco de la VM principal.

   kubectl --kubeconfig MANAGEMENT_API_SERVER 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. Elimina cada una de las relaciones de replicación de volúmenes que se indican en el paso anterior. Sustituye VRR_NAMES por los nombres de las relaciones de replicación de volúmenes.

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

   Haz los cambios siguientes:

   Variable	Definición
   MANAGEMENT_API_SERVER	El archivo kubeconfig del servidor de la API de gestión global.
   PROJECT	El proyecto de GDC del disco principal.
   PRIMARY_DISK_NAME	El nombre del disco de origen que se está replicando.
   PRIMARY_ZONE	La zona donde reside el disco principal.

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

Conectar el disco replicado a una VM

Mientras la replicación esté habilitada, el disco secundario no se puede conectar a una VM. Una vez que se haya detenido la replicación, puedes adjuntar el disco secundario a una máquina virtual recién creada o a una máquina virtual que ya tengas.