8 серверов в одном: кейс виртуализации Proxmox VE для производственной компании

Перед закупкой наши инженеры провели аудит того, что есть, и посчитали, что реально нужно новым серверам. Ниже — минимальные и рекомендуемые параметры для продуктивной работы Proxmox. Не теоретические, а те, с которыми мы работаем на практике:

На новых серверах первым делом проверили поддержку аппаратной виртуализации:

grep -E '(vmx|svm)' /proc/cpuinfo | head -1

Если вывод команды не пустой — процессор поддерживает KVM. У нас всё прошло без сюрпризов, но на старом железе такое лучше проверять заранее.

Клиент хотел понять, почему именно Proxmox, а не что-то другое. Мы подготовили детальное сравнение — особенно актуальное после того, как Broadcom купил VMware и лицензионная политика там резко изменилась:

• Стоимость: Proxmox — бесплатно (подписка на поддержку опциональна от €110/год), VMware vSphere — от $4,000/год за хост, Hyper-V — тянет за собой лицензию Windows Server
• Live Migration: Proxmox умеет переносить работающие ВМ между нодами кластера без остановки — пользователи ничего не замечают
• Backup: Proxmox Backup Server — бесплатный выделенный инструмент с дедупликацией, не нужно ничего докупать
• High Availability: встроенный HA прямо в платформе, без дополнительных лицензий и плясок с бубном

Для клиента арифметика сложилась сама собой: экономия на лицензиях — больше 500 000 рублей в год. При этом Proxmox закрывал все требования без компромиссов.

Как готовили носители и что делали дальше — по шагам:

# На Linux/macOS:
dd bs=1M conv=fdatasync if=proxmox-ve_8.2-1.iso of=/dev/sdX status=progress

# Или через Ventoy/Rufus на Windows

На каждом сервере установка шла одинаково:

1. Принять лицензионное соглашение (AGPL v3) — читать необязательно, но оно там есть
2. Выбрать целевой диск — установщик предложит файловую систему: ext4, xfs, ZFS (RAID0/1/10/RAIDZ), Btrfs
3. Указать страну, часовой пояс и раскладку клавиатуры
4. Задать пароль root и email администратора — на этот адрес будут приходить системные уведомления
5. Настроить сетевой интерфейс: hostname, IP-адрес, шлюз, DNS — всё это потом можно поменять, но лучше сразу указать правильно

Важно: на обоих серверах мы выбрали ZFS mirror (RAID1) для системного раздела. Это решение приняли сразу — отказоустойчивость с первого включения, без доработок.

После перезагрузки открыли веб-интерфейс по адресу https://IP-АДРЕС:8006 и сразу взялись за базовую настройку. Ниже — конфигурация, которую мы применили на этом проекте:

# Отключаем enterprise-репозиторий (если нет подписки)
sed -i 's/^deb/# deb/' /etc/apt/sources.list.d/pve-enterprise.list

# Добавляем бесплатный репозиторий
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list

# Обновляем
apt update && apt full-upgrade -y
reboot

Ещё убрали надоедливое предупреждение о подписке — оно выскакивает при каждом входе и раздражает всех без исключения:

sed -Ei.bak "s/NotFound/Active/g; s/No valid subscription/ITfresh License/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
systemctl restart pveproxy

Расхождение времени на нодах кластера — это гарантированные проблемы с бэкапами и репликацией. Проверено болезненным опытом. Вот что настроили:

# Устанавливаем chrony
apt install chrony -y

# Настраиваем NTP-серверы
cat > /etc/chrony/chrony.conf << 'EOF'
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
EOF

systemctl restart chrony
chronyc tracking

Следом закрыли периметр — настроили файрвол для защиты серверов от лишнего трафика:

# Включаем встроенный Proxmox Firewall через GUI:
# Datacenter -> Firewall -> Options -> Firewall: Yes

# Или через CLI:
pvesh set /cluster/firewall/options -enable 1

# Разрешаем SSH и веб-интерфейс
pvesh create /cluster/firewall/rules -action ACCEPT -type in -dport 22 -proto tcp -comment "SSH"
pvesh create /cluster/firewall/rules -action ACCEPT -type in -dport 8006 -proto tcp -comment "Proxmox Web UI"

Подняли VLAN-aware bridge — он изолирует сервисы друг от друга на уровне сети. Вот конфигурация /etc/network/interfaces, которую мы в итоге применили:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

# VLAN-aware bridge для изоляции трафика
auto vmbr1
iface vmbr1 inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 100 200 300

VLAN-aware bridge удобен тем, что VLAN-тег назначается каждой ВМ прямо через веб-интерфейс — никаких отдельных интерфейсов создавать не нужно. Мы разбили сеть так: VLAN 100 — бухгалтерия и 1С, VLAN 200 — общая сеть, VLAN 300 — видеонаблюдение. Три изолированных сегмента, и ни один не видит другой.

Чтобы не зависеть от одного сетевого интерфейса, объединили два физических порта на каждом сервере в bonding:

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

Режимов bonding несколько, и у каждого свои плюсы. Вот что мы разобрали с клиентом перед выбором:

• balance-rr (mode 0) — Round-robin, не требует настройки коммутатора
• active-backup (mode 1) — только отказоустойчивость, один интерфейс активен
• 802.3ad (mode 4) — LACP, требует поддержку коммутатора, максимальная производительность

Остановились на 802.3ad — настроили LACP на коммутаторе клиента и получили и отказоустойчивость, и максимальную полосу. После всех изменений применили конфигурацию командой: ifreload -a

Отдельно подняли модуль SDN — чтобы жёстко разделить production-среду и тестовый стенд разработчиков:

# Через веб-интерфейс: Datacenter -> SDN -> Zones
# Создаём зону типа VXLAN:
pvesh create /cluster/sdn/zones -zone myzone -type vxlan -peers 10.0.0.10,10.0.0.11 -bridge vmbr0

# Создаём виртуальную сеть (VNet):
pvesh create /cluster/sdn/vnets -vnet myvnet -zone myzone

# Добавляем подсеть:
pvesh create /cluster/sdn/vnets/myvnet/subnets -subnet 192.168.100.0/24 -gateway 192.168.100.1

# Применяем конфигурацию
pvesh set /cluster/sdn

Благодаря SDN разработчики клиента начали тестировать обновления 1С на полной копии базы — и эта копия физически не видит production. Никаких случайных «я просто хотел проверить» с поломкой рабочей системы.

Основное хранилище построили на ZFS. Выбор очевидный: встроенные снапшоты, контрольные суммы данных, гибкий RAID — всё из коробки. Конфигурация, которую мы применили:

# Создаём ZFS mirror (аналог RAID1) из двух дисков
zpool create -f -o ashift=12 tank mirror /dev/sdb /dev/sdc

# Создаём RAIDZ1 (аналог RAID5) из трёх дисков
zpool create -f -o ashift=12 datapool raidz /dev/sdb /dev/sdc /dev/sdd

# Оптимизация для виртуализации
zfs set compression=lz4 tank
zfs set atime=off tank
zfs set recordsize=64K tank
zfs set xattr=sa tank
zfs set primarycache=all tank

# Добавляем ZFS-пул как хранилище в Proxmox
pvesm add zfspool local-zfs -pool tank -content images,rootdir -sparse 1

ARC-кэш: ZFS активно ест оперативную память — это нужно учитывать, иначе виртуальным машинам просто не хватит RAM. Мы выставили жёсткий лимит:

# Ограничиваем ARC до 8 ГБ (чтобы оставить RAM для ВМ)
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u

Для тестового стенда разработчиков взяли LVM-Thin provisioning. Фишка в том, что ВМ можно выделить дискового пространства больше, чем физически есть — место списывается по факту записи:

# Создаём физический том и группу
pvcreate /dev/sdb
vgcreate vg_data /dev/sdb

# Создаём thin pool (95% от группы)
lvcreate -l 95%VG --type thin-pool -n tp_data vg_data

# Добавляем в Proxmox
pvesm add lvmthin local-lvm-data -vgname vg_data -thinpool tp_data -content images,rootdir

Для тестовой среды LVM-Thin — почти идеальный вариант: снапшоты создаются мгновенно, overprovisioning экономит место, а расширить пул можно без остановки машин.

Клиенту также подготовили план масштабирования — кластер из 3+ нод с Ceph для распределённого хранилища. Задокументировали инструкции заранее, чтобы второй этап прошёл без сюрпризов:

# Устанавливаем Ceph на каждой ноде через GUI:
# Datacenter -> Node -> Ceph -> Install

# Или через CLI:
pveceph install --repository no-subscription
pveceph init --network 10.0.0.0/24

# Создаём мониторы (минимум 3)
pveceph mon create

# Добавляем OSD (по одному на каждый диск)
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# Создаём пул для ВМ
pveceph pool create vm-pool --pg_num 128 --size 3 --min_size 2

# Добавляем как хранилище
pvesm add rbd ceph-pool -pool vm-pool -content images,rootdir -monhost 10.0.0.10,10.0.0.11,10.0.0.12

Ceph даст репликацию данных между нодами: если один сервер выходит из строя — остальные продолжают работать. Это второй этап проекта, но архитектуру под него мы заложили уже сейчас.

1С, Active Directory и видеонаблюдение получили полноценные KVM-машины. Здесь нужна полная изоляция и поддержка Windows — контейнеры не подойдут:

# Создаём ВМ через CLI
qm create 100 \
  --name web-server \
  --memory 4096 \
  --cores 4 \
  --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:32,iothread=1,discard=on \
  --ide2 local:iso/debian-12-netinst.iso,media=cdrom \
  --net0 virtio,bridge=vmbr0,firewall=1 \
  --boot order=scsi0\;ide2 \
  --ostype l26 \
  --agent enabled=1 \
  --start 0

# Запускаем ВМ
qm start 100

Вот ключевые параметры, которые мы выставили для максимальной производительности этих машин:

• --cpu host — проброс инструкций CPU напрямую в ВМ
• --scsihw virtio-scsi-single — самый производительный дисковый контроллер
• iothread=1 — выделенный поток для I/O операций
• discard=on — поддержка TRIM для SSD
• --agent enabled=1 — интеграция через QEMU Guest Agent

Почта, файловый сервер и веб-сайт уехали в LXC-контейнеры. Потребление ресурсов у них в разы ниже, чем у полных ВМ — и это ощутимо на практике:

# Скачиваем шаблон
pveam update
pveam download local debian-12-standard_12.2-1_amd64.tar.zst

# Создаём контейнер
pct create 200 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst \
  --hostname docker-host \
  --memory 2048 \
  --swap 512 \
  --cores 2 \
  --rootfs local-zfs:8 \
  --net0 name=eth0,bridge=vmbr0,ip=10.0.0.20/24,gw=10.0.0.1 \
  --nameserver 8.8.8.8 \
  --password \
  --unprivileged 1 \
  --features nesting=1

pct start 200

Флаг nesting=1 включили для контейнера с Docker — туда мы упаковали несколько микросервисов клиента. Без него Docker внутри LXC просто не запустится.

Чтобы в будущем не тратить по полдня на развёртывание новых машин, сделали Cloud-Init шаблоны. Новая ВМ из шаблона поднимается за 3-5 минут:

# Скачиваем cloud-образ Ubuntu
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

# Создаём шаблон
qm create 9000 --name ubuntu-cloud-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 9000 noble-server-cloudimg-amd64.img local-zfs
qm set 9000 --scsihw virtio-scsi-single --scsi0 local-zfs:vm-9000-disk-0,discard=on
qm set 9000 --ide2 local-zfs:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
qm set 9000 --agent enabled=1

# Настраиваем Cloud-Init
qm set 9000 --ciuser admin --cipassword $(openssl passwd -6 'SecurePass123')
qm set 9000 --sshkeys ~/.ssh/authorized_keys
qm set 9000 --ipconfig0 ip=dhcp

# Конвертируем в шаблон
qm template 9000

# Клонируем ВМ из шаблона
qm clone 9000 101 --name web-01 --full
qm set 101 --ipconfig0 ip=10.0.0.21/24,gw=10.0.0.1
qm start 101

Теперь IT-специалист клиента разворачивает десяток одинаковых серверов за минуты. Раньше для этого нужно было сначала купить железо, потом ждать поставки, потом настраивать вручную.

Для резервного копирования в Proxmox есть встроенный инструмент vzdump. Вот как мы его настроили у этого клиента:

# Бэкап одной ВМ (snapshot mode — без остановки)
vzdump 100 --mode snapshot --compress zstd --storage local --notes-template '{{guestname}} backup'

# Бэкап всех ВМ ноды
vzdump --all --mode snapshot --compress zstd --storage local --mailnotification always --mailto admin@itfresh.ru

# Восстановление
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_03_31-03_00_00.vma.zst 100 --storage local-zfs

Режимов бэкапа три, и IT-специалисту клиента мы объяснили разницу между ними сразу:

• snapshot — без простоя, используется QEMU snapshot (мы выбрали этот режим)
• suspend — ВМ на секунды «замирает» ради консистентного снимка
• stop — полная остановка ВМ на время бэкапа

Отдельно мы развернули PBS-сервер — под инкрементальные бэкапы с дедупликацией. Конфигурация, которую применили:

# На PBS-сервере: создаём datastore
proxmox-backup-manager datastore create store1 --path /mnt/backup

# На Proxmox VE: добавляем PBS как хранилище
pvesm add pbs pbs-main \
  --server 10.0.0.50 \
  --datastore store1 \
  --username backup@pbs \
  --password \
  --fingerprint AA:BB:CC:...

# Настраиваем расписание бэкапов:
# Datacenter -> Backup -> Add
# Или через конфиг:
cat >> /etc/pve/jobs.cfg << 'EOF'
job: backup-daily
    schedule 0 2 * * *
    storage pbs-main
    mode snapshot
    compress zstd
    all 1
    retention-keep-daily 7
    retention-keep-weekly 4
    retention-keep-monthly 6
EOF

PBS реально экономит место — до 90% за счёт дедупликации. На практике это выглядело так: на относительно скромном диске у клиента спокойно уместились бэкапы за полгода. Без дедупликации о таком можно было забыть.

Для ZFS-хранилищ дополнительно подняли репликацию ВМ на вторую ноду кластера:

# Создаём задание репликации (каждые 15 минут)
pvesr create-local-job 100-0 node2 --schedule '*/15' --rate 50

# Просмотр состояния репликации
pvesr status
pvesr list

# При отказе основной ноды, ВМ можно мгновенно запустить на node2

Репликация работает через ZFS send/receive — гоняет по сети только изменившиеся блоки, а не весь образ целиком. Если один сервер падает вчистую, критичные ВМ поднимаются на втором за считанные минуты. Проверяли — работает именно так.

Два узла без QDevice — это потенциальная проблема кворума. Поэтому QDevice настроили отдельно. Команды создания кластера:

# На первой ноде — создаём кластер
pvecm create my-cluster --link0 10.0.0.10

# На второй и третьей нодах — присоединяемся
pvecm add 10.0.0.10 --link0 10.0.0.11
pvecm add 10.0.0.10 --link0 10.0.0.12

# Проверяем статус
pvecm status
pvecm nodes

Важно: все ноды должны работать на одинаковой версии Proxmox и иметь синхронизированное время через NTP. Казалось бы, очевидно — но мы видели кластеры, где про NTP забыли, и потом долго разбирались с расползающимися логами. Для кластерного трафика подняли отдельный интерфейс.

HA сам перезапускает ВМ на живой ноде, когда одна из них падает. В HA мы занесли всё, что у клиента считается бизнес-критичным: 1С, файловый сервер и Active Directory:

# Добавляем ВМ в группу HA
ha-manager add vm:100 --group ha-group --state started --max_restart 3 --max_relocate 2

# Создаём HA-группу с приоритетами нод
ha-manager groupadd ha-group --nodes node1:2,node2:1,node3:1 --nofailback 0

# Проверяем статус HA
ha-manager status

# Тестируем отказ (на тестовой ноде)
systemctl stop pve-ha-lrm  # Имитация отказа

Слова словами, но мы провели честное тестирование — просто вырубили питание первого сервера и засекли время. Критичные ВМ поднялись на втором меньше чем за 3 минуты. Клиент смотрел на это вживую.

Серверы с двумя сокетами — это NUMA, и если ВМ привязана неправильно, половину производительности можно потерять просто так. Настроили привязку к NUMA-нодам:

# Включаем NUMA для ВМ
qm set 100 --numa 1

# Привязываем ВМ к конкретному сокету (NUMA node 0)
qm set 100 --cpulimit 4 --cpuunits 2048

# Тип CPU для максимальной производительности
qm set 100 --cpu host

# Для совместимости при миграции
qm set 100 --cpu x86-64-v3

Дополнительно подкрутили ядро под виртуализацию. Это не магия — конкретные параметры, которые дали прирост производительности 1С около 25%:

# Включаем hugepages (2MB страницы)
echo "vm.nr_hugepages = 4096" >> /etc/sysctl.conf  # 8 ГБ hugepages
sysctl -p

# I/O scheduler для SSD
echo "none" > /sys/block/sda/queue/scheduler

# Постоянная настройка через udev
cat > /etc/udev/rules.d/60-io-scheduler.rules << 'EOF'
ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
EOF

# Оптимизация сети
cat >> /etc/sysctl.conf << 'EOF'
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 30000
EOF
sysctl -p

Бухгалтеры заметили разницу без всяких бенчмарков: проведение документов в 1С стало ощутимо быстрее, чем на старом физическом железе. Приятно, когда оптимизация видна невооружённым глазом.

IT-специалист клиента должен видеть, что происходит с нагрузкой, — иначе как планировать масштабирование? Настроили мониторинг:

# Просмотр загрузки CPU и RAM
pvesh get /nodes/pve/status

# Топ ВМ по потреблению ресурсов
qm list | while read vmid name status mem pid; do
  [[ "$status" == "running" ]] && echo "$vmid $name $(qm monitor $vmid 'info balloon' 2>/dev/null)"
done

# Статистика ZFS
zpool iostat -v tank 5
arc_summary  # статистика ARC кэша

# Интеграция с Prometheus (node_exporter + pve-exporter)
apt install prometheus-pve-exporter -y