Xen
[править]
Материал из Википедии — свободной энциклопедии
Xen — кросс-платформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета и распространяемый на условиях лицензии GPL.
Основные особенности: поддержка режима паравиртуализации помимо
аппаратной виртуализации, минимальность кода самого гипервизора за счёт
выноса максимального количества компонентов за пределы гипервизора.
[править] Области применения
Технология виртуальных машин позволяет расширить функциональность оборудования следующими способами:
- Виртуальная машина обладает производительностью, сравнимой с реальной.
- Возможность миграции запущенной виртуальной машины между физическими машинами.
- Хорошая поддержка оборудования (поддерживается большинство драйверов устройств Linux)
- Возможность создания песочницы, перезагружаемые драйверы устройств.
[править] Терминология
Основной концепцией гипервизора является домен. Доменом
называется запущенная копия виртуальной машины. Если виртуальная машина
перезагружается, то её домен завершается (в момент перезагрузки) и
появляется новый домен. Более того, даже при миграции содержимое
копируется из одного домена в другой домен. Таким образом, за время
своей жизни практически все виртуальные машины оказываются по-очереди в
разных доменах. Xen оперирует только понятием домена, а понятие
«виртуальной машины» появляется на уровне администрирования (прикладных
программ, управляющих гипервизором).
Домены бывают нескольких типов. Самые известные dom0 и domU. dom0 —
первый запущенный Xen домен, обычно он автоматически создаётся и
загружается сразу после загрузки и инициализации гипервизора. Этот домен
имеет особые права на управление гипервизором и по-умолчанию всё
аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 —
это место жизни ПО, управляющего Xen . dom0 всегда один.
domU — рядовой домен (сокращение от User domain), содержащий в себе
домен выполняющихся виртуальных машин. Обычно не имеет доступа к
реальному оборудованию и является «полезной нагрузкой» системы
виртуализации. В отличие от dom0, domU может быть множество (обычно
несколько десятков).
stub-domain — домен, в котором запущена очень специализированная ОС,
обеспечивающая работу с каким-либо оборудованием или бэк-эндом драйвера.
Является развитием модели безопасности Xen. В продакте (то есть в
промышленно применяемых системах виртуализации на базе Xen) пока не
используется.
domain builder (конструктор доменов) — программа, которая создаёт
domU (загружает в него нужный код и сообщает гипервизору о необходимости
запуска). Помимо конструирования домена, обычно занимается подключением
и конфигурированием виртуальных устройств, доступных для виртуальной
машины. Она же отвечает за процесс миграции виртуальной машины с хоста
на хост.
[править] Паравиртуализация
-
Паравиртуализация — адаптация ядра исполняемой ОС для работы
совместно с Xen, обычно сокращается до PV. Позволяет достичь очень
высокой производительности за счёт отсутствия эмуляции «настоящего
железа», простоты интерфейсов и учёта существования гипервизора при
выполнении системных вызовов в коде ядра. Выполнение привилегированных
операций запрещено, вместо них совершаются гипервызовы (англ. hypercalls) —
обращения ядра гостевой ОС к гипервизору с просьбой о выполнении тех
или иных операций. В большинстве случаев изменения при портировании ОС
под Xen затрагивают только ядро ОС, хотя могут предполагать и
незначительные изменения в системных библиотеках (например, libc).
Процесс адаптации к Xen очень похож на портирование для новой платформы,
однако значительно проще ввиду простоты реализации «гостевой» части
драйвера (драйвера в Xen состоят из двух частей — одна исполняется вне
виртуальной машины, вторая находится внутри неё. Часть драйвера в
гостевой системе крайне примитивна и служит лишь транслятором запросов
во вторую часть. Это сделано преднамеренно для простоты портирования ОС
под Xen). В PV-режиме не поддерживаются «вложенные» режимы работы
процессора, такие как real-86, virtual-86, переключение между 32-битным и
64-битным режимом, поддержка эмуляции аппаратной виртуализации и т. д. В
связи с этим в PV-режиме отсутствует начальный фрагмент загрузки
компьютера (с имитацией кода BIOS, загрузчика и т. д.), а ядро гостевой
системы сразу же запускается в нужном режиме, подобно тому, как
запускаются обычные программы. В связи с этим, в частности, сам Xen не
может работать в PV-режиме (то есть невозможно запустить «вложенный»
гипервизор в PV-режиме).
[править] Аппаратная виртуализация
-
В режиме аппаратной виртуализации (HVM) гостевая ОС не «знает» про существование гипервизора. Xen с помощью модулей из QEMU
эмулирует реальное аппаратное обеспечение и позволяет провести
начальную загрузку ОС. По её окончании для нормальной производительности
должны запускаться PV-драйвера, которые реализуют быстрый интерфейс с
виртуальными устройствами, подобно тому, как это работает в PV-режиме).
Поскольку большинство привилегированных операций эмулируется, возможен
запуск Xen в HVM-режиме из-под Xen. В этом случае вложенный гипервизор
сможет работать только в PV-режиме.
[править] Минимизация функций гипервизора
Гипервизор Xen (по состоянию на версии 3 и 4) реализует минимальный
набор операций для управления оперативной памятью, состоянием
процессора, таймерами реального времени и счётчиками тактов (TSC)
процессора, прерываниями и контролем за DMA. Все остальные функции,
такие как реализация дисковых и блочных устройств, создание и удаление
виртуальных машин, их миграция между серверами и т. д. реализуется в
управляющем домене. За счёт этого размер гипервизора получается весьма
малым (для версии 3.4 размер двоичного кода всего гипервизора меньше 600
КБ), так же как и размер его исходного текста. По замыслу авторов это
увеличивает устойчивость системы виртуализации, так как ошибка в
компонентах вне гипервизора не приводит к компрометации/повреждению
самого гипервизора и ограничивает повреждения только вышедшей из строя
компонентой, не мешая работать остальным.
Все функции, связанные с обеспечением работы сети, блочных (дисковых)
устройств, эмуляции видеоадаптеров и прочих устройств вынесены за
пределы гипервизора. Большинство таких устройств состоит из двух частей:
драйвера в domU и программы в dom0. Драйвер (чаще всего встроенный в
ядро ОС или загружающийся в виде модуля) реализует минимальный объём
работы, фактически, транслируя запросы от ОС в программу в dom0.
Программа в dom0 выполняет основную часть работы. При этом программа
чаще всего запускается в виде отдельного процесса для каждого
обслуживаемого устройства. Сбой в такой программе ведёт к сбою только
одного устройства (блочного, сетевого) и не затрагивает работу других
копий программы (то есть не затрагивает сетевые/блочные устройства
остальных доменов, или даже другие устройства того же самого домена).
Традиционно используется следующая терминология: front — часть
модуля, находящегося в domU, back — часть, находящаяся в dom0. Для
некоторых типов устройств «задняя» часть может быть различной при
сохранении одной и той же «передней» части. Например, драйвер блочного
устройства может иметь backend в форме программы работы с VHD-образами, с
блочными устройствами, с iscsi-инициатором и т. д.
[править] Междоменное взаимодействие
Xen предоставляет доменам три механизма взаимодействия: один — с
гипервизором (hypercalls), и два между доменами. Чаще всего,
взаимодействие происходит между dom0 и domU, хотя модель допускает
взаимодействие и между двумя domU.
Междоменное взаимодействие сводится к двум видам: events (события) и
shard mem (общий доступ к памяти). Третий вариант — передача страницы
памяти, является частным случаем общего доступа к памяти.
Events служат примерно для того же, для чего служат прерывания в
архитектуре x86 или сигналы в Unix — быстрая синхронная или асинхронная
передача сигнала о наступлении какого-то события. Общий доступ к памяти
обеспечивает возможность передачи значительных объемов информации, а
события — скорость передачи.
События могут быть маскированными и немаскированными. Немаскированные события вызывают callback
(вызов функции, адрес которой передан ранее) и позволяют обрабатывать
событие сразу же по факту его возникновения. Маскированные события лишь
устанавливают флаг о том, что событие произошло, а обработчик
переодически смотрит, произошло ли событие (одно или более). Второй
метод позволяет не вызывать callback по каждому событию и в случае
частых событий существенно снижает время обработки. Напротив, первый
вариант (с вызовом callback) позволяет увеличить скорость обработки
события, которое, возможно, происходит не слишком часто, но требует
немедленной реакции.
В связи с тем, что сам гипервизор (около 500—600 КБ) реализует только
«ядро» системы, весь остальной функционал выносится на прикладной
уровень, работающий в dom0. Набор программ, реализующий функциональность
за пределами Xen называют англ. toolstack (устоявшегося перевода не имеется).
Существуют две версии toolstack для Xen: основанная на xend (входит в
большинство поставок Xen) и основанная на xapi (входит в состав Xen
Cloud Platform). Xend развивался одновременного с Xen, написан на Python
и с самого начала шёл под открытой лицензией. Xapi был проприетарной
разработкой Xensource (в дальнейшем Citrix), но в 2009 году был
опубликовано под лицензией GPL. Xapi написано на OCaml, имеет меньший набор возможностей, но работает более стабильно.
В обеих версиях toolstack присутствуют следующие утилиты:
- xenstored — демон, реализующий интерфейс XenStore. В xapi-toolstack
он переписан на ocaml, но реализует ту же самую функциональность.
- xenconsoled — демон, обеспечивающий в dom0 доступ к консолям
виртуальных машин. Xenconsoled реализует бэкэнд консольного устройства
для domU и использует API unix98 для создания псевдотерминалов в dom0. Соответствие между номером псевдотерминала и виртуальной машиной записывается в XenStore.
[править] Распространённость
Xen с каждым днем поддерживает всё больше и больше платформ. В настоящее время поддерживается Linux и NetBSD. Порт для FreeBSD в настоящее время проходит тестирование и вскоре будет официально выпущен (он доступен уже сейчас в SVN-репозитории FreeBSD). Порты других операционных систем, таких как Plan 9 также находятся в работе. Ожидается, что для всех этих операционных систем будут выпущены официальные порты для Xen (как это случилось для NetBSD).
На основе Xen создано несколько коммерческих продуктов для консолидации серверов. В частности это такие продукты как:
Xen начинался как исследовательский проект кембриджского университета
под руководством Яна Пратта (Ian Pratt), ставшего в дальнейшем
основателем компании XenSource. Компания поддерживала разработку
опенсорсной версии (xen) и параллельно продавала коммерческие версии ПО,
называвшиеся XenServer и XenEnterprise.
Первый публичный релиз Xen произошёл в 2003 году. В октябре 2007 Citrix купила XenSource и осуществила переименование продуктов:
- XenExpress в «XenServer Express Edition» (встроенная версия гипервизора стала называться «XenServer OEM Edition»)
- XenServer в «XenServer Standard Edition»
- XenEnterprise в «XenServer Enterprise Edition»
В дальнейшем они были переименованы в XenServer (Free), Essentials
for XenServer Enterprise, и Essentials for XenServer Platinum.
22 октября 2007 Citrix завершила поглощение XenSource[3], и опенсорсный проект переехал на сайт http://www.xen.org/.
21 октября 2009 Citrix объявила, что их, являющиеся в настоящий
момент коммерческими, версии XenServer станут полностью опенсорсными и
публично-доступными [4].
Саймон Кросби (Simon Crosby), главный инженер подразделения Цитрикс по
виртуализации заявил: «XenServer 100 % бесплатен и его исходные коды
будут полностью открыты в ближайшее время. Мы вообще не планируем
получение прибыли [с этого]». (англ. XenServer is 100% free, and also shortly fully open sourced. There is no revenue from it at all.).
Хотя версии Xen Server свободны, XenCenter (ПО для централизованного
управления) продаётся Citrix под собственнической лицензией.
Источник: http://ru.wikipedia.org/wiki/Xen | 
