Использование WDS и Hyper-V для развертывания размещений виртуальных компьютеров

Читатели, вероятно, знакомы со многими из убедительных причин для создания среды Hyper-V, но одной из них, которая может вызвать особый интерес, является возможность Hyper-V способствовать оценке продуктов и обучению в тестовых лабораториях и обучающих средах без принесения в жертву совместимости с 64-разрядной архитектурой. Hyper-V работает даже на 64-разрядном оборудовании начального уровня при условии наличия пригодного ЦП и недавнего обновления BIOS для поддержки виртуализации оборудования. Это делает простым и приятным развертывание полномасштабных тестовых сред, основанных на полностью поддерживаемых версиях программ, таких как 64-разрядная версия Microsoft Exchange Server 2007. А после того как развертывание организовано, несложно заново произвести его в любой момент, когда необходимо начать с нуля, хоть для просмотра нового продукта, хоть для запуска нового сеанса класса.

Даже при развертывании тестовой среды для клиента с двумя контроллерами доменов (DC), компьютером, на котором работает SQL Server, двумя серверами клиентского доступа SharePoint, сервером электронной почты Exchange 2007, транспортным сервером-концентратором и сервером клиентского доступа развертывание поглотит массу усилий. Предположим, что среда гораздо больше, скажем, с 600 виртуальными компьютерами (VM). Можно ли представить себе переустановку этих VM каждую неделю или каждый раз, как понадобится новая лабораторная среда? Автоматизация таких развертываний необходима и именно в данной области может помочь Hyper-V.

Hyper-V – это технология Windows, и ее можно сочетать с инструментарием управления Windows (WMI), Windows PowerShell, службами развертывания Windows (WDS), пакетом автоматической установки Windows (AIK) и средой предустановки Windows (Windows PE) 2.0, чтобы сделать возможными полномасштабные развертывания, производимые в мгновение ока – или, по крайней мере, не требующие большого внимания. Пользователю может казаться интересным разглядывание экранов установки и индикаторов выполнения, пока системы настраивают и устанавливают себя, но ему не обязательно делать это, если в его списке есть более важные вещи.

В этой статье, я покажу, как развертывать серверы Hyper-V, виртуальные компьютеры (VM), гостевые операционные системы и приложения серверов безо всякого участия администратора, путем использования WDS, индивидуализированных образов установки, файлов unattend.xml и сценариев WMI. Идея состоит в том, чтобы выполнить предварительную настройку среды WDS однажды и затем устанавливать тестовые системы по мере необходимости, например при переустановке среды обучения, устранении сложных проблем в различных настройках, а также разработке и тестировании пользовательских решений.

Единственным обязательным взаимодействием в ходе развертывания является нажатие клавиши F12 для запуска среды предзагрузочного выполнения (PXE), и даже этот этап можно устранить, если использовать Startrom.n12 вместо загрузочного файла по умолчанию Startrom.com в настройке WDS, как объясняется в статье TechNet «Общие сведения по разработке полностью автоматизированной установки».

Оставшиеся задачи после этого попадают в руки WDS, AIK и WMI после автозапуска виртуальных компьютеров Hyper-V. Файлы настройки и сценарии также можно будет найти в сопровождающем материале, доступном в разделе загрузок кода за февраль 2009 года на веб-сайте журнала TechNet Magazine по адресу technet.microsoft.com/magazine/cc135868. Собственно образы установки не включены сюда, поскольку они слишком велики, но сопровождающие файлы должно быть возможно приспособить к собственной лабораторной среде.

Архитектура развертывания

В центре моей инфраструктуры развертывания лабораторий находится сервер WDS, на котором работают службы доменов Active Directory (AD DS), служба доменных имен (DNS), протокол DHCP и, само собой, WDS. В целях удобства администрирования я также установил AIK и средства Hyper-V для удаленного администрирования на этом сервере. Вот и все, что нужно для подготовки к эффективности развертывания Hyper-V. Ничего больше не требуется, хотя и можно ввести дополнительные серверы WDS, если важна высокая доступность через избыточность. Оставшиеся физические компьютеры, являются серверами Hyper-V, развернутыми через WDS и размещающими VM, которые формируют собственно тестовую среду, как показано на рис. 1.

Увеличить

Рис. 1. Полномасштабная лабораторная среда, основанная на Hyper-V и виртуальных компьютерах

Указания по развертыванию сервера WDS приведены в сопровождающей памятке, «Развертывание служб развертывания Windows», загружаемой с того же веб-сайта загрузок, что упомянут выше. Как можно будет увидеть, установка прямолинейна. Именно развертывание и настройка узлов Hyper-V представляют собой сложность, но об этом будет чуть ниже.

Развертывание Hyper-V на основе WDS

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

Кратко говоря, нужно выполнить следующие действия: развернуть Windows Server 2008 на эталонном компьютере, обновить установку последними файлами Hyper-V, установить Hyper-V, использовать Sysprep.exe для создания установки, записать обобщенный образ установки и выгрузить его на сервер WDS, после чего автоматизировать Hyper-V по умолчанию. Я предпочитаю использовать Windows Server 2008 Server Core для Hyper-V, поскольку мои серверы Hyper-V выделены для размещения виртуальных компьютеров, а Server Core предлагает небольшой объем занимаемой памяти вместе с преимуществами в безопасности, надежности и управляемости. Для записи же образов установки я, само собой, использую WDS. Загляните в сопровождающую памятку «Развертывание узлов Hyper-V по умолчанию путем использования служб развертывания Windows», чтобы увидеть насколько легко можно обновить, загрузить и использовать обновленный образ установки Hyper-V. Проще не бывает.

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

Помимо всего прочего, Sysprep.exe обобщает данные настройки загрузки (BCD) и удаляет директиву о запуске гипервизора из хранилища BCD. От BCD ожидается независимость от микропрограммного обеспечения, но с Hyper-V дело обстоит иначе. Гипервизор полагается на возможности виртуализации лежащего в основе оборудования и BIOS, так что от директивы запуска гипервизора надо избавиться, чтобы обобщить установочный образ. Хранилище BCD можно модифицировать в автономном режиме, после обобщения Sysprep, но это не решение.

Если установочный образ подключить, используя ImageX.exe (средство, включенное в AIK), то ввести директиву запуска, используя BCDEdit.exe, нельзя; однако программа установки Windows устраняет эту директиву снова, в ходе фазы обобщения собственно процесса установки. Начинай сначала.

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

Увеличить

Рис. 2 Невозможно запустить виртуальные компьютеры, поскольку гипервизор не работает

Одним из способов повторного ввода директивы на запуск гипервизора является добавление ее вручную после установки сервера путем выполнения команды

bcdedit /set hypervisorlaunchtype auto

и перезапуска сервера Hyper-V, но это выполняемое вручную действие будет серьезным препятствием на пути полностью автоматического развертывания тестовой лаборатории. К счастью, AIK включает диспетчер образов систем Windows, который можно использовать, чтобы создать файл unattend.xml для установочного образа, который WDS применяет в дополнение к собственному файлу WDSClientUnattend.xml. В этом файле unattend.xml можно указать, что программе установки следует автоматически входить в Windows с административными учетными данными, предоставленными клиентом WDS, и затем выполнять сценарий, вставляющий директиву на запуск гипервизора обратно в хранилище BCD, а затем перезапускающий сервер.

На рис. 3 показан общий подход, а в сопровождающем материале есть полная версия файла unattend.xml, а также полный сценарий hypervconfig.vbs. Сценарий hypervconfig.vbs можно включить прямо в установочный образ, чтобы он был доступен в ходе установки. Нужно просто разместить образ с помощью ImageX.exe, как обрисовано в сопровождающей памятке «Индивидуализация развертываний Hyper-V».

Увеличить

Рис. 3. Перенастройка и запуск гипервизора

Настройка Hyper-V на основе WMI

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

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

Обобщение образа отключает порты Ethernet на виртуальных компьютерах от физических карт сетевого интерфейса и сквозные диски от лежащих в основе жестких дисков и устройств CD/DVD. Обобщение можно пропустить, но включение заранее установленных виртуальных компьютеров в образ установки – плохая идея. Заранее установленные виртуальные компьютеры раздувают образ в огромной степени, испытательные сроки развернутых тестовых серверов со временем заканчиваются, также и домены Active Directory не любят отключений на долгие периоды времени. Если восстановить лабораторную среду, используя резервные копии виртуальных компьютеров, установленных несколько месяцев назад, есть серьезный шанс столкнуться с проблемами проверки подлинности и репликации Active Directory. Проще начинать с нуля каждый раз.

Так что давайте предоставим виртуальные компьютеры и связанные с ними ресурсы, такие как сетевые платы, жесткие диски и диски DVD, среде Hyper-V, прежде чем браться собственно за развертывание лаборатории тестирования. Как можно предположить, предоставление этих виртуальных ресурсов является основной задачей сценария hypervconfig.vbs.

Этот подход довольно прямолинеен. Сценарий определяет имя локального сервера Hyper-V и затем настраивает набор VM для конкретного размещения. Каждый виртуальный компьютер получает два виртуальных устройства чтения DVD, сопоставленных с файлом .iso конкретного сервера и общим файлом ISO установки. Файл ISO конкретного сервера соответствует загрузочному диску DVD. Он содержит все необходимые сценарии и файлы настройки для автоматической установки определенного сервера лаборатории.

Общий файл установки представляет собственно носитель для установки. Совместное использование файла ISO всеми виртуальными компьютерами на сервере позволяет удержать размер установочного образа Hyper-V до некоторой степени под контролем. Файлы ISO можно поместить на сетевой сервер, но так или иначе файлы необходимо скопировать на сервер Hyper-V для установки, так что я решил напрямую включить их в установочный образ. Таким образом, файлы ISO становятся доступными локально, каждый раз как в этом возникает нужда. Это может быть полезно, например, при установке дополнительных компонентов и переустановке определенного виртуального компьютера без уничтожения всей среды лаборатории.

О дисках DVD для установки конкретного сервера я расскажу чуть ниже. Сперва я уделю основное внимание настройке инфраструктуры Hyper-V посредством сценариев на основе WMI. Как показано на рис. 4, тут необходимо предоставить разнообразные виртуальные ресурсы, включая виртуальный коммутатор, со внешними и внутренними портами коммутатора, сами виртуальные компьютеры с их виртуальными картами Ethernet, виртуальные диски IDE, подключенные к файлам виртуальных жестких дисков (VHD) и виртуальные диски DVD, подключенные к файлам ISO для установки гостевых операционных систем и серверных приложений.

Рис. 4. Предоставление виртуальных ресурсов для лабораторной среды

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

Сценарий hypervconfig.vbs настраивает VM на автоматический запуск при запуске физического компьютера, так что VM включаются после перезагрузки HypervisorLaunchType и так происходит установка лаборатории. Виртуальные компьютеры со временем загружаются в процедуры установки своей гостевой операционной системы. Это ключ к полностью автоматическому развертыванию лаборатории.

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

Чтобы подключить коммутатор к физической сети, необходимо создать порт коммутатора, вызвав метод CreateSwitchPort и связав этот порт с доступной сетью Ethernet на сервере. Физическую сетевую карту можно подключить только к одному виртуальному коммутатору, но несколько коммутаторов могут быть подключены друг к другу напрямую, или через виртуальные компьютеры, использующие программы маршрутизации. Но для целей этой статьи достаточно базовой среды локальной сети без сетевых маршрутизаторов, так что я настроил единственный виртуальный коммутатор на каждом сервере Hyper-V, подключенном к первой доступной физической карте Ethernet.

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

Путем вызова метода SetupSwitch виртуальный коммутатор преобразуется из частного коммутатора во внешний коммутатор, как показано в сценарии hypervconfig.vbs в сопровождающем материале. Сценарий содержит все подробности установки подключения ко внешней сети для виртуальных компьютеров. Для получения дополнительных сведений прочтите документ Документация поставщика виртуализации WMI на веб-сайте MSDN. Значительные части моего сценария hypervconfig.vbs основаны на примерах, доступных в документе «Использование поставщика виртуализации WMI».

Развертывание виртуальной лаборатории

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

Общий подход подобен методу Hyper-V. Вслед за автоматической установкой ОС позвольте учетной записи администратора войти в систему автоматически и выполнить любые дополнительные команды развертывания. Однако при этом необходимо координировать развертывание.

Все виртуальные компьютеры загружаются в их процедуры установки практически одновременно, но некоторые серверы зависят от других серверов, так что параллельное выполнение всех установок невозможно. Например, перед установкой любых других служб в домен необходимо установить AD DS, Exchange Server 2007 также требуют AD DS, фермы серверов SharePoint требуют SQL Server и так далее, так что единственный виртуальный компьютер в данном случае, на котором может немедленно работать программа установки Windows – это DC01.Litware.com. Все остальные должны ждать, пока не заработает DC.

Существует несколько способов реализации последовательности установки. Можно настроить задержку загрузки для виртуальных компьютеров, но этот прием известен своей ненадежностью. Готовы ли вы поспорить, что установка Active Directory всегда завершается за 15 минут? И сколько времени после этого уйдет на установку первого Exchange Server?

Другим вариантом является сценарий на основе WMI для переключения виртуальных компьютеров, когда это допускают предварительные требования к установке. Это лучшая альтернатива, но она требует координации централизованного исполнения сценария с распределенным развертыванием виртуальных компьютеров. Проще настроить каждую отдельную программу установки и позволить виртуальным компьютерам проверять любые данные требования к установке самим перед запуском их программ установки Windows, как показано на рис. 5.

Увеличить

Рис. 5. Реализация последовательности развертывания на основе предварительных требований к установке

Windows PE позволяет нам реализовывать эти индивидуализированные программы установки. Это минимальная операционная система Win32 с ограниченными службами, но с поддержкой узла сценариев Windows Script Host (WScript), WMI и компонентов доступа к данным Майкрософт (MDAC). Для выполнения сценария нужно лишь создать модифицированный образ Windows PE, добавить требуемые пакеты функций Windows, включит собственный сценарий и затем изменить файл Startnet.cmd, расположенный по адресу %SYSTEMROOT%\System32 образа Windows PE.

В сопровождающей памятке «Создание собственных образов загрузки для развертываний серверов» описан процесс создания модифицированного образа Windows PE для каждого сервера в среде тестовой лаборатории. На рис. 6 показано, как использовать эту методику для координации развертывания второго контроллера домена.

Увеличить

Рис. 6. Скоординированное развертывание второго контроллера домена в тестовой лаборатории

Файл Startnet.cmd включает в себя команду netsh для назначения статического IP-адреса сетевому интерфейсу виртуального компьютера с последующим вызовом сценария StartSetup. Команда netsh не является строго необходимой в среде с поддержкой DHCP, но она помогает высвечивать относящиеся к сети ошибки. Например, если предоставить стандартную сетевую карту (порт Microsoft Synthetic Ethernet Port) для своего виртуального компьютера в сценарии настройки Hyper-V вместо старой сетевой карты (порт Microsoft Emulated Ethernet) команда netsh даст информацию, что Windows PE не может распознать сетевой адаптер.

Сценарий StartSetup не информирует об этой проблеме при попытке доступа к сетевым ресурсам, поскольку оператор On Error Resume Next позволяет сценарию выдерживать ошибки среды выполнения. Если DC01 недоступен по любой причине, попытки подключения дают сбой, и сценарий зацикливается на неопределенное время. Цикл завершается, только если попытка подключения оказывается удачной и если DC01 является глобальным сервером каталогов, что предполагает успешную установку AD DS.

Когда цикл завершается, сценарий вызывает собственно команду Setup, указывая файл unattend.xml с параметрами настройки конкретного сервера. Схема на рис. 6 иллюстрирует, как ждать включения глобального сервера каталогов, но те же принципы применимы и в других ситуациях, например при проверке доступности общих файловых ресурсов или баз данных SQL Server. Просто попытайтесь получить доступ к ресурсу и выйдите из цикла в случае успеха.

Материалы по Hyper-V

• Веб-сайт Windows Server 2008 Hyper-V
  
• Блог группы виртуализации Windows Server
  
• Руководство по службам развертывания Windows
  
• Пакет автоматической установки Windows
  
• Справка по автоматической установке Windows

Развертывание серверных приложений

Остается лишь одна задача – настроить файл unattend.xml на добавление сервера к домену, настройку параметров TCP/IP, включение протокола удаленного рабочего стола (RDP) и настройку <FirstLogonCommands> для установки любых желаемых серверных приложений. Большинство серверных приложений Майкрософт поддерживают автоматические развертывания.

Для AD DS необходимо предоставить файл ответов, как объясняется в статье базы знаний Майкрософт «Указания по использованию автоматического режима для установки и удаления служб доменов Active Directory на контроллерах доменов, основанных на Windows Server 2008». Для Exchange Server 2007 следует вместо этого использовать параметры командной строки (см. раздел «Указания по установке Exchange 2007 в автоматическом режиме» интерактивной справки). Для SQL Server 2008 нужно выполнить указания интерактивной справки, обрисованные в разделе «Как установить SQL Server 2008 из командной строки». А что касается Windows SharePoint Services 3.0, то обратите внимание на материал «Ссылка на Config.xml (Windows SharePoint Services)».

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

Заключение.

Hyper-V – вдохновляющая технология. Она полностью совместима с 64-разрядными системами, так что при доступности последних для целей оценки или подготовки более не требуется разворачивать 32-разрядные версии программ. Это технология Windows, позволяющая воспользоваться всеми преимуществами WDS, AIK и Windows PE для развертывания. Она поддерживает WMI и Windows PowerShell через поставщик виртуализации WMI, который можно использовать для управления всеми аспектами виртуализованной среды, включая предоставление ресурсов и виртуальных компьютеров в ходе процесса развертывания. Она использует гипервизор, вместо монитора виртуальных компьютеров (VMM) для предоставления высокой производительности и повышения масштабирования и входит в Windows Server 2008 как бесплатная добавка.

Среды на основе Hyper-V сравнительно просто развертывать. Достаточно нескольких щелчков, чтобы приступить к работе над первыми виртуальными компьютерами, и в сочетании с технологиями развертывания Windows развертывание даже в наиболее сложных ситуациях доставляет одно удовольствие.

Единственным недостатком, который я вижу, является сетевая документация поставщика виртуализации WMI, которая пока остается в зачаточном состоянии, так что пример кода не охватывает всех актуальных задач. Но результаты вполне стоят усилий. Приятно видеть, как среда ИТ развертывает сама себя, даже если она включает в себя гораздо меньше 600 виртуальных компьютеров.