Виртуализация на уровне операционной системы

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:22, 1 мая 2016.

Виртуализация на уровне операционной системы (контейнерная виртуализация) — метод виртуализации, при котором ядро операционной системы поддерживает несколько изолированных экземпляров пространства пользователя, вместо одного. Эти экземпляры (часто называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны реальному серверу. Для систем на базе UNIX, эта технология может рассматриваться как улучшенная реализация механизма chroot. Ядро обеспечивает полную изолированность контейнеров, поэтому программы из разных контейнеров не могут воздействовать друг на друга.

История контейнеров

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

Поэкспериментировав с традиционной виртуализацией, сотрудники Google сочли ее не подходящей для решения этой задачи. Главной проблемой стали слишком большие потери производительности (слишком низкая плотность) и недостаточно эластичный отклик для динамического переконфигурирования системы под изменившуюся нагрузку для массового предоставления Web-сервисов.

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

В то же самое время одна группа разработчиков экспериментировала с Linux и концепцией, основанной на механизме cgroups — так называемые контейнеры процессов. Google наняла этих специалистов для работы над контейнеризацией своих ЦОД с целью решения проблемы эластичности при масштабировании. В январе 2008 года часть технологии cgroup, используемой Google, была перенесена в ядро Linux. В 2011 году Google и Parallels пришли к соглашению о сотрудничестве в области контейнерных технологий. Результатом стал релиз ядра Linux версии 3.8, представленный в 2013 году. В нем были объединены все актуальные на тот момент контейнерные технологии для Linux, что позволило избежать повторения болезненного разделения ядер, как в случае с KVM и Xen.

Отличительная особенность

Основное отличие виртуализации на уровне ОС в том, что виртуализируется не компьютер и не операционная система, а пользовательское окружение ОС. Эти экземпляры пользовательского окружения, называемые также контейнерами (рис. 1), полностью идентичны основному серверу и используют общее ядро ОС.

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

Наиболее популярным решением для данного типа виртуализации является OpenVZ и коммерческий продукт на его основе Virtuozzo, последнее время приобретает известность разрабатываемый при поддержке IBM LXC (Linux Containers), на аналогичных принципах работают FreeBSD Jail и Solaris Containers/Zones. Также среди реализаций выделяют:

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

Рис.1. Схема гипервизорной виртуализации
Рис.2. Схема контейнерной виртуализации

Гипервизор работает следующим образом (рис. 1): операционная система хоста эмулирует аппаратное обеспечение, поверх которого уже запускаются гостевые операционные системы. Это означает, что взаимосвязь между гостевой и хостовой операционными системами следует «железной» парадигме: все, что «умеет» делать оборудование, должно быть доступно гостевой ОС со стороны хостовой. Напротив, контейнеры (рис. 2) — это виртуализация на уровне операционной системы, а не оборудования. Отсюда вытекает преимущество: они меньше и компактнее гипервизорных гостевых сред, поскольку у них с хостом гораздо больше общего.

Далее, контейнеры — это всего лишь управляемые ресурсы. К примеру, когда Контейнер 1 и Контейнер 2 работают с одним и тем же файлом, ядро хоста открывает этот файл и размещает страницы из него в страничный кэш ядра, которые затем передаются Контейнеру 1 и Контейнеру 2: если оба «хотят» прочитать одни и те же данные, они получают одну и ту же страницу. Если же гипервизорным виртуальным машинам VM1 и VM2 надо выполнить такую же операцию, то сначала сам хост открывает запрашиваемый файл (создавая страницы в своем страничном кэше), а затем еще и каждое из ядер VM1 и VM2 выполняет аналогичное действие. Таким образом, в процессе чтения машинами VM1 и VM2 одного и того же файла в памяти существует целых три одинаковых страницы (по одной в страничном кэше хоста и в ядрах VM1 и VM2), потому что они не «умеют» одновременно использовать одну и ту же страницу, как это делают контейнеры.

Дело даже не столько в «чтении» файлов, сколько в возможности использовать одну копию исполняемых файлов и разделяемых библиотек (shared libs) в разных контейнерах. В обычной системе, если два или более процесса обращаются к одной и той же разделяемой библиотеке (например, libc), ее код присутствует в памяти только в одном экземпляре. Это относится и к исполняемым файлам, и к сегментам немодифицируемых данных, что позволяет существенно снизить требования к размеру оперативной памяти. Так как контейнеры используют единое ядро, вышеописанный механизм при некоторых условиях распространяется и на них, что приводит, в частности, к повышению плотности их размещения, которая и без этого механизма изначально выше, чем у виртуальных машин, поскольку отсутствуют множественные копии ядра.

В результате у контейнеров плотность (количество виртуальных сред, которые можно запустить на сервере) может быть до трех раз выше, чем у виртуальных машин, а на одном сервере вполне может размещаться несколько сотен контейнеров. Столь высокая плотность — одна из главных причин популярности контейнеров на рынке хостинга виртуальных выделенных серверов (VPS). Если на одном и том же сервере можно создать в три раза больше VPS, то в расчете на один VPS затраты снижаются на 66%, что для такого низкомаржинального бизнеса, как хостинг, иногда равно разнице между убыточностью и прибыльностью.

Основные преимущества контейнерной виртуализации

  • Контейнеры выполняются на одном уровне с физическими серверами. Отсутствие виртуализованного оборудования и использование реального оборудования и драйверов позволяют получить непревзойденную производительность.
  • Каждый контейнер может масштабироваться до ресурсов целого физического сервера.
  • Технология виртуализации на уровне ОС позволяет добиться высочайшей плотности (количество выделенных виртуальным ОС ресурсов может в несколько раз превышать ресурсы сервера). Это достигается за счет того, что использование одного экземпляр ядра и общих динамических библиотек позволяет значительно экономить память. Возможно создание и запуск сотен контейнеров на одном обычном физическом сервере.
  • Контейнеры используют единую ОС, что делает их поддержку и обновление очень простым. Приложения могут быть также развернуты в отдельном окружении.

Недостатки контейнерной виртуализации

К недостаткам можно отнести невозможность глубокой настройки или самостоятельной установки ОС, а также использование иной, отличной от хоста, версии операционной системы. По сути каждый контейнер представляет изолированную копию операционной системы хоста с настраиваемым пользовательским окружением и общими базовыми ресурсами (ядро и т.п.).

Ссылки по теме

Примечания