Методические указания к практическим занятиям по дисциплине «Распределенная обработка информации в автоматизированных системах»

Основные характеристики типов ролей: Web-роль. Web-роль содержит набор экземпляров-серверов с виртуальными машинами, на которых установлен IIS 7/7.5 и по умолчанию открыты несколько стандартных портов доступа по HTTP. Безопасность Web-роли может быть обеспечена сертификатом, привязанным к любой точке входа HTTPS. Worker-роль. Worker-роль содержит набор экземпляров-серверов с виртуальными машинами, на которых выполняется (обычно – в бесконечном цикле) определенная бизнес-логика, часто получающая данные для своей работы из Web-роли. По умолчанию входящие подключения в виртуальную машину, установленную на экземпляре Worker-роли, запрещены. Можно провести аналогию с Windows-сервисом (обычно проекты Worker-ролей используют аналогичную Windows-сервису программную модель) – наследуясь от RoleEntryPoint, класс , выполняющий бизнес-логику Worker-роли, использует три метода – OnStart() (вызывается при запуске роли, возвращает статус Busy балансировщику нагрузки до тех пор, пока не указано иное), Run() (выполняется постоянно, содержит основную логику) и OnStop() (выполняется при отключении роли, 30 секунд, может быть использован для закрытия подключений, удаления объектов и так далее). Рис. 3. Роли в Cloud Service Ход практической работы. Конфигурация Cloud Service В данном случае под Cloud Services мы понимаем проект (набор файлов), который описывает облачный сервис, данный проект может использоваться средой разработки Visual Studio. Конфигурация состоит из двух XML-файлов: Файл определения сервиса (Service Definition file, файл с расширением .csdef), содержащий описание ролей, точек входа в них (порты с указанными протоколами, открытые клиенту) и настройки конфигурации без заданных значений (например, строки подключения). Файл конфигурации сервиса (Service Configuration file, файл с расширением .cscfg), содержащий непосредственные значения для различных настроек, например, количество экземпляров-серверов, которые будут обслуживать конкретную роль, или значения для описанных в файле определения сервиса настроек конфигурации. В файлах конфигурации 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-ячейке, недоступной конечному пользователю. Рис. 4. VIP Swap Масштабирование Cloud Service Windows Azure Cloud Services могут быть автоматически масштабируемы на основе загрузки CPU или текущего количества сообщений в очереди сообщений хранилища Windows Azure. В панели администрирования Windows Azure Cloud Service пользователь может просматривать прогноз масштабирования, который сообщает о необходимости выполнить масштабирование для развернутого облачного сервиса. Для настройки автоматического масштабирования облачного сервиса необходимо указать период ожидания после каждого изменения масштаба. Пользователь может указать время ожидания в минутах перед следующим увеличением или уменьшением масштаба. Рис. 5. Маштабирование 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, ServiceBus и т.д.), в Visual Studio появляется интегрированное развертывание с помощью Web Deploy прямо в облако, IntelliTrace и многое другое. С каждой новой версией Windows Azure Tools появляется большое количество серьезных нововведений, с которыми можно ознакомиться по следующей ссылке - http://msdn.microsoft.com/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-задачи приведен и описан ниже. Атрибуты:

Похожие:

	Методические указания к практическим занятиям по дисциплине «экономическая... Методические указания к практическим занятиям по дисциплине «Экономическая география и регионалистика мира» для специальности 036401-...		Методические указания к практическим занятиям студентов по учебной дисциплине фармакология Методические рекомендации к практическим занятиям для студентов по учебной дисциплине фармакология. – Ульяновск: огбоу спо умк, 2014....
	Методические указания к практическим занятиям по пп. 01 «Учебная... Представлены методические указания к практическим занятиям по учебной практике, образцы документов для выполнения практических заданий,...		Методические указания к семестровым и практическим занятиям рпк «Политехник» Правоохранительные органы рф: Методические указания к семестровым и практическим занятиям / Сост. – И. И. Евтушенко; Волгоград гос...
	Методические указания по дисциплине «Экономическая теория» Методические указания по подготовке к семинарским и практическим занятиям по дисциплине «Экономическая теория». — Ростов н/Д: дгту,...		Методические указания для студентов к практическим занятиям с использованием программы Бухгалтерский учет. Методические указания для студентов к практическим занятиям с использованием программы «1С: Предприятие. Бухгалтерия...
	Методические рекомендации по разработке методических указаний к практическим... Методические рекомендации по разработке методических указаний к практическим занятиям, лабораторным работам по дисциплине/ Составители...		Методические указания к практическим занятиям по дисциплине «Основы научных исследований» Новосибирский государственный архитектурно-строительный университет (Сибстрин), 2004
	Методические указания к практическим занятиям по дисциплине «отраслевая... Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования		Методические указания к практическим (семинарским) занятиям по учебной дисциплине «Русский язык» Предметно-цикловая комиссия общегуманитарных и социально – экономических дисциплин