Система виртуализации OpenVZ: Часть 2.Работаем с контейнерами


Утилита управления vzctl

Снова рассмотрим команду создания нового контейнера:

	vzctl create 101 --ostemplate ubuntu-9.04-x86_64

Здесь 101 – это вручную выбираемый VEID (virtual environment ID) или CTID (container ID), целочисленный номер нового контейнера, который будет использоваться для управления им. Рекомендуется не использовать: а) зарезервированные номера меньше 101 и б) одинаковые номера на разных VPS-фермах, чтобы не иметь потенциальных проблем с миграцией и легче идентифицировать физическое расположение контейнера по его номеру.

После завершения данной команды появятся файл /etc/vz/conf/101.conf с настройками и каталоги: /var/lib/vz/private/101 (заполненный содержимым шаблона) и /var/lib/vz/root/101 (пустой).

Затем выполняется настройка:

	vzctl set 101 --save
		--name example1
		--ipadd 192.0.2.101
		--hostname example1.homelink.ru
		--nameserver 192.0.2.2
		--onboot yes
		--privvmpages 72000:80000

В этом примере используются следующие аргументы:

  • «save» приказывает сохранить изменения в conf-файле. Без этого параметра они будут применены к запущенному контейнеру без сохранения;
  • «name» задаёт произвольное читабельное имя, которое затем можно использовать вместо VEID. Например, «vzctl status example1»;
  • «ipadd» назначает контейнеру IP-адрес во внутренней сети OpenVZ;
  • «hostname» изменяет имя системы, используемое внутри контейнера для самоидентификации;
  • «nameserver» конфигурирует контейнер на использование указанного DNS-сервера;
  • «onboot» приказывает запускать контейнер при старте OpenVZ;
  • «privvmpages» устанавливает новые лимиты для одного из параметров.

После этого контейнер можно запустить:

	vzctl start example1

Проверить его выполнение:

	# vzctl status example1
	VEID 101 exist mounted running
	# vzlist
	VEID   NPROC   STATUS    IP_ADDR       HOSTNAME
	  20      53   running   192.0.2.101    example1.homelink.ru

Выполнить в нём одиночную команду:

	vzctl exec example1 uname -a

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

	vzctl enter example1

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

Лимиты

OpenVZ ограничивает для контейнеров потребление всех системных ресурсов: процессора, оперативной памяти, дискового пространства, системных буферов, сокетов и т. д. Начальные лимиты настолько строгие, что даже команда «apt-get update» в только что созданном контейнере завершается с сообщением об ошибке.

Управление ограничениями в системе с OpenVZ является двухуровневым: для контейнера в целом – средствами OpenVZ, внутри контейнера – стандартными средствами Linux, через ulimit и дисковые квоты.

Для проверки внешних ограничений служит файл /proc/user_beancounters. Внутри контейнера этот файл заполнен информацией по данному контейнеру, во внешней системе содержит сведения обо всех запущенных окружениях. Основной интерес в нём представляет последний столбец, «failcnt» («failure counter», т. е. «количество сбоев»):

	egrep -v ' 0$' /proc/user_beancounters

Для вывода в более удобном формате, а также для периодических отчётов рекомендуется использовать несколько небольших утилит, доступных на сайте sources.homelink.ru/openvz:

# ubc_failstat
	Version: 2.5 
	uid  resource         held    maxheld    barrier     limit     failcnt
	20:  privvmpages    184917     209713     200000    250000           5
	15:  numproc            16        130        130       130          31
	15:  numfile           515       2048       2048      2048        1122
	13:  tcpsndbuf           0     332416     319488    524288    55341330
	# ubc_faildiff /tmp/failstat.yesterday
	uid      resource          old          new        delta 
	13:     tcpsndbuf     50463657     52879924      2416267 
	15:       numfile          856         1122          266 
	15:       numproc           13           31           18

Из вывода ubc_failstat видно, что проблемы имеются в трёх контейнерах (13,15,20) , а ubc_faildiff показывает динамику количества ошибок по сравнению с предыдущим запомненным результатом.

Примеры исправления:

	vzctl set 20 --save --privvmpages 250000:300000
	vzctl set 15 --save --numproc 200:200 --numfile 4096:4096

vzctl не полностью проверяет корректность вводимых аргументов (например, позволяет задавать разный лимит и барьер для таких параметров, как numproc и numfile, для которых лимит и барьер обязаны совпадать), поэтому рекомендуется проводить дополнительную проверку конфигурационных файлов с помощью утилиты vzcfgvalidate:

	for n in /etc/vz/conf/??.conf;do echo Check $n; vzcfgvalidate $n; done

Обратите внимание, что проверяется именно файл (с указанием полного пути), а не текущие параметры, которые могут быть другими, если «vzctl set» запускался без ключа «—save». С другой стороны, vzcfgvalidate удобен тем, что может проверять параметры, когда контейнер не запущен.

Для исправления конфигурационного файла vzcfgvalidate следует запустить с ключом «-r» («repair mode», автоматическое исправление) или «-i» («interactive repair», ручное исправление).

Отличие между лимитом и барьером заключается в следующем: при превышении барьера счётчик ошибок увеличивается, но запрошенная операция выполняется. При превышении лимита операция завершается с ошибкой.

Сеть

OpenVZ создаёт в хост-системе и в каждом контейнере сетевой интерфейс venet0. Хост-система получает IP-адрес 192.0.2.1 и служит для контейнеров шлюзом по умолчанию:

	# vzctl exec 101 ip route list
	192.0.2.1 dev venet0  scope link 
	default via 192.0.2.1 dev venet0

Если контейнер должен быть доступен только локально (например, в нём выполняется FastCGI-приложение, вызываемое через запущенный в соседнем контейнере Web-сервер), ему следует выделить адрес из диапазона 192.0.2.0/24, например, 192.0.2.$VEID. Если же контейнер должен быть виден из внешнего мира, ему следует назначить IP-адрес из той же сети, в которой находится внешний интерфейс VPS-фермы (допустим, что её IP-адрес на сетевом интерфейсе eth0 равен 1.2.3.10/24):

	vzctl set 101 --save --ipadd 1.2.3.11
	vzctl set 102 --save --ipadd 1.2.3.12

Проверка:

	# vzctl exec 101 ip addr list dev venet0
	3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP>
	    link/void
	    inet 127.0.0.1/32 scope host venet0
	    inet 1.2.3.11/32 scope global venet0:2
	# ip route list | grep 1.2.3.11
	1.2.3.11 dev venet0 scope link

При этом OpenVZ автоматически создаст для IP-адреса контейнера ProxyARP-запись на внешних сетевых интерфейсах VPS-фермы, как если бы была вызвана команда «arp -i eth0 -Ds 10.20.30.11 eth0 pub»:

	# arp -ani eth0
	? (1.2.3.10) at 00:11:22:33:44:55 [ether] on eth0
	? (1.2.3.11) at * PERM PUP on eth0 
	? (1.2.3.12) at * PERM PUP on eth0

Не забудьте также разрешить на VPS-ферме маршрутизацию между интерфейсами eth0 и venet0, например:

	# iptables -A FORWARD -i venet0 -j ACCEPT
	# iptables -A FORWARD -o venet0 -j ACCEPT
	# sysctl net.ipv4.conf.all.forwarding = 1
	# sysctl net.ipv4.ip_forward = 1

IP-адрес 192.0.2.1 на хост-системе является неявным – его нет в свойствах устройства venet0, хотя хост-система видит через tcpdump пакеты, посылаемые на этот адрес из контейнеров. Таким образом, если хост-система хочет предоставлять контейнерам какие-то сервисы, например, DNS или прокси, следует явно назначить интерфейсу venet0 дополнительный IP, например, 192.0.2.2/24. Например, в ALT Linux это делается созданием каталога /etc/net/ifaces/venet0 с двумя файлами:

  • ipv4address:
    192.0.2.2/24
  • options:
    TYPE=venet
    ONBOOT=yes

Обратите внимание на «ONBOOT=yes». Благодаря ему интерфейс venet0 появится не в момент запуска OpenVZ, а существенно раньше – в момент запуска сети, т. е. перед запуском сетевых сервисов, и не будет исчезать при остановках OpenVZ. Это позволит явно привязать сервисы к venet0 и сделать их недоступными на остальных интерфейсах, не прибегая к помощи файрволла.

Пакет etcnet в ALTLinux содержит несколько относящихся к venet мелких ошибок, не влияющих на работоспособность, но приводящих к неверной диагностике при любых вызовах /etc/init.d/network. Исправление для них доступно на сайте bugzilla.altlinux.org.

Кроме venet (Virtual Network), OpenVZ способен предоставлять контейнерам ещё один тип устройств, veth (Virtual Ethernet). Veth предоставляет больше возможностей, но сложнее в настройке, менее производителен и требуется в исключительных случаях, поэтому здесь не описывается.

Доступ к устройствам

Из виртуальных окружений прямой доступ отсутствует и к железу, и к ядру. Каталог /dev почти пуст и содержит только логические устройства: null, zero, random, tty, console и т. д.

Сервисы, для работы которых требуется загрузка модулей ядра, смогут работать при выполнении трёх условий:

  • данный модуль загружен во внешней системе;
  • файл соответствующего устройства перенесён в /dev контейнера командой «vzctl set 11 —devnodes»;
  • модуль ядра во внешней системе и использующий его сервис в контейнере используют совместимые версии ABI («Application binary interface», «двоичный интерфейс для приложений»).

Если используемый в контейнере сценарий запуска сервиса в /etc/init.d пытается загружать необходимые сервису модули ядра с помощью команды modprobe, он не должен проверять результат загрузки ни через код завершения modprobe, так как modprobe завершится с ошибкой, ни с помощью команды lsmod, так как lsmod выведет пустой список.

Рассмотрим пример использования файловой системы FtpFs внутри контейнера:

  • для организации доступа используется пакет curlftpfs, входящий в большинство дистрибутивов. Этот пакет должен быть инсталлирован внутри контейнера;
  • curlftpfs использует fuse (Filesystem in USErspace) для получения из ядра обращений к файловой системе, которые он преобразует в вызовы библиотеки curl для обращения к FTP-серверу;
  • Fuse состоит из двух компонентов: драйвер файловой системы в ядре и библиотека-диспетчер в пространстве пользователя, которой драйвер передаёт все запросы;
  • драйвер и библиотека обмениваются данными через устройство /dev/fuse;
  • хотя программы и библиотеки запускаются внутри контейнера, драйвер и средства управления им должны быть инсталлированы в хост-системе;
  • каталог /dev в хост-системе и каталог /dev в контейнере – это разные каталоги; драйвер создаёт /dev/fuse в хост-системе и, чтобы /dev/fuse стал доступен в контейнере, требуется специальное указание.

Таким образом, настройка сводится к следующим шагам:

  • в контейнере инсталлируется curlftpfs. Вместе с ним автоматически установятся libfuse и libcurl, от которых он зависит;
  • в /etc/modules хост-системы вручную добавляется строка «fuse», чтобы драйвер, хранящийся в данном модуле ядра, автоматически загружался при старте системы;
  • альтернативно – во внешней системе инсталлируется пакет fuse; входящий в него сценарий /etc/init.d/fuse обеспечивает корректную загрузку драйвера,
  • для немедленного запуска драйвера выполняется команда «modprobe fuse» или «/etc/init.d/fuse start»,
  • созданный драйвером файл /dev/fuse копируется из внешней системы в контейнер:
    vzctl set 11 --devnodes fuse:rw --save
  • благодаря «—save» в /etc/vz/conf/11.conf добавится строка «DEVNODES=»fuse:rw «», следуя которой OpenVZ будет автоматически создавать /dev/fuse внутри контейнера при его запуске.

Virtuozzo

OpenVZ разрабатывается фирмой Parallels как часть более крупного коммерческого продукта под названием Parallels Virtuozzo Containers или PVC (ранее называвшегося просто Virtuozzo). В число преимуществ Virtuozzo, по сравнению с OpenVZ, входят:

  • файловая система VZFS;
  • управление через графическую консоль и Web-интерфейс;
  • программный интерфейс на базе XML для создания собственных инструментов управления и контроля;
  • средства миграции с физической системы в контейнер и обратно;
  • средства контроля за полосой и суммарным потреблением трафика;
  • интеграция с Plesk, коммерческой панелью управления хостингом той же фирмы;
  • круглосуточная техническая поддержка.

VZFS позволяет совмещать файловые системы контейнеров, при этом базовый образ используется всеми контейнерами, а изменения в нём для каждого контейнера сохраняются раздельно (аналог UnionFS). Преимущества такого подхода:

  • место, занимаемое программами на диске, становится фиксированным и не зависит от количества контейнеров, в которых эти программы инсталлированы;
  • уменьшается расход ОЗУ, так как код нескольких экземпляров программы или библиотеки, запущенной из одного и того же исполняемого файла, размещается в ОЗУ в единственном экземпляре;
  • обновление программного обеспечения в группе контейнеров выполняется одной командой.

Термины и сокращения

  • HN, Hardware Node – хост-система, физический компьютер с непосредственно инсталлированной на него операционной системой, служащие платформой для запуска виртуальных окружений;
  • VE, Virtual Environment – виртуальное окружение, имитирующее отдельный компьютер и/или отдельную операционную систему за счёт части ресурсов настоящего компьютера и запущенной на нём ОС;
  • CT, Container – более современный синоним VE;
  • VEID и CTID – числовой идентификатор контейнера, используемый для управления им;
  • CT0 и VE0 – синоним хост-системы;
  • UBC, User Beancounters – набор ограничений на потребление системных ресурсов, назначаемый контейнеру;
  • VPS, Virtual Private Hosting, виртуальный приватный хостинг – хостинг с поддержкой одной операционной системы (а также, возможно, единственного набора программ), в котором виртуализируется программное окружение. Ядро ОС запущено в единственном экземпляре, доступа к нему клиенты-владельцы виртуальных окружений не имеют;
  • VDS, Virtual Dedicated Hosting, виртуальный выделенный хостинг – хостинг с поддержкой различных операционных систем, в котором виртуализируется аппаратное окружение. В каждой виртуальной среде загружается своё ядро, доступное для управления клиенту-владельцу данной среды.

Заключение

Простая в установке и использовании производительная система Linux-виртуализации OpenVZ полезна не только для организации хостинга, но и для небольших Linux-серверов, так как повышает безопасность и упрощает обслуживание таких систем. С ее помощью администратор может, например, изолировать от основной системы потенциально уязвимые сервисы.