Два тарифа на одном хостинге: VPS за 300 рублей и VDS за 800 рублей. Характеристики на бумаге одинаковые — 2 vCPU, 4 GB RAM, SSD. В три часа ночи оба работают одинаково быстро. В час пик на VPS начинаются задержки, на VDS — нет. Дело не в маркетинговом названии, а в том, как гипервизор распределяет физические ресурсы между арендаторами.
Распространённое мнение — что VPS и VDS это одно и то же, просто разные слова для одного продукта. Верно примерно в половине случаев. В другой половине за разными названиями стоят принципиально разные архитектуры. И именно там причина, по которой два сервера с одинаковым прайсом ведут себя по-разному под реальной нагрузкой.
Что стоит за аббревиатурами на уровне архитектуры
VPS исторически означает Virtual Private Server и вырос из контейнерной виртуализации на уровне операционной системы. Типичные технологии — OpenVZ и LXC. Все контейнеры на физическом хосте используют одно общее ядро Linux. Изоляция обеспечивается программно: cgroups ограничивают ресурсы, namespaces разделяют процессы, сеть и файловую систему. Ядро одно, каждый контейнер видит свой срез пространства имён.
VDS расшифровывается как Virtual Dedicated Server и исторически связан с аппаратной виртуализацией — KVM, VMware ESXi, Hyper-V. Каждая виртуальная машина получает собственное ядро операционной системы и работает поверх эмулированного железа. Гипервизор выступает прослойкой между физическим железом и гостевыми системами: напрямую (Type-1, bare-metal) либо поверх хостовой ОС (Type-2).
Различие не косметическое. При контейнерной модели уязвимость ядра хоста потенциально затрагивает все контейнеры на физической машине одновременно. При KVM атака на гостевую ОС ограничена границами виртуальной машины и не выходит на гипервизор без эксплуатации отдельной escape-уязвимости.
Конкретный пример — CVE-2022-0847, Dirty Pipe. Уязвимость позволяла непривилегированному процессу перезаписывать данные в read-only файлах через механизм pipe в ядре Linux. В среде OpenVZ, где ядро хоста общее для всех контейнеров, эксплуатация этой CVE давала вектор атаки из контейнера на хост. KVM-машины оставались изолированными: ядро гостевой системы можно было скомпрометировать, но на физический хост и соседей атака не распространялась.
Модель распределения ресурсов — где возникает разница в производительности
В контейнерной модели CPU-ресурсы часто выделяются в режиме burst. Контейнеру написано «2 vCPU», но физически — не резервирование, а верхний предел. Когда соседи молчат, контейнер может забрать больше; когда соседи активны, планировщик ядра делит процессорное время между всеми. Несколько контейнеров с тяжёлой нагрузкой начинают конкурировать за одну очередь планировщика, время ожидания для каждого растёт непредсказуемо. Зависимость нелинейна при высоком заполнении.
В KVM-модели vCPU привязывается к физическим ядрам через QEMU/KVM scheduler. При корректной настройке со стороны провайдера — CPU pinning через libvirt — гостевая система получает гарантированное процессорное время вне зависимости от нагрузки соседей.
Схожая история с памятью. В OpenVZ действует механизм memory overcommit: суммарный объём памяти, выделенной всем контейнерам, может превышать объём физической RAM на хосте. Провайдер рассчитывает, что одновременно все контейнеры максимум не используют. Когда расчёт не сходится, возникает конкуренция за страницы памяти. В KVM overcommit тоже технически возможен через KSM (Kernel Samepage Merging — дедупликация одинаковых страниц памяти между VM), но провайдер, продающий «выделенный» VDS, как правило, его отключает и предоставляет реально зарезервированный объём.
Проверить разницу несложно. Запустить fio на случайное чтение и запись, sysbench на CPU — сначала в тихое время, потом в час пик. На контейнерном VPS разброс между двумя измерениями в 2–4 раза типичен. На KVM VDS с нормально настроенным CPU pinning разброс укладывается в 10% и ниже.
Почему провайдеры смешивают термины
Здесь как раз тот случай, когда «это одно и то же» — иногда правда.
Часть хостингов перешла на KVM для всего парка, но сохранила историческое деление на «VPS» и «VDS» в прайсе. Младшие тарифы называются VPS, старшие — VDS, хотя гипервизор один и тот же. Тогда различие действительно маркетинговое, и переплачивать вдвое за «VDS» при идентичной технологии нет смысла.
Другие провайдеры держат два отдельных парка: OpenVZ-кластер для дешёвых VPS и KVM-кластер для VDS. Тогда название отражает реальную разницу в архитектуре.
Узнать правду несложно. Тип гипервизора можно запросить у провайдера напрямую до покупки. Если уже есть доступ к серверу, достаточно выполнить `systemd-detect-virt` — команда возвращает строку с типом виртуализации: `kvm`, `openvz`, `lxc` или `none`. Утилита `virt-what` даёт более подробный вывод. Если провайдер не может ответить на вопрос о гипервизоре, само по себе информативно.
Когда разница критична, а когда нет
Контейнерный VPS на OpenVZ или LXC закрывает значительный класс задач без оговорок. Статические сайты, dev-окружения, небольшие API с предсказуемым трафиком до нескольких десятков RPS, задачи CI без жёстких SLA — везде, где деградация производительности в пиковые часы не является проблемой, контейнерная виртуализация работает хорошо и стоит дешевле.
KVM VDS необходим в других сценариях:
- Детерминированная производительность. Финансовые расчёты, очереди задач с прописанным SLA, базы данных под OLTP-нагрузку. Деградация в 3–4 раза в пиковые часы — нарушение контракта с пользователем или потеря транзакций.
- Кастомизация ядра. Загрузка собственного kernel, работа с eBPF для мониторинга или сетевой фильтрации, DPDK для высокопроизводительной обработки сетевых пакетов. В контейнерной среде с общим ядром хоста ничего из этого недоступно.
- Требования безопасности и регуляторика. Обработка персональных данных по 152-ФЗ с требованиями к изоляции среды, информационные системы под приказ ФСТЭК №21 или №17. Требования к средствам виртуализации класса защиты КВ де-факто предполагают аппаратную изоляцию. Контейнерная виртуализация с разделяемым ядром этим требованиям не соответствует: общее ядро означает, что граница между системами не является аппаратно подтверждённой.
На практике встречается ситуация, когда разработчики разворачивают production-систему с персданными на OpenVZ VPS, потому что тариф дешевле и «всё равно же виртуальная машина». При аудите по 152-ФЗ такая среда не пройдёт как изолированная — и переезд придётся делать уже под давлением регулятора.
Как выбрать не по названию, а по параметрам
Название тарифа — последнее, на что стоит смотреть. Список вопросов провайдеру перед покупкой:
- Тип гипервизора: KVM, OpenVZ, LXC, VMware, Hyper-V.
- Модель выделения CPU: burst-лимит или CPU pinning с гарантированным временем.
- Overcommit по RAM: есть или нет, если есть — коэффициент.
- Тип дискового контроллера: virtio-blk или virtio-scsi, тип хранилища на хосте (NVMe, SAS, RAID-уровень).
Если провайдер не отвечает на эти вопросы или отвечает уклончиво — достаточный ответ.
Большинство провайдеров предоставляют пробный период или возврат в течение суток. До принятия решения стоит прогнать UnixBench, fio на случайное чтение/запись с разными глубинами очереди, iperf3 для сети — особенно если сервер идёт под production. Запускать тесты лучше несколько раз в разное время суток, чтобы поймать поведение в пиковые часы.
На российском рынке KVM VDS с гарантированными ресурсами стоит в 2–3 раза дороже сопоставимого OpenVZ VPS. Переплата оправдана, если нагрузка непредсказуема или требования к изоляции жёсткие. Для dev-окружения или сайта с умеренным трафиком — нет.
Вопрос не в том, что лучше абстрактно. Нужна ли предсказуемость производительности или достаточно среднего по нагрузке результата — вот что определяет выбор. Архитектура гипервизора это и определяет. Название в прайсе не определяет ничего.
#информационнаябезопасность #кибербезопасность #облако #сети #разработка #комплаенс #аудит