PowerScale: SmartSyncs SYNCIQ-policymigreringsfel för en-till-många- eller kaskadreplikation

Migreringen av SmartSyncs SyncIQ-policy misslyckas med ett av två fel:

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.

Fel 1 uppstår när källbassökvägen har befintliga datauppsättningar som markeras som en måldatauppsättning av SmartSync. Och den associerade ögonblicksbild som används för migrering, som används av SyncIQ-principens källpost, är inte samma som används av den senaste datauppsättningen för den specifika källbassökvägen.

Fel 2 inträffar när källbassökvägen har befintliga datauppsättningar som inte är markerade som en måldatauppsättning av SmartSync. Och den associerade ögonblicksbild som används för migrering, som används av SyncIQ-principens källpost, är inte större än eller lika med den ögonblicksbild som används av den senaste datauppsättningen för den specifika källbassökvägen.

Om felet redan har inträffat går du till avsnittet Återställningssteg.

Steg för förebyggande migrering

Försiktighetsåtgärder som ska vidtas innan felen redan har dykt upp i migreringsjobbet. Innan du startar migreringsjobbet ska du utföra följande steg för att undvika ovanstående fel:

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

1. Steg 1: Identifiera din SyncIQ-policy Documentum Interactive Delivery Services. Till exempel:

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

2. Steg 2: källpostkatalogen i kluster A:

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

3. Steg 3: Visa en lista och visa XML-filen som motsvarar varje princip-ID och notera värdet latest-snap-id:

   1. Kontrollera A→B-ögonblicksbilden (det resulterande ID:t blir AX i nästa steg):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Kontrollera A→C-ögonblicksbilden (det resulterande ID:t blir AY i nästa steg):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Steg 4: Jämför värdena för latest-snap-id. Migrera policyn med det äldre (nedre)latest-snap-id först:
   Om ögonblicksbilden från A till B (AX) är äldre än ögonblicksbilden från A till C (AY), till exempel: AX = snapID 100,AY = snapID150. – Herr talman,
   Migrera sedan A till B-principen först.
   
   Om ögonblicksbilden från A till C (AY) är äldre än ögonblicksbilden från A till B (AX), till exempel: AX = snapID 150,AY = snapID100. – Herr talman,
   Migrera sedan principen A till C först.
   
   Om båda principerna använder samma ögonblicksbild, till exempel: AX = 100,AY = 100. – Herr talman,
   Båda principerna kan migreras först. Den andra principmigreringen återanvänder datauppsättningen.

Kedjad (överlappande) konfiguration (A → B → C)

1. Synkroniseringen bör slutföras helt, vilket säkerställer att alla kluster som ingår i principlänkning återspeglar identiska data.

2. Avaktivera alla SyncIQ-policyer i kedjan innan du fortsätter med migreringen. Detta förhindrar att nya inkrementella SyncIQ-jobb utlöses medan migreringen pågår. I en A→B→C-kedja inaktiverar du till exempel både A→B- och B→C-policyerna.

3. Viktigt: Migreringen måste alltid börja från rotklustret (källklustret). För mellanliggande kluster (till exempel B i en konfiguration med 3 kluster) måste alla principer vars källbassökväg också är ett mål för en annan SmartSync-princip använda samma (identiska) ögonblicksbild som den senaste datauppsättningen för bassökvägen. Om ögonblicksbilderna inte matchar pausas migreringsjobbet (blockeras inte permanent). Återställningsstegen har lagts till nedan i avsnittet Återställningssteg.

   Innan du migrerar länkade principer ska du se till att B→C SyncIQ-principen använder ögonblicksbildsbaserad synkronisering med samma ögonblicksbildsmönster som skapas av A→B-principen i kluster B. Detta säkerställer att båda policyerna delar samma baslinje för ögonblicksbilder i reläklustret.

4. Om B→C SyncIQ-principen inte ursprungligen konfigurerades med ögonblicksbildsbaserad synkronisering uppdaterar du den före migreringen med hjälp av följande steg:

   1. Steg 1: Kontrollera att A→B-principen skapar ögonblicksbilder av arkivmål (Target Snapshot Archive: bör visa Yes) samt med ett annat namngivningsmönster än standardnamngivningsmönstret 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

      Som du skulle märka i exemplet ovan är Target Snapshot Archive inställt på"Nej"och mönstret är standardmönstret med prefixet SIQ-*.

   2. Steg 2: Ändra A→ B-principen för att skapa en arkivögonblicksbild med ett annat mönster än standardmönstret:

      # 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. Steg 3: Ändra B→C-principen så att den använder --schedule=when-snapshot-taken:

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

   4. Steg 4: Aktivera A→B-principens jobb för att säkerställa att B→principen kommer ikapp den och återanvänder den arkivögonblicksbild som skapats av A-B.> Du kan verifiera genom att köra kommandot reports.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Vänta tills både A→Bprincipens jobb har slutförts och i sin tur utlöser det B→C-principens jobb. När båda jobben har slutförts kontrollerar du att arkivögonblicksbilden som skapats av A→B-principens senaste körning återanvänds av det senaste jobbet i B→C med följande kommando:

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

      Som du ser ovan är principen latest-snap-id för B→ C samma som principen latest-archive-snap för A→ B. Vilket är det tillstånd där den kedjade principens migrering ska gå igenom framgångsrikt.

Steg för återställningsmigrering

Om ett migreringsförsök redan har gjorts och migreringsjobbet försätts i ett pausat tillstånd följer du dessa återställningssteg:

Fan-out-konfiguration

När ett migreringsjobb för SyncIQ-policyn misslyckas med felet aktiveras motsvarande SyncIQ-policy igen. Åtgärdsstegen är:

1. Steg 1: Kör SyncIQ-policyn för att komma ikapp:
   # isi sync job start <policy-name>
   
2. Steg 2: Vänta tills den nya jobbkörningen har slutförts och visas i rapportutdata:
   # isi sync reports list --policy-name <policy-name>
3. Steg 3: Återuppta SmartSync-migreringsjobbet som hade pausats:
   # isi dm jobs resume <job_id>

Kedjad konfiguration (överlappande)

När ett migreringsjobb för SyncIQ-policyn misslyckas med felet aktiveras motsvarande SyncIQ-policy igen. Åtgärdsstegen är:

1. Steg 1: Ändra SyncIQ-policyn med kommandot:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Steg 2: Kör A-B> smart synkningspolicy med kommandot (förutsatt att uppströmspolicyn redan är migrerad):
   # isi dm policies modify <policy_name> --run-now=yes
   Ögonblicksbilden synkroniseras automatiskt med den senaste ögonblicksbilden av datauppsättningen på källbassökvägen.
3. Steg 3: Återuppta migreringsjobbet med kommandot:
   # isi dm jobs resume <job_id>