zVirt 3.0: переводим второй кластер VMware vSphere и проверяем live migration, HA и СХД

Несколько месяцев назад мы перевели первый кластер VMware vSphere на zVirt у клиента из реестра КИИ. Тот кластер был относительно несложным: десяток виртуалок, один датастор, оборудование новое. Результат нас устроил настолько, что было принято решение двигаться дальше - переводить второй кластер, где жизнь уже интереснее: больше нод, две разных СХД (Аквариус и Hitachi), ряд виртуалок под нагрузкой без возможности долгого окна обслуживания.

Как раз к этому моменту вышел zVirt 3.0 с обновлённым стеком на базе свежего oVirt и обещаниями улучшенной совместимости с отечественным железом. Решили работать сразу на новой версии.

Почему zVirt, а не Proxmox или голый KVM

Вопрос закономерный, и его нам задают клиенты регулярно. Proxmox тоже KVM-based, тоже бесплатный в базовой конфигурации, тоже умеет кластеры. Но в контексте КИИ играют роль несколько факторов, которые сдвигают выбор:

• Реестр Минцифры и сертификат ФСТЭК. zVirt там есть, Proxmox - нет. Для клиентов, где закупки идут по 44-ФЗ и где регулятор может прийти с вопросом «на основании чего», это аргумент, который закрывает дискуссию.
• Поддержка от российского вендора. Это не значит, что поддержка лучше по качеству, но это значит, что она есть на русском языке, в российской юрисдикции и с подписанием NDA по российскому праву.
• API-совместимость с oVirt. Клиент, у которого уже есть инструменты вокруг oVirt-стека (Ansible-плейбуки, скрипты бэкапа), переходит с минимальной переделкой. Голый KVM - это переписывать всё с нуля.

Как выглядел второй кластер до переезда

Пять физических хостов, VMware vSphere 7.0. Два типа СХД: Аквариус NAS с NFS-датастором и Hitachi VSP с блочным iSCSI. Итого три датастора, несколько десятков виртуальных машин, часть из которых - продуктивные сервисы с SLA.

vCenter управлял всем этим хозяйством. DRS и HA были включены. Конфигурация нехитрая, но и не тривиальная: разные типы хранилищ, разные профили виртуалок - от лёгких вспомогательных до тяжёлых СУБД.

Подготовка: что проверили перед стартом

Первая итерация с первым кластером научила нас не спешить. Перед переводом второго прошли по чеклисту:

Совместимость СХД. zVirt 3.0 поддерживает NFS и iSCSI через стандартные механизмы libvirt/oVirt. Аквариус NAS подключился без сюрпризов - там стандартный NFS v3/v4. С Hitachi VSP по iSCSI потребовалась небольшая работа с multipath: дефолтные настройки dm-multipath на хостах zVirt не совпадали с рекомендациями Hitachi для VSP, пришлось выставить правильный path_selector и no_path_retry. Не критично, но требует знания документации вендора СХД - не только zVirt.

Версии виртуалок. VMware vmx-версии выше 14 при конвертации через virt-v2v теряют часть метаданных. Перед миграцией понизили аппаратную версию там, где это было возможно без потерь.

Сетевая конфигурация. В vSphere был распределённый vSwitch с несколькими портгруппами. В zVirt это транслируется в OVN-сети или Linux bridge - в зависимости от конфигурации. Выбрали Linux bridge как более предсказуемый вариант, OVN оставили на потом.

Live migration: проверяем на практике

Live migration в zVirt (он же live migrate в терминах oVirt) работает через стандартный QEMU live migration поверх выделенного migration network. Мы настроили отдельный VLAN для миграционного трафика - это рекомендация документации, и она разумна: без изоляции миграционный трафик может конкурировать с продуктивным на 10GbE-аплинках.

Протестировали на нескольких виртуалках под нагрузкой. Результат - миграция между хостами проходит без заметных прерываний для сетевых соединений. Виртуалки с небольшим рабочим сетом памяти мигрируют быстро и чисто. Виртуалки с активно изменяемой памятью (СУБД под нагрузкой) - дольше, memory dirty rate влияет на время конвергенции, это стандартное поведение KVM live migration, не специфика zVirt.

Одна особенность, которая нас немного удивила: в zVirt 3.0 интерфейс миграции через веб-UI работает чисто, но при одновременной миграции нескольких виртуалок очерёдность не всегда очевидна. Движок ставит их в очередь, логика приоритизации в документации описана коротко. На практике это не мешало, но знать об этом полезно.

HA: настраиваем и проверяем

HA в zVirt основан на механизме oVirt High Availability в связке с sanlock для блокировок на уровне хранилища. Это принципиально отличается от VMware HA, где мастер-хост следит за heartbeat через datastore и сеть. В zVirt/oVirt агент HA (ovirt-ha-agent) работает на каждом хосте и принимает решение локально на основе состояния sanlock-лизов.

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

Один нюанс специфичен для нашей конфигурации с двумя типами СХД: HA-агент опирается на SPM (Storage Pool Manager) - роль, которая в каждый момент принадлежит одному хосту. Если SPM-хост падает, кворум переизбирает новый SPM, и это добавляет несколько секунд к времени восстановления. При двух типах хранилищ нужно убедиться, что preferred-хранилище для SPM выбрано правильно - по надёжности и задержкам.

Где мы сейчас

Перевод второго кластера занял несколько рабочих дней с учётом подготовки и тестирования. Все продуктивные виртуалки работают на zVirt 3.0. VMware vCenter выведен из эксплуатации на этом клиенте полностью.

Что можно сказать по итогам двух миграций: zVirt 3.0 - это не просто «KVM с веб-мордой». Это достаточно зрелый продукт для замены vSphere в типичной инфраструктуре КИИ. Болевые точки - совместимость с конкретными моделями СХД и поведение при сложных сетевых конфигурациях - решаемы, но требуют понимания стека, а не только кнопок в UI.

Параллельно ведём ещё два аналогичных проекта у других клиентов - там другое железо и другие СХД, так что картина будет шире. В рамках managed-сопровождения держим всё это под наблюдением.