oVirt 4.5 в продакшне: итоги миграции 150 ВМ в госучреждении

Три месяца назад взялись за миграцию с VMware vSphere 7 на oVirt 4.5 в государственном учреждении - 150 виртуальных машин, production-среда с требованиями по доступности и, само собой, перечнем требований по отечественному ПО. Сейчас всё работает, проект формально закрыт. Рассказываем без прикрас.

Почему oVirt, а не zVirt или Proxmox

Это был не наш выбор в полном смысле слова. У клиента требование - платформа виртуализации должна входить в реестр отечественного ПО или использоваться как основа для такой платформы. zVirt - очевидный кандидат, но на момент старта проекта у заказчика уже стоял пилот oVirt 4.5, развёрнутый предыдущим подрядчиком. Переходить на что-то другое означало ещё одну итерацию миграции, которую никто оплачивать не собирался.

Выбор, таким образом, свёлся к тому, чтобы работать с тем, что есть - и довести это до production-состояния. У oVirt 4.5 достаточная зрелость для такой задачи: движок на базе libvirt/QEMU, Engine на WildFly, приличный веб-интерфейс. Не самая удобная в мире система, но не сырая.

Что сработало хорошо

Live Migration. Это главное открытие проекта, если честно. Мы шли в него с определёнными ожиданиями, помня разный опыт с предыдущими миграциями. oVirt live migration для Linux-гостей отработала чисто - переезд ВМ между узлами без остановки, без потерь соединений, в плановые окна. Перенесли таким образом основной пул машин с минимальным числом простоев. Windows-гости тоже мигрировали нормально, хотя чуть медленнее из-за особенностей работы с памятью.

oVirt Engine и REST API. Управление кластером через веб-интерфейс Engine оказалось удобнее, чем ожидалось. Ansible-коллекция ovirt.ovirt покрывает большинство операций - создание, настройка, миграция ВМ. Переписали операционные скрипты клиента значительно быстрее, чем на прошлых проектах, просто потому что API документирован и предсказуем.

Конвертация Linux-гостей. Стандартная схема через virt-v2v с источником VMware - работает. PVSCSI-контроллеры отдельно переключали перед конвертацией, как уже делали раньше - эта история хорошо известна из предыдущего проекта с zVirt. Заложили это в чеклист и прошли без сюрпризов.

Где всё пошло не так

iSCSI shared storage. Вот тут нас накрыло. Архитектура хранилища у клиента - внешний iSCSI-массив, который предполагалось использовать как общий storage domain для кластера oVirt. На бумаге oVirt поддерживает iSCSI storage domains нормально. На практике мы потратили недели три на разбор проблем с multipath, таймаутами сессий и периодическими ошибками storage manager.

Корень проблем - в связке oVirt Storage Manager (VDSM) с конкретным firmware массива. VDSM делает определённые предположения о поведении iSCSI-таргета при переподключении, и когда массив эти предположения не разделял, начинались таймауты со стороны Engine. Часть проблем решилась правкой параметров multipath, часть - патчем конфигурации VDSM, часть - обновлением firmware массива. Но это не та история, когда «просто подключили и заработало».

Интерфейс администрирования. Это субъективное, но скажем: веб-интерфейс oVirt Engine за эти месяцы изучили хорошо - и он функциональный, но местами ведёт себя неожиданно. Ошибки в интерфейсе бывают неинформативными, и поиск реальной причины уходил в логи VDSM и Engine на хостах. Для команды, привыкшей к vCenter, - заметный откат по UX. Не критично, но честно.

Отдельные Windows-гости. Несколько машин с нестандартными конфигурациями дисков (несколько RDM в исходной инфраструктуре) потребовали ручной пересборки. virt-v2v с такими не дружит, пришлось делать через экспорт и ручную конвертацию с последующей установкой virtio-драйверов внутри. Это было предсказуемо, просто трудоёмко.

Куда дальше

Клиент сейчас изучает zVirt как следующий шаг - с учётом направления на отечественные платформы в госсекторе это логично. oVirt 4.5 как upstream для zVirt означает, что экспертиза, накопленная за эти три месяца, не пропадает: архитектура Engine, API, поведение VDSM - всё это в zVirt узнаваемо.

Shared storage через iSCSI в будущей конфигурации будем рассматривать с осторожностью - скорее всего, предложим альтернативу на Ceph или NFS в зависимости от объёмов. Опыт с iSCSI в oVirt на этом проекте достаточно убедительно показал, что зависимость от конкретного железа и firmware здесь выше, чем хотелось бы.

Сам проект - хороший пример того, чем управляемая инфраструктура отличается от разового развёртывания: трёхмесячная работа с платформой, которую никто до конца не знал, с реальными production-требованиями. Сдали работающее, хвостов осталось немного.