Создание образа сервера для роли виртуальной машины в Windows Azure

Обновлено: Март 2011 г.

[Поддержка функции «Роль виртуальной машины» в Windows Azure прекращается 15 мая 2013 г. После этой даты развертывания этой роли будут удалены. Для продолжения работы с существующими приложениями можно использовать виртуальные машины Windows Azure. Дополнительные сведения об использовании виртуальных машин для приложения см. на веб-странице Moving from VM Role to Windows Azure Virtual Machines (Переход от использования функции «Роль виртуальной машины» к использованию виртуальных машин Windows Azure).

Роль виртуальной машины Windows Azure аналогична другим ролям, поскольку все экземпляры ролей, выполняемые в Windows Azure, — это виртуальные машины, на которых выполняется операционная система Windows Server. Роль виртуальной машины отличается тем, что для нее создается образ сервера. Для этого нужно создать основной виртуальный жесткий диск, установить компоненты интеграции Windows Azure, установить приложения, настроить параметры, затем обобщить образ и загрузить его в Windows Azure.

Для создания образа Windows Server 2008 R2 можно использовать стандартные средства Windows. Например, для создания виртуального жесткого диска можно использовать Hyper-V Manager.

Основной виртуальный жесткий диск содержит операционную систему, приложения и все внесенные в ОС изменения. Для создания основного виртуального диска можно использовать Hyper-V Manager. После создания и подготовки образа сервера виртуальный диск загружается на портал управления платформой Windows Azure.

Далее приведен список ресурсов со сведениями о виртуальных жестких дисках и образах сервера.

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

Компоненты интеграции Windows Azure нужно установить на образе сервера перед загрузкой основного виртуального жесткого диска в Windows Azure. Компоненты интеграции Windows Azure выполняются в каждом экземпляре роли виртуальной машины, который создается из образа сервера и реализует интеграцию между экземплярами роли и средой Windows Azure.

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

Служба Windows Azure Connect предоставляет простой пользовательский интерфейс для настройки соединений, защищенных технологией IPsec, между виртуальными машинами в локальной сети и экземплярами ролей, запущенных в Windows Azure. IPsec защищает соединения по IP-сетям с помощью служб шифрования. Дополнительные сведения об использовании Windows Azure Connect см. в разделе Подключение локальных компьютеров к ролям Windows Azure.

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

VMRoleDevelopmentModel

Есть два варианта реализации адаптера.

  • Можно написать адаптер, который выполняется во время прохода специализации. Этот проход специализации производится во время настройки операционной системы после начальной загрузки образа сервера в Windows Azure или после переопределения образа экземпляра. Адаптер подобного вида можно создать без написания кода, при этом применяется один из двух методов: запускается либо скрипт из файла ответов, либо поставщик, написанный для средства подготовки системы (sysprep). Дополнительные сведения см. в разделе Написание адаптера, который выполняется во время настройки операционной системы.

  • Можно написать адаптер, который будет службой Windows, запускаемой автоматически при запуске операционной системы. Подобный адаптер можно реализовать в виде управляемого или машинного кода. Адаптер использует API среды выполнения Windows Azure для сбора динамических данных из среды Windows Azure. Дополнительные сведения см. в разделе Написание адаптера, который выполняется при запуске операционной системы.

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

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

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

При развертывании образа сервера в Windows Azure он находится в обобщенном состоянии. Это следствие выполнения средства SysPrep (sysprep), которое готовит локальный образ. Чтобы операционная система могла работать в экземпляре роли виртуальной машины Windows Azure, в ходе установки образа нужно выполнить проход специализации. Сведения, используемые для автоматизации прохода специализации, хранятся в файле ответов, который устанавливается в корневую папку образа сервера (c:\unattend.xml) компонентами интеграции Windows Azure.

Изменив файл ответов в ходе создания образа, можно подготовить скрипт, который будет вызываться во время прохода специализации после загрузки образа в Windows Azure. Дополнительные сведения об изменении файла ответов см. в разделе Комплект автоматической установки Windows.

Кроме того, можно написать поставщик для средства sysprep и включить его в образ сервера. Поставщик sysprep расширяет средство sysprep, чтобы обеспечить необходимую дополнительную функциональность. Компоненты интеграции Windows Azure поддерживают средство sysprep, используемое для выполнения прохода специализации, который при первом запуске экземпляра роли ВМ завершит настройку Windows. Сведения о разработке поставщика sysprep см. разделе Руководство разработчика поставщика средства Sysprep для Windows 7.

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

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

Служба Windows должна быть 64-битным процессом Windows, иначе она не сможет использовать API службы времени выполнения. Служба может быть реализована в виде управляемого или машинного кода. Дополнительные сведения об API-интерфейсе см. в разделах Windows Azure Managed Library Reference и Windows Azure Native Library Reference.

API-интерфейс службы времени выполнения можно вызывать только из процесса, который запущен под учетной записью Administrator или LocalSystem. Это ограничение гарантирует, что служба по умолчанию защищена и процесс с недостаточными правами не сможет воспользоваться API среды выполнения для чтения параметров конфигурации службы.

Служба Windows должна быть настроена для автоматического старта при запуске Windows. Служба должна реализовать методы жизненного цикла класса ServiceBase, включая OnStart и, если требуется отработка завершения работы, OnStop или OnShutdown. Код запуска должен завершиться к моменту завершения метода OnStart. Выключение, выполняемое службой Windows, должно быть завершено к моменту завершения метода OnStop или OnShutdown. Дополнительные сведения о создании служб Windows см. в разделе Приложения службы Windows.

После автоматического запуска служб, включая адаптер, Windows Azure узнает, что экземпляр готов к получению трафика из подсистемы балансировки нагрузки. По этой причине важно убедиться, что адаптер выполнил все задачи, необходимые для подготовки экземпляра роли ВМ и его приложений, до завершения метода OnStart. Экземпляр роли ВМ должен быть в состоянии готовности с момента завершения последовательности подготовки запуска и до момента выполнения последовательности завершения работы, если только экземпляр явно не исключен из ротации через состояние Busy. Это можно сделать, добавив обработчик на событие StatusCheck. После возникновения события можно вызвать метод SetBusy для объекта-аргумента события. Можно также воспользоваться командлетом Powershell Set-RoleInstanceStatus, который позволяет изменить состояние экземпляра роли ВМ.

После установки компонентов интеграции Windows Azure можно устанавливать нужные приложения и вносить изменения в конфигурацию операционной системы. Также можно установить агент Windows Azure Connect, создать и установить адаптер. После этого следует подготовить образ к загрузке.

Чтобы виртуальный диск правильно загрузился в Windows Azure, образ сервера нужно подготовить с помощью средства Sysprep. Дополнительные сведения об использовании Sysprep см. в разделе Использование Sysprep. Общие сведения. Дополнительные сведения о загрузке виртуального жесткого диска см. в разделе Отправка виртуального жесткого диска для роли виртуальной машины в Windows Azure.

См. также

Добавления сообщества

Показ: