Replica volúmenes de forma asíncrona

En esta página, se muestra 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. Estos datos replicados se pueden usar en una situación 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 crea una conmutación por error, no se puede configurar el volumen original para que se replique en el mismo volumen de destino. En cambio, se debe crear una nueva relación de replicación.

Para los operadores de aplicaciones que prefieren usar la CLI de gdcloud, consulta Cómo replicar volúmenes de forma asíncrona.

Antes de comenzar

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

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

Configura la replicación

El recurso personalizado (CR) VolumeReplicationRelationship brinda servicio 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 VolumeReplicationRelationship en la API de administración global:

API de PVC

Se requiere la vinculación del proyecto. Asegúrate de haber conectado tu proyecto a cada recurso de clúster en 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

Reemplaza lo siguiente:

• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API zonal
• VRR_NAME: el nombre del recurso VolumeReplicationRelationship
• PROJECT: el espacio de nombres del recurso del proyecto
• SOURCE_USER_CLUSTER_NAME: el nombre del recurso de clúster de usuario de origen que se 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 conectará
• DESTINATION_ZONE_NAME: el nombre del recurso de zona de destino

En este ejemplo, se supone que se crea un proyecto llamado PROJECT en una organización llamada my-org y que ya se aprovisionó un PVC llamado PVC_NAME. El SOURCE_USER_CLUSTER_NAME es el nombre del clúster de origen en el que existe el PVC, y el DESTINATION_USER_CLUSTER_NAME es el nombre del clúster de destino en el que existirá un nuevo PVC.

Los campos source y destination de la especificación indican de 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 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, el campo VolumeOverrideName se puede usar para especificar el nombre del PVC creado. Sin embargo, hasta que se cree un VolumeReplicationFailover, el PVC de destino permanecerá de solo lectura y no podrá ser activado por ninguna carga de trabajo.

API de disco de VM

Replica discos de máquina virtual

VolumeReplicationRelationship también brinda servicio 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 al que se replica 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 Project VirtualMachine. 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 VM.

Para las operaciones de VM con la CLI de gdcloud, solicita al administrador de IAM del proyecto que te asigne el rol de administrador de Project VirtualMachine y el rol de visualizador del proyecto (project-viewer).

Inicia la replicación asíncrona

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

Reemplaza lo siguiente:

• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API zonal
• VRR_NAME: el nombre del recurso VolumeReplicationRelationship
• PROJECT: el espacio de nombres del recurso del proyecto
• SOURCE_ZONE_NAME: el 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 la fuente
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: el nombre del recurso VirtualMachineDisk en el destino

En este ejemplo, se supone que se crea un proyecto llamado PROJECT en una organización llamada my-org y que ya se aprovisionó 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 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, 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 permanecerá de solo lectura y no podrá ser activado por ninguna carga de trabajo.

Verificación

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

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

El resultado es similar a este:

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

Crea conmutación por error

En caso de que la zona de origen no esté disponible por algún motivo, se puede crear un CR VolumeFailover en el plano de administración de la organización de la zona de destino. Para una organización v2, este sería el servidor de la API de administración. Para una organización v1, este sería el clúster de administrador de la organización. Por ejemplo, si se creó un VolumeReplicationRelationship que especifica zone2 como la zona de destino y existe un PVC o VirtualMachineDisk en la organización my-org, el CR VolumeFailover se crea en el plano de administración my-org en zone2. Esto interrumpe la relación de replicación entre las dos zonas y permite que una carga de trabajo active el PVC o 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

Reemplaza lo siguiente:

• FAILOVER_NAME: el nombre del recurso VolumeFailover
• MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API zonal
• VRR_NAME: el nombre del recurso VolumeReplicationRelationship

• PROJECT: el espacio de nombres del recurso del proyecto

• Luego, una conmutación por error exitosa se refleja en el estado del CR:

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

• El resultado es similar a este:

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

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

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

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

• El resultado es similar a este:

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, es seguro borrar el VolumeReplicationRelationship, ya que es la única acción restante que se puede realizar en este CR.

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

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 VolumeReplicationRelationship, para que coincida.

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