Гипервизоры. Что же это и как работает виртуальный сервер? / VPS.house corporate blog / Habr

История о том, как программное обеспечение отделившись от оборудования подарило нам виртуализацию и облачную вычислительную среду.

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

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

Что такое гипервизор?

Гипервизор — это процесс, который отделяет операционную систему компьютера и приложения от базового физического оборудования. Обычно представляет собой программное обеспечение, хотя создаются и встроенные гипервизоры, например, для мобильных устройств.

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

История гипервизоров

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

В середине 2000-х годов гипервизоры выходят на новый уровень, когда Unix, Linux и другие похожие на Unix операционные системы начали использовать технологии виртуализации. В чем же причины роста интереса к гипервизорам и виртуализации? Ну, во-первых, причина заключалась в улучшении аппаратных возможностей и мощностей, которые теперь позволили бы одной машине выполнять более синхронизированную работу; во-вторых, усиление контроля издержек, что привело к консолидации серверов; в-третьих, значимую роль сыграла безопасность и надежность благодаря усовершенствованию архитектуры гипервизоров; и конечно последняя, но не менее важная причина — возможность запуска зависимых от ОС приложений в различных аппаратных или операционных средах. Кроме того, в 2005 году разработчики процессоров начали добавлять аппаратную виртуализацию в свои продукты на базе x86, расширяя доступность (и преимущества) виртуализации для ПК и серверной аудитории.

Преимущества гипервизоров

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

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

Существует два типа гипервизоров с очень «креативными» названиями «ТИП 1» или «ТИП 2». Гипервизоры типа 1, иногда называемые «автономными гипервизорами», запускаются непосредственно на аппаратном обеспечении хоста для управления оборудованием и управления гостевыми виртуальными машинами. К современным гипервизорам первого типа относятся: Xen, Oracle VM Server для SPARC, Oracle VM Server для x86, Microsoft Hyper-V и VMware ESX / ESXi. Под управлением Hyper-V, кстати, работают все серверы VDS Windows на хостинге

VSP.house.

Гипервизоры типа 2, иногда называемые «хостовыми гипервизорами», запускаются на обычной ОС, как и другие приложения в системе. В этом случае гостевая ОС выполняется как процесс на хосте, а гипервизоры разделяют гостевую ОС и ОС хоста. Примеры гипервизоров второго типа: VMware Workstation, VMware Player, VirtualBox и Parallels Desktop для Mac.
На данный момент можно выделить трех основных крупнейших разработчиков гипервизоров: VMware, Microsoft и Citrix Systems.

Контейнеры против гипервизоров

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

Один из публицистов в статье 2016 для Network World высказал интересное мнение. Он заявил, что виртуальные машины используют много системных ресурсов, ведь каждая виртуальная машина запускает не только полную копию операционной системы, но и виртуальную копию всего оборудования, на котором должна запускаться операционная система. Соответственно, быстро возникает необходимость в использовании большого количества запоминающих устройств и машинных циклов. А все, что требуется контейнеру, — это операционная система, поддерживающая программы и каталоги, а также системные ресурсы для запуска конкретной программы.

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

Проблемы безопасности гипервизоров

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

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

Расширение возможностей гипервизора

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

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

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

habr.com

Обзор гипервизоров | ITSeason

Введение

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

Обзор гипервизоров

Microsoft Hyper-V

Microsoft Hyper-V — система виртуализации от корпорации Microsoft. Поставляется в двух вариантах: 1) как роль Microsoft Windows Server, а так же Microsoft Windows 10 и 8.1; 2) как самостоятельный продукт Microsoft Hyper-V Server. Первый вариант доступен только при наличии лицензии на ОС Windows, второй бесплатен и доступен для скачивания с официального сайта Microsoft. В принципе разницы в них нет, за исключением отсутствия графического интерфейса в Microsoft Hyper-V Server. Функционал Hyper-V идентичен.

Hyper-V является гипервизором, работающим на микроядерной архитектуре. Его особенность в том, что драйвера на устройства устанавливаются внутри хостовой операционной системы. Хоставая операционная система, запускается точно так же как все виртуальные машины. С той лишь разницей, что только хостовая операционная система имеет прямой доступ к оборудованию. Распределением ресурсов и прочими задачами занимается гипервизор. К плюсам такого типа гипервизоров можно отнести поддержку практически любого оборудования, так как не требуются драйвера заточенные именно под гипервизор.

Начиная с версии 2016 появилась поддержка вложенной виртуализации. Для управления данным гипервизором по умолчанию используется Диспетчер Hyper-V, который имеет много полезных функций, таких как репликация, миграция, снапшоты. Однако средства автоматического резервного копирования в нем отсутствуют. Так же допускается использование средств управления и резервного копирования от сторонних вендоров.

KVM

KVM (Kernel-based Virtual Machine) — система аппаратной виртуализации в среде Linux. Полностью бесплатный продукт. Все компоненты системы открыты. Является загружаемым модулем ядра Linux (kvm.ko). Состоит из модуля ядра kvm.ko и процессорно-специфических модулей kvm-intel.ko и kvm-amd.ko. Поскольку KVM это всего лишь модуль ядра Linux, сам по себе он работать не будет. Но тут на помощь приходит QEMU. QEMU — программа для эмуляции аппаратного обеспечения с открытым исходным кодом. В принципе, QEMU может работать и без KVM, но при использовании аппаратной виртуализации KVM скорость работы виртуальных машин выше чем при работе без него. Связка QEMU/KVM является предпочтительной.

Средства управления KVM

По умолчанию для управления QEMU/KVM графический интерфейс отсутствует. Управление гипервизором осуществляется через утилиту командной строки — virsh. Virsh имеет много возможностей, через него можно создавать и настраивать виртуальные машины, управлять резервным копированием и многое другое. Для получения полного списка команд данной утилиты служит команда — help.

Существуют и приложения с графическим интерфейсом для управлением виртуальными машинами, работающими на KVM. Самое распространенное — Virtual Machine Manager. Довольно неплохое средство управления виртуальными машинами. Легко устанавливается, имеет много возможностей и понятный интерфейс.

ConVirt — приложение, позволяющее управлять виртуальными машинами на KVM. Подходит как для управления несколькими виртуальными машинами на одном сервере, так и для управления большим количеством машин на нескольких серверах.

Еще одно средство с понятным графическим интерфейсом это Proxmox VE (Proxmox Virtual Environment) —  система виртуализации с открытым исходным кодом, работающая на дистрибутиве Debian. Является самостоятельным продуктом австрийской компании Proxmox Server Solutions GmbH. В роли гипервизоров использует KVM и LXC. Управление сервером и виртуальными машинами осуществляется через веб-интерфейс. Так же есть возможность управления через терминал. Поддерживает кластеризацию, живую миграцию, снапшоты, автоматическое резервное копирование и многое другое. Сам продукт бесплатный, но имеет платные опции, такие как техническая поддержка.

Citrix Hypervisor

Citrix Hypervisor (ранее XenServer) — это коммерческая платформа серверной виртуализации. Изначально Xen был исследовательским проектом Кембриджского университета. Руководителем проекта был Иэн Прэтт, который впоследствии основал компанию XenSource. Компания занималась разработкой продукта с открытым исходным кодом (Xen), а так же коммерческих продуктов (XenServer и XenEnterprise). Первый выпуск Xen датируется 2003 годом. В 2007 году компания Citrix купила XenSource. Отличительной особенностью Xen является поддержка паравиртуализации наряду с аппаратной виртуализацией. Паравиртуализация — адаптация ядра гостевой операционной системы для работы совместно с гипервизором. При этом за счет отсутствия необходимости эмуляции железа достигается достаточно высокая производительность. XenServer включает в себя несколько версий: Free, Standard и Enterprise. Устанавливаются все с они с одного образа. Ранее версия Standard мало чем отличалась от Free версии. Первая включала в себя дополнительную поддержку. Но начиная с версии XenServer 7.3 с бесплатной версии убрали часть функций, таких как интеграция с Active Directory, управление динамической памятью и много другое. Максимальный размер пула теперь ограничен тремя хостами. Тем самым разрыв между Free и Standard стал довольно существенным. Лицензируется по разъемам центральных процессоров. Для управления гипервизором используется консоль управления Citrix XenCenter, которая устанавливается на компьютер под управлением ОС Windows.

VMware

VMware ESXi — программный продукт аппаратной виртуализации, нацеленный в первую очередь на корпоративных клиентов. Устанавливается непосредственно на физический сервер и разделяет его ресурсы на логические разделы (виртуальные машины). Это полностью коммерческое решение, имеющее ограниченную по функционалу бесплатную версию — VMware vSphere Hypervisor.

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

 Управление гипервизором осуществляется через консоль VMware vSphere Client или VMware vCenter Server. Сервер vCenter представляет собой программное обеспечение для централизованное управления всеми серверами VMware ESXi из одного интерфейса. Поддерживает ряд дополнительных возможностей, таких как как планировщик, резервное копирование и т.д. vCenter Server рекомендуется использовать если у вас несколько серверов VMware ESXi.

На ряду с серверной версией VMware ESXi, компания имеет версию VMware Workstation. VMware Workstation — программное обеспечение виртуализации для компьютеров под управлением операционных Windows и Linux. Имеет урезанную бесплатную для некомерческого использования версию — VMware Workstation Player. Так же имеется лицензированная версия VMware Player — VMware Player Plus, позволяющая использовать дополнительные функции.

Oracle VM VirtualBox

VirtualBox — программный продукт виртуализации, разработанный компанией Oracle. Основная часть продукта распространяется бесплатно под лицензией GNU GPL v2. Работает под управлением всех популярных операционных систем, так как Windows, Linux, MacOS. Начиная с версии 5 VirtualBox не поддерживает установку на операционные стемы Windows XP и Windows Vista, а с версии 6 — на 32-разрядную версию Windows 7. VirtualBox довольно неплохой продукт и отлично подходит для домашнего использования. Прост в использовании, имеет понятный интерфейс и множество настроек. Присутствует возможность проброса USB на гостевую операционную систему.

Обзор систем контейнеризации

OpenVZ

OpenVZ — продукт виртуализации на уровне операционной системы, базируемая на ядре Linux. Отличительной особенность данного продукта является то, что в роли гостевых операционных систем могут выступать только дистрибутивы Linux. Но при этом у OpenVZ производительность виртуализации уровня операционной системы выше чем у аналогичных решений. OpenVZ распространяется на условиях лицензии GNU GPL v.2. Для работы OpenVZ не требуется поддержка процессором аппаратной виртуализации. Управлять данным гипервизором можно через терминал, а так же через OpenVZ Web Panel.

LXC

LXC — система виртуализации на уровне операционной системы. Представляет собой тоже, что и OpenVZ. Основана на технологии cgroups, входящей в ядро Linux, начиная с версии 2.6.29.

Выводы

В настоящей обзоре мы рассмотрели самые популярные гипервизоры. Какой из них выбрать? Решать только вам. Поскольку однозначного ответа на этот вопрос не существует. Для каких то задач лучше подойдет один, для каких то другой. Например в Hyper-V до сих пор отсутствует технология USB Redirection, используемая для проброса виртуальной машине аппаратных USB портов. Да вместо этого имеется Discrete Device Assigment (выделение дискретного устройства), но это не совсем то. Так, что если вам необходим проброс USB, то можно рассмотреть платный VMware (быть может в вашем случае будет достаточно ограниченной по функционалу бесплатной версии?), так же у бесплатного KVM с этим проблем не наблюдаются.

Если вы выбираете гипервизор для корпоративного использования, то советую выбирать между решениями гипервизоров первого типа. При выборе обратите внимание на то, под управлением каких операционных системам будут работать ваши виртуальные сервера. Для виртуализации Linux серверов лучше рассмотреть KVM, Citrix Hypervisor, либо VMware. Для Windows — Hyper-V. Считается, что Windows системы на нем работают несколько лучше (это не значит, что на KVM или VMware Microsoft Windows у вас будет плохо работать). К тому же Windows сервера на Hyper-V проще лицензировать, поскольку в лицензии Microsoft Windows Server входят определенное количество виртуальных серверов (2 для версии Standart и неограниченное количество для версии Datacenter).

Так же стоит обратить внимание на средства управления. Из текста выше вы уже знаете, что у каждого гипервизора они разные. Какое из них более удобное и функциональное сказать сложно. Кто к чему привык. Ну и опять же конечно зависит от задач, которые перед вами стоят. Так же не маловажным фактором в выборе, наряду с функционалом, является конечная стоимость внедрения того или иного продукта. Она может сыграть решающую роль в выборе.

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

Лично я, поработав с различными продуктами, пришел к следующему: для виртуализации Linux серверов в основном использую QEMU/KVM и Virtual Machine Manager, иногда, если необходимо создания кластера — Proxmox VE; для виртуализации Windows — Hyper-V Server; для домашнего использования — VirtualBox.

 

itseason.ru

О гипервизорах, виртуализации систем и о том, как это работает в облачной среде

Гипервизоры, виртуализация и облако

Бхану П. Толети
Опубликовано 23.07.2012

Серия контента:

Этот контент является частью # из серии # статей: Гипервизоры, виртуализация и облако

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Гипервизоры, виртуализация и облако

Следите за выходом новых статей этой серии.

Ссылка на оригинал (in English)

Виртуализация оптимизирует использование ИТ-ресурсов, рассматривая физические ресурсы компании в качестве резервуаров, из которых можно динамически черпать виртуальные ресурсы.

Об этом цикле статей

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

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

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

• консолидация с целью уменьшения стоимости оборудования;
• оптимизация рабочей нагрузки;
• гибкость и оперативность ИТ-услуг.

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

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

Более того, виртуальные ресурсы могут иметь функции или особенности, отсутствующие у исходных физических ресурсов.

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

Гипервизор ― это программное или микропрограммное обеспечение, позволяющее виртуализировать системные ресурсы.

Рисунок 1. Виртуализация, переход от физического подхода к логическому

Теперь рассмотрим типы гипервизоров.

Общие сведения о гипервизорах

Существует два типа гипервизоров:

• гипервизоры типа 1 и
• гипервизоры типа 2.

Гипервизоры типа 1 работают непосредственно на оборудовании системы. Гипервизоры типа 2 работают поверх базовой операционной системы, которая обеспечивает службы виртуализации, такие как поддержка устройства ввода/вывода и управление памятью. На рисунке 2 показано, чем различаются гипервизоры типа 1 и типа 2.

Рисунок 2. Различия между гипервизорами типа 1 и типа 2

Гипервизоры, описанные в этом цикле статей, поддерживают различные аппаратные платформы в различных облачных средах.

• PowerVM: принадлежность серверов на базе IBM POWER5, POWER6 и POWER7, этот гипервизор поддерживается операционными системами IBM i, AIX® и Linux®; PowerVM поддерживается в среде IBM SmartCloud Enterprise.
• VMware ESX Server: встроенный гипервизор VMware ESX работает непосредственно на аппаратуре серверов, не требуя дополнительной операционной системы. Он поддерживается в среде IBM SmartCloud Enterprise.
• Xen: монитор виртуальных машин для процессорных архитектур IA-32, x86-64, Itanium и ARM, Xen позволяет выполнять несколько гостевых операционных систем на одном и том же оборудовании одновременно. Xen-системы имеют структуру, в которой гипервизор Xen занимает самый низкий и привилегированный уровень.
• KVM: инфраструктура виртуализации для ядра Linux, KVM поддерживает платформенно-зависимую виртуализацию на процессорах с аппаратными расширениями для виртуализации. Первоначально он поддерживал процессоры x86, но в настоящее время к ним добавился широкий спектр процессоров и гостевых операционных систем, в том числе множество вариаций Linux, BSD, Solaris, Windows®, Haiku, ReactOS и AROS Research Operating System (есть даже модифицированная версия QEMU, способная использовать KVM для работы с Mac OS X).
• z/VM: текущая версия операционной системы виртуальных машин IBM, z/VM работает на серверах IBM zSeries и может использоваться для поддержки большого числа (тысяч) виртуальных машин Linux.

Все эти гипервизоры поддерживаются оборудованием IBM.

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

Правильный выбор гипервизора

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

Но выбор нельзя основывать на одних лишь показателях производительности. Кроме возможностей гипервизора, необходимо проверить, какие гостевые операционные системы он поддерживает.

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

Гипервизоры разные, но все они имеют схожие черты. Знание их особенностей и поддерживаемых гостевых операционных систем ― важный аспект любого процесса выбора гипервизора для виртуализации оборудования. Решение будет основываться на соответствии этих данных требованиям вашей организации. (Начните этот процесс с детального изучения каждого гипервизора.)

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

Производительность виртуальной машины

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

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

Управление памятью

Ищите виртуализацию памяти с аппаратной поддержкой. Предпочтительными являются возможность выделения избыточного количества памяти и поддержка больших таблиц страниц в гостевой ВМ и в гипервизоре; дополнительно следует рассмотреть возможность обобщения страниц памяти (memory page sharing).

Высокая готовность

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

Динамическая миграция

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

Сети, системы хранения данных и безопасность

В сфере сетей гипервизоры должны поддерживать выравнивание нагрузки и групповую работу (teaming) сетевых карт (NIC), Unicast-изоляцию, а также поддержку объединения каналов (trunking) стандартных (802.1Q) виртуальных локальных сетей (VLAN).

Каждый гипервизор должен поддерживать также системы хранения данных на основе сетей iSCSI (и Fibre Channel) и корпоративное ПО защиты данных, причем некоторое предпочтение отдается инструментами и API, Fibre Channel over Ethernet (FCoE) и совместимости с мультигипервизором виртуальных дисков.

Функции управления

Обратите внимание на такие функции управления, как ловушки Simple Network Management Protocol (SNMP), интеграцию с другим программным обеспечением управления и отказоустойчивость сервера управления — эти функции имеют неоценимое значение для гипервизора.

Несколько советов…

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

• Гипервизор PowerVM способен справляться с UNIX®-нагрузками, содержащими критические бизнес-приложения, которые выполняют тяжелые транзакции, когда важнейшим требованием является производительность.
• VMware ESX достаточно хорошо работает с критически важными бизнес-приложениями на System X (серверы x86 для Windows и Linux).
• Если приложение не особенно критично для бизнеса, можно попробовать KVM или Xen (первоначальные расходы на них тоже относительно невелики).

Можно даже попробовать некоторые бесплатные виртуальные машины, такие как Xen и KVM.

Заключение

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

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

• зрелость,
• простота развертывания,
• управляемость и автоматизация,
• поддержка и сопровождение,
• производительность,
• масштабируемость,
• надежность, высокая готовность и работоспособность,
• безопасность.

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

Ресурсы для скачивания

Похожие темы

Подпишите меня на уведомления к комментариям

www.ibm.com

Гипервизор — Национальная библиотека им. Н. Э. Баумана

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

Определение

Гипервизор (англ. Hypervisor) или Монитор виртуальных машин (в компьютерах) — программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами. Гипервизор также может (но не обязан) предоставлять работающим под его управлением на одном хост-компьютере ОС средства связи и взаимодействия между собой (например, через обмен файлами или сетевые соединения) так, как если бы эти ОС выполнялись на разных физических компьютерах. Гипервизор сам по себе в некотором роде является минимальной операционной системой (микроядром или наноядром). Он предоставляет запущенным под его управлением операционным системам сервис виртуальной машины, виртуализируя или эмулируя реальное (физическое) аппаратное обеспечение конкретной машины. И управляет этими виртуальными машинами, выделением и освобождением ресурсов для них. Гипервизор позволяет независимое «включение», перезагрузку, «выключение» любой из виртуальных машин с той или иной ОС. При этом операционная система, работающая в виртуальной машине под управлением гипервизора, может, но не обязана «знать», что она выполняется в виртуальной машине, а не на реальном аппаратном обеспечении.

Термин

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

Обязанности

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

Типы

Все гипервизоры, обеспечивающие работу виртуальных машин и приложений, делятся на два типа. Большинство современных гипервизоров относятся к Type 2, что подразумевает установку гипервизора в основную клиентскую операционную систему. Гипервизоры, которые относятся к Type 1, интегрируются с аппаратной составляющей ВС, а клиентская операционная система работает поверх этой аппаратуры и гипервизора. По мнению Тима Джонса в реализации технологий ВМ выделяются три основных подхода (рис. 1).

• Гипервизор первого типа (автономный, тонкий, исполняемый на “голом железе” — Type 1, native, bare-metal) — программа, исполняемая непосредственно на аппаратном уровне компьютера и выполняющая функции эмуляции физического аппаратного обеспечения и управления аппаратными средствами и гостевыми ОС. То есть такой гипервизор сам по себе в некотором роде является минимальной операционной системой.
• Гипервизор второго типа (хостовый, монитор виртуальных машин — hosted, Type-2, V) — специальный дополнительный программный слой, расположенный поверх основной хостовой ОС, который в основном выполняет функции управления гостевыми ОС, а эмуляцию и управление аппаратурой берет на себя хостовая ОС.
• Гипервизор гибридный (Hybrid, Type-1+) — объединенный вариант первых двух, в котором функции управления аппаратными средствами выполняются тонким гипервизором и специальной депривилегированной сервисной ОС, работающей под управлением тонкого гипервизора. Обычно гипервизор управляет напрямую процессором и памятью компьютера, а через сервисную ОС гостевые ОС работают с остальными аппаратными компонентами.

автономный гипервизор (Тип 1) имеет свои встроенные драйверы устройств, модели драйверов и планировщик и поэтому не зависит от базовой ОС. Так как автономный гипервизор работает непосредственно в окружении усечённого ядра, то он более производителен, но проигрывает в производительности виртуализации на уровне ОС и паравиртуализации. Примерами таких технологий выступают: VMware ESX , Citrix, XenServer. Гипервизор на основе базовой ОС (Тип 2, V) представляет собой компонент, работающий в одном кольце с ядром основной ОС (кольцо 0). Гостевой код может выполняться прямо на физическом процессоре, но доступ к устройствам ввода-вывода компьютера из гостевой ОС осуществляется через второй компонент, обычный процесс основной ОС — монитор уровня пользователя. Примерами таких гипервизоров выступают: VirtualBox, VMware Workstation, QEMU, Parallels. Гибридный гипервизор (Тип 1+) состоит из двух частей: из тонкого гипервизора, контролирующего процессор и память, а также работающей под его управлением специальной сервисной ОС в кольце пониженного уровня. Через сервисную ОС гостевые ОС получают доступ к физическому оборудованию. Примерами данного вида гипервизоров выступают: Sun Logical Domains, Xen, Citrix XenServer, Microsoft Hyper- V.

Типы архитекруры на реальных примерах

VMware vSphere Hypervisor

Классический вариант полностью автономного гипервизора, который относится к категории архитектуры монолитного ядра. Он содержит всё необходимое для работы ВМ и по сути является автономной ОС, включающей в том числе и драйверы для работы с оборудованием. Именно на эти моменты как на архитектурные преимущества делает акцент VMware, подчеркивая, что такой подход обеспечивает наиболее полную изоляцию ВМ, а следовательно, и более высокую надежность системы в целом. В целом ее ESX Server состоит из собственно гипервизора, среды исполнения (ESXi) и сервисной консоли на базе ядра Linux, при этом ESXi может использоваться автономно, но в этом случае у него ограничены возможности управления системой. Критики данного варианта указывают на сложность решения задачи реализации собственной модели драйверов, доводка которой до нужного уровня является многолетней задачей. Отмечается также, что вся архитектура ESX — закрытая, проприетарная (на это делает акцент даже Microsoft).

Microsoft Hyper-V

Придерживается иного подхода, который называют архитектурой микроядра, т.е. разделения функций по разным модулям и уровням. В сущности данный подход вариант гипервизора смешанного типа (Тип 1+), когда сам гипервизор выполняет только функции управления памятью и процессором, а для взаимодействия с внешними устройствами и управления служит привилегированная родительская ВМ на базе ядра Windows (в случае Citrix — Linux).

По мнению разработчиков Microsoft, такой подход более эффективен при высокой вычислительной нагрузке, когда используется только “тонкий” гипервизор, который в случае Microsoft занимает всего порядка 100 Кб оперативной памяти.

Для ускорения же работы на уровне драйверов Microsoft использует два механизма взаимодействия прикладных BM с родительской. В одном случае применяется специальный внутренний интерфейс VMBus, который позволяет общаться ВМ между собой напрямую. Он доступен для ВМ, реализованных на базе Windows, а также Xen, но только для тех разработчиков, с кем у Microsoft есть соответствующий уровень сотрудничества. Для всех остальных ОС используется второй вариант полной эмуляции драйверов. Как свое преимущество Microsoft также подчеркивает наличие в ее Hyper-V проверенной модели драйверов, которая развивается в рамках Windows Server в целом на протяжении ряда лет.

Citrix XenServer

KVM

Qemu-KVM

Популярные на рынке (2015)

В настоящее время, существует несколько лидирующих систем виртуализации. Среди всех систем особо выделяется openVZ, популярность её использования обеспечивается высоким функционалом, большой степенью надежности и изоляции ресурсов и поддержкой «живой» миграции, отсутствующей у конкурентов. Применяя технологии виртуализации в совершенствовании и оптимизации информационной среды вуза в конфигурации OpenVZ (базовая), Hyper-V и Xen (вспомогательные), можно эффективно обеспечивать студентов и преподавателей круглосуточно функционирующими гостевыми машинами с возможностью доступа в Интернет, и осуществлять централизованный контроль над ресурсами локальной сети. Решением проблем оптимизации информационной инфраструктуры организации, связанных со сложностью, безопасностью, надёжностью и дороговизной компонентов информационной системы, может служить повсеместное внедрение технологий виртуализации. Основываясь на многолетнем опыте и потребностях ШГПИ, оптимальным явилось решение о внедрении в работу Вычислительного Центра, обслуживающего большинство локальных сетей вуза, системы виртуализации OpenVZ. Выбор системы виртуализации основывается на:

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

ru.bmstu.wiki

Архитектура Hyper-V: Глубокое погружение / Habr

Всем занять свои места! Задраить люки! Приготовиться к погружению!
В этой статье я попытаюсь рассказать об архитектуре Hyper-V еще подробнее, чем я сделал это ранее.

Что же такое – Hyper-V?

Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают».
Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках).
Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.

Гипервизор

Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов.
Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера.
Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).

Гипервизор 1 рода

Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.

Рис.1 Гипервизор 1 рода запускается на «голом железе».

Работа гипервизоров 1 рода непосредственно с оборудованием позволяет достичь большей производительности, надежности и безопасности.
Гипервизоры 1 рода используются во многих решениях Enterprise-класса:

• Microsoft Hyper-V
• VMware ESX Server
• Citrix XenServer

Гипервизор 2 рода

В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).

Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС

Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности.
Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.

Монолитный гипервизор

Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).

Рис. 3. Монолитная архитектура

Монолитная архитектура имеет свои достоинства и недостатки. Среди достоинств можно отметить:

• Более высокую (теоретически) производительность из-за нахождения драйверов в пространстве гипервизора
• Более высокую надежность, так как сбои в работе управляющей ОС (в терминах VMware – «Service Console») не приведет к сбою всех запущенных виртуальных машин.

Недостатки же у монолитной архитектуры следующие:

• Поддерживается только то оборудование, драйверы на которое имеются в гипервизоре. Из-за этого вендор гипервизора должен тесно сотрудничать с вендорами оборудования, чтобы драйвера для работы всего нового оборудования с гипервизором вовремя писались и добавлялись в код гипервизора. По той же причине при переходе на новую аппаратную платформу может понадобиться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может понадобиться смена аппаратной платформы, поскольку старое оборудование уже не поддерживается.
• Потенциально более низкая безопасность – из-за включения в гипервизор стороннего кода в виде драйверов устройств. Поскольку код драйверов выполняется в пространстве гипервизора, существует теоретическая возможность воспользоваться уязвимостью в коде и получить контроль как над хостовой ОС, так и над всеми гостевыми.

Самым распространенным примером монолитной архитектуры является VMware ESX.

Микроядерная архитектура

При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС.
Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.

Рис. 4. Микроядерная архитектура

Достоинства у такой архитектуры следующие:

• Не требуются драйвера, «заточенные» под гипервизор. Гипервизор микроядерной архитектуры совместим с любым оборудованием, имеющим драйверы для ОС родительской партиции.
• Поскольку драйверы выполняются внутри родительской партиции – у гипервизора остается больше времени на более важные задачи – управление памятью и работу планировщика.
• Более высокая безопасность. Гипервизор не содержит постороннего кода, соответственно и возможностей для атаки на него становится меньше.

Самым ярким примером микроядерной архитектуры является, собственно, сам Hyper-V.

Архитектура Hyper-V

На рис.5 показаны основные элементы архитектуры Hyper-V.

Рис.5 Архитектура Hyper-V

Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.

Родительская партиция

Родительская партиция создается сразу же при установке системной роли Hyper-V. Компоненты родительской партиции показаны на рис. 6.
Назначение родительской партиции следующее:

• Создание, удаление и управление дочерними партициями, в том числе и удаленное, посредством WMI-провайдера.
• Управление доступом к аппаратным устройствам, за исключением выделения процессорного времени и памяти – этим занимается гипервизор.
• Управление питанием и обработка аппаратных ошибок, если таковые возникают.

Рис.6 Компоненты родительской партиции Hyper-V

Стек виртуализации

Следующие компоненты, работающие в родительской партиции, в совокупности называют стеком виртуализации:

• Служба управления виртуальными машинами (VMMS)
• Рабочие процессы виртуальных машин (VMWP)
• Виртуальные устройства
• Драйвер виртуальной инфраструктуры (VID)
• Библиотека интерфейсов гипервизора

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

• Управление состоянием виртуальных машин (включено/выключено)
• Добавление/удаление виртуальных устройств
• Управление моментальными снимками

При запуске виртуальной машины VMMS создает новый рабочий процесс виртуальной машины. Подробнее о рабочих процессах будет рассказано далее.
Так же именно VMMS определяет, какие операции разрешено выполнять с виртуальной машиной в настоящий момент: к примеру, если происходит удаление снапшота, то применить снапшот в течение операции удаления она не даст. Подробнее о работе с моментальными снимками (снапшотами) виртуальных машин можно почитать в соответствующей моей статье.
Если говорить более детально – то VMMS управляет следующими состояниями виртуальных машин:

• Starting
• Active
• Not Active
• Taking Snapshot
• Applying Snapshot
• Deleting Snapshot
• Merging Disk

Другие задачи управления – Pause, Save и Power Off – выполняются не службой VMMS, а непосредственно рабочим процессом соответствующей виртуальной машины.
Служба VMMS работает как на уровне пользователя, так и на уровне ядра как системная служба (VMMS.exe) и зависит от служб Remote Procedure Call (RPC) и Windows Management Instrumentation (WMI). Служба VMMS включает в себя множество компонент, среди которых имеется и WMI-провайдер, предоставляющий интерфейс для управления виртуальными машинами. Благодаря этому можно управлять виртуальными машинами из командной строки и с помощью скриптов VBScript и PowerShell. System Center Virtual Machine Manager так же использует этот интерфейс для управления виртуальными машинами.

Рабочий процесс виртуальной машины (VMWP)

Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service.
Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит:
Создание, конфигурация и запуск виртуальной машины
Пауза и продолжение работы (Pause/Resume)
Сохранение и восстановление состояния (Save/Restore State)
Создание моментальных снимков (снапшотов)
Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.

Виртуальные устройства

Виртуальные устройства (VDevs) – это программные модули, реализующие конфигурацию и управление устройствами для виртуальных машин. VMB включает в себя базовый набор виртуальных устройств, включающий в себя шину PCI и системные устройства, идентичные чипсету Intel 440BX. Есть два типа виртуальных устройств:

• Эмулируемые устройства – эмулируют определенные аппаратные устройства, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.
• Синтетические устройства – не эмулируют реально существующие в природе железки. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.

Драйвер виртуальной инфраструктуры (VID)

Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.

Библиотека интерфейса гипервизора

Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.

Провайдеры служб виртуализации (VSP)

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

Шина виртуальных машин (VMBus)

Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств.
Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.
Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.

Дочерние партиции

Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.

Рис. 7 Дочерние партиции

Итак, в дочерних партициях могут быть установлены:

• ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 7)
• ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
• ОС, не поддерживающие компоненты интеграции (например, FreeBSD).

Во всех трех случаях набор компонент в дочерних партициях будет немного различаться.

ОС Windows с установленными компонентами интеграции

Операционные системы Microsoft Windows, начиная с Windows 2000 поддерживают установку компонент интеграции. После установки Hyper-V Integration Services в гостевой ОС запускаются следуюшие компоненты:

• Клиенты служб виртуализации. VSC представляют собой синтетические устройства, позволяющие осуществлять доступ к физическим устройствам посредством VMBus через VSP. VSC появляются в системе только после установки компонент интеграции, и позволяют использовать синтетические устройства. Без установки интеграционных компонент гостевая ОС может использовать только эмулируемые устройства. ОС Windows 7 и Windows Server 2008 R2 включает в себя компоненты интеграции, так что их не нужно устанавливать дополнительно.
• Улучшения. Под этим имеются в виду модификации в коде ОС чтобы обеспечить работу ОС с гипервизором и тем самым повысить эффективность ее работы в виртуальной среде. Эти модификации касаются дисковой, сетевой, графической подсистем и подсистемы ввода-вывода. Windows Server 2008 R2 и Windows 7 уже содержат в себе необходимые модификации, на другие поддерживаемые ОС для этого необходимо установить компоненты интеграции.

Так же, компоненты интеграции предоставляют следующий функционал:

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

ОС не из семейства Windows, но поддерживающая компоненты интеграции

Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.

Вместо заключения

На этом я, пожалуй, закончу свою вторую статью, посвященную архитектуре Hyper-V. Предыдущая статья вызвала у некоторых читателей вопросы, и надеюсь, что теперь я на них ответил.
Надеюсь, что чтение не было слишком скучным. Я достаточно часто использовал «академический язык», но это было необходимо, поскольку тематика статьи предполагает очень большой объем теории и практически нуль целых нуль десятых практики.

Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.

habr.com

как это работает / Habr

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

Метод основан на технологии аппаратной виртуализации памяти (англ. nested paging или hardware assisted paging, общепринятого русскоязычного термина нет). Эта технология появилась в последних моделях процессоров Intel и AMD. Версия Intel называется Intel Extended Page Table (EPT) и поддерживается процессорами начиная с семейства Nehalem (Intel Core i3, i5, i7). Аналог AMD называется AMD Rapid Virtualization Indexing (RVI) и присутствует на процессорах, начиная с поколения AMD K10. Технологии схожи, поэтому все, что описывается далее об Intel EPT, применимо и к AMD RVI.

Теория

Итак, у нас есть гипервизор и работающая под его контролем гостевая операционная система (гость).

Переход управления из гипервизора в гостевую ОС называется VM Entry, обратный переход – VM Exit. Вся работа – это последовательность VM Entry и VM Exit, сменяющих друг друга. Гипервизор работает в изолированном адресном пространстве и «невидим» со стороны гостевой ОС. При этом он может изменять состояние гостевой ОС (виртуальный процессор, память, виртуальное аппаратное обеспечение и т.д.).

Читателю есть смысл ознакомиться с нашей предыдущей статьей, где речь шла о методе, основанном на теневой таблице страниц (shadow paging). Описываемый здесь метод – дальнейшее логическое его развитие.

Аппаратная виртуализация памяти, в противовес программной виртуализации в shadow paging, резко упрощает гипервизор и, как следствие, делает его надежнее. Кроме того, значительно повышается производительность и снижается расход памяти.

При обычной работе процессора любое обращение к физическому адресу немедленно ведет к его выставлению на адресной шине процессора (кроме таких случаев, как обращение к APIC, но мы их опустим для простоты изложения). В случае с nested paging любое обращение гостя к физическому адресу (он получает название «гостевой физический адрес») сперва транслируется через специальную таблицу страниц. Физический адрес, полученный из гостевого физического адреса, выставляется на адресной шине, после чего происходит обращение к памяти.

Преобразование гостевых физических адресов для Intel EPT аналогично обычному страничному преобразованию:

Таблица страниц четырехуровневая и напоминает таблицу страниц для преобразования виртуальных адресов в 64-битном режиме Intel 64. Основное отличие – строение записей таблицы. На рисунке приведено строение записи для нижнего уровня таблицы (PTE):

Нас интересуют три младших бита записей, которые определяют доступ к физической памяти. Если сброшены биты R, W, X (биты 0…2), то доступ к описываемой PTE памяти соответственно на чтение, запись и исполнение вызывает выход в гипервизор (EPT Violation по терминологии Intel).

Это дает возможность контролировать исполнение кода на процессоре и записи в память c кодом.

Суть метода

Полная виртуализация не является в нашем случае целью. Для контроля над выполнением и модификацией кода нам достаточно виртуализировать память и процессор.

Для виртуализации памяти нам нужно построить таблицу страниц EPT с отображением гостевых физических адресов в реальные физические адреса «один в один» (identity mapping). При этом в записях на нижнем уровне таблицы (PTE) мы сбрасываем биты W и X. Каждая такая запись описывает доступ к странице памяти размером 4 КБ.

Далее возможны два варианта выхода в гипервизор (VM Exit) с EPT Violation:

1. Доступ к странице памяти на запись. При этом происходит выход в гипервизор, после чего он разрешает запись в страницу (устанавливает бит W), но запрещает выполнение (сбрасывает бит X).
2. Доступ к странице памяти на выполнение. При этом гипервизор разрешает выполнение на странице (устанавливает X), но запрещает запись в нее (сбрасывает W).

Таким образом, страница памяти может быть либо только исполняемой, либо только записываемой. Запись и исполнение соответственно влекут выход в гипервизор (VM Exit) и переводят страницу из одного состояния в другое.

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

Практическая реализация

Мы реализовали детектор руткитов Hypersight Rootkit Detector, использующий вышеописанный метод. Он спроектирован так, чтобы его можно было загружать и выгружать по запросу пользователя. Это позволяет использовать его совместно с программами виртуализации, такими как VMware и VirtualBox.

Наш детектор руткитов может обнаруживать следующую активность в ядре:

• Попытки перехода в режим гипервизора.
• Модификации управляющих регистров кодом вне ядра и HAL.
• Модификации невыгружаемого кода ядра, HAL и драйверов в памяти, модификации SSDT. В том числе модификации путем отображения виртуальной памяти.
• Выполнение кода за пределами исполняемых секций драйверов, ядра и HAL. Так называемый «скрытый код», козырная карта руткитов, теперь легко обнаруживается.

Падение производительности при включенном мониторинге – в пределах одного процента и практически незаметно «на глаз». Потребление памяти гипервизором – около 40 МБ для четырехъядерного процессора. Это дает возможность использования метода на компьютерах с памятью от 1 ГБ, предназначенных для офисных задач и разработки.

Дальнейшая работа

Возможности гипервизора не ограничиваются лишь детектированием руткитов. Возможно также и блокирование вредоносной активности. Мы ведем исследования в этой области и надеемся представить результаты в скором будущем. Также на повестке дня стоит портирование на 64-битную архитектуру и процессоры AMD RVI.

Заключение

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

Литература

Документация по процессорам Intel: www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

Документация по процессорам AMD: developer.amd.com/documentation/guides/Pages/default.aspx

habr.com

Гипервизор — это… Что такое Гипервизор?

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

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

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

Типы гипервизора

Автономный гипервизор (Тип 1)

Имеет свои встроенные драйверы устройств, модели драйверов и планировщик и поэтому не зависит от базовой ОС. Так как автономный гипервизор работает непосредственно на оборудовании, то он более производителен.

Пример: VMware ESX

На основе базовой ОС (Тип 2, V)

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

Примеры: Microsoft Virtual PC, VMware Workstation, QEMU, Parallels, VirtualBox.

Гибридный (Тип 1+)

Гибридный гипервизор cостоит из двух частей: из тонкого гипервизора, контролирующего процессор и память, а также работающей под его управлением специальной сервисной ОС в кольце пониженного уровня. Через сервисную ОС гостевые ОС получают доступ к физическому оборудованию.

Примеры: Microsoft Virtual Server, Sun Logical Domains, Xen, Citrix XenServer, Microsoft Hyper-V

Ссылки

dic.academic.ru