Цель лекции: Ознакомление с организацией Web-сервисов и управлением ими в новой версии Windows Azure.
Презентацию к лекции вы можете скачать здесь.
Как уже отмечалось, для создания Web-сервиса его необходимо прежде всего реализовать с использованием какого-либо инструмента, например, Visual Studio. Затем его необходимо подготовить к публикации в облаке (средствами Visual Studio) и, войдя на портал облака, осуществить рабочее развертывание сервиса в облаке. Далее, в облаке имеются возможности мониторинга сервиса, его настройки, визуализации информации о его масштабе
Для организации облачных web-сервисов в Azure реализован целый ряд новых компонент. Среди них - Traffic Manager (Управление трафиком), Connect (Соединения), CDN (Сеть кэширующих серверов). Они облегчают работу пользователям облака и дают дополнительные возможности управления сервисами. Интересно, что набор этих компонент постоянно расширяяется.
Компонента Windows Azure Соединения (Connect) предназначена для описания и обработки виртуальной сети. Позволяет настроить подключения между компьютерами в локальной сети и ролями (т.е. процессами), запущенными в Azure.
Компонента Traffic Manager (Диспетчер трафика) предназначена для управления пользовательским трафиком своих сервисов в Azure в различных центрах обработки данных и визуализации информации о них. Под трафиком в данном контексте понимается распределение загрузки между различными, удаленными друг от друга, центрами обработки данных (например, ЦОД Microsoft в Редмонде, штат Вашингтон, США, и в Дублине, Ирландия), на компьютерах которых могут выполняться облачные сервисы одного и того же пользователя.
Принципы балансировки нагрузки сервисов в некотором смысле аналогичны принципам распределения ресурсов в операционных системах (например, Round Robin – поровну, по очереди, "по кругу").
В предыдущей лекции мы создали средствами Azure Compute (облачного портала) "пустой" Web-сервис saf1. Рассмотрим теперь наиболее удобный способ реализации Web-сервиса – средствами Visual Studio. В примерах использована версия Visual Studio 2010.
Прежде всего, для получения необходимых полномочий необходимо запустить Visual Studio от имени администратора. Для этого вызываем контекстное меню значка Visual Studio на панели инструментов и в нем выбираем соответствующий пункт (рис 8.1).
(рис 8.1) Запуск Visual Studio от имени администратора
Затем создаем проект, содержащий Web-сервис, реализованный на базе ASP.NET (т.е. шаблон Web-страницы). Соответствующий пример имеется в документации по Azure. Назовем проект WindowsAzureProject1. Web-страница сервиса содержит сообщение "Hello World from Professor Safonov’s course on Windows Azure", по которому можно определить, что это именно наш Web-сервис (рис 8.2):
(рис 8.2) Создание проекта для Windows Azure
Выполняем сборку и пробный запуск проекта способом, рекомендуемым Microsoft, - выбором пункта Debug / Start without debugging. Собранный Web-сервис запускается на локальной машине с помощью эмулятора облака для тестирования.
Для подготовки к публикации сервиса в облаке выбираем в solution explorer, для имени нашего проекта WindowsAzureProject1, в контекстном меню пункт Publish (рис 8.3):
(рис 8.3) Подготовка Web-сервиса к публикации в облаке
Среда Visual Studio генерирует в поддиректории Publish два файла – файл описания сервиса и файл его конфигурации – и визуализирует в Windows Explorer ссылку на эту дисерторию на локальной машине (рис 8.4):
(рис 8.4) Генерация конфигурационных файлов сервиса для его публикации и визуализация поддиректории Publish
Эту директорию необходимо запомнить для последующего развертывания сервиса в облаке средствами портала Windows Azure.
На рис 8.5 изображен результат тестового запуска Web-сервиса на локальной машине (обратите внимание на IP-адрес – 127.0.0.1) с помощью эмулятора облака.
(рис 8.5) Тестовый запуск Web-сервиса на локальной машине с помощью эмулятора облака
Войдем на портал Azure, на котором мы уже создали имя нашего облачного сервиса – saf1. Нам предстоит под этим именем создать рабочее развертывание в облаке реализованного нами сервиса.
Кликнув пункт "Web-службы", а затем – имя сервиса saf1, переходим к странице, на которой мы сможем указать параметры рабочего развертывания сервиса, т.е. связать имя сервиса с его реализацией и загрузить реализацию в облако под требуемым URL-адресом – saf1.cloudapp.net (рис 8.6):
(рис 8.6) Страница портала Azure для создания рабочего развертывания сервиса
Кликнув "Создать рабочее развертывание" (или "Обновить рабочее развертывание", если какая-либо реализация сервиса уже существует), переходим к странице, на которой необходимо указать пути к файлам описания и конфигурации публикуемого Web-сервиса на локальной машине (рис 8.7). Используем информацию о поддиректории Publish, которую нам ранее предоставила среда Visual Studio. При создании выбираем опцию, при которой допустимо иметь всего один экземпляр Web-роли (в общем случае, в целях повышения надежности для сервисного кода, рекомендуется иметь не менее двух экземпляров каждой роли).
(рис 8.7) Указание параметров рабочего развертывания сервиса в облаке
Наконец, рабочее развертывание сервиса в облаке выполнено, что подтверждается трассировочными сообщениями облачной среды и статусом "Выполняется" в столбце "Рабочая среда" (рис 8.8, рис 8.9):
(рис 8.8) Рабочее развертывание сервиса в облаке выполнено
(рис 8.9) Трассировочные сообщения о развертывании сервиса в облаке
Теперь, кликнув по URL-адресу http://saf1.cloudapp.net, вызываем браузер и убеждаемся, что по данному адресу сервис доступен в облаке Windows Azure (рис 8.10):
(рис 8.10) Обращение к сервису по его URL-адресу в облаке
Кликнув "Панель мониторинга", получаем информацию о мониторинге сервиса (рис 8.11):
(рис 8.11) Мониторинг сервиса
В виде диаграммы отображается процент использования процессора. Указывается также имя Web-роли нашег сервиса – WebRole1.
Кликнув "Настройки", получаем информацию о настройках сервиса (рис 8.12):
(рис 8.12) Настройки сервиса
Кликнув "Масштаб", получаем информацию о масштабе Web-сервиса. Сервис выполняется на малой конфигурации виртуальной машины – объем виртуальной памяти 1.75 Гб, число ядер процессора – 1, число экземпляров Web-роли WebRole1 – 1 (рис 8.13):
(рис 8.13) Масштаб сервиса
Кликнув "Экземпляры", получаем информацию о выполняемых экземплярах ролей (рис 8.14):
(рис 8.14) Экземпляры ролей сервиса
Средства управления Web-сервисами, пользователями, подписками, областями и др. (т.е. всей облачной вселенной) в Windows Azure поистине уникальны и, кроме того, постоянно развиваются все дальше и дальше. Использование подобных инструментов весьма полезно, так как развивает кругозор программистов и их абстрактное мышление. Некоторая сложность архитектуры – это отражение реальной сложности современного программного обеспечения, в котором воедино слились Web-технологии, средства защиты, визуализации, мониторинга и др.
Разница между такими средствами управления и, для сравнения, средствами управления пользовательскими заданиями в операционных системах прежних поколений очень велика. В прежних ОС мы могли визуализировать информацию обо всех задачах, выполняемых на одной mainframe-машине.
Легендарная команда ВЦПП (время центрального процессора пользовательских задач) в ОС ДИСПАК для БЭСМ-6 [2] позволяла узнать статус своих и других задач – сколько времени они выполняются, сколько времени им еще осталось считаться и др.
В системе же Windows Azure пользователь, как некий добрый волшебник, получает право управления всеми своими облачными заданиями, которые могут выполняться на десятках и сотнях машин в ЦОД различных регионов мира, да еще и право перераспределять нагрузку между ними – например, поручить исполнение того или иного сервиса либо ЦОД в Редмонде, США, либо ЦОД в Ирландии.
Реализация сервиса может быть выполнена с помощью столь удобного инструмента, как Visual Studio, и развернута в облаке с локальной машины средствами портала Azure.
Traffic Manager - Управление трафиком
Соединения (Connect) - Компонента Windows Azure, предназначенная для описания и обработки виртуальной сети
CDN - Сеть кэширующих серверов (Content Delivery Network)
Территориальная группа – группа серверов ЦОД какого-либо региона, который пользователь выбрал для предпочтительного выполнения своих сервисов.
Основные этапы управления облачным Web-сервисом – создание имени сервиса на портале, реализация Web-сервиса средствами Visual Studio, развертывание сервиса средствами облачного портала. Возможен мониторинг сервиса, его настройки, получение информации о его масштабе и выполняемых экземплярах его ролей. В Windows Azure имеется целый ряд полезных компонент для управления сервисами: Traffic Manager (Управление трафиком), Connect (Соединения), CDN (Сеть кэширующих серверов).
Цель лекции: Ознакомление с организацией Web-сервисов и управлением ими в новой версии Windows Azure.
Презентацию к лекции вы можете скачать здесь.
Как уже отмечалось, для создания Web-сервиса его необходимо прежде всего реализовать с использованием какого-либо инструмента, например, Visual Studio. Затем его необходимо подготовить к публикации в облаке (средствами Visual Studio) и, войдя на портал облака, осуществить рабочее развертывание сервиса в облаке. Далее, в облаке имеются возможности мониторинга сервиса, его настройки, визуализации информации о его масштабе
Для организации облачных web-сервисов в Azure реализован целый ряд новых компонент. Среди них - Traffic Manager (Управление трафиком), Connect (Соединения), CDN (Сеть кэширующих серверов). Они облегчают работу пользователям облака и дают дополнительные возможности управления сервисами. Интересно, что набор этих компонент постоянно расширяяется.
Компонента Windows Azure Соединения (Connect) предназначена для описания и обработки виртуальной сети. Позволяет настроить подключения между компьютерами в локальной сети и ролями (т.е. процессами), запущенными в Azure.
Компонента Traffic Manager (Диспетчер трафика) предназначена для управления пользовательским трафиком своих сервисов в Azure в различных центрах обработки данных и визуализации информации о них. Под трафиком в данном контексте понимается распределение загрузки между различными, удаленными друг от друга, центрами обработки данных (например, ЦОД Microsoft в Редмонде, штат Вашингтон, США, и в Дублине, Ирландия), на компьютерах которых могут выполняться облачные сервисы одного и того же пользователя.
Принципы балансировки нагрузки сервисов в некотором смысле аналогичны принципам распределения ресурсов в операционных системах (например, Round Robin – поровну, по очереди, "по кругу").
В предыдущей лекции мы создали средствами Azure Compute (облачного портала) "пустой" Web-сервис saf1. Рассмотрим теперь наиболее удобный способ реализации Web-сервиса – средствами Visual Studio. В примерах использована версия Visual Studio 2010.
Прежде всего, для получения необходимых полномочий необходимо запустить Visual Studio от имени администратора. Для этого вызываем контекстное меню значка Visual Studio на панели инструментов и в нем выбираем соответствующий пункт (рис 8.1).
(рис 8.1) Запуск Visual Studio от имени администратора
Затем создаем проект, содержащий Web-сервис, реализованный на базе ASP.NET (т.е. шаблон Web-страницы). Соответствующий пример имеется в документации по Azure. Назовем проект WindowsAzureProject1. Web-страница сервиса содержит сообщение "Hello World from Professor Safonov’s course on Windows Azure", по которому можно определить, что это именно наш Web-сервис (рис 8.2):
(рис 8.2) Создание проекта для Windows Azure
Выполняем сборку и пробный запуск проекта способом, рекомендуемым Microsoft, - выбором пункта Debug / Start without debugging. Собранный Web-сервис запускается на локальной машине с помощью эмулятора облака для тестирования.
Для подготовки к публикации сервиса в облаке выбираем в solution explorer, для имени нашего проекта WindowsAzureProject1, в контекстном меню пункт Publish (рис 8.3):
(рис 8.3) Подготовка Web-сервиса к публикации в облаке
Среда Visual Studio генерирует в поддиректории Publish два файла – файл описания сервиса и файл его конфигурации – и визуализирует в Windows Explorer ссылку на эту дисерторию на локальной машине (рис 8.4):
(рис 8.4) Генерация конфигурационных файлов сервиса для его публикации и визуализация поддиректории Publish
Эту директорию необходимо запомнить для последующего развертывания сервиса в облаке средствами портала Windows Azure.
На рис 8.5 изображен результат тестового запуска Web-сервиса на локальной машине (обратите внимание на IP-адрес – 127.0.0.1) с помощью эмулятора облака.
(рис 8.5) Тестовый запуск Web-сервиса на локальной машине с помощью эмулятора облака
Войдем на портал Azure, на котором мы уже создали имя нашего облачного сервиса – saf1. Нам предстоит под этим именем создать рабочее развертывание в облаке реализованного нами сервиса.
Кликнув пункт "Web-службы", а затем – имя сервиса saf1, переходим к странице, на которой мы сможем указать параметры рабочего развертывания сервиса, т.е. связать имя сервиса с его реализацией и загрузить реализацию в облако под требуемым URL-адресом – saf1.cloudapp.net (рис 8.6):
(рис 8.6) Страница портала Azure для создания рабочего развертывания сервиса
Кликнув "Создать рабочее развертывание" (или "Обновить рабочее развертывание", если какая-либо реализация сервиса уже существует), переходим к странице, на которой необходимо указать пути к файлам описания и конфигурации публикуемого Web-сервиса на локальной машине (рис 8.7). Используем информацию о поддиректории Publish, которую нам ранее предоставила среда Visual Studio. При создании выбираем опцию, при которой допустимо иметь всего один экземпляр Web-роли (в общем случае, в целях повышения надежности для сервисного кода, рекомендуется иметь не менее двух экземпляров каждой роли).
(рис 8.7) Указание параметров рабочего развертывания сервиса в облаке
Наконец, рабочее развертывание сервиса в облаке выполнено, что подтверждается трассировочными сообщениями облачной среды и статусом "Выполняется" в столбце "Рабочая среда" (рис 8.8, рис 8.9):
(рис 8.8) Рабочее развертывание сервиса в облаке выполнено
(рис 8.9) Трассировочные сообщения о развертывании сервиса в облаке
Теперь, кликнув по URL-адресу http://saf1.cloudapp.net, вызываем браузер и убеждаемся, что по данному адресу сервис доступен в облаке Windows Azure (рис 8.10):
(рис 8.10) Обращение к сервису по его URL-адресу в облаке
Кликнув "Панель мониторинга", получаем информацию о мониторинге сервиса (рис 8.11):
(рис 8.11) Мониторинг сервиса
В виде диаграммы отображается процент использования процессора. Указывается также имя Web-роли нашег сервиса – WebRole1.
Кликнув "Настройки", получаем информацию о настройках сервиса (рис 8.12):
(рис 8.12) Настройки сервиса
Кликнув "Масштаб", получаем информацию о масштабе Web-сервиса. Сервис выполняется на малой конфигурации виртуальной машины – объем виртуальной памяти 1.75 Гб, число ядер процессора – 1, число экземпляров Web-роли WebRole1 – 1 (рис 8.13):
(рис 8.13) Масштаб сервиса
Кликнув "Экземпляры", получаем информацию о выполняемых экземплярах ролей (рис 8.14):
(рис 8.14) Экземпляры ролей сервиса
Средства управления Web-сервисами, пользователями, подписками, областями и др. (т.е. всей облачной вселенной) в Windows Azure поистине уникальны и, кроме того, постоянно развиваются все дальше и дальше. Использование подобных инструментов весьма полезно, так как развивает кругозор программистов и их абстрактное мышление. Некоторая сложность архитектуры – это отражение реальной сложности современного программного обеспечения, в котором воедино слились Web-технологии, средства защиты, визуализации, мониторинга и др.
Разница между такими средствами управления и, для сравнения, средствами управления пользовательскими заданиями в операционных системах прежних поколений очень велика. В прежних ОС мы могли визуализировать информацию обо всех задачах, выполняемых на одной mainframe-машине.
Легендарная команда ВЦПП (время центрального процессора пользовательских задач) в ОС ДИСПАК для БЭСМ-6 [2] позволяла узнать статус своих и других задач – сколько времени они выполняются, сколько времени им еще осталось считаться и др.
В системе же Windows Azure пользователь, как некий добрый волшебник, получает право управления всеми своими облачными заданиями, которые могут выполняться на десятках и сотнях машин в ЦОД различных регионов мира, да еще и право перераспределять нагрузку между ними – например, поручить исполнение того или иного сервиса либо ЦОД в Редмонде, США, либо ЦОД в Ирландии.
Реализация сервиса может быть выполнена с помощью столь удобного инструмента, как Visual Studio, и развернута в облаке с локальной машины средствами портала Azure.
Traffic Manager - Управление трафиком
Соединения (Connect) - Компонента Windows Azure, предназначенная для описания и обработки виртуальной сети
CDN - Сеть кэширующих серверов (Content Delivery Network)
Территориальная группа – группа серверов ЦОД какого-либо региона, который пользователь выбрал для предпочтительного выполнения своих сервисов.
Основные этапы управления облачным Web-сервисом – создание имени сервиса на портале, реализация Web-сервиса средствами Visual Studio, развертывание сервиса средствами облачного портала. Возможен мониторинг сервиса, его настройки, получение информации о его масштабе и выполняемых экземплярах его ролей. В Windows Azure имеется целый ряд полезных компонент для управления сервисами: Traffic Manager (Управление трафиком), Connect (Соединения), CDN (Сеть кэширующих серверов).
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.