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.

Convertir une relation SnapMirror existante en relation SnapMirror active Sync

Contributeurs
PDF

Si vous avez configuré la protection SnapMirror, vous pouvez convertir la relation en synchronisation active SnapMirror. À partir de ONTAP 9.15.1, vous pouvez convertir la relation pour utiliser une protection active/active symétrique.

Convertir une relation SnapMirror existante en relation SnapMirror active Sync asymétrique

Si vous avez déjà une relation synchrone SnapMirror entre un cluster source et un cluster destination, vous pouvez la convertir en relation synchrone SnapMirror asymétrique. Vous pouvez ainsi associer les volumes en miroir à un groupe de cohérence, garantissant ainsi un RPO nul sur une charge de travail à plusieurs volumes. En outre, vous pouvez conserver les snapshots SnapMirror existants si vous devez revenir à un point dans le temps avant d'établir la relation de synchronisation active SnapMirror.

Description de la tâche

  • Vous devez être administrateur du cluster et SVM sur les clusters principal et secondaire.

  • Vous ne pouvez pas convertir le RPO nul en synchronisation RTO zéro en modifiant la règle SnapMirror.

  • Vous devez vous assurer que le mappage des LUN est annulé avant d'émettre le snapmirror create commande.

    Si les LUN existantes du volume secondaire sont mappées et l' AutomatedFailover la règle est configurée, le snapmirror create la commande déclenche une erreur.

Avant de commencer

  • Une relation synchrone de SnapMirror avec RPO nul doit exister entre le cluster principal et le cluster secondaire.

  • Avant de pouvoir créer la relation SnapMirror avec un objectif RTO nul, toutes les LUN du volume de destination doivent être démappées.

  • La synchronisation active SnapMirror prend uniquement en charge les protocoles SAN (pas NFS/CIFS). Assurez-vous qu'aucun composant du groupe de cohérence n'est monté pour l'accès au NAS.

Étapes

  1. Depuis le cluster secondaire, effectuer une mise à jour SnapMirror sur la relation existante :

    SiteB::>snapmirror update -destination-path vs1_dst:vol1

  2. Vérifier que la mise à jour SnapMirror a été correctement effectuée :

    SiteB::>snapmirror show

  3. Mettez en pause chacune des relations synchrones avec RPO nul :

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol1

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol2

  4. Supprimez chacune des relations synchrones RPO zéro :

    SiteB::>snapmirror delete -destination-path vs1_dst:vol1

    SiteB::>snapmirror delete -destination-path vs1_dst:vol2

  5. Relâcher la relation SnapMirror source mais conserver les copies Snapshot courantes :

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2

  6. Créer une relation SnapMirror synchrone à objectif de durée de restauration nul :

    SiteB::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol1:@vol1,vol2:@vol2 -policy AutomatedFailover

  7. Resynchroniser le groupe de cohérence :

    SiteB::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst

  8. Relancez les chemins d'E/S de la LUN hôte pour restaurer tous les chemins d'accès aux LUN.

Convertir une relation SnapMirror en relation actif-actif symétrique

Depuis la version ONTAP 9.15.1, vous pouvez convertir une relation SnapMirror existante en relation actif-actif symétrique SnapMirror synchrone.

Avant de commencer

  • Vous devez exécuter ONTAP 9.15.1 ou une version ultérieure.

  • Une relation synchrone de SnapMirror avec RPO nul doit exister entre le cluster principal et le cluster secondaire.

  • Avant de pouvoir créer la relation SnapMirror avec un objectif RTO nul, toutes les LUN du volume de destination doivent être démappées.

  • La synchronisation active SnapMirror prend uniquement en charge les protocoles SAN (pas NFS/CIFS). Assurez-vous qu'aucun composant du groupe de cohérence n'est monté pour l'accès au NAS.

Étapes

  1. Depuis le cluster secondaire, effectuer une mise à jour SnapMirror sur la relation existante :

    SiteB::>snapmirror update -destination-path vs1_dst:vol1

  2. Vérifier que la mise à jour SnapMirror a été correctement effectuée :

    SiteB::>snapmirror show

  3. Mettez en pause chacune des relations synchrones avec RPO nul :

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol1

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol2

  4. Supprimez chacune des relations synchrones RPO zéro :

    SiteB::>snapmirror delete -destination-path vs1_dst:vol1

    SiteB::>snapmirror delete -destination-path vs1_dst:vol2

  5. Relâcher la relation SnapMirror source mais conserver les copies Snapshot courantes :

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2

  6. Créez une relation synchrone SnapMirror RTO zéro avec la règle AutomatedFailoverDuplex :

    SiteB::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol1:@vol1,vol2:@vol2 -policy AutomatedFailoverDuplex

  7. Si les hôtes existants sont locaux du cluster principal, ajoutez l'hôte au cluster secondaire et établissez la connectivité avec l'accès respectif à chaque cluster.

  8. Sur le site secondaire, supprimez les mappages de LUN sur les groupes initiateurs associés aux hôtes distants.

    Remarque Assurez-vous que le groupe initiateur ne contient pas de mappages pour les LUN non répliquées.

    SiteB::> lun mapping delete -vserver svm_name -igroup igroup -path <>

  9. Sur le site principal, modifiez la configuration de l'initiateur pour les hôtes existants afin de définir le chemin proximal des initiateurs sur le cluster local.

    SiteA::> igroup initiator add-proximal-vserver -vserver svm_name -initiator host -proximal-vserver server

  10. Ajoutez un groupe initiateur et un initiateur pour les nouveaux hôtes et définissez la proximité de l'hôte pour l'affinité avec l'hôte sur son site local. Réplication igroup exécutable pour répliquer la configuration et inverser la localisation de l'hôte sur le cluster distant.


    SiteA::> igroup modify -vserver vsA -igroup ig1 -replication-peer vsB
    SiteA::> igroup initiator add-proximal-vserver -vserver vsA -initiator host2 -proximal-vserver vsB

  11. Découvrez les chemins sur les hôtes et vérifiez que les hôtes disposent d'un chemin Active/Optimized vers la LUN de stockage à partir du cluster préféré

  12. Déployez l'application et distribuez les workloads des machines virtuelles entre les clusters.

  13. Resynchroniser le groupe de cohérence :

    SiteB::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst

  14. Relancez les chemins d'E/S de la LUN hôte pour restaurer tous les chemins d'accès aux LUN.