Домен даних: Посібник з оновлення ОС для систем високої доступності (HA)
摘要: Огляд процесу оновлення операційної системи домену даних (DDOS) на пристроях «високої доступності» (DDHA) домену даних.
说明
Щоб скоротити запланований час простою на технічне обслуговування, в архітектуру HA включено оновлення системи rolling. Послідовне оновлення може спочатку оновити резервний вузол, а потім використовувати очікуване відновлення 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 з'явиться у списку.
- Будь ласка, запустіть попередню перевірку на активному вузлі. Оновлення слід перервати, якщо виникне будь-яка помилка.
Будь ласка, також вимкніть GC, переміщення даних та реплікацію перед початком оновлення (крок #6), щоб ці завдання не призводили до збільшення часу вимкнення DDFS під час оновлення. Коротший час вимкнення DDFS допоможе мінімізувати наслідки для клієнтів. Ці робочі навантаження не впливають на операції резервного копіювання/відновлення клієнтів.
Залежно від потреб, ці служби можна відновити після завершення оновлення за допомогою відповідних команд увімкнення. Будь ласка, зверніться до посібника з адміністрування для отримання більш детальної інформації.
У посібнику з адміністрування описано деякі інші ручні перевірки та команди, які не є строго необхідними для системи HA. Попереднє перезавантаження в даний час пропонується як тест для систем з одним вузлом. Він не потрібен для систем HA, оскільки #5 "ha failover" нижче вже включає автоматичне перезавантаження під час процесу відновлення після відмови.
- Необов'язково. Перед запуском віялового оновлення рекомендується двічі виконати відмовостійкість HA вручну на активному вузлі. Метою є перевірка функціональності відмовостійкості. Операція призведе до перезавантаження активного вузла, будь ласка, майте це на увазі.
По-перше, підготуйтеся до відновлення після відмови, вимкнувши GC, переміщення даних і реплікацію. Будь ласка, зверніться до посібника з адміністрування, щоб дізнатися, як це зробити за допомогою графічного інтерфейсу. Ці служби не впливають на робочі навантаження резервного копіювання/відновлення клієнтів. Потім дійте "ha failover".

(Коли статус системи HA знову стане «високодоступним», будь ласка, виконайте другий «ha failover» і зачекайте, поки обидва вузли почнуть підключатися)
Після відновлення аварійного ремонту HA зупинені служби можна відновити за допомогою відповідних команд увімкнення. Будь ласка, зверніться до посібника з адміністрування для отримання більш детальної інформації.
Наведені вище перевірки відмови є необов'язковими і не обов'язково проводитися безпосередньо перед оновленням. Тести на відмову можуть бути проведені до оновлення, наприклад, за два тижні, щоб можна було використовувати менший період обслуговування для подальшого оновлення. Час простою служби DDFS для кожного відновлення після відмови становить близько 10 хвилин (менше або більше залежно від версій DDOS та деяких інших факторів). Версії DDOS 7.4 і пізніші матимуть менше простоїв до випуску завдяки постійному вдосконаленню DDOS SW.
- Якщо попередня перевірка завершена без проблем, продовжуйте послідовне оновлення на активному вузлі.
- Будь ласка, дочекайтеся завершення оновлення. Перед цим, будь ласка, не ініціюйте будь-яку операцію відновлення після відмови 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 не працює протягом періоду відновлення після відмови. Спостерігаючи за виведенням команди "fileys 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”)
системний пакет Список пакетів Active-node # системи
File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- -------
- Будь ласка, запустіть попередню перевірку на активному вузлі. Оновлення слід перервати, якщо виникне будь-яка помилка.
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. Попереднє перезавантаження в даний час пропонується як тест для систем з одним вузлом. Він не потрібен для систем HA, оскільки #5 "ha failover" нижче вже включає автоматичне перезавантаження під час процесу відновлення після відмови.
- Необов'язково. Перед запуском віялового оновлення рекомендується двічі виконати відмовостійкість 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
А потім виконати команду failover:
Active-node # ha failoverЦя операція ініціює відновлення після відмови з цього вузла. Локальний вузол перезавантажиться.
Бажаєте продовжити? (так|ні) [ні]: так
Ініційовано операцію відновлення після відмови. Запустіть 'ha status', щоб відстежувати статус
(Коли статус системи HA знову стане «високодоступним», будь ласка, виконайте другий «ha failover» і зачекайте, поки обидва вузли почнуть підключатися)
Після відновлення аварійного ремонту HA зупинені служби можна відновити за допомогою відповідних команд увімкнення. Будь ласка, зверніться до посібника з адміністрування для отримання більш детальної інформації.
Наведений вище тест на відмову є необов'язковим і не обов'язково проводитися безпосередньо перед оновленням. Тести на відмову можуть бути проведені до оновлення, наприклад, за два тижні, щоб можна було використовувати менший період обслуговування для подальшого оновлення. Час простою служби DDFS для кожного відновлення після відмови становить близько 10 хвилин (менше або більше залежно від версій DDOS та деяких інших факторів). У DDOS версії 7.4 і пізніших буде менше простоїв до випуску завдяки постійному вдосконаленню DDOS SW.
- Якщо попередня перевірка завершена без проблем, продовжуйте послідовне оновлення на активному вузлі.
Active-node # system upgrade start <rpm file> Команда «оновлення системи» оновлює ОС 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 успішно завершено.
Примітка: Якщо у вас виникнуть проблеми з оновленням, зверніться до служби підтримки Data domain для отримання подальших інструкцій і підтримки.
ЛОКАЛЬНЕ ОНОВЛЕННЯ для пари 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, резервний вузол (у цьому випадку це node1) відключений, статус 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 успішно завершено.
其他信息
Віялова модернізація:
-
Зауважте, що під час оновлення виконується одиночне відновлення після відмови, тому ролі поміняються місцями
-
Інформація про оновлення продовжує зберігатися в infra.log році, але в ha.log може з'явитися додаткова інформація
-
Прогрес оновлення можна відстежувати за допомогою годинника оновлення системи
Оновлення локального вузла:
-
Оновлення локального вузла не виконує відмовостійкість HA
-
Як наслідок, це буде тривалий період простою, поки активний вузол оновлюється/перезавантажується/виконує дії після оновлення перезавантаження, що, швидше за все, призведе до того, що час очікування резервного копіювання/відновлення закінчиться та вийде з ладу. Вимагайте виділення часового вікна обслуговування для локального оновлення.
-
Навіть стан системи HA «погіршується», можна продовжувати локальне оновлення.
-
З якоїсь причини rolling upgrade може вийти з ладу несподівано. Локальний апгрейд можна розглядати як метод виправлення в цій ситуації.