Proxmox VE 8.2: разворачиваем кластер для клиента, уходящего с VMware ESXi

Proxmox VE 8.2 вышел на прошлой неделе, и мы, что называется, попали в нужное время: у нас как раз идёт развёртывание кластера для производственного клиента, который уходит с VMware ESXi. Релиз пришёлся кстати - несколько вещей из changelog напрямую касаются того, что мы сейчас делаем.

Почему вообще Proxmox

Вопрос «почему не vSphere» перестал быть дискуссионным после того, как Broadcom поглотил VMware и начал новую ценовую политику. Для СМБ это стало несколькими неприятными письмами от реселлеров с предложением переоформить лицензии по новым условиям. Часть клиентов восприняла это как повод наконец разобраться с альтернативами.

Proxmox VE в этом контексте интересен тем, что это не «бесплатная поделка», а полноценная платформа на базе Debian с коммерческой поддержкой и enterprise-репозиторием. KVM под капотом, LXC-контейнеры рядом, Ceph как опциональное хранилище. Для объектов без требования сертификата ФСТЭК на гипервизор - вполне обоснованный выбор.

Для нашего текущего клиента ситуация именно такая: объект КИИ по бумагам есть, но значимости второй категории нет, поэтому требование использовать только сертифицированное ПО на уровне гипервизора отсутствует. Это важное уточнение - если у вас значимый объект КИИ, дорожная карта выглядит иначе.

Что принёс Proxmox VE 8.2

Несколько изменений из релиза, которые нам реально важны в работе:

Ceph Reef (18.x) как поддерживаемая версия. Это главное в 8.2. Предыдущая версия Proxmox шла с Ceph Quincy (17.x). Reef принёс заметные улучшения в производительности BlueStore и улучшения в балансировке - PG Autoscaler стал умнее в части распределения Placement Groups. Для нашего трёхузлового кластера с гибридными дисками (NVMe + SAS) это повод тестировать Reef именно сейчас, а не ждать.

Обновлённый планировщик HA. В 8.2 переработана логика выбора узла при миграции виртуальных машин в HA-кластере. Планировщик теперь лучше учитывает текущую нагрузку на CPU и memory при принятии решения о размещении, а не только статические веса узлов. На практике это должно означать меньше ситуаций, когда после failover все ВМ с упавшего узла выстраиваются в очередь на один и тот же «лёгкий» хост.

Переработанный интерфейс. Proxmox давно не трогал UI кардинально, и в 8.2 его всё-таки приличнее переработали: дерево ресурсов стало отзывчивее, сводка по узлу информативнее, работа с хранилищами чище. Это не революция, но заметно. Клиенты, которые видели старый интерфейс 7-й версии и смотрели на него скептически - в 8.2 немного расслабляются.

Обновления ядра и QEMU. Базовое ядро обновилось до 6.8, QEMU до 8.2.2. Для нашей ситуации это важно: часть гостевых систем на ESXi работала с vmxnet3, и при переносе на KVM нужно работать с virtio. Более свежий QEMU лучше справляется с горячим добавлением устройств без перезагрузки гостя.

Как идёт миграция с ESXi

Клиент - производственное предприятие, три узла, порядка сорока виртуальных машин разного калибра: Windows Server, несколько Linux-серверов, одна Windows 10 для АРМ. Всё это жило на VMware ESXi 7.0 с vCenter Standard.

Схема миграции - без остановки: разворачиваем параллельный Proxmox-кластер на тех же физических серверах после добавления дополнительных дисков, переносим ВМ пачками через virt-v2v, тестируем, переключаем. vCenter и ESXi уйдут в конце.

Несколько наблюдений по ходу процесса:

virt-v2v работает, но требует внимания. Инструмент конвертации умеет работать с ESXi напрямую через API, и в большинстве случаев это работает. Но «большинство случаев» - не все. Виртуальные машины с несколькими дисками требуют проверки порядка устройств после конвертации. Несколько машин с Windows потребовали ручной переустановки драйверов - virtio-драйверы для Windows ставятся через ISO, который нужно монтировать в гостевую систему.

Сеть - отдельный разговор. В VMware-мире все привыкли к vSwitch с DVS. Proxmox работает с Linux-бриджами (OVS - опционально). Это принципиально другая модель конфигурации, и если у клиента была сложная сетевая топология с VLAN-тегированием на уровне vSwitch - придётся пересобирать конфигурацию руками под Linux-концепции. У нас топология несложная, но пара дней на это ушла.

Ceph на трёх узлах - минимальная конфигурация. Мы сознательно идём на неё, потому что четвёртый узел бюджетом не предусмотрен. Реплика 3, минимальный размер - нормально для отказоустойчивости, но нагрузочное тестирование при выходе одного узла нужно провести обязательно. С Reef это делаем следующим этапом.

Что настораживает

Proxmox - не vSphere, и это не только про интерфейс. Экосистема резервного копирования меньше. Proxmox Backup Server - хорошее решение, но если клиент использовал Veeam с vSphere integration, нужно либо переходить на PBS, либо разбираться с агентным резервным копированием от Veeam. У нас на этом проекте решаем через PBS - проще и дешевле, но это выбор нужно делать осознанно.

Поддержка через enterprise-подписку есть, но это не то же самое, что VMware Global Support с SLA и единым вендором. Для managed-сопровождения это означает, что часть ответственности за знания о платформе остаётся на нашей стороне, а не перекладывается на вендора.

Где мы сейчас

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

Proxmox VE 8.2 в качестве платформы для нового кластера - выбор, который сейчас выглядит обоснованным. Посмотрим, как он покажет себя под реальной нагрузкой.