Proxmox VE: что это, как работает и кому подходит

Главный аргумент Proxmox VE прост: бесплатный, с кластером из коробки и собственным сервером бэкапа, на фоне Broadcom-цен VMware это весомо. Главное ограничение - нет сертификации ФСТЭК и записи в реестре отечественного ПО, а это закрывает доступ к КИИ и ГИС. Proxmox VE - что это и можно ли построить на нём корпоративную виртуализацию вместо VMware vSphere? Под капотом - открытая платформа от австрийской Proxmox Server Solutions GmbH на базе KVM и LXC поверх Debian, с веб-интерфейсом и встроенной кластеризацией.

Дальше в статье - как Proxmox VE устроен внутри, чем технически отличается от VMware, как лицензируется и каким компаниям он реально подходит.

Кнопка: оставить заявку

Что такое Proxmox VE и кто его делает

Proxmox VE - серверная платформа виртуализации с открытым исходным кодом, которая объединяет KVM (полная виртуализация x86) и LXC (системные контейнеры) под единым веб-интерфейсом. Вендор - Proxmox Server Solutions GmbH (Австрия), релизы с 2008 года, лицензия GNU AGPL v3. База - Debian с кастомным ядром на Ubuntu LTS. Текущее поколение - 8.x. Поставка - ISO-образ с Debian и Proxmox-пакетами либо установка поверх существующего Debian. Ключевая особенность: один продукт закрывает сразу полные ВМ и контейнеры и приносит встроенную кластеризацию без отдельного сервера уровня vCenter.

Архитектура Proxmox VE: как платформа устроена внутри

Гипервизор Proxmox VE - ядро Linux с модулем KVM и QEMU, полная виртуализация x86-машин с virtio. Контейнеры реализованы через LXC - лёгкие системные окружения отдельной ОС, удобные для статичных сервисов без жёсткой изоляции на уровне ядра.

Управление - HTML5 веб-интерфейс на каждом узле (порт 8006). Из консоли работают команды pvesh, qm, pct и REST API. Кластер строится из равных узлов через Corosync и распределённую файловую систему pmxcfs - отдельной «головы» уровня vCenter нет, конфигурация реплицируется между всеми узлами автоматически.

Хранилище: ZFS, Ceph (входит в дистрибутив), NFS, iSCSI, локальные диски и LVM. Сеть - Linux bridge, OVS, VLAN и SDN из коробки. Параллель с VMware: vCenter → отсутствует как отдельный продукт, ESXi → узел Proxmox, datastore → storage.

Чем Proxmox VE отличается от VMware vSphere

Когда вы сравниваете proxmox vs vmware, речь идёт о vSphere Standard или Enterprise Plus с vCenter - против Proxmox VE со встроенным кластером и Proxmox Backup Server.

Что у Proxmox VE есть как у VMware

1. HA - автоматический рестарт ВМ при отказе узла кластера;
2. Live migration - миграция работающей ВМ между узлами без простоя;
3. Снапшоты, шаблоны и клоны ВМ;
4. Бэкап - vzdump для полных дампов и Proxmox Backup Server для инкрементальных копий с дедупликацией;
5. Распределённое хранилище - Ceph входит в комплект (аналог идеи vSAN);
6. Импорт ВМ из OVA/OVF, диски qcow2 и raw.

В чём Proxmox проще или слабее

1. Нет vCenter как отдельного продукта - управление встроено в каждый узел. Архитектурно проще, но непривычно после VMware.
2. Нет аналогов NSX-T, vRealize / Aria, Tanzu, AppDefense, Skyline.
3. Нет сертификации ФСТЭК и реестра отечественного ПО - критично для КИИ, ГИС, ИСПДн с высокими УЗ и большинству госконтрактов.
4. Меньше готовых интеграций уровня корпоративной экосистемы (мониторинг, ITSM).
5. Документация и сообщество - преимущественно англоязычные.

Proxmox закрывает базовые сценарии vSphere, но не корпоративные: NSX-T, Tanzu, Aria и ФСТЭК остаются за рамками.

Лицензирование Proxmox VE: бесплатно или с подпиской

Лицензирование Proxmox устроено просто: продукт распространяется по GNU AGPL v3, использование без оплаты - доступ к no-subscription репозиторию свободный. Платная подписка - это поддержка вендора и доступ к стабильному enterprise-репозиторию с обкатанными обновлениями.

Подписка делится на четыре уровня по возрастанию SLA: Community, Basic, Standard, Premium. Различия - число тикетов в год, удалённая поддержка, время ответа. Цена - в евро в год на каждый сокет физического процессора. Конкретные цифры - по открытым данным на дату публикации, прайс меняется.

Подписка нужна для коммерческого продакшена с SLA, банков, финтеха, инфраструктур, где простой стоит дорого. Без неё можно работать на тест-стендах, лабах, MSP с собственной экспертизой. Без подписки в логах появляется напоминание о no-subscription репозитории - на работу не влияет, но многие администраторы переключаются на enterprise-репозиторий.

Миграция с VMware на Proxmox VE: способы и нюансы

Миграция с vmware на proxmox реализуется тремя способами. Первый - импорт OVA/OVF через qm importovf на узле Proxmox. Универсально, но требует места и времени. Второй - прямой импорт с ESXi storage (мастер с Proxmox VE 8.2): веб-интерфейс подключается к ESXi и переносит ВМ напрямую. Третий - сторонние инструменты (Veeam, Vinchin, ClonOS) для парков от 50 ВМ. Автоматически переносятся образ диска и базовые параметры ВМ. Вручную: VMware Tools удаляется до миграции, virtio в Windows-гостях, MAC и IP фиксируются заранее, кастомные .vmx переносятся отдельно.

Чек-лист этапов миграции: до, в день, после

1. До миграции - инвентаризация ВМ. Пилот на 2–3 машинах, установка virtio-драйверов в гостевые Windows, план отката, синхронизация бэкапов в Proxmox Backup Server.
2. В день миграции - удаление VMware Tools перед стартом, запуск импорта в мультипотоке, финальный холодный синк на минутах простоя, обновление DNS и таблиц маршрутизации.
3. После миграции - проверка virtio, сети и MAC, проверка работы кластера и Live migration, нагрузочный прогон 24–48 часов, вывод исходных ВМ из эксплуатации после стабильного периода.

Системные требования и подбор железа

Системные требования Proxmox в продакшене - это не «минимальные» цифры с офсайта, а конфигурация, которая выдержит нагрузку и позволит включить HA. Процессор должен поддерживать Intel VT-x или AMD-V и виртуализацию памяти (EPT / RVI). Рекомендуемые поколения - Xeon Scalable от 2-го (Cascade Lake) и AMD EPYC Rome / Milan / Genoa.

Память: минимум 4 ГБ для теста, в продакшене от 64 ГБ ECC на узел, для нагруженных кластеров - 256–512 ГБ. ZFS требует дополнительного RAM под ARC-кеш - закладывайте 1 ГБ RAM на 1 ТБ хранилища. Сеть: для лабораторий 1×1 Gb, в продакшене 2×10 Gb на узел с разнесением management, production и storage, для нагруженных кластеров 25/100 Gb. Хранилище: одноузловой сервер - локальный ZFS-пул на NVMe, кластер - Ceph, NFS или iSCSI (локальный сторадж не работает с Live migration). По правилу N+1 держите 30% запаса по vCPU и RAM.

Если вы планируете прод-кластер из 3–5 узлов на Proxmox, ориентируйтесь на серверы под виртуализацию с двумя сокетами Xeon Scalable, ECC-памятью от 256 ГБ и парой портов 10/25 Gb на узел - это даст запас под HA и Live migration без узких мест.

Кластер, HA и резервное копирование Proxmox

Кластер Proxmox требует минимум 3 узла для нормальной работы кворума и HA. Технология - Corosync поверх pmxcfs, выделенного управляющего сервера нет, конфигурация реплицируется автоматически. Live migration работает при общем хранилище (NFS, iSCSI или Ceph) и совместимых CPU между узлами. HA Manager автоматически перезапускает ВМ при отказе узла, правила настраиваются на уровне отдельных машин или групп.

Бэкап реализован на двух уровнях: vzdump делает полные дампы ВМ и контейнеров, Proxmox Backup Server - инкрементальный бэкап с дедупликацией, шифрованием и восстановлением одиночных файлов. Distributed Replication даёт ZFS-репликацию между узлами с минутной точностью - основа для DR без отдельной СХД. Если железо однородное, Ceph внутри кластера даёт гиперконвергентную схему.

Практический пример кластера Proxmox VE: конфигурация на 3 узла

Настройка кластера Proxmox на практике чаще всего сводится к гиперконвергентной схеме из трёх одинаковых узлов, где KVM и Ceph живут в одном контуре и не требуют внешней СХД. Такой кластер Proxmox из трёх нод переживает плановый или аварийный отказ любого одного узла: кворум сохраняется, ВМ перезапускаются на живых нодах, а данные остаются доступными за счёт репликации Ceph. Ниже - конкретная конфигурация, которую вы можете взять за отправную точку и адаптировать под свою нагрузку.

Железо на узел

Все три ноды делаются идентичными - это упрощает Live migration и балансировку Ceph. На узел закладывается два сокета Xeon Scalable, 256–512 ГБ ECC RAM, отдельный NVMe под операционную систему с ZFS-зеркалом и отдельные NVMe или SSD корпоративного класса под OSD Ceph. Сетевые адаптеры - 10/25 GbE, желательно два порта под данные и отдельный интерфейс под управление. Чтобы три узла были идентичны по CPU и дискам под Ceph, удобнее сразу заказать подбор серверного оборудования под параметры кластера, а не собирать ноды по остаткам склада - разнобой по контроллерам и дискам бьёт по стабильности OSD.

Сеть: три раздельных сегмента

Сеть - ключевой момент всей схемы. Правильнее развести три независимых сегмента. Первый - management: веб-интерфейс на порту 8006, SSH, API. Второй - выделенная сеть Corosync под кворум, где важна низкая и стабильная латентность. Третий - сеть Ceph и Live migration на 25/100 GbE, через которую идёт основной объём трафика репликации и переноса ВМ. Corosync выносят в отдельную сеть не из перфекционизма: если кворумный трафик делит линк с нагруженным Ceph, всплеск репликации поднимает задержки, ноды перестают вовремя видеть друг друга, и кластер уходит в риск split-brain. Отдельный физический канал под Corosync снимает эту зависимость. Разнесение Corosync и Ceph требует запаса портов 10/25 GbE - это стоит учесть при выборе сетевого оборудования, потому что нехватка портов позже выливается в переделку топологии.

Пример IP-схемы для трёх узлов:

Кворум

Три узла дают классический нечётный кворум: кластер держит отказ одной ноды и продолжает обслуживать ВМ. Если у вас на старте только две физические ноды, голосов не хватает, и корректное решение - добавить QDevice: внешний арбитр на небольшом сервере или VM вне кластера, который отдаёт третий голос и снимает патовую ситуацию при отказе одного из двух узлов. Но полноценный гиперконвергентный сценарий с Ceph всё равно начинается с трёх нод.

Хранилище

Под данные ВМ разворачивается пул Ceph с фактором репликации 3: каждый объект хранится в трёх копиях на разных нодах, что и обеспечивает выживание кластера при потере одного узла. Отдельный пул удобно выделить под диски ВМ, отделив его от служебных данных. Локальный ZFS остаётся только под операционную систему узла - держать на нём продакшен-ВМ не стоит: локальный сторадж не участвует в Live migration, и такие машины нельзя переносить между нодами без простоя.

HA и правило N+1

За автоматический перезапуск отвечает HA Manager. ВМ объединяются в HA-группы с привязкой к нодам и приоритетами, а корректный вывод зависшего узла обеспечивает fencing через watchdog - он гарантирует, что «подвисшая» нода не будет одновременно держать те же ВМ, что уже поднялись в другом месте. HA Proxmox имеет смысл только при запасе ресурсов: по правилу N+1 держите около 30% свободного vCPU и RAM на кластер, чтобы после отказа одной ноды оставшиеся две приняли её нагрузку без деградации.

Резервное копирование

Proxmox Backup Server ставится отдельным узлом за пределами кластера. Смысл прост: если PBS живёт внутри того же контура, авария кластера или хранилища накрывает вместе с продакшеном и резервные копии. Вынесенный PBS с собственными дисками хранит инкрементальные дедуплицированные бэкапы и остаётся доступным даже тогда, когда основной кластер недоступен.

Базовый порядок сборки кластера в консоли выглядит так:

# на первом узле создаём кластер

pvecm create prod-cluster --link0 10.0.20.11

# на остальных узлах присоединяемся к кластеру

pvecm add 10.0.20.11 --link0 10.0.20.12

# проверка статуса кворума

pvecm status

Ceph при этом разворачивают через веб-интерфейс или утилиту pveceph: инициализация, мониторы, OSD и пул. Команды выше даны как ориентир - точный синтаксис и версии флагов всегда сверяйте с документацией Proxmox VE 8.x.

Итоговый порядок настройки:

1. Подготовка сети - три раздельных сегмента (management, Corosync, Ceph/миграция) и адресация по IP-схеме.
2. Создание кластера на первом узле через pvecm create.
3. Добавление второго и третьего узлов через pvecm add и проверка кворума.
4. Разворачивание Ceph - мониторы, OSD, пул с репликацией 3.
5. Настройка HA - группы ВМ, watchdog-fencing, запас N+1.
6. Резервное копирование - подключение вынесенного Proxmox Backup Server и расписание заданий.

Ограничения и риски

Главное ограничение - нет сертификации ФСТЭК и нет в реестре отечественного ПО. Это закрывает доступ к КИИ, ГИС, ИСПДн с высокими УЗ и большинству госконтрактов. Для таких задач смотрите zVirt и другие сертифицированные платформы. Иностранный вендор (Австрия) - для российских компаний это операционный риск с поддержкой: у Proxmox нет российского представительства с локальной техподдержкой и SLA.

Документация и сообщество в основном англоязычные. Меньше готовых интеграций экосистемы VMware (мониторинг, ITSM). Опытных Proxmox-инженеров на рынке труда меньше, чем VMware-администраторов - это влияет на найм и стоимость поддержки.

Кому подходит Proxmox VE, а кому нет

Чек-лист из пяти вопросов поможет понять ваш сценарий:

1. Подпадаете под требования по импортозамещению - КИИ, госконтракты, регуляторы?
2. Зависите от VMware-функций без аналогов: NSX-T с микросегментацией, Tanzu, vRealize / Aria?
3. Есть инженеры с опытом Linux/KVM или готовность их обучить?
4. Парк ВМ - стандартный (Windows Server, Linux, БД, веб) без RDM, FT, vGPU?
5. Готовы платить за подписку Proxmox или иметь собственную экспертизу для поддержки?

Подходит: малый и средний бизнес без КИИ, MSP/хостинг, тест-стенды, DevOps-окружения. Подходит с подпиской: коммерческий продакшен среднего масштаба со стандартными нагрузками - подписка нужна для SLA и стабильного репозитория. Не подходит: КИИ и госорганизации (нужна сертифицированная платформа уровня zVirt) и enterprise с глубокой зависимостью от VMware-стека (NSX, Tanzu, Aria).

Заключение

Proxmox VE - рабочее open-source решение для большинства инфраструктур без требований КИИ: малый и средний бизнес, MSP, хостинг, DevOps. Для КИИ и проектов с глубокой зависимостью от VMware-экосистемы лучше рассматривать zVirt или другие сертифицированные платформы.

Практический следующий шаг: разверните пилот на 2–3 узлах с Proxmox Backup Server, проверьте совместимость железа, обкатайте миграцию одной-двух ВМ и сравните стоимость подписки Proxmox с текущими лицензиями VMware. Когда состав парка и план миграции понятны, удобно подобрать сервер под Proxmox под конкретную нагрузку: тип процессора, объём памяти и ZFS/Ceph-конфигурация подбираются так, чтобы пилотный кластер можно было масштабировать без замены платформ.