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 bloque aislados de Google Distributed Cloud (GDC).

La réplica 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 réplica.

Antes de empezar

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

Después, asegúrate de que tienes 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.

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 VolumeReplicationRelationship en la API de gestió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 da por hecho que se ha creado un proyecto llamado my-project en una organización llamada my-org y que ya se ha aprovisionado un PVC llamado my-block-pvc. clusterRef es el nombre del clúster en el que se encuentra el 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 xx-xxxx-zone1 a xx-xxxx-zone2.

Comprueba el estado de la relación de réplica recuperando el VolumeReplicationRelationship CR de la API global. Consulta el siguiente ejemplo. Ten en cuenta que la salida se ha truncado para simplificarla:

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

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 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 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 xx-xxxx-zone2 como zona de destino y existe un PVC en la organización my-org, el CR VolumeFailover se crea en el plano de gestión my-org en xx-xxxx-zone2. De esta forma, se rompe la relación de replicación entre las dos zonas y se permite que una carga de trabajo monte el PVC de la zona de destino:

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

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

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

Una vez creada la conmutación por error, el my-pvc-repl VolumeReplicationRelationship pasa a un estado Broken Off. El PVC de xx-xxxx-zone2 ahora se puede montar.

En este punto, el VolumeReplicationRelationship será similar al siguiente ejemplo. De nuevo, este resultado se ha truncado 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 eliminar VolumeReplicationRelationship sin problemas, ya que es la única acción que se puede realizar en este CR.

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 objeto VolumeReplicationRelationship.

Replicar discos de máquinas virtuales

VolumeReplicationRelationship también ofrece servicios para la API de réplica de disco de máquina virtual (disco de VM) asíncrona. 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 réplica 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 del 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 del proyecto (project-viewer).

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

Haz los cambios siguientes:

VariableDefinición
PRIMARY_DISK_NAME Nombre del disco de origen que se está replicando.
PROJECT El proyecto de GDC del disco principal.
PRIMARY_ZONE La zona en la que se encuentra el disco principal.
SECONDARY_DISK_NAME Nombre del disco de destino en el que se replicará.
SECONDARY_ZONE 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

Haz los cambios siguientes:

VariableDefinición
GLOBAL_MANAGEMENT_API El archivo kubeconfig del servidor de la API de gestión global.
VRR_NAME Nombre de la relación de replicación de volúmenes.
Se debe usar el mismo nombre al detener la replicación asíncrona.
PROJECT El proyecto de GDC del disco principal.
PRIMARY_DISK_NAME Nombre del disco de origen que se está replicando.
PRIMARY_ZONE La zona en la que se encuentra el disco principal.
SECONDARY_DISK_NAME Nombre del disco de destino en el que se replicará.
SECONDARY_ZONE La zona en la que debe residir el disco secundario.

Listar relaciones de replicación asíncronas

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

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

Haz los cambios siguientes:

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

La salida tendrá este aspecto:

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

Detener la réplica asíncrona en un disco de una VM principal con gdcloud o kubectl.

gdcloud

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

Haz los cambios siguientes:

VariableDefinición
PRIMARY_DISK_NAME Nombre del disco de origen que se está replicando.
PROJECT El proyecto de GDC del disco principal.
PRIMARY_ZONE La zona en la que se encuentra 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. 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 GLOBAL_MANAGEMENT_API delete volumereplicationrelationships \
      -n PROJECT VRR_NAMES
    

    Haz los cambios siguientes:

    VariableDefinición
    GLOBAL_MANAGEMENT_API El archivo kubeconfig del servidor de la API de gestión global.
    PROJECT El proyecto de GDC del disco principal.
    PRIMARY_DISK_NAME Nombre del disco de origen que se está replicando.
    PRIMARY_ZONE La zona en la que se encuentra el disco principal.

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

Adjuntar el disco replicado a una VM

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