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

Windows Azure Cloud Services

Базовым сервисом платформы Windows Azure является Cloud Services (ранее Hosted Services). В таблицу 5.1 сведены данные о том, каким образом реализует ту или иную функцию или сценарий Cloud Services и Web Sites.

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

Для того, чтобы понять принцип работы ролевой модели, можно взять в качестве примера типичное Web-приложение, написанное с использованием паттерна разработки MVC (Model-View-Controller). Типичное Web-приложение состоит из представления (Web-интерфейса пользователя), контроллера (слоя бизнес-логики, служащего также прослойкой между представлением и слоем доступа к источнику данных) и слоем доступа к источнику данных. Архитектура большинства Web-приложений на высоком уровне может быть сведена именно к такому разделению. Конечный же пользователь имеет доступ к приложению по конечной точке доступа (ссылке) по HTTP либо HTTPS.

В контексте ролевой модели будет выглядеть следующим образом – представление меняет свое название на Web-роль, контроллер – на Worker-роль, слой доступа к источнику данных же может быть реализован внутри отдельной Worker-роли. Для получения данных от представления (Web-роли) обработчиком-контроллером (Worker-ролью) традиционно используется Middleware в виде сервиса очередей. При этом сервисом Middleware может выступать как Windows Azure Storage Queue, так и Windows Azure Service Bus (о которых будет рассказано в соответствующих главах курса). Использование Middleware приводит к одной из best practice разработки отказоустойчивых распределенных приложений – вместо разработки тесносвязанной системы (в которой потеря одного из компонентов, например, Web-роли, будет означать неработоспособность всей системы и потерю данных) разработчик может использовать Middleware в режиме брокера (Brokered Messaging) – Web-роль не знает о том, сколько обработчиков обрабатывает приходящие с нее сообщения, есть ли эти обработчики, находятся ли они оффлайн или онлайн, и, если такого не предусмотрено, не знает о статусе обработки этих сообщений, кладя при этом сообщения в сервис Middleware (очередь), где они хранятся до тех пор, пока не собираются сборщиком мусора либо не обрабатываются экземплярами Worker-роли. При этом связность системы значительно ослабляется – выход из строя части системы с большей степенью вероятности не приведет к сбою всей системы.

Как уже было сказано, для каждой из ролей существует определенное количество экземпляров, выполняющих аналогичную копию роли. Это значит, что пользователь, войдя по ссылке на Web-сайт, может попасть как на первый экземпляр Web-роли, так и на второй, или на любой, находящийся в ротации балансировщика нагрузки. Это накладывает серьезные ограничения на некоторые привычные практики разработки – например, необходимо учитывать, что балансировщик нагрузки Windows Azure не является "липким", то есть нет гарантии, что пользователь, зайдя на сайт с утра и попав на экземпляр Web-роли №1, вечером попадет на тот же самый экземпляр. Учитывать это необходимо тогда, когда разработчиком реализуется механизм хранения пользовательских данных, например, сессии. В том случае, если данные сессии сохраняются локально на экземпляре Web-роли, с увеличением количества экземпляров будет увеличиваться степень вероятности того, что пользователь не увидит своих данных при следующем входе. В таких случаях рекомендуется использовать внешнее хранилище.

Примечание

Основные характеристики типов ролей:

Конфигурация Cloud Service

В данном случае под Cloud Services мы понимаем проект (набор файлов), который описывает облачный сервис, данный проект может использоваться средой разработки Visual Studio. Конфигурация состоит из двух XML-файлов:

В файлах конфигурации Windows Azure также есть возможность задать два параметра, указывающих версию операционной системы, которая будет обслуживать развернутый сервис. Первый параметр – "семейство" операционной системы, атрибут osFamily в файле конфигурации сервиса. Может иметь следующие значения: 1 (Windows 2008), 2 (Windows 2008 R2), 3 (Windows 2012). Второй параметр – "версия" операционной системы, атрибут osVersion в файле конфигурации, имеющий вид типа WA-GUEST-OS-2.15_201305-01. Получающий подобную настройку сервис Windows Azure производит поиск конкретного образа операционной системы определенного разработчиком семейства. Необходимо упомянуть, что стандартным значением этой настройки является "*", которое обозначает, что сервис будет запущен на самой новой версии операционной системы и по мере выхода новых версий будет обновлён. Механизм обновления сначала обновляет все сервисы с указанным атрибутом osVersion="*".

Корректная настройка конфигурационных файлов имеет критическое значение для развертывания в облако. Оба конфигурационных файла при развертывании решения Cloud Service в Windows Azure попадают на обработку специальному автоматическому сервису Windows Azure Fabric, который, согласно этим файлам, производит поиск свободных ресурсов, удовлетворяющих конфигурации, инициирует создание и установку виртуальных машин и дальнейшее развертывание решения на эти виртуальные машины. Таким образом, если в конфигурации сервиса настроено N экземпляров для Web-роли и M экземпляров для Worker-роли, то конфигурация развернутого в облако решения примет вид, как на изображении.

Стенды

Непосредственно при развертывании разработчиком проводится настройка того расположения, в которое будет развернуто его решение. В Windows Azure Cloud Services доступно два расположения для развернутого решения – это Production и Staging (используемые для решения, работающего в реальной среде, и решения, развернутого для тестирования, соответственно). Эти расположения, называемые ячейками развертывания, фактически отличаются только доменным именем и внутренними правилами маршрутизации. Так, для Production-ячейки внутренними сервисами настраивается DNS-имя, которое указал разработчик при создании Cloud Service (например, http://appname.cloudapp.net, собственное доменное имя указать при развертывании нельзя), для Staging же создается временное DNS-имя типа http://[guid].cloudapp.net. При переразвертывании решения в Staging-развертывание DNS-имя сбрасывается на новое.

В том же случае, если решение успешно прошло тестирование в Staging-ячейке, разработчик вместо развертывания решения в Production-ячейку, может нажатием кнопки на портале управления инициировать процедуру VIP Swap. Данная процедура отправляет запрос балансировщику нагрузки, который "меняет местами" Virtual IP, используемый для развертывания, и, таким образом, без каких-бы то ни было физических переносов и миграций за несколько минут решение в Staging-ячейке переходит в ячейку Production. Если же во время выполнения в ячейке Production выявляются ошибки, процедура VIP Swap может быть инициирована повторно, и разработчики могут исправить ошибки и протестировать решение в Staging-ячейке, недоступной конечному пользователю.

Масштабирование Cloud Service

Windows Azure Cloud Services могут быть автоматически масштабируемы на основе загрузки CPU или текущего количества сообщений в очереди сообщений хранилища Windows Azure. В панели администрирования Windows Azure Cloud Service пользователь может просматривать прогноз масштабирования, который сообщает о необходимости выполнить масштабирование для развернутого облачного сервиса. Для настройки автоматического масштабирования облачного сервиса необходимо указать период ожидания после каждого изменения масштаба. Пользователь может указать время ожидания в минутах перед следующим увеличением или уменьшением масштаба.

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

Движок автомасштабирования использует в своей работе пятиминутные интервалы, каждый интервал проверяя нагрузку на центральный процессор за последний час. Это означает, что движок может инициировать процесс автомасштабирования каждые пять минут.

Также возможна установка дополнительного программного обеспечения, которое называется WASABi, для осуществления автомасштабирования без участия портала управления Windows Azure, и с помощью REST API.

Windows Azure Tools for Visual Studio

Windows Azure Tools for Visual Studio является пакетом инструментов, которыми пользуется разработчик для создания, управления, запуска и развертывания Web-приложений в Windows Azure. В данный пакет входят шаблоны проектов (например, Web-роли, Worker-роли, Worker-роли с поддержкой Caching и т.д.), расширения интерфейса Visual Studio (например, новое представление Windows Azure Log, в реальном времени оповещающее разработчика о статусе развертывания), расширения Storage Explorer и Server Explorer (например, после установки Windows Azure Tools for Visual Studio появляется возможность управлять аккаунтом хранилища, созданным в Windows Azure Storage, Service Bus и т.д.), в Visual Studio появляется интегрированное развертывание с помощью Web Deploy прямо в облако, IntelliTrace и многое другое. С каждой новой версией Windows Azure Tools появляется большое количество серьезных нововведений, с которыми можно ознакомиться по следующей ссылке - http://msdn.microsoft.com/ru-ru/library/windowsazure/ff683673.aspx.

Windows Azure Tools могут быть установлены со следующими версиями Visual Studio:

Windows Azure SDK

Ядром всей функциональности, которую использует разработчик локально, является Windows Azure SDK. Windows Azure SDK не является частью .NET Framework, поэтому она должна устанавливаться отдельно для возможности разработки для Windows Azure.

Основными компонентами Windows Azure SDK являются эмуляторы вычислений и хранилища. Эмулятор вычислений используется для запуска, отладки и тестирования Cloud Services на локальном компьютере, что может быть осуществлено даже без подключения к Интернет. Эмулятор вычислений предоставляет графический интерфейс для базовых задач по управлению и просмотра диагностических логов для уже запущенного решения Cloud Service.

Однако, существует набор различий между решением, запущенным в эмуляторе, и запущенным в облаке:

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

Эмулятор хранилища предоставляет возможность запуска трех сервисов хранилища Windows Azure на локальном компьютере – блобов, таблиц и очередей. Сервисы запускаются в виде REST-сервисов и далее могут быть использованы из любого локального приложения по определенным портам. Основным механизмом локального эмулятора хранилища является SQL Server.

Приложение 1

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>

Атрибуты:

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. Далее компонент 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). Затем операционная система автоматически перезапускается для завершения процесса установки. После перезапуска операционной системы запускаются службы из списка автозапуска. Далее балансировщику нагрузки передается сообщение о том, что данный экземпляр готов к работе (в том случае, если определены конечные точки входа).