KVM против OpenVZ и LXC: что на самом деле позволяет тип виртуализации вашего VPS

Два тарифа 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, зависит от того, кто управляет этим хостом.

ЧИТАТЬ

KVM против OpenVZ 2022: кто король виртуализации?

Что позволяет запускать каждый тип

Определяющие покупку оси — контроль над ядром, поддержка гостевой операционной системы, совместимость с Docker, поведение памяти, изменение размеров и политика ресурсов.

Что же выбрать? 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 есть в маркетплейсе если вы предпочитаете не устанавливать его вручную.

Часто задаваемые вопросы

systemd-detect-virt