Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Виртуализация ОС - теория и практика OpenVZ

Виртуализация ОС — теория и практика OpenVZ

OpenVZ vs LXC

Проект Virtuozzo Containers, как и его открытый клон OpenVZ, существует и развивается уже порядка 10 лет. Изначально ядро платформы развивалось самостоятельно в стороне от основной ветки ядра Linux. Но где-то на половине пути разработчики Parallels поняли, что такая стратегия очень сложна и затратна.

Поэтому было принято решение портировать все фир­менные наработки в основную ветку ядра, дабы дать им са­мостоятельное развитие. Но процесс вливания патчей до­вольно сложен и длителен.

На сегодняшний день лишь половина «ядерного» функ­ционала Virtuozzo перекочевала в основную ветку ядра. Фактически на ней  и основывается LXC. Конечно же, не­которые части проекта, такие как утилиты управления, ша­блоны и ряд других, разрабатываются не программистами Parallels. Но в целом своей жизнью и текущей функциональ­ностью LXC обязана именно им.

Установка 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.repo

#  rpm —import http://ftp.openvz.org/

PM-GPG-Key-OpenVZ

и устанавливаем ядро:

#  yum install vzkernel

 

После установки ядро OpenVZ будет использоваться по умолчанию при загрузке ОС. Прежде чем перезагрузить­ся и отдать управление системой новому ядру, необходимо изменить ряд параметров в файле /etc/sysctl.conf:

net.ipv4.ip_forward = 1

net.ipv6.conf.default.forwarding = 1

net.ipv6.conf.all.forwarding = 1

net.ipv4.conf.default.proxy_arp = 0

net.ipv4.conf.all.rp_filter = 1

kernel.sysrq = 1

net.ipv4.conf.default.send_redirects = 1

net.ipv4.conf.all.send_redirects = 0

Примечание. В свежих версия vzctl начиная с 4.4 при­веденные выше параметры будут внесены автоматически при установке.

А также отключить SELinux:

 #  echo «SELINUX=disabled» > /etc/sysconfig/selinux

И в завершение необходимо установить пользователь­ские утилиты управления OVZ:

#  yum install vzctl vzquota ploop

Далее перезагружаем систему и получаем готовую к экс­плуатации платформу OpenVZ.

Примечание. Начиная с версии ядра 3.х базовые функции, такие как создание, запуск и остановка контейнеров, возможны без установки собственного ядра OpenVZ. Для это­го лишь необходимо установить vzctl версию 4.0 или более новую .

Шаблоны контейнеров

Как и в случае с LXC, для создания нового контейнера не­обходим шаблон. Фактически шаблон — это корневая фай­ловая система, различные утилиты и конфигурационные файлы конкретного дистрибутива. Обычно в минимальной инсталляции. В официальном репозитории  OpenVZ под­готовлены шаблоны для наиболее популярных ОС. Там мож­но найти различные версии Ubuntu, Debian, CentOS, а также SUSE Linux. Но, на мой взгляд, наиболее простой способ получить нужный шаблон — это скачать его вручную и по­ложить в предназначенный для этого каталог /vz/template/ cache/.

# cd /vz/template/cache/

# wget http://download.openvz.org/template/precreated/ubuntu-13.10-x86_64.tar.gz

Полученный архив после скачивания распаковывать не нужно, утилита vzctl все сделает сама.

Кроме официального репозитория с шаблонами, есть еще множество сторонних. Например, проект TurnKey Linux  предоставляет готовые сборки Debian 7 с различ­ными предварительно настроенными сервисами. Там и поч­товые серверы и веб-серверы, системы управления контен­том и прочее.

Создание собственных шаблонов

Вполне логично, что возникает желание создать свой собст­венный шаблон с особыми настройками и различным ПО. Этот процесс требует выполнения множества различных действий, но все они очень просты и понятны. Следуя одной из детальных инструкций , это легко сделать самостоя­тельно.

Администрирование контейнеров

Теперь, когда у нас есть шаблон дистрибутива, можно при­ступить к его развертыванию.

#  vzctl create 101 —ostemplate ubuntu-13.10-x86_64

Здесь 101 — это обязательный уникальный идентифика­тор контейнера, который может быть произвольным числом.

Новый экземпляр ОС будет создан в течение считан­ных секунд. Фактически это время потрачено на распа­ковку архива и помещение его содержимого в каталог /vz/private/<id-контейнера>.

Далее по логике следует настройка основных парамет­ров экземпляра:

# vzctl set 101 —hostname u101 —save

# vzctl set 101 —ipadd 10.200.77.45 —save

# vzctl set 101 —nameserver 10.200.77.10 —save

Ключ —save означает, что указанные параметры должны быть записаны в конфигурационный файл контейнера /etc/ vz/conf/101.conf на постоянной основе и устанавливаются при каждом запуске экземпляра. Если его опустить, то ука­занные настройки применяются к контейнеру до его переза­грузки (в случае если он запущен).

Так как большинство настроек ОС Linux хранится в про­стых текстовых файлах, их легко можно перенести на мно­жество контейнеров.

Например, скопировать список репозиториев и серверов DNS:

cp /etc/apt/sources.list

/vz/private/101/etc/apt/sources.listcp

 /etc/resolv.conf /vz/private/101/etc/resolv.conf

Если оперировать идентификатором контейнера неудоб­но, то ему можно присвоить понятное человеку имя:

 #  vzctl set 101 —name ubuntu101 —save

Таких имен можно задать множество и использовать их для выполнения всех операций, например, для запуска контейнера:

#  vzctl start ubuntu101

Кроме команды start, есть еще stop — завершение рабо­ты, restart — остановка и запуск, а также destroy — удаление остановленного контейнера с диска.

При развертывании нового экземпляра из шаблона со­вершенно непонятно, какие учетные данные использовать для входа в ОС. Но это не проблема. Задать пароль любому пользователю экземпляра, в том числе root, можно прямо из хост-системы:

#  vzctl set 101 —userpasswd root:123456

Если указанной учетной записи в системе не окажется, она будет создана. Разобравшись с пользователями, можно подключаться к контейнеру классическим способом, с по­мощью SSH.

 #  ssh -l ubuntu 10.200.77.45

Если у контейнера нет IP-адреса или отсутствует сервис SSH, то можно войти как root, напрямую, без всяких паролей:

#  vzctl enter 101

Для просмотра списка существующих контейнеров ис­пользуется следующая команда:

#  vzlist

CTID           NPROC STATUS        IP_ADDR            HOSTNAME

101                18 running     10.200.77.45       u101

Без параметров vzlist выводит список только запущенных экземпляров. Добавив ключ -all, вы увидите все зарегистри­рованные в системе контейнеры.

Администратор может все

Ключ vzctl enter — не единственная иллюстрация безгранич­ных возможностей администратора хост-системы. Есть еще vzctl exec, которая позволяет выполнять практически любую команду в контейнере от имени суперпользователя и воз­вращать результат выполнения в консоль хоста. Например, вывести список DNS-серверов:

 #  vzctl exec 101 cat /etc/resolv.conf

nameserver 10.200.119.11 nameserver 10.200.119.12

Или отключить сетевой интерфейс:

 #  vzctl exec 101 ifdown venet0

Снимки состояния (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. По факту диск является тонким и будет увеличиваться в объеме по мере заполнения данными.

Созданные ранее контейнеры обычного типа можно лег­ко привести к этому виду, задав сначала желаемый размер диска:

 #  vzctl set 101 —diskspace 10G —save

 а затем выполнив конвертацию:

#  vzctl convert 101 —layout ploop

Теперь можно создавать снимки:

 #  vzctl snapshot 101 —name SNAP01 —description pred install

Созданные снимки помещаются в каталог /vz/private/101/ dump. В отличие от LXC создавать снимки можно прямо во время работы контейнера. Чтобы просмотреть доступ­ные снапшоты, необходимо выполнить:

#  vzctl snapshot-list 101

К сожалению, будут выведены только уникальный иден­тификатор снимка, его имя и время создания. Описание, за­данное при создании, показано не будет. Его можно посмот­реть самостоятельно в файле/vz/private/IOI/Snapshots.xml.

Переключиться на любой снимок легко:

#  vzctl snapshot-switch 101 —id 89e469a8-47b7-41a5-bbd3-5bf3312521d8

Ключ —id позволяет задать идентификатор снимка. К со­жалению, оперировать именами тут нельзя. Удалить снимок можно, заменив snapshot-switch на snapshot-delete.

Ограничение ресурсов

Ресурсы (CPU, память, диск, операции ввода/вывода и даже правила iptables), предоставляемые гостевым окружениям, могут быть нескольких видов:

гарантированные — это тот объем ресурсов, который контейнер получит в любых условиях; негарантированные — это свободные ресурсы хоста, которые могут быть отданы контейнеру, если он в них нуждается. Но они также могут быть отобраны в любой момент;

лимитированные — это максимальная планка, за кото­рую контейнер не может выйти.

Лимитирование ресурсов защищает контейнеры друг от друга, а дополнительное выделение свободных ресурсов повышает производительность активных контейнеров в мо­менты простоя хоста. Данная тема требует более разверну­того описания по каждому из ресурсов.

За более подробной информацией читатели могут обра­титься в мой интернет-блог .

Сетевой стек

Контейнеры OpenVZ могут быть подключены к сети тремя различными типами сетевых интерфейсов, каждый из кото­рых имеет свои особенности и назначение.

Первый тип, используемый по умолчанию, — это vnet (Virtual network). Vnet-устройство работает на третьем уровне (L3) модели OSI и не имеет своего собственного MAC-адреса. Практически такой интерфейс является сво­его рода псевдонимом (alias) интерфейса хост- системы. Она же, исходя из заголовков пакетов, определяет, како­му контейнеру предназначается трафик. Настройка вы­полняется администратором базовой системы. Плюсами такой конфигурации являются легкость настройки и мак­симальное среди всех типов быстродействие. Минусы же вытекают из отсутствия у интерфейса MAC-адреса. Это де­лает невозможной работу

широковещательных запросов, что не позволяет использовать DHCP-сервер или Samba внутри контейнера. Также в связи с отсутствием MAC-адреса не будут работать приложения, нуждающиеся в нем, в том числе IPv6.

Veth (Virtual Ethernet device) — виртуальный Ethernet-интерфейс. Этот тип сетевого устройства работает на вто­ром уровне (L2) модели OSI и предоставляет контейнеру полноценный сетевой стек, включая и собственный MAC-адрес. Внутри гостевого окружения такой интерфейс выгля­дит, как настоящий, и его настройка может быть выполнена без вмешательства администратора хост-системы. К его ми­нусам можно отнести более сложную настройку , а также меньшую производительность относительно vnet.

Третий тип подключения — это делегирование физиче­ского сетевого контроллера в контейнер. Это наименее популярный подход, так как он более дорогой и сложный. Если при каких-то условиях это необходимо, например, хо­чется сделать из контейнера настоящий роутер, что само по себе не очень правильно, то надо действовать следую­щим образом:

#  vzctl set 103 —netdev_add eth2 —save

После этого eth2 становится доступен внутри контейне­ра и соответственно не должен иметь каких-либо настроек в хост-системе. Настройка его производится стандартными средствами внутри контейнера, затем можно работать с се­тью в обычном режиме.

Миграция контейнеров между физическими узлами

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

Главное требование — это настроенная между узлами SSH авторизация  по ключам, не требующая ввода пароля.

Вторым пунктом будет идентичная настройка узлов. Под идентичностью подразумевается наличие одинаковых версий пакетов, а также единое расположение каталогов и конфигурационных файлов OpenVZ. Впрочем, если уста­новлена одна и та же версия дистрибутива и используются пути по умолчанию, все пройдет гладко.

Стоит отметить, что идентичность оборудования не тре­буется. Модели процессоров (за исключением разрядно­сти), объем памяти и конфигурация дисковой подсистемы значения не имеют. Если все соблюдено, то перенести вы­ключенную машину на другой узел можно следующим об­разом:

#  vzmigrate <имяПринимающегоХоста> 101

Миграция остановленного контейнера хороша тем, что происходит максимально быстро. Но если простой не­желателен, то можно выполнить перенос «на живую» рабо­тающего экземпляра.

#  vzmigrate —online <имяПринимающегоХоста> 101

В таком случае переносится не только содержимое файловой системы, но и состояние процессов, сокетов, открытых файлов и прочего. Все это особым образом за­мораживается и передается на другой узел. В процессе перемещения происходит кратковременный разрыв соеди­нения с контейнером. Время разрыва зависит от конфигу­рации.

Готовые сборки и панели управления

Если неохота возиться с установкой и настройкой OpenVZ, но хочется быстро получить функционал этого продукта, можно воспользоваться одной из готовых сборок. Лиде­ром тут, пожалуй, является продукт под названием Proxmox VE . Этот дистрибутив основан на Debian и включает в себя средства виртуализации KVM и OpenVZ одновре­менно. Функционал тут довольно богатый. Средства ре­зервного копирования, кластеризации и живой миграции ВМ. Есть собственный репозиторий с различными шабло­нами для OpenVZ, развернуть которые можно в несколько

кликов. Управление осуществляется через удобный веб-ин­терфейс. Единственным минусом, на мой взгляд, является то, что у проекта с открытым исходным кодом обновления доступны только за деньги. Альтернативой является проект OpenNode Cloud Platform [11], предоставляющий схожий функционал.

Кроме готовых коробочных решений, существуют от­дельные веб-панели, облегчающие администрирование ин­фраструктуры OpenVZ. Наиболее функциональное и удоб­ное решение, на мой взгляд, — это OpenVZ Web Panel [12]. Ее легко установить:

# wget -O — http://ovz-web-panel.googlecode.com/svn/installer/ai.sh | sh

 А после все настройки доступны по адресу:

 http://<имя сервера>:3000

 Это решение позволяет выполнять большинство админи­стративных действий с контейнерами OpenVZ. Тут и сред­ства резервного копирования, и мониторинг, и управление несколькими хост-системами.

Заключение: OpenVZ — это полноценная, самодостаточная и безопасная платформа для контейнерной виртуализации. Долгий путь развития и совершенствования сделал из нее весьма эф­фективное решение в своем классе. Лично я давно не полу­чал такого удовольствия от программного продукта, с кото­рым работал. Почти все сделано удобно и просто, а главное, работает так, как ожидается. Любые вопросы легко решают­ся с помощью документации. Какое-либо сравнение с LXC не имеет смысла — на данный момент это продукты совер­шенно разного уровня. LXC еще в начале пути, и до серьез­ного production-решения ему нужно дорасти. Есть мнения, что с развитием LXC продукт OpenVZ постепенно переста­нет развиваться и совсем умрет. Но это не так. Проект ак­тивно развивается и уходить с рынка не планирует. Более того, перенос функционала в основную ветку ядра позволит со временем использовать все больше возможностей плат­формы без установки собственных ядер.

Источник: Системный администратор №138 май 2014

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.