OpenVZ vs LXC
Проект Virtuozzo Containers, как и его открытый клон OpenVZ, существует и развивается уже порядка 10 лет. Изначально ядро платформы развивалось самостоятельно в стороне от основной ветки ядра Linux. Но где-то на половине пути разработчики Parallels поняли, что такая стратегия очень сложна и затратна.nnПоэтому было принято решение портировать все фирменные наработки в основную ветку ядра, дабы дать им самостоятельное развитие. Но процесс вливания патчей довольно сложен и длителен.nnНа сегодняшний день лишь половина «ядерного» функционала Virtuozzo перекочевала в основную ветку ядра. Фактически на ней и основывается LXC. Конечно же, некоторые части проекта, такие как утилиты управления, шаблоны и ряд других, разрабатываются не программистами Parallels. Но в целом своей жизнью и текущей функциональностью LXC обязана именно им.n
Установка OpenVz
Как уже говорилось выше, часть компонентов OpenVZ отсутствует в основной ветке ядра Linux, а соответственно и в ядрах большинства дистрибутивов. По этой причине для того, чтобы использовать OpenVZ, необходимо специальное ядро, в котором есть все необходимое для запуска контейнеров. Подготовленные ядра можно найти практически для любого дистрибутива. OpenVZ базируется на ядрах Red Hat, поэтому более предпочтительными являются дистрибутивы RHEL\CentOS\Scientific Linux. Хотя на официальном сайте также предоставлены репозитории и инструкции для Debian. Я сторонник CentOS, и поэтому в рамках моей статьи будет использоваться этот дистрибутив версии 6.3. Прежде чем приступать к установке компонентов OVZ, рекомендуется сформировать отдельный раздел на жестком диске или целый массив для будущего хранилища контейнеров, директории /vz. Удобнее всего это выполнить в процессе инсталляции ОС на этапе разбивки дисков. Когда система будет установлена и настроена сеть, можно приступать к установке нового ядра. Первым делом подключиаем репозиторий OVZ
# wget -P /etc/yum.repos.d/ http://ftp.openvz.Org/openvz.reponn# rpm —import http://ftp.openvz.org/nnPM-GPG-Key-OpenVZ
и устанавливаем ядро:n
# yum install vzkernel
nnПосле установки ядро OpenVZ будет использоваться по умолчанию при загрузке ОС. Прежде чем перезагрузиться и отдать управление системой новому ядру, необходимо изменить ряд параметров в файле /etc/sysctl.conf
net.ipv4.ip_forward = 1nnnet.ipv6.conf.default.forwarding = 1nnnet.ipv6.conf.all.forwarding = 1nnnet.ipv4.conf.default.proxy_arp = 0nnnet.ipv4.conf.all.rp_filter = 1nnkernel.sysrq = 1nnnet.ipv4.conf.default.send_redirects = 1nnnet.ipv4.conf.all.send_redirects = 0
Примечание. В свежих версия vzctl начиная с 4.4 приведенные выше параметры будут внесены автоматически при установке.n
А также отключить SELinux:
nn
# echo «SELINUX=disabled» > /etc/sysconfig/selinux
И в завершение необходимо установить пользовательские утилиты управления OVZ
# yum install vzctl vzquota ploop
Далее перезагружаем систему и получаем готовую к эксплуатации платформу OpenVZ.nnПримечание. Начиная с версии ядра 3.х базовые функции, такие как создание, запуск и остановка контейнеров, возможны без установки собственного ядра OpenVZ. Для этого лишь необходимо установить vzctl версию 4.0 или более новую .n
Шаблоны контейнеров
Как и в случае с LXC, для создания нового контейнера необходим шаблон. Фактически шаблон — это корневая файловая система, различные утилиты и конфигурационные файлы конкретного дистрибутива. Обычно в минимальной инсталляции. В официальном репозитории OpenVZ подготовлены шаблоны для наиболее популярных ОС. Там можно найти различные версии Ubuntu, Debian, CentOS, а также SUSE Linux. Но, на мой взгляд, наиболее простой способ получить нужный шаблон — это скачать его вручную и положить в предназначенный для этого каталог /vz/template/ cache/.n
# cd /vz/template/cache/nn# wget http://download.openvz.org/template/precreated/ubuntu-13.10-x86_64.tar.gz
Полученный архив после скачивания распаковывать не нужно, утилита vzctl все сделает сама.nnКроме официального репозитория с шаблонами, есть еще множество сторонних. Например, проект TurnKey Linux предоставляет готовые сборки Debian 7 с различными предварительно настроенными сервисами. Там и почтовые серверы и веб-серверы, системы управления контентом и прочее.n
Создание собственных шаблонов
Вполне логично, что возникает желание создать свой собственный шаблон с особыми настройками и различным ПО. Этот процесс требует выполнения множества различных действий, но все они очень просты и понятны. Следуя одной из детальных инструкций , это легко сделать самостоятельно.n
Администрирование контейнеров
Теперь, когда у нас есть шаблон дистрибутива, можно приступить к его развертыванию.n
# vzctl create 101 —ostemplate ubuntu-13.10-x86_64
Здесь 101 — это обязательный уникальный идентификатор контейнера, который может быть произвольным числом.nnНовый экземпляр ОС будет создан в течение считанных секунд. Фактически это время потрачено на распаковку архива и помещение его содержимого в каталог /vz/private/<id-контейнера>.nnДалее по логике следует настройка основных параметров экземпляра
# vzctl set 101 —hostname u101 —savenn# vzctl set 101 —ipadd 10.200.77.45 —savenn# vzctl set 101 —nameserver 10.200.77.10 —save
Ключ —save означает, что указанные параметры должны быть записаны в конфигурационный файл контейнера /etc/ vz/conf/101.conf на постоянной основе и устанавливаются при каждом запуске экземпляра. Если его опустить, то указанные настройки применяются к контейнеру до его перезагрузки (в случае если он запущен).nnТак как большинство настроек ОС Linux хранится в простых текстовых файлах, их легко можно перенести на множество контейнеров.nnНапример, скопировать список репозиториев и серверов DNS
cp /etc/apt/sources.listn
/vz/private/101/etc/apt/sources.listcp
n
/etc/resolv.conf /vz/private/101/etc/resolv.conf
n
Если оперировать идентификатором контейнера неудобно, то ему можно присвоить понятное человеку имя
# vzctl set 101 —name ubuntu101 —save
Таких имен можно задать множество и использовать их для выполнения всех операций, например, для запуска контейнера
# vzctl start ubuntu101
Кроме команды start, есть еще stop — завершение работы, restart — остановка и запуск, а также destroy — удаление остановленного контейнера с диска.nnПри развертывании нового экземпляра из шаблона совершенно непонятно, какие учетные данные использовать для входа в ОС. Но это не проблема. Задать пароль любому пользователю экземпляра, в том числе root, можно прямо из хост-системы
# vzctl set 101 —userpasswd root:123456
Если указанной учетной записи в системе не окажется, она будет создана. Разобравшись с пользователями, можно подключаться к контейнеру классическим способом, с помощью SSH.n
# ssh -l ubuntu 10.200.77.45
Если у контейнера нет IP-адреса или отсутствует сервис SSH, то можно войти как root, напрямую, без всяких паролей
# vzctl enter 101
Для просмотра списка существующих контейнеров используется следующая команда:
nn
# vzlistnnCTID NPROC STATUS IP_ADDR HOSTNAMEnn101 18 running 10.200.77.45 u101
Без параметров vzlist выводит список только запущенных экземпляров. Добавив ключ -all, вы увидите все зарегистрированные в системе контейнеры.n
Администратор может все
Ключ vzctl enter — не единственная иллюстрация безграничных возможностей администратора хост-системы. Есть еще vzctl exec, которая позволяет выполнять практически любую команду в контейнере от имени суперпользователя и возвращать результат выполнения в консоль хоста. Например, вывести список DNS-серверов
# vzctl exec 101 cat /etc/resolv.confnnnameserver 10.200.119.11 nameserver 10.200.119.12
Или отключить сетевой интерфейс:
nn
n
# vzctl exec 101 ifdown venet0
n
Снимки состояния (snapshots)
Тут стоит начать с такой довольно известной технологии, как Loopback Device (loop), — это механизм ядра Linux, позволяющий эмулировать обычные файлы как блочные устройства. Подключаются такие файлы через специальный виртуальный контроллер, позволяющий традиционными способами создавать разделы и файловые системы внутри этих файлов. OpenVZ использует более продвинутую реализацию этого механизма под названием ploop. Это дает возможность создавать диски, растущие в объеме по мере заполнения (тонкие диски), изменять их размер на лету, создавать мгновенные снимки (snapshots). Если эти возможности вам необходимы, то новые контейнеры должны создаваться следующим образом
# vzctl create 101 —ostemplate ubuntu-13.10-x86_64 —layout ploop —diskspace 4G
Ключ —layout ploop отвечает за создание контейнера в файле-диске /vz/private/101/root.hdd, максимальный размер которого задается ключом diskspace 4G. По факту диск является тонким и будет увеличиваться в объеме по мере заполнения данными.nnСозданные ранее контейнеры обычного типа можно легко привести к этому виду, задав сначала желаемый размер диска
# vzctl set 101 —diskspace 10G —save
а затем выполнив конвертацию:
nn
# vzctl convert 101 —layout ploop
Теперь можно создавать снимки:
nn
# vzctl snapshot 101 —name SNAP01 —description pred install
Созданные снимки помещаются в каталог /vz/private/101/ dump. В отличие от LXC создавать снимки можно прямо во время работы контейнера. Чтобы просмотреть доступные снапшоты, необходимо выполнить
# vzctl snapshot-list 101
К сожалению, будут выведены только уникальный идентификатор снимка, его имя и время создания. Описание, заданное при создании, показано не будет. Его можно посмотреть самостоятельно в файле/vz/private/IOI/Snapshots.xml.n
Переключиться на любой снимок легко:
nn
# vzctl snapshot-switch 101 —id 89e469a8-47b7-41a5-bbd3-5bf3312521d8
Ключ —id позволяет задать идентификатор снимка. К сожалению, оперировать именами тут нельзя. Удалить снимок можно, заменив snapshot-switch на snapshot-delete.n
Ограничение ресурсов
Ресурсы (CPU, память, диск, операции ввода/вывода и даже правила iptables), предоставляемые гостевым окружениям, могут быть нескольких видов:гарантированные — это тот объем ресурсов, который контейнер получит в любых условиях; негарантированные — это свободные ресурсы хоста, которые могут быть отданы контейнеру, если он в них нуждается. Но они также могут быть отобраны в любой момент;nnлимитированные — это максимальная планка, за которую контейнер не может выйти.nnЛимитирование ресурсов защищает контейнеры друг от друга, а дополнительное выделение свободных ресурсов повышает производительность активных контейнеров в моменты простоя хоста. Данная тема требует более развернутого описания по каждому из ресурсов.nnЗа более подробной информацией читатели могут обратиться в мой интернет-блог .n
Сетевой стек
Контейнеры OpenVZ могут быть подключены к сети тремя различными типами сетевых интерфейсов, каждый из которых имеет свои особенности и назначение.nnПервый тип, используемый по умолчанию, — это vnet (Virtual network). Vnet-устройство работает на третьем уровне (L3) модели OSI и не имеет своего собственного MAC-адреса. Практически такой интерфейс является своего рода псевдонимом (alias) интерфейса хост- системы. Она же, исходя из заголовков пакетов, определяет, какому контейнеру предназначается трафик. Настройка выполняется администратором базовой системы. Плюсами такой конфигурации являются легкость настройки и максимальное среди всех типов быстродействие. Минусы же вытекают из отсутствия у интерфейса MAC-адреса. Это делает невозможной работуnnшироковещательных запросов, что не позволяет использовать DHCP-сервер или Samba внутри контейнера. Также в связи с отсутствием MAC-адреса не будут работать приложения, нуждающиеся в нем, в том числе IPv6.nnVeth (Virtual Ethernet device) — виртуальный Ethernet-интерфейс. Этот тип сетевого устройства работает на втором уровне (L2) модели OSI и предоставляет контейнеру полноценный сетевой стек, включая и собственный MAC-адрес. Внутри гостевого окружения такой интерфейс выглядит, как настоящий, и его настройка может быть выполнена без вмешательства администратора хост-системы. К его минусам можно отнести более сложную настройку , а также меньшую производительность относительно vnet.nnТретий тип подключения — это делегирование физического сетевого контроллера в контейнер. Это наименее популярный подход, так как он более дорогой и сложный. Если при каких-то условиях это необходимо, например, хочется сделать из контейнера настоящий роутер, что само по себе не очень правильно, то надо действовать следующим образом
# vzctl set 103 —netdev_add eth2 —save
После этого eth2 становится доступен внутри контейнера и соответственно не должен иметь каких-либо настроек в хост-системе. Настройка его производится стандартными средствами внутри контейнера, затем можно работать с сетью в обычном режиме.n
Миграция контейнеров между физическими узлами
На мой взгляд, это одна из важнейших функций платформы виртуализации, если используется более одного физического хоста. Перенос контейнеров с узла на узел для обеспечения балансировки нагрузки или для проведения обслуживания периодически просто необходим. OpenVZ предоставляет такую возможность, на мой взгляд, довольно удобную в использовании.nnГлавное требование — это настроенная между узлами SSH авторизация по ключам, не требующая ввода пароля.nnВторым пунктом будет идентичная настройка узлов. Под идентичностью подразумевается наличие одинаковых версий пакетов, а также единое расположение каталогов и конфигурационных файлов OpenVZ. Впрочем, если установлена одна и та же версия дистрибутива и используются пути по умолчанию, все пройдет гладко.nnСтоит отметить, что идентичность оборудования не требуется. Модели процессоров (за исключением разрядности), объем памяти и конфигурация дисковой подсистемы значения не имеют. Если все соблюдено, то перенести выключенную машину на другой узел можно следующим образом
# vzmigrate <имяПринимающегоХоста> 101
Миграция остановленного контейнера хороша тем, что происходит максимально быстро. Но если простой нежелателен, то можно выполнить перенос «на живую» работающего экземпляра.n
# vzmigrate —online <имяПринимающегоХоста> 101
В таком случае переносится не только содержимое файловой системы, но и состояние процессов, сокетов, открытых файлов и прочего. Все это особым образом замораживается и передается на другой узел. В процессе перемещения происходит кратковременный разрыв соединения с контейнером. Время разрыва зависит от конфигурации.n
Готовые сборки и панели управления
Если неохота возиться с установкой и настройкой OpenVZ, но хочется быстро получить функционал этого продукта, можно воспользоваться одной из готовых сборок. Лидером тут, пожалуй, является продукт под названием Proxmox VE . Этот дистрибутив основан на Debian и включает в себя средства виртуализации KVM и OpenVZ одновременно. Функционал тут довольно богатый. Средства резервного копирования, кластеризации и живой миграции ВМ. Есть собственный репозиторий с различными шаблонами для OpenVZ, развернуть которые можно в несколькоnnкликов. Управление осуществляется через удобный веб-интерфейс. Единственным минусом, на мой взгляд, является то, что у проекта с открытым исходным кодом обновления доступны только за деньги. Альтернативой является проект OpenNode Cloud Platform [11], предоставляющий схожий функционал.nnКроме готовых коробочных решений, существуют отдельные веб-панели, облегчающие администрирование инфраструктуры OpenVZ. Наиболее функциональное и удобное решение, на мой взгляд, — это OpenVZ Web Panel [12]. Ее легко установить
# wget -O — http://ovz-web-panel.googlecode.com/svn/installer/ai.sh | sh
А после все настройки доступны по адресу:
n http://<имя сервера>:3000nn Это решение позволяет выполнять большинство административных действий с контейнерами OpenVZ. Тут и средства резервного копирования, и мониторинг, и управление несколькими хост-системами.nnЗаключение: OpenVZ — это полноценная, самодостаточная и безопасная платформа для контейнерной виртуализации. Долгий путь развития и совершенствования сделал из нее весьма эффективное решение в своем классе. Лично я давно не получал такого удовольствия от программного продукта, с которым работал. Почти все сделано удобно и просто, а главное, работает так, как ожидается. Любые вопросы легко решаются с помощью документации. Какое-либо сравнение с LXC не имеет смысла — на данный момент это продукты совершенно разного уровня. LXC еще в начале пути, и до серьезного production-решения ему нужно дорасти. Есть мнения, что с развитием LXC продукт OpenVZ постепенно перестанет развиваться и совсем умрет. Но это не так. Проект активно развивается и уходить с рынка не планирует. Более того, перенос функционала в основную ветку ядра позволит со временем использовать все больше возможностей платформы без установки собственных ядер.nnИсточник: Системный администратор №138 май 2014