Всем занять свои места! Задраить люки! Приготовьтесь к погружению! В этой статье я постараюсь рассказать об архитектуре 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 используются во многих решениях корпоративного класса:
- Microsoft Hyper-V
- VMware ESX-сервер
- Citrix XenServer
Гипервизор 2 типа
В отличие от типа 1, гипервизор типа 2 работает внутри ОС хоста (см.рис.
2).
Рис.
2 Гипервизор типа 2 работает внутри гостевых операционных систем В этом случае виртуальные машины запускаются в пользовательском пространстве хостовой ОС, что не лучшим образом сказывается на производительности.
Примерами гипервизоров 2-го типа являются MS Virtual Server и VMware Server, а также продукты виртуализации настольных компьютеров — MS VirtualPC и VMware Workstation.
Монолитный гипервизор
Гипервизоры с монолитной архитектурой включают в свой код драйверы аппаратных устройств (см.рис.
3).
Рис.
3. Монолитная архитектура Монолитная архитектура имеет свои преимущества и недостатки.
Среди преимуществ:
- Более высокая (теоретическая) производительность за счет нахождения драйверов в пространстве гипервизора
- Более высокая надежность, поскольку сбои в управляющей ОС (в терминах VMware — «Сервисная консоль») не приведут к выходу из строя всех работающих виртуальных машин.
- Поддерживается только оборудование, для которого в гипервизоре имеются драйверы.
По этой причине поставщик гипервизора должен тесно сотрудничать с поставщиками оборудования, чтобы гарантировать, что драйверы для всего нового оборудования для работы с гипервизором будут написаны и своевременно добавлены в код гипервизора.
По этой же причине при переходе на новую аппаратную платформу может потребоваться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может потребоваться смена аппаратной платформы, поскольку старое оборудование больше не поддерживается.
- Потенциально более низкая безопасность из-за включения в гипервизор стороннего кода в виде драйверов устройств.
Поскольку код драйвера выполняется в пространстве гипервизора, теоретически можно воспользоваться уязвимостью в коде и получить контроль как над хостовой ОС, так и над всеми гостевыми ОС.
Микроядерная архитектура
В архитектуре микроядра драйверы устройств запускаются внутри операционной системы хоста.ОС хоста в этом случае работает в той же виртуальной среде, что и все виртуальные машины, и называется «родительским разделом».
Все остальные среды соответственно являются «детскими».
Единственная разница между родительским и дочерним разделами заключается в том, что только родительский раздел имеет прямой доступ к серверному оборудованию.
Сам гипервизор отвечает за распределение памяти и планирование процессорного времени.
Рис.
4. Микроядерная архитектура Преимущества этой архитектуры заключаются в следующем:
- Драйверы, адаптированные для гипервизора, не требуются.
Гипервизор с микроядерной архитектурой совместим с любым оборудованием, имеющим драйверы для родительской ОС.
- Поскольку драйверы выполняются внутри родительского раздела, у гипервизора остается больше времени для более важных задач — управления памятью и работы планировщика.
- Более высокая безопасность.
Гипервизор не содержит никакого постороннего кода, а значит, возможностей для его атаки меньше.
Архитектура 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 работает как на уровне пользователя, так и на уровне ядра как системная служба (VMMS.exe) и зависит от служб удаленного вызова процедур (RPC) и инструментария управления Windows (WMI).
Служба VMMS включает в себя множество компонентов, включая поставщика WMI, предоставляющего интерфейс для управления виртуальными машинами.
Благодаря этому вы можете управлять виртуальными машинами из командной строки и с помощью сценариев VBScript и PowerShell. System Center Virtual Machine Manager также использует этот интерфейс для управления виртуальными машинами.
Рабочий процесс виртуальной машины (VMWP) Для управления виртуальной машиной из родительского раздела запускается специальный процесс — рабочий процесс виртуальной машины (VMWP).
Этот процесс работает на уровне пользователя.
Для каждой работающей виртуальной машины служба VMMS запускает отдельный рабочий процесс.
Это позволяет изолировать виртуальные машины друг от друга.
Для повышения безопасности рабочие процессы выполняются под учетной записью встроенного пользователя сетевой службы.
Процесс VMWP используется для управления соответствующей виртуальной машиной.
В его задачи входит: Создание, настройка и запуск виртуальной машины Пауза и продолжение работы (Пауза/Возобновление) Сохранить/восстановить состояние Создание снимков Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (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, что намного быстрее, чем эмуляция физических устройств.
Этот драйвер также является промежуточным звеном между гипервизором и компонентами стека виртуализации пользовательского уровня.
Библиотека интерфейса гипервизора Библиотека интерфейса гипервизора (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 в гостевой ОС запускаются следующие компоненты:
- Клиенты службы виртуализации.
VSC — это синтетические устройства, которые обеспечивают доступ к физическим устройствам через VMBus через VSP. VSC появляются в системе только после установки компонентов интеграции и допускают использование синтетических устройств.
Без установки компонентов интеграции гостевая ОС может использовать только эмулированные устройства.
Windows 7 и Windows Server 2008 R2 включают компоненты интеграции, поэтому нет необходимости устанавливать их дополнительно.
- Улучшения.
Под этим подразумевается внесение изменений в код ОС для обеспечения работы ОС с гипервизором и тем самым повышения эффективности ее работы в виртуальной среде.
Эти модификации касаются дисковой, сетевой, графической подсистем и подсистем ввода/вывода.
Windows Server 2008 R2 и Windows 7 уже содержат необходимые модификации; для этого компоненты интеграции должны быть установлены на других поддерживаемых ОС.
- Heartbeat — помогает определить, отвечает ли дочерний раздел на запросы родительского.
- Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерними и родительскими разделами.
- Синхронизация времени между хостовой и гостевой ОС
- Завершение работы гостевой ОС
- Служба теневого копирования томов (VSS), которая позволяет получать согласованные резервные копии.
На данный момент это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие операционные системы при установке компонентов интеграции используют сторонние VSC для взаимодействия с VSC через VMBus и доступа к оборудованию.
Компоненты интеграции для Linux были разработаны Microsoft в сотрудничестве с Citrix и доступны для загрузки в Центре загрузки Microsoft. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведется работа по их интеграции в ядро Linux через Проект драйвера Linux , что существенно расширит список поддерживаемых гостевых ОС.
Вместо заключения
На этом я, пожалуй, закончу свою вторую статью об архитектуре Hyper-V. Предыдущая статья вызвала вопросы у некоторых читателей, и надеюсь, что теперь я на них ответила.Надеюсь, чтение было не слишком скучным.
«Академическим языком» я пользовался довольно часто, но это было необходимо, так как тема статьи предполагает очень большой объём теории и практически ноль целых ноль практики.
Большое спасибо Митчу Таллоху и команде виртуализации Microsoft. На основе их книги Понимание решений Microsoft по виртуализации и статья была подготовлена.
Теги: #Виртуализация #архитектура #Hyper-V
-
«Коммерсантъ» Инвестирует В «Супы»
19 Oct, 24 -
Cookie-Бомбы, Или Как Остановить Интернет
19 Oct, 24
