Низкоуровневые оболочки типа 1 выполняются прямо на базовом физическом оборудовании главных компьютеров и выполняют роль управляющих программ. Другими словами, они выполняются «на железе». В этом случае гостевые операционные системы выполняются на нескольких виртуальных машинах, размещенных над слоем низкоуровневой оболочки (см. Рисунок 1).
Так как низкоуровневые оболочки типа 1 выполняются прямо на оборудовании, а не в среде ОС, они обычно обеспечивают оптимальную производительность, доступность и безопасность по сравнению с другими типами. Низкоуровневые оболочки типа 1 в том числе реализуются в следующих продуктах виртуализации сервера:
Низкоуровневые оболочки типа 2 выполняются в среде ОС, запущенной на главном компьютере. В этом случае гостевые операционные системы выполняются на виртуальных машинах над низкоуровневой оболочкой (см. Рисунок 2). Виртуализация такого типа обычно называется размещенной виртуализацией. Сравнение рисунка 2 и рисунка 1 позволяет понять, что гостевые операционные системы, запущенные в виртуальных машинах платформ низкоуровневой оболочки типа 2, отделены от базового оборудования еще одним уровнем. Наличие дополнительного уровня между виртуальными машинами и оборудованием вызывает снижение производительности на платформах оболочки типа 2 и ограничивает количество виртуальных машин, которые можно запускать на практике. Низкоуровневые оболочки типа 2 в том числе реализуются в следующих продуктах виртуализации сервера:
Монолитная архитектура низкоуровневой оболочки предполагает наличие драйверов устройств, которые поддерживают оболочку, размещены в ней и управляются ей (см. Рисунок 3).
Монолитная архитектура имеет как преимущества, так и некоторые недостатки. Например, монолитные низкоуровневые оболочки не требуют управляющей (родительской) операционной системы, так как все гостевые системы взаимодействуют напрямую с базовым оборудованием компьютера с помощью драйверов устройств. Это одно из преимуществ монолитной архитектуры. С другой стороны тот факт, что драйверы должны быть разработаны специально для низкоуровневой оболочки, представляет существенные трудности, так как на рынке распространены различные типы материнских плат, контроллеров хранения, сетевых адаптеров и другого оборудования. В результате производителям монолитных платформ низкоуровневых оболочек необходимо тесно работать с производителями оборудования, чтобы убедиться в том, что драйверы для этих устройств поддерживают низкоуровневую оболочку. Кроме того, это делает производителей оболочек зависимыми от производителей оборудования, которые поставляют необходимые драйверы для своих продуктов. Таким образом, круг устройств, которые могут использоваться в виртуализованных операционных системах на монолитных платформах низкоуровневой оболочки значительно уже по сравнению с ситуацией запуска тех же операционных систем на физических компьютерах. Важной особенностью этой архитектуры является то, что она игнорирует один из наиболее важных принципов безопасности — необходимость эшелонированной защиты. При эшелонированной защите создается несколько рубежей обороны. В этой модели эшелонированная защита отсутствует, так как все выполняется в наиболее привилегированной части системы. Примером продукта для виртуализации сервера, который использует монолитную архитектуру низкоуровневой оболочки, является VMware ESX Server.Микроядерные низкоуровневые оболочки не требуют специальных драйверов, так как в роли основного (родительского) раздела выступает операционная система. Такой раздел предоставляет среду выполнения, необходимую для доступа драйверов устройства к базовому физическому оборудованию главного компьютера. Разделы будут рассмотрены далее, а сейчас представьте, что термин «раздел» эквивалентен виртуальной машине. На платформах микроядерной низкоуровневой оболочки установка драйверов устройств требуется только для физических устройств, работающих в родительском разделе. Установка этих драйверов в гостевых операционных системах не требуется, так как для доступа к физическому оборудованию главного компьютера гостевым операционным системам необходимо всего лишь обратиться к родительскому разделу. Другими словами, микроядерная архитектура не предполагает прямого доступа гостевых операционных систем к базовому оборудованию. Доступ к физическим устройствам осуществляется только путем взаимодействия с родительским разделом. На рисунке 4 микроядерная архитектура низкоуровневой оболочки показана более подробно.
Микроядерная архитектура имеет несколько преимуществ по сравнению с монолитной. Во-первых, отсутствие необходимости в специальных драйверах позволяет использовать широкий спектр существующих драйверов, предоставленных производителем. Во-вторых, драйверы устройств не входят в оболочку, поэтому она создает меньше нагрузки, имеет меньший размер и большую устойчивость. В-третьих, что наиболее важно, площадь потенциальной атаки сведена к минимуму, так как в оболочку не загружается посторонний код (драйверы устройств создаются сторонними компаниями, поэтому считаются посторонним кодом с точки зрения разработчика оболочки). Согласитесь, что проникновение вредоносного программного обеспечения в оболочку и установление контроля над всеми виртуальными ОС компьютера — это последнее, что вам хотелось бы испытать. Единственным недостатком микроядерной конструкции является необходимость особого, родительского раздела. Это повышает нагрузку на систему (хотя обычно она минимальна), так как доступ дочерних разделов к оборудованию требует их взаимодействия с родительским разделом. Существенным преимуществом микроядерной архитектуры Hyper-V является обеспечение эшелонированной защиты.Технология Hyper-V позволяет свести выполнение кода в низкоуровневой оболочке к минимуму и передавать большее количество функций вверх по стеку (например, интерфейсы конечного автомата и управления, которые в пользовательском режиме выполняются выше по стеку). Что же можно привести в качестве примера платформы виртуализации сервера с микроядерной архитектурой? Несомненно, это Microsoft Hyper-V, в родительском разделе которого выполняется Windows Server 2008 или более поздние версии.Ниже представлены некоторые основные особенности исходной версии платформы Microsoft Hyper-V:
В версии Windows Server 2008 R2 в роль Hyper-V добавлены новые функции. Они повышают гибкость, производительность и масштабируемость Hyper-V. Рассмотрим их более подробно.
Hyper-V R2 содержит следующие новые функции, которые повышают гибкость развертывания и обслуживания инфраструктуры виртуализации сервера:
Hyper-V R2 содержит следующие новые функции, которые могут повысить производительность инфраструктуры виртуализации сервера:
Также можно работать с любыми сочетаниями одноядерных, двухъядерных и четырехъядерных процессоров, если общее количество виртуальных машин не превышает 384, а общее количество виртуальных процессоров, выделенных виртуальным машинам, не превышает 512. Такие возможности позволяют Hyper-V R2 обеспечивать максимально возможные на рынке значения плотности виртуальных машин на данный момент. Для сравнения: предыдущая версия Hyper-V в Windows Server 2008 SP2 поддерживала всего до 24 логических процессоров и до 192 виртуальных машин. Обратите внимание на то, что при использовании отказоустойчивых кластеров Hyper-V R2 поддерживает до 64 виртуальных машин на узел кластера.
При применении соответствующих процессоров (например, процессоров Intel с расширенными таблицами страниц EPT начиная с поколения i7 или последних моделей процессоров AMD с вложенными таблицами страниц NPT) Hyper-V R2 существенно увеличивает производительность системы во многих случаях. Повышение производительности вызвано улучшением технологии управления памятью и снижением количества копий памяти, необходимых для использования этих функций процессора. Производительность повышается в особенности при работе с крупными наборами данных (например, с Microsoft SQL Server). Использование памяти для низкоуровневой оболочки Microsoft Hypervisor может сократиться с 5 процентов до 1 процента от общей физической памяти. Таким образом, дочерним разделам будет доступно больше памяти, что позволяет добиться высокой степени консолидации.
Windows Vista и Windows Server 2008. Функция VM Chimney по умолчанию отключена. Для работы ее необходимо включить на физическом сетевом адаптере и в главной операционной системе.Подробные сведения см. на странице http://support.microsoft.com/kb/951037.
Обратите внимание на то, что эту функцию могут использовать не все приложения. В частности, приложения, использующие предварительно размещенные буферы и продолжительные подключения с большими объемами передачи данных, получат наибольшие преимущества от включения этой функции. Кроме того, следует помнить о том, что физические сетевые адаптеры с поддержкой разгрузки TCP Chimney могут обрабатывать ограниченное количество разгруженных подключений, которые используются всеми виртуальными машинами узла.
В результате это позволяет повысить пропускную способность сети и сократить интенсивность использования ЦП при переносе крупных файлов.
Hyper-V R2 содержит следующие новые функции, которые повышают масштабируемость инфраструктуры виртуализации сервера:
Широкие возможности Hyper-V уже привели к тому, что эта технология заменяет Microsoft Virtual Server во многих организациях, ранее использовавших Virtual Server для консолидации серверов, обеспечения непрерывности работы, тестирования и разработки. При этом Virtual Server до сих пор может найти применение в корпоративной инфраструктуре виртуализации. В таблице 1 приводится сравнение некоторых функций и технических данных Hyper-V и Virtual Server.
Таблица 1. Сравнение компонентов и технических характеристик Virtual Server 2005 R2 SP1 и Hyper-V R2
Компонент или технические данные |
Virtual Server 2005 R2 SP1 |
Hyper-V R2 |
Архитектура |
||
Тип виртуализации |
Размещенные системы |
На основе низкоуровневой оболочки |
Производительность и масштабируемость |
||
32-разрядные виртуальные машины |
Да |
Да |
64-разрядные виртуальные машины |
Нет |
Да |
32-разрядные узлы |
Да |
Нет |
64-разрядные узлы |
Нет |
Да |
Виртуальные машины с несколькими процессорами |
Нет |
Да |
Максимальный объем гостевой оперативной памяти на каждую виртуальную машину |
3,6 ГБ |
64 ГБ |
Максимальное количество гостевых ЦП на каждую виртуальную машину |
1 |
4 |
Максимальная оперативная память узла |
256 ГБ |
1 ТБ |
Максимальное количество запущенных виртуальных машин |
64 |
384 |
Управление ресурсами |
Да |
Да |
Доступность |
||
Переключение гостевых систем при отказе |
Да |
Да |
Переключение главных компьютеров при отказе |
Да |
Да |
Миграция узлов |
Да |
Да |
Моментальные снимки виртуальных машин |
Нет |
Да |
Управление |
||
Возможность расширения и управления через скрипты |
Да, COM |
Да, WMI |
Пользовательский интерфейс |
Веб-интерфейс |
Интерфейс MMC 3 0 |
Интеграция SCVMM |
SCVMM 2007 |
SCVMM 2008 |
Дополнительные сведения Для получения дополнительных сведений о возможностях Virtual Server и его загрузки перейдите на страницу http://www.microsoft.com/windowsserversystem/virtualserver/downloads.aspx. Для получения сведений о миграции виртуальных машин с Virtual Server на Hyper-V обратитесь к разделу «Virtual Machine Migration Guide: How To Migrate from Virtual Server to Hyper-V» в библиотеке TechNet по адресу http://technet.microsoft.com/en-us/library/dd296684.aspx.