Форма входа

Логин:
Пароль:

Поиск

Наши координаты

Телефон:
+7 (913) 229 5479
Адрес:
г. Барнаул
пр. Строителей, 16, оф. 613
Почтовый адрес:
656067, Алтайский край, г.Барнаул, 67 отделение связи,
а/я 4180
E-mail:
support@oit-company.ru

Наши партнёры





Вторник, 25.07.2017, 11:41
Приветствуем Вас Гость
Регистрация | Вход | RSS

ОТДЕЛ
ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
 
Каталог статей


Главная » Статьи » Интересные статьи

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


Об авторе

В сфере IT с 1986 года. Работает системным администратором в компании "Икс-Трим” (Интернет и домашние сети). Основные рабочие инструменты на данный момент: Perl, ALT Linux и FreeBSD. Занятие в свободное время (когда оно есть) - борьба с газоскрёбами.

Источник



Категория: Интересные статьи | Добавил: sashacd (09.03.2010)
Просмотров: 1539 | Комментарии: 1 | Рейтинг: 0.0/0 |
Всего комментариев: 0
Имя *:
Email *:
Код *:

Copyright ООО "Отдел Информационных Технологий" © 2017