Поговорим сегодня об одном из фундаментальных сервисов платформы Microsoft Azure — Cloud Services.
Основная идея Cloud Services состоит в реализации многоуровневого решения с помощью одной или нескольких веб-ролей и рабочих-ролей (web-роль, worker-роль) для распределенной обработки запросов или данных.
Итак, вводное определение: Cloud services (Облачные службы) Microsoft Azure – это возможность создавать многокомпонентные приложения, несколько переосмысленные в сторону ролевой модели и гибкого масштабирования.
Например, при увеличении нагрузки можно масштабировать только обработчик на стороне сервера, но оставить количество экземпляров веб-фронтенда.
Примечание:
Общие моменты и основные различия между Cloud Services и Web Sites, каким образом реализует ту или иную функцию или сценарий каждая из служб можно посмотреть в статье Сравнение веб-сайтов Azure, облачных служб и виртуальных машин на русском и на английском языке.
Архитектура Cloud Services и роли
Рассмотрим принцип ролевой модели на основе типичного Web-приложения, написанного с использованием MVC (Model-View-Controller).
- Представление (Web-интерфейса пользователя);
- Контроллер (Слой бизнес-логики);
- Слой доступа к источнику данных.
Доступ к приложению осуществляется по конечной точке доступа (HTTP либо HTTPS).
- Представление меняет свое название на Web-роль;
- Контроллер – на Worker-роль;
- Слой доступа к источнику данных может быть реализован внутри отдельной Worker-роли.
Для получения данных от представления (Web-роли) обработчиком-контроллером (Worker-ролью) традиционно используется Middleware в виде сервиса очередей.
При этом в качестве Middleware может выступать например Microsoft Azure Storage Queue или Microsoft Azure Service Bus.
Использование Middleware является прекрасным примером разработки отказоустойчивых распределенных приложений.
Вместо разработки тесно связанной системы, для которой потеря одного из компонентов (например, Web-роли) будет означать неработоспособность всей системы и потерю данных разработчик может использовать Middleware в режиме брокера (Brokered Messaging).
Это значит, что Web-роль просто кладет сообщения в сервис Middleware (в очередь), где они сохраняются до тех пор, пока ими не займется сборщик мусора, либо пока они не обработаются экземплярами Worker-роли.
В то же время Web-роль не имеет понятия о том, сколько обработчиков занимаются приходящими с нее сообщениями, сущетсвуют ли эти обработчики, оффлайн они или онлайн, и не знает о статусе обработки этих сообщений (если это специально не предусмотрено).
Очевидно, что связность системы значительно снижается, ведь теперь выход из строя части системы не приведет к сбою системы в целом.
Как видно на рисунке архитектуры Cloud Services, каждая из ролей существует в некотором количестве экземпляров, выполняющих одну и ту же функцию роли.
Это означает, что, перейдя по ссылке на Web-сайт, пользователь может попасть как на первый экземпляр Web-роли, так и на любой другой, находящийся в ротации балансировщика нагрузки.
Ниже подробно описаны типы ролей и их основные характеристики:
- Web-роль. Web-роль содержит набор экземпляров-серверов с виртуальными машинами, на которых установлен IIS 7/7.5 и по умолчанию открыты несколько стандартных портов доступа по HTTP. Безопасность Web-роли обеспечивается сертификатом, привязанным к любой точке входа HTTPS.
- Worker-роль. Worker-роль содержит набор экземпляров-серверов с виртуальными машинами, на которых выполняется бизнес-логика, обычно получающая данные для своей работы из Web-роли.
По умолчанию входящие подключения к виртуальной машине на экземпляре Worker-роли, запрещены.
Проекты Worker-ролей используют следующую программную модель – наследуясь от RoleEntryPoint, класс, выполняющий бизнес-логику Worker-роли, реализует три метода:- OnStart() — вызывается при запуске роли, возвращает статус «Busy» балансировщику нагрузки до тех пор, пока не указано иное;
- Run() — выполняется постоянно, содержит основную логику;
- OnStop() — выполняется при отключении роли, 30 секунд и может быть использован для закрытия подключений, удаления объектов и т.д.
Для обеспечения непрерывной работы службы при выполнении действий по обновлению, а так же для соответствия требованиям уровня обслуживания необходимо определить хотя бы по два экземпляра каждой роли.
Конфигурация Cloud Service
Для описание конфигурации, под Cloud Services будем понимать проект, т.е. набор файлов, который описывает облачный сервис. Этот проект можно использовать в Visual Studio.
Итак, конфигурация состоит из двух XML-файлов:
- Файл определения сервиса (Service Definition file, с расширением .csdef). Задает параметры, используемые Microsoft Azure для настройки облачной службы (описание ролей, точки входа и настройки конфигурации без заданных значений).
- Файл конфигурации сервиса (Service Configuration file, с расширением .cscfg). Содержит непосредственные значения для различных параметров, например, количество экземпляров-серверов, которые будут обслуживать конкретную роль.
В файлах конфигурации Microsoft Azure также есть возможность задать два параметра, указывающих версию операционной системы, которая будет обслуживать развернутый сервис. Первый параметр – «семейство» операционной системы, атрибут osFamily, второй osVersion – «версия» операционной системы.
Сервис Microsoft Azure, получивший данную настройку производит поиск конкретного образа операционной системы определенного разработчиком семейства. Стандартное значение этой настройки «*», обозначающее, что сервис будет запущен на самой новой версии операционной системы и будет обновляться по мере выхода новых версий.
Оба конфигурационных файла при развертывании решения Cloud Service в Microsoft Azure обрабатываются специальным автоматическим сервисом Azure Fabric, который, основываясь на этих файлах, производит поиск свободных ресурсов, удовлетворяющих конфигурации, инициирует создание и установку виртуальных машин и дальнейшее развертывание решения.
Поэтому правильная настройка конфигурационных файлов имеет большое значение при развертывании в облако.
Окружения
Каждый экземпляр Сloud Services предоставляет разработчику два расположения для развернутого решения — Production и Staging, которые используются для варианта, работающего в реальной среде, и решения, развернутого для тестирования, соответственно.
В процессе развертывания разработчик производит настройку того расположения, в котором будет развернуто его решение.
Эти расположения, называются ячейками развертывания и отличаются только доменным именем и внутренними правилами маршрутизации.
Для Production-ячейки настраивается DNS-имя, указанное разработчиком при создании Cloud Service, например, http://appname.cloudapp.net, для Staging же создается временное DNS-имя следующего типа http://[guid].cloudapp.net.
После успешного тестирования решения в Staging, разработчику не нужно разворачивать решение в Production, достаточно на портале управления инициировать процедуру VIP Swap, которая свою очередь отправит запрос балансировщику нагрузки для того чтобы «поменять местами» VirtualIP, используемый для развертывания.
Таким образом, без каких либо переносов и миграций, за несколько минут решение из Staging-ячейки переходит в Production.
При выявлении ошибок в ячейке Production, процедура VIP Swap может быть инициирована повторно для продолжения тестирования решения в Staging-ячейке, которая кстати говоря не доступна конечному пользователю.
Масштабирование Cloud Service
Для Microsoft Azure Cloud Services существует возможность автоматического масштабирования на основе загрузки CPU или текущего количества сообщений в очереди хранилища Microsoft Azure.
Разработчик может отслеживать прогноз масштабирования в панели администрирования, который сообщит о необходимости выполнить масштабирование для облачного сервиса.
Чтобы настроить автоматическое масштабирование облачного сервиса, необходимо указать период ожидания (в минутах) перед каждым изменением масштаба.
Масштабирование на основе количества сообщений в очереди в очереди удобно использовать в том случае, если количество сообщений в очереди превышает определенное пороговое значение или опускается ниже его, экземпляры роли создаются или удаляются или виртуальные машины включаются в группу доступности или исключаются из нее.
Разработчик самостоятельно задает число сообщений в очереди, при котором Azure будет автоматически масштабировать сервис.
Часто при масштабировании роли выгодно масштабировать также и базу данных, используемую приложением. Если база данных связана с облачной службой, можно изменить версию и размер базы данных SQL на портале управления.
Движок авто масштабирования использует пятиминутные интервалы, и каждый интервал проверяет нагрузку на центральный процессор за последний час. Следовательно движок может инициировать процесс авто масштабирования каждые пять минут.
Но так же можно и запланировать автоматическое масштабирование приложения, настроив расписания для различных периодов.
Также возможна установка дополнительного программного обеспечения, которое называется WASABi, для осуществления автомасштабирования без участия портала управления Azure, с помощью REST API.
Azure Tools for Microsoft Visual Studio
Пакет инструментов Azure для Visual Studio полезен разработчикам для создания, управления, запуска и развертывания Web-приложений в Azure.
Пакет содержит в себе шаблоны проектов (Web-роли, Worker-роли и т.д.), возможности удаленной отладки и создания виртуальных машин, Emulator Express, расширения интерфейса Visual Studio, расширения Storage Explorer и Server Explorer, интегрированное развертывание с помощью Web Deploy в облако, IntelliTrace и многое другое.
Последний выпуск Azure Tools поддерживается следующими версиями Visual Studio:
- Visual Studio 2012
- Visual Studio 2013
- Visual Studio Express 2012 для Web
- Visual Studio Express 2013 для Web
Microsoft Azure SDK
Для обеспечения функциональности, которую разработчик использует локально, необходим Azure SDK. Azure SDK не включен в .NET Framework по умолчанию и устанавливается отдельно.
Основные компоненты Azure SDK — эмулятор вычислений и хранилища, необходимый для запуска, отладки и тестирования Cloud Services на локальном компьютере, что очень удобно в условиях отсутствия подключения к Интернету.
Эмулятор вычислений предоставляет графический интерфейс для выполнения базовых задач по управлению и просмотру диагностических логов рабочего решения Cloud Service.
Ниже перечислены некоторые различия между решением, запущенным в эмуляторе, и запущенным в облаке, что означает необходимость тестирования некоторых частей решения именно в облаке:
- Эмулятор поддерживает ограниченное количество ролей и экземпляров. Максимальное количество ролей на развертывание равно 50.
- Эмулятор предоставляет запущенным решениям администраторские права, тогда как решение, запущенное в Azure, по умолчанию не имеет администраторских прав.
- Эмулятор не моделирует полностью балансировку нагрузки.
- Эмулятор использует IIS Express, а в Azure – IIS.
- В эмулятор вычислений все роли выполняются на локальном компьютере, тогда как в Azure роли выполняются на отдельных виртуальных машинах.
Полный перечень различий доступен по следующей ссылке.
Эмулятор хранилища обеспечивает локальную среду, для моделирования трех сервисов хранилища Azure на локальном компьютере – блобов, таблиц и очередей. Основным механизмом локального эмулятора хранилища является SQL Server.
В настоящий момент графический инструмент эмулятора считается устаревшим и в будущем будет исключен из SDK. Доступ к функциям эмулятора теперь обеспечивает командная строка.
Антивирус для Cloud Services
Не так давно компания Microsoft представила антивирус для облачных сервисов Azure, обеспечивающий защиту в реальном времени или по расписанию, а так же предоставляющий сбор информации об атаках вашей учетной записи через Azure Diagnostics.
Антивирус в Azure построен на той же платформе, что и Microsoft Security Essentials [MSE], Microsoft Forefront Endpoint Protection, Microsoft System Center Endpoint Protection, Windows Intune, и Windows Defender для Windows, 8.0 и выше. И предназначен для работы в фоновом режиме.
Разработчик может настроить антивирус, основываясь на потребностях своего решения, выбрать работу защиты в режиме реального времени или сканирование по расписанию, запустить обновление средств защиты или сбор информации о вредоносных происшествиях.
Антивирус устанавливается по умолчанию на каждом экземпляре Cloud Services.
Вы можете включить службу защиты, используя базовую конфигурацию или настроить ее по собственному желанию. Настройки службы защиты по умолчанию уже оптимизированы для работы в среде Microsoft Azure. Но вы можете так же настроить их в соответствии со спецификой именно вашего решения.
Ниже представлена общая схема обеспечения работы инструмента антивируса Microsoft Azure для облачных сервисов и виртуальных машин:
Полезные ссылки
- Попробовать Azure бесплатно на 30 дней!
- Полная документация по Microsoft Cloud Services
- Центр разработки Microsoft Azure (azurehub.ru) – сценарии, руководства, примеры, рекомендации по разработке
- Twitter.com/windowsazure_ru — последние новости Microsoft Azure
- Сообществе Microsoft Azure на Facebook – эксперты, вопросы
- Изучить курсы виртуальной академии Microsoft по облачным и другим технологиям
- Бизнес и облако: лучшие практики решений
- Windows 8.1 Update для крупных организаций. Начало работы
- Гибридное облако Microsoft: Руководство по типовым решениям
- Набор средств для подготовки пользователей к Windows 8.1
- Введение в графическую библиотеку Win2D
- Загрузить бесплатную или пробную Visual Studio
- Стать разработчиком универсальных приложений Windows
Автор: maria_gore
