Віртуалізація на виділеному сервері: KVM, Proxmox чи ESXi
На власному залізі обирають з трьох варіантів: чистий KVM з libvirt, Proxmox VE (той самий KVM плюс контейнери LXC і вебпанель) або VMware ESXi. Для більшості задач беруть Proxmox VE: він ставиться поверх Debian, веде і машини, і контейнери, та не вимагає купівлі ліцензії. ESXi має сенс там, де вже є інфраструктура VMware і персонал під неї.
- Апаратна віртуалізація має бути увімкнена в BIOS: на Intel це VT-x, прапорець
vmxу /proc/cpuinfo. - Оперативну пам'ять не переписують понад фізичну: сума RAM усіх машин плюс 2–4 GB гіпервізору має вміститися.
- Ядра переписують спокійно: за нерівномірного навантаження нормально 3–4 vCPU на фізичний потік.
- Кожній машині з власною публічною адресою потрібна окрема IPv4: $5/міс.
- Без KVM/IPMI помилка в конфігурації мосту відрізає доступ до сервера; опція коштує $5/міс.
Що потрібно від заліза
Гіпервізор упирається в пам'ять і диск раніше, ніж у процесор. Пам'ять гостю виділяється цілком і не стискається, тому 16 GB на тарифі Start — це реально 12–13 GB під машини після відрахування гіпервізора та кешу. Диски потрібні із запасом за IOPS: десяток машин пише випадково й одночасно, тож NVMe в RAID1 відрізняється від пари SATA SSD не відсотками, а разами.
ECC-пам'ять тут не розкіш: одна перевернута комірка в пам'яті хоста псує сторінку будь-якої з гостьових систем, і діагностувати це потім украй важко. Усі виділені сервери ZevsHost ідуть з DDR4 ECC, конфігурації перелічені на сторінці виділених серверів.
Третя вимога — віддалене керування: встановлення гіпервізора і відновлення після невдалого оновлення ядра робляться через консоль, а не по SSH. Як це працює — у статті про IPMI та KVM-over-IP.
Перевірка підтримки віртуалізації
Перше, що роблять на новій машині, — переконуються, що KVM доступний. Якщо прапорців немає, віртуалізацію вимкнено в BIOS, і підняти її по SSH не вийде.
# прапорець vmx (Intel) або svm (AMD) в описі процесора
grep -c -E 'vmx|svm' /proc/cpuinfo
# модуль ядра завантажено і пристрій створено
lsmod | grep kvm
ls -l /dev/kvm
# Debian/Ubuntu: повна перевірка готовності хоста
apt-get install -y libvirt-clients qemu-kvm
virt-host-validate qemu 2>&1 | grep -v PASS
# RHEL/AlmaLinux/Rocky
dnf install -y libvirt-client qemu-kvm
virt-host-validate qemu
Вивід virt-host-validate без рядків WARN і FAIL означає, що хост готовий.
Який гіпервізор обрати
| Варіант | Керування | Коли брати | Чого коштує |
|---|---|---|---|
| KVM + libvirt | virsh, virt-install, файли XML | 2–5 машин, усе автоматизується скриптами або Ansible | Немає панелі, знімки й резервні копії налаштовуєте самі |
| Proxmox VE | Вебпанель, API, CLI (qm, pct) | Змішане навантаження, машини й контейнери, копії та кластер | Потребує окремого розділу під сховище, власний стек мережі |
| VMware ESXi | Host Client, vCenter | Уже є інфраструктура і фахівці VMware | Жорсткі вимоги до драйверів, ліцензування |
| LXC-контейнери | pct у Proxmox або lxc | Однотипні Linux-оточення, щільність важливіша за ізоляцію | Спільне ядро з хостом, чуже ядро всередині не запустити |
Якщо машин більше трьох, панель окупається за перший тиждень. Що таке Proxmox і чим він відрізняється від голого KVM — у статті Proxmox: що це таке, покрокове встановлення розібрано у встановленні Proxmox, а вибір сховища — в матеріалі про сховище ZFS у Proxmox.
Мережа: міст і адреси
Схем дві. Міст виносить гостей у ту саму мережу, що й хост: кожній машині потрібна своя публічна IPv4. NAT залишає гостей у приватній підмережі та пробрасує порти з єдиної адреси хоста.
# Debian/Proxmox: міст поверх фізичного інтерфейсу
cat << 'EOF' > /etc/network/interfaces.d/vmbr0
auto vmbr0
iface vmbr0 inet static
address 203.0.113.10/24
gateway 203.0.113.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
EOF
# застосовуємо і одразу перевіряємо, що міст піднявся
ifreload -a
ip -br addr show vmbr0
bridge link show
Адреси й підмережі для гостей замовляються окремо, по $5/міс за IPv4; як їх маршрутизувати — у статті про додаткові IPv4 та підмережі.
Скільки машин вміщується в тариф
| Тариф | RAM | Диски | Реалістична щільність |
|---|---|---|---|
| Dedicated Start DE, $49 | 16 GB ECC | 2×500 GB SSD, RAID1 | 3–4 машини по 2–4 GB |
| Dedicated Pro DE, $99 | 32 GB ECC | 2×1 TB NVMe, RAID1 | 6–8 машин по 4 GB |
| Dedicated Enterprise US, $149 | 64 GB ECC | 4×1 TB NVMe, RAID10 | 12–16 машин по 4 GB |
Цифри дано із запасом на гіпервізор і кеш. Під знімки закладайте ще 20–30% диска: знімок росте на обсяг змінених блоків.
Перевищення фізичної пам'яті на гіпервізорі без swap закінчується тим, що OOM killer убиває не винну машину, а найбільшу — зазвичай саме продуктивну базу. Перевіряйте free -m на хості за запущених під навантаженням гостей: available має лишатися не меншим за 10% фізичної. Другий спосіб втратити сервер — переналаштувати міст по SSH: з'єднання рветься на команді застосування, і без KVM/IPMI машину не підняти. Змінюйте мережу лише з консолі IPMI.
Коротко
- Proxmox VE закриває більшість сценаріїв: KVM, LXC, панель, резервні копії; чистий libvirt виправданий за 2–5 машин.
- Перед встановленням перевірте прапорець vmx і вивід virt-host-validate: без апаратної підтримки гіпервізор не запуститься.
- Пам'ять не переписують понад фізичну, ядра переписують: 3–4 vCPU на потік за нерівномірного навантаження.
- Кожній машині з публічною адресою потрібна своя IPv4 за $5/міс, або NAT із пробросом портів.
- Мережу переналаштовують лише з IPMI-консолі: помилка в мосту відрізає SSH миттєво.