PowerScale: errore di migrazione delle policy SYNCIQ di SmartSync per la replica one-to-many o in cascata

La migrazione delle policy SyncIQ di SmartSync ha esito negativo con uno dei due errori seguenti:

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'errore 1 si verifica quando il percorso di base di origine presenta dataset preesistenti contrassegnati come dataset di destinazione da SmartSync. E la snapshot associata utilizzata per la migrazione, utilizzata dal record di origine della policy SyncIQ non è la stessa utilizzata dal dataset più recente per lo specifico source-basepath.

L'errore 2 si verifica quando il percorso di base di origine dispone di dataset preesistenti che non sono contrassegnati come dataset di destinazione da SmartSync. E la snapshot associata utilizzata per la migrazione, utilizzata dal record di origine della policy SyncIQ, non è maggiore o uguale alla snapshot utilizzata dal dataset più recente per il source-basepath specifico.

Se l'errore si è già verificato, consultare la sezione Procedura di ripristino.

Passaggi di migrazione preventiva

Misure precauzionali da adottare prima che gli errori vengano già visualizzati nel processo di migrazione. Prima di avviare il processo di migrazione, attenersi alla seguente procedura per evitare gli errori sopra menzionati:

Configurazione fan-out (A → B + A → C)

1. Passo 1: Identificare la policy SyncIQ Documentum Interactive Delivery Services. Ad esempio:

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

2. Passaggio 2: directory dei record di origine nel cluster A:

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

3. Passo 3: Elencare e visualizzare il file XML corrispondente a ciascun ID policy e annotare il valore latest-snap-id:

   1. Controllare un'istantanea A→B (l'ID risultante sarà AX nel passaggio successivo):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Controllare un'istantanea A→C (l'ID risultante sarà AY nel passaggio successivo):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Passo 4: Confrontare i valori snap-id più recenti. Eseguire prima la migrazione della policy con il precedente (inferiore) latest-snap-id:
   se l'istantanea da A a B (AX) è precedente all'istantanea da A a C (AY), ad esempio: AX = snapID 100,AY = snapID150.
   Eseguire quindi prima la migrazione della policy A a B.
   
   Se l'istantanea da A a C (AY) è precedente all'istantanea da A a B (AX), ad esempio: AX = snapID 150,AY = snapID100.
   Eseguire quindi la migrazione della policy A a C.
   
   Se entrambe le policy utilizzano la stessa istantanea, ad esempio: AX = 100,AY = 100.
   È possibile migrare prima entrambe le policy. La seconda migrazione delle policy riutilizza il dataset.

Configurazione concatenata (a cascata) (A → B → C)

1. La sincronizzazione deve essere completamente completata, assicurandosi che tutti i cluster coinvolti nel concatenamento delle policy riflettano dati identici.

2. Disabilitare tutte le policy SyncIQ nella catena prima di procedere con la migrazione. Ciò impedisce l'attivazione di nuovi job SyncIQ incrementali mentre è in corso la migrazione. Ad esempio, in una catena A→B→C, disabilitare le policy A→B e B→C.

3. Importante: La migrazione deve sempre iniziare dal cluster radice (origine). Per qualsiasi cluster intermedio (ad esempio B in una configurazione a 3 cluster), tutte le policy il cui percorso di base di origine è anche una destinazione per un'altra policy SmartSync devono utilizzare la stessa istantanea (identica) del dataset più recente per tale percorso di base. Se le istantanee non corrispondono, il processo di migrazione verrà sospeso (non bloccato in modo permanente). Procedura di ripristino aggiunta di seguito nella sezione Procedura di ripristino.

   Prima di eseguire la migrazione delle policy concatenate, assicurarsi che la policy SyncIQ B→C utilizzi la sincronizzazione basata su snapshot con lo stesso modello di snapshot prodotto dalla policy A→B nel cluster B. Ciò garantisce che entrambe le policy condividano la stessa baseline di istantanee nel cluster di inoltro.

4. Se la policy SyncIQ B→C non è stata originariamente configurata con la sincronizzazione basata su snapshot, aggiornarla prima della migrazione utilizzando la seguente procedura:

   1. Passo 1: Verificare che la policy A→B crei snapshot di destinazione di archiviazione (Target Snapshot Archive: dovrebbe mostrare Yes) e con un modello di denominazione diverso da quello predefinito di 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

      Come si può notare nell'esempio precedente, Target Snapshot Archive è impostato su "No" e il modello è quello predefinito con il prefisso SIQ-*.

   2. Passo 2: Modificare la policy A→B per creare una snapshot di archivio con un modello diverso da quello predefinito:

      # 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. Passo 3: Modificare la policy B→C in modo da utilizzare --schedule=when-snapshot-taken:

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

   4. Passo 4: Attivare il processo della policy A→B per assicurarsi che la policy B→C la recuperi e riutilizzi la snapshot di archivio creata da A-B>; è possibile verificarlo eseguendo il comando reports.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Attendere il completamento del processo di entrambe le policy A→B che, a sua volta, attiverà il processo della policy B→C. Una volta completati entrambi i processi, verificare che la snapshot di archivio creata dall'ultima esecuzione della policy A→B venga riutilizzata dal lavoro più recente di B→C utilizzando il seguente comando:

      # 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>
      

      Come si può notare in precedenza, latest-snap-id per la policy B→ C è uguale a latest-archive-snap per A→ B. Ovvero lo stato per il corretto esito della migrazione dei criteri concatenati.

Procedura di migrazione di ripristino

Se è già stato effettuato un tentativo di migrazione e il processo di migrazione passa allo stato PAUSED, attenersi alla seguente procedura di ripristino:

Configurazione fan-out

Quando un processo di migrazione della policy SyncIQ ha esito negativo con errore, la policy SyncIQ corrispondente viene riabilitata. I passaggi di mitigazione sono:

1. Passaggio 1: eseguire la policy SyncIQ per recuperare:
   # isi sync job start <policy-name>
   
2. Passaggio 2: Attendere che la nuova esecuzione del processo venga completata correttamente e visualizzata nell'output dei report:
   # isi sync reports list --policy-name <policy-name>
3. Passaggio 3: Riprendere il processo di migrazione SmartSync che era stato sospeso:
   # isi dm jobs resume <job_id>

Configurazione concatenata (a cascata)

Quando un processo di migrazione della policy SyncIQ ha esito negativo con errore, la policy SyncIQ corrispondente viene riabilitata. I passaggi di mitigazione sono:

1. Passo 1: Modificare la policy SyncIQ utilizzando il comando:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Passo 2: Eseguire la policy A-B> Smart Sync utilizzando il comando (supponendo che la policy upstream sia già stata migrata):
   # isi dm policies modify <policy_name> --run-now=yes
   L'istantanea verrà sincronizzata automaticamente con l'istantanea del dataset più recente sul percorso di base di origine.
3. Passo 3: Riprendere il processo di migrazione utilizzando il comando:
   # isi dm jobs resume <job_id>