Краткое введение в OpenVZ¹

Различные технологии виртуализации позволяют запускать на одном сервере несколько в той или иной степени независимых экземпляров операционной системы (или даже разных операционных систем). Системы виртуализации различаюются как степенью изоляции выполняющихся операционных систем, так и другими особенностями и ограничениями. В дистрибутивах ALT Linux в качестве технологии виртуализации используется OpenVZ.

OpenVZ является реализацией виртуализации на уровне операционной системы (подобно, например, технологии jail, доступной в ОС FreeBSD). Все запущенные с её помощью экземпляры операционной системы (далее виртуальные контейнеры) используют один общий экземпляр ядра Linux. Это способствует повышению производительности по сравнению с технологиями, основанными на полной виртуализации оборудования, а также даёт администратору основной системы дополнительные возможности по контролю и управлению виртуальными контейнерами.

Минусом этой технологии является невозможность использования в разных виртуальных контейнерах операционных систем, не основанных на ядре Linux, а также разных версий ядра.

Система OpenVZ использует модифицированное ядро, обеспечивающее виртуализацию, изоляцию, управление ресурсами, сохранение состояний виртуальных серверов.

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

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

Файлы

Системные библиотеки, приложения, виртуализованные файловые системы /proc и /sys, виртуализованные блокировки и т. п.

Пользователи и группы

Свои собственные пользователи и группы, включая root.

Дерево процессов

Виртуальный контейнер имеет доступ только к своим собственным процессам (начиная с init). Идентификаторы процессов (PID) также виртуализованы, поэтому PID программы init равняется 1, как ему и следует быть.

Сеть

Виртуальное сетевое устройство (venet) обеспечивает наличие виртуальной сети в пределах физического сервера. Каждый виртуальный контейнер может иметь свой набор правил фильтрации пакетов.

Устройства

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

Объекты IPC

Разделяемая память, семафоры, сообщения.

Управление ресурсами

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

Основными компонентами управления ресурсами в OpenVZ являются: двухуровневая дисковая квота, специальный планировщик процессора, ограничения (user beancounters) и дополнительные полномочия (capabilities). Все эти ресурсы могут быть изменены во время работы виртуального сервера без перезагрузки.

Использование диска

Администратор физического сервера может установить для виртуальных серверов дисковые квоты, в терминах дискового пространства и количества индексных узлов (i-nodes), число которых примерно равно количеству файлов. Это верхний уровень дисковой квоты.

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

Работая внутри контейнера, можно определить объем доступного ему дискового пространства, выполнив следующие команды:

# echo "simfs / simfs rw 0 0" >>/etc/mtab
$ df -h

Одной из не всегда очевидных проблем при планировании ресурсов является дисковый ввод/вывод. При создании нагруженного сервера с обширным вводом/выводом в различных контейнерах следует помимо общей практики использования RAID1+ для повышения надёжности множества сервисов на одной системе по возможности применять разнесение потоков данных по различным физическим дискам².

Например, практически возможно использование одного физического сервера как терминального (LTSP) и для сборки программных пакетов (hasher) при условии, что терминал-сервер и пакетные базы размещены на программном RAID1, а сборка ведётся на отдельном SCSI-диске; иначе даже существенный объём RAM (например, 4Gb) не поможет избежать заметного взаимного влияния контейнеров при дисковых операциях.

Планировщик процессора

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

Администратор физического сервера может устанавливать количество процессорного времени, выделяемого каждому виртуальному серверу, как на основании системы весов (cpuunits), так и задавая явные пределы (cpulimit).

Ограничения

OpenVZ предоставляет для каждого виртуального контейнера набор счётчиков, ограничений и гарантий. Имеется набор из примерно 20 параметров, которые выбраны таким образом, чтобы никакой виртуальный контейнер не мог злоупотребить каким-либо ресурсом, и таким образом помешать работе других виртуальных контейнеров на этом же физическом сервере. Смысл порогового и максимального значений может различаться в зависимости от параметра.

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

# cat /proc/user_beancounters >~/user_beancounters.`date "+%Y%m%d-%H%M"`

Затем повторить операцию, которая привела к ошибке, и снова снять показания счётчиков. Затем их нужно сравнить и выяснить, какой из счётчиков failcnt увеличил значение — соответствующий лимит нужно будет увеличить. Краткое пояснение смысла разных лимитов приведено ниже, более подробную информацию можно найти в man vzctl. Нужно также принимать во внимание, что некоторые лимиты установлены в блоках (обычно 512 байт), некоторые — в страницах памяти (4 Кб на x86 архитектуре), некоторые в байтах и других натуральных величинах.

Память

kmemsize

Количество памяти, используемое ядром. Этот параметр связан со значением параметра numproc Каждый процесс потребляет некоторое количество памяти ядра: 30–50 килобайт, как минимум 16. Важно иметь достаточно большой зазор между пороговым и максимальным значениями, чтобы не вынуждать ядро завершать процессы, выполняющиеся в виртуальном окружении.

lockedpages

Количество страниц памяти, заблокированной при помощи mlock.

privvmpages

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

shmsize

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

physpages

Объём физической памяти, используемое виртуальным контейнером. Используется только для учёта, пороговое значение должно быть выставленно в 0.

vmguarpages

Гарантированный размер доступной памяти в страницах. Имеет смысл изменять только пороговое значение.

oomguarpages

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

Процессы и файлы

numproc

Количество процессов и обеспечиваемых ядром потоков. Установка порогового значения, отличающегося от максимального, не имеет смысла.

numflock

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

numpty

Количество псевдотерминалов. Не может превышать 255. Установка порогового значения, отличающегося от максимального, не имеет смысла.

numsiginfo

Количество структур siginfo. Установка порогового значения, отличающегося от максимального, не имеет смысла.

dcachesize

Максимальный размер кешей файловой системы (в байтах). Максимальное значение должно быть больше порогового.

numfile

Максимальное количество открытых файлов. Установка порогового значения, отличающегося от максимального, не имеет смысла.

Сеть

numtcpsock

Максимальное количество сокетов протокола TCP. Установка порогового значения, отличающегося от максимального, не имеет смысла.

tcpsndbuf

Максимальный размер буферов для данных, отправляемых по протоколу TCP. Пороговое значение не должно быть меньше 64 Кб, а разница между ним и максимальным значением не должна быть меньше значения numtcpsock, умноженного на 2,5.

tcprcvbuf

Максимальный размер буферов для данных, получаемых через протокол TCP. Пороговое значение не должно быть меньше 64 Кб, а разница между ним и максимальным значением не должна быть меньше значения numtcpsock, умноженного на 2,5.

othersockbuf

Максимальный размер прочих (не TCP) буферов отправки. Увеличение лимита ускоряет связь через локальные сокеты.

dgramrcvbuf

Максимальный размер прочих (не TCP) буферов получения. Установка порогового значения, отличающегося от максимального, не имеет смысла.

numothersock

Максимальное количество не-TCP сокетов (локальных, UDP и других). Установка порогового значения, отличающегося от максимального, не имеет смысла.

numiptent

Макисмальное количество записей в таблицах фильтрации сетевых пакетов (iptables).

Дополнительная информация

• Официальный сайт проекта http://openvz.org
• Вики разработчиков и пользователей OpenVZ http://wiki.openvz.org
• Форум проекта http://forum.openvz.org
• Рекомендации по настройке OpenVZ в ALT Linux http://www.freesource.info/wiki/AltLinux/Dokumentacija/OpenVZ