Windows Azure Pack — что за зверь и с чем его есть?
Всем согревающий привет от Лорда Огня!
В этот замечательный, солнечный и морозный (ух! — лад-хлад!) день уж очень хочется рассказать про что-нибудь облачное (банально, не правда ли? — смайл).
Вот как раз на тему облачности думаю я пора рассказать про такую интересную штуку как Windows Azure Pack! Это как WIndows Azure, только как-бы «у вас в кармане»! Интересно? Тогда милости прошу продолжить чтение!
Что за чудо-юдо, что за дивный зверь?
Ну давайте разберемся, что же это такое — Windows Azure Pack? Ну во-первых, он совершенно бесплатен и доступен для скачивания в открытую. Во-вторых, по сути это набор аналогичных технологий механизмов своего старщего и полноценного брата — Windows Azure, который является публичным облаком от Microsoft. Вот только Azure Pack надстраивается над частным облачным тандемом — Windows Server 2012 R2 и System Center 2012 R2. Надстройка же позволяет получить интерфейс внешне практически ничем не отличающийся от Windows Azure, реализуя возможности самообслуживания, мультитенантность (или многоарендность, если изволите) на разных уровнях предоставления услуг — как на уровне IaaS, так и на уровне PaaS.
Если вникнуть в детали — то по сути это набор веб-порталов, которые используют REST API и прослойку SPF (Service Provider Foundation) как его реализующую для управления различными элементами инфраструктуры: компонентами System Center, в частности VMM, базами данных SQL или MySQL, веб-сайтами IIS (по сути на уровне PaaS) — это как пример. Если полностью перечислить функционал — то получится следующая картина, описанная ниже.
Вот так выглядит полный список предоставляемых сервисов через Windows Azure Pack на сегодняшний день.
1) Портал управления для администраторов — по сути, интерфейс, через который производится вся настройка сервисов, которые можно будет предоставлять через Windows Azure Pack. В частности на этом портале создаются и управляются ресурсы частного из VMM (или же публичного облака — смотря кто конечный потребитель), учетные записи пользователей — по сути создается роль Tenant Administrator все в том же VMM, планы предоставления услуг (план — это набор услуг который можно скомпоновать и предоставить пользователю через создание подписки), задать квоты на потребляемые ресурсы, а также установить механизмы биллинга для потребляемых ресурсов за счет сторонних компонентов, например Cloud Cruiser.
Вот так выглядит созданный пользователь и проассоциированная с ним подписка в Windows Azure Pack с точки зрения VMM.
2) Портал управления для пользователей — это по сути интерфейс для потребления услуг конечным пользователем — например задачу развертывания, мониторинга и управления веб-сайтами, виртуальными машинами или же сервисными шинами можно реализовать черз этот портал.
3) Service management API — это по сути REST API, который позволяет интегрировать порталы Windows Azure со сторонними решениями, например системами биллинга. Также этот механизм позволяет перенести функционал Windows Azure в кастомизированные, собственные веб-порталы (читай — интерфейсы). Тут главное разобраться — можно полностью реализовать весь функционал Windows Azure Pack на портале внешне ничего с ним общего даже не имеющим — да здравствует свобода выбора и конкурентное преимущество!
4) Виртуальные машины — по сути это уровень IaaS в области предоставления виртуальных машин как Windows, так и Linux. Данный портал включает в себя возможности создания галереи образов ВМ, аналогично своему взрослому брату, а также настройки виртуальных сетей и области масштабирования разворачиваемых компонентов.
5) Сервисная шина (Service Bus) — сервис, предоставляющий надежную систему обмена сообщениями и данными между распределенными приложениями. Данный механизм действует по подписке на сообщения на основе запросов или тем публикаций или подписок.
6) SQL и MySQL — по сути это сервис на уровне PaaS для предоставления экземпляров баз данных на указанных платформах, используется в сочетании с веб-сайтами, как правило. Тут важо понимать, что SQL можно и на уровне IaaS развернуть, т.е. получить виртуальную машину с СУБД, но в данном случае модно скзать, что предоставляется доступ к определенному экземпляру базы данных с квотой на ее объем, иными словами на ВМ с SQL может быть множество различных изолированных пользователей на уровне PaaS, который не имеют доступа к самой ВМ, только к СУБД, да и то — только к своему собственному экземпляру БД.
Пример подключения СУБД SQL на уровне PaaS в Windows Azure Pack.
7) Автоматизация и расширенные функции — по сути портал для создания кастомных, индивидуальных сервисов и их включение в работу пользователя. Можно, например, создавать runbook’и с целью автоматизации рабочих потоков и бизнес-процессов, а также исполнять их.
Где взять и как поставить?
Наверное, один из самых простых в установке продуктов из всех, с которыми мне приходилось работать.
Необходимо запустить наш Web Installer на машине, где планируется развернуть Azure Pack. Для начала рекомендую использовать экспресс-метод — это когда все роли и компоненты Azure Pack разворачиваются на одном сервере на базе Windows Server 2012 / 2012 R2.
Вот собственно и ссылка на установщик. Далее просто выбираем все компоненты и кликаем на Next->Next->Next>))))).
Так выглядит установщик Windows Azure Pack.
На всякий случай — список предварительных требований к установке:
• Windows Server 2012 или Windows Server 2012 R2
• Microsoft Web Platform Installer 4.6
• Internet Information Services (IIS) 8 или IIS 8.5
С точки зрения требования к оборудования картина такая:
• 8 ГБ ОЗУ. Если вы запускаете внутри ВМ, то настоятельно рекомендуется НЕ ИСПОЛЬЗОВАТЬ динамическую память.
• 40 ГБ дискового пространства.
По скольку Windows Azure Pack — это веб-портал, то по умолчанию понадобится доступ некоторым портам, на брандмауэре открыть их нужно будет:
Admin API (API функций администратора)
30004
Management portal for administrators (Портал управления для администраторов)
30091
Authentication site (Сайт аутентификации)
30071
Configuraton site (Сайт настройки и конфигурирования)
30101 — Локальная подсеть
Monitoring (Мониторинг)
30020
MySQL resource provider (Провайдер подключения СУБД MySQL)
30012
SQL Server or MySQL resource provider (Провайдер подключения СУБД SQL или MySQL)
30010
Tenant API (API для работы с пользовательскими функциями — внутренний)
30005
Tenant public API (API для работы с пользовательскими функциями — публичный)
30006
Management portal for tenants (Портал управления для пользователей)
30081
Usage (Служебный портал)
30022
WebAppGallery (Галерея веб-приложений)
30018
Windows authentication site (Сайт аутентификации)
30072
Как-то так выгляди общая история с WAP (Windows Azure Pack) — я естественно призываю самостоятельно попробовать его в деле, развернуть и настроить — а потом поиграть уже с сервисами и его функциями — крайне интересное занятие выходит на практике! Удачных Вам экспериментов!
Обзор: Windows Azure — правильно сделанный облачный хостинг виртуальных машин
Добрый день, уважаемые коллеги,
Представляю вам перевод статьи от нашего зарубежного айтишника-коллеги про Windows Azure Virtual Machines. В связи с большим количеством идиоматических и просто словесных изысков, местами перевод довольно вольный.
Некоторые из самых главных противостояний Microsoft не ведутся в открытую, на спорном поле, на котором главенствует общественное мнение, постоянно при этом освещаемое СМИ. Но, если же есть что-то, что Microsoft всегда делали лучше конкурентов — так это распахивание новой целины, нахождение новых возможностей и точная, но безотказная их обработка. Apple и Samsung могут, конечно, и дальше держать нос по курсу, тупиком которого всегда будет бытовая электроника; Microsoft же имеет куда больший потенциал, будучи восходящей звездой на облачной арене. Это противостояние началось со стремления Microsoft перенести электронную почту в облако Office 365, дальше же в битву за господство отправляются Windows Azure и XaaS.
Если вы все еще считаете, что мы еще не перешли в эпоху «больших данных», вы дико ошибаетесь. Наши потребности в данных уже достигли астрономического уровня, что подтверждает IBM: 90 процентов данных, которые мы имеем сегодня, было создано только за последние два года. Вовсе не удивительно, что большая часть этих растущих потребностей в данных в настоящее время перебрасываются в виртуальную среду, будь то локальная инфраструктура под управлением VMWare или Hyper-V или лично мой выбор: виртуальные машины в облаке.
Прежде чем углубиться в свои рассуждения о Microsoft Azure как о платформе, на которой можно размещать виртуальные машины, позвольте мне сказать, что я и несколько моих клиентов использовали этот ресурс на ограниченной основе примерно с октября прошлого года. Тем временем Microsoft тихо вывела IaaS-составляющую Windows Azure из беты, что произошло всего несколько недель назад. Наряду с замечательными выкаченными SLA для виртуальных машин (99,95%), компания еще и всерьез намерилась ввязаться в ценовую войну с гигантами рынка Аmazon, войну, исхода которой предсказать не представляется возможным. Так что, если вы думали, что Microsoft позиционировала Azure как не более чем некий домашний проектик, стоит еще раз подумать.
Сейчас жаркая пора – ресурсы переходят из физической среды в облачную. По моему мнению, как консультанта многих представителей мелкого и среднего бизнеса в Чикаго, виртуальные машины, размещенные в облаке, больше подходят для маленьких организаций (до 25 человек), и этому есть причины. Некоторые из них – самые серьезные преимущества облачных виртуальных машин над виртуальными машинами в локальной инфраструктуре – перечислены ниже:
Есть и другие аспекты, но мои первые впечатления от Azure были крайне положительными. Нет, были и проблемы, но, если сравнивать с Amazon EC2, который я использовал в то же время, я отдаю предпочтение Azure.
Там все просто, очень достойные по сравнению с конкурентами цены, и есть гибкость, которая нужна любому проекту по виртуализации. Microsoft даже предоставляет возможность запуска в облаке Linux.
Использование Azure означает то, что вы имеете доступ к быстрейшим каналам связи. Инфраструктура датацентров Microsoft одна из лучших в мире, и скриншот выше с результатами тестирования скорости для виртуальной машины с Server 2012, расположенной в Production в Azure, говорит сам за себя.
Amazon и Microsoft – не единственные, кто выступает на арене виртуальных машин в облаке. Какое-то время назад в игру вступили RackSpace и множество мелких вендоров типа SoftSys, PayPerCloud и MyHosting. Я это пишу не для того, чтобы как-то принизить этих ребят, поскольку у меня немного опыта работы с SoftSys, но они просто не могут соревноваться с Azure в двух основных аспектах: количестве предоставляемых функций и цене. В этих двух аспектах Microsoft и Amazon лидируют.
Конечно, Google запустил в середине 2012 года Compute Engine. Но, так как они поддерживают виртуальные машины только на Linux, да еще и с определенными вопросами по загрузке, я не рассматриваю Google как серьезного игрока. Пока. На мой взгляд, сервису необходимо добавить поддержку виртуальных машин под управлением Windows для того, чтобы конкурировать с Azure и EC2.
Старая-добрая война цен? Ничего подобного
Я не из тех, кто оценивает компании по одной только стоимости – я знаю, что есть гораздо больше факторов, играющих роль в сравнении качества. Но сегодня бюджеты играют роль, и, когда планка качества одинакова, смотрят на бюджеты. Поэтому Microsoft должны удерживать Amazon, если хотят превратить развивающийся Azure в сервис, которым будут пользоваться все. Также, как Microsoft побили ценой провайдеров Exchange со своим Office 365, я думаю, что была создана арена виртуальных инфраструктурных сервисов, на которой всего два игрока – Amazon и Microsoft.
Это помогает Microsoft держать планку ценообразования такой же, либо меньшей, нежели Amazon EC2 и S3. Своим недавним решением снизить цены на 21-33 процента Microsoft даёт техническому коммьюнити уверенность в том, что корпорация хочет выровнять рынок – основываясь на функциональности, а не цене. Моим клиентам это помогло рассматривать Azure в качестве вполне жизнеспособного конкурента.
Но сравнение цен Amazon и Microsoft – то еще болезненное занятие. Вебсайт Amazon EC2 настолько коряв, что есть одна страница, описывающая цены и сравнительные таблицы сервисов, для понимания характеристик которых необходимо вернуться на страницу, описывающую типы экземпляров виртуальных машин. Похоже, Amazon хочет создать облако непонимания.
Калькулятор затрат Azure же, в отличие от, прост до такой степени, что достаточно использовать веб-форму, расчитывающую стоимость используемых сервисов налету в зависимости от количества виртуальных машин, выбранных исходя из необходимой производительности. При этом можно смешивать и сравнивать развертывания Windows и Linux, добавлять экземпляры SQL, и так далее. Просто, быстро, четко – я, как технический специалист и как клиент, ценю, когда компании используют KISS.
Чисто на ценовых позициях Microsoft наступает на цены Amazon достаточно для того, чтобы это стоило отметить. Ниже представлено сравнение цен от 7 мая 2013, основанное на публично доступных ценах. Для Amazon использовались цены US East как самые низкие цены на сервисы Amazon в США.
Как можно увидеть, практически аналогичный экземпляр Medium Windows у Microsoft стоит меньше на более чем 12 процентов. Перед тем, как вы скажете, что «есть же различия в количестве памяти», обратите внимание, что эта разница – всего 6 процентов. Если рассматривать цифры, то это все равно означает, что Microsoft предлагает цену на 6 процентов лучшую нежели Amazon. Для той организации, которая думает на тему того, чтобы использовать эти виртуальные машины в режиме нон-стоп многие месяцы, эта небольшая разница существенна. Для тех, кому интересно, что скрывается за unit of EC2 processing power, вы можете почитать официальный FAQ.
Такое же преимущество в чистых цифрах у Microsoft и в том случае, если мы вырастаем до, например, уровня Extra Large:
Управление тоже считается, и тут Azure выше EC2
Еще одной областью, в которой Microsoft укладывает Amazon, является управление. Если вы хотите быстро развернуть виртуальную машину на Amazon, вам сначала нужно изучить здоровенный справочник, иначе может так получиться, что вы выберете слишком большой экземпляр и получите чек-сюрприз. Пациенту не станет лучше, пока Amazon не предпримет серьезных решений по тому количеству шагов, которые нужно совершить для создания экземпляра на EC2.
Портал управления Microsoft Azure (также известный как просто Портал) выглядит достаточно цельно, прост в освоении и управлении и логично сбалансирован. Панель управления же Amazon EC2 – развал технических жаргонизмов и ссылок. Неудивительно, что мне больше нравится работать на портале управления Azure, нежели копаться на свалке Amazon.
Портал управления Microsoft понятен и четок. Хотите виртуальную машину? Нажмите на большой кнопке New в левом нижнем углу, выберите ОС и заполните несколько необходимых текстовых полей. Далее портал управления будет в реальном времени сообщать о том, какой статус у развертываемой виртуальной машины.
Еще кое-что – управление различными сервисами у Amazon нелогично разнесено по разным панелям. Управление EC2 отлично от управления S3 и RDS. Почему нельзя было сыграть красиво и разместить все на едином портале управления, как у Azure? Если мне нужно объяснить малому бизнесу, как управлять несколькими сервисами Amazon AWS, я не представляю, как все это объяснять.
Вот так Amazon предлагает управлять их сервисами онлайн. У каждого сервиса – собственная панель управления.
Я отлично знаю, что большинство организаций не будет проводить много времени в онлайн-панелях управления, но есть множество ситуаций, в которых нужно включать-выключать виртуальные машины или развертывать тестовые среды для различных задач. Подход к управлению облачными сервисами Microsoft выглядит гораздо более цельным, осмысленным и «взрослым», даже учитывая то, что Amazon на этом рынке дольше всех. Возраст не всегда полезен, как оказалось.
Производительность и надежность – приз у Azure
Microsoft, может, и относительные новички на облачной арене, но работают они однозначно как ветераны, если судить по отчетам энтерпрайз-вендора систем хранилища данных Nasumi. Nasumi пару месяцев назад опубликовали их второй отчет State of Cloud Storage, и Azure выиграла по многим аспектам, включая производительность и надежность. Свои выводы Nasumi подкрепили довольно жестким заключением: “Microsoft Azure практически во всех категориях ушли далеко вперед по сравнению с Amazon S3”.
О каких категориях говорили Nasumi? Тесты были проведены с ноября 2012 по январь 2013:
• Скорость: Azure оказалась на 56 процентов быстрее, нежели их конкурент Amazon S3.
• Доступность: Скорость ответа Azure была на 25 процентов быстрее, нежели у Amazon S3, у которых второе место.
Единственное, в чем Amazon обошли Azure, это масштабируемость, но и то всего на 1.3 процента. «Мало того, что Microsoft в чистых тестах значительно превзошли конкурентов — их облачная платформа для хранения данных не выдала ни одной ошибки на 100 миллионов операций чтения и записи», говорится в отчете. Amazon плотно занял второе место, но Nasumi уверены, что Azure вполне может быть лидером в облачном хранении данных и облачных сервисах.
Возможности Azure выглядят безграничными
В этом обзоре мы рассмотрели только виртуальные машины Azure. Но при всем при том, что мы увидели, в этой области Microsoft может ограничить только небо. Платформа уже содержит много предлагаемых сервисов, например, облачный SQL, мобильные сервисы, блобы, хранилище данных, и аппетиты Microsoft по переходу всего в облако не уменьшаются.
Возьмем, например, возможность аутентификации в Azure с помощью Active Directory. Сегодня эта функция ограничена только платформой и федерацией с существующими сервисами и локальной инфраструктурой AD, но только представьте, если мы сможем взять все оставшиеся локальные сервера AD и поместить их в облако? Я знаю, что это реально, и ожидаю, что это скоро начнет происходить. Дальнейшие изыскания еще больше уверили меня в свете свежих новостей о новом проекте, находящемся в разработке. Под кодовым именем Mohoro Microsoft рассматривают разработку облачного VDI, рынок которого сейчас занят игроками типа Citrix. Если Microsoft сделает все правильно и встроит эту функцию в Azure на основе оплаты-по-факту-использования, VDI может стать гораздо дешевле и доступнее для мелкого бизнеса.
Подобные сценарии VDI в экосистеме Windows были традиционно доступны только энтерпрайзу. Почему? Дорогое железо; дорогой софт; сложное лицензирование; огромные затраты на планирование; полный поворот в том, как организация реализует свою десктопную технологию. Azure уже доказал, что может предоставить бэкенд для реализации различных сценариев. Не сомневаюсь, что они могут сделать “VDI для народа» уже очень скоро.
И, если Windows проходит путь к модели оплаты-по-факту-использования, то остальные продукты Windows впоследствии отправятся за Windows. Сегодняшние усилия Microsoft по превращению Office в 365-платформу не меняют тот факт, что софт все еще надо загружать и устанавливать локально.
Если же Azure будет развиваться в следующие 5-10 лет, это все может стать достоянием прошлого. Представьте, что вы сможете просто выбрать, какие приложения Office вы хотите использовать, нажать кнопку и налету получить их в десктопе Windows на Azure за несколько секунд.
Microsoft (почти) все правильно делает с Azure
Microsoft Azure идеален? Конечно, нет. Есть проблемы, но они не делают сервис менее привлекательным. Например, резервирование статических IP для виртуальных машин – все еще боль тогда, когда вы удаляете виртуальную машину. Еще Microsoft не избегает детских ошибок со своим проектом, например, как произошло в феврале прошлого года. Но, как и с любым другим облачным сервисом, есть проблемы, и они решаются. Подождем и посмотрим, что будет дальше. Непохоже же, что Google Apps не подвержены простоям.
Если же вы ищете сервис, который достаточно гибок для реализации различных сценариев, имеет хорошие цены и авторитет в вопросах безопасности, мне кажется, большего просить невозможно. Azure прошла путь от сервиса, добавленного задним числом, до полноценного предложения, которым я уже воспользовался для многих клиентов, и расчитываю сделать еще больше в будущем.
Будет интересно, насколько жизнеспособна идея с VDI на Azure, и выгорит ли она или нет. Некоторые исследования уже выяснили, что VDI используется более 80 процентов организаций, и цифра растет. Тем временем, как индустрия пытается уйти от Редмонда, такие качественные предложения будут их обратно выталкивать. Надеюсь, что другие, типа Amazon, не отстанут в этом.
Подробное описание возможностей разработки с Microsoft Azure Cloud Services
Поговорим сегодня об одном из фундаментальных сервисов платформы Microsoft Azure — Cloud Services.
Основная идея Cloud Services состоит в реализации многоуровневого решения с помощью одной или нескольких веб-ролей и рабочих-ролей (web-роль, worker-роль) для распределенной обработки запросов или данных.
Итак, вводное определение: Cloud services (Облачные службы) Microsoft Azure – это возможность создавать многокомпонентные приложения, несколько переосмысленные в сторону ролевой модели и гибкого масштабирования.
Например, при увеличении нагрузки можно масштабировать только обработчик на стороне сервера, но оставить количество экземпляров веб-фронтенда.
Примечание:
Общие моменты и основные различия между Cloud Services и Web Sites, каким образом реализует ту или иную функцию или сценарий каждая из служб можно посмотреть в статье Сравнение веб-сайтов Azure, облачных служб и виртуальных машин на русском и на английском языке.
Архитектура Cloud Services и роли
Доступ к приложению осуществляется по конечной точке доступа (HTTP либо HTTPS).
Для получения данных от представления (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-роли, так и на любой другой, находящийся в ротации балансировщика нагрузки.
Ниже подробно описаны типы ролей и их основные характеристики:
Для обеспечения непрерывной работы службы при выполнении действий по обновлению, а так же для соответствия требованиям уровня обслуживания необходимо определить хотя бы по два экземпляра каждой роли.
Конфигурация Cloud Service
Для описание конфигурации, под Cloud Services будем понимать проект, т.е. набор файлов, который описывает облачный сервис. Этот проект можно использовать в Visual Studio.
Итак, конфигурация состоит из двух XML-файлов:
Сервис 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:
Microsoft Azure SDK
Основные компоненты Azure SDK — эмулятор вычислений и хранилища, необходимый для запуска, отладки и тестирования Cloud Services на локальном компьютере, что очень удобно в условиях отсутствия подключения к Интернету.
Эмулятор вычислений предоставляет графический интерфейс для выполнения базовых задач по управлению и просмотру диагностических логов рабочего решения Cloud Service.
Ниже перечислены некоторые различия между решением, запущенным в эмуляторе, и запущенным в облаке, что означает необходимость тестирования некоторых частей решения именно в облаке:
Эмулятор хранилища обеспечивает локальную среду, для моделирования трех сервисов хранилища 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 для облачных сервисов и виртуальных машин: