Proxmox VE как замена VMware для офиса: реальный кейс на 3 ноды

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор компании АйТи Фреш. Знаете, за последние полтора года ко мне обратились целых восемь компаний, и у всех была одна и та же проблема. После ухода Broadcom их любимый VMware стал стоить просто как чугунный мост! А бедный штатный админ хватается за голову и кричит: «Мы же без 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 я, в принципе, тоже люблю. Но у него комьюнити заметно поменьше, а чтобы получить нормальный веб-UI (Xen Orchestra), нужно либо платить, либо собирать его из исходников вручную. Для клиента, где админ — это один-единственный человек, такой расклад совсем не подходит.

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

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

Старую СХД 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С-сервер — это самая показательная нагрузка для офиса, она даёт чёткое представление о производительности.

Ускорение на 10-15 % объясняется довольно просто: KVM работает прямо в ядре Linux, без "лишнего" overhead промежуточного гипервизора. А ZFS на локальных NVMe, само собой, работает быстрее, чем iSCSI к старой СХД. Failover, конечно, чуть медленнее, чем у VMware, но для офиса разница в 30 секунд не имеет значения — пока админа дозовёшься, он всё равно минуту консоль открывает.

Экономика проекта: окупаемость за полгода

Самое интересное — деньги. Вот честный расчёт по проекту ПромТорга.

Только на лицензиях мы получили экономию в 580 тыс. руб./год! Разовые затраты на весь проект составили 600 тыс. руб. Если считать вместе с третьим сервером, окупаемость чуть больше года. А если брать только разовые работы, то всего полгода — третий сервер всё равно был нужен для обеспечения отказоустойчивости.

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

Мы уже полтора года эксплуатируем эту систему, и, пожалуй, пришло время разобрать "грабли". Вот три вещи, которые я бы сейчас изменил в архитектуре:

• Не экономил бы на третьем сервере с самого начала. Был соблазн собрать кластер из двух нод с 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 — это оптимальный выбор. А вот для крупного предприятия, с сотнями ВМ и очень сложной сетевой архитектурой, уже нужен глубокий, индивидуальный анализ.

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 секунд сервер активируется как обычно.