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

Но от новых веяний никуда не деться, и все чаще компании при проектировании новой или обновлении существующей инфраструктуры на стандартной платформе х86 вспоминают о технологиях виртуализации, понимая, что в обычных условиях физический сервер просто не используется на полную мощность. До недавнего времени пакетом, который рассматривался в первую очередь, был VMware ESX Server. Это платформа, позволяющая создавать виртуальные системы «на голом железе», а значит, повышать производительность работы системы и ее устойчивость. Но и стоимость данного решения была иногда выше стоимости самого сервера, на котором планировалось развернуть виртуальные системы.

Недавно компания Microsoft анонсировала выход новой серверной операционной системы Windows Server 2008, в составе которой будут использоваться встроенные средства виртуализации с использованием технологий Intel VT и AMD-V. Данные средства вполне могут составить конкуренцию VMware ESX Server, и они значительно превосходят существующий продукт Microsoft Virtual Server 2005, но давайте обо всем по порядку.

Немного теории

Что собой представляют технологии виртуализации в разном исполнении? Чаще всего используемая среда выглядит следующим образом (рис. 1).

Рисунок 1. Виртуализация на уровне операционной системы

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

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

Более производительной архитектурой виртуализации является подход, где установка виртуальных систем происходит без «прослойки» операционной системы (рис. 2).

Рисунок 2. Виртуализация на уровне гипервизора

В этом случае между аппаратной составляющей и гостевыми операционными системами существует только один слой программного обеспечения — менеджер виртуальных машин. Другой вариант данного подхода предполагает использование гипервизора, задача которого — управление операционными средами или разделами (partitions). Каждый раздел — это набор из вычислительных ресурсов системы: определенного процента использования процессора, оперативной памяти, пространства на жестком диске, устройства ввода/вывода. Задачи гипервизора — это распределение имеющихся ресурсов между разделами и контроль над их использованием операционными средами.

В свою очередь, использование второго метода виртуализации также можно разбить на два варианта (рис. 3a, 3б).

Рисунок 3а. Использование стека драйверов на уровне гипервизора

Рисунок 3б. Использование стека драйверов на уровне гостевой ОС

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

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

Второй вариант лишен этого недостатка.

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

Последний вариант как раз и реализован в новой технологии виртуализации в Windows Server 2008. Построение виртуальных сред показано на рис. 4.

Рисунок 4. Построение механизма виртуализации в Windows Server 2008

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

Ключевые отличия технологий, реализованных в Virtual Server 2005 R2 и Windows Server 2008 Virtualization, перечислены в таблице.

Судя по данным таблицы, виртуализация в Windows Server 2008 имеет более широкую функциональность по сравнению с Virtual Server, но и некоторые ограничения при использовании, о которых следует упомянуть. Во-первых, для базовой операционной системы предусмотрено использование только 64-разрядной платформы, так как это необходимо для поддержки 64-разрядных гостевых операционных систем. Во-вторых, для работы гипервизора требуются процессоры с аппаратной поддержкой виртуализации.

Большинство современных серверов уже поставляется с процессорами, которые поддерживают технологию виртуализации (например, для процессоров Intel Xeon это процессоры семейства 51xx, 53xx и 54хх, для процессоров AMD — четырехъядерные Opteron).

Возможности Hyper-V

Что собой представляет новая технология Hyper-V, предлагаемая компанией Microsoft, и какие функции становятся доступны системным администраторам?

Ключевые возможности, предоставляемые новой технологией, следующие:

  • 64-разрядная архитектура гипервизора обеспечивает поддержку широкого круга аппаратных устройств и более высокий (по сравнению с Virtual Server) уровень защиты и производительности работы системы (в этом мы попробуем убедиться позже);
  • поддержка широкого круга операционных систем в качестве гостевых, включая 32- и 64-разрядные серверные платформы, такие как Windows, Linux и др. Следует отметить, что Linux-платформы должны обеспечивать поддержку Xen;
  • поддержка мультипроцессорной обработки SMP (Symmetric Multiprocessor) в виртуальной среде, что позволяет добавлять в виртуальную среду до восьми процессоров (фактически речь идет о восьми процессорных ядрах). Правда, возможность использования мультипроцессорной конфигурации доступна только при запуске в качестве гостевой системы Windows Server 2008. При использовании Windows Server 2003 придется применять однопроцессорную конфигурацию;
  • балансировка нагрузки между виртуальными системами. Hyper-V включает в себя функции виртуального коммутатора, что позволяет воспользоваться функциями компонента балансировки нагрузки Network Load Balancing (NLB);
  • поддержка миграции виртуальной системы с одной физической платформы на другую, что позволяет построить кластерную среду, которая обеспечивает переход с одного сервера на другой в случае сбоя первого или миграцию на более производительный сервер;
  • создание снимков виртуальной системы. Данная особенность очень полезна при использовании сервера для тестирования приложений и служб, так как в случае проблем с работой после установки нового приложения администратор сможет восстановить предыдущее состояние сервера, минимизируя время, которое понадобилось бы для удаления приложения или полной переустановки системы;
  • гибкое управление ресурсами виртуальной среды. Администратор при необходимости может выделять дополнительные ресурсы для работы системы без остановки последней;
  • интеграция со средствами управления System Center для мониторинга и управления виртуальными средами. Следует отметить, что Hyper-V предоставляет собственные счетчики производительности для отображения состояния виртуальной среды, точно так же как интерфейсы WMI и API, что предоставляет широкие возможности для разработки собственных сценариев управления виртуальной средой;
  • поддержка виртуальных сетей для сложной комплексной конфигурации.

Управление только на уровне единичного сервера позволяет управлять параметрами виртуального сервера, создавать и восстанавливать снимки состояний системы (что мы рассмотрим далее). Более интересная комбинация возможна при интеграции с System Center Operation Manager для отслеживания и управления виртуальными средами на основе анализа состояний системы. Например, при загрузке одной из виртуальных систем, обеспечивающей доступ к Web-серверу, выше указанного порога, возможен запуск дополнительной виртуальной системы для работы на NLB-кластере совместно с текущей системой. Таким образом, сценарии могут быть самые различные, и это уже тема для отдельной статьи.

Установка базовой операционной системы

Чтобы попробовать работать с Hyper-V, воспользуемся Windows Server 2008 Enterprise Edition RC1 и системой с процессором, который поддерживает технологию виртуализации. При загрузке выбираем вариант полной установки, хотя на промышленных серверах такой необходимости нет — можно задействовать режим Windows Core. Режим Windows Core оптимально подходит для работы с виртуальными серверами, так как мы не планируем осуществлять установку и работу служб в базовой операционной системе, отводя ей только роль «управляющего» гостевыми виртуальными системами (более того, не рекомендуется установка дополнительных ролей на сервере с установленной ролью Hyper-V).

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

По завершении установки запускаем приложение Server Manager и в разделе Roles Summary выбираем пункт Add Roles. В мастере установки ролей необходимо выбрать Hyper-V. Далее, проходя по этапам мастера установки ролей, вводим необходимые параметры для запуска Hyper-V. По завершении необходимо перезагрузить систему, а затем зарегистрироваться с учетной записью пользователя, под которой была выполнена установка роли. Для управления виртуальными средами используется оснастка MMC Hyper-V Manager.

Если изначально выбрать режим установки Windows Core, то установка роли производится с помощью команды

Start /w ocsetup Microsoft-Hyper-V

Управление же виртуальной средой нужно будет осуществлять с консоли управления, установленной на другом сервере.

Установка гостевой операционной системы

Добавить новую гостевую систему помогает мастер, и, пройдя через все этапы, вы создадите файл для виртуального жесткого диска и укажете все параметры конфигурации системы (экран 1). Правда, есть нюанс — с помощью мастера нельзя сразу указать количество виртуальных процессоров, выделяемых для системы, — процессорных ядер (я проводил тесты на однопроцессорном двухъядерном компьютере). И невозможно указать, что вместо использования файла *.vhd следует использовать раздел жесткого диска, что полезно для ускорения работы дисковой системы. Но эти параметры можно скорректировать позже, сразу после создания виртуальной системы.

Экран 1. Создание виртуальной системы в Windows Server 2008

Настройка виртуальной системы не вызвала вопросов, а вот с загрузкой системы был небольшой сюрприз — при старте выдавалось сообщение, что гипервизор не работает, поэтому виртуальная машина не может быть запущена. Вопрос решился достаточно просто: в настройках BIOS компьютера по умолчанию был выключен параметр, отвечающий за использование функций разграничения прав при работе с виртуальными ресурсами. После его включения и повторной загрузки системы при запуске виртуального сервера появилось окно Hyper-V, и система продолжила установку (экран 2).

Экран 2. Запуск среды виртуализации Microsoft Hyper-V

Производительность работы физической и виртуальной системы

Описанный выше метод реализации виртуализации в Windows Server 2008 имеет преимущества в производительности по сравнению с системой, которая работает над прослойкой в виде операционной системы под управлением менеджера виртуальных машин. Но насколько заметно упадет производительность при работе между операционной системой без использования Hyper-V и гостевой операционной системой, работающей с использованием технологии Hyper-V?

Чтобы это выяснить, я решил использовать утилиту PCMark05 версии 1.2.0, которая поддерживает работу в системе Windows Vista и позволяет проводить синтетические тесты. Меня интересовали три параметра: CPU Benchmark, Memory Benchmark и HDD Benchmark. Тесты проводились в такой последовательности:

  1. Устанавливался Windows Server 2008 RC1 Enterprise Edition и производились тесты.
  2. Добавлялась роль Hyper-V, потом в качестве виртуального сервера — Windows Server 2008 RC1 Enterprise Edition и производились тесты.
  3. Удалялась роль Hyper-V, устанавливался Virtual Server 2005 R2 SP1, в нем в качестве виртуального сервера — Windows Server 2008 RC1 Enterprise Edition и производились тесты.

Конечно же, разница в функциональности продуктов Windows Server Virtualization и Microsoft Virtual Server 2005 R2 SP1 не позволяет говорить об объективно равных условиях тестирования. Windows Server Virtualization умеет работать с 64-разрядными гостевыми системами, и можно указать, сколько виртуальных процессоров выделить для разделов, а Virtual Server 2005 R2 SP1 не имеет такой возможности. Но все же ради любопытства все три конфигурации были опробованы (для третьей конфигурации была взята 32-разрядная версия Windows Server 2008 RC1 Enterprise Edition). Результаты полученных тестов отображены на графиках (рис. 5).

Рисунок 5. Сравнение производительности систем с использованием PCMark 05

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

Снимки виртуальных систем

Одна из возможностей, которая включена в Hyper-V, — это использование службы снимков VSS для создания образов состояния системы. Использование снимков возможно с любой виртуальной средой, даже в процессе установки системы, так как работа снимков реализована на слое виртуализации. Принцип работы снимков заключается в следующем:

  • при первом создании снимка формируется файл AVHD, в который начинают сохраняться изменения, производимые в дисковой подсистеме. При этом в оригинальный VHD-файл изменения не вносятся;
  • при повторном создании снимка создается следующий файл AVHD, в который начинают записываться вносимые изменения, а предыдущий файл AVHD не изменяется.

Для создания снимка в консоли управления следует выбрать виртуальную машину, вызвать контекстное меню и нажать пункт Snapshot (экран 3). При этом можно задать имя для снимка либо выбрать автоматическую генерацию имени.

Экран 3. Создание снимка виртуальной системы

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

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

При повторном снятии снимка с виртуальной системы в консоли отображается дерево снимков, которое указывает на зависимость второго снимка от начального. Также создается пара файлов BIN/VSV состояния системы и файл AVHD.

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

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

Экран 4. Управление снимками виртуальной системы

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

Виртуализацию — в жизнь

Предложенный Windows Server 2008 механизм виртуализации Hyper-V, несомненно, будет востребован при построении ИТ-инфраструктур предприятий. Ряд преимуществ по сравнению с Virtual Server 2005 R2 SP1 позволит администратору более гибко управлять вычислительными ресурсами сервера, обеспечивая необходимый уровень производительности служб. Дополнительные функции, такие как «горячее» добавление памяти, процессорной мощности, дисковой и сетевой подсистем, позволят избежать необходимости перезагрузки виртуальной среды, а умеренные вычислительные затраты на работу гипервизора позволяют говорить о высоком коэффициенте полезного действия вычислительных мощностей сервера.

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

Алексей Приймак (alexey.priymak@gmail.com) — ведущий консультант по инфраструктурным решениям в украинской компании-интеграторе «БМС Консалтинг». Имеет сертификаты MCSE, MCT


Таблица. Различия Virtual Server 2005 R2 и Windows Server 2008 Virtualization

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF