Обновление Proxmox без остановки сервисов

MAATRIX

Рано или поздно приходит письмо от Proxmox о новой версии, а apt update показывает три десятка пакетов на обновление, включая новое ядро. Обновлять хост страшно: apt upgrade может потребовать перезагрузки, а перезагрузка узла — это остановка всех VM на нём. Разница в том, что происходит дальше, зависит от одной вещи: у вас кластер из нескольких физических серверов или один одиночный узел. В первом случае простоя можно избежать вовсе, во втором — только сократить его до минимума. Разберём оба сценария по шагам.

Два сценария, и почему они принципиально разные

Обновление пакетов самой системы Proxmox (это Debian под капотом, плюс пакеты pve-*) само по себе не требует остановки VM — apt upgrade ставит новые версии pve-manager, qemu-server, pve-container и так далее, а запущенные машины продолжают работать на уже загруженных в память процессах kvm/lxc. Простой возникает не от обновления пакетов, а от перезагрузки хоста, которая нужна:

• когда обновилось ядро (pve-kernel-*) — новое ядро применяется только после ребута;
• когда обновился сам гипервизор QEMU/KVM до версии, несовместимой с уже запущенными процессами «на лету» (redhat-подобных live-patch механизмов для ядра Proxmox из коробки не предлагает);
• после мажорного апгрейда версии Proxmox (например, с 8.x на 9.x) — там перезагрузка обязательна почти всегда.

Дальше всё решает один вопрос: можно ли на время перезагрузки этого узла переместить его VM на другое физическое железо?

• Кластер из нескольких узлов — да, можно. Живая миграция переносит работающие VM на соседний узел без остановки, и весь узел освобождается для спокойного обновления и перезагрузки.
• Одиночный узел — нет. Переносить VM некуда, поэтому при перезагрузке хоста они неизбежно на какое-то время встанут. Здесь задача — не «убрать простой», а «сделать его максимально коротким и предсказуемым».

Дальше — практика по каждому случаю отдельно.

Сценарий 1: обновление узла в кластере (rolling update)

Если у вас настроен кластер Proxmox из нескольких узлов с общим или разделяемым хранилищем (Ceph, ZFS+replication, NFS, общий iSCSI), обновление делается методом rolling update: узлы обновляются по одному, один за другим, и в любой момент времени недоступен для новых задач только тот узел, который сейчас обновляется — остальные продолжают обслуживать VM без перерыва.

Принцип живой миграции подробно разобран в статье про живую миграцию виртуалок и что происходит с памятью — коротко: Proxmox копирует память работающей VM на целевой узел, продолжая синхронизировать «грязные» страницы, пока разница не станет минимальной, и в конце происходит короткое (доли секунды — единицы секунд) переключение. Сеть и диски (если хранилище общее) не прерываются, TCP-сессии внутри VM обычно выживают.

Предварительные условия

Перед тем как начинать, проверьте:

• Ресурсы на других узлах. Если вы эвакуируете VM с узла A, узлы B и C должны выдержать вырастающую на время нагрузку (RAM и vCPU). Проверьте это заранее, а не в процессе — иначе миграция может просто не пройти по памяти.
• Общее хранилище. Живая миграция с диском на локальном хранилище (local-lvm, локальный ZFS без реплики) тоже возможна («миграция с диском», storage migration на лету), но она медленнее и ощутимо грузит сеть между узлами — планируйте окно с запасом. С Ceph или репликацией ZFS диск уже доступен на всех узлах, и переезжает только состояние в памяти.
• Кворум. В кластере из 2 узлов при выводе одного из них временно теряется кворум, если нет третьего голосующего узла (можно обойтись QDevice). Без кворума кластер может уйти в read-only по управлению — проверьте состояние pvecm status заранее.
• Совместимость версий CPU. Если узлы кластера собраны на разном железе, задайте у VM тип CPU не «host», а конкретную модель (kvm64, x86-64-v2-AES и т.п.) или общий минимальный набор флагов — иначе миграция между узлами с разными процессорами может не пройти или потребует выключения VM.

Пошаговый план для одного узла кластера

1. Проверить состояние кластера.

pvecm status
ha-manager status

Убедитесь, что кластер здоров (кворум есть), и посмотрите, не привязаны ли к обновляемому узлу HA-группы жёстко.

1. Поставить узел в режим обслуживания (опционально, но полезно). Если используется HA-manager, переведите узел в maintenance-режим, чтобы HA не пыталась перезапускать на нём ресурсы во время миграции:

ha-manager crm-command node-maintenance enable pve-node1

Это заставит HA-стек сам аккуратно смигрировать управляемые им ресурсы на другие узлы.

1. Эвакуировать оставшиеся VM вручную. Через веб-интерфейс: узел → правый клик на VM → «Migrate», выбрать целевой узел, отметить «Online» (живая миграция). Через CLI для конкретной VM:

qm migrate 101 pve-node2 --online

Для контейнеров LXC — только офлайн-миграция или миграция с кратким простоем самого контейнера (pct migrate), живой миграции LXC в классическом виде Proxmox не делает так же, как для QEMU — учитывайте это при планировании, если у вас много контейнеров, а не VM.

Чтобы не гонять команды по одной, можно эвакуировать все VM узла разом:

for vmid in $(qm list | awk 'NR>1{print $1}'); do
  qm migrate "$vmid" pve-node2 --online
done

Проверьте после этого, что узел действительно пуст:

qm list
pct list

1. Убедиться, что все VM реально переехали и работают. Зайдите в пару машин, проверьте сетевую доступность, посмотрите логи внутри гостевой ОС на предмет паники или таймаутов диска — обычно живая миграция проходит незаметно для гостя, но лучше убедиться до, а не после отключения узла.

1. Обновить и перезагрузить освобождённый узел.

apt update
apt list --upgradable
apt dist-upgrade

Прочитайте вывод — если среди обновляемых пакетов есть pve-kernel-*, перезагрузка обязательна:

reboot

Дождитесь, что узел вернулся в кластер:

pvecm status

и что веб-интерфейс узла снова отвечает.

1. Снять maintenance-режим (если включали).

ha-manager crm-command node-maintenance disable pve-node1

1. Вернуть VM обратно или оставить как есть. Технически без разницы, где именно физически крутится VM внутри кластера — если распределение нагрузки устраивает, можно оставить как есть и просто продолжить с следующим узлом. Если хочется вернуть на «родной» узел (например, из-за локального хранилища с более быстрым диском), повторите миграцию в обратную сторону.

1. Повторить шаги 2-7 для следующего узла кластера. В любой момент времени обновляется только один узел, остальные продолжают отвечать за VM — простоя сервисов в целом нет, хотя отдельные VM переживают короткое (обычно незаметное для пользователя) переключение при живой миграции.

Таблица: что проверить перед rolling update кластера

Сценарий 2: обновление одиночного узла (без кластера)

Если у вас один физический сервер и переносить VM физически некуда, полностью убрать простой при перезагрузке хоста нельзя — это ограничение архитектуры, а не что-то, что решается тонкой настройкой. Здесь фокус на другом: максимально сократить длительность простоя и убрать из процесса всё, что можно сделать заранее без остановки VM.

Что можно делать без простоя вообще

Обновление пакетов, которое не требует нового ядра, никак не трогает работающие VM — их процессы уже загружены в память и продолжают работать, пока вы обновляете pve-manager, вспомогательные утилиты, pve-firewall, PHP для веб-интерфейса и так далее. Смело делайте это в рабочее время:

apt update
apt list --upgradable

Посмотрите на список: если в нём нет pve-kernel-* и нет строк вида «需要 перезагрузка» (Proxmox сам подсказывает флагом needrestart, если модуль установлен) — можно просто:

apt dist-upgrade

и жить дальше без перезагрузки. Веб-интерфейс может кратковременно моргнуть при обновлении pve-manager (перезапуск pveproxy), но это доли секунды и не касается самих VM.

Что требует перезагрузки — и как её спланировать

Если в списке обновлений есть новое ядро, перезагрузка неизбежна. План действий:

1. Прочитать release notes перед обновлением. Особенно если речь о мажорной версии Proxmox (8→9) — там могут быть breaking changes: смена формата конфигов, изменения в сетевом стеке (переход на новую схему интерфейсов), несовместимость старых плагинов хранилищ. Тот же принцип «сначала читаем, что изменилось, потом обновляем» справедлив и для баз данных — см. разбор в статье про обновление мажорной версии базы данных на проде: там подход к рискам почти дословно переносится на Proxmox.

1. Сделать снапшоты или бэкапы VM перед перезагрузкой хоста. Не потому что перезагрузка сама по себе опасна для дисков, а потому что если после ребута что-то пойдёт не так (не поднялась сеть, не стартовал сервис), у вас должна быть точка возврата. Снапшоты (если хранилище их поддерживает — подробнее в статье как устроены снапшоты в Proxmox) — это быстро, но не замена полноценному бэкапу. Полный бэкап через vzdump или Proxmox Backup Server надёжнее, но требует времени и места:

vzdump 101 102 103 --storage backup-storage --mode snapshot --compress zstd

Режим --mode snapshot делает бэкап без остановки VM (для этого нужен снапшот-совместимый storage), так что сам бэкап простоя не добавляет.

1. Уведомить пользователей заранее о плановом окне. Если на сервере крутятся продовые сервисы с реальными пользователями, сообщите о плановых работах хотя бы за сутки — конкретное время и ожидаемую длительность (обычно 3-10 минут на перезагрузку хоста среднего объёма, но это ориентир: у вас может быть иначе в зависимости от объёма RAM, количества VM и скорости диска, на котором лежит их состояние).

1. Выбрать период минимальной нагрузки. Для большинства проектов с русскоязычной или европейской аудиторией это глубокая ночь по местному времени пользователей — 2:00-5:00. Если у сервиса международная аудитория без явного пика — смотрите статистику посещаемости за пару недель и выбирайте объективный минимум, а не «на глаз».

1. Выполнить обновление и зафиксировать состояние ДО перезагрузки.

apt update && apt dist-upgrade
qm list
pct list

Сохраните список VM, которые должны подняться автоматически — если настроен автозапуск и порядок старта виртуалок, после ребута хоста они поднимутся сами в заданном порядке; если нет — будьте готовы запустить их вручную командой qm start <vmid>.

1. Перезагрузить и проконтролировать поднятие.

reboot

После возврата хоста в сеть проверьте:

systemctl status pveproxy pvedaemon pve-cluster
qm list
pct list

Убедитесь, что все VM/контейнеры, которые должны быть запущены, действительно запущены (status: running), а не просто существуют в списке.

Сколько реально длится простой

Точные цифры зависят от железа (в первую очередь — скорость диска под системным разделом и объём RAM, который нужно освободить/восстановить у гостевых ОС) и от количества VM с автозапуском. Ориентировочно перезагрузка самого хоста Proxmox — это 1-3 минуты POST + загрузка ядра, затем ещё какое-то время на последовательный старт VM (это управляется задержками автозапуска, которые вы сами настраиваете). Считайте это ориентиром для планирования окна, а не гарантией — на конкретном железе будет иначе, проверьте на тестовом обновлении, сколько времени уходит именно у вас.

План отката, если обновление пошло не так

Готовьте план отката до, а не после того, как что-то сломалось — общий принцип тот же, что и в статье про план отката миграции: откат должен быть продуман и, желательно, один раз проверен, а не изобретён в панике в 4 утра.

Практические варианты для Proxmox:

• Снапшот файловой системы хоста (если корень на ZFS или LVM-thin) — можно сделать снапшот перед apt dist-upgrade и откатиться если что-то критично сломалось на уровне ОС. Это не защищает от проблем с новым ядром, если вы уже загрузились в него, но спасает при проблемах на уровне пакетов Proxmox.
• Держать старое ядро в GRUB. Proxmox по умолчанию не удаляет предыдущие версии ядра сразу — в меню GRUB при загрузке можно выбрать предыдущую версию, если новая не поднимается или вызывает проблемы с драйверами/сетью. Проверьте это до планового окна:

proxmox-boot-tool kernel list

• Актуальный бэкап VM — если хост-уровневые методы не спасают, разворачиваете VM из бэкапа на любом доступном железе.
• Документированная последовательность действий. Запишите заранее (не во время инцидента), какие команды и в каком порядке выполнять при откате — так же, как для отката миграции: это должно быть скучным чек-листом, а не творчеством под давлением.

Тестируйте обновление на некритичном окружении

Прежде чем катить обновление на боевой узел или на весь кластер, по возможности проверьте его на менее критичном узле или тестовом стенде:

• В кластере — начните rolling update с узла, где меньше всего важных VM (или где легче всего перенести оставшиеся), а не с того, где крутится основная база данных.
• На одиночном сервере — если у вас есть тестовый VPS или отдельная тестовая VM с похожей конфигурацией Proxmox, обновите сначала её и посмотрите на реальное время простоя и на то, не сломалось ли что-то в сети или в хранилище после ребута.
• Для мажорных версий Proxmox (8→9 и подобных) тестовый прогон особенно важен — там меняется больше, чем в обычном минорном обновлении, и вероятность неожиданностей выше.

Частые вопросы