Два тарифи VPS на одній сторінці. Чотири vCPU, 8 ГБ RAM, 160 ГБ сховища, майже однакова ціна. На одному вказано KVM. На іншому — OpenVZ. Жодна сторінка не пояснює, що змінює це слово.
Воно змінює те, що вам дозволено запускати. Типи віртуалізації VPS — не просто примітка про продуктивність. Вони визначають, чи контролюєте ви ядро, чи можливий Windows і чи працює Docker без участі провайдера. KVM, OpenVZ і LXC — це насамперед питання можливостей, а вже потім питання швидкості.
У цьому посібнику розглянуто три позначення, найважливіші для такого вибору під час купівлі. Xen, VMware, Hyper-V та інші платформи віртуалізації існують, але залишаються поза межами цього порівняння трьох варіантів.
TL;DR
- KVM дає кожному VPS власне гостьове ядро. Docker працює штатно, Windows технічно можливий, і зазвичай ви можете завантажувати модулі ядра або запускати власне ядро. Проте сам по собі KVM не гарантує виділених CPU чи RAM; зобов'язання щодо ресурсів усе одно залежать від провайдера й тарифу.
- OpenVZ тарифи VPS зазвичай є контейнерами Linux, що поділяють ядро хоста. Docker може працювати в OpenVZ 7 лише тоді, коли провайдер використовує сумісне ядро та конфігурацію шаблону. Замінити ядро хоста не можна, а пам'ять понад RAM обробляється через контрольований провайдером VSwap, а не через звичайний дисковий своп, керований гостем.
- LXC також використовує ядро хоста, але побудований на механізмах ізоляції основного ядра Linux. Docker може працювати, якщо хост увімкне потрібні функції, хоча Proxmox рекомендує вкладати контейнери у віртуальну машину QEMU для навантажень, що потребують максимальної ізоляції та живої міграції.
- Контейнери зазвичай простіше змінювати в розмірі на ходу. KVM теж може підтримувати гаряче підключення CPU та пам'яті, тож «KVM завжди вимагає перезавантаження» — ненадійне правило під час купівлі. Запитайте провайдера, що насправді підтримує його платформа.
- Для статичного сайту чи невеликого стека LAMP, якому ніколи не потрібні Docker, Windows або налаштування на рівні ядра, практична різниця може бути невеликою. Ізоляція, життєвий цикл і політика ресурсів усе одно можуть відрізнятися.
Єдина відмінність, з якої випливають усі інші
KVM дає кожному VPS на хості власне гостьове ядро. Контейнери OpenVZ і LXC використовують ядро, завантажене хостом.
KVM — це рішення повної віртуалізації для обладнання x86 з розширеннями віртуалізації. Він увійшов до основного ядра Linux починаючи з версії 2.6.20. Кожен гість бачить віртуальне обладнання й завантажує власну операційну систему та власне ядро.
Контейнерні типи працюють інакше. LXC — це інтерфейс користувацького простору для механізмів ізоляції ядра Linux, зокрема простори імен, cgroups, capabilities, seccomp і профілі безпеки. Його мета — середовище, близьке до звичайного встановлення Linux, без завантаження окремого ядра.
Контейнер OpenVZ дотримується тієї ж загальної моделі спільного ядра, хоча OpenVZ використовує власну платформу та власний стек ядра. OpenVZ 7 може керувати і контейнерами, і віртуальними машинами KVM, але якщо роздрібний тариф VPS позначено як «OpenVZ», продають зазвичай саме контейнерний тип.
Усі описані нижче відмінності в можливостях випливають саме з цього. Модуль ядра потрібно завантажити в ядро, яким керуєте ви. Інша операційна система потребує іншого ядра. Docker потребує просторів імен на рівні ядра, і вони мають бути доступні там, де перебуває саме ядро. З боку KVM ця межа проходить шаром гіпервізора, архітектуру якого зазвичай поділяють на гіпервізори типу 1 і типу 2.
LXC часто трапляється в середовищах Proxmox, зокрема на серверах під власним керуванням і на деяких хостингових платформах. Чи зможете ви ввімкнути розширені можливості LXC, залежить від того, хто керує цим хостом.
Що дозволяє запускати кожен тип
Осі, що визначають покупку, — це контроль над ядром, підтримка гостьової операційної системи, сумісність із Docker, поведінка пам'яті, зміна розмірів і політика ресурсів.
| Можливість | KVM | OpenVZ | LXC |
|---|---|---|---|
| Docker | Так, нативно | Умовно: лише OpenVZ 7, і провайдер має використати шаблон EZ або відповідний власний шаблон разом із потрібними функціями ядра хоста | Умовно: хост має ввімкнути вкладеність і keyctl |
| Власне ядро або завантажувані модулі | Зазвичай так | Ні, прив'язано до ядра хоста | Ні, використовує ядро хоста |
| Windows як гостьова ОС | Так, якщо провайдер підтримує образ і шлях ліцензування | Ні, лише Linux | Ні, лише Linux |
| Модулі ядра для VPN (WireGuard, OpenVPN) | Під керуванням гостя | Залежить від провайдера: TUN/TAP має бути відкритий | Залежить від провайдера: визначається функціями ядра, увімкненими на хості |
| Керування свопом | Під керуванням гостя | Керований хостом VSwap замість звичайного дискового свопу | Політика хоста, сучасний cgroup v2 |
| Зміна ресурсів на ходу, без перезавантаження | Залежить від платформи, гаряче підключення CPU й пам'яті можливе | Часто можливо | Часто можливо |
| Гарантія виділених ресурсів | Не закладена за замовчуванням, вирішує політика провайдера | Не закладена за замовчуванням, а щільність контейнерів полегшує оверселінг | Не закладена за замовчуванням |
Що ж обрати? KVM — найчистіша відповідь, коли потрібні Windows, власне ядро, завантажувані гостем модулі або передбачуваний хост для Docker. OpenVZ і LXC можуть бути ефективними середовищами Linux, але рішення на рівні ядра вони залишають провайдеру.
Це карта можливостей, а не бенчмарк. Вона нічого не каже про затримки сховища, якість мережі, покоління CPU, завантаженість хоста чи політику розподілу ресурсів у провайдера. Два провайдери з однаковим типом віртуалізації можуть видати дуже різні машини.
Саме на умовних клітинках покупці втрачають час. Якось я розгортав VPN на контейнерному VPS, де потрібна мережева функція на боці хоста не була відкрита. Інтерфейс не піднімався, і розв'язання вимагало звернення до підтримки, а не зміни конфігурації всередині гостя. Обираючи контейнерний тариф, запитуйте, чи відкриває провайдер саме той пристрій або ту функцію ядра, яка потрібна вашому VPN. Із KVM ви зазвичай керуєте цим зсередини гостя.
Чому саме Docker вирішує більшість покупок
Контейнерний VPS проти KVM VPS перестає бути абстрактним порівнянням тієї миті, коли у вимогах з'являється Docker. Сам Docker використовує простори імен ядра, cgroups, мережу та драйвери сховища. Усередині KVM ці можливості належать гостьовому ядру, яким керуєте ви. Усередині OpenVZ чи LXC вони зрештою залежать від хоста.
Docker в OpenVZ
Підтримка Docker в OpenVZ — це рішення щодо провіженінгу, яке ухвалюють над вами. стаття підтримки SolusVM стверджує, що Docker може працювати всередині OpenVZ 7 починаючи з певного випуску ядра 3.10, але там само сказано, що зі звичайними застарілими попередньо створеними шаблонами Docker не працює. Контейнер має використовувати шаблон EZ або відповідний власний шаблон. Ця ж стаття виключає гостей на CentOS 8.
То чи працює Docker на OpenVZ? Іноді. Провайдер мав побудувати послугу навколо сумісного ядра OpenVZ 7 і відповідного шляху шаблонів. Якщо на сторінці тарифу про це чітко не сказано, запитайте підтримку до купівлі та збережіть відповідь у письмовому вигляді.
Якщо конфігурація хоста несумісна, зміна прапорців Docker усередині VPS не усуне першопричину. Потрібно, щоб провайдер змінив конфігурацію контейнера або перевів вас на інший тип віртуалізації.
Docker в LXC
Docker може працювати всередині LXC, коли хост відкриває потрібні функції. У Proxmox до них зазвичай належать вкладеність контейнерів і keyctl для непривілейованих контейнерів.
Важливіший сигнал під час купівлі — рекомендація самого розробника платформи. У документації Proxmox сказано, що вкладення контейнерів у віртуальну машину QEMU в Proxmox залишається рекомендованою практикою для сценаріїв, що потребують максимальної ізоляції та живої міграції, замість запуску прямо в системному контейнері LXC.
Якщо хост LXC під вашим контролем, ви можете зважити цей компроміс і тестувати оновлення у зручному темпі. Якщо ви орендуєте LXC VPS, ядром, профілем безпеки та прапорцями розширених функцій керує провайдер. Уточніть підтримувану конфігурацію, замість того щоб вважати, ніби root усередині контейнера — це достатньо.
Docker в KVM
Docker зазвичай працює, бо гостьовий Linux керує власним оточенням ядра. Над гостем немає ні перемикача вкладеності LXC, ні вимоги до шаблону OpenVZ. Вам усе одно потрібні підтримуваний дистрибутив Linux, сумісне ядро та достатньо RAM і сховища під навантаження.
Володіти гостьовим ядром означає й обслуговувати його. На некерованому VPS оновлення, правила брандмауера, безпека Docker і резервні копії залишаються вашою турботою.
Ключовий висновок: Docker не робить OpenVZ чи LXC неможливими, але перетворює конфігурацію провайдера на частину надійності вашого застосунку. Для орендованого продакшн-хоста під Docker KVM усуває цю додаткову залежність.
Чи означають «4 vCPU» чотири виділені ядра процесора
VPS, який здається повільним, хоча його власний моніторинг показує процесор у простої, — найчастіший симптом, про який розповідають. Можливим це робить контейнерна віртуалізація. Боротьба за ресурси відбувається шаром нижче того, що бачить гість, тож його власні метрики не показують нічого поганого.
Механізм — сама по собі низька накладна вартість. Контейнер обходиться хосту значно дешевше, ніж повноцінна віртуальна машина, тож на те саме залізо вміщується більше контейнерів. Таку щільність дешево створити й важко помітити зсередини гостя, через що оверселінг структурно простіший на OpenVZ, ніж на KVM. KVM не заважає провайдеру набивати хост. Але він резервує реальну пам'ять і реальні частки CPU на кожного гостя, що ставить арифметичну стелю такому набиванню. Діагностична сторона має окремий посібник про те, як зрозуміти, чи займається ваш провайдер оверселінгом.
Пам'ять теж поводиться інакше. В OpenVZ дисковий своп не можна використати як додаткову пам'ять, тож цифра RAM на сторінці тарифу — це стіна, а не пологий схил. Гість KVM за нестачі пам'яті сповільнюється. У контейнері OpenVZ за нестачі пам'яті процеси вбивають.
Є й наслідок для ізоляції, і саме його недооцінюють. Пам'ять контейнера адресується з боку хоста так, як пам'ять гостя KVM — ні. Шифрування диска всередині гостя й далі захищає вас від украденого диска. Але воно не захищає ключі працюючого контейнера від машини, на якій він працює. Якщо у вашу модель загроз входить оператор хоста, спільне ядро — хибна основа. Жодне налаштування всередині гостя цього не змінює.
Ключовий висновок: та сама цифра на сторінці тарифу означає різну обіцянку залежно від типу. На KVM це виділення. На OpenVZ це стеля, яку ви ділите з іншими.
Де OpenVZ усе ще має сенс і куди він рухається
Якщо ви тримаєте статичний сайт або стек LAMP із невеликим трафіком, ви, можливо, ніколи не зіткнетеся з тими можливостями, які обмежує OpenVZ. Ні Windows, ні власного ядра, ні завантажуваного гостем модуля, ні продакшн-Docker. Для такого вузького завдання добре обслуговуваний контейнер OpenVZ усе ще впорається.
Життєвий цикл вимагає більше уваги, ніж десять років тому. OpenVZ 7 побудований на ядерній гілці RHEL 7, версії 3.10. Сам по собі номер версії не доводить, що підтримуваному корпоративному ядру бракує виправлень безпеки, адже вендори бекпортують патчі. Але він означає, що варто перевірити сумісність із ПЗ, розрахованим на новіші інтерфейси ядра.
The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the офіційній політиці життєвого циклу.
Сьогодні це не зламає працюючий сайт на OpenVZ. Але робить план міграції провайдера важливим ще до того, як ви довірите йому нове довготривале навантаження. Запитайте, яка версія OpenVZ чи Virtuozzo працює, як доставляються виправлення безпеки та який шлях міграції доступний.
Якщо на сторінці тарифу не названо тип віртуалізації, запитайте підтримку, а не виводьте його з ціни. Відповідь варто отримати в письмовому вигляді.
Вибір за типом навантаження
Відштовхуйтеся від вимоги, а не від технології.
Обирайте KVM, коли навантаженню потрібне власне ядро
KVM — прямий вибір, якщо вам потрібне будь-що з переліченого:
- Windows як гостьова операційна система
- Власне ядро
- Модулі ядра, що завантажує гість
- Продакшн-Docker без залежностей на кшталт «контейнер у контейнері»
- Вкладена віртуалізація, якщо провайдер її відкриває
- Своп і тонке налаштування ядра під керуванням гостя
Windows вирішує справу, бо й контейнери OpenVZ, і контейнери LXC використовують ядро хоста на Linux. Вибір між Linux і Windows для самого застосунку — окреме питання, пов'язане із сумісністю ПЗ, адмініструванням і ліцензуванням. Дивіться порівняння VPS на Linux і Windows для цього рішення.
Обирайте LXC, коли потрібен ефективний системний контейнер Linux
LXC розумний, коли навантаження лише під Linux, не потребує окремого ядра й виграє від низьких накладних витрат або швидких змін на боці хоста. Особливо корисний, коли хостом Proxmox чи LXC керуєте ви самі.
Для орендованого LXC VPS перевірте підтримку Docker, потрібні пристрої, режим безпеки, поведінку резервних копій і чи можна ввімкнути розширені функції.
Розгляньте OpenVZ для простого, перевіреного Linux-навантаження
OpenVZ усе ще може підійти для базового сайту, невеликого стека LAMP, DNS-сервісу чи так само типового Linux-навантаження, якщо:
- Провайдер документує версію платформи.
- Ваше ПЗ підтримує доступне оточення ядра.
- Вам не потрібні Windows чи налаштування ядра.
- Docker або не потрібен, або явно підтримується.
- У провайдера є зрозумілий план безпеки та міграції.
- Ціна або операційна модель дають вам реальний привід його обрати.
Не обирайте його лише тому, що старе порівняння стверджує, ніби OpenVZ завжди дешевший. Порівняйте поточний тариф, підтримку, політику ресурсів і варіанти міграції.
Якщо ваша відповідь випала на KVM, вирішує обмеження, а не вподобання. КМВ VPS від Cloudzy завантажується за 60 секунд на AMD EPYC із чистим NVMe, і кожен екземпляр отримує власне гостьове ядро. Модулі ядра завантажуються, власні ядра стартують, підтримуються гості й на Linux, і на Windows. Docker є в маркетплейсі якщо ви волієте не встановлювати його вручну.
Часті запитання
Чи можу я запустити Docker на VPS з OpenVZ?
Лише якщо провайдер налаштував сумісне середовище OpenVZ 7. SolusVM документує підтримку на достатньо свіжих ядрах OpenVZ 7 із шаблонами EZ або відповідними власними, тоді як стандартні застарілі шаблони не працюють. Вважайте Docker непідтримуваним, поки провайдер не підтвердить точну конфігурацію.
Чи може OpenVZ запустити Windows?
Ні, у вигляді контейнера OpenVZ — ні. Контейнер використовує Linux-ядро хоста. KVM може запустити гостя з Windows, бо віртуальна машина завантажує власне ядро операційної системи, хоча провайдер усе одно має підтримувати образ, ISO та шлях ліцензування.
LXC — це те саме, що Docker?
Ні. LXC зазвичай застосовують для системних контейнерів, які нагадують легкі Linux-машини із системою ініціалізації та кількома процесами. Docker — це платформа прикладних контейнерів, побудована навколо образів та окремих сервісів. Обидва використовують можливості ядра Linux, як-от простори імен і cgroups, тому терміни іноді плутають.
Що таке LXC VPS?
LXC VPS — це системний контейнер Linux, розміщений через LXC або платформу на базі LXC, наприклад Proxmox. Він виглядає й поводиться багато в чому як невеликий сервер Linux, але використовує ядро хоста замість власного. Це робить його легким і водночас обмежує контроль на рівні ядра.
Як дізнатися, який тип віртуалізації використовує провайдер?
Перегляньте сторінку тарифу або запитайте підтримку. Усередині екземпляра Linux ця команда часто визначає оточення:
systemd-detect-virtВона може повернути такі значення, як kvm, openvz, або lxc. Визначення зсередини гостя корисне, але перед купівлею кращим джерелом залишається письмова специфікація провайдера.
Чи гарантує KVM виділені CPU та RAM?
Ні. KVM підтримує овербукінг CPU й пам'яті. Провайдер може пропонувати зарезервовані ресурси, спільні або їх поєднання. Шукайте чіткі формулювання на кшталт виділена RAM, закріплений CPU, зарезервований vCPU чи без овербукінгу, замість того щоб вважати, ніби це гарантує гіпервізор.
Чи завжди KVM — кращий вибір?
Ні. KVM — єдиний варіант для Docker, власних ядер і Windows, але для навантаження, яке нічого з цього не торкається, практична різниця майже непомітна.
Обговорення
Коментарі
Увійдіть, щоб долучитися до обговорення.