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

Restauration d'une machine virtuelle dans la reprise après sinistre de virtualisation OpenShift

Contributeurs banum-netapp
PDF

Cette section fournit des informations sur le processus de restauration (failback) d'une machine virtuelle (VM) dans le cadre de la reprise après sinistre de OpenShift Virtualization à l'aide de NetApp Trident Protect et AppMirror. Après qu'une opération de basculement a été effectuée vers un cluster de destination de reprise après sinistre, vous pouvez utiliser le processus de restauration pour inverser la direction de la réplication et rétablir le cluster source d'origine en tant que cluster principal pour la VM. Cela implique de resynchroniser toutes les modifications apportées à la VM pendant la période de basculement vers le cluster source d'origine, puis de promouvoir la relation de réplication dans le sens inverse. En suivant ces étapes, vous pouvez vous assurer que votre VM s'exécute sur le cluster source d'origine avec toutes les modifications intactes après un événement de reprise après sinistre.

Retour arrière pour la reprise après sinistre de virtualisation OpenShift

Avec Trident Protect, vous pouvez effectuer un « retour arrière » après une opération de basculement en utilisant la séquence d'opérations suivante. Dans ce workflow pour restaurer la direction de réplication d'origine, Trident Protect réplique (resynchronise) toutes les modifications de l'application vers l'application source d'origine avant d'inverser la direction de la réplication.

Ce processus débute à partir d'une relation ayant effectué un basculement vers une destination et comprend les étapes suivantes :

  1. Commencez par un état de basculement échoué.

  2. Resynchronisez à l'inverse la relation de réplication

    Lorsque vous effectuez une resynchronisation inverse d'une relation de réplication ayant basculé, l'application de destination devient l'application source, et la source devient la destination. Les modifications apportées à l'application de destination pendant le basculement sont conservées.

    1. Sur le cluster de destination d'origine, supprimez le CR AppMirrorRelationship. Cela fait en sorte que la destination devienne la source. S'il reste des planifications de protection sur le nouveau cluster de destination, supprimez-les.

      Afficher un exemple

      Suppression de la relation OCP-v AppMirror pour démarrer le basculement

    2. Créez un instantané sur le nouveau cluster source (destination d'origine) afin de capturer les modifications apportées pendant la période de basculement. Cela garantit que toutes les modifications sont répliquées sur le cluster source d'origine lors de la resynchronisation.

      Afficher un exemple 
      # snapshot.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
  name: test-source-dr-init-snapshot-failback
  namespace: test-dr-ns
spec:
  applicationRef: test-dest-app
  appVaultRef: ontap-s3-appvault
  reclaimPolicy: Delete

      Instantané à la demande OCP-v de la VM créé à l'aide de l'interface de ligne de commande Trident Protect sur le nouveau cluster source Instantané à la demande OCP-v de la VM créé à l'aide de l'interface de ligne de commande Trident Protect sur le nouveau cluster source Instantané à la demande OCP-v de la VM créé à l'aide de l'interface de ligne de commande Trident Protect sur le nouveau cluster source

    3. Configurez une relation de réplication du nouveau cluster source (destination d'origine) vers le cluster source d'origine, en configurant les valeurs pour la direction inverse.

      Afficher un exemple

      # application-mirror-relationship.yaml

      apiVersion: protect.trident.netapp.io/v1
kind: AppMirrorRelationship
metadata:
  name: amr1
spec:
  desiredState: Established
  destinationAppVaultRef: ontap-s3-appvault
  destinationApplicationRef: dr-source-vm-failback
  namespaceMapping:
  - destination: test-dr-ns
    source: test-dr-ns-dest
  recurrenceRule: |-
    DTSTART:20240901T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  sourceAppVaultRef: ontap-s3-appvault
  sourceApplicationName: test-dest-app
  sourceApplicationUID: "uid of the app in the original source cluster"
  storageClassName: "sc-nas"

      Relation OCP-v AppMirror créée dans le cluster source d'origine pour inverser le sens de la réplication Relation OCP-v AppMirror créée dans le cluster de destination d'origine pour inverser le sens de la réplication

    4. Promouvez la relation de réplication du nouveau cluster source (destination d'origine) vers le cluster source d'origine en mettant à jour le champ desiredState dans le CR AppMirrorRelationship sur « Promoted ».

      Afficher un exemple

      Relation OCP-v AppMirror dans le cluster source d'origine promue pour effectuer un basculement complet

      Vous voyez maintenant la machine virtuelle s’exécuter dans le cluster source d’origine. Le processus de restauration est maintenant terminé. Vous pouvez maintenant nettoyer les ressources dans le cluster de destination d’origine. Vous pouvez également configurer une nouvelle relation de réplication si vous souhaitez maintenir les capacités de reprise après sinistre après le processus de restauration.

      Remarque N’effectuez pas d’opération de resynchronisation normale, car cela supprimerait les données écrites sur le cluster de destination pendant la procédure de basculement.