Proxmox VE как замена VMware для офиса: реальный кейс на 3 ноды
Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За последние полтора года ко мне обратились восемь компаний с одной и той же проблемой: VMware после ухода Broadcom стал стоить как чугунный мост, а штатный админ говорит «без vSphere мы умрём». Расскажу про самый показательный из этих проектов — компания ПромТорг, 40 рабочих мест, две стойки в собственной серверной, бюджет на лицензии вырос с 220 до 580 тыс. руб./год. Мы перевели всё на Proxmox VE за два выходных, окупили проект за полгода, и админ клиента после этого присылал мне на Новый год коньяк.
Контекст: как Broadcom задрал цены на VMware
Я работаю с виртуализацией с 2008 года, когда ESXi 3.5 ещё ставился с диска. VMware был стандартом де-факто: дорого, зато стабильно и предсказуемо. В ноябре 2023 года Broadcom купил VMware за 61 миллиард долларов и начал переделывать модель лицензирования. К началу 2025 года новая схема докатилась до российского рынка: вместо привычной per-socket подписки ввели per-core, минимум 16 ядер на сокет, а Essentials Plus (типичный пакет для среднего офиса) подорожал в 2.5–4 раза в зависимости от конфигурации.
Мой клиент ПромТорг — оптовая торговля стройматериалами, 40 человек в офисе на Юго-Западной, две стойки на 2 сервера + СХД в собственной серверной. До конца 2024 года они платили 220 тыс. руб./год за VMware vSphere Essentials Plus + 95 тыс. руб./год за Veeam Backup Essentials. После пересмотра тарифов Broadcom им выкатил счёт на 580 тыс. руб. за следующий год — ровно за тот же объём, ровно за то же железо. У клиента 18 виртуальных машин: контроллер домена, 1С-сервер, файловый сервер, IIS, почтовый шлюз, два терминальных сервера, SQL для CRM, и ещё мелочёвка. Ничего особенного, типичный офис.
Почему именно Proxmox, а не XCP-ng или oVirt
Когда выбираешь альтернативу VMware, на столе обычно три варианта: Proxmox VE, XCP-ng (бывший XenServer) и oVirt (теперь OpenShift Virtualization от Red Hat). Я перепробовал все три на разных проектах за последние полтора года, и для офисного сегмента уверенно выбираю Proxmox. Вот почему.
- Зрелость и комьюнити. Proxmox существует с 2008 года, за плечами 17 лет разработки. Issue tracker и форум живые, баги закрываются за дни, а не за месяцы.
- База Debian. Под капотом — обычный Debian Linux. Если ваш админ умеет читать
journalctlи редактировать/etc/network/interfaces, он разберётся с Proxmox за неделю. С oVirt пришлось бы изучать Ansible, Engine, всю экосистему Red Hat. - Web UI без бубна. Открываешь браузер на 8006-м порту — и работаешь. Никакого тяжёлого vCenter, который сам требует виртуальную машину с 16 ГБ ОЗУ.
- Бесплатная подписка опциональна. Можно вообще без подписки, можно Standard за 30 тыс. руб./сокет/год — это в разы дешевле VMware Essentials.
- Встроенный Proxmox Backup Server. Заменяет Veeam с дедупликацией и инкрементальными копиями. Бесплатно.
XCP-ng я тоже люблю, но у него меньше комьюнити, а Xen Orchestra (нормальный веб-UI) либо платный, либо требует самостоятельной сборки из исходников. Это плохо для клиента, у которого админ — один человек.
Архитектура: 3 ноды, локальные диски, ZFS-репликация
На старте у клиента было два сервера HP DL380 Gen10 с СХД HP MSA 2050 на iSCSI. Я предложил пересобрать инфраструктуру по другой логике: вместо дорогого общего хранилища взять три однотипные ноды с локальными NVMe-дисками и использовать ZFS-репликацию вместо общего стораджа. Получается дешевле, быстрее и без единой точки отказа в виде СХД.
| Компонент | Старая инфраструктура | Новая инфраструктура |
|---|---|---|
| Гипервизор | VMware vSphere Essentials Plus | Proxmox VE 8.2 + подписка Standard |
| Серверы | 2× HP DL380 Gen10 | 3× HP DL380 Gen10 (добавили ещё один из стока) |
| Хранилище | HP MSA 2050 (iSCSI, 24×1.2TB SAS) | Локальные NVMe (4×1.92TB Samsung PM9A3 на ноду) |
| Файловая система | VMFS на iSCSI LUN | ZFS RAID-10 локально + zfs-send репликация |
| Сеть | 2×10GbE LACP к коммутатору | 2×10GbE LACP + 2×1GbE для Corosync |
| Бэкапы | Veeam Backup Essentials → NAS Synology | Proxmox Backup Server на отдельной железке + копия в дата-центр |
Старую СХД MSA 2050 не выбросили — переделали под второй уровень бэкапов и архив старых данных 1С (по требованиям ФНС хранить 5 лет).
Установка кластера: пошагово на боевом железе
Установка Proxmox VE на сервер занимает 12 минут. Скачиваешь ISO с официального сайта (около 1.3 ГБ), записываешь на флешку через Rufus, в BIOS выставляешь UEFI-загрузку и проходишь стандартный мастер. Я ставлю на ZFS RAID-10 поверх 4-х NVMe-дисков сразу из инсталлятора — потом ничего перенастраивать не нужно.
После установки трёх нод собираем кластер. Сетевая конфигурация на каждой ноде в /etc/network/interfaces делается так:
# Management — VLAN 10, 1GbE
auto eno1
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.10.10.11/24
gateway 10.10.10.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
# Corosync — отдельный физический порт, VLAN 20
auto eno2
iface eno2 inet static
address 10.20.20.11/24
# VM traffic — 2x10GbE LACP
auto bond0
iface bond0 inet manual
bond-slaves eno5 eno6
bond-mode 802.3ad
bond-miimon 100
bond-xmit-hash-policy layer3+4
auto vmbr1
iface vmbr1 inet manual
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
На первой ноде создаём кластер, остальные присоединяем командой pvecm add. Важно: для Corosync (это сервис, который определяет, жива ли нода) выделите отдельный физический интерфейс. Если Corosync будет ходить через тот же интерфейс, что и трафик ВМ, при пиковой нагрузке кластер начнёт «терять» ноды и устраивать ненужные failover.
# На первой ноде
pvecm create promtorg-cluster --link0 10.20.20.11
# На второй и третьей
pvecm add 10.20.20.11 --link0 10.20.20.12
pvecm add 10.20.20.11 --link0 10.20.20.13
# Проверяем
pvecm status
# Quorum information
# Date: Sat Nov 16 22:14:00 2025
# Quorum provider: corosync_votequorum
# Nodes: 3
# Quorate: Yes
# Total votes: 3
# Quorum: 2
ZFS-репликация вместо общего хранилища
Главное архитектурное решение — отказ от общего хранилища в пользу ZFS-репликации между нодами. Логика такая: каждая ВМ живёт на локальных NVMe одной ноды, но её снапшоты раз в 15 минут реплицируются на другую ноду. При падении основной ноды HA-механизм Proxmox запускает ВМ из последней реплики на резервной ноде — потеря данных максимум 15 минут, время простоя около 2-3 минут.
Настраиваем репликацию через GUI или CLI:
# Включаем репликацию ВМ 100 (1С-сервер) с ноды pve1 на pve2 каждые 15 минут
pvesr create-local-job 100-0 pve2 --schedule '*/15' --comment '1S server backup replication'
# Аналогично для критичных ВМ
pvesr create-local-job 101-0 pve3 --schedule '*/15' # Контроллер домена
pvesr create-local-job 102-0 pve2 --schedule '*/30' # Файловый сервер
# Проверяем статус репликаций
pvesr status
# JobID Enabled Target LastSync NextSync Duration FailCount
# 100-0 Yes local/pve2 22:00 22:15 45.3s 0
# 101-0 Yes local/pve3 22:00 22:15 12.1s 0
# 102-0 Yes local/pve2 22:00 22:30 128.7s 0
За год эксплуатации был один реальный отказ — у одной из нод сгорел блок питания (резервный по умолчанию был установлен, но кабель оказался не подключен — это отдельная история про подрядчика, который монтировал стойку). HA отработал штатно: через 90 секунд после падения ноды все ВМ автоматически запустились на двух оставшихся, потерялось 11 минут данных по 1С (последняя репликация прошла за 11 минут до сбоя). Восстановление вручную заняло у бухгалтерии около часа — переввод нескольких документов.
Миграция 18 виртуальных машин с VMware
Самая нервная часть проекта — собственно миграция. Готовились две недели, делали в выходные. Алгоритм для каждой ВМ:
- На VMware устанавливаем VirtIO-драйверы внутри Windows (для Linux не нужно — драйверы уже в ядре).
- Останавливаем ВМ на VMware, экспортируем через
ovftoolв OVA-файл на NFS-шару. - Конвертируем VMDK в qcow2:
qemu-img convert -f vmdk -O qcow2 disk.vmdk disk.qcow2. - Создаём ВМ на Proxmox с теми же параметрами CPU/RAM/сети.
- Импортируем диск:
qm importdisk 100 disk.qcow2 local-zfs. - Запускаем, проверяем сеть и работу приложения.
Для массовой миграции я написал bash-скрипт, который проходит по списку ВМ и делает всё автоматически. Если интересны детали — пишите в телеграм, поделюсь.
На Windows-ВМ есть нюанс с сетевым адаптером: после смены гипервизора Windows видит новую сетевую карту (VirtIO Ethernet вместо VMware VMXNET3) и сбрасывает IP-настройки. Заранее запишите, какой IP, маску и DNS прописать после первой загрузки. Для контроллера домена это критично — без правильного IP DC не поднимется.
Главная ошибка, которую я совершил на одном из ранних проектов: забыл установить VirtIO-драйверы в Windows ДО миграции. После переноса виртуалка не могла найти диск с операционной системой и упала в BSOD. Восстановление через Live-CD заняло 4 часа. С тех пор это пункт номер один в чек-листе.
Бэкапы через Proxmox Backup Server
Proxmox Backup Server (PBS) — отдельный продукт от тех же разработчиков, бесплатный, ставится на отдельную железку или ВМ. Он делает то же, что Veeam: инкрементальные бэкапы с дедупликацией и шифрованием. Реальная экономия места — 3-4 раза по сравнению с обычными tar-архивами.
У ПромТорга PBS стоит на маленьком сервере SuperMicro с 8 дисками по 8 ТБ в RAIDZ2 — получается 48 ТБ полезного места. Бэкапы 18 ВМ занимают около 6 ТБ после дедупликации, хранятся 90 дней. Параллельно копия отправляется ночью через WireGuard в наш дата-центр в Москве — это второй уровень защиты от ransomware и пожара.
# Подключаем PBS к Proxmox-кластеру
pvesm add pbs promtorg-pbs \
--server 10.10.10.50 \
--datastore main \
--username backup@pbs \
--password ******** \
--fingerprint ab:cd:ef:12:34:56:78:90:...
# Расписание ежедневных бэкапов в 02:00
# /etc/pve/jobs.cfg
vzdump: daily-backup
enabled 1
schedule 02:00
storage promtorg-pbs
mailnotification always
mailto admin@promtorg.ru
mode snapshot
compress zstd
pool production
prune-backups keep-daily=14,keep-weekly=4,keep-monthly=6
# Раз в неделю проверяем восстановление случайной ВМ
# (тестирование бэкапов — единственный способ убедиться, что они работают)
Тестирование восстановления раз в квартал — обязательная процедура. Я был на трёх проектах, где у клиента «бэкапы есть» оказывались битыми — никто не проверял. PBS позволяет смонтировать бэкап как отдельный диск без полного восстановления, так что проверка занимает 5 минут.
Производительность: сравнение до/после
После переезда замерили реальные показатели на одинаковых нагрузках. Тестировали 1С-сервер — это самая показательная для офиса нагрузка.
| Тест | VMware vSphere 7 | Proxmox VE 8.2 |
|---|---|---|
| Запуск 1С-предприятия (холодный старт) | 34 сек | 27 сек |
| Открытие большой формы документа | 1.8 сек | 1.5 сек |
| Тестовый отчёт «Анализ продаж за год» | 42 сек | 38 сек |
| Перенос ВМ между нодами (live migration) | не замеряли | 18 сек (8GB ОЗУ, 10GbE) |
| Failover при отказе ноды | ~60 сек (vSphere HA) | ~90 сек (Corosync HA) |
Ускорение на 10-15 % объясняется просто: KVM работает прямо в ядре Linux без overhead промежуточного гипервизора, а ZFS на локальных NVMe быстрее, чем iSCSI к старой СХД. Failover чуть медленнее VMware, но для офиса разница в 30 секунд несущественна — нужно успеть позвать админа, тот всё равно открывает консоль минуту.
Экономика проекта: окупаемость за полгода
Самое интересное — деньги. Вот честный расчёт по проекту ПромТорга.
| Статья | VMware (год) | Proxmox (год) |
|---|---|---|
| Лицензии гипервизора | 580 000 ₽ | 95 000 ₽ (Standard на 3 ноды) |
| Бэкап (Veeam → PBS) | 95 000 ₽ | 0 ₽ (PBS бесплатный) |
| Техподдержка вендора | входит в лицензию | входит в подписку |
| Итого ПО в год | 675 000 ₽ | 95 000 ₽ |
| Разовые работы по миграции | — | 280 000 ₽ |
| Третий сервер (купили из стока) | — | 320 000 ₽ |
Экономия только на лицензиях — 580 тыс. руб./год. Разовые затраты на проект — 600 тыс. руб. Окупаемость — чуть больше года, если считать вместе с третьим сервером, или 6 месяцев — если считать только разовые работы (третий сервер всё равно нужен был для отказоустойчивости).
Чего я бы не делал, если бы начинал заново
Полтора года эксплуатации — самое время для разбора граблей. Вот три вещи, которые я бы поменял в архитектуре:
- Не экономил бы на третьем сервере с самого начала. Был соблазн собрать кластер из двух нод с QDevice, но это плохое решение для production. Третья нода — это страховка, которая стоит 3-4 % от общего бюджета и спасает от 80 % сценариев отказа.
- Сразу настроил бы реплицирование на удалённую площадку. Первые три месяца бэкапы лежали только на локальном PBS. Если бы серверная сгорела — потеряли бы всё. Сейчас копия уезжает в дата-центр в Москве каждую ночь.
- Заранее обучил бы админа клиента. У меня ушло три недели на то, чтобы Андрей (штатный сисадмин ПромТорга) перестал звонить мне по каждой мелочи. Если бы я провёл с ним два дня обучения до миграции, эти три недели мы бы сэкономили.
Когда Proxmox НЕ подходит и стоит остаться на VMware
Не хочу делать вид, что Proxmox решает все проблемы. Есть сценарии, когда переход не оправдан:
- У вас VDI на тысячу пользователей с VMware Horizon. В Proxmox нет аналога Horizon, и пилить связку Proxmox + Apache Guacamole для большого VDI — это эпопея.
- Критична функция Fault Tolerance. VMware FT держит зеркальную копию ВМ на второй ноде в реальном времени, при отказе — ноль секунд простоя. У Proxmox этого нет, минимум 30-90 секунд на failover.
- Используете NSX или vSAN на полную катушку. Если у вас сложные программно-определяемые сети с микросегментацией NSX, миграция превращается в полную пересборку архитектуры.
- Есть жёсткие требования регулятора по сертифицированному гипервизору. Некоторые ФСТЭК-сертифицированные продукты требуют конкретно VMware. Хотя сейчас появились российские ФСТЭК-сертификаты на Proxmox-форки.
Для типичного офиса 20-100 рабочих мест с десятком-двумя виртуалок Proxmox — оптимальный выбор. Для крупного предприятия с сотнями ВМ и сложной сетевой архитектурой — нужен индивидуальный анализ.
Оцените миграцию вашей инфраструктуры на Proxmox
Если ваш бюджет на VMware вырос в 2-4 раза после прихода Broadcom и вы рассматриваете переход на open-source виртуализацию — я могу приехать и за 2-3 рабочих дня посчитать конкретный проект под вашу инфраструктуру. Аудит бесплатный, никаких обязательств. По итогам получите письменный план миграции с точной стоимостью и сроками.
Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш
FAQ — частые вопросы по переходу с VMware на Proxmox
- Сколько стоит миграция с VMware на Proxmox для офиса 40 человек?
- В нашем кейсе разовые работы (планирование, перенос 18 ВМ, обучение админа клиента) обошлись в 280 тыс. руб. Экономия на лицензиях окупила проект за 6 месяцев — VMware vSphere Essentials Plus после ухода Broadcom стоил клиенту около 580 тыс. руб./год, Proxmox с подпиской Standard на 3 ноды — 95 тыс. руб./год.
- Можно ли использовать Proxmox без подписки в production?
- Технически да — функционал тот же. Но для бизнеса я всегда рекомендую брать подписку Standard (~30 тыс. руб./сокет/год). Это даёт enterprise-репозиторий с протестированными обновлениями. Free-репозиторий иногда выкатывает пакеты, ломающие кластер.
- Достаточно ли 3 нод для HA-кластера Proxmox?
- Да, 3 ноды — это минимум и одновременно оптимум для офиса. Кворум Corosync требует чётного большинства. При падении одной ноды две оставшиеся продолжают работать, ВМ автоматически перезапускаются. Для офиса до 60 рабочих мест 3 нод хватает с запасом.
- Сколько занимает миграция одной ВМ с VMware на Proxmox?
- Чистое время конвертации диска 200 ГБ — около 40 минут на 10GbE. С учётом подготовки (установка VirtIO-драйверов, настройка сети, тестирование) на одну ВМ закладывайте 1.5–2 часа. У нас 18 ВМ перенесли за два выходных дня командой из двух инженеров.
- Что делать с лицензиями Windows Server после миграции?
- Лицензии Windows Server привязаны к виртуальным машинам, а не к гипервизору. После миграции на Proxmox они остаются валидными. Внутри Windows нужно установить VirtIO-драйверы (бесплатные) и через 30 секунд сервер активируется как обычно.