Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Replica volúmenes usando SnapMirror

Trident admite relaciones de espejo entre un volumen de origen en un clúster y el volumen de destino en el clúster emparejado para replicar datos para recuperación ante desastres.  Puedes usar una Custom Resource Definition (CRD) con espacio de nombres, llamada Trident Mirror Relationship (TMR), para realizar las siguientes operaciones:

  • Crear relaciones de espejo entre volúmenes (PVCs)

  • Eliminar relaciones de espejo entre volúmenes

  • Rompe las relaciones espejo

  • Promociona el volumen secundario durante condiciones de desastre (conmutaciones por error)

  • Realiza una transición sin pérdidas de aplicaciones de un clúster a otro (durante conmutaciones por error o migraciones planificadas)

Requisitos previos de replicación

Asegúrate de que se cumplan los siguientes requisitos previos antes de comenzar:

Clústeres ONTAP
  • Trident: Trident versión 22.10 o posterior debe existir tanto en los clústeres de Kubernetes de origen como en los de destino que utilizan ONTAP como backend.

  • Licencias: Las licencias asíncronas de ONTAP SnapMirror usando el paquete Data Protection deben estar habilitadas tanto en el clúster ONTAP de origen como en el clúster de destino. Consulta "Resumen de licencias de SnapMirror en ONTAP" para más información.

    A partir de ONTAP 9.10.1, todas las licencias se entregan como un archivo de licencia NetApp (NLF), que es un único archivo que habilita varias funciones. Consulta "Licencias incluidas con ONTAP One" para más información.

    Nota Solo se admite la protección asíncrona de SnapMirror.
Emparejamiento
  • Clúster y SVM: Los backends de almacenamiento de ONTAP deben estar interconectados. Consulta "Descripción general de clúster y SVM peering" para más información.

    Importante Asegúrate de que los nombres de SVM usados en la relación de replicación entre dos clústeres ONTAP sean únicos.
  • Trident y SVM: las SVM remotas emparejadas deben estar disponibles para Trident en el clúster de destino.

Controladores compatibles

NetApp Trident admite la replicación de volúmenes con la tecnología NetApp SnapMirror usando clases de almacenamiento respaldadas por los siguientes controladores: ontap-nas: NFS ontap-san: iSCSI ontap-san: FC ontap-san: NVMe/TCP (requiere como mínimo la versión ONTAP 9.15.1)

Nota La replicación de volúmenes usando SnapMirror no es compatible con sistemas ASA r2. Para información sobre los sistemas ASA r2, consulta "Conoce los sistemas de almacenamiento ASA r2".

Crear un PVC reflejado

Sigue estos pasos y usa los ejemplos de CRD para crear una relación de espejo entre los volúmenes primario y secundario.

Pasos
  1. Realiza los siguientes pasos en el clúster principal de Kubernetes:

    1. Crea un objeto StorageClass con el parámetro trident.netapp.io/replication: true.

      Ejemplo
      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: csi-nas
      provisioner: csi.trident.netapp.io
      parameters:
        backendType: "ontap-nas"
        fsType: "nfs"
        trident.netapp.io/replication: "true"
    2. Crea un PVC con una StorageClass creada previamente.

      Ejemplo
      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: csi-nas
      spec:
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 1Gi
        storageClassName: csi-nas
    3. Crea un CR de MirrorRelationship con información local.

      Ejemplo
      kind: TridentMirrorRelationship
      apiVersion: trident.netapp.io/v1
      metadata:
        name: csi-nas
      spec:
        state: promoted
        volumeMappings:
        - localPVCName: csi-nas

      Trident obtiene la información interna del volumen y el estado actual de protección de datos (DP) del volumen, luego rellena el campo de estado de MirrorRelationship.

    4. Obtén el TridentMirrorRelationship CR para obtener el nombre interno y SVM del PVC.

      kubectl get tmr csi-nas
      kind: TridentMirrorRelationship
      apiVersion: trident.netapp.io/v1
      metadata:
        name: csi-nas
        generation: 1
      spec:
        state: promoted
        volumeMappings:
        - localPVCName: csi-nas
      status:
        conditions:
        - state: promoted
          localVolumeHandle: "datavserver:trident_pvc_3bedd23c_46a8_4384_b12b_3c38b313c1e1"
          localPVCName: csi-nas
          observedGeneration: 1
  2. Realiza los siguientes pasos en el clúster secundario de Kubernetes:

    1. Crea un StorageClass con el parámetro trident.netapp.io/replication: true.

      Ejemplo
      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: csi-nas
      provisioner: csi.trident.netapp.io
      parameters:
        trident.netapp.io/replication: true
    2. Crea un CR MirrorRelationship con información sobre el destino y el origen.

      Ejemplo
      kind: TridentMirrorRelationship
      apiVersion: trident.netapp.io/v1
      metadata:
        name: csi-nas
      spec:
        state: established
        volumeMappings:
        - localPVCName: csi-nas
          remoteVolumeHandle: "datavserver:trident_pvc_3bedd23c_46a8_4384_b12b_3c38b313c1e1"

      Trident creará una relación SnapMirror con el nombre de política de relación configurado (o el predeterminado para ONTAP) y la inicializará.

    3. Crea un PVC con el StorageClass creado previamente para que actúe como secundario (SnapMirror destino).

      Ejemplo
      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: csi-nas
        annotations:
          trident.netapp.io/mirrorRelationship: csi-nas
      spec:
        accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 1Gi
      storageClassName: csi-nas

      Trident comprobará si existe el TridentMirrorRelationship CRD y fallará al crear el volumen si la relación no existe. Si la relación existe, Trident se asegurará de que el nuevo volumen FlexVol se coloque en una SVM que esté peered con la SVM remota definida en el MirrorRelationship.

Estados de replicación de volúmenes

Una Trident Mirror Relationship (TMR) es un CRD que representa un extremo de una relación de replicación entre PVCs. La TMR de destino tiene un estado, que le dice a Trident cuál es el estado deseado. La TMR de destino tiene los siguientes estados:

  • Establecido: el PVC local es el volumen de destino de una relación de espejo, y esta es una nueva relación.

  • Promocionado: el PVC local es ReadWrite y montable, sin relación de espejo actualmente en vigor.

  • Reestablecido: el PVC local es el volumen de destino de una relación de espejo y también estaba previamente en esa relación de espejo.

    • El estado restablecido debe usarse si el volumen de destino estuvo alguna vez en una relación con el volumen de origen porque sobrescribe el contenido del volumen de destino.

    • El estado restablecido fallará si el volumen no estaba previamente en una relación con el origen.

Promociona el PVC secundario durante una conmutación por error no planificada

Realiza el siguiente paso en el clúster secundario de Kubernetes:

  • Actualiza el campo spec.state de TridentMirrorRelationship a promoted.

Promociona el PVC secundario durante una conmutación por error planificada

Durante una conmutación por error planificada (migración), realiza los siguientes pasos para promover el PVC secundario:

Pasos
  1. En el clúster primario de Kubernetes, crea una instantánea del PVC y espera hasta que se cree la instantánea.

  2. En el clúster primario de Kubernetes, crea el CR SnapshotInfo para obtener detalles internos.

    Ejemplo
    kind: SnapshotInfo
    apiVersion: trident.netapp.io/v1
    metadata:
      name: csi-nas
    spec:
      snapshot-name: csi-nas-snapshot
  3. En el clúster de Kubernetes secundario, actualiza el campo spec.state del CR TridentMirrorRelationship a promoted y spec.promotedSnapshotHandle al internalName de la instantánea.

  4. En el clúster secundario de Kubernetes, confirma el estado (campo status.state) de TridentMirrorRelationship a promoted.

Restaura una relación de réplica tras una conmutación por error

Antes de restablecer una relación de espejo, elige el lado que quieres convertir en el nuevo primario.

Pasos
  1. En el clúster secundario de Kubernetes, asegúrate de que los valores del campo spec.remoteVolumeHandle en el TridentMirrorRelationship estén actualizados.

  2. En el clúster de Kubernetes secundario, actualiza el campo spec.mirror de TridentMirrorRelationship a reestablished.

Operaciones adicionales

Trident admite las siguientes operaciones en los volúmenes primario y secundario:

Replica el PVC primario en un nuevo PVC secundario

Asegúrate de que ya tienes un PVC primario y un PVC secundario.

Pasos
  1. Elimina los PersistentVolumeClaim y TridentMirrorRelationship CRD del clúster secundario (de destino) establecido.

  2. Elimina el CRD TridentMirrorRelationship del clúster principal (origen).

  3. Crea un nuevo CRD TridentMirrorRelationship en el clúster principal (de origen) para el nuevo PVC secundario (de destino) que quieres establecer.

Redimensiona un PVC reflejado, primario o secundario

El PVC se puede redimensionar de forma normal, ONTAP expandirá automáticamente cualquier destino flevxols si la cantidad de datos excede el tamaño actual.

Eliminar la replicación de un PVC

Para eliminar la replicación, realiza una de las siguientes operaciones en el volumen secundario actual:

  • Elimina el MirrorRelationship en el PVC secundario. Esto rompe la relación de replicación.

  • O, actualiza el campo spec.state a promoted.

Elimina un PVC (que antes estaba replicado)

Trident comprueba si hay PVC replicados y libera la relación de replicación antes de intentar eliminar el volumen.

Eliminar un TMR

Eliminar una TMR en un lado de una relación de réplica hace que la TMR restante pase al estado promoted antes de que Trident complete la eliminación. Si la TMR seleccionada para eliminar ya está en estado promoted, no existe una relación de réplica y la TMR se eliminará y Trident promoverá el PVC local a ReadWrite. Esta eliminación libera los metadatos de SnapMirror para el volumen local en ONTAP. Si este volumen se usa en una relación de réplica en el futuro, debe usar una nueva TMR con un estado de replicación de volumen established al crear la nueva relación de réplica.

Actualizar las relaciones de réplica cuando ONTAP está en línea

Las relaciones de espejo se pueden actualizar en cualquier momento después de que se establecen. Puedes usar los campos state: promoted o state: reestablished para actualizar las relaciones. Al promover un volumen de destino a un volumen normal ReadWrite, puedes usar promotedSnapshotHandle para especificar una instantánea específica a la que restaurar el volumen actual.

Actualiza las relaciones de réplica cuando ONTAP está fuera de línea

Puedes usar un CRD para realizar una actualización de SnapMirror sin que Trident tenga conectividad directa con el clúster ONTAP. Consulta el siguiente formato de ejemplo de TridentActionMirrorUpdate:

Ejemplo
apiVersion: trident.netapp.io/v1
kind: TridentActionMirrorUpdate
metadata:
  name: update-mirror-b
spec:
  snapshotHandle: "pvc-1234/snapshot-1234"
  tridentMirrorRelationshipName: mirror-b

status.state refleja el estado del TridentActionMirrorUpdate CRD. Puede tomar un valor de Succeeded, In Progress o Failed.