Isilon: Які кроки CLI для SyncIQ Failover і Failback

Які кроки CLI для резервного перемикання та відмовки SyncIQ?
Процес UI має покрокову інструкцію, чи існувало щось подібне для CLI?

Детальні кроки щодо проходження FOFB

Посібник CLI для перемикання та відмовлення:

• Керівництво
  з адміністрування CLI PowerScale OneFS 9.5.0.0 Сторінка 271 для 9.5
• Керівництво
  з адміністрування CLI PowerScale OneFS 9.7.0.0 Сторінка 288 для 9.7
• Керівництво
  з адміністрування CLI PowerScale OneFS 9.8.0.0 Сторінка 295 для 9.8
• Керівництво
  з адміністрування CLI PowerScale OneFS 9.9.0.0 Сторінка 296 для 9.9
• PowerScale OneFS 9.10.0.0 Керівництво
  з адміністрування CLI Сторінка 299 для 9.10

Хоча наведена вище документація містить корисну інформацію, нижче наведені кроки більш детальні при виконанні резервного переходу та відмовлення за допомогою CLI.

Кроки нижче використовують термінологію SyncIQ для цих двох термінів:

• КЛАСТЕР ДЖЕРЕЛ = ПЕРВИННИЙ
• ЦІЛЬОВИЙ КЛАСТЕР = ВТОРИННИЙ

ВІДКЛЮЧЕННЯ:

1. У кластері PRIMARY розгляньте можливість запуску domainmark За кілька днів або за кілька тижнів до роботи, якщо це перша спроба переключення на запас для кластера. Якщо набір даних великий, це допомагає заощадити час на прискорення роботи domainmark Фаза роботи.

   Примітка. Нова опція «Прискорена відмова змови» прибирає цей крок. Цей крок має бути виконаний ЛИШЕ один раз. Якщо позначений — майбутнє domainmark Вакансії (див. крок 7 нижче) є безопераційними.

   # isi job jobs start domainmark --root=<path> --dm-type=synciq

   Це позначає кожну LIN відповідним захисним ідентифікатором домену заздалегідь, замість того, щоб завдання аварійного перемикання виконує все (див. крок 7). The domainmark Виконання завдання може займати багато часу залежно від розміру набору даних.

2. Припиніть писати на шлях PRIMARY політики.

   Примітка. Записи на шляху PRIMARY політики, що відбуваються з цього кроку, не зберігаються, що призводить до можливої DL. Переконайтеся, що всі записи на цей шлях НА ОСНОВНОМУ припинилися.

3. У кластері PRIMARY зробіть резервну копію розкладів політик, а потім вимкніть усі розклади, встановивши політики на ручну роботу.

   Щоб зберегти резервну копію розкладів:

   # cat /ifs/.ifsvar/modules/tsm/config/siq-policies.gc|egrep 'common.name|schedule ' >> /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

   Потім вимкніть усі розклади, встановивши політики на ручні режими.

   Примітка. Завдання синхронізації та завдання резервування не можуть виконувати одночасно за задумом і призводять до невдачі спроби переключення на резервування. Щоб уникнути цієї ситуації, встановіть усі політики на ручні режими.

   # isi sync policies modify  --policy=[POLICY] --schedule=""

4. У кластері PRIMARY виконайте останнє завдання синхронізації і переконайтеся, що воно успішно виконано.

   Примітка. Цей крок рекомендується лише при тестуванні функціональності FOFB. НЕ виконуйте цей крок, якщо кластер PRIMARY вже зіткнувся з подією відмови, а кластер SECONDARY вже налаштований на дозвол запису.

   # isi sync jobs start [POLICY]

   Виконайте цю команду, щоб підтвердити успішне виконання:

   # isi sync reports list --reports-per-policy=1
   *Confirm the End time and State=finished

   На PRIMARY кластері виконайте останню синхронізацію.

   # isi sync jobs start [POLICY]

5. У кластері SECONDARY виконайте дію «Дозволити записи» і перевірте, чи локальне завдання виконує цю дію.

   # isi sync recovery allow-write --policy-name=[POLICY]
   # isi sync target list
   Name             Source    Target Path              Last Job State  FOFB State
   -----------------------------------------------------------------------------------
   qtestsync  primary_clust      /ifs/data/siq_quota_test finished        writes_enabled
   -----------------------------------------------------------------------------------
   Total: 1

   ПРИМІТКА. Змінюйте налаштування каталогу SmartLock за потреби в обох кластерах.
   https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

6. Перенаправляйте клієнтів (SMB, NFS, HTTP, FTP тощо) до ВТОРИННОГО кластера

   Примітка. Особливості цього кроку виходять за межі цієї статті і вимагають створення спільних ресурсів SMB, приєднання до домену Active Directory, облікових записів машин, SPN, експорту NFS, перенаправлення DNS SmartConnect та додавання постачальників автентифікації.

7. Створіть знімок відновлення на обох кластерах перед тим, як приступити до підготовки до синхронізації

   ПРО ДЖЕРЕЛО

   # isi snapshot snapshots create --path=[SOURCE_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

   В ЦІЛЬ

   # isi snapshot snapshots create --path=[TARGET_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

8. У кластері PRIMARY виконайте завдання резервування з підготовкою до повторної синхронізації та переконайтеся, що фаза resync_prep_finalize завершена.

   # isi sync recovery resync-prep --policy-name=[POLICY]
   
   # isi sync reports list --policy-name=qtestsync --sort job_id
   Policy Name  Job ID  Start Time          End Time            Action                  State
   ---------------------------------------------------------------------------------------------
   qtestsync    1       2015-02-11T08:31:27 2015-02-11T08:31:34 run                     finished
   qtestsync    2       2015-02-11T08:41:19 2015-02-11T08:41:31 resync_prep             finished
   qtestsync    3       2015-02-11T08:41:31 2015-02-11T08:41:34 resync_prep_domain_mark finished
   qtestsync    4       2015-02-11T08:41:34 2015-02-11T08:41:42 resync_prep_restore     finished
   qtestsync    5       2015-02-11T08:41:42 2015-02-11T08:41:45 resync_prep_finalize    finished

FAILBACK

ls -l /ifs/.ifsvar/modules/tsm/config/source_records/7da67596f099b75ad687a05f6b11781d*

1. Нова політика [POLICY]_mirror на кластері SECONDARY може бути виконана для початку синхронізації з PRIMARY.

   # isi sync jobs start --policy-name=[POLICY]_mirror

2. Припиніть писати на шлях ВТОРИННОЇ політики.

   Примітка. Записи на шляху SECONDARY політик, що відбуваються від цього кроку вперед, не зберігаються, що призводить до можливої DL. Переконайтеся, що всі записи в цей шлях НА ВТОРИННОМУ КАНАЛІ зупинилися.

3. Вимкніть усі розклади, встановивши політики на ручний режим.

   # isi sync policies modify  --policy=[POLICY]_mirror --schedule=""

4. У кластері SECONDARY виконайте останнє завдання синхронізації

   # isi sync jobs start --policy-name=[POLICY]_mirror

5. У кластері PRIMARY виконайте дію «Дозволити записи» і перевірте, чи локальне завдання виконує цю дію.

   # isi sync recovery allow-write --policy-name=[POLICY]_mirror
   # isi sync target list
   Name             Source    Target Path              Last Job State  FOFB State
   -----------------------------------------------------------------------------------
   qtestsync_mirror secondary_clust      /ifs/data/siq_quota_test finished        writes_enabled
   -----------------------------------------------------------------------------------
   Total: 1

   ПРИМІТКА. Змінюйте налаштування каталогу SmartLock за потреби в обох кластерах.
   https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

6. Перенаправляйте клієнтів (SMB, NFS, HTTP, FTP тощо) до кластера PRIMARY

   Примітка. Деталі цього кроку виходять за межі цієї статті і вимагають створення акцій SMB, експорту NFS та перенаправлення SmartConnect DNS.

7. Створіть знімок відновлення на обох кластерах перед тим, як приступити до підготовки до синхронізації

   ПРО ДЖЕРЕЛО

   # isi snapshot snapshots create --path=[SOURCE_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

   В ЦІЛЬ

   # isi snapshot snapshots create --path=[TARGET_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

8. У кластері SECONDARY виконайте завдання відмовки з підготовкою до повторної синхронізації та підтверджіть, що resync_prep_finalize вдалося

   # isi sync recovery resync-prep --policy-name=[POLICY]_mirror
   
   # isi sync reports list --policy-name=[POLICY]_mirror --sort job_id --reports-per-policy=5
   Policy Name  Job ID  Start Time          End Time            Action                  State
   ---------------------------------------------------------------------------------------------
   qtestsync_mirror    1       2015-02-12T08:31:27 2015-02-12T08:31:34 run                     finished
   qtestsync_mirror    2       2015-02-12T08:41:19 2015-02-12T08:41:31 resync_prep             finished
   qtestsync_mirror    3       2015-02-12T08:41:31 2015-02-12T08:41:34 resync_prep_domain_mark finished
   qtestsync_mirror    4       2015-02-12T08:41:34 2015-02-12T08:41:42 resync_prep_restore     finished
   qtestsync_mirror    5       2015-02-12T08:41:42 2015-02-12T08:41:45 resync_prep_finalize    finished

   SECONDARY тепер є ТІЛЬКИ для ЧИТАННЯ, а політика SECONDARY [POLICY]_mirror вимкнена.

   Примітка. Не видаляйте жодних політик дзеркал.

9. Початкові політики на PRIMARY тепер увімкнені. Використовуйте файл резервної копії з кроку 3 FAILOVER, щоб відновити розклади полісів.

   Про ПРАЙМЕРІ:
   Перегляньте збережену копію графіків полісів:

   # cat /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

   Відновіть графіки полісів:

   # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]

10. На оригінальному Вторинному знімку останній знімок SIQ-mirrorpolID<> залишиться після успішного відмови. Вручну очищайте SIQ-mirrorpolID-останній<> знімок, щоб уникнути запису COW у будь-які існуючі знімки на Secondary.

    # isi snapshot snapshots list
    ID   Name                                        Path
    -----------------------------------------------------------------------
    16   SIQ-recovery-policy-Test                    /ifs/data/failovertest
    18   SIQ-005056ac0655f7f5e267a71dae70c997-latest /ifs/data/failovertest  <-- pol_mirror-latest
    24   SIQ-ps9715x1-Test-2025-03-25_19-20-52       /ifs/data/failovertest
    -----------------------------------------------------------------------
    Total: 3
    
    # isi snapshot snapshots delete --id=<id>

Ось приклад кроків тестування, які ігнорують зміни у вторинному кластері після відмововідновлення та зворотного повернення. Виконуються ті самі кроки, за винятком того, що політика дзеркала виконується лише як ПІДГОТОВКА ДО ПОВТОРНОЇ СИНХРОНІЗАЦІЇ, А НЕ ЗВИЧАЙНЕ ЗАВДАННЯ СИНХРОНІЗАЦІЇ з Вторинного на Основне, тому зміни не надсилаються назад до Основного кластера. Переконайтеся, що кожен крок виконано, перш ніж переходити до наступного кроку.

ВІДНОВЛЕННЯ ПІСЛЯ ВІДМОВИ:

1. У кластері PRIMARY розгляньте можливість запуску domainmark на кілька днів або тижнів вперед, якщо це перша спроба відновлення після відмови для кластера. Якщо набір даних великий, це допомагає заощадити час на прискоренні domainmark Фаза роботи.

   Примітка: Це корисно лише для першої в історії спроби відновлення після відмови. Подальші спроби відновлення після відмови вже не приносять користі цьому.

   # isi job jobs start domainmark --root=<path> --dm-type=synciq

   Це позначає кожен LIN відповідним захисним ідентифікатором домену заздалегідь, а не змушує відмовостійкий завдання виконувати все (див. крок 7). Об'єкт domainmark Робота може зайняти багато часу в залежності від розміру набору даних.

2. Припиніть будь-який запис на шлях ОСНОВНОЇ політики.

   Примітка: Записи на шляху ПЕРВИННИХ політик, які відбуваються з цього кроку вперед, не зберігаються , що призводить до можливого DL. Підтвердіть у клієнта , що всі записи на той шлях НА ОСНОВНОМУ припинилися.

3. У кластері PRIMARY створіть резервну копію розкладів політик, а потім вимкніть усі розклади, встановивши політики на ручний.

   Щоб зберегти резервну копію розкладів:

   # cat /ifs/.ifsvar/modules/tsm/config/siq-policies.gc|egrep 'common.name|schedule ' >> /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

   Потім вимкніть усі розклади, встановивши політики на ручні.

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

   # isi sync policies modify  --policy=[POLICY] --schedule=""

4. У кластері PRIMARY запустіть останнє завдання синхронізації та переконайтеся, що воно успішно завершено.

   Примітка: Цей крок рекомендований лише у випадку, якщо ви тестуєте функціональність FOFB. НЕ виконуйте цей крок, якщо ОСНОВНИЙ кластер вже зіткнувся з подією збою, а ВТОРИННИЙ кластер вже налаштований на дозвіл запису.

   # isi sync jobs start [POLICY]

   Виконайте цю команду, щоб підтвердити успішне завершення:

   # isi sync reports list --reports-per-policy=1
   *Confirm the End time and State=finished

   У кластері PRIMARY запустіть останнє завдання синхронізації.

   # isi sync jobs start [POLICY]

5. У ДОДАТКОВОМУ кластері виконайте дію «Дозволити запис» і переконайтеся, що локальне завдання завершило цю дію.

   # isi sync recovery allow-write --policy-name=[POLICY]
   # isi sync target list
   Name             Source    Target Path              Last Job State  FOFB State
   -----------------------------------------------------------------------------------
   qtestsync  primary_clust      /ifs/data/siq_quota_test finished        writes_enabled
   -----------------------------------------------------------------------------------
   Total: 1

6. Перенаправляйте клієнтів (SMB, NFS, HTTP, FTP і так далі) на ВТОРИННИЙ кластер

   Примітка: Специфіка цього кроку виходить за рамки цієї статті та вимагає створення спільних ресурсів SMB, приєднання до домену Active Directory, облікових записів машин, експорту SPN, NFS, переспрямування DNS SmartConnect і додавання постачальників автентифікації.

7. У кластері PRIMARY виконайте завдання з відновлення після відмови з підготовкою повторної синхронізації та підтвердьте, що етап resync_prep_finalize завершено.

   # isi sync recovery resync-prep --policy-name=[POLICY]

   # isi sync reports list --policy-name=qtestsync --sort job_id
   Policy Name  Job ID  Start Time          End Time            Action                  State
   ---------------------------------------------------------------------------------------------
   qtestsync    1       2015-02-11T08:31:27 2015-02-11T08:31:34 run                     finished
   qtestsync    2       2015-02-11T08:41:19 2015-02-11T08:41:31 resync_prep             finished
   qtestsync    3       2015-02-11T08:41:31 2015-02-11T08:41:34 resync_prep_domain_mark finished
   qtestsync    4       2015-02-11T08:41:34 2015-02-11T08:41:42 resync_prep_restore     finished
   qtestsync    5       2015-02-11T08:41:42 2015-02-11T08:41:45 resync_prep_finalize    finished

ЗВОРОТНИЙ ЗВ'ЯЗОК

ПРОПУСТІТЬ КРОКИ 1 І 4 (ВИДАЛЕНІ НИЖЧЕ), ЯКЩО ВИ НЕ ХОЧЕТЕ, ЩОБ ЗМІНИ НАДСИЛАЛИСЯ НАЗАД ДО PRIMARY ДЛЯ ТЕСТУ.

Нову політику [POLICY]_mirror на кластері SECONDARY можна запустити, щоб почати синхронізацію назад до ОСНОВНОГО.

1. Припиніть будь-який запис на шлях ВТОРИННОЇ політики.

2. Вимкніть усі розклади, встановивши політики на ручні.

   # isi sync policies modify  --policy=[POLICY]_mirror --schedule=""

3. У кластері PRIMARY виконайте дію «Дозволити запис» і переконайтеся, що локальне завдання завершило цю дію.

   # isi sync recovery allow-write --policy-name=[POLICY]_mirror
   # isi sync target list
   Name             Source    Target Path              Last Job State  FOFB State
   -----------------------------------------------------------------------------------
   qtestsync_mirror secondary_clust      /ifs/data/siq_quota_test finished        writes_enabled
   -----------------------------------------------------------------------------------
   Total: 1

4. Перенаправляйте клієнтів (SMB, NFS, HTTP, FTP і так далі) в ОСНОВНИЙ кластер

   Примітка: Специфіка цього кроку виходить за рамки цієї бази даних і вимагає створення спільних ресурсів SMB, експорту NFS та перенаправлення DNS SmartConnect.

5. У ВТОРИННОМУ кластері виконайте завдання зворотного зв'язку з підготовкою повторної синхронізації та підтвердіть, що resync_prep_finalize вдалося

   # isi sync recovery resync-prep --policy-name=[POLICY]_mirror
   
   # isi sync reports list --policy-name=qtestsync_mirror --sort job_id
   Policy Name  Job ID  Start Time          End Time            Action                  State
   ---------------------------------------------------------------------------------------------
   qtestsync_mirror    1       2015-02-12T08:31:27 2015-02-12T08:31:34 run                     finished
   qtestsync_mirror    2       2015-02-12T08:41:19 2015-02-12T08:41:31 resync_prep             finished
   qtestsync_mirror    3       2015-02-12T08:41:31 2015-02-12T08:41:34 resync_prep_domain_mark finished
   qtestsync_mirror    4       2015-02-12T08:41:34 2015-02-12T08:41:42 resync_prep_restore     finished
   qtestsync_mirror    5       2015-02-12T08:41:42 2015-02-12T08:41:45 resync_prep_finalize    finished

   Політика SECONDARY тепер доступна лише для читання, а політика SECONDARY [POLICY]_mirror вимкнена.

   Примітка: Не видаляйте жодних дзеркальних політик.

6. Початкові політики на PRIMARY тепер увімкнено. Використовуйте файл резервної копії з кроку 3 FAILOVER, щоб відновити розклад політик. На ПРАЙМЕРІЗ:

   Перегляньте збережену копію розкладів політик:

   # cat /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

   Відновіть графіки політики:

   # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]