PowerScale: Помилка міграції політики SYNCIQ від Smartsync для реплікації One-to-many або Cascade

Міграція політики SyncIQ від SmartSync зазнає невдачі через одну з двох помилок:

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.

Помилка 1 виникає, коли базовий шлях джерела має вже існуючі набори даних, які позначені як цільовий набір даних SmartSync. А пов'язаний знімок, що використовується для міграції і використовується вихідним записом політики SyncIQ, відрізняється від того, що використовується в останньому наборі даних для конкретного базового шляху джерела.

Помилка 2 виникає, коли базовий шлях джерела має вже існуючі набори даних, які не позначені як цільовий набір даних SmartSync. А пов'язаний знімок, що використовується для міграції і використовується вихідним записом політики SyncIQ, не перебільшує і не дорівнює знімку, який використовується в останньому наборі даних для конкретного базового джерела.

Якщо помилка вже виникла, перейдіть до розділу «Кроки відновлення».

Кроки превентивної міграції

Запобіжні заходи, які слід вжити, поки помилки не проявилися у міграційній справі. Перед початком міграції виконайте наступні кроки, щоб уникнути вищезазначених помилок:

Конфігурація розширення (A → B + A → C)

1. Крок 1: Визначте свою політику SyncIQ Interactive Delivery Services. Приклад:

   1. Політика A → B:
      # isi sync policies view <pol_a_b> | head -2
   2. Політика A → C:
      # isi sync policies view <pol_a_c> | head -2

2. Крок 2: каталог вихідних записів у кластері A:

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

3. Крок 3: Перегляньте та перегляньте XML-файл, що відповідає кожному ідентифікатору політики, і зверніть увагу на значення останнього snap-id:

   1. Перевірте знімок A→B (у наступному кроці отриманий ID буде AX):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Перевірте знімок A→C (отриманий ID буде AY на наступному кроці):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Крок 4: Порівняйте значення найновіших Snap-ID. Спочатку мігруйте політику зі старим (нижчим) найновішим snap-id:
   Якщо знімок з A to B (AX) старіший за знімок з A to C (AY), наприклад: AX = snapID 100,AY = snapID150.
   Потім спочатку мігруйте політику A to B.
   
   Якщо знімок з A to C (AY) старший за знімок з A to B (AX), наприклад: AX = snapID 150,AY = snapID100.
   Потім спочатку мігруйте політику з A на C.
   
   Якщо обидві політики використовують однаковий знімок, наприклад: AX = 100,AY = 100.
   Будь-яку з полісів можна передати спочатку. Друга міграція політики повторно використовує цей набір даних.

Ланцюгова (каскадна) конфігурація (A → B → C)

1. Синхронізація має бути повністю завершена, щоб усі кластери, залучені до ланцюжка політик, відображали ідентичні дані.

2. Вимкніть усі політики SyncIQ у ланцюжку перед міграцією. Це запобігає запуску нових додаткових завдань SyncIQ під час міграції. Наприклад, у ланцюжку A→B→C вимкніть як політики A→B, так і B→C.

3. Важливо: Міграція завжди має починатися з кореневого (вихідного) кластера. Для будь-якого проміжного кластера (наприклад, B у встановленні з 3 кластерами) всі політики, базовий шлях яких також є цільовою для іншої політики SmartSync, повинні використовувати той самий (ідентичний) знімок, що й останній набір даних для цього базового шляху. Якщо знімки не співпадають, завдання міграції буде призупинено (не буде заблоковано назавжди). Кроки відновлення, додані нижче в розділі «Кроки відновлення».

   Перед міграцією ланцюжкових політик переконайтеся, що політика B→C SyncIQ використовує синхронізацію на основі знімків із тим самим шаблоном знімків, який створює політика A→B на кластері B. Це гарантує, що обидві політики мають однаковий базовий рівень знімка на кластері релейного пристрою.

4. Якщо політика B→C SyncIQ спочатку не була налаштована з синхронізацією на основі знімків, оновіть її перед міграцією, використовуючи такі кроки:

   1. Крок 1: Перевірте, що політика A→B створює архівні знімки цілей (Target Snapshot Archive: має відображати Так) з патерном іменування, відмінним від стандартного шаблону іменування 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

      Як ви помітили на наведеному вище прикладі, Target Snapshot Archive встановлений на "No", а шаблон — стандартний з префіксом SIQ-*.

   2. Крок 2: Модифікуйте політику A→ B, щоб створити архівний знімок з іншим шаблоном, відмінним від стандартного:

      # 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: Модифікуйте політику B→C, щоб використовувати --schedule=when-snapshot-taken:

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

   4. Крок 4: Активуйте роботу політики A→B, щоб переконатися, що політика B→C наздоганяє її і повторно використовує архівний знімок, створений A-B>; ви можете перевірити, виконавши команду звітів.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Дочекайтеся, поки робота обох полісів A→B завершиться, і це спровокує роботу політики B→C. Після завершення обох завдань перевірте, що архівний знімок, створений останнім запуском політики A→B, повторно використовується останнім завданням 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>
      

      Як ви помітили вище, останній snap-id для політики B→ C такий самий, як і останній archive-snap для A→ B. Це стан, у якому міграція ланцюжкових полісів має пройтися успішно.

Кроки міграції відновлення

Якщо міграція вже була спробована, а завдання міграції переходить у стан PAUSED, дотримуйтесь цих кроків відновлення:

Конфігурація розширення

Коли завдання міграції політики SyncIQ не завершується з помилкою, відповідна політика SyncIQ повертається назад. Кроки пом'якшення наступних:

1. Крок 1: Запустіть політику SyncIQ, щоб наздогнати:
   # isi sync job start <policy-name>
   
2. Крок 2: Дочекайтеся, поки новий запуск завдання успішно завершиться і з'явиться у звіті:
   # isi sync reports list --policy-name <policy-name>
3. Крок 3: Відновіть роботу міграції SmartSync, яка була призупинена:
   # isi dm jobs resume <job_id>

Ланцюгова (каскадна) конфігурація

Коли завдання міграції політики SyncIQ не завершується з помилкою, відповідна політика SyncIQ повертається назад. Кроки пом'якшення наступних:

1. Крок 1: Змініть політику SyncIQ за допомогою команди:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Крок 2: Запустіть політику A-B> Smart Sync за допомогою команди (припускаючи, що політика upstream вже мігрована):
   # isi dm policies modify <policy_name> --run-now=yes
   Він автоматично синхронізує знімок із останнім знімком набору даних на базовому шляху джерела.
3. Крок 3: Продовжуйте виконання міграції за допомогою команди:
   # isi dm jobs resume <job_id>