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éplication de volumes à l'aide de SnapMirror

Contributeurs
PDF

À l'aide d'Astra Control Provisioner, vous pouvez créer des relations de miroir entre un volume source sur un cluster et le volume de destination sur le cluster peering pour la réplication des données pour la reprise après incident. Vous pouvez utiliser une définition de ressource personnalisée (CRD) avec un espace de nom pour effectuer les opérations suivantes :

  • Création de relations de symétrie entre les volumes (ESV)

  • Supprimez les relations de symétrie entre les volumes

  • Rompez les relations de symétrie

  • Promotion du volume secondaire en cas d'incident (basculements)

  • Transition sans perte des applications d'un cluster à un autre (en cas de basculements ou de migrations planifiés)

Conditions préalables à la réplication

Assurez-vous que les conditions préalables suivantes sont remplies avant de commencer :

Clusters ONTAP

  • Astra Control Provisioner : Astra Control Provisioner version 22.10 ou ultérieure doit exister sur les clusters Kubernetes source et de destination qui utilisent ONTAP en tant que backend.

  • Licences : les licences asynchrones de SnapMirror ONTAP utilisant le bundle protection des données doivent être activées sur les clusters ONTAP source et cible. Reportez-vous à la section "Présentation des licences SnapMirror dans ONTAP" pour en savoir plus.

Peering

  • Cluster et SVM : les systèmes back-end de stockage ONTAP doivent être peering. Reportez-vous à la section "Présentation du cluster et de SVM peering" pour en savoir plus.

    Important S'assurer que les noms de SVM utilisés dans la relation de réplication entre deux clusters ONTAP sont uniques.

  • Astra Control Provisioner et SVM : les SVM distants à peering doivent être disponibles pour Astra Control Provisioner sur le cluster de destination.

Pilotes pris en charge

  • La réplication de volume est prise en charge pour les pilotes ontap-nas et ontap-san.

Créer une demande de volume persistant en miroir

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

É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 une demande de volume persistant avec une classe de stockage 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 demande de modification MirrorRelationship avec des informations locales.

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

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

    4. Obtenir le CR TridentMirrorRelationship pour obtenir le nom interne et la 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 classe de stockage 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 demande de modification 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"

      ASTRA Control Provisioner crée une relation SnapMirror avec le nom de la stratégie de relation configurée (ou par défaut pour ONTAP) et l'initialise.

    3. Créez une demande de volume persistant avec une classe de stockage précédemment créée pour agir en tant que classe secondaire (destination 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

      ASTRA Control Provisioner vérifiera le CRD TridentMirrorRelationship et ne créera pas le volume si la relation n'existe pas. Si la relation existe, Astra Control Provisioner s'assurera que le nouveau volume FlexVol est placé sur un SVM peering avec le SVM distant défini dans le MirrorRelationship.

États de réplication des volumes

Une relation de miroir Trident (TMR) est une relation CRD qui représente une extrémité d'une relation de réplication entre les ESV. La TMR de destination a un état qui indique à Astra Control provisionner l'état souhaité. La TMR de destination a 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 ReadWrite et montable, sans relation de miroir actuellement en vigueur.

  • Rétabli: Le PVC local est le volume de destination d'une relation miroir et était également auparavant dans cette relation miroir.

    • L'état rétabli doit être utilisé si le volume de destination était déjà 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 dans une relation avec la source.

Promotion de la demande de volume persistant secondaire en cas de basculement non planifié

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

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

Promotion de la demande de volume persistant secondaire lors d'un basculement planifié

Lors d'un basculement planifié (migration), effectuez les étapes suivantes pour promouvoir la demande de volume persistant secondaire :

Étapes

  1. Sur le cluster Kubernetes principal, créez un snapshot de la demande de volume persistant et attendez que le snapshot soit créé.

  2. Sur le cluster Kubernetes principal, créez la CR SnapshotInfo pour obtenir des informations 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 du TridentMirrorRelationship CR en promu et spec.promotedSnapshotHandle en tant que nom interne du snapshot.

  4. Sur le cluster Kubernetes secondaire, confirmez l'état (champ status.state) de TridentMirrorRelationship à promu.

Restaurer une relation de miroir après un basculement

Avant de restaurer une relation de symétrie, choisissez le côté que vous voulez faire comme nouveau principal.

Étapes

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

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

Opérations supplémentaires

ASTRA Control Provisioner prend en charge les opérations suivantes sur les volumes principal et secondaire :

Répliquer la demande de volume persistant primaire sur une nouvelle demande de volume secondaire

Assurez-vous que vous avez 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 un nouveau CRD TridentMirrorRelationship sur le cluster principal (source) pour le nouveau PVC secondaire (destination) que vous souhaitez établir.

Redimensionner une PVC en miroir, principale ou secondaire

La demande de volume persistant peut être redimensionnée normalement, ONTAP étendra automatiquement les flevxols de destination si la quantité de données dépasse la taille actuelle.

Supprimer la réplication d'une demande de volume persistant

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

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

  • Ou, mettez à jour le champ spec.state à promu.

Suppression d'une demande de volume persistant (qui était auparavant mise en miroir)

Le mécanisme de provisionnement Astra Control vérifie si des demandes de volume persistant sont répliquées et libère la relation de réplication avant toute tentative de suppression du volume.

Supprimer une TMR

La suppression d'une TMR d'un côté d'une relation symétrique entraîne la transition de la TMR restante vers l'état promu avant que Astra Control Provisioner ne termine la suppression. Si la TMR sélectionnée pour la suppression est déjà à l'état promoted, il n'y a pas de relation miroir existante et la TMR sera supprimée et Astra Control Provisioner promouvra le PVC local à ReadWrite. 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 une nouvelle TMR avec un état de réplication établi volume lors de la création de la nouvelle relation miroir.

Mettre à 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 permettant de mettre à jour les relations. Lors de la promotion d'un volume de destination en volume ReadWrite standard, vous pouvez utiliser promotedSnapshotHandle pour spécifier un snapshot spécifique dans lequel restaurer le volume actuel.

Mettre à jour les relations en miroir lorsque ONTAP est hors ligne

Vous pouvez utiliser un CRD pour effectuer une mise à jour SnapMirror sans qu'Astra Control ne dispose d'une connectivité directe au cluster ONTAP. Reportez-vous à l'exemple de format de TridentActionMirrorUpdate suivant :

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. Il peut prendre une valeur de succeed, In Progress ou FAILED.