PowerScale: Chyba migrace zásad SYNCIQ společnosti Smartsync pro replikaci typu jeden na více nebo kaskádovou replikaci

Migrace zásad SyncIQ společnosti SmartSync selže s jednou ze dvou chyb:

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.

K chybě 1 dochází, když zdrojová základní cesta obsahuje již existující datové sady, které nástroj SmartSync označí jako cílová datová sada. A přidružený snímek, který se používá pro migraci a který používá zdrojový záznam zásady SyncIQ, není stejný jako snímek, který používá nejnovější datová sada pro konkrétní zdrojovou základní cestu.

K chybě 2 dochází, když zdrojová základní cesta obsahuje již existující datové sady, které technologie SmartSync neoznačuje jako cílová datová sada. A přidružený snímek používaný pro migraci používaný zdrojovým záznamem zásady SyncIQ není větší nebo roven snímku používanému nejnovější datovou sadou pro konkrétní zdrojovou základní cestu.

Pokud k chybě již došlo, přejděte k části Postup obnovení.

Preventivní kroky migrace

Preventivní kroky, které je potřeba provést, než se chyby v úloze migrace projeví. Před spuštěním úlohy migrace proveďte následující kroky, abyste se vyhnuli výše uvedeným chybám:

Konfigurace ventilátoru (A → B + A → C)

1. 1. krok: Identifikujte své zásady SyncIQ Documentum Interactive Delivery Services. Například:

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

2. Krok 2: adresář zdrojových záznamů v clusteru A:

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

3. 3. krok: Vypíše a zobrazte soubor XML odpovídající každému ID zásady a poznamenejte si hodnotu latest-snap-id:

   1. Zkontrolujte A→B snapshot (výsledné ID bude AX v dalším kroku):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Zkontrolujte snímek A→C (výsledné ID bude v dalším kroku AY):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. 4. krok: Porovnejte hodnoty latest-snap-id. Nejprve migrujte zásadu se starším (nižším) nejnovějším identifikátorem snap-id:
   Pokud je snímek A to B (AX) starší než snímek A až C (AY), například: AX = snapID 100,AY = snapID150.
   Pak nejprve migrujte zásadu A na B.
   
   Pokud je snímek A – C (AY) starší než snímek A – B (AX), například: AX = snapID 150,AY = snapID100.
   Pak nejprve migrujte zásadu A na C.
   
   Pokud obě zásady používají stejný snímek, například: AX = 100,AY = 100.
   Obě zásady je možné migrovat jako první. Druhá migrace zásad datovou sadu znovu použije.

Zřetězená (kaskádová) konfigurace (A → B → C)

1. Synchronizace by měla být zcela dokončena, aby se zajistilo, že všechny clustery zapojené do řetězení zásad budou odrážet identická data.

2. Než budete pokračovat v migraci, zakažte všechny zásady SyncIQ v řetězci. Tím se zabrání spuštění nových přírůstkových úloh SyncIQ během migrace. Například v řetězci A→B→C zakažte zásady A→B i B→C.

3. Důležité: Migrace musí vždy začít z kořenového (zdrojového) clusteru. Pro každý zprostředkující cluster (například B v nastavení se 3 clustery) musí všechny zásady, jejichž zdrojová základní cesta je také cílem jiné zásady SmartSync, používat stejný (identický) snímek jako nejnovější datová sada pro danou základní cestu. Pokud se snímky neshodují, úloha migrace se pozastaví (nebude trvale zablokována). Postup obnovení přidaný níže v části Kroky obnovení.

   Před migrací zřetězených zásad se ujistěte, že zásada B→C SyncIQ používá synchronizaci založenou na snímcích se stejným vzorem snímku vytvořeným zásadou A→B v clusteru B. Tím zajistíte, že obě zásady budou sdílet stejný směrný plán snímku v přenosovém clusteru.

4. Pokud zásada B→C SyncIQ nebyla původně nastavena se synchronizací založenou na snapshotech, aktualizujte ji před migrací pomocí následujících kroků:

   1. 1. krok: Ověřte, že zásada A→B vytvoří cílové snímky archivu (Target Snapshot Archive: should show Yes) a také s jiným vzorem pojmenování, než je výchozí vzor pojmenování 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

      Jak jste si všimli ve výše uvedeném příkladu, cílový archiv snímků je nastavený na"Ne" a vzor je výchozí s předponou SIQ-*.

   2. 2. krok: Upravte zásadu A→ B tak, aby se vytvořil snímek archivu s jiným než výchozím vzorem:

      # 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. 3. krok: Upravte zásadu B→C tak, aby používala --schedule=when-snapshot-taken :

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

   4. 4. krok: Aktivujte úlohu zásady A→B, abyste zajistili, že zásada B→C ji dožene a znovu použije snímek archivu vytvořený A-B>. To můžete ověřit spuštěním příkazu reports.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Počkejte na dokončení úlohy zásady A→B a následně se aktivuje úloha zásady B→C. Po dokončení obou úloh pomocí následujícího příkazu ověřte, že snímek archivu vytvořený nejnovějším spuštěním zásady A→B je znovu použit nejnovější úlohou B→C:

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

      Jak jste si všimli výše, latest-snap-id pro zásadu B→ C je stejné jako latest-archive-snap pro zásadu A→ B. Což je stav, ve kterém migrace zřetězených zásad úspěšně projde.

Postup migrace obnovení

Pokud již došlo k pokusu o migraci a úloha migrace přejde do stavu POZASTAVENO, postupujte podle následujících kroků obnovení:

Konfigurace ventilátoru

Pokud úloha migrace zásad SyncIQ selže s chybou, odpovídající zásada SyncIQ se znovu povolí. Opatření pro zmírnění rizik jsou následující:

1. Krok 1: Spusťte zásadu SyncIQ, abyste to dohnali:
   # isi sync job start <policy-name>
   
2. Krok 2: Počkejte, až se spuštění nové úlohy úspěšně dokončí a zobrazí se ve výstupu sestavy:
   # isi sync reports list --policy-name <policy-name>
3. Krok 3: Obnovte pozastavenou úlohu SmartSync Migration:
   # isi dm jobs resume <job_id>

Zřetězená (kaskádová) konfigurace

Pokud úloha migrace zásad SyncIQ selže s chybou, odpovídající zásada SyncIQ se znovu povolí. Opatření pro zmírnění rizik jsou následující:

1. 1. krok: Upravte zásady SyncIQ pomocí příkazu:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. 2. krok: Spusťte zásadu A-B> Smart Sync pomocí příkazu (za předpokladu, že nadřazená zásada je již migrována):
   # isi dm policies modify <policy_name> --run-now=yes
   Snímek se automaticky synchronizuje s nejnovějším snímkem datové sady na zdrojové základní cestě.
3. 3. krok: Obnovte úlohu migrace pomocí příkazu:
   # isi dm jobs resume <job_id>