Разработка приложений с Windows Azure Cloud Services

Приложение 1

увеличить изображение
Рис. 5.9. Жизненный цикл роли

A. RDFE/FFE – RedDog Front End. RedDog Front End – то, что связывает пользователя и fabric, представляя публично доступный API, который является Web-интерфейсом для портала управления и SMAPI. Все запросы пользователя обязательно проходят через RDFE, FFE же (Fabric Front End) – это прослойка, которая занимается трансляцией запросов от RDFE в язык, понятный fabric. Таким образом, запрос пользователя получается RDFE, затем проходит через FFE и приходит fabric-контроллеру в понятном ему виде.

B. Fabric-контроллер занимается управлением, мониторингом, обеспечением отказоустойчивости и многими другими задачами в датацентре. Это механизм, который знает обо всём, что происходит в системе, начиная с сетевого подключения и заканчивая состоянием операционных систем на виртуальных машинах. Контроллер постоянно поддерживает связь с собственными агентами, установленными на операционных системах и посылающих полную информацию о том, что происходит с этой операционной системой, включая версию ОС, конфигурации сервиса, пакеты конфигурации и так далее.

C. Агент на хосте занимается настройкой гостевых операционных систем и коммуникациями с агентом на госте (WaAppAgent), периодически проверяя гостевого агента на его работоспособность и, если агент на хосте не получает ответ в течении 10 минут, гостевая ОС перезапускается.

D. WaAppAgent, гостевой агент, конфигурирует гостевую операционную систему – брандмауэры, списки доступа, разворачиваемый сервис, сертификаты, передаёт информацию о статусе роли в fabric, и занимается мониторингом WaHostBootstrapper, проверяя статус роли.

E. WaHostBootstrapper на основе прочитанной конфигурации роли запускает startup-задачи и процессы и производит их мониторинг. Кроме этого, отвечает на запрос о статусе роли, вызывая событие StatusCheck.

F. IISConfigurator работает только при использовании Web-роли. Запускает сервисы, касающиеся IIS, конфигурирует rewrite-модуль в web.config приложения, настраивает пулы приложений (виртуальные директории, приложения, порты, host headers) согласно модели сервиса, логирование IIS, разрешения и списки ACL и копирует веб-сайт в папку e:\sitesroot.

G. Startup-задачи определяются моделью роли и запускаются WaHostBootstrapper. Startup-задачи – это задачи, которые выполняются при запуске экземпляра роли, и являются простыми выполняемыми файлами (Command-Line Executable). При разворачивании в Windows Azure Fabric-контроллер читает определение сервиса и определяет необходимые для роли ресурсы, после чего инициирует выполнение процесса запуска роли. Код для определения Startup-задачи приведен и описан ниже.

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
   <WebRole name="WebRole1">
      <Startup>
         <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple">
         </Task>
      </Startup>
   </WebRole>
</ServiceDefinition>

Атрибуты:

• CommandLine – имя файла, который должен быть выполнен при запуске Startup-задачи.
• ExecutionContext – контекст безопасности, применяющийся при запуске Startup-задачи. Есть два типа контекста безопасности:
  • Limited – запуск файла с тем же уровнем разрешений, с каким запущена роль.
  • Elevated – запуск файла с администраторскими правами.
• TaskType определяет тип выполнения задачи и является очень важным атрибутом, так как разные типы выполняются по-разному – либо синхронно, либо асинхронно. Типы:
  • Simple (по умолчанию, синхронное выполнение): задача запускается и блокирует экземпляр до окончания выполнения задачи. Примечание: если задача по какой-либо причине сломается и не выполнится, экземпляр будет заблокирован и не сможет запуститься. Поэтому надо быть аккуратнее с использованием этого типа.
  • Background (асинхронное выполнение): задача запускается, но не блокирует экземпляр, выполняясь параллельно.
  • Foreground (асинхронное выполнение): задача запускается, но не позволяет роли выключиться до окончания выполнения задачи.

H.H.H. Компоненты DiagnosticsAgent, RemoteAccessAgent и RemoteForwarderAgent – это плагины, которые определяются в файле определения сервиса роли.Особенность первых двух плагинов в том, что когда они прописываются в качестве startup-задачи, каждый из них определяет не одну, а две задачи, одну простую, вторую с параметром /blockStartup. Обычная startup-задача определяется с типом выполнения Background, дабы запуск роли не был произведен только после выполнения этой задачи. Задача с параметром /blockStartup определяется с типом выполнения Simple – WaHostBootstrapper будет ожидать её окончания, после чего процесс сможет быть продолжен. Причина данного поведения – модули диагностики и удаленного доступа (RDP) должны быть инициализированы и настроены перед стартом роли.

I. WaWorkerHost – процесс, который запущен для Worker-ролей и содержащий все скомпилированные сборки роли и точки входа в код (OnStart, Run).

J. WaWebHost – процесс, который запускается для Web-ролей, когда они настраиваются для использования Hostable Web Core (HWC) с SDK 1.2. Необходимо учитывать, что процесс Worker-а IIS (w3wp) не используется и пулов приложений не создается, так как IIS расположен внутри WaWebHost.exe.

K. WallSHost – процесс, отвечающий за Web-роли, использующие полнофункциональный IIS. Данный процесс сначала загружает первую сборку, в которой реализован класс RoleEntryPoint (эта сборка определена в e:\__entrypoint.txt), после чего выполняет код из этого класса (методы OnStart,Run,OnStop). Все события, касающиеся RoleEnvironment (StatusCheck, Changes и прочие), созданные в этом классе, вызываются в этом процессе.

L. W3WP является стандартным процессом IIS, который используется в полнофункциональном IIS. Данный процесс запускает пул приложения, сконфигурированный IISConfiguration, и все события RoleEnvironment (StatusCheck, Changes, и др.) запускаются именно в нём. Обратите внимание, что эти события вызываются как в WallSHost, так и в w3wp, если вы подписываетесь на события из обоих процессов.

Жизненный цикл – концептуально

Рис. 5.10. Блок-схема жизненного цикла

Жизненный цикл роли начинается с момента загрузки пакета и конфигурации облачного сервиса на платформу Windows Azure. Далее компонент Fabric-контроллер производит поиск необходимого оборудования согласно прописанным в определении сервиса инструкциям. После обнаружения и выделения необходимых ресурсов на них разворачивается образ гостевой операционной системы (либо по умолчанию, либо указанной в описании сервиса). Окончание развертывания инициирует процесс загрузки гостевой операционной системы.

Развернув операционную систему, контроллер переходит к развертыванию сервиса. В этом случае, если роль содержит в определении сервиса указание на Startup-задачу, эти задачи начинают последовательно выполняться в синхронном или асинхронном режимах.

После выполнения, например, задачи с типом Simple, процесс загрузки роли переходит на этап запуска IISConfigurator, при этом параллельно инициируется событие OnStart (либо немного позже). Startup-задачи могут как просто отказать в выполнении, так и никогда не закончиться – это разные ситуации, которые должны решаться разными методами.

По окончании события OnStart роль переходит в состояние Ready, что означает, что она может принимать запросы от балансировщика нагрузки. В этот момент инициируется событие Run, которое можно переопределить в коде файла WebRole.cs, добавив, если необходимо, какую-либо логику.

По прошествии какого-то времени роль может быть очищена (recycled) или вообще выключена. При этом инициируется событие OnStop, в котором распространенной практикой является определение логики очистки состояния роли – закрытия подключений к базе данных, переноса данных в блоб или таблицы, и так далее.

После события OnStop роль полностью останавливается.

Жизненный цикл роли – подробно

Жизнь роли начинается с момента загрузки пакета и конфигурации облачного сервиса на платформу Windows Azure. Далее запрос отправляется компоненту RDFE, который совершает некоторые действия, касающиеся подписки (проверка и так далее), после чего передает запрос FFE. FFE ищет подходящий пул машин (основываясь на том, что написано в конфигурации) и обменивается данными с Fabric-контроллером в данном пуле машин.

Fabric-контроллер производит поиск хоста с требуемым значений количества ядер CPU (или инициирует запрос на развертывание нового хоста), далее копирует пакет сервиса и его конфигурационные файлы на этот хост, после чего сообщает агенту хоста на хостовой операционной системе о наличии нового сервиса и необходимости его развернуть.

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

WaAppAgent настраивает гостевую операционную систему (конфигурацию брандмауэра, локального хранилища, указанного в настройках роли, списки доступа и прочее) и копирует конфигурационный файл в формате XML в директорию c:\Config, после чего запускает процесс WaHostBootstrapper.

Если используется полнофункциональный IIS, то WaHostBootstrapper запускает процесс IISConfigurator и сообщает ему, чтобы тот удалил все существующие пулы приложений для Web-роли.

WaHostBootstrapper последовательно читает Startup-задачи из узла <Startup> в файле E:\RoleModel.xml, выполняя их. Если в списке присутствуют задачи типа Simple, WaHostBootstrapper будет ждать до тех пор, пока все из них не закончат свое выполнение и не возвратят успешный код возврата.

Для полнофункционального IIS WaHostBootstrapper передает IISConfigurator запрос на конфигурацию пула приложений AppPool и переводит сайт в директорию E:\Sitesroot\<index> где <index> – начинающийся с 0 индекс сайта, сконфигурированного в узле <Sites> в конфигурации сервиса.

WaHostBootstrapper запускает процесс в зависимости от типа роли:

a. Worker-роль: Запускается WaWorkerHost.exe, при этом WaHostBootstrapper вызывает метод OnStart() и после успешного его завершения начинает выполнять метод Run(), пометив экземпляр роли как Ready (готовый к принятию запросов) и передав балансировщику нагрузки сообщение о том, что данный экземпляр готов к работе (в том случае, если определены конечные точки входа). В процессе работы экземпляра роли процесс WaHostBootsrapperпериодически опрашивает экземпляр о его статусе.

b. SDK 1.2 HWC Web-роль: Старый режим работы Web-ролей. Запускается WaWebHost, после чего WaHostBootstrapper вызывает метод OnStart() и после успешного его завершения начинает выполнять метод Run(), пометив экземпляр роли как Ready (готовый к принятию запросов) и передав балансировщику нагрузки сообщение о том, что данный экземпляр готов к работе. Далее WaWebHost инициирует запрос (GET /do.__rd_runtime_init__). Все запросы попадают процессу WaWebHost.exe. В процессе работы экземпляра роли процесс WaHostBootsrapper периодически опрашивает экземпляр о его статусе. Данный тип роли не поддерживает функциональность, доступную в полнофункциональном IIS.

c. Web-роль с полнофункциональным IIS: Запускается процесс WaIISHost, при этом WaHostBootstrapper вызывает метод OnStart() и после успешного его завершения начинает выполнять метод Run(), пометив экземпляр роли как Ready (готовый к принятию запросов) и передав балансировщику нагрузки сообщение о том, что данный экземпляр готов к работе (в том случае, если определены конечные точки входа). В процессе работы экземпляра роли процесс WaHostBootsrapper периодически опрашивает экземпляр о его статусе.

Все входящие запросы, получаемые полнофункциональным IIS, инициируют создание IIS-ом процесса W3WP

При подключении по удаленному доступу можно получить доступ к логам всех процессов.

WaAppAgent

D:\Packages\GuestAgent\WaAppAgent.exe.log

D:\Packages\GuestAgent\WaAppAgent.log

WaHostBootstrapper

C:\Resources\Directory\<guid>.<role>.DiagnosticStore\

WaWebHost

C:\Resources\Temp\<guid>.<role>\RoleTemp\WaWebHost.log

WaIISHost

C:\Resources\Temp\<guid>.<role>\RoleTemp\WaIISHost.log

IISConfigurator

C:\Resources\Temp\<guid>.<role>\RoleTemp\IISConfigurator.log

IIS Logs

C:\Resources\Directory\<guid>.<role>.DiagnosticStore\LogFiles\W3SVC1

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