Утилита управления 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-серверов, так как повышает безопасность и упрощает обслуживание таких систем. С ее помощью администратор может, например, изолировать от основной системы потенциально уязвимые сервисы. Надеемся, наши статьи помогут читателям в их повседневной работе.

Об авторе