Также как и с жизненным циклом страницы ASP.NET, необходимо понимать, что происходит с приложением во время его работы на платформе Windows Azure.
На рис.1 приведена архитектура процессов роли.
Рис. 1. Архитектура роли Windows Azure
Давайте рассмотрим всё с самого начала.
A. RDFE/FFE – RedDog Front End (кстати, название RedDog имеет собственную историю, предположительно которую рассказал Марк Руссинович в своем великолепном докладе об архитектуре всего в Windows Azure – http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-853T ). RedDog Front End – то, что связывается пользователя и fabric, а именно представляет из себя публично доступный API, который является фронтендом для портала управления и 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>
Атрибуты:
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, если вы подписываетесь на события из обоих процессов.
С компонентами понятно. Теперь, что касается жизненного цикла роли Windows Azure – его можно рассматривать по-разному – концептуально и более конкретный. Рассмотрим оба варианта.
Концептуальный
Рис. 2. Концептуальный подход к жизненному циклу роли Windows Azure
Жизнь роли начинается с момента загрузки пакета и конфигурации облачного сервиса на платформу Windows Azure. Далее компонент Fabric-контроллер производит поиск необходимого оборудования согласно прописанным в определении сервиса инструкциям. После обнаружения и выделения необходимых ресурсов на них разворачивается образ гостевой операционной системы (либо по умолчанию, либо указанной в описании сервиса). Окончание развертывания инициирует процесс загрузки гостевой операционной системы.
Развернув операционную систему, контроллер переходит к развертыванию сервиса. В этом случае, если роль содержит в определении сервиса указание на Startup-задачу, эти задачи начинают последовательно выполняться в синхронном или асинхронном режимах.
После выполнения, допустим, задачи с типом Simple, процесс загрузки роли переходит на этап запуска IISConfigurator, при этом параллельно инициируется событие OnStart (либо немного позже). Startup-задачи могут как просто отказать в выполнении, так и никогда не закончится – это разные ситуации, и должны решаться они по-разному.
По окончании события OnStart роль переходит в состояние Ready, что означает, что она может принимать запросы от балансировщика нагрузки. В этот момент инициируется событие Run, которое можно переопределить в коде файла WebRole.cs, добавив, если необходимо, какую-либо логику.
По прошествии какого-то времени роль может быть очищена (recycled) или вообще выключена. При этом инициируется событие OnStop, в котором распространенной практикой является определение логики очистки состояния роли – закрытия подключений к базе данных, переноса данных в блоб или таблицы, и так далее.
После события OnStop роль полностью останавливается.
Конкретный
Жизнь роли начинается с момента загрузки пакета и конфигурации облачного сервиса на платформу Windows Azure. Далее запрос отправляется компоненту RDFE, который совершает некоторые действия, касающиеся подписки (проверка и так далее), после чего передает запрос FFE. FFE ищет подходящий пул машин (основываясь на том, что прописано в конфигурации – здесь включается в дело конфигурация аффинных групп и географической локаций, и основываясь на том, что FFE предоставил Fabric – данные о доступности оборудования и так далее) и обменивается данными с Fabric-контроллером в данном пуле машин.
Fabric-контроллер ищет хост с требуемым значений количества ядер CPU (или инициирует запрос на развертывание нового хоста), далее копирует пакет сервиса и его конфигурационные файлы на этот хост, после чего сообщает агенту хоста на хостовой операционной системе о наличии нового сервиса и необходимости его развернуть.
Агент хоста запускает гостевую операционную систему и связывается с агентом на клиенте (WaAppAgent). Теперь хост должен периодически отсылать пакеты гостю, дабы удостовериться, что роль на этом хосте находится в состоянии, удовлетворяющем условиям.
WaAppAgent настраивает гостевую операционную систему (конфигурацию брандмауэра, локального хранилища, указанного в настройках роли, списки доступа и прочее) и копирует конфигурационный файл в формате XML в директорию c:\Config, после чего запускает процесс WaHostBootstrapper.
Если используется полнофункциональный IIS, то WaHostBootstrapper запускает процесс IISConfigurator и сообщает ему, чтобы тот удалил все существующие пулы приложений для Web-роли. В последних версиях SDK есть известная проблема с появлением ошибок IISConfigurator при развертывании приложения в локальном эмуляторе вычислений – она связана именно с тем, что, возможно, созданы пулы, которые не получается удалить, и тайм-аут на запуск IISConfigurator истекает.
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). Затем операционная система автоматически перезапускается для завершения процесса установки. После перезапуска операционной системы запускаются службы из списка автозапуска. Далее балансировщику нагрузки передается сообщение о том, что данный экземпляр готов к работе (в том случае, если определены конечные точки входа). .