PowerScale: Fehler bei der Migration der SYNCIQ-Policy von Smartsync für 1:n- oder kaskadierte Replikation

Die SyncIQ-Policy-Migration von SmartSync schlägt mit einem von zwei Fehlern fehl:

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.

Fehler 1 tritt auf, wenn der Quellbasispfad bereits vorhandene Datenvolumen aufweist, die von SmartSync als Zieldatenvolumen markiert werden. Und der zugehörige Snapshot, der für die Migration verwendet wird und vom Quelldatensatz der SyncIQ-Policy verwendet wird, ist nicht derselbe, der vom neuesten Datenvolumen für den spezifischen Quellbasispfad verwendet wird.

Fehler 2 tritt auf, wenn der Quellbasispfad bereits vorhandene Datenvolumen aufweist, die von SmartSync nicht als Zieldatenvolumen markiert wurden. Und der zugehörige Snapshot, der für die Migration verwendet wird und vom Quelldatensatz der SyncIQ-Policy verwendet wird, ist nicht größer oder gleich dem Snapshot, der vom neuesten Datenvolumen für den spezifischen Quellbasispfad verwendet wird.

Wenn der Fehler bereits aufgetreten ist, fahren Sie mit dem Abschnitt Wiederherstellungsschritte fort.

Präventive Migrationsschritte

Vorsichtsmaßnahmen, die Sie ergreifen müssen, bevor die Fehler bereits im Migrationsjob angezeigt werden. Bevor Sie den Migrationsjob starten, führen Sie die folgenden Schritte aus, um die oben genannten Fehler zu vermeiden:

Fan-out-Konfiguration (A → B + A → C)

1. Schritt 1: Identifizieren Ihrer SyncIQ-Policy Documentum Interactive Delivery Services. Zum Beispiel:

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

2. Schritt 2: Das Quelldatensatzverzeichnis auf Cluster A:

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

3. Schritt 3: Listen Sie die XML-Datei auf, die jeder Policy-ID entspricht, und zeigen Sie sie an und notieren Sie sich den Wert für latest-snap-id:

   1. Überprüfen Sie den A→B-Snapshot (die resultierende ID lautet AX im nächsten Schritt):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Überprüfen Sie den A→C-Snapshot (die resultierende ID lautet im nächsten Schritt AY):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Schritt 4: Vergleichen Sie die Werte der neuesten Snap-ID. Migrieren Sie zuerst die Policy mit der älteren (unteren) latest-snap-id:
   Wenn der A-zu-B-Snapshot (AX) älter ist als der A-zu-C-Snapshot (AY), z. B.: AX = snapID 100,AY = snapID150.
   Migrieren Sie dann zuerst die Policy A nach B.
   
   Wenn der A-zu-C-Snapshot (AY) älter ist als der A-zu-B-Snapshot (AX), z. B.: AX = snapID 150,AY = snapID100.
   Migrieren Sie dann zuerst die Policy A nach C.
   
   Wenn beide Policies denselben Snapshot verwenden, z. B.: AX = 100,AY = 100.
   Beide Policies können zuerst migriert werden. Bei der zweiten Policy-Migration wird das Datenvolumen wiederverwendet.

Verkettete (kaskadierte) Konfiguration (A → B → C)

1. Die Synchronisation sollte vollständig abgeschlossen sein, um sicherzustellen, dass alle an der Policy-Verkettung beteiligten Cluster identische Daten widerspiegeln.

2. Deaktivieren Sie alle SyncIQ-Policies in der Kette, bevor Sie mit der Migration fortfahren. Dadurch wird verhindert, dass neue inkrementelle SyncIQ-Jobs ausgelöst werden, während die Migration durchgeführt wird. Deaktivieren Sie beispielsweise in einer A→B→C-Kette sowohl die A→B- als auch die B→C-Policy.

3. Wichtig: Die Migration muss immer vom Root-Cluster (Quelle) beginnen. Für jedes Zwischencluster (z. B. B in einer Konfiguration mit 3 Clustern) müssen alle Policies, deren Quellbasispfad auch ein Ziel für eine andere SmartSync-Policy ist, denselben (identischen) Snapshot wie das neueste Datenvolumen für diesen Basispfad verwenden. Wenn die Snapshots nicht übereinstimmen, wird der Migrationsjob angehalten (nicht dauerhaft blockiert). Wiederherstellungsschritte wurden unten im Abschnitt Wiederherstellungsschritte hinzugefügt.

   Stellen Sie vor der Migration verketteter Policies sicher, dass die B→C SyncIQ-Policy eine Snapshot-basierte Synchronisation mit demselben Snapshot-Muster verwendet, das von der A→B-Policy auf Cluster B erzeugt wird. Dadurch wird sichergestellt, dass beide Policies dieselbe Snapshot-Baseline auf dem Relay-Cluster verwenden.

4. Wenn die B→C SyncIQ-Policy ursprünglich nicht mit Snapshot-basierter Synchronisation eingerichtet wurde, aktualisieren Sie sie vor der Migration mithilfe der folgenden Schritte:

   1. Schritt 1: Überprüfen Sie, ob die A→B-Policy Archivziel-Snapshots (Ziel-Snapshot-Archiv: sollte Ja anzeigen) auch mit einem anderen Benennungsmuster als dem standardmäßigen Benennungsmuster von SIQ-* erstellt.

      # 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

      Wie Sie im obigen Beispiel sehen werden, ist "Ziel-Snapshot-Archiv" auf "Nein" festgelegt und das Muster ist das Standardmuster mit dem Präfix "SIQ-*".

   2. Schritt 2: Ändern Sie die A→ B-Policy, um Archiv-Snapshots mit einem anderen Muster als dem Standardmuster zu erstellen:

      # 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. Schritt 3: Ändern Sie die B→C-Policy so, dass --schedule=when-snapshot-taken verwendet wird:

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

   4. Schritt 4: Lösen Sie den Job der A→B-Policy aus, um sicherzustellen, dass die B→C-Policy aufholt und den von A-B> erstellten Archiv-Snapshot wiederverwendet. Sie können dies überprüfen, indem Sie den Befehl reports ausführen.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Warten Sie, bis der Job der A→B-Policy abgeschlossen ist. Dadurch wird wiederum der Job der B→C-Policy ausgelöst. Sobald beide Jobs abgeschlossen sind, überprüfen Sie, ob der Archiv-Snapshot, der von der letzten Ausführung der A→B-Policy erstellt wurde, vom neuesten Job von B→C mithilfe des folgenden Befehls wiederverwendet wird:

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

      Wie Sie oben sehen werden, ist die neueste Snap-ID für die B→ C-Policy identisch mit der neueste-Archiv-Snapshot für A→ B. Dies ist der Status, in dem die Migration der verketteten Policy erfolgreich abgeschlossen wird.

Schritte für die Recovery-Migration

Wenn bereits ein Migrationsversuch unternommen wurde und der Migrationsjob in den Status PAUSED wechselt, führen Sie die folgenden Recovery-Schritte aus:

Fan-out-Konfiguration

Wenn ein Migrationsjob für SyncIQ-Policies mit dem Fehler fehlschlägt, wird die entsprechende SyncIQ-Policy wieder aktiviert. Die Abhilfemaßnahmen sind:

1. Schritt 1: Führen Sie die SyncIQ-Policy aus, um aufzuholen:
   # isi sync job start <policy-name>
   
2. Schritt 2: Warten Sie, bis der neu ausgeführte Job erfolgreich abgeschlossen wurde und in der Berichtsausgabe angezeigt wird:
   # isi sync reports list --policy-name <policy-name>
3. Schritt 3: Setzen Sie den angehaltenen SmartSync-Migrationsjob fort:
   # isi dm jobs resume <job_id>

Verkettete (kaskadierte) Konfiguration

Wenn ein Migrationsjob für SyncIQ-Policies mit dem Fehler fehlschlägt, wird die entsprechende SyncIQ-Policy wieder aktiviert. Die Abhilfemaßnahmen sind:

1. Schritt 1: Ändern Sie die SyncIQ-Policy mit dem Befehl:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Schritt 2: Führen Sie die A-B Smart Sync-Policy> mithilfe des Befehls aus (vorausgesetzt, die Upstream-Policy wurde bereits migriert):
   # isi dm policies modify <policy_name> --run-now=yes
   Der Snapshot wird automatisch mit dem neuesten Datenvolumen-Snapshot im Quellbasispfad synchronisiert.
3. Schritt 3: Setzen Sie den Migrationsjob mit dem folgenden Befehl fort:
   # isi dm jobs resume <job_id>