PowerScale : Erreur de migration de la règle SYNCIQ de SmartSync pour la réplication un-à-plusieurs ou en cascade

La migration des règles SyncIQ de SmartSync échoue avec l’une des deux erreurs suivantes :

1. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) does not match latest dataset snapshot (<snapshot-id>) for the source basepath (<source-base-path>). This source basepath may act as a target for an existing SmartSync policy. Hence, the SIQ policy migration can't proceed unless the two snapshots are identical. Start the SIQ policy to match the latest dataset snapshot (<snapshot-id>) in source.
2. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) is older than the snapshot (<snapshot-id>) associated with the latest dataset (<dataset details>) for the source basepath (<source-base-path>). Replicate to the latest snapshot or above to proceed with the SIQ policy migration.

L’erreur 1 se produit lorsque le chemin de base source possède un ou plusieurs jeux de données préexistants qui sont marqués comme jeu de données cibles par SmartSync. De plus, le snapshot associé utilisé pour la migration par l’enregistrement source de la règle SyncIQ n’est pas le même que celui utilisé par le dernier jeu de données pour le chemin source-base spécifique.

L’erreur 2 se produit lorsque le chemin de base source possède un ou plusieurs jeux de données préexistants qui ne sont pas marqués comme jeu de données cibles par SmartSync. De plus, le snapshot associé utilisé pour la migration, utilisé par l’enregistrement source de la règle SyncIQ, n’est pas supérieur ou égal au snapshot utilisé par le dernier jeu de données pour le chemin de base source spécifique.

Si l’erreur s’est déjà produite, accédez à la section Recovery Steps.

Étapes de migration préventive

Mesures de précaution à prendre avant que les erreurs ne s’affichent déjà dans la tâche de migration. Avant de démarrer la tâche de migration, procédez comme suit pour éviter les erreurs mentionnées ci-dessus :

Configuration à facteur pyramidal (A → B + A → C)

1. Étape 1 : Identifiez votre règle SyncIQ Documentum Interactive Delivery Services. Par exemple :

   1. Politique A → B :
      # isi sync policies view <pol_a_b> | head -2
   2. Politique A → C :
      # isi sync policies view <pol_a_c> | head -2

2. Étape 2 : le répertoire des enregistrements sources sur le cluster A :

   # cd /ifs/.ifsvar/modules/tsm/config/source_records/

3. Étape 3 : Répertoriez et affichez le fichier XML correspondant à chaque ID de règle, et notez la valeur latest-snap-id :

   1. Vérifiez le snapshot A→B (l’ID obtenu sera AX à l’étape suivante) :
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Vérifiez le snapshot A→C (l’ID obtenu sera AY à l’étape suivante) :
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Étape 4 : Comparez les valeurs latest-snap-id. Migrez d’abord la politique avec l’ancien (lower)latest-snap-id :
   Si le snapshot A vers B (AX) est plus ancien que le snapshot A vers C (AY), par exemple : AX = snapID 100,AY = snapID150.
   Ensuite, migrez d’abord la règle A vers B.
   
   Si le snapshot A vers C (AY) est plus ancien que le snapshot A vers B (AX), par exemple : AX = snapID 150,AY = snapID100.
   Ensuite, migrez d’abord la règle A vers C.
   
   Si les deux politiques utilisent le même snapshot, par exemple : AX = 100,AY = 100.
   L’une ou l’autre règle peut être migrée en premier. La deuxième migration de règle réutilise le jeu de données.

Configuration en chaîne (en cascade) (A → B → C)

1. La synchronisation doit être entièrement effectuée, en veillant à ce que tous les clusters impliqués dans le chaînage des règles reflètent des données identiques.

2. Désactivez toutes les règles SyncIQ de la chaîne avant de poursuivre la migration. Cela empêche le déclenchement de nouvelles tâches SyncIQ incrémentielles pendant la migration. Par exemple, dans une chaîne A→B→C, désactivez les règles A→B et B→C.

3. À noter : La migration doit toujours commencer à partir du cluster racine (source). Pour tout cluster intermédiaire (tel que B dans une configuration à 3 clusters), toutes les règles dont le chemin de base source est également une cible pour une autre règle SmartSync doivent utiliser le même snapshot (identique) que le dernier jeu de données pour ce chemin de base. Si les snapshots ne correspondent pas, la tâche de migration sera interrompue (non bloquée définitivement). Étapes de récupération ajoutées ci-dessous dans la section Étapes de récupération.

   Avant de migrer des règles chaînées, assurez-vous que la règle B→C SyncIQ utilise la synchronisation basée sur les snapshots avec le même modèle de snapshot produit par la règle A→B sur le cluster B. Cela permet de s’assurer que les deux politiques partagent la même référence de snapshot sur le cluster de relais.

4. Si la règle B→C SyncIQ n’a pas été initialement configurée avec la synchronisation basée sur les snapshots, mettez-la à jour avant la migration en procédant comme suit :

   1. Étape 1 : Vérifiez que la règle A→B crée des snapshots cibles d’archivage (Archive de snapshots cible : doit indiquer Oui) ainsi qu’avec un modèle de dénomination autre que le modèle de dénomination par défaut de SIQ-*.

      # isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: No Target Snapshot Pattern: SIQ-%{SrcCluster}-%{PolicyName}-%Y-%m-%d_%H-%M-%S

      Comme vous pouvez le remarquer dans l’exemple ci-dessus, l’archive cible de snapshots est définie sur « No » et le modèle est celui par défaut avec le préfixe SIQ-*.

   2. Étape 2 : Modifiez la règle A→ B pour créer un snapshot d’archivage avec un modèle différent du modèle par défaut :

      # isi sync policies modify <A_to_B_policy> --target-snapshot-archive True --target-snapshot-pattern 'snapB-%{PolicyName}-%Y-%m-%d'

# isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: Yes Target Snapshot Pattern: snapB-%{PolicyName}-%Y-%m-%d
      

   3. Étape 3 : Modifiez la politique B→C pour utiliser --schedule=when-snapshot-taken :

      # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken

   4. Étape 4 : Déclenchez la tâche de la règle A→B pour vous assurer que la stratégie B→C rattrape son retard et réutilise l’instantané d’archive créé par A-B> ; vous pouvez le vérifier en exécutant la commande reports.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Attendez que la tâche de la stratégie A→B soit terminée et, à son tour, cela déclenchera la tâche de la stratégie B→C. Une fois les deux tâches terminées, vérifiez que le snapshot d’archive créé par la dernière exécution de la règle A→B est réutilisé par la dernière tâche de B→C à l’aide de la commande suivante :

      # cat /ifs/.ifsvar/modules/tsm/config/target_records/<A_to_B_policy_Id>.xml | grep latest-archive-snap 
   <latest-archive-snap-alias>621</latest-archive-snap-alias> 
         <latest-archive-snap>625</latest-archive-snap>

# cat /ifs/.ifsvar/modules/tsm/config/source_records/<B_to_C_policy_Id>.xml | grep latest-snap-id
           <latest-snap-id>625</latest-snap-id>
   <restore-latest-snap-id>0</restore-latest-snap-id>
      

      Comme vous l’avez remarqué ci-dessus, le dernier-snap-id pour B→ C est identique au dernier-archivage-snap pour A→ B. Quel est l’état pour que la migration de la stratégie en chaîne se déroule avec succès.

Étapes de migration et de récupération

Si une migration a déjà été tentée et que la tâche de migration passe à l’état PAUSE, suivez les étapes de restauration suivantes :

Configuration à facteur pyramidal

Lorsqu’une tâche de migration d’une règle SyncIQ échoue avec l’erreur, la règle SyncIQ correspondante est réactivée. Les mesures d’atténuation sont les suivantes :

1. Étape 1 : exécutez la règle SyncIQ pour rattraper votre retard :
   # isi sync job start <policy-name>
   
2. Étape 2 : attendez que la nouvelle tâche s’exécute avec succès et s’affiche dans la sortie des rapports :
   # isi sync reports list --policy-name <policy-name>
3. Étape 3 : reprenez la tâche de migration SmartSync qui a été interrompue :
   # isi dm jobs resume <job_id>

Configuration en chaîne (en cascade)

Lorsqu’une tâche de migration d’une règle SyncIQ échoue avec l’erreur, la règle SyncIQ correspondante est réactivée. Les mesures d’atténuation sont les suivantes :

1. Étape 1 : Modifiez la règle SyncIQ à l’aide de la commande :
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Étape 2 : Exécutez la règle A-B> Smart Sync à l’aide de la commande (en supposant que la règle en amont est déjà migrée) :
   # isi dm policies modify <policy_name> --run-now=yes
   Le snapshot sera automatiquement synchronisé avec le dernier snapshot de jeu de données sur le chemin de base source.
3. Étape 3 : Reprenez la tâche de migration à l’aide de la commande suivante :
   # isi dm jobs resume <job_id>