Proxmox VE 9.0: тестируем новый storage API с отечественными NVMe-массивами

Proxmox VE 9.0 вышел в начале февраля. Мажорный релиз - значит Debian 13 в основе, QEMU 10, и то, что нас интересовало больше всего: переработанный storage API. Подняли стенд, подключили отечественные NVMe-массивы, заодно посмотрели на два других изменения из changelog - улучшенный cluster log и обновлённый HA-менеджер.

Зачем вообще лабораторный стенд

Proxmox у нас живёт в нескольких проектах managed-сопровождения. Это не самый очевидный выбор для крупных инсталляций, но он хорошо работает там, где нужна управляемая гипервизорная среда без enterprise-лицензионных издержек и с человекочитаемым конфигом. При этом мажорные релизы Proxmox - это не косметические обновления, там обычно что-то ломается в конфигурации хранилищ или сети, и мы давно выработали правило: сначала стенд, потом production.

Конкретно с 9.0 поводом для аккуратности стал именно новый storage API - достаточно серьёзный рефакторинг, чтобы не апгрейдить вслепую.

Новый storage API: что поменялось и зачем это важно

В Proxmox до 9.0 работа со storage backend-ами шла через единый плоский интерфейс, который оброс костылями за несколько мажорных версий. В 9.0 это переписали: storage plugins теперь регистрируют свои возможности через явный capability-манифест, и ядро PVE использует его при принятии решений - например, поддерживает ли конкретный storage thin provisioning, snapshots, или live resize.

На практике это означает несколько вещей.

Первое - инициализация хранилищ при старте ускорилась. На нашем стенде с четырьмя storage backend-ами (два NVMe-массива, один NFS и один Ceph-пул) время от старта pvestatd до состояния «всё доступно» сократилось заметно. Это особенно ощутимо на кластерах с большим числом ВМ - pvestatd в старом PVE мог долго опрашивать хранилища последовательно.

Второе - поддержка отечественных NVMe-массивов через iSCSI/NVMe-oF теперь ведёт себя предсказуемо. Мы подключали массивы отечественного производства через NVMe-oF (TCP-транспорт). В PVE 8.x это работало через plugin-костыль с ручной настройкой timeout-ов и неочевидными параметрами в /etc/pve/storage.cfg. В 9.0 NVMe-oF plugin объявляет правильные capabilities, PVE понимает, что storage умеет snapshots на уровне устройства, и перестаёт пытаться делать это программно поверх. Снапшоты ВМ с дисками на этих массивах теперь проходят через hardware offload - это быстрее и не грузит хост.

Третье - live resize дисков наконец работает без танцев с бубном. Раньше на iSCSI-хранилищах приходилось вручную пробрасывать resize-команду в гостя после расширения lun. Теперь PVE делает это через storage plugin, если тот заявил поддержку online-resize. Наш NVMe-массив её поддерживает - протестировали, работает.

Одна оговорка: обновление хранилищ в конфиге при миграции с PVE 8.x требует ручного прохода по /etc/pve/storage.cfg. Автоматической миграции нет - нужно сверить capability-параметры с документацией нового plugin-а для каждого backend-а. Не сложно, но если хранилищ много - закладывайте время.

Cluster log: теперь можно читать

Это изменение не анонсировали в крупных буквах, но мы заметили сразу. В PVE 8.x cluster log в веб-интерфейсе был примерно бесполезен - записи сыпались потоком без нормальной фильтрации, timestamp-ы иногда расходились между нодами из-за разницы часовых поясов в логах, и найти конкретное событие миграции или ошибку storage было упражнением для терпеливых.

В 9.0 cluster log получил нормальную структуру. Записи теперь сгруппированы по типу события (migration, storage, HA, api), есть фильтрация по ноде и временному диапазону, timestamp-ы унифицированы в UTC. Мелочь, но на кластерах с активным движением ВМ это реально упрощает диагностику.

HA-менеджер: что изменилось

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

Timeout при потере кворума стал конфигурируемым. В старых версиях при потере кворума HA-менеджер ждал фиксированное время перед тем, как объявить ноду dead и начать восстановление ресурсов. В 9.0 этот timeout вынесен в параметр cluster-а. На нашем стенде с быстрой internal-сетью между нодами мы его уменьшили - это сократит окно недоступности ВМ при реальном сбое ноды.

Priority-группы для HA-ресурсов. Теперь ресурсам можно назначить приоритет восстановления. На кластерах, где ВМ разного класса критичности, это позволяет сказать HA-менеджеру: сначала восстанови СУБД, потом веб-серверы, и только потом dev-окружения. Раньше порядок восстановления был по сути не гарантирован.

Где сейчас

Стенд отработал неделю, серьёзных проблем не вылезло. Основной риск для production-апгрейда - storage.cfg миграция, о которой написали выше. На кластерах с нестандартными storage plugin-ами (а у части наших клиентов они есть) нужно проверить совместимость plugin-а с новым capability API - если plugin старый и не обновлялся, он просто не будет регистрировать capabilities и упадёт до legacy-режима, что работает, но без новых возможностей.

Production-апгрейд первого кластера планируем на следующий месяц - после того, как vендор выкатит первый пакет с post-release fixes. Это наш стандартный ритм для мажорных версий, и Proxmox 9.0 тут не исключение.