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

Наши инженеры провели аудит существующей инфраструктуры и определили требования к новым серверам. Вот минимальные и рекомендуемые параметры для продуктивного использования Proxmox:

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

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

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

Мы подготовили для клиента детальное сравнение платформ. В условиях изменения лицензионной политики VMware (после приобретения Broadcom) это было особенно актуально:

• Стоимость: 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 для видеонаблюдения.

Для повышения надёжности и пропускной способности мы объединили два физических интерфейса на каждом сервере:

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-машины. 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, в котором разместили несколько микросервисов клиента.

Для удобства дальнейшего масштабирования мы создали Cloud-Init шаблоны — это позволяет развернуть новую ВМ за минуты:

# Скачиваем 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. Вот команды создания кластера:

# На первой ноде — создаём кластер
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). Для выделенной кластерной сети мы использовали отдельный интерфейс.

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 для ВМ
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