Виртуальная реальность по-русски: Осваиваем виртуализацию уровня ОС на примере OpenVZ. Типы виртуализации: OVZ и KVM

OpenVZ - это реализация технологии виртуализации на уровне операционной системы, которая базируется на ядре Linux. OpenVZ позволяет на одном физическом сервере запускать множество изолированных копий операционной системы, называемых Виртуальные Частные Серверы (Virtual Private Servers, VPS ) или Виртуальные Среды (Virtual Environments, VE ).

Поскольку OpenVZ базируется на ядре Linux, в отличие от виртуальных машин (напр. VMware) или паравиртуализационных технологий (напр. Xen), в роли «гостевых» систем могут выступать только дистрибутивы Linux . Однако, виртуализация на уровне операционной системы в OpenVZ даёт лучшую производительность, масштабируемость, плотность размещения, динамическое управление ресурсами, а также лёгкость в администрировании, чем у альтернативных решений. Согласно сайту OpenVZ, накладные расходы на виртуализацию очень малы, и падение производительности составляет всего 1-3 %, по сравнению с обычными Linux-системами. OpenVZ является базовой платформой для Virtuozzo - проприетарного продукта Parallels, Inc. OpenVZ распространяется на условиях лиценции GNU GPL v.2. OpenVZ состоит из модифицированного ядра Linux и пользовательских утилит.

OpenVZ - это технология ядра Linux, позволяющая запускать несколько виртуальных частных серверов (VPS) на одном физическом компьютере. Каждый из серверов при этом выглядит как отдельный сервер с отдельными доступом root, IP-адресом, таблицей процессов, файловой системой, правилами брандмауэра и т. д. От средств полной виртуализации вроде Xen или VMWare эту программу отличает то, что в каждом экземпляре VPS используется одна и та же разделяемая копия ядра Linux. По этому, например, с OpenVZ нельзя загрузить экземпляр Windows 7 и экземпляр RedHat, и нельзя загружать модули ядра независимо в каждый VPS. Но «пространство пользователя» в каждом VPS может быть разным, поэтому можно, например, запустить CentOS и SUSE рядом на одном и том же ядре. Это эффективное решение, и можно создать достаточно полную иллюзию отдельно администрируемых компьютеров, чтобы удовлетворить пользователей, которые не хотят много платить за хостинг-услуги.

Ядро OpenVZ - это модифицированное ядро Linux, которое обеспечивает виртуализацию, изоляцию, управление ресурсами и чекпоинтинг (сохранение текущего состояния VE).

Утилиты OpenVZ

vzctl - утилита для манипулирования VPS (создание, уничтожение, установка параметров …)

vzquota - утилита для квотирования VPSs. Чаще используется неявно через vzctl.

vzpid - позволяет определить, какому контейнеру принадлежит процесс (в качестве параметра принимает pid процесса).

vzubc - утилита, заменяющая такой инструмент, как cat /proc/user_beancounters.

vzlist - печатает листинг контейнеров.

vzmemcheck, vzcpucheck, vzcalc - служат для получения информации об используемых ресурсах.

vzctl

Запустить контейнер по его имени или CTID: # vzctl start example1 # vzctl start 101

Проверить состояние VE: # vzctl status 101 CTID 101 exist mounted running # vzlist -a CTID NPROC STATUS IP_ADDR HOSTNAME 101 8 running 10.161.85.101 my.example.com

Выполнить в нём одиночную команду: vzctl exec 101 uname -a

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

Сервер OpenVZ

Файловая система . Разбивка HDD на аппаратном узле. Рекомендуется использовать отдельный раздел для хранения данных VE. (по умолчанию /vz/private/). Причина этого в том, что если вы захотите использовать дисковые квоты на каждый VE, используемые OpenVZ, вы не сможете использовать обычные квоты Linux. На том же разделе. В данном контексте OpenVZ-квота не является чистой квотой, она действует как обычная дисковая квота, но в рамках VE, а не аппаратного узла. Квоты OpenVZ поддерживаются только для файловых систем ext2/ext3, если квоты не важны рекомендуется ставить ext4 . Избегайте использовать корневой раздел для хранения данных VE. В такой ситуации администратор VE может превысить дисковый барьер в 5%, полностью заполнить корневой раздел аппаратного узла, и вызвать крах системы.

Точка монтирования	Тип файловой системы	Комментарии
/	ext4	Корневой раздел для файлов ОС аппаратного узла. 8-10 Гб
/swap	swap	Пространство подкачки Linux. 2хОЗУ или 1хОЗУ
LVM - Все свободное место.
LVM /tmp	ext4	/tmp 10GB
LVM /home	ext4	/home 20GB
LVM /vz	ext4	/vz Rest
LVM /noexec	ext4	/vz/noexec 10GB

Выбираем минимальную установку. В руководстве безопасности OpenVZ настоятельно рекомендуется не использовать на уровне аппаратного узла никаких сетевых сервисов кроме sshd (Защита демона sshd).

Доставим дополнительные пакеты # yum install nano mc wget lsof mailx mlocate ntsysv

Установка ядра с поддержкой OpenVZ, для этого добавим официальный репозиторий OpenVZ: # cd /etc/yum.repos.d # wget -P /etc/yum.repos.d/ http://ftp.openvz.org/openvz.repo # rpm --import http://ftp.openvz.org/RPM-GPG-Key-OpenVZ # yum install vzkernel

Редактируем загрузчик ОС в файле menu.lst, в котором ядро с поддержкой OpenVZ должно стоять первым или единственным # cp /boot/grub/menu.lst /boot/grub/menu.lst.bak # nano /boot/grub/menu.lst

Установка инструментов администрирования OpenVZ # yum install vzctl vzquota ploop # shutdown -r now

Настраиваем sysctl : sysctl.conf # On Hardware Node we generally need # packet forwarding enabled and proxy arp disabled net.ipv4.ip_forward = 1 net.ipv6.conf.default.forwarding = 1 net.ipv6.conf.all.forwarding = 1 net.ipv4.conf.default.proxy_arp = 0 # Enables source route verification # Проверка источника включена net.ipv4.conf.all.rp_filter = 1 # Enables the magic-sysrq key kernel.sysrq = 1 # We do not want all our interfaces to send redirects # нам не нужно чтобы ВСЕ интерфейсы перенаправляли трафик net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.all.send_redirects = 0

Запуск # service vz start

Установка VE

Cкачиваем готовые шаблоны для VE: Precreated template caches for different distributions . Также скачиваем контрольные суммы для проверки целостности файлов шаблона (OpenVZ - проверка целостности template). # cd /vz/template/cache/ # wget -c http://download.openvz.org/template/precreated/debian-6.0-x86_64.tar.gz # wget -c http://download.openvz.org/template/precreated/debian-6.0-x86_64.tar.gz.asc # wget -c http://download.openvz.org/template/precreated/contrib/debian-5.0-i386-minimal.tar.gz # wget -c http://download.openvz.org/template/precreated/contrib/debian-5.0-i386-minimal.tar.gz.asc # wget -O - http://download.openvz.org/RPM-GPG-Key-OpenVZ | gpg --import # gpg --verify debian-6.0-x86_64.tar.gz.asc

В OpenVZ существует два основных варианта размещения файлов контейнера, они называются ploop и simfs. Simfs – более старый способ размещения файлов контейнера. При его использовании все файлы находятся в определенном каталоге файловой системы физического узла. Ploop более новый способ, при его использовании все файлы контейнера размещаются в одном отдельном большом файле.

Создание контейнера simfs для debian-5.0-i386-minimal.tar.gz: # vzctl create 101 --ostemplate debian-5.0-i386-minimal --layout simfs CT configuration saved to /etc/vz/conf/101.conf

Выполним настройку контейнера: Включить автоматический запуск виртуального окружения при старте сервера # vzctl set 101 --save --onboot yes --name talk-mss --ipadd 10.161.85.101 --hostname my.example.com --nameserver "208.67.222.222 8.8.4.4"

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

Монтирование разделов в VE

Лимиты VE

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

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

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

# egrep -v " 0$" /proc/user_beancounters

Процессорные лимиты

"Вес" CPU для данного контейнера. Аргументом может быть положительное число в диапазоне от 8 до 500000. Устанавливает зависимость распределения CPU между разными контейнерами. Значение по умолчанию - 1000. Значение 1000 в одном контейнере и 2000 в другом означает, что при прочих равных условиях второй контейнер получит вдвое больше CPU.

–cpulimit num[%]

Лимит использования CPU контейнером. В процентах. Если компьютер имеет два CPU, то это значит он имеет всего 200% CPU, которые можно распределить между контейнерами. Значение по умолчанию - 0 (нет лимита).

Устанавливает количество процессоров (не ядер) доступных в контейнере.

Клонирование VPS сервера

Клонирование VPS сервера на OpenVZ:

Остановим сервер, который будем клонировать # vzctl stop 101

Клонируем конфигурационный файл, в нем как минимум нужно изменить IP до запуска нового VE # cp /etc/vz/conf/101.conf /etc/vz/conf/103.conf

Если используется mount # cp /etc/vz/conf/101.mount /etc/vz/conf/103.mount # mkdir /vz/noexec/vz-103-home

Клонируем сервер копированием при помощи утилиты Использование rsync в примерах , ключ -а позволяет сохранить права на файлы и указывает на рекурсивное копирование, слеш "/" в конце директории, указывает, что мы ее копируем. # rsync -av /vz/private/107/ /vz/private/108 # rsync -av /vz/noexec/vz-107-home/ /vz/noexec/vz-108-home

Для переноса VE между серверами можно использовать утилиту tar с ключом -p, который позволяет сохранить права на файлы. Например: на первом хосте # cd /vz/private/ # tar -cpvf 109-mb3_3.tar 109/

Любым способом копируем на второй хост и на нем запускаем

# cd /vz/private/ # tar -xvpf 109-mb3_3.tar

FAQ

Как включить в VE OpenVZ запись истории команд bash?

Как включить в VE OpenVZ запись истории команд пользователя, которые отображаются командой history в консоли? (No bash history in VE). По умолчанию в bash всё пишется в файл ~/.bash_history. Если хотим хранить историю в другом файле, то нужно в.bashrc, задать команду HISTFILE=~/.my_history. Выясним в какой файл записывается история в нашем VE # env | grep -i HISTFILE HISTFILE=/dev/null

И видим что история сразу затирается. Редактируем файл и задаем параметр HISTFILE глобально /etc/bash.bashrc или в.bashrc пользователя)

HISTSIZE - определяет число строк, хранящихся в списке истории (в памяти интерпретатора).

HISTFILESIZE - максимальное количество команд хранящихся в файле истории.

Dnsmasq в контейнере OpenVZ

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

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

USB устройство в VE

Задача . Сделать доступным в VE подключенный USB ключ (на флешке лицензия).

Вывести список USB устройств. Нас интересуется флешка вставленная в Bus 006 Device 002 # lsusb Bus 004 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse Bus 006 Device 002: ID 04b9:0300 SafeNet USB SuperPro/UltraPro

Подробности об устройстве: # ls -al /dev/bus/usb/006/002 crw-rw-r-- 1 root root 189, 641 Ноя 27 09:10 /dev/bus/usb/006/002

Войдем в VE и создадим это устройство в нем (mknod) # vzctl enter VEID # mkdir -p /dev/bus/usb/006 # cd /dev/bus/usb/006 # mknod 002 c 189 641

В конфигурационный файл /etc/vz/conf/VEID.conf добавим строку DEVNODES="bus/usb/006/002:rw "

Перезагрузим VE и проверим видимость USB ключа в VE # vzctl restart VEID # vzctl enter VEID # lsusb Bus 006 Device 002: ID 04b9:0300 SafeNet USB SuperPro/UltraPro

Установка tun/tap для OpenVPN на OpenVZ VE

По умолчанию запрещено использование этих виртуальных драйверов.

Загрузим модуль tun в HN: modprobe tun

проверим

Lsmod | grep tun

Выясним параметры устройства tun в HN для использования в mknod VE ls -la /dev/net/tun crw-rw-rw- 1 root root 10, 200 Авг 27 08:26 /dev/net/tun

Включаем поддержку на самом VE сервере (111 - номер VE сервера) vzctl set 111 --devnodes net/tun:rw --save vzctl set 111 --devices c:10:200:rw --save vzctl set 111 --capability net_admin:on --save vzctl exec 111 mkdir -p /dev/net vzctl exec 111 chmod 600 /dev/net/tun

Перезагрузите VE сервер vzctl restart 111

VE маршрутизация 2 сетевых интерфейсов

В случае когда VE OpenVZ два и более сетевых интерфейса, например venet0:0 и venet0:1 может возникнуть проблема прохождения пакетов между HN OpenVZ, то есть не в пределах одного сервера OpenVZ (где все они соединены через интерфейс venet0), а между двумя и более HN OpenVZ. Самое простое решение использовать NAT на HW, но тогда будет подменяться IP, что не всегда нужно. Втрое решение исправить в VE изменить маску сети на /24

Ifconfig venet0:1 netmask 255.255.255.0

Более подробно решение проблемы здесь: OpenVZ multiple networks on CTs . Можно также запускать эту команду при помощи файла /etc/rc.local

/sbin/ifconfig venet0:1 netmask 255.255.255.0

или для CentOS создать выполняемый файл /sbin/ifup-local. Для добавления маршрута на новую сеть (например 10.26.95.0/24) в VE обязательно нужно указать источник src .

ifup-local #!/bin/bash / sbin/ ifconfig venet0:1 netmask 255.255.255.0 / sbin/ ip route add 10.26.95.0/ 24 dev venet0:1 src 10.161.85.112

Резервное копирование контейнеров OpenVZ

Физически файлы контейнера просто находятся в некоторой директории на HN. При запуске VE эта директория монтируются в другую, посредством механизмов, напоминающих mount –bind и последующий chroot. Т.е. для резервного копирования достаточно скопировать или архивировать эту директорию. Т.к. контейнер может быть запущен либо остановлен, то и резервное копирование может быть выполнено «горячее», либо «холодное». При горячем копировании может произойти порча структуры файлов, которые не были закрыты запущенными в контейнере программами. Особенно это чревато для баз данных. По этому этот метод нужно использовать очень осторожно. Этих недостатков лишено холодное копирование, но для него необходимо остановить контейнер, что не всегда приемлемо, да и вообще не хорошо вмешиваться в работу VE.

Для осуществление живой миграции контейнеров между HN у OpenVZ есть специальное состояние - checkpoint . При входе в это состояние все процессы контейнера замораживаются и содержимое памяти сбрасывается в дамп. Сохраняется также ядерная информация (например, о состоянии открытых сокетов). После перемещения файлов и дампа памяти VE на другой HN можно его там «оживить». Если промежуток времени от заморозки до оживления составляет единицы-десятки секунд, то приложения могут даже не заметить перемещения контейнера, а сетевые клиенты могут не отключиться.

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

Данный метод позволяет сократить время простоя виртуальной машины до минимума.** При использовании данного метода, наиболее полезны опции: –stdexcludes - позволяет исключить временные файлы (/tmp и т.д.) –exclude-path - позволяет исключить определенные директории. Адреса директорий задаются с помощью regexp. modprobe vzcpt vzdump --suspend 121 --mailto root vzdump --compress --suspend 121 --mailto root

Возможные проблемы: ERROR: Backup of VM 121 failed - command "vzctl --skiplock chkpnt 121 --suspend" failed with exit code 16

Исправить

Modprobe vzcpt

Восстановить VE с другим CTID vzrestore / vz/ dump/ vzdump-openvz-121 -2016 _02_09-12 _27_09.tgz 123

OpenVZ - контейнерная система виртуализации для Linux. Мы можем создать n-ое количество виртуальных машин, в зависимости от конфигурации нашей реальной машины. Каждая виртуальная машина будет работать как отдельная автономная система и не будет конфликтовать с другими машинами.

Созданные с помощью OpenVZ машины могут быть перезагружены независимо одна от одной, могут иметь разных пользователей, IP адреса, память, процессы, файлы, приложения, библиотеки и настройки. Так как используется виртуализация на уровне ОС, в отличие от VirtualBox Vmware и KVM, гостевые системы будут использовать одно и то же ядро - хост системы.

Это позволяет каждой машине наиболее эффективно работать с системными ресурсами: памятью, процессором, дисковым пространством и сетью. В этой инструкции будет рассмотрена установка OpenVZ на Ubuntu 16.04.

Системные требования:

Intel совместимый или AMD процессор;
Как минимум 128 Мб оперативной памяти;
Минимум 4 ГБ свободного места на диске;
Подключение к интернет;

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

Добавим репозиторий OpenVZ в систему:

cat << EOF > /etc/apt/sources.list.d/openvz-rhel6.list
deb http://download.openvz.org/debian wheezy main
# deb http://download.openvz.org/debian wheezy-test main
EOF

Импортируем OpenVZ GPG ключ для репозитория:

wget http://ftp.openvz.org/debian/archive.key

apt-key add archive.key

Обновим списки пакетов:

apt-get install linux-image-openvz-amd64

Или для i386:

apt-get update && apt-get install linux-image-openvz-686

Настроем параметры нового ядра:

Включаем форвардинг пакетов и отключаем прокси
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

# включаем magic-sysrq
kernel.sysrq = 1

# Разрешаем использовать редиректы для сетевых интерфейсов
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

Затем установим утилиты для контроля и статистики OpenVZ:

apt-get install vzctl vzquota ploop vzstats

Установка OpenVZ на Ubuntu 16.04 завершена. Теперь можно перезагрузить компьютер и загрузится с ядром OpenVZ Ubuntu, Пункт меню Ubuntu with openvz можно найти в подменю Advanted options for Ubuntu:

Теперь вы готовы создавать и управлять виртуальными машинами в OpenVZ.

Создание виртуальных машин OpenVZ

Создадим нашу первую виртуальную машину. Для этого существует утилита vzctl. Выполните команду:

sudo vzctl create 1 --ostemplate debian-7.0-x86_64 --config vswap-2g

Здесь 1, это уникальный номер виртуальной машины, --ostemplate указывает шаблон дистрибутива, который будет загружен и распакован, в нашем случае это Debian 7. Опция --config задает конфигурационный файл, в котором указаны все настройки машины. Конфигурационные файлы лежат в каталоге /etc/vz/conf/.

Настраивать OpenVZ в Ubuntu будем с помощью утилиты vzctl. Сначала добавим старт при загрузке:

sudo vzctl set 1 --onboot yes --save

Зададим имя хоста:

sudo vzctl set 1 --hostname debian7.example.com - save

Установим IP адрес и DNS сервера:

sudo vzctl set 1 --save --ipadd 192.168.1.2

$ sudo vzctl set 1 --save --nameserver 8.8.8.8

Количество используемых ядер:

sudo vzctl set 1 --save --cpus 4

Доступное количество оперативной памяти:

sudo vzctl set 1 --save --ram 1G

Размер раздела подкачки:

sudo vzctl set 1 --save --swap 4G

Доступное дисковое пространство:

sudo vzctl set 1 --save --diskspace 100G

Готово. С настройкой OpenVZ Ubuntu завершили, теперь запускаем машину:

sudo vzctl start 1

И устанавливаем пароль:

sudo vzctl exec 1 passwd

Готово. Машина работает и вы уже можете ее использовать. При указании ip адреса для виртуальной машины убедитесь, что для физической и виртуальной машины используется одна и та же подсеть. Если хотите использовать другую подсеть нужно отредактировать файл /etc/vz/vz.conf:

vi /etc/vz/vz.conf

Раскомментируйте строчку:

NEIGHBOUR_DEVS=detect

И измените ее на:

NEIGHBOUR_DEVS=all

Выводы

Вот и все. Теперь вы знаете как выполняется установка openvz на ubuntu 16.04. Для меня настройка OpenVZ показалась намного проще чем те же самые LXC контейнеры. Если у вас остались вопросы, спрашивайте в комментариях!

Часть 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

Лимиты

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

egrep -v " 0$" /proc/user_beancounters

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

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

Ресурсы для скачивания

static.content.url=http://www.сайт/developerworks/js/artrating/

ArticleID=472857

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

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

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

Сравнение типов виртуализаций

OpenVZ	KVM
ОС из ряда предложенных: Debian, CentOS, Ubuntu	Linux, Windows, FreeBSD, установка собственного дистрибутива
Изменение ресурсов без перезагрузки (жёсткий диск, память, процессор)	Память и процессор изменятся после перезагрузки, жёсткий диск - только после обращения в поддержку (на готовых тарифах память изменить нельзя)
Смена тарифного плана без перезагрузки	Смена тарифного плана . Сервер будет недоступен 1-2 часа.
Мягкие лимиты: максимальная производительность сервера может отклоняться в большую или меньшую сторону	Жёсткие лимиты: каждый сервер получает заявленные ресурсы
Ограничение на запуск высоконагруженных проектов. Запрещено запускать Java-приложения, массовые рассылки и проксировать трафик. TUN/TAP выключен.	Возможность запуска любых проектов (кроме систем распределённых вычислений)

Виртуализация OpenVZ

OpenVZ - виртуализация уровня операционной системы. Технология базируется на ядре ОС Linux и позволяет на одном физическом сервере создавать и запускать изолированные друг от друга копии выбранной операционной системы (Debian, CentOS, Ubuntu). Установка другой ОС невозможна, так как виртуальные серверы используют общее ядро Linux.

Технология отличается легкостью управления сервером: пользователь может в личном кабинете самостоятельно добавить количество ресурсов (память, процессор, жесткий диск) или перейти на другой тариф с той же виртуализацией. Изменения ресурсов применяются автоматически, без перезагрузки сервера.

На серверах с виртуализацией OpenVZ запрещается запускать:

сервисы для организации проксирования любого вида трафика
сервисы потокового вещания
игровые серверы
системы или элементы систем распределённых вычислений (например, bitcoin mining)
сервисы массовой рассылки почтовых сообщений, даже если они используются в легальных целях
Java-приложения
иные ресурсоёмкие приложения

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

Виртуализация KVM

KVM (Kernel-based Virtual Machine) - технология аппаратной виртуализации, позволяющая создать на хост-машине полный виртуальный аналог физического сервера . KVM позволяет создать полностью изолированный от «соседей» виртуальный сервер с собственным ядром ОС, который пользователь может настраивать и модифицировать под собственные нужды без ограничений. Каждому такому серверу выделяется своя область в оперативной памяти и пространство на жестком диске, что повышает общую надежность работы такого сервера.

Возможна установка любой операционной системы на выбор (Debian, CentOS, Ubuntu, FreeBSD, Windows Server), либо установка собственного дистрибутива (в панели VMmanager в разделе ISO-образы нажмите кнопку Создать и добавьте свой ISO-образ системы).

Смена тарифного плана возможна только в большую сторону и только в рамках базовой линейки тарифов (Старт, Разгон, Отрыв, Улёт). Если ваш проект «вырастет» из тарифа, напишите запрос в поддержку из Личного кабинета - администраторы сменят тариф на требуемый бесплатно. Изменить тариф в меньшую сторону можно только переносом на новый сервер. Закажите новый сервер и перенесите данные самостоятельно, либо специалисты технической поддержки помогут с переносом за 1 обращение по пакету администрирования или 250 руб.

Помните, что на тарифах VDS-Форсаж и VDS-Атлант , вы можете изменять ресурсы вместо смены тарифа : количество доступных ядер процессора и оперативной памяти самостоятельно в панели управления, а размер жёсткого диска - после обращения в поддержку (в рамках администрирования или за 250 руб.).

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

На серверах с виртуализацией KVM Абоненту запрещается размещать системы или элементы систем распределённых вычислений (например, bitcoin mining ).