Proxmox VE vs OpenStack: три пилота миграции с VMware и критерии выбора

В марте мы публиковали первый отчёт по пилоту Proxmox VE и обзор тестового кластера OpenStack Yoga. С тех пор пилоты продолжались, и к началу мая у нас закрыты три проекта миграции с VMware vSphere - с разными клиентами, разным масштабом и разными итогами. Время свести всё в одну картину.

Три пилота - три контекста

Проекты были разные, и это важно - иначе сравнение получилось бы нечестным.

Первый - SMB-клиент, три хоста ESXi, около двадцати виртуалок, команда поддержки без выделенного VMware-инженера. Переехали на Proxmox VE 7.1. Этот кейс мы уже описывали подробно.

Второй - клиент покрупнее: восемь физических хостов, порядка шестидесяти ВМ, есть выделенные системные администраторы с опытом Linux-серверов, но без глубокого OpenStack-бэкграунда. Тоже переехали на Proxmox, но уже в кластерной конфигурации с Ceph в качестве shared storage.

Третий - у клиента инфраструктура под сервисы с multi-tenant требованиями и необходимостью изолировать окружения разных внутренних команд. Плюс стояла задача bare-metal provisioning для части нагрузки. Здесь выбрали OpenStack Yoga, развернули через Kolla-Ansible.

Что показало сравнение

Попробуем честно: не «что лучше», а «что у каждого получается».

Это не исчерпывающий список параметров, но это те параметры, по которым у нас возникали реальные вопросы в ходе трёх пилотов.

Где Proxmox явно выигрывает

Второй пилот показал это нагляднее всего. Клиент получил работающий кластер из восьми нод с Ceph примерно за три рабочих дня - включая перенос ВМ. Команда разобралась в интерфейсе за несколько часов. Proxmox Web UI - не самый красивый, но плотный и быстрый, и в нём видно всё, что нужно для ежедневной работы.

Ansible-интеграция тоже адекватная: есть community-модули для управления ВМ, снапшотами, конфигурацией нод. Не такой богатый набор, как для vSphere через govmomi, но для стандартных задач хватает.

Proxmox Backup Server в связке с основным кластером работает нормально - дедупликация, верификация, политики ротации. Это отдельный продукт, но лёгкий в настройке.

Главное ограничение Proxmox - горизонт масштаба. Кластер из нескольких десятков нод - это уже территория, где начинают проявляться вещи, которые в крупных инсталляциях неудобны: RBAC не такой гибкий, как хотелось бы, сетевая изоляция между проектами делается вручную через VLAN, единого control plane для нескольких кластеров нет.

Где OpenStack оправдывает сложность

Третий пилот - это тот случай, где сложность OpenStack не избыточна, а адекватна задаче. Multi-tenant изоляция через проекты Keystone, отдельные сети на каждый tenant через Neutron с OVN, Octavia для балансировки - всё это есть из коробки, это первоклассные граждане системы, а не заплатки поверх.

API у OpenStack - это отдельная тема. Когда клиент говорит «нам нужно управлять инфраструктурой программно», OpenStack даёт стандартный набор: Nova API, Neutron API, Cinder API - каждый с документацией, с python-клиентом, с Terraform-провайдером. Писать IaC под OpenStack - это не изобретение велосипеда, это стандартный workflow.

Ironic в Yoga стал заметно приличнее. Провижининг bare-metal машин через IPMI и PXE работал без глубоких шаманств - у нас ушёл один день на настройку, и это с нуля, не с готовым шаблоном.

Операционная нагрузка выше - это честный минус. Обновление кластера между релизами OpenStack - это упражнение с серьёзным upgrade guide и обязательным staging. Kolla-Ansible упрощает жизнь, но не убирает необходимость понимать, что происходит под капотом.

Как мы формулируем критерии выбора

После трёх пилотов у нас примерно такой алгоритм:

• Парк до 10-15 хостов, команда без глубокого cloud-опыта, нет требований к multi-tenant - Proxmox VE. Операционная нагрузка соразмерна, порог входа адекватный, всё работает без PhD.

• Есть требования к изоляции проектов, нужен API для автоматизации ресурсов, планируется масштаб больше пары десятков хостов - OpenStack. Но только если команда готова к операционной сложности или её сопровождают.

• Нужен bare-metal provisioning - OpenStack с Ironic, альтернатив на практике нет.

• Бюджет и сроки очень сжаты, команды нет - Proxmox, и сопровождение с нашей стороны быстрее раскатать, чем объяснять Neutron с нуля.

Что остаётся открытым

Мы не трогали в этих трёх пилотах GPU-нагрузки и PCI passthrough - там своя история. Не тестировали high availability для самого control plane OpenStack в production-условиях - в пилоте это было упрощено.

Ещё один вопрос, который клиенты задают всё чаще: что с лицензиями и поддержкой у Proxmox в долгую? Community-версия бесплатна, enterprise-подписка есть - но это небольшая европейская компания, и у части клиентов есть резонные вопросы про устойчивость. Мы пока не имеем чёткого ответа, который устроил бы всех - просто фиксируем как открытую точку.

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