OpenVZ на CentOS 5: 15 контейнеров вместо 15 физических серверов

Прошло два месяца с нашей миграции на CentOS 5, и за это время мы успели попробовать на той же базе кое-что интересное - OpenVZ. Не вместо Xen и не вместо VMware, а рядом, под конкретную задачу.

Задача была простая и при этом болезненная: у команды разработки постоянно не хватало тестовых окружений. Создать новое - значит либо ждать выделения физической машины (когда она появится - бог знает), либо разворачивать виртуалку в Xen, что занимает около часа с учётом установки ОС, базовой настройки, раздачи доступов. Час - это не катастрофа, но когда разработчику нужно окружение прямо сейчас, чтобы воспроизвести баг, час - это много.

Почему OpenVZ, а не просто ещё один Xen

Xen мы не бросаем: для production-виртуалок и для клиентских задач он остаётся основным. Но у Xen есть специфика: каждый гость - это отдельное ядро, отдельный boot, полноценный изолированный процесс запуска. Это его сила для production и его цена для dev/test, где окружения создаются и выбрасываются по несколько раз в день.

OpenVZ работает иначе. Все контейнеры (VE - Virtual Environment, в терминологии OpenVZ) разделяют ядро хоста. Нет виртуализации железа, нет эмуляции - только изоляция на уровне ядра через namespace и cgroup-подобные механизмы. Это означает, что контейнер стартует за секунды и потребляет только то, что реально использует, - без накладных расходов на гостевое ядро, виртуальный BIOS и весь остальной хостинговый театр.

Платить за это приходится ограничением: все контейнеры должны быть Linux, и их ядро - это ядро хоста. Никакого Windows внутри, никаких экспериментов с альтернативными дистрибутивами с экзотическими патчами ядра. Для наших dev/test задач это не ограничение - там всё равно CentOS или Debian.

Как разворачивали

OpenVZ под CentOS 5 ставится через репозиторий openvz.org. Пакеты vzkernel и vzctl - ядро с OpenVZ-патчами и утилита управления контейнерами. После установки и перезагрузки в новое ядро всё готово к работе.

Шаблоны контейнеров - prebuilt-образы минимальных систем в формате tar.gz - скачиваются с того же сайта. CentOS 5 minimal и Debian Etch minimal у нас ушли в работу сразу. Создание контейнера:

vzctl create 101 --ostemplate centos-5-x86_64 --hostname dev101.int --ipadd 10.0.1.101
vzctl start 101
vzctl exec 101 passwd root

От команды vzctl create до работающего окружения с ssh-доступом - около двух минут. Это не преувеличение для красоты: мы засекали.

Пятнадцать контейнеров - это сколько на самом деле

На один физический сервер (4 ядра, 8 ГБ RAM, CentOS 5) мы развернули 15 контейнеров для dev/test. Каждому выдали по 512 МБ RAM в качестве мягкого лимита (параметр privvmpages в конфиге VE). По факту большинство из них в покое потребляют 50-80 МБ - это просто запущенные сервисы без нагрузки.

Накладные расходы самого OpenVZ как слоя - минимальны. Нет отдельного гостевого ядра, нет QEMU, нет виртуального железа. То, что в Xen или VMware уходит на гипервизорный overhead, здесь просто отсутствует. Один и тот же PHP-скрипт внутри контейнера работает практически с той же скоростью, что на хосте напрямую - мы проверяли.

Изоляция - достаточная для наших внутренних задач. Контейнеры не видят процессы друг друга, у каждого своя файловая система, свои сетевые интерфейсы, свои лимиты ресурсов. Это не полная изоляция в смысле VMware или Xen - shared kernel есть shared kernel, и если ядро хоста упадёт, умрут все 15 контейнеров сразу. Для тестовых окружений это приемлемо. Для клиентских production-VPS, где нужна изоляция неограниченного доверия, мы бы ещё подумали.

Что изменилось в работе

Время создания нового окружения - с часа до двух минут. Для разработчика это разница между «подожди, я сейчас всё подниму» и «уже готово, ссылка вот».

Снос и пересоздание - vzctl stop 101 && vzctl destroy 101 и через минуту новый контейнер с нуля. Это удобно, когда нужно воспроизвести баг в чистой среде или когда разработчик что-то сломал в процессе экспериментов.

Снапшоты - через vzdump, утилиту резервного копирования контейнеров. Сделать снапшот перед рискованным изменением, откатиться если что - стало рутиной, а не подвигом.

Количество обращений к нам с просьбой «поднять тестовую машину» сократилось: разработчики разобрались с vzctl и теперь справляются сами с рутинными задачами. Мы выдаём им права на управление своими контейнерами - и не становимся узким местом каждый раз, когда нужна свежая среда.

Про VMware и позиционирование

OpenVZ в хостинговой нише - популярная альтернатива VMware именно там, где важна плотность: много небольших VPS на одном железе с минимальными накладными расходами. Это другой класс инструмента, не конкурент, а сосед. VMware ESXi или Xen - для изоляции с полным стеком и Windows-гостями. OpenVZ - для Linux-контейнеров с максимальной плотностью и минимальным временем операций.

У нас сейчас оба сценария живут в managed-инфраструктуре: Xen для production-виртуалок, OpenVZ для dev/test-парка. Ни один из них не претендует на роль единственного правильного ответа.