Обновление узла до 3.2

Узел обновляется штатным скриптом vStack.update.sh. Скрипт едет в поставке и лежит на узле в /root/bin/. Узлы обновляются по одному, и каждый после обновления перезагружается.

Страница рассчитана на узлы линий 3.0.x и 3.1.x, которые переходят на 3.2.0. Переход с линии 2.x меняет мажорную версию FreeBSD и выполняется вместе с технической поддержкой vStack.

Все команды выполняются от root на самом узле.

Перед окном

1. Доступ к репозиторию. Пакеты берутся из репозитория vStack, а он пускает только адреса из списка разрешённых. Заранее отправьте в техническую поддержку адреса, с которых узлы выходят наружу. Без этого скрипт завершится с кодом 2.
2. Консоль узла. Нужен доступ к IPMI или BMC на случай, если узел не вернётся по сети.
3. Нагрузка с узла снята. ВМ погашены или перенесены, пулы узла отданы другим узлам кластера. Как это сделать, описано в разделе «Перенос сервисов пула». Если ВМ в кластере работают и на узлах, которые не держат их пул, порядок описан в разделе «Освобождение узла с удалённо запущенными ВМ».
4. Время синхронизировано на всех узлах. Проверьте ntpq -p: источник времени должен быть достижим.
5. Снята копия конфигурации узла. Процедура описана на странице «Снятие конфигурации узла». Сам скрипт обновления тоже делает копию, но держит её на системном диске узла, и при переустановке она пропадёт вместе с ним.

Порядок обхода кластера

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

Resilver начинается сам. Пока узел перезагружается, пулы остальных узлов теряют его диски, а когда узел возвращается, ZFS догоняет изменения на них. Если перезагрузить следующий узел раньше, пул, у которого ещё не закончилась синхронизация, потеряет второй диск. Пул с избыточностью N+1 этого не переживает.

Проверка на каждом узле, который держит пулы:

zpool status | grep -E 'pool:|state:|scan:'

Идти дальше можно, когда у всех пулов state: ONLINE, а в строке scan: нет resilver in progress.

Ещё два правила на время обхода:

• Смешанный по версиям кластер — нормальное рабочее состояние, пока идёт обход.
• Пул, который уже работал на обновлённом узле, не возвращайте на необновлённый. Держите пулы на уже обновлённых узлах, пока не закончите обход.

предупреждение

Не выполняйте zpool upgrade ни во время обхода, ни после него. Скрипт обновления напоминает об этом в итоговой сводке.

Шаг 1. Обновить сам скрипт

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

fetch -o /root/bin/vStack.update.sh https://repo.vstack.com/os/3.2.0/update.sh
fetch -o /tmp/update.sh.sig        https://repo.vstack.com/os/3.2.0/update.sh.sig
openssl dgst -sha256 \
  -verify /usr/share/keys/vstack/vstackos.pub \
  -signature /tmp/update.sh.sig /root/bin/vStack.update.sh
chmod 0755 /root/bin/vStack.update.sh

Проверка должна напечатать Verified OK. Если напечатано что-то другое, обновление не начинайте.

Шаг 2. Сухой прогон

Сухой прогон ничего на узле не меняет. Скрипт пишет временный конфиг репозитория и показывает план pkg.

/root/bin/vStack.update.sh --controllers --base \
  --source release --version 3.2.0 --dry-run

Убедитесь, что репозиторий доступен, а в плане нет неожиданных удалений пакетов.

Шаг 3. Обновление

/root/bin/vStack.update.sh --controllers --base \
  --source release --version 3.2.0

• --controllers обновляет пакеты узла, кроме базовой системы.
• --base обновляет базовую систему и ядро. После него перезагрузка обязательна.

Перезапускать контроллеры сразу после обновления незачем, если следом идёт перезагрузка. Это можно отключить ключом --no-restart. Ключ --reboot перезагружает узел по завершении. Полный список ключей есть в справочнике.

Перед транзакцией скрипт снимает копию конфигурации в /var/backups/etc-<ts>: /etc, /usr/local/etc и, в подкаталоге boot, файлы /boot/loader.conf, /boot/loader.conf.local и /boot/device.hints. Отдельно сохраняется vstack-env.conf. После обновления скрипт возвращает из копии учётные записи, настройки ssh, sysctl.conf, syslog.conf, hosts, ntp.conf, vstack-env.conf и три файла загрузки, то есть профиль тюнинга узла. Остальные файлы из копии поимённо не возвращаются, их при необходимости сверяют вручную.

Шаг 4. Проверки до перезагрузки

1. Код возврата равен 0. Любой другой код разберите до перезагрузки, смысл кодов приведён ниже.
2. Оболочка root исполняема. Иначе после перезагрузки sshd не пустит root на узел.

   pw usershow root | awk -F: '{ print $NF }'   # путь оболочки
   ls -l $(pw usershow root | awk -F: '{ print $NF }')

3. Защита загрузки взведена.

   cat /boot/nextboot.conf                         # одноразовая загрузка нового ядра
   cat /boot/loader.conf.d/zz-vstack-fallback.conf # загрузка по умолчанию на время окна: прежнее ядро

   Смотрите именно файлы. Строка boot summary в логе печатает имена ядер с лишним суффиксом _prev и сбивает с толку. На деле один раз грузится новое ядро, а откат идёт на прежнее.
4. Сводка прогона. Она лежит в /var/backups/update-summary-<ts>.txt, рядом файлы versions-before-*.txt и versions-after-*.txt. Полный лог пишется в /var/log/vstack-os-update-<ts>.log.

Загрузчик обновляется только на одном системном диске

Скрипт копирует новый loader.efi на тот EFI-раздел, с которого узел загружен сейчас. EFI-раздел второго системного диска остаётся со старым загрузчиком. Если после обновления прошивка загрузит узел со второго диска, новое ядро будет загружено старым загрузчиком.

Поэтому не меняйте порядок загрузки в прошивке во время окна и учитывайте это при замене системного диска.

Шаг 5. Перезагрузка и приёмка

reboot

Если новое ядро не загрузилось, следующая перезагрузка поднимет узел на прежнем. Узел, который завис на приглашении загрузчика, сам не перезагрузится: сбросьте его с консоли IPMI или BMC.

После подъёма:

uname -r                       # база целевой линии
cat /etc/os-release            # VERSION_ID = 3.2.0
pkg query '%n %v' | grep -i vstack
pkg check -d -a                # зависимости целостны
ls /boot/nextboot.conf /boot/loader.conf.d/zz-vstack-fallback.conf 2>&1

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

Затем проверьте сервисы узла (service <имя> status) и его состояние в кластере, дождитесь конца resilver на всех пулах и верните нагрузку. Сами пулы на вернувшийся узел не возвращаются, их переносят вручную.

Перенос сервисов пула

За окно перенос нужен дважды: снять пулы с узла перед работами и вернуть после.

Обычный путь — интерфейс vStack Center, раздел «Сервисы кластера».

Исключение — пул, на котором работает управляющая ВМ (vStack Center). Его нельзя переносить из интерфейса. Перенос начинается с приостановки ВМ пула, в неё попадает и сама управляющая ВМ: Center выключает себя посреди операции, и перенос обрывается. Такой пул переносят утилитой кластера на узле.

Обычно управляющая ВМ живёт на первом пуле кластера, z01. Проверить можно по ВМ с номером 0:

vstack-vm vm list

Перенос утилитой кластера

Этот способ нужен для пула с управляющей ВМ и для кластеров без Center. Команды выполняются с любого узла кластера.

Пул представлен в кластере сервисом zpool_<имя пула>: пулу z01 соответствует сервис zpool_z01. В командах указывается имя сервиса, а не имя пула. Имена сервисов и номера узлов показывает vstack-cluster status:

vstack-cluster status

Node ID:  1; name:   q100u001.example.com; state:       ONLINE; [     enabled]
	Service name:       cluster-management; state:    STARTED; [     enabled]
	Service name:                zpool_z01; state:    STARTED; [     enabled]

Node ID:  2; name:   q100u002.example.com; state:       ONLINE; [     enabled]
	Service name:                zpool_z02; state:    STARTED; [     enabled]
...

Перенос пула z01 на узел 2:

vstack-cluster service move -s zpool_z01 --dst-id=2

Узел назначения должен быть в ONLINE и открыт (enabled). Подробно команда описана в справочнике.

Пока пул переносится, ВМ пула выключаются, а выдача его томов прерывается. Это окно обслуживания, а не бесшовная операция.

Освобождение узла с удалённо запущенными ВМ

ВМ может работать не на узле-владельце своего пула: тогда её диски приезжают по NVMe-oF/TCP. В выводе vstack-vm vm list такие ВМ отмечены словом remote. Перед обновлением узел освобождают от ВМ его пулов и от ВМ, которые запущены на нём с дисками из чужих пулов.

ВМ останавливайте и запускайте через vStack Center.

1. Перенесите пулы узла, как описано в разделе «Перенос сервисов пула». ВМ этих пулов, которые работают на других узлах, перед переносом остановите, а после переноса запустите снова. Найти их можно на каждом узле кластера:

   vstack-vm vm list | grep -w remote | grep -w <пул>

2. Уведите с узла остальные ВМ. Найдите их на самом узле:

   vstack-vm vm list | grep -w remote

   Каждую остановите и запустите действием «Запустить на узле», выбрав другой узел. Затем убедитесь, что на узле не осталось ни одной ВМ:

   ls /dev/vmm

   Ответ No such file or directory означает, что ВМ на узле нет.

3. Закройте узел для размещения ВМ и проверьте, что у него статус DISABLED:

   vstack-cluster node disable --id=<N>
   vstack-cluster node status

   Если утилиты vstack-cluster на узле нет, те же действия выполняют ccrd_cli --node --node_id <N> --command disable и ccrd_cli --node --command status.

   После закрытия ещё раз выполните ls /dev/vmm. Если на узле появились ВМ, уведите их, как в шаге 2.

   предупреждение

   На время работ не запускайте и не переносите ВМ на закрытый узел. Закрытым держите не больше одного узла.

4. Обновите узел по шагам 1–5 этой страницы.

5. Откройте узел после приёмки:

   vstack-cluster node enable --id=<N>

   Без утилиты vstack-cluster: ccrd_cli --node --node_id <N> --command enable. Затем при необходимости верните пулы. ВМ на узел сами не возвращаются.

Коды возврата

Код	Что означает
0	обновление выполнено
1	ошибка в аргументах
2	источник или версия недоступны, не получен ключ подписи, либо запрошен переход между мажорами без --allow-major-upgrade
3	ошибка pkg или проверки нового ядра
4	не удалось сохранить или восстановить конфигурацию (/etc, /usr/local/etc, файлы загрузки)
5	установленный сервис не перезапустился
6	обновление выполнено, но оболочка root не исполняема. Чинить до перезагрузки
7	обновление выполнено, но запись /boot не подтверждена. Не перезагружать до разбора

При кодах 6 и 7 скрипт намеренно игнорирует --reboot.

Откат

Пакеты скрипт не откатывает. Вернуться можно так:

• Загрузка. Прежнее ядро остаётся на узле и доступно из меню загрузчика, пока окно обновления не закрыто успешной загрузкой.
• Конфигурация. Копия лежит в /var/backups/etc-<ts>, хранятся пять последних.
• Система целиком. Переустановка с носителя целевой версии или восстановление из резервной копии узла, снятой до работ.

Данные пулов, диски ВМ и конфигурацию за пределами того, что перечислено в шаге 3, скрипт не сохраняет. Их копию снимайте до окна сами, см. «Снятие конфигурации узла».