Домен даних: Посібник з оновлення ОС для систем високої доступності (HA)

Summary: Огляд процесу оновлення операційної системи домену даних (DDOS) на пристроях «високої доступності» (DDHA) домену даних.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Планове технічне обслуговування системи HA

Щоб скоротити запланований час простою на технічне обслуговування, в архітектуру HA включено оновлення системи rolling. Послідовне оновлення може спочатку оновити резервний вузол, а потім використовувати очікуване відновлення HA для переміщення служб з активного вузла на резервний вузол. Нарешті, попередні активні вузли будуть модернізовані та знову приєднаються до кластера HA як резервний вузол. Всі процеси виконуються в одній команді.
Альтернативним підходом до ручного оновлення є «локальне оновлення». Спочатку вручну оновіть резервний вузол, а потім вручну оновіть активний вузол.  Нарешті, резервний вузол знову приєднається до кластера HA. Локальне оновлення може виконуватися як для регулярного оновлення, так і для виправлення проблем.
Всі операції по оновленню системи на активному вузлі, що вимагають перетворення даних, можуть не початися до тих пір, поки обидві системи не будуть оновлені до одного рівня і стан HA не буде повністю відновлено.


DDOS 5.7 і далі підтримують два види методів модернізації систем HA:

  • Rolling upgrade - автоматичне оновлення обох вузлів HA однією командою. Після оновлення сервіс переноситься на інший вузол.

  • Локальне оновлення - вручну оновлюйте вузли HA один за одним. Сервіс зберігається в тому ж вузлі після оновлення.

 

Послідовне оновлення за допомогою графічного інтерфейсу:

Підготуйте систему до оновлення:

  1. Будь ласка, переконайтеся, що статус системи HA «високодоступний».

 Login GUI à Home à Dashboard

Сторінка інформаційної панелі
  1. DDOS RPM-файл повинен бути розміщений на активному вузлі, і оновлення повинно починатися з цього вузла.
- Як знайти активний вузол:
  Login GUI à Home à Dashboard

Сторінка інформаційної панелі               
 
  1. Завантажте файл RPM на активний вузол
Графічний інтерфейс для входу à Обслуговування à Система à Натисніть кнопку

Сторінка технічного обслуговування
ЗАВАНТАЖИТИ ПАКЕТ ОНОВЛЕННЯПісля завантаження файл RPM з'явиться у списку.  
  1. Будь ласка, запустіть попередню перевірку на активному вузлі. Оновлення слід перервати, якщо виникне будь-яка помилка.
Графічний інтерфейс входу à Обслуговування à Система à Натисніть файл RPM оновлення à Натисніть ПОПЕРЕДНЯ ПЕРЕВІРКА ОНОВЛЕННЯ

Сторінка системи 
 

         Будь ласка, також вимкніть GC, переміщення даних та реплікацію перед початком оновлення (крок #6), щоб ці завдання не призводили до збільшення часу вимкнення DDFS під час оновлення. Коротший час вимкнення DDFS допоможе мінімізувати наслідки для клієнтів. Ці робочі навантаження не впливають на операції резервного копіювання/відновлення клієнтів.

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

         У посібнику з адміністрування описано деякі інші ручні перевірки та команди, які не є строго необхідними для системи HA. Попереднє перезавантаження в даний час пропонується як тест для систем з одним вузлом. Він не потрібен для систем HA, оскільки #5 "ha failover" нижче вже включає автоматичне перезавантаження під час процесу відновлення після відмови.

  1. Необов'язково. Перед запуском віялового оновлення рекомендується двічі виконати відмовостійкість HA вручну на активному вузлі. Метою є перевірка функціональності відмовостійкості. Операція призведе до перезавантаження активного вузла, будь ласка, майте це на увазі.

   
              По-перше, підготуйтеся до відновлення після відмови, вимкнувши GC, переміщення даних і реплікацію. Будь ласка, зверніться до посібника з адміністрування, щоб дізнатися, як це зробити за допомогою графічного інтерфейсу. Ці служби не впливають на робочі навантаження резервного копіювання/відновлення клієнтів. Потім дійте "ha failover".
 

Login GUI à Health à High Availability à Click Failover to XXX


(Коли статус системи HA знову стане «високодоступним», будь ласка, виконайте другий «ha failover» і зачекайте, поки обидва вузли почнуть підключатися)
 

Після відновлення аварійного ремонту HA зупинені служби можна відновити за допомогою відповідних команд увімкнення. Будь ласка, зверніться до посібника з адміністрування для отримання більш детальної інформації.

Наведені вище перевірки відмови є необов'язковими і не обов'язково проводитися безпосередньо перед оновленням. Тести на відмову можуть бути проведені до оновлення, наприклад, за два тижні, щоб можна було використовувати менший період обслуговування для подальшого оновлення. Час простою служби DDFS для кожного відновлення після відмови становить близько 10 хвилин (менше або більше залежно від версій DDOS та деяких інших факторів). Версії DDOS 7.4 і пізніші матимуть менше простоїв до випуску завдяки постійному вдосконаленню DDOS SW.
 

      Покрокова процедура оновлення
  1. Якщо попередня перевірка завершена без проблем, продовжуйте послідовне оновлення на активному вузлі.
Графічний інтерфейс для входу à Обслуговування à Система à Натисніть файл RPM оновлення à Натисніть ВИКОНАТИ ОНОВЛЕННЯ СИСТЕМИ
 
Сторінка системи
  1. Будь ласка, дочекайтеся завершення оновлення. Перед цим, будь ласка, не ініціюйте будь-яку операцію відновлення після відмови HA.

Наявність DDFS під час вищевказаної команди:

  1. Спочатку він оновить резервний вузол і перезавантажить його до нової версії. Це займає приблизно від 20 хвилин до 30 хвилин залежно від різних факторів. Служба DDFS працює на активному вузлі протягом цього періоду без будь-якого зниження продуктивності.

  2. Після застосування нового DDOS система переключить службу DDFS на модернізований резервний вузол. Це займає приблизно 10 хвилин (менше або більше в залежності від різних факторів).

    1. Одним із суттєвих факторів є оновлення DAE FW. Це може спричинити на ~20 хвилин більше простою залежно від того, скільки DAE налаштовано. Будь ласка, зверніться до бази даних "Домен даних: Оновлення HA Rolling може не вдатися під час оновлення мікропрограми зовнішнього корпусу", щоб визначити, чи потрібне оновлення DAE FW. Зверніть увагу, що починаючи з DDOS 7.5 з'явилося удосконалення для включення онлайн-оновлення DAE FW, що усуває цю проблему.

    2. Можна звернутися до служби підтримки Dell, щоб обговорити фактори, які можуть вплинути на час оновлення. Залежно від клієнтської ОС, програми та протоколу між клієнтом і системою HA, іноді користувачеві може знадобитися вручну відновити робочі навантаження клієнта відразу після відновлення після відмови. Наприклад, якщо з клієнтами DDBoost і час відновлення після відмови перевищує 10 хвилин, то тайм-аут клієнта і користувачеві потрібно вручну відновити робочі навантаження. Але зазвичай на клієнтах доступні налаштування для встановлення значень часу очікування та часу повторних спроб. 

Зауважте, що служба DDFS не працює протягом періоду відновлення після відмови. Спостерігаючи за виведенням команди "fileys status" на оновленому вузлі, можна дізнатися, чи відновлено роботу служби DDFS чи ні. Очікується, що версії DDOS 7.4 і пізніших версій матимуть все менше і менше простоїв через удосконалення коду DDOS.

Після відновлення після відмови раніше активний вузол буде модернізовано.  Після застосування оновлення він перезавантажиться до нової версії, а потім знову приєднається до кластера HA як резервного вузла. Цей процес не вплине на роботу служби DDFS, оскільки її вже було відновлено в #II вище.


     Верифікація:
  1. Після завершення послідовного оновлення потрібен графічний інтерфейс для входу через IP-адресу передрезервного вузла, в даному випадку це node1.
Login GUI à Maintenance à System à Check Upgrade History
Сторінка системи
  1. Будь ласка, перевірте, чи немає неочікуваних сповіщень.
Login GUI à Dashboard à Alerts
  1. На даний момент оновлення Rolling успішно завершено.

Послідовне оновлення за допомогою CLI:
      Підготуйте систему до оновлення:
  1. Будь ласка, переконайтеся, що статус системи 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
     -----------------------------   -------   -------   --------
  1. 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
      -----------------------------   -------   -------   --------
  1. Завантажте файл 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”)
            Після виконання команди "scp" перевірте інформацію про
системний пакет Список пакетів 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
     ------------------   ----------   ------   ----------   -----  -------         
  1. Будь ласка, запустіть попередню перевірку на активному вузлі. Оновлення слід перервати, якщо виникне будь-яка помилка.
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" нижче вже включає автоматичне перезавантаження під час процесу відновлення після відмови.

  1. Необов'язково. Перед запуском віялового оновлення рекомендується двічі виконати відмовостійкість 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. 
  

      Покрокова процедура оновлення      
  1. Якщо попередня перевірка завершена без проблем, продовжуйте послідовне оновлення на активному вузлі.
             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 під час вищевказаної команди:

  1. Спочатку він оновить резервний вузол і перезавантажить його до нової версії. Це займає приблизно від 20 хвилин до 30 хвилин залежно від різних факторів. Служба DDFS працює на активному вузлі протягом цього періоду без будь-якого зниження продуктивності.

  2. Після застосування нового DDOS система переключить службу DDFS на модернізований резервний вузол. Це займає приблизно 10 хвилин (менше або більше в залежності від різних факторів).

    1. Одним із суттєвих факторів є оновлення DAE FW. Це може спричинити на ~20 хвилин більше простою залежно від того, скільки DAE налаштовано. Будь ласка, зверніться до бази даних "Домен даних: Оновлення HA Rolling може не вдатися під час оновлення мікропрограми зовнішнього корпусу", щоб визначити, чи потрібне оновлення DAE FW. Зверніть увагу, що починаючи з DDOS 7.5 з'явилося удосконалення для включення онлайн-оновлення DAE FW, що усуває цю проблему.

    2. Можна звернутися до служби підтримки Dell, щоб обговорити фактори, які можуть вплинути на час оновлення. Залежно від клієнтської ОС, програми та протоколу між клієнтом і системою HA, іноді користувачеві може знадобитися вручну відновити робочі навантаження клієнта відразу після відновлення після відмови. Наприклад, якщо з клієнтами DDBoost і час відновлення після відмови перевищує 10 хвилин, то тайм-аут клієнта і користувачеві потрібно вручну відновити робочі навантаження. Але зазвичай на клієнтах доступні налаштування для встановлення значень часу очікування та часу повторних спроб. 

  1. Після відновлення після відмови раніше активний вузол буде модернізовано.  Після застосування оновлення він перезавантажиться до нової версії, а потім знову приєднається до кластера HA як резервного вузла. Цей процес не вплине на роботу служби DDFS, оскільки її вже було відновлено в #II вище.

Зауважте , що служба DDFS не працює протягом періоду відновлення після відмови. Спостерігаючи за виведенням команди "fileys status" на оновленому вузлі, можна дізнатися, чи відновлено роботу служби DDFS чи ні. Очікується, що версії DDOS 7.4 і пізніших версій матимуть все менше і менше простоїв через удосконалення коду DDOS.
  1. Після того, як резервний вузол (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
  1. Будь ласка, дочекайтеся завершення оновлення. Перед цим, будь ласка, не ініціюйте будь-яку операцію відновлення після відмови HA.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
  1. Будь ласка, перевірте статус 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
--------------   ------
            

     Верифікація:
  1. Будь ласка, переконайтеся, що обидва вузли мають однакову версію 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
  1. Будь ласка, перевірте, чи немає неочікуваних сповіщень.
Node1 # alert show current
Node0 # alert show current
  1. На даний момент оновлення Rolling успішно завершено. 

Примітка: Якщо у вас виникнуть проблеми з оновленням, зверніться до служби підтримки Data domain для отримання подальших інструкцій і підтримки.


ЛОКАЛЬНЕ ОНОВЛЕННЯ для пари DDHA: 
Локальне оновлення загалом функціонує наступним чином:

      Підготуйте систему до оновлення:

  1. Перевірте стан системи 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
     -----------------------------   -------   -------   --------

  1. 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
-----------------------------   -------   -------   --------
  1. Завантажте файл 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”)
 
            Після виконання команди "scp" перевірте інформацію про системний пакет
     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
     ------------------   ----------   ------   ----------   -----   ------
  1. Будь ласка, запустіть попередню перевірку на активному вузлі, якщо статус 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.           
     Покрокова процедура оновлення   
     
  1. Переведіть резервний вузол в автономний режим.
            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 погіршується, продовжуйте локальне оновлення, оскільки подальші кроки можуть впоратися з помилками.)
  1. Переконайтеся, що статус резервного вузла знаходиться в автономному режимі.
       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
    -----------------------------   -------   -------   --------
    1. Виконайте оновлення на резервному вузлі. Ця операція викличе перезавантаження резервного вузла.
             Standby-node # system upgrade start <rpm file> local
        Команда 'system upgrade' оновлює ОС Data Domain.  Доступ до
    файлів переривається під час оновлення.  Система перезавантажується автоматично
    після оновлення.
                Ти впевнений? (так|ні) [ні]: так
    Гаразд, продовжуємо.
        «Місцевий» прапорець є дуже руйнівним для систем HA і повинен використовуватися лише як ремонтна операція.
               Ти впевнений? (так|ні) [ні]: так
    Гаразд, продовжуємо.
        Триває оновлення:
        Вузол 1: фаза 3/4 (перезавантаження 0%)
    Оновлення розпочато.  Система перезавантажиться.
    1. Резервний вузол перезавантажиться в нову версію DDOS, але залишиться в автономному режимі.
    2. Будь ласка, перевірте статус оновлення системи, оновлення ОС може зайняти більше 30 хвилин.
                 Standby-node # system upgrade status
          Current Upgrade Status: DD OS upgrade Succeeded
          End time: 20xx.xx.xx:xx:xx
    1. Будь ласка, перевірте стан системи 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
          -----------------------------   -------   -------   --------
    1. Виконайте локальне оновлення на активному вузлі. Ця операція призведе до перезавантаження активного вузла.
            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.
    1. Будь ласка, перевірте статус оновлення системи, оновлення ОС може зайняти більше 30 хвилин.
             Active-node # system upgrade status
        Current Upgrade Status: DD OS upgrade Succeeded
        End time: 20xx.xx.xx:xx:xx
    1. Після завершення активного оновлення вузла стан системи 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' не було запущено на попередніх кроках, будь ласка, проігноруйте цей крок)
    1. Резервний вузол перезавантажиться і знову приєднається до кластера. Після нього статус 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
         --------------   ------
    Верифікація:
    1. Будь ласка, переконайтеся, що обидва вузли мають однакову версію 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
    1. Будь ласка, перевірте, чи немає неочікуваних сповіщень.
           Node1 # alert show current
       Node0 # alert show current
    1. На даний момент оновлення Rolling успішно завершено.
               
    Примітка: Якщо у вас виникнуть проблеми з оновленням, зверніться до служби підтримки Data domain для отримання подальших інструкцій і підтримки.

    Additional Information

    Віялова модернізація:

    • Зауважте, що під час оновлення виконується одиночне відновлення після відмови, тому ролі поміняються місцями

    • Інформація про оновлення продовжує зберігатися в infra.log році, але в ha.log може з'явитися додаткова інформація

    • Прогрес оновлення можна відстежувати за допомогою годинника оновлення системи 

    Оновлення локального вузла:

    • Оновлення локального вузла не виконує відмовостійкість HA

    • Як наслідок, це буде тривалий період простою, поки активний вузол оновлюється/перезавантажується/виконує дії після оновлення перезавантаження, що, швидше за все, призведе до того, що час очікування резервного копіювання/відновлення закінчиться та вийде з ладу. Вимагайте виділення часового вікна обслуговування для локального оновлення.

    • Навіть стан системи HA «погіршується», можна продовжувати локальне оновлення.

    • З якоїсь причини rolling upgrade може вийти з ладу несподівано. Локальний апгрейд можна розглядати як метод виправлення в цій ситуації.

       

    Affected Products

    Data Domain

    Products

    Data Domain, DD OS
    Article Properties
    Article Number: 000009653
    Article Type: How To
    Last Modified: 07 Oct 2025
    Version:  8
    Find answers to your questions from other Dell users
    Support Services
    Check if your device is covered by Support Services.