zVirt 4.1: обновляем тестовый кластер и проверяем live migration под нагрузкой

zVirt 4.1 вышел в конце декабря - мы его заметили, но не бросились обновлять всё подряд. Сначала подняли 4.1 на тестовом кластере, поигрались с нагрузкой и посмотрели, что из заявленного реально меняет жизнь, а что - пункт в release notes. Вот что зафиксировали за первую неделю.

Что нового в 4.1

Два изменения, которые вынесены в анонс как ключевые:

Расширенная поддержка CPU-офлоадинга. zVirt 4.1 добавляет поддержку аппаратного офлоадинга для более широкого спектра сетевых карт - прежде всего речь о виртуализации SR-IOV и работе с vDPA. На тестовом кластере у нас не было подходящих NIC с поддержкой vDPA, так что эту часть мы видели только по документации. SR-IOV, который использовался и в 4.0, работает без изменений - конфиги перенеслись без ручной правки.

Новый кластерный планировщик. Это то, что нас интересовало больше. В 4.0 планировщик размещения ВМ работал по достаточно простым политикам - Even Distribution и Power Saving из базового oVirt. В 4.1 разработчики переработали алгоритм взвешивания хостов: теперь учитывается не только текущая загрузка CPU и памяти, но и исторический профиль нагрузки за несколько минут. По идее, это должно снизить количество «пустых» миграций - когда планировщик видит кратковременный пик и начинает двигать ВМ, которые через минуту и сами бы успокоились.

Как проверяли: live migration под нагрузкой

На тестовом кластере - три хоста, около двадцати ВМ разного профиля - мы специально воспроизвели ситуацию, которая в 4.0 вызывала лишние миграции. Запускали стресс-тест на нескольких ВМ одновременно с пиковой нагрузкой на CPU около 80%, потом резко её снимали и наблюдали за поведением планировщика.

В 4.0 при таком сценарии планировщик успевал запустить одну-две миграции «в сторону» менее загруженного хоста прежде, чем нагрузка спадала. В 4.1 на аналогичном сценарии планировщик выдержал паузу - ВМ остались на месте. Это приятно. Особенно с учётом того, что каждая лишняя миграция PostgreSQL-ВМ под активной записью - это небольшое, но ощутимое прерывание работы с повышенным временем конвергенции памяти, о котором мы писали по итогам 4.0.

По самим live migration в 4.1 видимых изменений нет - механика QEMU-миграции та же, параметры migration_convergence_timeout и auto_converge работают так же. Но именно в контексте нового планировщика live migration стало происходить реже и по делу - что, собственно, и нужно.

Совместимость с Astra Linux SE 1.8

Отдельный вопрос, который нам задавали несколько клиентов: работает ли zVirt 4.1 с Astra Linux SE 1.8? Спойлер - в теории да, на практике с оговорками.

Официальной записи в матрице совместимости zVirt 4.1 и Astra Linux SE 1.8 на момент нашего тестирования нет. Astra Linux SE 1.7 (которая шла как «Смоленск 1.7») в матрице есть, 1.8 - отсутствует, хотя именно 1.8 выпустили в декабре и именно на неё переходят клиенты из КИИ.

Мы попробовали поднять хост zVirt 4.1 на Astra Linux SE 1.8 на тестовом железе. Установка агентов прошла, хост появился в Engine, ВМ запускаются. Узкое место нашлось в пакетах VDSM: часть зависимостей тянется из репозитория под 1.7, и при установке вылезают предупреждения о несовместимых версиях python-пакетов. Работает - но это не та ситуация, с которой хочется идти в продуктив на КИИ-объекте.

Вывод по совместимости: без официального подтверждения от вендора по Astra Linux SE 1.8 в продуктив ставить 4.1 не стоит. Для тестовых сред - можно, с пониманием риска.

Что с обновлением с 4.0

Апдейт Engine и хостов с 4.0 на 4.1 по нашему опыту проходит штатно - ни одной ВМ не уронили, Engine поднялся без ручного вмешательства. Стандартная процедура: Engine сначала, потом хосты поочерёдно через maintenance mode. Ничего необычного.

Единственный нюанс: после обновления Engine новый планировщик активируется автоматически для кластеров с политикой Even Distribution. Если у вас кластер с кастомными весами или политикой Power Saving - проверьте поведение явно, дефолтные значения весов изменились.

Где сейчас

Тестовый кластер на 4.1 работает несколько дней. Для продуктивных кластеров клиентов в managed-сопровождении держим 4.0 до прояснения ситуации с Astra Linux SE 1.8. Если вендор выпустит обновление матрицы совместимости в январе - обновление пройдёт быстро, у нас уже есть отработанный процесс.

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