PowerScale: Migratiefout van het SYNCIQ-beleid van Smartsync voor één-op-veel of trapsgewijze replicatie

De migratie van het SyncIQ-beleid van SmartSync mislukt met een van de volgende twee fouten:

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.

Fout 1 treedt op wanneer het Source Basepath reeds bestaande dataset(s) heeft die door SmartSync zijn gemarkeerd als een doeldataset. En de bijbehorende snapshot die wordt gebruikt voor migratie, gebruikt door de bronrecord van het SyncIQ-beleid, is niet dezelfde die wordt gebruikt door de nieuwste dataset voor het specifieke bronbasispad.

Fout 2 treedt op wanneer het bronbasispad reeds bestaande dataset(s) heeft die niet door SmartSync als doeldataset zijn gemarkeerd. En de bijbehorende snapshot die wordt gebruikt voor migratie, gebruikt door de bronrecord van het SyncIQ-beleid, is niet groter dan of gelijk aan de snapshot die wordt gebruikt door de nieuwste dataset voor het specifieke bronbasispad.

Als de fout al is opgetreden, gaat u naar het gedeelte Herstelstappen.

Preventieve migratiestappen

Voorzorgsmaatregelen die moeten worden genomen voordat de fouten al zijn weergegeven in de migratietaak. Voordat u de migratietaak start, voert u de volgende stappen uit om de bovengenoemde fouten te voorkomen:

Fan-outconfiguratie (A → B + A → C)

1. Stap 1: Identificeer uw SyncIQ-beleid Documentum Interactive Delivery Services. Bijvoorbeeld:

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

2. Stap 2: de map met bronrecords op Cluster A:

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

3. Stap 3: Vermeld en bekijk het XML-bestand dat overeenkomt met elke beleids-ID en noteer de waarde van de laatste-snap-id:

   1. Controleer A→B-snapshot (de resulterende ID is AX in de volgende stap):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Controleer A→C-snapshot (de resulterende ID is AY in de volgende stap):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Stap 4: Vergelijk de waarden van de laatste-snap-id. Migreer het beleid eerst met de oudere (onderste) laatste-snap-id:
   Als de A naar B snapshot (AX) ouder is dan de A naar C snapshot (AY), bijvoorbeeld: AX = snapID 100,AY = snapID150.
   Migreer dan eerst het A naar B beleid.
   
   Als de A naar C-snapshot (AY) ouder is dan de A-naar-B-snapshot (AX), bijvoorbeeld: AX = snapID 150,AY = snapID100.
   Migreer vervolgens eerst het A naar C-beleid.
   
   Als beide beleidsregels dezelfde snapshot gebruiken, bijvoorbeeld: AX = 100,AY = 100.
   Beide beleidsregels kunnen eerst worden gemigreerd. Bij de tweede beleidsmigratie wordt de dataset opnieuw gebruikt.

Geketende configuratie (trapsgewijs) (A → B → C)

1. De synchronisatie moet volledig worden voltooid, zodat alle clusters die betrokken zijn bij beleidsketens identieke data weergeven.

2. Schakel alle SyncIQ-beleidsregels in de keten uit voordat u doorgaat met de migratie. Dit voorkomt dat nieuwe incrementele SyncIQ-taken worden geactiveerd terwijl de migratie wordt uitgevoerd. In een A→B→C-keten schakelt u bijvoorbeeld zowel het A→B- als het B→C-beleid uit.

3. Belangrijk: De migratie moet altijd beginnen bij het rootcluster (broncluster). Voor elk tussenliggend cluster (zoals B in een opstelling met 3 clusters) moeten alle beleidsregels waarvan het bronbasispad ook een doel is voor een ander SmartSync-beleid, dezelfde (identieke) snapshot gebruiken als de nieuwste dataset voor dat basispad. Als de snapshots niet overeenkomen, wordt de migratietaak gepauzeerd (niet permanent geblokkeerd). Herstelstappen zijn hieronder toegevoegd in het gedeelte Herstelstappen.

   Voordat u geketende beleidsregels migreert, moet u ervoor zorgen dat het B→C SyncIQ-beleid synchronisatie op basis van snapshots gebruikt met hetzelfde snapshotpatroon dat wordt geproduceerd door het A→B-beleid op cluster B. Dit zorgt ervoor dat beide beleidsregels dezelfde snapshotbasislijn delen op het relaycluster.

4. Als het B→C SyncIQ-beleid oorspronkelijk niet is ingesteld met synchronisatie op basis van snapshots, werkt u het vóór de migratie bij met behulp van de volgende stappen:

   1. Stap 1: Controleer of het A→B-beleid ook archiefdoelsnapshots maakt (Doelsnapshotarchief: moet Ja weergeven) met een ander naamgevingspatroon dan het standaardnaamgevingspatroon van 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

      Zoals u in het bovenstaande voorbeeld zou zien, is Target Snapshot Archive ingesteld op "Nee" en is het patroon het standaardpatroon met het voorvoegsel SIQ-*.

   2. Stap 2: Wijzig het A→B-beleid om een archiefsnapshot te maken met een ander patroon dan het standaardpatroon:

      # 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. Stap 3: Wijzig het B→C-beleid om --schedule=when-snapshot-taken te gebruiken:

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

   4. Stap 4: Activeer de taak van het A→Bbeleid om ervoor te zorgen dat het B→C-beleid deze inhaalt en de archiefmomentopname die door A-B> is gemaakt, opnieuw gebruikt. U kunt dit controleren door de opdracht rapporten uit te voeren.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Wacht tot de taak van zowel het A→Bbeleid is voltooid als dat de taak van het B→Cbeleid is voltooid. Zodra beide taken zijn voltooid, controleert u of de archiefsnapshot die is gemaakt door de laatste uitvoering van het A→Bbeleid, opnieuw wordt gebruikt door de nieuwste taak van B→C met behulp van de volgende opdracht:

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

      Zoals u hierboven zou zien, is de laatste-snap-id voor B→ C-beleid hetzelfde als de laatste-archief-snap voor A→ B. Dat is de status voor de migratie van geketend beleid om met succes te doorlopen.

Stappen voor herstelmigratie

Als er al een migratiepoging is gedaan en de migratietaak wordt onderbroken, volgt u deze herstelstappen:

Fan-out configuratie

Wanneer een migratietaak van het SyncIQ-beleid mislukt met de fout, wordt het bijbehorende SyncIQ-beleid weer ingeschakeld. De mitigatiestappen zijn:

1. Stap 1: Voer het SyncIQ-beleid uit om bij te praten:
   # isi sync job start <policy-name>
   
2. Stap 2: Wacht tot de nieuwe taakuitvoering is voltooid en wordt weergegeven in de rapportuitvoer:
   # isi sync reports list --policy-name <policy-name>
3. Stap 3: Hervat de SmartSync-migratietaak die was onderbroken:
   # isi dm jobs resume <job_id>

Geketende configuratie (trapsgewijs)

Wanneer een migratietaak van het SyncIQ-beleid mislukt met de fout, wordt het bijbehorende SyncIQ-beleid weer ingeschakeld. De mitigatiestappen zijn:

1. Stap 1: Wijzig het SyncIQ-beleid met de opdracht:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Stap 2: Voer A-B Smart Sync-beleid> uit met de opdracht (ervan uitgaande dat het upstreambeleid al is gemigreerd):
   # isi dm policies modify <policy_name> --run-now=yes
   De snapshot wordt automatisch gesynchroniseerd met de nieuwste snapshot van de dataset op het basispad van de bron.
3. Stap 3: Hervat de migratietaak met de opdracht:
   # isi dm jobs resume <job_id>