В этой статье мы поговорим о том, что такое Hyper-V «изнутри», и чем он отличается от VMware ESX с точки зрения архитектуры, а не маркетинговых листовок. Статья будет делиться на три части. В первой части я расскажу о самой архитектуре гипервизора, в двух других – о том, как Hyper-V работает с устройствами хранения данных и с сетью.
Итак, как мы уже знаем, Hyper-V – это платформа виртуализауции серверов от Microsoft, пришедшая на смену Virtual Server. В отличие от последнего, Hyper-V – это не самостоятельный продукт, а всего-навсего компонента ОС Windows Server 2008. Итак, давайте посмотрим, что происходит с Windows Server 2008 после установки роли Hyper-V:
Как мы видим, после установки роли Hyper-V архитектура системы очень сильно меняется: если до этого ОС работала с памятью, процессором и железом напрямую, то после установки распределением памяти и процессорного времени управляет уже гипервизор. Так же появляются некоторые новые компоненты, о которых будет рассказано далее. После установки Hyper-V система создает изолированные окружения, в которых запускаются гостевые ОС, так называемые партиции (partitions). Не путать с разделами (partitions) жесткого диска. Сама хостовая ОС, в свою очередь, с момента установки Hyper-V точно так же работает в изолированной партиции, которая именуется родительской (parent partition). Партиции, в которых запускаются гостевые ОС именуются дочерними. Разница между родительской партиции и дочерними состоит в том, что только из родительской партиции может осуществляться прямой доступ к аппаратному обеспечению сервера. Все остальные партиции полностью изолированы как друг от друга, так и от аппаратного обеспечения самого сервера. Все взаимодействие с железом идет через драйверы, работающие внутри хостовой ОС, то есть через родительскую партицию. Каждая виртуальная машина имеет набор виртуальных устройств (сетевой адаптер, видеоадаптер, контроллер дисков, и т.д.), которые взаимодействуют с родительской партицией посредством так называемой шины виртуальных устройств (VMBus). И уже в родительской партиции все обращения к виртуальным устройствам передаются драйверам железа. В этом – коренное отличие Hyper-V от VMware ESX: в ESX драйверы устройств «вмонтированы» в сам гипервизор. Хорошо это или плохо – однозначно сказать невозможно. С одной стороны – безусловно хорошо: гипервизор ESX может работать самостоятельно, без необходимости в хостовой ОС, и поэтому имеет намного меньшие требования по памяти и дисковому пространству. С другой же стороны, список поддерживаемого железа очень сильно ограничен, и установить новые драйверы в ESX невозможно. Поэтому может сложиться ситуация, что при использовании VMware ESX когда появляется, к примеру, новый драйвер, поддерживающий какие-то особые функции железа – придется ждать новой версии гипервизора. Возможна и обратная ситуация: при замене железа на новое может возникнуть необходимость в переходе на новый гипервизор. В Hyper-V же будет достаточно просто установить соответствующие драйверы в хостовой ОС.
Теперь рассмотрим среду Hyper-V, в которой запущено, помимо хостовой ОС, еще три виртуальных машины. На одной из них установлена ОС Windows и установлены интеграционные компоненты (ОС Windows 7 и Windows Server 2008 R2 включают интеграционные компоненты в себя), на другой установлена ОС, не поддерживающая интеграционные компоненты (либо же они просто не установлены), а на третьей установлена ОС Linux, для которой существуют интеграционные компоненты (на данный момент поддерживаются только SLES и RHEL).
Итак, в родительской партиции, в пространстве пользователя, имеются:
В пространстве ядра родительской партиции выполняются:
Рассмотрим теперь сами виртуальные машины. Как уже было сказано, каждая виртуальная машина работает в своем изолированном окружении, именуемом партицией. Внутри каждой виртуальной машины есть клиент сервиса виртуализации (VSC), который и предоставляет гостевой ОС интерфейс виртуальных устройств, и осуществляет их взаимодействие с родительской партицией через VMBus. Если внутри гостевой ОС установлены интеграционные компоненты (все версии Windows, начиная с XP и Server 2003, а так же некоторые версии Linux – SLES и RHEL), то могут использоваться так называемые синтетические устройства, то есть виртуальные устройства, имеющие определенный, специфичный для Hyper-V функционал. К примеру – поддержка VMQ виртуальным сетевым адаптером, или же виртуальный SCSI-контроллер. Все эти специфические функции предоставляются провайдером сервисов виртуализации (VSP), работающем в родительской партиции. Он же преобразует запросы от виртуальных машин, идущие через VMBus, и переадресует их драйверам физических устройств. Если же интеграционные компоненты не поддерживаются гостевой ОС, или они не были установлены – используются эмулируемые устройства (Legacy Network Adapter, Virtual IDE Controller, и т.д.). В этом случае VMBus не используется, а гостевая ОС посредством драйверов эмулируемых устройств обращается с гипервизором напрямую. Гипервизор переадресует эти запросы драйверам устройств в родительской партиции через рабочий процесс виртуальной машины (VMWP), который выполняется не в пространстве ядра, а в пространстве пользователя. Это очень сильно сказывается на производительности, и пожтому использовать эмулируемые устройства крайне не рекомендуется. Их можно использовать только в том случае, когда гостевая ОС не поддерживает установку интеграционных компонент. Если же такие ОС (*BSD, неподдерживаемые версии Linux, и т.д.) достаточно активно используются в Вашей организации — стоит подумать о других платформах виртуализации, к примеру — о том же VMware ESX.
Какого-либо иного способа взаимодействия виртуальных машин между собой, с хостовой ОС или с железом – не существует. Это было сделано в целях безопасности: виртуальные машины могут взаимодействовать с хостовой ОС или между собой только через сетевые интерфейсы, какого-либо «проброса устройств», как USB, так и PCI нет. Это – опять же палка о двух концах: с одной стороны, это повышает безопасность, но с другой стороны – не позволяет гостевым ОС использовать спецефичные устройства, такие, например, как HASP-ключи или модемы. Поэтому, если в гостевой ОС необходимо использовать такие устройства (к примеру, там установлено ПО от 1С, требующее для запуска наличие аппаратного HASP-ключа) приходится пользоваться ухищрениями вроде проброса USB через TCP/IP-сеть. Делается это, как правило, с помощью стороннего ПО.
Выделением памяти и процессорного времени занимается сам гипервизор. В отличие от VMware ESX, гипервизор Hyper-V не содержит драйверов устройств и компонент, написанных сторонними разработчиками. Это позволяет уменьшить размер самого гипервизора, и повысить его надежность и безопасность. Гостевые ОС, как уже было сказано, не имеют прямого доступа к физическим процессорам и к прерываниям. Именно гипервизор выполняет роль планировщика, выделяя процессорное время каждой партиции (в том числе и родительской) в соответствии с настройками, именно гипервизор получает запросы на прерывания от партиций и транслирует их физическим процессорам, и именно гипервизор выделяет виртуальным машинам области памяти и транслирует адреса, получаемые от партиций, в физические адреса. Управление партициями осуществляется хостовой ОС посредством так называемого интерфейса гипервызовов. Пользовательский интерфейс для управления гипервизором предоставляют WMI-провайдеры посредством драйвера виртуальной инфраструктуры (VID).
На этом, пожалуй, первую часть я закончу. В следующей статье я расскажу о том, как Hyper-V работает с устройствами хранения данных (жесткие диски, внешние СХД, и т.п.).
Итак, как мы уже знаем, Hyper-V – это платформа виртуализауции серверов от Microsoft, пришедшая на смену Virtual Server. В отличие от последнего, Hyper-V – это не самостоятельный продукт, а всего-навсего компонента ОС Windows Server 2008. Итак, давайте посмотрим, что происходит с Windows Server 2008 после установки роли Hyper-V:
Как мы видим, после установки роли Hyper-V архитектура системы очень сильно меняется: если до этого ОС работала с памятью, процессором и железом напрямую, то после установки распределением памяти и процессорного времени управляет уже гипервизор. Так же появляются некоторые новые компоненты, о которых будет рассказано далее. После установки Hyper-V система создает изолированные окружения, в которых запускаются гостевые ОС, так называемые партиции (partitions). Не путать с разделами (partitions) жесткого диска. Сама хостовая ОС, в свою очередь, с момента установки Hyper-V точно так же работает в изолированной партиции, которая именуется родительской (parent partition). Партиции, в которых запускаются гостевые ОС именуются дочерними. Разница между родительской партиции и дочерними состоит в том, что только из родительской партиции может осуществляться прямой доступ к аппаратному обеспечению сервера. Все остальные партиции полностью изолированы как друг от друга, так и от аппаратного обеспечения самого сервера. Все взаимодействие с железом идет через драйверы, работающие внутри хостовой ОС, то есть через родительскую партицию. Каждая виртуальная машина имеет набор виртуальных устройств (сетевой адаптер, видеоадаптер, контроллер дисков, и т.д.), которые взаимодействуют с родительской партицией посредством так называемой шины виртуальных устройств (VMBus). И уже в родительской партиции все обращения к виртуальным устройствам передаются драйверам железа. В этом – коренное отличие Hyper-V от VMware ESX: в ESX драйверы устройств «вмонтированы» в сам гипервизор. Хорошо это или плохо – однозначно сказать невозможно. С одной стороны – безусловно хорошо: гипервизор ESX может работать самостоятельно, без необходимости в хостовой ОС, и поэтому имеет намного меньшие требования по памяти и дисковому пространству. С другой же стороны, список поддерживаемого железа очень сильно ограничен, и установить новые драйверы в ESX невозможно. Поэтому может сложиться ситуация, что при использовании VMware ESX когда появляется, к примеру, новый драйвер, поддерживающий какие-то особые функции железа – придется ждать новой версии гипервизора. Возможна и обратная ситуация: при замене железа на новое может возникнуть необходимость в переходе на новый гипервизор. В Hyper-V же будет достаточно просто установить соответствующие драйверы в хостовой ОС.
Теперь рассмотрим среду Hyper-V, в которой запущено, помимо хостовой ОС, еще три виртуальных машины. На одной из них установлена ОС Windows и установлены интеграционные компоненты (ОС Windows 7 и Windows Server 2008 R2 включают интеграционные компоненты в себя), на другой установлена ОС, не поддерживающая интеграционные компоненты (либо же они просто не установлены), а на третьей установлена ОС Linux, для которой существуют интеграционные компоненты (на данный момент поддерживаются только SLES и RHEL).
Итак, в родительской партиции, в пространстве пользователя, имеются:
- WMI-провайдеры – позволяют управлять виртуальными машинами как локально, так и удаленно.
- Сервис управления виртуальными машинами (VMMS) – собственно говоря, управляет виртуальными машинами.
- Рабочие процессы виртуальных машин (VMWP) – процессы, в которых выполняются все действия виртуальных машин – обращение к виртуальным процессорам, устройствам, и т.д.
В пространстве ядра родительской партиции выполняются:
- Драйвер виртуальной инфраструктуры (VID) – осуществляет управление партициями, а так же процессорами и памятью виртуальных машин.
- Провайдер сервисов виртуализации (VSP) – предоставляет специфические функции виртуальных устройств (так называемые «синтетические устройства) посредством VMBus и при наличии интеграционных компонент на стороне гостевой ОС.
- Шина виртуальных устройств (VMBus) – осуществляет обмен информацией между виртуальными устройствами внутри дочерних партиций и родительской партицией.
- Драйверы устройств – как уже говорилось выше, только родительская партиция имеет прямой доступ к аппаратным устройствам, и потому именно внутри нее работают все драйверы.
- Windows Kernel – собственно ядро хостовой ОС.
Рассмотрим теперь сами виртуальные машины. Как уже было сказано, каждая виртуальная машина работает в своем изолированном окружении, именуемом партицией. Внутри каждой виртуальной машины есть клиент сервиса виртуализации (VSC), который и предоставляет гостевой ОС интерфейс виртуальных устройств, и осуществляет их взаимодействие с родительской партицией через VMBus. Если внутри гостевой ОС установлены интеграционные компоненты (все версии Windows, начиная с XP и Server 2003, а так же некоторые версии Linux – SLES и RHEL), то могут использоваться так называемые синтетические устройства, то есть виртуальные устройства, имеющие определенный, специфичный для Hyper-V функционал. К примеру – поддержка VMQ виртуальным сетевым адаптером, или же виртуальный SCSI-контроллер. Все эти специфические функции предоставляются провайдером сервисов виртуализации (VSP), работающем в родительской партиции. Он же преобразует запросы от виртуальных машин, идущие через VMBus, и переадресует их драйверам физических устройств. Если же интеграционные компоненты не поддерживаются гостевой ОС, или они не были установлены – используются эмулируемые устройства (Legacy Network Adapter, Virtual IDE Controller, и т.д.). В этом случае VMBus не используется, а гостевая ОС посредством драйверов эмулируемых устройств обращается с гипервизором напрямую. Гипервизор переадресует эти запросы драйверам устройств в родительской партиции через рабочий процесс виртуальной машины (VMWP), который выполняется не в пространстве ядра, а в пространстве пользователя. Это очень сильно сказывается на производительности, и пожтому использовать эмулируемые устройства крайне не рекомендуется. Их можно использовать только в том случае, когда гостевая ОС не поддерживает установку интеграционных компонент. Если же такие ОС (*BSD, неподдерживаемые версии Linux, и т.д.) достаточно активно используются в Вашей организации — стоит подумать о других платформах виртуализации, к примеру — о том же VMware ESX.
Какого-либо иного способа взаимодействия виртуальных машин между собой, с хостовой ОС или с железом – не существует. Это было сделано в целях безопасности: виртуальные машины могут взаимодействовать с хостовой ОС или между собой только через сетевые интерфейсы, какого-либо «проброса устройств», как USB, так и PCI нет. Это – опять же палка о двух концах: с одной стороны, это повышает безопасность, но с другой стороны – не позволяет гостевым ОС использовать спецефичные устройства, такие, например, как HASP-ключи или модемы. Поэтому, если в гостевой ОС необходимо использовать такие устройства (к примеру, там установлено ПО от 1С, требующее для запуска наличие аппаратного HASP-ключа) приходится пользоваться ухищрениями вроде проброса USB через TCP/IP-сеть. Делается это, как правило, с помощью стороннего ПО.
Выделением памяти и процессорного времени занимается сам гипервизор. В отличие от VMware ESX, гипервизор Hyper-V не содержит драйверов устройств и компонент, написанных сторонними разработчиками. Это позволяет уменьшить размер самого гипервизора, и повысить его надежность и безопасность. Гостевые ОС, как уже было сказано, не имеют прямого доступа к физическим процессорам и к прерываниям. Именно гипервизор выполняет роль планировщика, выделяя процессорное время каждой партиции (в том числе и родительской) в соответствии с настройками, именно гипервизор получает запросы на прерывания от партиций и транслирует их физическим процессорам, и именно гипервизор выделяет виртуальным машинам области памяти и транслирует адреса, получаемые от партиций, в физические адреса. Управление партициями осуществляется хостовой ОС посредством так называемого интерфейса гипервызовов. Пользовательский интерфейс для управления гипервизором предоставляют WMI-провайдеры посредством драйвера виртуальной инфраструктуры (VID).
На этом, пожалуй, первую часть я закончу. В следующей статье я расскажу о том, как Hyper-V работает с устройствами хранения данных (жесткие диски, внешние СХД, и т.п.).
