Практикум по учебной дисциплине (стр. 5 )

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

Также возможна установка дополнительного программного обеспечения, которое называется 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. /ru-ru/library/windowsazure/ff683673.aspx.

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

Visual Studio 2012 Visual Studio Express 2012 для Web Visual Studio 2010 SP1 Visual Web Developer 2010 SP1

Рис. 6. Добавление роли в Cloud Service

Windows Azure SDK

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

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

Рис. 7. Просмотр диагностических логов запущенного Cloud Service

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

Эмулятор поддерживает ограниченное количество ролей и экземпляров. Максимальное количество ролей на развертывание равно 25, максимальное количество поддерживаемых ядер равно 20. Эмулятор предоставляет запущенным решениям администраторские права, тогда как решение, запущенное в Windows Azure, по умолчанию не имеет администраторских прав. Эмулятор не предоставляет балансировку нагрузки. По умолчанию эмулятор использует IIS Express, Windows Azure – IIS.

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

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

Рис.8. Интерфейс эмулятора хранилища

Жизненный цикл роли

Рис. 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. /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, если вы подписываетесь на события из обоих процессов.