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 de type ONTAP SnapMirror DP existante en XDP

Contributeurs netapp-aaron-holt netapp-lenida netapp-aherbin netapp-ahibbard netapp-dbagwell
PDF

Si vous procédez à une mise à niveau vers ONTAP 9.12.1 ou version ultérieure, vous devez convertir les relations de type DP en relation XDP avant la mise à niveau. ONTAP 9.12.1 et versions ultérieures ne prennent pas en charge les relations de type DP. Vous pouvez facilement convertir une relation de type DP existante en XDP pour tirer parti de SnapMirror flexible à la version.

Avant de mettre à niveau votre système vers ONTAP 9.12.1, vous devez convertir les relations de type DP en relation XDP avant de pouvoir procéder à une mise à niveau vers ONTAP 9.12.1 et versions ultérieures.

Description de la tâche

  • SnapMirror ne convertit pas automatiquement les relations de type DP existantes en relation XDP. Pour convertir la relation, vous devez rompre et supprimer la relation existante, créer une nouvelle relation XDP et resynchroniser la relation.

  • Lors de la planification de votre conversion, notez que la préparation en arrière-plan et la phase d'entreposage des données d'une relation SnapMirror XDP peuvent prendre un certain temps. Il n'est pas rare de voir la relation SnapMirror indiquant l'état « préparation » pour une période prolongée.

Remarque

Après avoir converti un type de relation SnapMirror de DP en XDP, les paramètres d'espace, tels que la taille automatique et la garantie d'espace ne sont plus répliqués vers la destination.
Étapes

  1. Depuis le cluster de destination, s'assurer que la relation SnapMirror est de type DP, que l'état du miroir est SnapMirror, que l'état de la relation est inactif et que la relation fonctionne correctement :

    snapmirror show -destination-path <SVM:volume>

    L'exemple suivant montre la sortie du snapmirror show commande :

    cluster_dst::>snapmirror show -destination-path svm_backup:volA_dst

Source Path: svm1:volA
Destination Path: svm_backup:volA_dst
Relationship Type: DP
SnapMirror Schedule: -
Tries Limit: -
Throttle (KB/sec): unlimited
Mirror State: Snapmirrored
Relationship Status: Idle
Transfer Snapshot: -
Snapshot Progress: -
Total Progress: -
Snapshot Checkpoint: -
Newest Snapshot: snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026
Newest Snapshot Timestamp: 06/27 10:00:55
Exported Snapshot: snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026
Exported Snapshot Timestamp: 06/27 10:00:55
Healthy: true
    Remarque

    Il peut être utile de conserver une copie des snapmirror show valeurs de sortie de la commande pour garder le suivi des paramètres de relation existants. Pour en savoir plus, snapmirror show consultez le "Référence de commande ONTAP".

  2. A partir des volumes source et de destination, assurez-vous que les deux volumes disposent d'un snapshot commun :

    volume snapshot show -vserver <SVM> -volume <volume>

    L'exemple suivant montre le volume snapshot show sortie pour les volumes source et de destination :

    cluster_src:> volume snapshot show -vserver vsm1 -volume volA
---Blocks---
Vserver Volume Snapshot State Size Total% Used%
-------- ------- ------------------------------- -------- -------- ------ -----
svm1 volA
weekly.2014-06-09_0736 valid 76KB 0% 28%
weekly.2014-06-16_1305 valid 80KB 0% 29%
daily.2014-06-26_0842 valid 76KB 0% 28%
hourly.2014-06-26_1205 valid 72KB 0% 27%
hourly.2014-06-26_1305 valid 72KB 0% 27%
hourly.2014-06-26_1405 valid 76KB 0% 28%
hourly.2014-06-26_1505 valid 72KB 0% 27%
hourly.2014-06-26_1605 valid 72KB 0% 27%
daily.2014-06-27_0921 valid 60KB 0% 24%
hourly.2014-06-27_0921 valid 76KB 0% 28%
snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026
valid 44KB 0% 19%
11 entries were displayed.


cluster_dest:> volume snapshot show -vserver svm_backup -volume volA_dst
---Blocks---
Vserver Volume Snapshot State Size Total% Used%
-------- ------- ------------------------------- -------- -------- ------ -----
svm_backup volA_dst
weekly.2014-06-09_0736 valid 76KB 0% 30%
weekly.2014-06-16_1305 valid 80KB 0% 31%
daily.2014-06-26_0842 valid 76KB 0% 30%
hourly.2014-06-26_1205 valid 72KB 0% 29%
hourly.2014-06-26_1305 valid 72KB 0% 29%
hourly.2014-06-26_1405 valid 76KB 0% 30%
hourly.2014-06-26_1505 valid 72KB 0% 29%
hourly.2014-06-26_1605 valid 72KB 0% 29%
daily.2014-06-27_0921 valid 60KB 0% 25%
hourly.2014-06-27_0921 valid 76KB 0% 30%
snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026

  3. Pour vous assurer que les mises à jour planifiées ne s'exécutent pas pendant la conversion, mettez au repos la relation de type DP existante :

    snapmirror quiesce -source-path <SVM:volume> -destination-path <SVM:volume>
    Remarque

    On doit exécuter cette commande depuis le SVM de destination ou le cluster destination.

    L'exemple suivant arrête la relation entre le volume source volA marche svm1 et le volume de destination volA_dst marche svm_backup:

    cluster_dst::> snapmirror quiesce -destination-path svm_backup:volA_dst

    Pour en savoir plus, snapmirror quiesce consultez le "Référence de commande ONTAP".

  4. Casser la relation de type DP existante :

    snapmirror break -destination-path <SVM:volume>
    Remarque

    On doit exécuter cette commande depuis le SVM de destination ou le cluster destination.

    L'exemple suivant rompt la relation entre le volume source volA marche svm1 et le volume de destination volA_dst marche svm_backup:

    cluster_dst::> snapmirror break -destination-path svm_backup:volA_dst

    Pour en savoir plus, snapmirror break consultez le "Référence de commande ONTAP".

  5. Si la suppression automatique des snapshots est activée sur le volume de destination, désactivez-la :

    volume snapshot autodelete modify -vserver _SVM_ -volume _volume_ -enabled false

    L'exemple suivant désactive la suppression automatique de snapshot sur le volume de destination volA_dst :

    cluster_dst::> volume snapshot autodelete modify -vserver svm_backup -volume volA_dst -enabled false

  6. Supprimez la relation DP-type existante :

    snapmirror delete -destination-path <SVM:volume>

    Pour en savoir plus, snapmirror-delete consultez le "Référence de commande ONTAP".

    Remarque

    On doit exécuter cette commande depuis le SVM de destination ou le cluster destination.

    L'exemple suivant supprime la relation entre le volume source volA marche svm1 et le volume de destination volA_dst marche svm_backup:

    cluster_dst::> snapmirror delete -destination-path svm_backup:volA_dst

  7. Relâcher la relation de reprise d'activité SVM d'origine sur la source :

    snapmirror release -destination-path <SVM:volume> -relationship-info-only true

    L'exemple suivant permet de libérer la relation de SVM Disaster Recovery :

    cluster_src::> snapmirror release -destination-path svm_backup:volA_dst -relationship-info-only true

    Pour en savoir plus, snapmirror release consultez le "Référence de commande ONTAP".

  8. Vous pouvez utiliser la sortie que vous avez conservée de l' snapmirror show Commande pour créer la nouvelle relation de type XDP :

    snapmirror create -source-path <SVM:volume> -destination-path <SVM:volume>  -type XDP -schedule <schedule> -policy <policy>

    La nouvelle relation doit utiliser le même volume source et destination. Pour en savoir plus sur les commandes décrites dans cette procédure"Référence de commande ONTAP", reportez-vous à la .

    Remarque

    On doit exécuter cette commande depuis le SVM de destination ou le cluster destination.

    L'exemple suivant illustre la création d'une relation de reprise d'activité SnapMirror entre le volume source volA marche svm1 et le volume de destination volA_dst marche svm_backup utilisation de la valeur par défaut MirrorAllSnapshots règle :

    cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst
-type XDP -schedule my_daily -policy MirrorAllSnapshots

  9. Resynchronisation des volumes source et de destination :

    snapmirror resync -source-path <SVM:volume> -destination-path <SVM:volume>

    Pour améliorer le temps de resynchronisation, vous pouvez utiliser le -quick-resync option, mais vous devez être conscient que les économies d'efficacité de stockage peuvent être perdues.

    Remarque

    On doit exécuter cette commande depuis le SVM de destination ou le cluster destination. Bien que la resynchronisation ne nécessite pas de transfert de base, elle peut prendre du temps. Vous pouvez exécuter la resynchronisation en dehors des heures de pointe.

    L'exemple suivant resynchronque la relation entre le volume source volA marche svm1 et le volume de destination volA_dst marche svm_backup:

    cluster_dst::> snapmirror resync -source-path svm1:volA -destination-path svm_backup:volA_dst

    En savoir plus sur snapmirror resync dans le "Référence de commande ONTAP" .

  10. Si vous avez désactivé la suppression automatique des snapshots, réactivez-la :

    volume snapshot autodelete modify -vserver <SVM> -volume <volume> -enabled true
Une fois que vous avez terminé

  1. Utilisez le snapmirror show Commande permettant de vérifier que la relation SnapMirror a été créée.

    Pour en savoir plus, snapmirror show consultez le "Référence de commande ONTAP".

  2. Une fois que le volume de destination SnapMirror XDP commence à mettre à jour les snapshots tel que défini par la SnapMirror policy, utilisez la commande output of snapmirror list-destinations du cluster source pour afficher la nouvelle relation SnapMirror XDP.

Informations supplémentaires sur les relations de type DP

À partir de ONTAP 9.3, le mode XDP est le mode par défaut et toutes les invocations du mode DP sur la ligne de commande ou dans les scripts nouveaux ou existants sont automatiquement converties en mode XDP.

Les relations existantes ne sont pas affectées. Si une relation est déjà de type DP, elle continuera d'être de type DP. Depuis ONTAP 9.5, MirrorAndVault est la stratégie par défaut lorsqu'aucun mode de protection des données n'est spécifié ou lorsque le mode XDP est spécifié comme type de relation. Le tableau ci-dessous indique le comportement attendu.

Si vous spécifiez…​

Le type est…​

La stratégie par défaut (si vous ne spécifiez pas de règle) est…​

DP

XDP

MirrorAllsnapshots (reprise après incident SnapMirror)

Rien

XDP

MirrorAndVault (réplication unifiée)

XDP

XDP

MirrorAndVault (réplication unifiée)

Comme le montre le tableau, les stratégies par défaut attribuées à XDP dans différentes circonstances assurent que la conversion conserve l'équivalence fonctionnelle des types précédents. Vous pouvez bien sûr utiliser différentes règles si nécessaire, y compris des règles pour la réplication unifiée :

Si vous spécifiez…​

Et la politique est…​

Résultat :

DP

MirrorAllsnapshots

Reprise sur incident SnapMirror

XDPDefault

SnapVault

MirrorAndVault

Réplication unifiée

XDP

MirrorAllsnapshots

Reprise sur incident SnapMirror

XDPDefault

SnapVault

Les seules exceptions à la conversion sont les suivantes :

  • Les relations de protection des données de SVM continuent à être par défaut en mode DP dans ONTAP 9.3 et versions antérieures.

    Depuis ONTAP 9.4, les relations de protection des données du SVM sont définies par défaut en mode XDP

  • Les relations de protection des données de partage de la charge du volume racine continuent à être par défaut en mode DP.

  • Les relations de protection des données SnapLock continuent à être par défaut en mode DP dans ONTAP 9.4 et versions antérieures.

    Depuis ONTAP 9.5, les relations de protection des données SnapLock se servent par défaut du mode XDP.

  • Les invocations explicites de DP continuent à être activées par défaut avec le mode DP si vous définissez l'option d'ensemble du cluster suivante :

    options replication.create_data_protection_rels.enable on

    Cette option est ignorée si vous n'appelez pas explicitement DP.

Informations associées