Что нового в Windows Server 2012 R2 Hyper-V. Часть 1

За время паузы всего в один год, что соответствует девятимесячному циклу разработки, между выходами систем Windows Server 2012 и Windows Server 2012 R2, компании Microsoft пришлось принимать решение: стоит ли внести небольшие изменения по всему спектру механизмов Windows Server или лучше сосредоточиться на ключевых сценариях и внести значительные изменения в технологии, связанные с этими сценариями? К счастью, компания пошла по второму пути. Одним из главных направлений работы стало «облако». В результате гипервизор Hyper-V в системе Windows Server 2012 R2 может похвастаться значительными улучшениями и новыми возможностями.

Хотя масштабируемость гипервизора Hyper-V не обуславливала изменений при выпуске версии Windows Server 2012 R2 (см. врезку «Масштабируемость в числах»), другие направления выиграли от внесенных улучшений. К таким направлениям можно отнести основной формат виртуальных машин Hyper-V, активацию и подключение, виртуальное хранилище и сетевое взаимодействие, мобильность и репликацию, а также новые возможности, связанные с системами Linux. Данная статья посвящена основным улучшениям, а также изменениям в технологиях мобильности и репликации. Об остальных возможностях я расскажу во второй статье.

Формат виртуальных машин второго поколения

Основная архитектура виртуальных машин Hyper-V не претерпела существенных изменений с момента появления в системе Windows Server 2008. Эта архитектура основывалась на том, что операционные системы виртуальных машин работали в «информационном вакууме». Для операционных систем не существовало понятий виртуализации или виртуализованных устройств. А, следовательно, для их функционирования требовался определенный набор эмулированных устройств.

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

Новое поколение виртуальных машин предназначено для современных операционных систем. Новый формат убирает все эмулируемые устройства, необходимые для «изолированных» операционных систем. В списке потерь значатся эмулируемые под интерфейс PS/2 мышь и клавиатура, контроллер IDE (полностью), устаревший эмулируемый сетевой адаптер Intel, приводы гибких дисков и порты LPT, а также многие системные устройства, такие как мосты PCI-to-ISE и Pentium II Processor-to-PCI. Взамен остается упрощенная виртуальная машина, которая поддерживает загрузку с контроллеров SCSI или с помощью окружения Preboot Execution Environment (PXE) через синтетический (стандартный) сетевой адаптер. Кроме того, виртуальные машины второго поколения позволяют динамически менять размер загрузочного диска. На экране 1 показаны отличия содержимого диспетчера Device Manager у виртуальных машин первого и второго поколения.

Экран 1. Содержимое диспетчера Device Manager для виртуальных машин первого и второго поколения

Есть еще одно важное различие. В отличие от основанных на архитектуре BIOS виртуальных машин первого поколения, виртуальные машины второго поколения построены на архитектуре Unified Extensible Firmware Interface (UEFI) и позволяют задействовать такие механизмы, как Secure Boot. Однако это изменение также провоцирует проблемы, как минимум для тех, кто захочет обновить виртуальную машину первого поколения до формата второго поколения.

Развертывания на основе архитектуры BIOS имеют системный раздел в формате NTFS, в то время как развертывания на основе архитектуры UEFI используют системный раздел Extensible Firmware Interface в формате FAT32. Таким образом, вы не можете просто взять виртуальные жесткие диски формата Virtual Hard Disk (VHD) от виртуальной машины первого поколения и прикрепить их к виртуальной машине второго поколения, использующей формат VHDX. Единственный способ провести обновления – использовать подход с применением резервного копирования, сняв образ операционной системы с виртуальной машины первого поколения и восстановив его на новую виртуальную машину второго поколения. Сложности могут возникнуть и при таком подходе, из-за изменений в аппаратной части и из-за того, что загрузочным устройством теперь является не контроллер IDE, а контроллер SCSI.

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

На момент написания статьи виртуальные машины второго поколения поддерживают использование только 64-разрядных операционных систем версии Windows 8 и новее или Windows Server 2012 и новее. У виртуальных машин второго поколения нет модуля Compatibility Support Module (CSM), который в физической системе разрешает использование эмуляции BIOS, чтобы могли работать операционные системы, не основанные на интерфейсе UEFI OS. Следовательно, такие операционные системы не могут работать на виртуальных машинах второго поколения.

Выбрать, какое поколение использовать, достаточно просто. Если вам требуется обратная совместимость с предыдущими версиями гипервизора Hyper-V или работа с Windows Azure, задействуйте виртуальные машины первого поколения. Если обратная совместимость не нужна и вы используете поддерживаемые операционные системы, тогда смело выбирайте виртуальные машины второго поколения. Только имейте в виду, что вам понадобятся различные шаблоны для виртуальных машин первого и второго поколения, из-за несовместимости архитектур BIOS и UEFI.

Динамическое клонирование виртуальных машин

Версия Windows Server 2012 R2 вносит изменения в номенклатуру. То, что раньше называлось снимками – сохраненные состояния виртуальных машин на определенный момент времени – теперь называется контрольными точками. Это изменение унифицирует (приводит к единой номенклатуре) гипервизор Hyper-V и систему System Center Virtual Machine Manager (VMM).

Раньше у нас не было возможности экспортировать запущенную виртуальную машину или даже контрольную точку (снимок) виртуальной машины. Ситуация изменилась в версии 2012 R2 Hyper-V, которая позволяет экспортировать запущенные машины и контрольные точки запущенных машин. Данное изменение очень удобно для определенных сценариев. Например, предположим, что вы столкнулись с проблемой на виртуальной машине и хотите сохранить проблемное окружение прямо перед перезагрузкой и настройкой данной машины, чтобы иметь возможность в дальнейшем изучить проблему. Или представьте, что вы собираетесь создать тестовое окружение, основанное на производственных системах, но не хотите останавливать работу сервера. Процесс не изменился: у вас просто есть возможность экспортировать запущенную виртуальную машину или ее контрольные точки. Кроме того, экспорт можно выполнять с помощью команд Windows PowerShell с именами Export-VM и Export-VMSnapshot.

Режим расширенного сеанса

Для взаимодействия с виртуальной машиной вы обычно подключаетесь к операционной системе по протоколу RDP. Такой подход позволяет задействовать все возможности, доступные через протокол RDP, такие как буфер обмена, перенаправление принтеров и аудиоустройств, настройки экрана и т.д. Однако не всегда есть возможность подключиться к виртуальной машине по протоколу RDP. В качестве альтернативы приходится использовать функцию VMConnect, доступную при выборе действия Connect для виртуальной машины в диспетчере Hyper-V Manager. Возможности данного типа подключения исторически были сильно ограничены, он имеет жестко заданное разрешение и не обеспечивает перенаправление устройств или доступ к буферу обмена.

В версии Windows Server 2012 R2 Hyper-V впервые появился режим расширенного сеанса (Enhance Session Mode) для виртуальных машин с операционными системами Windows 8.1 и Windows Server 2012 R2. Создание данного режима стало возможным благодаря тому, что при перепроектировании операционных систем элементы протокола RDP были перенесены в архитектуру шины VMBus. При включенном режиме Enhanced Session Mode многие возможности протокола RDP теперь доступны при использовании функции VMConnect для подключения к виртуальной машине:

• настраиваемое разрешение;
• доступ к буферу обмена;
• перенаправления принтеров, аудиоустройств и дисков;
• доступ к смарт-картам и устройствам USB.

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

На экране 2 показано новое окно подключения для функции VMConnect. Вы можете задать разрешение экрана и перечень локальных ресурсов, которые необходимо сделать доступными. Обратите внимание на параметр Save my settings for future connections to this virtual machine. Если вы установите данный флаг, то все сохраненные настройки прописываются в папку \%APPDATA%\Roaming\Microsoft\Windows\Hyper-V\Client\1.0 с именем файла в формате vmconnect.rdp..config.

Экран 2. Новое окно подключения VMConnect

Несмотря на то, что стали доступны многие возможности RDP, подключение все равно рассматривается как административное, поэтому лицензия клиентского доступа Remote Data Services (RDS) не требуется. Вдобавок к обязательной установке на виртуальных машинах систем Windows 8.1 или Windows Server 2012 R2 для использования режима Enhanced Session Mode актуальны следующие требования:

• Серверная политика Enhanced Session Mode Policy в настройках сервера диспетчера Hyper-V Manager должна быть включена и установлена в значение Allow enhanced session mode. Эта политика по умолчанию отключена.
• В гостевой операционной системе должна быть запущена служба Remote Desktop Services, при этом активировать параметр Allow remote connections to this computer в настройках системы не обязательно.
• Авторизующийся пользователь должен быть членом группы локальных администраторов или группы пользователей удаленного рабочего стола в гостевой операционной системе.
• В гостевой системе должна быть завершена настройка при первом включении компьютера (этап OOBE).

Технически не являясь функцией режима Enhanced Session Mode, новая служба интеграции Guest, отключенная по умолчанию, представляет собой часть процесса расширенного взаимодействия и заслуживает упоминания. Когда эта новая служба интеграции включена, вы можете использовать команду Copy-VMFile оболочки PowerShell для копирования файлов на виртуальную машину, не устанавливая сетевое соединение. Такая возможность доступна только администраторам системы Hyper-V.

Автоматическая активация виртуальных машин

Активация виртуальных машин проблематична для многих организаций. Могут возникнуть комплексные трудности при перемещении виртуальных машин из вашего окружения в другие. Лицензия Windows Server Datacenter позволяет задействовать неограниченное количество виртуальных машин c операционной системой Windows Server, но при этом все равно должен быть предусмотрен способ активировать их:

• использовать ключ Multiple Activation Key (MAK);
• использовать ключ Key Management Service (KMS);
• использовать активацию на основе каталога Active Directory для систем Windows Server 2012 и более новых версий на машинах, присоединенных к домену.

В системе Windows Server 2012 R2 появился механизм автоматической активации виртуальных машин Automatic Virtual Machine Activation (AVMA). Как следует из названия, механизм AVMA, запущенный на активированном сервере Windows Server 2012 R2 Datacenter Hyper-V, автоматически активирует любую версию системы Windows Server 2012 R2. Единственный необходимый шаг – задействовать ключ AVMA в гостевой операционной системе, чтобы дать системе команду использовать механизм AVMA. Эти ключи перечислены в статье Automatic Virtual Machine Activation (technet.microsoft.com/en-us/library/dn303421.aspx):

• Windows Server 2012 R2 Datacenter—Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW;
• Windows Server 2012 R2 Standard—DBGBW-NPF86-BJVTX-K3WKJ-MTB6V;
• Windows Server 2012 R2 Essentials—K2XGM-NMBT3-2R6Q8-WF2FK-P36R2.

Если вы посмотрите на виртуальную машину с системой Windows Server 2012 R2 через диспетчер Device Manager, то увидите компонент Microsoft Hyper-V Activation среди устройств System. Используйте его для активации обмена информацией, связанной с активацией.

Улучшения в механизме динамической миграции

В системе Windows Server 2012 впервые реализована возможность динамической миграции между парой узлов. Процессы миграции динамически настраивают сами себя, основываясь на доступной полосе пропускания. Весь трафик динамической миграции отправлялся по сети в несжатом состоянии, поэтому, в зависимости от размера виртуальной машины, динамическая миграция могла занимать значительное время. Однако виртуальная машина была доступна во время динамической миграции, поэтому время выполнения не имело большого значения, если только вы не ждали, пока завершится миграция виртуальной машины с определенного узла, чтобы выключить этот узел для проведения обслуживания или с другой целью.

В системе Windows Server 2012 R2 появилось два новых параметра настройки динамической миграции.

• Compression. Этот параметр является новой настройкой по умолчанию и отвечает за сжатие данных при динамической миграции. Хотя сжатие потребляет дополнительные циклы процессора на обоих узлах Hyper-V (на исходном и целевом), оно кардинально сокращает время выполнения динамических миграций.
• SMB. Этот параметр отвечает за службу SMB Direct, механизм, использующий преимущества сетевых адаптеров, поддерживающих технологию Remote Direct Memory Access (RDMA). Технология RDMA позволяет передавать по сети огромные объемы данных, используя минимальный объем ресурсов хост-сервера. По сути, сетевой адаптер выделяет блок памяти и принимает меры для пересылки этого блока по сети. Операционная система хост-сервера даже не учитывает сетевые пакеты. Эта возможность обеспечивает наиболее быстрый процесс динамической миграции и использует меньшее количество ресурсов хост-сервера, но требует наличия сетевых адаптеров с поддержкой технологии RDMA.

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

В системе Windows Server 2012 R2 появилась еще одна важная, с учетом высокой частоты выхода новых версий системы Windows Server, функция динамической миграции: динамическая миграция между версиями. Динамическая миграция между версиями позволяет выполнять динамическую миграцию с хост-сервера версии Windows Serve 2012 Hyper-V на хост-сервер версии Windows Server 2012 R2 Hyper-V. Эта возможность означает, что в процессе миграции в работе виртуальной машины не будет простоев. Такой функции очень не хватало пользователям Hyper-V, не желавшим допускать простоев в работе даже при обновлении гипервизора Hyper-V.

Изменения в механизме реплики Hyper-V

Механизм Hyper-V Replica позволяет выполнять асинхронную репликацию виртуальных машин с одного отдельного или входящего в состав кластера хост-сервера Hyper-V на другой. Такая возможность полезна для аварийного восстановления. Информацию еще об одном механизме обеспечения отказоустойчивости Hyper-V, который не является нововведением в системе Windows Server 2012 R2, можно найти во врезке «Hyper-V Recovery Manager».

Благодаря асинхронному характеру репликации виртуальная машина может быть реплицирована между центрами обработки данных, что не окажет влияния на производительность исходной виртуальной машины. Механизм Hyper-V Replica реплицирует диски VHD виртуальных машин и позволяет выполнять различные типы аварийного восстановления, в том числе запланированное, незапланированное и тестовое. Кроме того, есть возможность во время аварийного восстановления присвоить виртуальной машине альтернативный IP-адрес. Площадки, на которые выполняется аварийное восстановление, обычно имеют схему IP-адресации, отличную от основного центра обработки данных. В системе Windows Server 2012 частота выполнения репликации зафиксирована в значении 5 минут.

Изначально задачей механизма Hyper-V Replica была репликация между центрами обработки данных. Но некоторые организации использовали функции Hyper-V Replica внутри одного центра обработки данных. Например, для репликации виртуальных машин между кластерами Hyper-V или между одиночными хост-серверами Hyper-V, на которых не могла использоваться кластеризация. Таким клиентам требовалась возможность выполнять репликацию чаще чем раз в 5 минут и отсылать дополнительную реплику виртуальной машины в центр обработки данных. Последнее требование было невыполнимо, так как виртуальная машина может иметь только одну реплику.

Механизм Hyper-V Replica в системе Windows Server 2012 R2 приобрел две новые функции, которые помогут закрыть описанные выше потребности. Во-первых, настройки частоты репликации стали более гибкими: есть возможность установить значения в 30 секунд, 5 минут или 15 минут. Во-вторых, можно расширить репликацию.

Расширенный механизм Hyper-V Extended Replica позволяет создавать реплики реплик, как показано на рисунке. Имейте в виду, что у дополнительной реплики есть собственная частота создания. Вы по-прежнему не можете иметь более одной реплики отдельной виртуальной машины: например, виртуальная машина на сервере А не в состоянии напрямую посылать реплику на серверы В и С. Но, как мы видим на рисунке, реплику можно отправить с одного сервера на другой, после чего эта реплика виртуальной машины сможет послать свою реплику на третий узел.

Рисунок. Расширенный механизм Hyper-V Extended Replica

Новый расширенный набор функций позволяет реализовать множество дополнительных сценариев. Например, можно выполнять репликацию внутри центра обработки данных с частотой в 30 секунд, после чего отправлять дополнительную реплику в другой центр обработки данных с частотой в 30 секунд, 5 минут или 15 минут. Один важный момент: дополнительная реплика не может создаваться с большей частотой, чем основная реплика. Например, если основная реплика создается каждые 5 минут, то дополнительная реплика может создаваться с частотой в 5 или 15 минут, но не каждые 30 секунд.

В этой статье я уделил внимание основным изменениям в гипервизоре Hyper-V, но они составляют только половину всех новых возможностей. В следующей статье мы продолжим погружение в Windows Server 2012 R2 Hyper-V. Многие улучшения, касающиеся других областей систем Windows Server и System Center будут полезны в виртуальных окружениях, так что выделите время на изучение всех аспектов систем Windows Server, System Center и Windows Azure.