В проблематике технологий виртуализации тема гипервизоров, которая доминировала в 2007—2008 гг., с выпуском в прошлом году Microsoft Hyper-V и Citrix XenServer явно отошла на второй план, уступив место вопросам управления виртуальными средами. И в целом понятно почему.

До выхода этих двух продуктов именно вопрос гипервизора был ключевым при выборе поставщика технологий. Ведь система на базе настоящего гипервизора была только у VMware — ESX Server. У Microsoft был только Virtual Server, в котором управление виртуальными машинами (ВМ) реализовано с использованием хостовой ОС, что для производственного применения не очень хорошо. XenServer уже был на рынке, но принадлежал небольшой компании, веса которой было недостаточно для серьезного присутствия на корпоративном рынке. Потом это решающее конкурентное преимущество у VMware исчезло: Microsoft сделала супервизор, а XenServer перешел в руки Citrix, более авторитетного ИТ-игрока. Супервизорных решений стало достаточно много, к тому же они быстро перешли в разряд бесплатных (прямое следствие возросшей конкуренции), и акцент борьбы за заказчика переместился на уровень выше — в сферу управления виртуальными средами.

Но смещению это фокуса способствовало также и развитие потребностей заказчиков, которые как раз год назад, освоив технологию виртуализации отдельных серверов, стали переходить к решению задачи комплексного управления виртуальной ИТ-инфраструктурой. В этом плане вполне уместно использовать авторитет IDC, которая еще два года назад сказала о начале нового периода применения технологий виртуализации (Virtualization 2.0), когда заказчики, решив в основном вопросы эффективности использования вычислительных ресурсов, сконцентрируются на вопросах повышения надежности и доступности сервисов. Правда, эти слова IDC относились к американскому рынку, у нас этап V2.0 еще впереди.

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

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

Виртуальные машины и гипервизоры

Сначала нужно уточнить, что термин гипервизор (hypervisor) на самом деле используется в двух понятиях, которые нужно различать. Первое, широкое, включает все виды технологий поддержки исполнения виртуальных машин (ВМ). Более узкое — один из вариантов таких решений, основанный на отсутствии хостовой ОС.

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

В реализации технологий ВМ выделяются три основных подхода (рис. 1). ·

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

Итак, в широком смысле гипервизор — это все три перечисленные выше вида, а в узком — это гипервизор первого типа. Это нужно знать для понимания того, что именно имеется в виду, когда о некотором продукте говорится, что он — гипервизор.

Напомним, что именно гипервизор первого типа считается классическим вариантом реализации архитектуры ВМ, как раз он был впервые реализован компанией IBM в 1960 г. в виде системы CP/CMS, которая считается прародителем сегодняшней z/VM*.

Виртуализация же систем x86 начиналась в конце 90-х с использования второго (хостового) варианта, который долгое время доминировал на рынке и тогда назывался просто “ПО виртуализации”. Термин гипервизор стал применяться применительно к x86-компьютерам лишь 3—4 года назад в связи с началом широкого применения первого варианта другими разработчиками для создания собственных продуктов и чтобы отличить его от традиционных хостовых решений. В 2008 г. тип 1 гипервизора стал уже доминирующим на рынке, и потому данный термин теперь используется для обозначения всего ПО исполнения виртуальных машин.

Тут нужно подчеркнуть, что реализация механизма ВМ для компьютеров x86 является непростой задачей по целому ряду причин, одна из которых — необходимость преодоления унаследованных особенности этой программно-аппаратной архитектуры. В частности, исходная архитектура x86 не позволяла параллельное исполнение некоторых команд процессора в привилегированном режиме работы (что нужно было в случае работы нескольких ОС). Для ее решения использовались два основных метода виртуализации: полная виртуализация (Full, Native Virtualization) и паравиртуализация (Paravirtualization). В первом случае конфликты исключались с помощью бинарной трансляции “плохих команд” на уровне гипервизора, во втором — за счет исключения этих команд путем коррекции ядра гостевой ОС.

Однако в 2004—2005 гг. Intel и AMD внесли коррективы в архитектуру своих процессоров, реализовав в них технологии соответственно Intel VT и AMD SVM. Это существенно упростило создание виртуализационных средств, что способствовало расширению числа разработок в этой области. Но здесь следует отметить, что многие появившиеся в последнее время гипервизоры (например, Microsoft Hyper-V) изначально ориентированы на работу только с современными процессорами с поддержкой архитектуры Intel VT или AMD SVM.

Гипервизор гипервизору рознь

В настоящее время системы виртуализации серверов на базе хостового гипервизора (тип 2) уходят с рынка, используются фактически только в унаследованных системах для проведения макетных исследований или в каких-то нишевых областях применения. В качестве примера можно привести VMware Server, Microsoft Virtual Server и Parallels Server for Mac.

Доминирующее положение на рынке занимают виртуализационные решения, реализованные на базе “настоящего” гипервизора (тип 1). Хотя на самом деле вопрос о том, к какому типу гипервизора относится то или иное решение, является спорным. Википедия причисляет к типу 1 почти все имеющиеся на рынке продукты — VMware ESX Server, Microsoft Hyper-V, Citrix XenServer, Oracle VM, Sun Logical Domains Hypervisor и др. Однако более внимательное изучение этого вопроса говорит о том, что “настоящий” тип 1 — это только VMware ESX, а остальные — это, скорее, гипервизоры смешанного типа.

Попробуем рассмотреть данный вопрос на примере двух главных конкурентов на этом рынке — VMware ESX и Microsoft Hyper-V (рис. 2) **.

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

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

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

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

Для ускорения же работы на уровне драйверов Microsoft использует два механизма взаимодействия прикладных BM с родительской. В одном случае применяется специальный внутренний интерфейс VMBus, который позволяет общаться ВМ между собой напрямую. Он доступен для ВМ, реализованных на базе Windows, а также Xen, но только для тех разработчиков, с кем у Microsoft есть соответствующий уровень сотрудничества (сейчас это Novell, Citrix, Red Hat). Для всех остальных ОС используется второй вариант полной эмуляции драйверов.

Как свое преимущество Microsoft также подчеркивает наличие в ее Hyper-V проверенной модели драйверов, которая развивается в рамках Windows Server в целом.

Кто главнее — OC или гипервизор?

Можно отдельно обсуждать вопросы технических преимуществ и недостатков одного и другого подхода, но вполне очевидно, что в стратегическом плане речь идет о другом: смогут ли гипервизоры заменить традиционные ОС, в роли ключевого компонента всей современной ИТ-архитектуры. VMware уже давно двигалась в направлении положительного ответа на этот вопрос и открыто еще в 2008 г. заявила о своих намерениях. Уже в ближайшие месяцы компания должна сделать решительный шаг по реализации этих планов, выпустив новую версию своей виртуализационной платформы vSphere 4, которая уже объявлена первой на ИТ-рынке облачной ОС нового поколения.

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

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

*Термин “гипервизор” специально придуман IBM в 1972 г. для того, чтобы подчеркнуть отличие от термина супервизор, которым традиционно называли ядро ОС, а точнее, менеджер ресурсов ядра в эпоху мэйнфреймов. Гипервизор является расширением и обобщением понятия супервизора: подобно тому, как супервизор в ядре ОС обеспечивает изоляцию пользовательских программ друг от друга, выделение и освобождение ресурсов для пользовательских процессов, так и гипервизор обеспечивает изоляцию и управление ресурсами для самих ОС как целого, вместе с их пользователями и процессами (Википедиа).

**При многих технологических различиях архитектурные подходы Microsoft Hyper-V и Citrix XenSever в целом очень близки, что и определяет их более тесный на рынке альянс.