Обновление zVirt

Обновление заключается в обновлении менеджера управления и гипервизоров.

Чтобы избежать ошибок, перед началом обновления внимательно прочитайте раздел Особенности и ограничения и спланируйте последовательность действий.

1. Рекомендуемый алгоритм обновления

Обновление zVirt c архитектурой Hosted Engine

Проверьте наличие обновлений.
Обновите стандартные хосты.
Обновите все свободные хосты с ролью HostedEngine. Под "свободными" понимаются хосты, на которых в текущий момент не выполняется ВМ HostedEngine (обозначены значком ).
Переведите в режим обслуживания хост с ролью HostedEngine, на котором в текущий момент времени работает ВМ HostedEngine (обозначен значком ). Дождитесь окончания миграции ВМ HostedEngine. Выполните обновление этого хоста.
Обновите Менеджер управления.
При необходимости обновите версии совместимости кластеров и центров данных.

Обновление zVirt c архитектурой Standalone

Обновление zVirt c архитектурой Standalone All-In-One

2. Процедура обновления

2.1. Проверка наличия обновлений

Предварительные требования:

Проверка обновления может выполняться вручную или автоматически.

Автоматическая проверка выполняется через заданный интервал времени. Значение для интервала задается с помощью ключа конфигурации HostPackagesUpdateTimeInHours. Значение по умолчанию - 24 часа.

Для проверки текущего интервала, подключитесь по SSH к Менеджеру управления и выполните следующую команду:

engine-config --get=HostPackagesUpdateTimeInHours

Для установки нового значения используйте следующую команду:

engine-config --set HostPackagesUpdateTimeInHours=10 (1)

1	В этом примере устанавливается частота проверки равная 10 часам

Для ручной проверки обновлений выполните следующие действия:

Авторизуйтесь на портале администрирования с достаточными правами.
Перейдите в Ресурсы Хосты.
Выделите нужный хост и нажмите Настройки Проверить обновления.
В окне подтверждения нажмите OK.

После окончания проверки, при наличии доступных обновлений, в строке соответствующего хоста, а также в подробном представлении появится значок .

2.2. Обновление хостов

2.2.1. Автоматическое обновление

Предварительные требования:

Обновление может быть выполнено как для отдельных хостов, так и для всех хостов указанного кластера.

Перед выполнением обновления необходимо проверить количество ядер в системе.

Проверьте список в каталоге /boot:

ll /boot/initramfs* /boot/vmlinuz*

Пример вывода:

-rw-------. 1 root root 122930369 мая  5 15:34 /boot/initramfs-4.18.0-553.6.1.el8.x86_64.img (1)
-rw-------. 1 root root 113097490 мая  5 15:35 /boot/initramfs-6.1.128-isp3.img (2)
-rw-------. 1 root root 114718602 мая  5 15:37 /boot/initramfs-6.1.128-isp6.img (3)
-rw-------. 1 root root  40737280 мая  5 15:42 /boot/initramfs-6.1.128-isp6kdump.img
lrwxrwxrwx. 1 root root        26 апр 19 17:49 /boot/vmlinuz -> /boot/vmlinuz-6.1.128-isp6
-rwxr-xr-x. 1 root root  10873232 мая 30  2024 /boot/vmlinuz-4.18.0-553.6.1.el8.x86_64  (1)
-rw-r--r--. 1 root root   7021056 апр 19 17:48 /boot/vmlinuz-6.1.128-isp3  (2)
-rw-r--r--. 1 root root   7553536 апр 19 17:49 /boot/vmlinuz-6.1.128-isp6  (3)

1	Относится к ядру 4.18.0-553
2	Относится к ядру 6.1.128-isp3
3	Относится к ядру 6.1.128-isp6

Проверьте список в каталоге /boot/zvirt-node-<version>

ll /boot/zvirt-node-*/initramfs* ll /boot/zvirt-node-*/vmlinuz*

Пример вывода:

-rw-------. 1 root root 122930369 мая  5 15:34 /boot/zvirt-node-ng-4.3-0.20250419.0+1/initramfs-4.18.0-553.6.1.el8.x86_64.img (1)
-rw-------. 1 root root 113097490 мая  5 15:35 /boot/zvirt-node-ng-4.3-0.20250419.0+1/initramfs-6.1.128-isp3.img (2)
-rw-------. 1 root root 114718602 мая  5 15:37 /boot/zvirt-node-ng-4.3-0.20250419.0+1/initramfs-6.1.128-isp6.img (3)
-rw-------. 1 root root  40737280 мая  5 15:42 /boot/zvirt-node-ng-4.3-0.20250419.0+1/initramfs-6.1.128-isp6kdump.img
-rwxr-xr-x. 1 root root  10873232 мая 30  2024 /boot/zvirt-node-ng-4.3-0.20250419.0+1/vmlinuz-4.18.0-553.6.1.el8.x86_64 (1)
-rw-r--r--. 1 root root   7021056 апр 19 17:48 /boot/zvirt-node-ng-4.3-0.20250419.0+1/vmlinuz-6.1.128-isp3  (2)
-rw-r--r--. 1 root root   7553536 апр 19 17:49 /boot/zvirt-node-ng-4.3-0.20250419.0+1/vmlinuz-6.1.128-isp6 (3)

1	Относится к ядру 4.18.0-553
2	Относится к ядру 6.1.128-isp3
3	Относится к ядру 6.1.128-isp6

Если по результатам проверки, как в примере выше, выявлено наличие 3 и более ядер, обновление хостов необходимо выполнять с помощью скрипта.

2.2.1.1. Обновление всех хостов в кластере

Перед обновлением кластера учтите следующие особенности и ограничения:

Обновление необходимо производить по одному кластеру.
Если в кластере включена миграция, виртуальные машины автоматически мигрируют на другой хост в кластере.
В кластере должно быть достаточно памяти для миграции виртуальных машин. В противном случае миграция зависнет и завершится сбоем. Уменьшить использование памяти можно путем выключения виртуальных машин в кластере.
Виртуальные машины, закрепленные за хостами, не могут мигрировать. Такие виртуальные машины могут быть выключены вручную или автоматически с помощью активации соответствующего параметра обновления (см. ниже).
Виртуальная машина HostedEngine не может мигрировать на стандартные хосты, поэтому убедитесь, что в кластере с ВМ HostedEngine есть хотя бы один дополнительный хост с ролью HosteEngine.

Порядок действий:

Авторизуйтесь на портале администрирования с правами, достаточными для обновления.

Перейдите в Ресурсы Кластеры.

Если была выполнена проверка наличия обновлений, то кластеры, для которых доступны обновления, отмечаются значком .

Если проверка наличия обновлений не была выполнена, это можно сделать в визарде обновления с помощью активации соответствующего параметра обновления (см. ниже).

Выделите нужный кластер и нажмите Обновить.
В визарде обновления кластера:
1. Выберите хосты, для которых необходимо выполнить обновление и нажмите Далее.
2. Укажите параметры обновления:
  Остановить прикрепленные ВМ: при выборе останавливает все виртуальные машины, которые закреплены на хостах в кластере. Можно снять этот флажок, чтобы пропустить обновление хостов с закрепленными ВМ.
  
  Тайм-аут обновления: устанавливает время ожидания обновления отдельного хоста, прежде чем обновление кластера завершится сбоем. Значение по умолчанию — 60. Таймаут можно увеличить для больших кластеров, где 60 минут может быть недостаточно, или уменьшить для небольших кластеров, где хосты обновляются быстро.
  
  Проверить обновление: проверяет каждый хост на наличие доступных обновлений перед запуском процесса обновления. Этот параметр можно активировать, чтобы убедиться, что для хостов имеются доступные обновления.
  
  Перезагрузка после обновления: перезагружает каждый хост после его обновления и выбран по умолчанию. Можно снять этот флажок, чтобы ускорить процесс, если вы уверены, что обновление не требует перезагрузки хоста.
  
  Режим обслуживания: устанавливает политику планирования cluster_maintenance на время обновления кластера. Она выбрана по умолчанию, поэтому активность ограничена, и виртуальные машины не могут запускаться, если они не являются высокодоступными. Вы можете снять этот флажок, если у вас есть настраиваемая политика планирования, которую вы хотите продолжать использовать во время обновления, но это может иметь неизвестные последствия.
3. Нажмите Далее.
4. На странице обзора параметров проверьте количество обновляемых хостов и нажмите Обновить.

После начала обновления отображается экран статуса обновления кластера с индикатором выполнения и списком этапов, которые были завершены.

Вы можете нажать Go to Event Log, чтобы открыть записи журнала для обновления. Закрытие этого экрана не прерывает процесс обновления.

Процесс обновления можно наблюдать:

На экране Ресурсы Кластеры - в столбце Доступность обновления будет отображаться индикатор выполнения обновления.
На экране Ресурсы Хосты - обновляемые хосты будут иметь состояние Installing и помечены значком .
В разделе События панели уведомлений.

2.2.1.2. Обновление отдельных хостов

Перед обновлением хостов учтите следующие особенности и ограничения:

Если в кластере включена миграция, виртуальные машины автоматически мигрируют на другой хост в кластере.
В кластере должно быть достаточно памяти для миграции виртуальных машин. В противном случае миграция зависнет и завершится сбоем. Уменьшить использование памяти можно путем выключения виртуальных машин в кластере.
Виртуальные машины, закрепленные за хостами, не могут мигрировать. Такие виртуальные машины могут быть выключены вручную или автоматически с помощью активации соответствующего параметра обновления (см. ниже).
Виртуальная машина HostedEngine не может мигрировать на стандартные хосты, поэтому убедитесь, что в кластере с ВМ HostedEngine есть хотя бы один дополнительный хост с ролью HosteEngine.

Порядок действий:

Авторизуйтесь на портале администрирования с правами, достаточными для обновления.
Перейдите в Ресурсы Хосты.
Убедитесь, что хосты получили информацию о наличии обновлений. Хосты, для которых доступно обновление будут помечены значком .
Выделите нужный хост и нажмите Настройки Обновить.

В окне подтверждения нажмите OK. Работающие виртуальные машины мигрируют на другие хосты кластера в соответствии с политикой миграции. Если миграция отключена для каких-либо виртуальных машин, вам будет предложено их выключить.

В процессе обновления хост состояние хоста будет меняться в следующем порядке: PreparingForMaintenance > Maintenance > Installing > Reboot > Up.

Если обновление не удалось, статус хоста изменится на Install Failed. В этом случае, изучив события и журналы, найдите и устраните причину ошибки и повторите процедуру обновления.

Повторите процедуру для остальных хостов кластера.

Для проверки того, что хост успешно обновился:

На портале администрирования перейдите Ресурсы Хосты.
Нажмите на имя обновлённого хоста для перехода в подробное представление.
Проверьте версию ОС на вкладке Общее:

Рисунок 1. Ожидаемая версия ОС

На обновление информации об установленных версиях ПО на веб-портале требуется некоторое время.

2.2.2. Обновление с помощью скрипта

Предварительные требования:

На обновляемом хосте(ах) настроены и активированы репозитории.
1. Подключитесь по SSH или через веб-консоль к хосту.
2. Установите rpm-пакет со скриптом автообновления zvirt-update:
  dnf install -y zvirt-update
3. Запустите терминальный мультиплексор:
  tmux
4. Запустите процесс автообновления с помощью команды:
  zvirt-update
5. Следуйте инструкциям на экране.
6. Перезагрузите хост для загрузки с новым ядром:
  reboot
7. По окончанию обновления если хост с ролью HostedEngine является единственным хостом такого типа в кластере:
  1. запустите ВМ HostedEngine:
    
    hosted-engine --vm-start
  2. Убедитесь в корректности статуса ВМ HostedEngine (для запуска требуется некоторое время)
    
    hosted-engine --vm-status
    
    Ожидаемый статус ВМ HostedEngine
    
    Engine status: {"vm": "up", "health": "good", "detail": "Up"}
8. Выведите гипервизор из обслуживания:
  1. На портале администрирования перейдите Ресурсы Хосты.
  2. Выделите нужный хост и нажмите Управление > Включить.

2.3. Обновление Менеджера управления

Предварительные требования:

На Менеджере управления настроены и активированы репозитории.

Порядок действий:

Если Менеджер управления развернут в архитектуре HostedEngine, активируйте режим глобального обслуживания:
На хосте с ВМ HostedEngine режим глобального обслуживания кластера в веб-интерфейсе или выполнив, подключившись по SSH к хосту, следующие команды:
hosted-engine --set-maintenance --mode=global hosted-engine --vm-status
Убедитесь, что включен режим глобального обслуживания - в выводе должна присутствовать надпись !! Cluster is in GLOBAL MAINTENANCE mode !!:
Если Менеджер развернут в архитектуре Standalone All-in-One, переведите хост с Менеджером в режим обслуживания.
Подключитесь по SSH к Менеджеру управления и авторизуйтесь пользователем root.
Установите rpm-пакет со скриптом автообновления zvirt-update:
```
dnf install -y zvirt-update
```
Запустите терминальный мультиплексор:
```
tmux
```
Запустите процесс автообновления с помощью команды:
```
zvirt-update
```
Следуйте инструкциям на экране.
Перезагрузите Менеджер управления для загрузки с новым ядром:
В архитектуре Standalone:
- Подключитесь по SSH к хосту с Менеджером управления.
- Выполните команду перезагрузки.
  
  reboot
В архитектуре HostedEngine:
- Подключитесь по SSH к хосту с ролью HostedEngine.
- Остановите ВМ HostedEngine:
  
  hosted-engine --vm-shutdown
- Дождитесь остановки ВМ. Статус можно проверить следующей командой:
  
  hosted-engine --vm-status
- После остановки (в статусе значение down) запустите ВМ:
  
  hosted-engine --vm-start
Если ранее был включен режим глобального обслуживания, отключите его:
hosted-engine --set-maintenance --mode=none hosted-engine --vm-status
В выводе должно отсутствовать уведомление !! Cluster is in GLOBAL MAINTENANCE mode !!.
Если выполнялось обновление Менеджера управления в архитектуре Standalone All-in-One, выведите хост из режима обслуживания.

Если в среде используются модули "Репликация и DR" или/и "Конвертация" и во время обновления Менеджеров управления был выполнен переход с AAA-JDBC на Keyclock, необходимо:

В настройках агента-отправителя, агента-приемника в разделе Репликация и DR Площадки изменить имя пользователя на [username]@interlansso.
Выполнить перезапуск сервиса («Restart agent services») на агентах.
Восстановить работу репликации групп ВМ.

Проверить обновление можно на странице входа веб-интерфейса

и наличием нового функционала.