zVirt 4.0: переводим второй кластер ESXi и разбираем разницу vMotion vs live migration на отечественном железе

zVirt 4.0 вышел на прошлой неделе - релиз на обновлённой базе oVirt, с официальной поддержкой Astra Linux 2.8 LTS в качестве хостовой ОС и расширенной поддержкой отечественных серверных платформ. Для нас это совпало по времени с завершением переноса второго кластера VMware ESXi у клиента из КИИ. Так что пост получается одновременно про релиз и про практику - что из заявленного реально работает, где потребовалось доделывать руками.

Контекст: почему 4.0, а не ждать 4.x

Мы уже переводили первый кластер этого же клиента на zVirt 3.0 - тогда всё прошло приемлемо, хотя и с нюансами по multipath и SPM. Второй кластер откладывали: там серьёзнее железо (несколько хостов на Aquarius, один на YADRO), другая СХД и больше ВМ под нагрузкой. Дожидались стабильной точки, и выход 4.0 с задокументированной поддержкой Aquarius в списке совместимости стал этой точкой. Параллельно у клиента как раз закончился переход хостовых машин на Astra Linux 2.8 LTS - требование регулятора, и zVirt 4.0 под эту версию тоже сертифицирован.

Что поменялось в 4.0 по сравнению с 3.x

Ключевые изменения, которые реально ощущаются в работе, а не по release notes:

Обновлённое ядро oVirt. zVirt 4.0 перешёл на более свежую ветку oVirt, и это заметно прежде всего в REST API - ряд методов, которые в 3.x работали с оговорками или требовали обходных путей, теперь работают чисто. Наши Ansible-плейбуки под управление кластером потребовали минимальной правки, а не переписки.

Поддержка Astra Linux 2.8 как хостовой ОС. В 3.x под Astra Linux 2.7 это работало, но без официальной поддержки - приходилось ставить пакеты из совместимых репозиториев и молиться. В 4.0 есть официальный репозиторий для Astra Linux 2.8, пакеты подписаны, установка через штатный инсталлятор. Для КИИ с требованием сертифицированной ОС это принципиально.

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

vMotion vs live migration: в чём реальная разница

Этот вопрос всплывает на каждом проекте миграции, и всегда кто-то в команде клиента формулирует его как «а live migration - это то же самое, что vMotion?». Почти, но не совсем.

vMotion в VMware - это проприетарный механизм с централизованным управлением через vCenter. vCenter координирует передачу состояния памяти, контролирует порядок переключения сети, умеет параллельную миграцию нескольких ВМ с расстановкой приоритетов и Storage vMotion - одновременный перенос диска и вычислений. Это полированный продукт, который работает предсказуемо в том числе на экзотических конфигурациях.

Live migration в zVirt (точнее - QEMU live migration, которым управляет oVirt) работает через прямую передачу состояния памяти между хостами по выделенной сети. Принципиально то же самое, но без ряда удобств vCenter: нет централизованной очерёдности при массовой миграции, нет аналога Storage vMotion в одном действии (перенос диска - отдельная операция), и поведение при высоком dirty rate памяти требует понимания параметров.

На практике на этом кластере мы заметили несколько вещей:

• Чистые ВМ мигрируют без проблем. ВМ с умеренной нагрузкой на память переезжают без заметного прерывания соединений. Параметры migration_convergence_timeout и max_bandwidth в oVirt настроили под ширину нашего migration VLAN - важно сделать это до начала работы, а не оставлять дефолты.
• СУБД под нагрузкой требуют аккуратности. PostgreSQL-ВМ с активной записью мигрировали с увеличенным временем конвергенции - dirty rate опережал скорость копирования страниц. Лечится либо окном с пониженной нагрузкой, либо параметром auto_converge, который принудительно троттлит ВМ в процессе. Второе вариант работает, но с заметным падением производительности на время миграции - лучше выбирать окно.
• Параллельная миграция нескольких ВМ через UI - без очевидной приоритизации. Как и в 3.0, движок ставит в очередь, но порядок не прозрачен. Мы скрипт написали поверх API - запускаем волнами по несколько ВМ с паузой между запусками.

HA на отечественном железе: нюансы

HA в zVirt 4.0 - всё тот же механизм oVirt HA с sanlock, который мы уже настраивали на первом кластере. Но на Aquarius-хостах вылезло несколько специфических вещей.

Тайминги sanlock. На хостах Aquarius с локальными NVMe-дисками под sanlock latency оказалась чуть выше, чем на типичных серверных конфигурациях, которые описаны в документации zVirt. Дефолтные таймауты sanlock (io_timeout) рассчитаны на SAN или быстрые блочные устройства. При пиковой нагрузке на СХД sanlock начинал считать хост недоступным раньше времени, что приводило к ложному срабатыванию HA - ВМ перезапускались на другом хосте без реальной причины. Решение - выставить sanlock_io_timeout через кастомный конфиг. Значение нужно подбирать под конкретное железо, универсального нет.

SPM-роль на смешанном кластере. Хост YADRO в кластере по характеристикам сети немного медленнее Aquarius-хостов на migration network. Это привело к тому, что при автоматическом выборе SPM он иногда брал эту роль на себя и это создавало излишнюю нагрузку при параллельных операциях. Прописали preferred SPM явно - на наиболее стабильном Aquarius-хосте.

Quorum при потере одного хоста. В кластере четыре хоста, и при падении одного кворум сходился нормально. Критичный момент - убедиться, что HA-агент на каждом хосте имеет доступ к SPM-хранилищу. При использовании двух СХД (как у нас - NFS и iSCSI) это требует явной проверки, а не «должно работать по документации».

Где сейчас

Второй кластер работает на zVirt 4.0 несколько дней. Продуктивные ВМ под нагрузкой, HA проверен учебным отказом одного хоста - результат ожидаемый, виртуалки поднялись на оставшихся хостах в пределах нескольких минут. VMware vCenter на этом клиенте теперь полностью выведен из эксплуатации.

Главный вывод по 4.0 на данный момент: релиз заметно взрослее предыдущих в части официальной поддержки отечественного стека. Astra Linux 2.8 как хостовая ОС без самодеятельности с репозиториями - это существенный шаг для КИИ-проектов. Проблемы с санлоком на специфичном железе - решаемы, но требуют понимания механики, а не только инструкции по установке.

В managed-сопровождении держим оба кластера под мониторингом. Если понадобится - поделимся конкретными значениями параметров sanlock по результатам наблюдений.