· 16 мин чтения

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. Вот почему.

XCP-ng я тоже люблю, но у него меньше комьюнити, а Xen Orchestra (нормальный веб-UI) либо платный, либо требует самостоятельной сборки из исходников. Это плохо для клиента, у которого админ — один человек.

Архитектура: 3 ноды, локальные диски, ZFS-репликация

На старте у клиента было два сервера HP DL380 Gen10 с СХД HP MSA 2050 на iSCSI. Я предложил пересобрать инфраструктуру по другой логике: вместо дорогого общего хранилища взять три однотипные ноды с локальными NVMe-дисками и использовать ZFS-репликацию вместо общего стораджа. Получается дешевле, быстрее и без единой точки отказа в виде СХД.

КомпонентСтарая инфраструктураНовая инфраструктура
ГипервизорVMware vSphere Essentials PlusProxmox VE 8.2 + подписка Standard
Серверы2× HP DL380 Gen103× HP DL380 Gen10 (добавили ещё один из стока)
ХранилищеHP MSA 2050 (iSCSI, 24×1.2TB SAS)Локальные NVMe (4×1.92TB Samsung PM9A3 на ноду)
Файловая системаVMFS на iSCSI LUNZFS RAID-10 локально + zfs-send репликация
Сеть2×10GbE LACP к коммутатору2×10GbE LACP + 2×1GbE для Corosync
БэкапыVeeam Backup Essentials → NAS SynologyProxmox 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

Самая нервная часть проекта — собственно миграция. Готовились две недели, делали в выходные. Алгоритм для каждой ВМ:

  1. На VMware устанавливаем VirtIO-драйверы внутри Windows (для Linux не нужно — драйверы уже в ядре).
  2. Останавливаем ВМ на VMware, экспортируем через ovftool в OVA-файл на NFS-шару.
  3. Конвертируем VMDK в qcow2: qemu-img convert -f vmdk -O qcow2 disk.vmdk disk.qcow2.
  4. Создаём ВМ на Proxmox с теми же параметрами CPU/RAM/сети.
  5. Импортируем диск: qm importdisk 100 disk.qcow2 local-zfs.
  6. Запускаем, проверяем сеть и работу приложения.

Для массовой миграции я написал 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 7Proxmox 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 месяцев — если считать только разовые работы (третий сервер всё равно нужен был для отказоустойчивости).

Чего я бы не делал, если бы начинал заново

Полтора года эксплуатации — самое время для разбора граблей. Вот три вещи, которые я бы поменял в архитектуре:

Когда Proxmox НЕ подходит и стоит остаться на 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 секунд сервер активируется как обычно.