Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Répliquez des volumes à l'aide de SnapMirror

Contributeurs netapp-aruldeepa
PDF

Trident prend en charge les relations de miroir entre un volume source sur un cluster et le volume de destination sur le cluster homologue pour la réplication des données en vue de la reprise après sinistre.   Vous pouvez utiliser une définition de ressource personnalisée (CRD) avec espace de noms, appelée relation miroir Trident (TMR), pour effectuer les opérations suivantes :

  • Créer des relations de miroir entre les volumes (PVC)

  • Supprimer les relations de miroir entre les volumes

  • Briser les relations miroir

  • Promouvoir le volume secondaire en cas de sinistre (basculements)

  • Effectuer une transition sans perte des applications d'un cluster à l'autre (lors de basculements ou de migrations planifiés).

Prérequis de réplication

Veuillez vous assurer que les conditions préalables suivantes sont remplies avant de commencer :

Clusters ONTAP

  • * Trident*: La version 22.10 ou ultérieure de Trident doit être présente sur les clusters Kubernetes source et de destination qui utilisent ONTAP comme backend.

  • Licences : Les licences asynchrones ONTAP SnapMirror utilisant le module de protection des données doivent être activées sur les clusters ONTAP source et de destination. Se référer à "Présentation des licences SnapMirror dans ONTAP" pour plus d'informations.

    À partir d' ONTAP 9.10.1, toutes les licences sont fournies sous forme de fichier de licence NetApp (NLF), qui est un fichier unique permettant d'activer plusieurs fonctionnalités. Se référer à"Licences incluses avec ONTAP One" pour plus d'informations.

    Remarque Seule la protection asynchrone SnapMirror est prise en charge.
Interconnexion

  • Cluster et SVM : Les backends de stockage ONTAP doivent être appariés. Se référer à "Aperçu du peering de clusters et de SVM" pour plus d'informations.

    Important Assurez-vous que les noms SVM utilisés dans la relation de réplication entre deux clusters ONTAP sont uniques.

  • * Trident et SVM * : Les SVM distants appariés doivent être disponibles pour Trident sur le cluster de destination.

Pilotes pris en charge

NetApp Trident prend en charge la réplication de volumes avec la technologie NetApp SnapMirror utilisant des classes de stockage prises en charge par les pilotes suivants : ontap-nas : NFS ontap-san : iSCSI ontap-san : FC ontap-san : NVMe/TCP (nécessite au minimum la version ONTAP 9.15.1)

Remarque La réplication de volumes à l'aide de SnapMirror n'est pas prise en charge pour les systèmes ASA r2. Pour plus d'informations sur les systèmes ASA r2, consultez"En savoir plus sur les systèmes de stockage ASA r2" .

Créer un PVC miroir

Suivez ces étapes et utilisez les exemples CRD pour créer une relation miroir entre les volumes primaires et secondaires.

Étapes

  1. Effectuez les étapes suivantes sur le cluster Kubernetes principal :

    1. Créez un objet StorageClass avec le trident.netapp.io/replication: true paramètre.

      Exemple
      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. Créez un PVC avec la StorageClass précédemment créée.

      Exemple
      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: csi-nas
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-nas

    3. Créez une ressource personnalisée MirrorRelationship avec des informations locales.

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

      Trident récupère les informations internes du volume et l'état actuel de protection des données (DP) du volume, puis remplit le champ d'état de la MirrorRelationship.

    4. Obtenez le CR TridentMirrorRelationship pour obtenir le nom interne et le SVM du 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. Effectuez les étapes suivantes sur le cluster Kubernetes secondaire :

    1. Créez une StorageClass avec le paramètre trident.netapp.io/replication : true.

      Exemple
      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-nas
provisioner: csi.trident.netapp.io
parameters:
  trident.netapp.io/replication: true

    2. Créez une ressource personnalisée MirrorRelationship avec les informations de destination et de source.

      Exemple
      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 créera une relation SnapMirror avec le nom de stratégie de relation configuré (ou par défaut pour ONTAP) et l'initialisera.

    3. Créez un PVC avec la StorageClass précédemment créée pour servir de destination secondaire (SnapMirror ).

      Exemple
      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 vérifiera l'existence de la définition de ressource personnalisée (CRD) TridentMirrorRelationship et ne parviendra pas à créer le volume si la relation n'existe pas. Si la relation existe, Trident s'assurera que le nouveau FlexVol volume est placé sur une SVM appariée avec la SVM distante définie dans la MirrorRelationship.

États de réplication du volume

Une relation miroir Trident (TMR) est un CRD qui représente une extrémité d'une relation de réplication entre PVC. Le TMR de destination possède un état qui indique à Trident quel est l'état souhaité. Le TMR de destination présente les états suivants :

  • Établi : le PVC local est le volume de destination d’une relation miroir, et il s’agit d’une nouvelle relation.

  • Promu : le PVC local est lisible en écriture et montable, sans relation miroir actuellement en vigueur.

  • Rétabli : le PVC local est le volume de destination d’une relation miroir et faisait également partie auparavant de cette relation miroir.

    • L'état rétabli doit être utilisé si le volume de destination a déjà été en relation avec le volume source, car il écrase le contenu du volume de destination.

    • L'état rétabli échouera si le volume n'était pas auparavant en relation avec la source.

Favoriser la mise en place d'un PVC secondaire lors d'un basculement imprévu

Effectuez l'étape suivante sur le cluster Kubernetes secondaire :

  • Mettez à jour le champ spec.state de TridentMirrorRelationship en promoted .

Favoriser le PVC secondaire lors d'un basculement planifié

Lors d'un basculement (migration) planifié, effectuez les étapes suivantes pour promouvoir le PVC secondaire :

Étapes

  1. Sur le cluster Kubernetes principal, créez un instantané du PVC et attendez que l'instantané soit créé.

  2. Sur le cluster Kubernetes principal, créez la ressource personnalisée SnapshotInfo pour obtenir des détails internes.

    Exemple
    kind: SnapshotInfo
apiVersion: trident.netapp.io/v1
metadata:
  name: csi-nas
spec:
  snapshot-name: csi-nas-snapshot

  3. Sur le cluster Kubernetes secondaire, mettez à jour le champ spec.state de la ressource personnalisée TridentMirrorRelationship à promoted et spec.promotedSnapshotHandle à internalName du snapshot.

  4. Sur le cluster Kubernetes secondaire, vérifiez que l'état (champ status.state) de TridentMirrorRelationship est bien promu.

Rétablir une relation miroir après un basculement

Avant de rétablir une relation miroir, choisissez le côté que vous souhaitez définir comme nouveau côté principal.

Étapes

  1. Sur le cluster Kubernetes secondaire, assurez-vous que les valeurs du champ spec.remoteVolumeHandle de la relation TridentMirrorRelationship sont mises à jour.

  2. Sur le cluster Kubernetes secondaire, mettez à jour le champ spec.mirror de TridentMirrorRelationship en reestablished .

Opérations supplémentaires

Trident prend en charge les opérations suivantes sur les volumes primaires et secondaires :

Répliquez le PVC primaire sur un nouveau PVC secondaire.

Assurez-vous d'avoir déjà un PVC primaire et un PVC secondaire.

Étapes

  1. Supprimez les CRD PersistentVolumeClaim et TridentMirrorRelationship du cluster secondaire (destination) établi.

  2. Supprimez le CRD TridentMirrorRelationship du cluster principal (source).

  3. Créez une nouvelle CRD TridentMirrorRelationship sur le cluster principal (source) pour le nouveau PVC secondaire (destination) que vous souhaitez établir.

Redimensionner un PVC miroir, primaire ou secondaire

Le PVC peut être redimensionné normalement ; ONTAP étendra automatiquement les flevxols de destination si la quantité de données dépasse la taille actuelle.

Supprimer la réplication d'un PVC

Pour supprimer la réplication, effectuez l'une des opérations suivantes sur le volume secondaire actuel :

  • Supprimez la relation MirrorRelationship sur le PVC secondaire. Cela rompt la relation de réplication.

  • Ou bien, mettez à jour le champ spec.state à promue.

Supprimer un PVC (qui était précédemment dupliqué)

Trident vérifie la présence de PVC répliqués et libère la relation de réplication avant de tenter de supprimer le volume.

Supprimer un TMR

La suppression d'un TMR d'un côté d'une relation en miroir entraîne la transition du TMR restant vers l'état promu avant que Trident ne termine la suppression. Si le TMR sélectionné pour suppression est déjà à l'état promu, il n'existe aucune relation miroir et le TMR sera supprimé et Trident promouvra le PVC local à Lecture/Écriture. Cette suppression libère les métadonnées SnapMirror pour le volume local dans ONTAP. Si ce volume est utilisé dans une relation miroir à l'avenir, il doit utiliser un nouveau TMR avec un état de réplication de volume établi lors de la création de la nouvelle relation miroir.

Mettez à jour les relations miroir lorsque ONTAP est en ligne.

Les relations miroir peuvent être mises à jour à tout moment après leur établissement. Vous pouvez utiliser le state: promoted ou state: reestablished champs pour mettre à jour les relations. Lors de la promotion d'un volume de destination en un volume ReadWrite standard, vous pouvez utiliser promotedSnapshotHandle pour spécifier un instantané spécifique dans lequel restaurer le volume actuel.

Mettre à jour les relations miroir lorsque ONTAP est hors ligne

Vous pouvez utiliser une CRD pour effectuer une mise à jour SnapMirror sans que Trident ait une connectivité directe avec le cluster ONTAP . Veuillez vous référer à l'exemple de format suivant pour TridentActionMirrorUpdate :

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

`status.state`reflète l'état du CRD TridentActionMirrorUpdate. Elle peut prendre la valeur Réussi, En cours ou Échec.