Replicar volúmenes de forma asíncrona

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

La réplica asíncrona se usa para replicar datos de una zona de GDC a otra. Estos datos replicados se pueden usar en un escenario de conmutación por error en caso de que los datos de la zona de origen no estén disponibles. Ten en cuenta que, una vez que se haya creado una conmutación por error, el volumen original no se podrá configurar para que se replique en el mismo volumen de destino. En su lugar, se debe crear una nueva relación de réplica.

Si los operadores de aplicaciones prefieren usar la interfaz de línea de comandos gdcloud, consulta Replicar volúmenes de forma asíncrona.

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 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 app-volume-replication-admin para modificar directamente el recurso VolumeReplicationRelationshipReplica zonal.

Configurar la replicación

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

API de PVC

Es obligatorio indicar un enlace de proyecto. Asegúrate de haber vinculado tu proyecto a cada recurso Cluster 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 zonal.
• VRR_NAME: nombre del recurso VolumeReplicationRelationship.
• PROJECT: el espacio de nombres del recurso Project.
• SOURCE_USER_CLUSTER_NAME: nombre del recurso de clúster de usuario de origen que se va a conectar.
• PVC_NAME: nombre del recurso PersistentVolumeClaim.
• SOURCE_ZONE_NAME: nombre del recurso de zona de origen.
• DESTINATION_USER_CLUSTER_NAME: nombre del recurso de clúster de usuario de destino al que se va a conectar.
• DESTINATION_ZONE_NAME: el nombre del recurso de zona de destino.

En este ejemplo se da por hecho 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 el PVC y DESTINATION_USER_CLUSTER_NAME es el nombre del clúster de destino en el que se creará un nuevo PVC.

Los campos source y destination de la especificación indican de dónde se replican los datos (from) y a dónde se replican (to), 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 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, se puede usar el campo VolumeOverrideName para especificar el nombre del PVC creado. Sin embargo, hasta que se cree un VolumeReplicationFailover, el PVC de destino seguirá siendo de solo lectura y no podrá montarse en ninguna carga de trabajo.

API de discos de VM

Replicar discos de máquinas virtuales

VolumeReplicationRelationship también ofrece servicios para la API de replicación asíncrona de discos de máquinas virtuales (discos de MV). El disco de origen que se está replicando se denomina "disco principal". El disco de destino al que se está replicando se denomina disco secundario. Al iniciar la replicación asíncrona en un disco primario, se creará automáticamente el disco secundario.

Solicitar 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 Administrador de máquinas virtuales de proyecto (project-vm-admin) en el espacio de nombres del proyecto en el que se encuentra el disco de la VM.

Para realizar operaciones con máquinas virtuales mediante la interfaz de línea de comandos gdcloud, pide al administrador de gestión de identidades y accesos de tu proyecto que te asigne el rol Administrador de máquinas virtuales del proyecto y el rol Lector de proyectos (project-viewer).

Iniciar la replicación asíncrona

Inicia la replicación asíncrona en un disco de una 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 zonal.
• VRR_NAME: nombre del recurso VolumeReplicationRelationship.
• PROJECT: el espacio de nombres del recurso Project.
• SOURCE_ZONE_NAME: nombre del recurso de zona de origen.
• DESTINATION_ZONE_NAME: el nombre del recurso de zona de destino.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: el nombre del recurso VirtualMachineDisk en el origen.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: el nombre del recurso VirtualMachineDisk en el destino.

En este ejemplo se da por hecho 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 de dónde se replican los datos (from) y a dónde se replican (to), 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, el campo volumeOverrideName se puede usar para especificar el nombre del VirtualMachineDisk creado. Sin embargo, hasta que se cree un VolumeReplicationFailover, el VirtualMachineDisk de destino seguirá siendo de solo lectura y ninguna carga de trabajo podrá montarlo.

Verificación

Comprueba el estado de la relación de replicación recuperando 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 discos 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 algún motivo, se puede crear un VolumeFailover en el plano de gestión de la zona de destino de la organización. En el caso de una organización de la versión 2, sería el servidor de la API de gestión. En una organización de la versión 1, este sería el clúster de administrador de la organización. Por ejemplo, si se ha creado un VolumeReplicationRelationship que especifica zone2 como zona de destino y existe un PVC o un VirtualMachineDisk en la organización my-org, se creará el CR VolumeFailover en el plano de gestión my-org en zone2. De esta forma, se rompe la relación de réplica entre las dos zonas y se permite que una carga de trabajo monte el PVC o el VirtualMachineDisk de 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: nombre del recurso VolumeFailover.
• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API zonal.
• VRR_NAME: nombre del recurso VolumeReplicationRelationship.

• PROJECT: el espacio de nombres del recurso Project.

• Después, el estado de la CR reflejará que la conmutación por error se ha realizado correctamente:

  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 creada la conmutación por error, el my-vrr-repl VolumeReplicationRelationship pasa a un estado Broken Off. Ahora se puede montar el PVC o VirtualMachineDisk en zone2.

• En este punto, el VolumeReplicationRelationship será similar al 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 discos 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, ya que es la única acción que se puede realizar en esta respuesta predefinida.

  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 se debe cambiar el tamaño del volumen correspondiente de la zona de destino, que se crea en nombre del usuario cuando se crea un VolumeReplicationRelationship, para que coincida.

Consulta la documentación sobre cómo ampliar los discos de una VM o sobre cómo ampliar la capacidad de un volumen para cambiar el tamaño del almacenamiento en las zonas de origen y de destino.