Контрольная облачные хранилища. Содержание Введение 1 Области применения 2 Терминология 3 Технологии 1 Паравиртуализация 2 Аппаратная виртуализация 3 Минимизация функций гипервизора 4 Междоменное
 Скачать 28.38 Kb.
|
|
Содержание Введение 1 Области применения 2 Терминология 3 Технологии 3.1 Паравиртуализация 3.2 Аппаратная виртуализация 3.3 Минимизация функций гипервизора 3.4 Междоменное взаимодействие 4 Toolstack 5 Распространённость 6 История Заключение Список использованных источников Введение Xen — кросс-платформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета и распространяемый на условиях лицензии GPL. Основные особенности: поддержка режима паравиртуализации помимо аппаратной виртуализации, минимальность кода самого гипервизора за счёт выноса максимального количества компонент за пределы гипервизора. Области применения Технология виртуальных машин позволяет расширить функциональность оборудования следующими способами: Виртуальная машина обладает производительностью, сравнимой с реальной. Возможность миграции запущенной виртуальной машины между физическими машинами. Хорошая поддержка оборудования (поддерживается большинство драйверов устройств Linux) Возможность создания песочницы, перезагружаемые драйверы устройств. Терминология Основной концепцией гипервизора является домен. Доменом называется запущенная копия виртуальной машины. Если виртуальная машина перезагружается, то её домен завершается (в момент перезагрузки) и появляется новый домен. Более того, даже при миграции содержимое копируется из одного домена в другой домен. Таким образом, за время своей жизни практически все виртуальные машины оказываются по-очереди в разных доменах. Xen оперирует только понятием домена, а понятие «виртуальной машины» появляется на уровне администрирования (прикладных программ, управляющих гипервизором). Домены бывают нескольких типов. Самые известные dom0 и domU. dom0 — первый запущенный Xen домен, обычно он автоматически создаётся и загружается сразу после загрузки и инициализации гипервизора. Этот домен имеет особые права на управление гипервизором и по-умолчанию всё аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 — это место жизни ПО, управляющего Xen . dom0 всегда один. domU — рядовой домен (сокращение от User domain), содержащий в себе домен выполняющихся виртуальных машин. Обычно не имеет доступа к реальному оборудованию и является «полезной нагрузкой» системы виртуализации. В отличие от dom0, domU может быть множество (обычно несколько десятков). stub-domain — домен, в котором запущена очень специализированная ОС, обеспечивающая работу с каким-либо оборудованием или бэк-эндом драйвера. Является развитием модели безопасности Xen. В продакте (то есть в промышленно применяемых системах виртуализации на базе Xen) пока не используется. domain builder (конструктор доменов) — программа, которая создаёт domU (загружает в него нужный код и сообщает гипервизору о необходимости запуска). Помимо конструирования домена, обычно занимается подключением и конфигурированием виртуальных устройств, доступных для виртуальной машины. Она же отвечает за процесс миграции виртуальной машины с хоста на хост. 3. Технологии 3.1. Паравиртуализация Паравиртуализация — адаптация ядра исполняемой ОС для работы совместно с Xen, обычно сокращается до PV. Позволяет достичь очень высокой производительности за счёт отсутствия эмуляции «настоящего железа», простоты интерфейсов и учёта существования гипервизора при выполнении системных вызовов в коде ядра. Выполнение привилегированных операций запрещено, вместо них совершаются гипервызовы (англ. hypercalls) — обращения ядра гостевой ОС к гипервизору с просьбой о выполнении тех или иных операций. В большинстве случаев изменения при портировании ОС под Xen затрагивают только ядро ОС, хотя могут предполагать и незначительные изменения в системных библиотеках (например, libc). Процесс адаптации к Xen очень похож на портирование для новой платформы, однако значительно проще ввиду простоты реализации «гостевой» части драйвера (драйвера в Xen состоят из двух частей — одна исполняется вне виртуальной машины, вторая находится внутри неё. Часть драйвера в гостевой системе крайне примитивна и служит лишь транслятором запросов во вторую часть. Это сделано преднамеренно для простоты портирования ОС под Xen). В PV-режиме не поддерживаются «вложенные» режимы работы процессора, такие как real-86, virtual-86, переключение между 32-битным и 64-битным режимом, поддержка эмуляции аппаратной виртуализации и т. д. В связи с этим в PV-режиме отсутствует начальный фрагмент загрузки компьютера (с имитацией кода BIOS, загрузчика и т. д.), а ядро гостевой системы сразу же запускается в нужном режиме, подобно тому, как запускаются обычные программы. В связи с этим, в частности, сам Xen не может работать в PV-режиме (то есть невозможно запустить «вложенный» гипервизор в PV-режиме). 3.2. Аппаратная виртуализация В режиме аппаратной виртуализации (HVM) гостевая ОС не «знает» про существование гипервизора. Xen с помощью модулей из QEMU эмулирует реальное аппаратное обеспечение и позволяет провести начальную загрузку ОС. По её окончании для нормальной производительности должны запускаться PV-драйвера, которые реализуют быстрый интерфейс с виртуальными устройствами, подобно тому, как это работает в PV-режиме). Поскольку большинство привилегированных операций эмулируется, возможен запуск Xen в HVM-режиме из-под Xen. В этом случае вложенный гипервизор сможет работать только в PV-режиме. 3.3. Минимизация функций гипервизора Гипервизор Xen (по состоянию на версии 3 и 4) реализует минимальный набор операций для управления оперативной памятью, состоянием процессора, таймерами реального времени и счётчиками тактов (TSC) процессора, прерываниями и контролем за DMA. Все остальные функции, такие как реализация дисковых и блочных устройств, создание и удаление виртуальных машин, их миграция между серверами и т. д. реализуется в управляющем домене. За счёт этого размер гипервизора получается весьма малым (для версии 3.4 размер двоичного кода всего гипервизора меньше 600 КБ), так же как и размер его исходного текста. По замыслу авторов это увеличивает устойчивость системы виртуализации, так как ошибка в компонентах вне гипервизора не приводит к компрометации/повреждению самого гипервизора и ограничивает повреждения только вышедшей из строя компонентой, не мешая работать остальным. Все функции, связанные с обеспечением работы сети, блочных (дисковых) устройств, эмуляции видеоадаптеров и прочих устройств вынесены за пределы гипервизора. Большинство таких устройств состоит из двух частей: драйвера в domU и программы в dom0. Драйвер (чаще всего встроенный в ядро ОС или загружающийся в виде модуля) реализует минимальный объём работы, фактически, транслируя запросы от ОС в программу в dom0. Программа в dom0 выполняет основную часть работы. При этом программа чаще всего запускается в виде отдельного процесса для каждого обслуживаемого устройства. Сбой в такой программе ведёт к сбою только одного устройства (блочного, сетевого) и не затрагивает работу других копий программы (то есть не затрагивает сетевые/блочные устройства остальных доменов, или даже другие устройства того же самого домена). Традиционно используется следующая терминология: front — часть модуля, находящегося в domU, back — часть, находящаяся в dom0. Для некоторых типов устройств «задняя» часть может быть различной при сохранении одной и той же «передней» части. Например, драйвер блочного устройства может иметь backend в форме программы работы с VHD-образами, с блочными устройствами, с iscsi-инициатором и т. д. 3.4. Междоменное взаимодействие Xen предоставляет доменам три механизма взаимодействия: один — с гипервизором (hypercalls), и два между доменами. Чаще всего, взаимодействие происходит между dom0 и domU, хотя модель допускает взаимодействие и между двумя domU. Междоменное взаимодействие сводится к двум видам: events (события) и shard mem (общий доступ к памяти). Третий вариант — передача страницы памяти, является частным случаем общего доступа к памяти. Events служат примерно для того же, для чего служат прерывания в архитектуре x86 или сигналы в Unix — быстрая синхронная или асинхронная передача сигнала о наступлении какого-то события. Общий доступ к памяти обеспечивает возможность передачи значительных объемов информации, а события — скорость передачи. События могут быть маскированными и немаскированными. Немаскированные события вызывают callback (вызов функции, адрес которой передан ранее) и позволяют обрабатывать событие сразу же по факту его возникновения. Маскированные события лишь устанавливают флаг о том, что событие произошло, а обработчик переодически смотрит, произошло ли событие (одно или более). Второй метод позволяет не вызывать callback по каждому событию и в случае частых событий существенно снижает время обработки. Напротив, первый вариант (с вызовом callback) позволяет увеличить скорость обработки события, которое, возможно, происходит не слишком часто, но требует немедленной реакции. Toolstack В связи с тем, что сам гипервизор (около 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. 5. Распространённость Xen с каждым днем поддерживает всё больше и больше платформ. В настоящее время поддерживается Linux и NetBSD. Порт для FreeBSD в настоящее время проходит тестирование и вскоре будет официально выпущен (он доступен уже сейчас в SVN-репозитории FreeBSD). Порты других операционных систем, таких как Plan 9 также находятся в работе. Ожидается, что для всех этих операционных систем будут выпущены официальные порты для Xen (как это случилось для NetBSD). На основе Xen создано несколько коммерческих продуктов для консолидации серверов. В частности это такие продукты как: Citrix XenServer Virtual Iron XenSource Server Sun xVM Oracle® VM RHEL5, RHEL6 использует KVM 6. История 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 % бесплатен и его исходные коды будут полностью открыты в ближайшее время. Список использованных источников Александр Самойленко «Обзор популярных платформ виртуализации VMware, Citrix и Microsoft» [Электронный ресурс]. Режим доступа: https://www.vmgu.ru/articles/samoylenko-virtualization-platforms-review Студизба [Электронный ресурс]. Режим доступа: https://studizba.com/lectures/informatika-i-programmirovanie/oblachnye-vychisleniya/4760-tehnologii-virtualizacii.html itWeek [Электронный ресурс]. Режим доступа: https://www.itweek.ru/infrastructure/article/detail.php?ID=107230 ixbt Виртуализация: новый подход к построению IT-инфраструктуры [Электронный ресурс]. Режим доступа: https://www.ixbt.com/cm/virtualization.shtml |