Интернет магазин китайских планшетных компьютеров

Компьютеры - OpenVZ - Ядро

Ядро OpenVZ — это модифицированное ядро Linux, добавляющее концепцию виртуальной среды. Ядро обеспечивает виртуализацию, изоляцию, управление ресурсами и чекпоинтинг.

Версии

Ядра

На данный момент поддерживается четыре ветки OpenVZ-ядер:

• ovzkernel-2.6.9-023stab052.4 — основанная на патчсетах RHEL4 ядро. Стабильное, рекомендовано для промышленного использования, поддерживаемое.
• ovzkernel-2.6.18-194.8.1.el5.028stab070.4 — основанная на патчсетах RHEL5.5 ядро. Стабильное, рекомендовано для промышленного использования, поддерживаемое. Основное
• kernel-2.6.27-kuindzhi.1 — основанная на ванильном ядре 2.6.27. Нестабильное ядро, не рекомендовано для промышленного применения, поддерживаемое. Версии ветки именуются в честь русских художников.
• kernel-2.6.32-dobrovolskiy.1 — основанная на ванильном ядре 2.6.32. Нестабильное ядро. Версии ветки именуются в честь русских космонавтов.

Комплект пользовательских утилит

Основными утилитами являются:

• vzctl — Основная утилита для управления контейнерами. Применяется для создания, удаления, запуска, остановки и перезапуска контейнеров, а также для применения новых параметров.

Последняя версия vzctl-3.0.24.2. В состав пакета также входят vzlist, vzmigrate, vzcalc, vzcfgvalidate, vzmemcheck, vzcpucheck, vzpid, vzsplit и некоторые другие, менее значимые утилиты.

• vzlist — Печатает листинг контейнеров. Поддерживает выборки по различным параметрам контейнеров и их комбинациям.
• vzmigrate — Утилита для offline и online миграции.
• vzcfgvalidate — Проверяет верность конфигурационного файла контейнера.
• vzmemcheck, vzcpucheck, vzcalc — Служат для получения информации об используемых ресурсах.
• vzsplit — Служит для генерации конфигурационных файлов контейнеров. Позволяет «разделить» физический сервер на указанное число частей.
• vzpid — Позволяет определить, какому контейнеру принадлежит процесс. В качестве параметра принимает pid-номер процесса.
• vzquota — Утилита для работы с дисковой квотой контейнера. Текущая версия: vzquota-3.0.12-1.

Так же существует ряд утилит либо не поддерживаемых официально, либо «заброшенных»:

• vzdump — Неофициальная утилита для создания backup’ов контейнеров. Поддерживает «горячее» создание копий.
• vzrpm, vzyum, vzpkg — утилиты для работы с HardwareNode с пакетной системой гостевого окружения и темплейтами.
• vzpkg2 — Форк vzpkg, поддерживает менеджмент RedHat-based и Debian-based гостевых окружений. По всей видимости, проект заброшен.

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

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

Файлы

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

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

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

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

VE видит только свои собственные процессы. Идентификаторы процессов также виртуализованы, поэтому PID программы init — 1, как и должно быть.

Сеть

Виртуальное сетевое устройство, позволяющая VE иметь свои собственные адреса IP, а также наборы правил маршрутизации и файрволла.

Устройства

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

Объекты IPC

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

И так далее и тому подобное…

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

Управление ресурсами в OpenVZ состоит из трёх компонентов: двухуровневая дисковая квота, честный планировщик процессора, и так называемые юзер бинкаунтеры. Эти ресурсы могут быть изменены во время работы VE, перезагрузка не требуется.

Двухуровневая дисковая квота

Администратор OpenVZ сервера может установить дисковые квоты на VE, в терминах дискового пространства и количества айнодов. Это первый уровень дисковой квоты.

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

Честный планировщик процессора

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

Администратор OpenVZ сервера может устанавливать различные значения cpuunits для разных VE, и процессорное время будет распределяться соответственно соотношению этих величин назначенных для VE.

Также имеется параметр ограничения — cpulimit, устанавливающий верхний лимит процессорного времени в процентах, отводимый для определенной VE.

User Beancounters

User Beancounters — это набор счётчиков, ограничений и гарантий на каждую VE. Имеется набор из примерно 20 параметров, которые выбраны для того, чтобы покрыть все аспекты работы VE так, чтобы никакая VE не могла злоупотребить каким-либо ресурсом, который ограничен для всего сервера, и таким образом помешать другим VE.

Ресурсы, которые считаются и контролируются — это, в основном, оперативная память и различные объекты в ядре, например, разделяемые сегменты памяти IPC, сетевые буферы и т. п. Каждый ресурс можно посмотреть в файле /proc/user_beancounters — для него есть пять значений: текущее использование, максимальное использование, барьер, лимит и счётчик отказов. Смысл барьера и лимита зависит от параметра; вкратце, о них можно думать как о мягком лимите и жёстком лимите. Если какой-либо ресурс пытается превысить лимит, его счётчик отказов увеличивается — таким образом, владелец VE может видеть, что происходит, путём чтения файла /proc/user_beancounters в своём VE.

Чекпоинтинг и миграция на лету

Функциональность миграции «на лету» и чекпоинтинга была выпущена для OpenVZ в середине апреля 2006. Она позволяет переносить VE с одного физического сервера на другой без необходимости останавливать/перезапускать VE. Этот процесс называется чекпоинтинг: VE «замораживается» и её полное состояние сохраняется в файл на диске. Далее этот файл можно перенести на другую машину и там «разморозить» VE. Задержка этого процесса — примерно несколько секунд; важно подчеркнуть, что это задержка в обслуживании, а не отказ в обслуживании.

Начиная с версии 2.6.24, в ядро включены pid namespaces, вследствие чего миграция «на лету» становится «безопасной», так как в этом случае 2 процесса в разных VE смогут иметь один и тот же pid.

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

Эта возможность делает реальными такие сценарии, как апгрейд сервера без необходимости его перезагрузки: к примеру, если вашей СУБД нужно больше памяти или более мощный процессор, вы покупаете новый более мощный сервер и мигрируете VE с СУБД на него, а потом увеличиваете лимиты на эту VE. Если вам нужно добавить оперативной памяти в сервер, вы мигрируете все VE с этого сервера на другой, выключаете сервер, устанавливаете дополнительную память, запускаете сервер и мигрируете все VE обратно.