DataDomain: Посібник з оновлення ОС для систем з високою доступністю (HA)
Summary: Огляд процесу оновлення системи операцій домену даних (DDOS) на пристроях домену даних «Високодоступні» (DDHA).
Instructions
Для скорочення запланованого простою з обслуговування в архітектуру HA включено системне оновлення. Поточне оновлення може спочатку оновити резервний вузол, а потім використати очікуване резервування HA для переміщення сервісів з активного вузла до резервного вузла. Нарешті, попередні активні вузли будуть оновлені і повернуться до кластера HA як резервний вузол. Усі процеси виконуються в одній команді.
Альтернативним підходом до ручного оновлення є «локальне оновлення». Спочатку ручно оновіть резервний вузол, а потім активний — вручну. Нарешті, резервний вузол знову приєднається до кластера HA. Локальне оновлення можна виконувати як для звичайного оновлення, так і для вирішення проблем
.Усі операції оновлення системи на активному вузлі вимагають перетворення даних, можливо, не починаються, доки обидві системи не будуть оновлені до одного рівня і стан HA не буде повністю відновлений.
DDOS 5.7 і далі підтримує два типи способів оновлення систем HA:
-
Rolling upgrade — автоматично оновлюйте обидва вузли HA однією командою. Після оновлення сервіс переміщується на інший вузол.
-
Локальне оновлення — вручну оновлюйте вузли HA по одному. Після оновлення сервіс зберігається в тому ж вузлі.
Підготуйте систему до оновлення:
-
Будь ласка, переконайтеся, що статус системи HA є «дуже доступним».
Login GUI à Home à Dashboard
- Файл DDOS RPM слід розмістити на активному вузлі, і оновлення має починатися саме з цього вузла.
Login GUI à Home à Dashboard
- Завантажити файл RPM на активний вузол
Після завантаження файл RPM буде перелічено.
- Будь ласка, запустіть precheck на активному вузлі. Оновлення слід припинити, якщо виникне будь-яка помилка.
Будь ласка, також вимкніть GC, переміщення даних і реплікацію перед початком оновлення (крок #6), щоб ці завдання не призвели до довшого часу вимкнення DDFS під час оновлення. Коротший час закриття DDFS допоможе мінімізувати вплив на клієнтів. Ці навантаження не впливають на операції резервного копіювання/відновлення клієнта.
Залежно від потреб, ці послуги можуть бути відновлені після завершення оновлення за допомогою відповідних команд увімкненняment . Будь ласка, зверніться до керівництва з адміністрування для отримання додаткової інформації.
У адміністративному посібнику описані інші ручні перевірки та команди, які не є строго обов'язковими для системи HA. Pre-reboot наразі рекомендується як тест для одновузлових систем. Вона не потрібна для систем HA, оскільки #5 "ha failover" нижче вже включає автоматичне перезавантаження під час процесу відмовлення.
- Необов'язково. Перед запуском rolling upgrade рекомендується двічі зробити аварійне перемикання HA вручну на активному вузлі. Мета — перевірити функціональність аварійного перемикання. Операція перезавантажить активний вузол, будь ласка, зверніть на це увагу.
По-перше, готуйтеся до перемикання в резерв, вимкнувши GC, переміщення даних і реплікацію. Будь ласка, зверніться до керівництва з адміністрування, щоб дізнатися, як це зробити через графічний інтерфейс. Ці сервіси не впливають на навантаження на резервне копіювання/відновлення клієнтів. Потім продовжуйте "ha failover".
(Коли статус системи HA знову стане «високо доступним», будь ласка, виконайте друге «ha failover» і чекайте, поки обидва вузли стануть онлайн)
Після аварійного перемикання HA зупинені сервіси можна відновити за допомогою відповідних команд увімкнення. Будь ласка, ознайомтеся з керівництвом з адмініструванням для отримання додаткової інформації.
Вищезазначені тести на відключення є необов'язковими і не обов'язково проводяться безпосередньо перед оновленням. Тести на відключення можуть бути проведені до оновлення, наприклад, за два тижні, щоб для подальшого оновлення можна було використати менше вікно обслуговування. Час простою сервісу DDFS при кожному резервному режимі становить близько 10 хвилин (менше або більше залежно від версій DDOS та деяких інших факторів). Версії DDOS 7.4 і новіші матимуть менше простоїв за релізом завдяки постійним покращенням DDOS SW.
- Якщо precheck завершився без проблем, продовжуйте кидати оновлення на активному вузлі.
- Будь ласка, зачекайте на фініш оновлення. Перед цим будь ласка, не запускайте жодну аварійну операцію HA.
Доступність DDFS під час вищезазначеного командування:
-
Спочатку оновить резервний вузол і перезавантажить його до нової версії. Це займає приблизно від 20 до 30 хвилин залежно від різних факторів. Сервіс DDFS працює і працює на активному вузлі протягом цього періоду без погіршення продуктивності.
-
Після застосування нового DDOS система переключить сервіс DDFS на оновлений резервний вузол. Це займає приблизно 10 хвилин (менше або більше залежно від різних факторів).
-
Важливим фактором є оновлення DAE FW. Це може призвести до ~20 хвилин більше простою залежно від кількості налаштованих DAE. Будь ласка, зверніться до бази знань «Домен даних»: Оновлення HA Rolling може не спрацювати для зовнішнього оновлення прошивки корпусу», щоб визначити, чи потрібне оновлення DAE FW. Зверніть увагу, що починаючи з DDOS 7.5, з'явилося покращення для онлайн-оновлення DAE FW, що усуває цю проблему.
-
Можна звернутися до підтримки Dell для обговорення факторів, які можуть впливати на час оновлення. Залежить від клієнтської ОС, додатка та протоколу між клієнтом і системою HA, іноді користувачу може знадобитися вручну відновити клієнтські навантаження одразу після резервного переключення. Наприклад, якщо з клієнтами DDBoost час відмовлення перевищує 10 хвилин, то клієнт має відновити навантаження вручну. Але зазвичай на клієнтах доступні налаштування для встановлення значень тайм-ауту та часу повторних спроб.
-
Зверніть увагу, що сервіс DDFS не працює під час періоду резервування. Спостерігаючи за результатом команди "filesys status" на оновленому вузлі, можна дізнатися, чи відновлено сервіс DDFS. Очікується, що версії DDOS на версії 7.4 і новіших матимуть все менше простоїв через покращення коду DDOS.
Після резервування вже активний вузол буде оновлено. Після застосування оновлення він перезавантажиться до нової версії, а потім знову приєднається до кластера HA як резервний вузол. Сервіс DDFS не зазнає впливу під час цього процесу, оскільки його вже відновили у #II вище.
Верифікація:
- Після завершення регулярного оновлення потрібен графічний інтерфейс входу через IP-адресу попереднього резервного вузла, у цьому випадку це node1.
- Будь ласка, перевірте, чи є несподівані сповіщення.
- На цьому етапі оновлення Rolling успішно завершено.
Постійне оновлення через CLI:
Підготуйте систему до оновлення:
- Будь ласка, переконайтеся, що статус системи HA є «дуже доступним».
#ha status
HA System name: HA-system
HA System status: highly available ç
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online
Node1 1 standby online
----------------------------- ------- ------- --------
- Файл DDOS RPM слід розмістити на активному вузлі, і оновлення має починатися саме з цього вузла.
#ha status
HA System name: HA-system
HA System status: highly available
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online ß Node0 is active node
Node1 1 standby online
----------------------------- ------- ------- --------
- Завантажити файл RPM на активний вузол
Client-server # scp <rpm file> sysadmin@HA-system.active_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
про пакет системи Активний вузол # список пакетів системи
File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- -------
- Будь ласка, запустіть precheck на активному вузлі. Оновлення слід припинити, якщо виникне будь-яка помилка.
Active-node # system upgrade precheck <rpm file>
Upgrade precheck in progress:
Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
Будь ласка, також вимкніть GC, переміщення даних і реплікацію перед початком оновлення (крок #6), щоб ці завдання не призвели до довшого часу вимкнення DDFS під час оновлення. Коротший час закриття DDFS допоможе мінімізувати вплив на клієнтів. Ці навантаження не впливають на операції резервного копіювання/відновлення клієнта. Залежно від потреб, ці послуги можна відновити після завершення оновлення за допомогою відповідних команд активації. Будь ласка, зверніться до керівництва з адміністрування для отримання додаткової інформації.
Active-node # filesys clean stop
Active-node # cloud clean stop
Active-node # data-movement suspend
Active-node # data-movement stop to-tier active
Active-node # replication disable all
Зверніть увагу, що існує кілька команд «watch», які перевіряють, чи виконані вищезазначені операції.
Active-node # filesys clean watch
Active-node # cloud clean watch
Active-node # data-movement watch
У адміністративному посібнику описані інші ручні перевірки та команди, які не є строго обов'язковими для системи HA. Pre-reboot наразі рекомендується як тест для одновузлових систем. Вона не потрібна для систем HA, оскільки #5 "ha failover" нижче вже включає автоматичне перезавантаження під час процесу відмовлення.
- Необов'язково. Перед запуском rolling upgrade рекомендується двічі зробити аварійне перемикання HA вручну на активному вузлі. Мета — перевірити функціональність аварійного перемикання. Операція перезавантажить активний вузол, будь ласка, зверніть на це увагу.
По-перше, готуйтеся до перемикання в резерв, вимкнувши GC, переміщення даних і реплікацію. Ці сервіси не впливають на навантаження на резервне копіювання/відновлення клієнтів. Потім запусти "ha failover".
Команди для цього такі:
Active-node # filesys clean stop
Active-node # cloud clean stop
Active-node # data-movement suspend
Active-node # data-movement stop to-tier active
Active-node # replication disable all
Зверніть увагу, що існує кілька команд «watch», які перевіряють, чи виконані вищезазначені операції.
Active-node # filesys clean watch
Active-node # cloud clean watch
Active-node # data-movement watch
А потім виконайте команду резервування:
Active-node # ha failoverЦя операція ініціює резервування з цього вузла. Локальний вузол перезавантажиться.
Хочеш продовжити? (так|ні) [ні]: так
Запущено аварійну операцію. Запустіть 'ha status' для моніторингу статусу
(Коли статус системи HA знову стане «високо доступним», будь ласка, виконайте друге «ha failover» і чекайте, поки обидва вузли стануть онлайн)
Після аварійного перемикання HA зупинені сервіси можна відновити за допомогою відповідних команд увімкнення. Будь ласка, ознайомтеся з керівництвом з адмініструванням для отримання додаткової інформації.
Вищезазначені тести на переключення є необов'язковими і не обов'язково проводяться безпосередньо перед оновленням. Тести на відключення можуть бути проведені до оновлення, наприклад, за два тижні, щоб для подальшого оновлення можна було використати менше вікно обслуговування. Час простою сервісу DDFS для кожного резервного перемикання становить близько 10 хвилин (менше або більше залежно від версій DDOS та деяких інших факторів). DDOS версії 7.4 і пізніші матимуть менше простоїв за релізом завдяки постійним покращенням DDOS SW.
- Якщо precheck завершився без проблем, продовжуйте кидати оновлення на активному вузлі.
Active-node # system upgrade start <rpm file> Команда 'system upgrade' оновлює операційну систему Data Domain. Доступ
до файлів переривається під час оновлення. Система автоматично
перезавантажується Після оновлення.
Are you sure? (yes|no) [no]: yes ok, proceeding. Upgrade in progress: Node Severity Issue Solution ---- -------- ------------------------------ -------- 0 WARNING 1 component precheck script(s) failed to complete 0 INFO Upgrade time est: 60 mins 1 WARNING 1 component precheck script(s) failed to complete 1 INFO Upgrade time est: 80 mins ---- -------- ------------------------------ -------- Node 0: phase 2/4 (Install 0%) , Node 1: phase 1/4 (Precheck 100%) Upgrade phase status legend: DU : Data Upgrade FO : Failover .. PC : Peer Confirmation VA : Volume Assembly Node 0: phase 3/4 (Reboot 0%) , Node 1: phase 4/4 (Finalize 5%) FO Upgrade has started. System will reboot.
Доступність DDFS під час вищезазначеного командування:
-
Спочатку оновить резервний вузол і перезавантажить його до нової версії. Це займає приблизно від 20 до 30 хвилин залежно від різних факторів. Сервіс DDFS працює і працює на активному вузлі протягом цього періоду без погіршення продуктивності.
-
Після застосування нового DDOS система переключить сервіс DDFS на оновлений резервний вузол. Це займає приблизно 10 хвилин (менше або більше залежно від різних факторів).
-
Важливим фактором є оновлення DAE FW. Це може призвести до ~20 хвилин більше простою залежно від кількості налаштованих DAE. Будь ласка, зверніться до бази знань «Домен даних»: Оновлення HA Rolling може не спрацювати для зовнішнього оновлення прошивки корпусу», щоб визначити, чи потрібне оновлення DAE FW. Зверніть увагу, що починаючи з DDOS 7.5, з'явилося покращення для онлайн-оновлення DAE FW, що усуває цю проблему.
-
Можна звернутися до підтримки Dell для обговорення факторів, які можуть впливати на час оновлення. Залежить від клієнтської ОС, додатка та протоколу між клієнтом і системою HA, іноді користувачу може знадобитися вручну відновити клієнтські навантаження одразу після резервного переключення. Наприклад, якщо з клієнтами DDBoost час відмовлення перевищує 10 хвилин, то клієнт має відновити навантаження вручну. Але зазвичай на клієнтах доступні налаштування для встановлення значень тайм-ауту та часу повторних спроб.
-
-
Після резервування вже активний вузол буде оновлено. Після застосування оновлення він перезавантажиться до нової версії, а потім знову приєднається до кластера HA як резервний вузол. Сервіс DDFS не зазнає впливу під час цього процесу, оскільки його вже відновили у #II вище.
- Після перезавантаження резервного вузла (node1) можна увійти в резервний вузол для моніторингу стану/прогресу оновлення.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade In Progress
Node 0: phase 3/4 (Reboot 0%)
Node 1: phase 4/4 (Finalize 100%) waiting for peer confirmation
- Будь ласка, зачекайте на фініш оновлення. Перед цим будь ласка, не запускайте жодну аварійну операцію HA.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Будь ласка, перевірте статус HA, обидва вузли онлайн, статус системи HA — «високо доступний».
Node1 # ha status detailed
HA System name: HA-system
HA System Status: highly available
Interconnect Status: ok
Primary Heartbeat Status: ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check: ok
Node Node1:
Role: active
HA State: online
Node Health: ok
Node Node0:
Role: standby
HA State: online
Node Health: ok
Mirroring Status:
Component Name Status
-------------- ------
nvram ok
registry ok
sms ok
ddboost ok
cifs ok
-------------- ------
Верифікація:
- Будь ласка, перевірте, чи обидва вузли мають однакову версію DDOS.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version
Data Domain OS x.x.x.x-12345
- Будь ласка, перевірте, чи є несподівані сповіщення.
Node1 # alert show current
Node0 # alert show current
- На цьому етапі оновлення Rolling успішно завершено.
Примітка: Якщо у вас виникли проблеми з оновленням, будь ласка, звертайтеся до служби підтримки домену даних для подальших інструкцій та підтримки.
МІСЦЕВЕ ОНОВЛЕННЯ для пари DDHA:
Локальне оновлення загалом функціонує так:
Підготуйте систему до оновлення:
- Перевірте стан системи HA. Навіть якщо статус погіршується, локальне оновлення може допомогти в цій ситуації.
#ha status HA System name: HA-system HA System status: highly available <- Node Name Node id Role HA State ----------------------------- ------- ------- -------- Node0 0 active online Node1 1 standby online ----------------------------- ------- ------- --------
- DDoS-файл RPM має розміщуватися на обох вузлах, а оновлення має починатися з резервного вузла.
#ha status
HA System name: HA-system
HA System status: highly available
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online
Node1 1 standby online <- Node1 is standby node
----------------------------- ------- ------- --------
- Завантажте файл RPM на обидва вузли.
Client-server # scp <rpm file> sysadmin@HA- system.active_node:/ddr/var/releases/
Client-server # scp <rpm file> sysadmin@HA-system.standby_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
Active-node # system package list File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- ------ Standby-node # system package list File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- ------
- Будь ласка, запустіть попередню перевірку на активному вузлі, чи статус HA 'дуже доступний'. Оновлення слід припинити, якщо виникне будь-яка помилка.
Active-node # system upgrade precheck <rpm file>
Upgrade precheck in progress: Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%) Upgrade precheck found no issues.
Якщо статус HA «деградований», потрібно зробити попередню перевірку на обох вузлах.
Active-node # system upgrade precheck <rpm file> local
Upgrade precheck in progress:
Node 0: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
Standby-node # system upgrade precheck <rpm file> local
Upgrade precheck in progress:
Node 1: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
- Вимкніть резервний вузол.
Standby-node # ha offline
This operation will cause the ha system to no longer be highly available.
Do you want to proceed? (yes|no) [no]: yes
Standby node is now offline.
(ПРИМІТКА: Якщо офлайн-робота не вдалася або статус HA погіршився, будь ласка, продовжуйте локальне оновлення, оскільки наступні кроки можуть вирішувати збої.)
- Переконайтеся, що статус узла очікування офлайн.
Standby-node # ha status
HA System name: HA-system
HA System status: degraded
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node1 1 standby offline
Node0 0 active degraded
----------------------------- ------- ------- --------
- Виконайте оновлення на резервному вузлі. Ця операція викликає перезавантаження резервного вузла.
Команда 'system upgrade' оновлює операційну систему Data Domain. Доступ
до файлів переривається під час оновлення. Система автоматично
перезавантажується Після оновлення.
Ти впевнений? (так|ні) [ні]: так
Добре, продовжую.
«Локальний» прапорець є дуже шкідливим для систем HA, і його слід використовувати лише для ремонту.
Ти впевнений? (так|ні) [ні]: так
Добре, продовжую.
Оновлення в процесі:
Вузол 1: фаза 3/4 (перезавантаження 0%)
Оновлення почалося. Система перезавантажиться.
- Резервний вузол перезавантажиться у новій версії DDOS, але залишиться офлайн.
- Будь ласка, перевірте статус оновлення системи, оновлення ОС може зайняти більше 30 хвилин.
Standby-node # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Будь ласка, перевірте статус системи HA: резервний вузол (у цьому випадку це вузол 1) офлайн, статус HA — «деградований».
Standby-node # ha status
HA System name: HA-system
HA System status: degraded
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node1 1 standby offline
Node0 0 active degraded
----------------------------- ------- ------- --------
- Виконайте локальне оновлення активного вузла. Ця операція перезавантажить активний вузол.
Active-node # system upgrade start <rpm file> local
The 'system upgrade' command upgrades the Data Domain OS. File access
is interrupted during the upgrade. The system reboots automatically
after the upgrade.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
The 'local' flag is highly disruptive to HA systems and should be used only as a repair operation.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
Upgrade in progress:
Node Severity Issue Solution
---- -------- ------------------------------ --------
0 WARNING 1 component precheck
script(s) failed to complete
0 INFO Upgrade time est: 60 mins
---- -------- ------------------------------ --------
Node 0: phase 3/4 (Reboot 0%)
Upgrade has started. System will reboot.
- Будь ласка, перевірте статус оновлення системи, оновлення ОС може зайняти більше 30 хвилин.
Active-node # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Після завершення оновлення активного вузла статус системи HA все одно погіршується. Виконайте наступну команду, щоб зробити резервний вузол онлайн, він перезавантажить вершину очікування.
Standby-node # ha online The operation will reboot this node. Do you want to proceed? (yes|no) [no]: yes Broadcast message from root (Wed Oct 14 22:38:53 2020): The system is going down for reboot NOW! **** Error communicating with management service.(ПРИМІТКА: Якщо 'ha offline' не було запущено на попередніх кроках, будь ласка, ігноруйте цей крок)
- Резервний вузол перезавантажиться і знову приєднається до кластера. Після цього статус HA знову стане «дуже доступним».
Active-node # ha status detailed
HA System name: Ha-system
HA System Status: highly available
Interconnect Status: ok
Primary Heartbeat Status: ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check: ok
Node node0:
Role: active
HA State: online
Node Health: ok
Node node1:
Role: standby
HA State: online
Node Health: ok
Mirroring Status:
Component Name Status
-------------- ------
nvram ok
registry ok
sms ok
ddboost ok
cifs ok
-------------- ------
Верифікація:
- Будь ласка, перевірте, чи обидва вузли мають однакову версію DDOS.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version
Data Domain OS x.x.x.x-12345
- Будь ласка, перевірте, чи є несподівані сповіщення.
Node1 # alert show current
Node0 # alert show current
- На цьому етапі оновлення Rolling успішно завершено.
Additional Information
Оновлення з рухомим ходом:
-
Зверніть увагу, що під час оновлення виконується один резерв, тому ролі змінюються місцями
-
Інформація про оновлення продовжує зберігатися у infra.log, але може з'явитися додаткова інформація в ha.log
-
Прогрес оновлень можна відстежувати через watch оновлення системи
Оновлення локального вузла:
-
Оновлення локального вузла не виконує резервування HA
-
Внаслідок цього буде тривалий період простою, поки активний вузол оновлює/перезавантажується/виконує операції після перезавантаження, що, ймовірно, призведе до тайм-ауту резервних копій/відновлень. Вимагайте виділення часу на обслуговування для локального оновлення.
-
Навіть статус системи HA — «деградований», можна продовжити локальне оновлення.
-
З якоїсь причини оновлення може несподівано вийти з ладу. Локальне оновлення можна розглядати як метод виправлення в такій ситуації.