Платформа Windows Azure для предприятий

Вычисления в облаке уже доказали, что они заслуживают внимание со стороны как известных предприятий, так и недавно появившихся компаний. Многие предприятия смотрят на вычисления в облаке не просто с любопытством. На момент написания этой статьи было опубликовано исследование рынка ИТ-услуг, где был сделан вывод, что большинство ИТ-менеджеров на предприятиях располагает достаточными ресурсами для внедрения вычислений в облаке в сочетании с локальными.

Конечно, есть люди, настроенные весьма скептически по отношению к возможности использования вычислений в облаке непосредственно на предприятии. Тут ситуация во многом аналогична той, которая была в свое время при создании ARPANET (предшественницы Интернета); многие скептически настроенные научно-исследовательские институты не хотели присоединяться к этой сети, боясь потерять конфиденциальность своих данных. Но, как только ученые увидели, какие выгоды несет обмен данными по сети и возможность коллективной работы, их уже нельзя было остановить, а все остальное стало достоянием истории. Нынешние крупные предприятия — подобно скептикам эпохи ARPANET — находятся в стадии привыкания к смене парадигмы, связанной с тем, как приобретаются и эксплуатируются вычислительные средства.

Понимая тенденции в отрасли и запросы клиентов, Microsoft сделала крупную ставку на вычисления в облаке, выпустив платформу Windows Azure и необходимые вспомогательные сервисы для создания и выполнения сервисов индустриального уровня в облаке. В этой статье мы обсудим архитектуру платформы Windows Azure и рассмотрим, как она удовлетворяет требованиям решений корпоративного класса.

Вычисления в облаке

Существует несколько определений вычислений в облаке, но больше всего мне нравится одно из них: вычислительный ресурс доставляется как коммунальная услуга с применением стандартов и протоколов Интернета. Это определение открывает возможности для концепций «общедоступное облако» (public cloud) и «закрытое облако» (private cloud). Общедоступные облака, как и предполагает их название, открыты любому, кто умеет обращаться с кредитной картой. Закрытые облака подразумевают их эксклюзивное использование каким-либо предприятием или консорциумом.

Платформа Windows Azure, веб-сервисы Amazon, Google App Engine и Force.com — вот несколько примеров общедоступных облаков. Любой закрытый информационный центр, принадлежащий крупному предприятию, может быть назван закрытым облаком, если он использует преимущества модели унифицированных ресурсов, которая за счет виртуализации позволяет интерпретировать процессорные мощности, хранилища и сетевые каналы как пул гомогенных ресурсов.

Вычисления как одна из коммунальных услуг были давней мечтой тех, кто занимался автоматизацией производственных процессов. Инициативы Microsoft Dynamic Systems Initiative (DSI) и аналогичные от других поставщиков были нацелены на то, чтобы операторы информационных центров могли реализовать соответствующие услуги: высокая автоматизация, самоуправление, самостоятельно оптимизируемое и измеряемое хранилище, сетевые и вычислительные ресурсы. Хотя этот замысел заслуживал всяческих похвал, его внедрение шло с переменным успехом. И лишь появление средств виртуализации превратило предоставление вычислительных сервисов как коммунальных услуг в реальность. Виртуализация помогла отделить операционную систему и приложения от физического оборудования. Они интерпретируются как данные, поэтому автоматизированные процессы можно разрабатывать по запросу и размещать нужную операционную систему и другие зависимые ресурсы на целевом оборудовании.

Чтобы подготовить почву для обсуждения платформы Windows Azure, я кратко рассмотрю отраслевую терминологию облачных вычислений и спроецирую ее на платформу Windows Azure — тогда нам будет легче понять ее. На рис. 1 показаны схема отраслевой терминологии и ее сопоставление с платформой Windows Azure. В следующих разделах я подробно расскажу о различных типах облачных сервисов и различиях между ними. Рис.

Рис. 1. Платформа Windows Azure как предложение PaaS

Software as a Service (SaaS)

SaaS Software as a Service (SaaS) — бизнес-модель доставки ПО, в которой приложение размещается у провайдера или третьей стороны и становится доступным клиентам по подписке. Клиенты SaaS используют выполняемое в инфраструктуре провайдера ПО на основе оплаты текущих расходов. Вносить предоплату не требуется, поэтому клиент может не заключать какие-либо долгосрочные контракты.

Но даже на контрактной основе клиенты могут в любой момент отказаться от использования ПО. Нижележащая инфраструктура и конфигурация ПО невидимы пользователям, а значит, клиенты должны довольствоваться только предлагаемой функциональностью. SaaS построена на многопользовательской архитектуре, и контексты пользователей всегда логически отделяются друг от друга.

Многопользовательская архитектура может не устроить некоторые компании из-за самой природы их бизнеса, поэтому провайдеры могут предлагать таким клиентам физически изолированную инфраструктуру и взимать дополнительную плату, связанную с поддержкой программно-аппаратных средств. Хорошие примеры SaaS — Microsoft Business Productivity Online Suite (BPOS) и CRM Online. Microsoft также предлагает выделенный хостинг этих сервисов за дополнительную плату.

Приложения для коллективной работы между различными предприятиями пользуются большим успехом в пространстве SaaS. Поскольку аппаратно-программная конфигурация прозрачна для конечных пользователей, расходы на специалистов в области ИТ минимальны, если вообще требуются. Некоторые SaaS-приложения разрешается настраивать конечным пользователям через конфигурацию, но в подавляющем большинстве случаев такой возможности нет. В итоге участие разработчиков тоже сводится к минимуму.

SaaS способен улучшить такой аспект приложений, как время вывода продукта на рынок, и попутно устранить проблемы соответствия ИТ бизнесу, на которые часто жалуются многие клиенты. На ранних этапах внедрения SaaS на предприятии головная боль корпоративных архитекторов «теневой ИТ-персонал» (небольшая группа программистов, хорошо разбирающихся в финансовом положении предприятия и тесно связанных с какими-то бизнес-подразделениями) может препятствовать такой инициативе уровня всего предприятия или уводить ее в сторону. Группе корпоративных архитекторов нужно понимать это и вести разъяснительную работу в бизнес-подразделениях. Им также нужно спроектировать новые процессы управления или модифицировать существующие, чтобы адаптировать их для SaaS.

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

С точки зрения провайдера сервисов, любая малая компания может стать провайдером SaaS и конкурировать с крупными корпорациями — разработчиками ПО. Такие компании теперь могут сосредоточиться на своих задачах, не вкладывая большие средства в приобретение аппаратно-программной инфраструктуры и управление ею.

PaaS

SaaS выглядит правильным выбором для всех потребностей компании в ПО. Однако каждая компания имеет уникальную ИТ-среду, где могут использоваться самые разнообразные технологии — от устаревших до специфических для конкретной области бизнеса. Найти SaaS-сервис, удовлетворяющий все потребности специфической области бизнеса, зачастую невозможно, поэтому компаниям все равно приходится заниматься разработкой своих приложений. Platform as a Service (PaaS) как раз и отвечает потребностям компаний, желающих создавать и выполнять собственные приложения как сервисы. К таким компаниям могут относиться независимые поставщики ПО (ISV), провайдеры сервисов с добавочной стоимостью (value-added service providers), корпоративные вычислительные центры и все, кому необходимы собственные приложения. В случае PaaS предлагаются серверы приложений с почти бесконечной масштабируемостью за счет огромного пула ресурсов, а также необходимые вспомогательные сервисы, в том числе хранилища, защиту, инфраструктуру интеграции и средства разработки полной платформы.

Провайдер сервисов предлагает предварительно сконфигурированную, виртуализованную среду серверов приложений, в которой могут развертывать свои приложения отделы разработок предприятий. Так как провайдеры сервисов управляют оборудованием (беря на себя его модернизацию, поддержку и т. д.), а также гарантируют минимальные простои серверов приложений, участие ИТ-специалистов предприятия сводится к минимуму. Разработчики создают приложения и помечают их дескрипторами ресурсов. При развертывании соответствующий механизм связывает с таким приложением необходимые инфраструктурные возможности, объявленные в дескрипторах приложения. Ресурсы могут включать сетевые конечные точки, балансировщики нагрузки, процессорные ядра, память и зависимое ПО. Масштабирование по запросу в сочетании с управлением оборудованием и серверами приложений освобождает разработчиков от необходимости заботиться об инфраструктуре и позволяет им сосредоточиться на создании приложений. PaaS, как правило, подходит для совершенно новых приложений, так как устаревшие приложения зачастую требуют обширной переработки для соответствия правилам выполнения в изолированных программных средах.

IaaS

Infrastructure as a Service (IaaS) — аналог традиционного хостинга, где предприятие использует размещенную среду как логическое расширение своего информационного центра. Серверы (физические и виртуальные) арендуются по мере необходимости, а ИТ-специалисты, управляющие инфратсруктурой, имеют полный контроль над конфигурацией ПО. Некоторые провайдеры позволяют даже гибко настраивать аппаратную конфигурацию, что делает сервис более дорогим по сравнению с эквивалентным предложением PaaS.

В состав ПО могут входить операционные системы, платформы приложений, промежуточное ПО, серверы баз данных, корпоративные шины сервисов, сторонние компоненты и инфраструктуры, а также ПО для управления и мониторинга. За счет свободы выбора сервера приложений вы получаете гибкость в выборе средств разработки. Такого рода гибкость усложняет ИТ-среду, поскольку ИТ-специалистам заказчика приходится поддерживать эти серверы, словно они находятся на самом предприятии. Операции обслуживания могут включать установку исправлений и обновлений операционных систем и сервера приложений, балансировку нагрузки, кластеризацию серверов баз данных с аварийным восстановлением и многое другое, что направлено на уменьшение рисков, связанных со сбоями аппаратно-программных средств.

Разработчики создают, тестируют и развертывают приложения с полным пониманием конфигурации аппаратно-программного обеспечения серверов. Зачастую на заказчика возлагается даже восстановление после катастроф и поддержка непрерывной работы. Одно из важных преимуществ IaaS в том, что она разрешает перенос устаревших приложений в облако. Поскольку у IaaS гибкость столь высока, что она допускает формирование любой конфигурации, портируемость приложения между провайдерами облака затруднительна. Перенос устаревших приложений — изюминка IaaS, так как это позволяет имитировать корпоративную инфраструктуру в облаке. IaaS также поддерживает новые приложения, требующие серьезного контроля над программной конфигурацией. Например, некоторым приложениям может понадобиться установка сторонних библиотек и сервисов, и IaaS не накладывает здесь никаких ограничений.

Платформа Windows Azure обладает всеми преимуществами PaaS и в то же время обещает гибкость на уровне IaaS, как было показано на рис. 1. Платформа Windows Azure объединяет большие пулы вычислительных мощностей (серверов), сетевых ресурсов и ресурсов хранения в коммунальную вычислительную среду, из которой клиенты могут брать ресурсы по требованию и платить только за использованные ресурсы. Платформа Windows Azure (что типично для облачных сред) помогает клиентам избегать авансовых расходов и поддерживает наращивание ИТ-возможностей по мере необходимости.

Платформа Windows Azure

Эта платформа предоставляет размещенный сервер приложений, а также инфраструктуру хранения, сетевых коммуникаций и интеграции, необходимую для создания и выполнения Windows-приложений. Платформа Windows Azure, предоставляя коммунальную вычислительную среду, опирается на большие пулы аппаратного обеспечения промышленного класса. На рис. 2 показана модель ресурсов на платформе Windows Azure, где виртуализованное хранилище, сетевые и вычислительные ресурсы предоставляются по запросу через набор политик обеспечения во время развертывания. Мозг всей этой экосистемы — Fabric Controller с набором выделенных ресурсов, не являющихся частью пула ресурсов приложений. Поскольку Fabric Controller не имеет права на сбой, он обеспечивается аппаратно-программной средой с высокой степенью избыточности.

Рис. 2. Концептуальная схема вычислительной инфраструктуры (система Windows Azure может отличаться)

Пул вычислительных ресурсов включает ресурсы промышленного класса, сделанные отказоустойчивыми с помощью Fabric Controller. Архитектура последнего предусматривает раннее обнаружение сбоев приложения и создание дополнительных экземпляров для соблюдения соглашений об уровне обслуживания (service-level agreements, SLA). Так как среда Windows Azure является полной платформой хостинга приложений, она обеспечивает стабильность работы приложения, предлагая практически неограниченные ресурсы, выделяемые по требованию. Свободные ресурсы возвращаются в пул, что повышает степень их использования. Ресурсы включают процессорное время, виртуализованное хранилище и виртуализованные сетевые средства динамической перенастройки маршрутов в частных и общедоступных сетях. Физические конфигурации этих ресурсов невидимы архитекторам и разработчикам приложения.

Итак, каким образом владельцы приложения получают эти ресурсы? Берут телефон и звонят ИТ-специалисту, как это обычно делается в традиционных средах на предприятии? Нет, такой вариант никому даже в голову не приходил, так как массивы информационных центров на платформе Windows Azure управляются глубоко автоматизированными процессами под надзором специалистов. Рутинная эксплуатация информационного центра не требует участия человека. Платформа Windows Azure позволяет владельцам приложения получать необходимые ресурсы через машинно-читаемые модели, включающие использование дескрипторов ресурсов. В Windows Azure эти дескрипторы называют моделями сервиса (service models). Такие модели определяют ресурсы приложения и их зависимости, достаточные для обеспечения полноценной инфраструктуры в период выполнения без участия человека. В связи с таким уровнем автоматизации на создание инфраструктуры для приложения часто уходит менее пяти минут. Если вы сравните этот показатель с тем, что есть в типичных средах предприятия, то сразу же почувствуете всю мощь вычислений в облаке.

Вычислительная часть

Вычислительная часть платформы Windows Azure отвечает за обеспечение процессорным временем выполняемых приложений. Приложения размещаются в виртуализованнах средах, чтобы избежать любых физических зависимостей от нижележащих операционной системы и оборудования. Свободное сопряжение приложений достигается виртуализацией ресурсов, в том числе локальных файлов, хранилища (структурированного и неструктурированного), средств диагностики, мониторинга и протоколирования. Размещаемая среда реализуется как виртуальная машина (VM), поэтому сбои одного приложения не влияют на другие приложения, выполняемые на том же физическом оборудовании.

Приложения развертываются на платформе Windows Azure как пакеты ролей и связанных с ними исполняемого кода и ресурсов. Роль в Azure декларативно определяет характеристики размещенной среды. Когда развернутое приложение активируется, среда обеспечения Azure анализирует модель сервиса, выбирает предварительно сконфигурированный образ VM на основе типа роли, копирует биты приложения в VM, запускает «машину» и загружает необходимые приложению сервисы. Определение сервиса на рис. 3 представляет приложение Shopping List, используемое как пример в рамках этой статьи.

Рис. 3. Модель сервиса для рабочей и веб-ролей

Определение ShoppingListService

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="ShoppingList">
<WebRole name="ShoppingList_WebRole">
<LocalResources>
<LocalStorage name="ShoppoingList_ImageCache" sizeInMB="100"
cleanOnRoleRecycle="false"/>
</LocalResources>
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistOut"/>
</ConfigurationSettings>
</ WebRole>
< WorkerRole name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistIn"/>
</ConfigurationSettings>
< WorkerRole />
</ServiceDefinition>

Конфигурация ShoppingListService

<?xml version="1.0"?>
<ServiceConfiguration serviceName="ShoppingList">
</Role>
<Role name="ShoppingList_WebRole">
<Instances count="3" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the following two lines for application
storage needs on  local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistOut" value="shoppinglistq"/>
</ConfigurationSettings>
</Role>
<Role name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the followign two lines for local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistIn" value="shoppinglistq"/>
</ConfigurationSettings>
</Role></ServiceConfiguration>

Приложение Shopping List, представленное на рис. 3, запрашивает три экземпляра веб-роли (Web role) и два экземпляра рабочей роли (worker role). Веб-трафик к нескольким экземплярам веб-роли автоматически балансируется, и все три экземпляра будут обеспечены SSL, а также конечными точками HTTP на каждое описание модели сервиса. Чтобы не допускать полного краха приложения, Fabric Controller распределяет выделяемые под роли ресурсы по множеству доменов сбоя (failure domains). Организация домена сбоя гораздо сложнее, чем упрощенная схема на рис. 2. Простоты ради можно считать каждую серверную стойку с соответствующими сетевым коммутатором и блоком питания одним доменом сбоя.

Согласно рис. 2, Fabric Controller изначально создает одну веб-роль в каждом домене сбоя, используя стойки 1, 3 и n. Я рассмотрю надежность всего вычислительного уровня Windows Azure с точки зрения нескольких гипотетических событий. При событии 1 веб-роль 1 и рабочая роль 1 перестают отвечать в результате сбоя питания серверной стойки. Fabric Controller начинает процесс выделения ресурсов для веб-роли 1 и рабочей роли 1 в доступных стойках: 2 и 3. Чуть позже возникает событие 2, в ходе которого перемещенная веб-роль 1 не проходит проверку на работоспособность из-за сбоя приложения. Тогда Fabric Controller начинает выделять ресурсы для веб-роли 1 в одной из других доступных стоек.

В течение этих событий доступность приложения никак не страдает. Запросы на веб-страницы по-прежнему обслуживаются по меньшей мере двумя оставшимися веб-ролями, а минимум одна рабочая роль продолжает извлекать транзакционные элементы из очередей и вести запись в хранилище Windows Azure Storage. Fabric Controller в любой момент времени старается сохранить равновесие для трех работоспособных экземпляров веб-роли и двух экземпляров рабочей роли. На практике серверные стойки могут быть оборудованы избыточными источниками питания и сетевыми коммутаторами, поэтому рециклинг роли и перераспределение ресурсов для нее чаще вызывается сбоями приложения или необходимостью вертикального масштабирования из-за возросшего количества запросов.

Модель сервиса в Shopping List запросила две рабочие роли, чтобы избежать появления единственной точки сбоя. Даже несмотря на то что веб-уровень и уровень пакетной обработки отделены от очередей Windows Azure Queues, все равно лучше запрашивать минимум две рабочие роли при хостинге сервисов пакетной обработки повышенной ответственности, для которых важна скорость ответа. Если скорость ответа для вас не имеет значения, вы можете обойтись всего одной рабочей ролью.

Из рис. 1 видно, что платформа Windows Azure дает преимущества PaaS и в то же время сохраняет гибкость IaaS. Это достигается моделью развертывания на основе политик, публикуемой рабочими и веб-ролями, CGI-ролями, а также множеством ролей, которые появятся в будущем. Список поддерживаемых ролей продолжает расширяться для удовлетворения потребностей клиентов в развертывании разнообразных приложений.

Архитектура облака, ориентированная на экономию расходов

Архитектурные решения могут сильно влиять на экономические характеристики ИТ-систем, эксплуатируемых малыми и крупными предприятиями. Хотя вычисления в облаке обеспечивают динамичность и гибкость ИТ, при создании архитектуры решения следует принимать во внимание расходы на его эксплуатацию предприятими. Архитектура облачного приложения должна не только обеспечивать нужную функциональность и важнейших характеристики (масштабируемость, доступность, надежность и производительность), но и оптимизировать затраты на эксплуатацию. В случае эксплуатации непосредственно на предприятии архитекторы приложения редко уделяют внимание стоимости хранилища, сетевой полосы пропускания или расходам на процессорное время, а ведь это капитальные затраты на уровне организации.

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

Рассмотрим модель затрат на платформе Windows Azure применительно к приложению Shopping List (рис. 4). На схеме показано логическое представление архитектуры Shopping List; стрелки указывают направление передачи данных. Пунктирными стрелками обозначено использование пропускной способности внутри информационного центра, а сплошными — прием и передача данных информационным центром в облаке.

Рис. 4. Модель тарификации для приложения на платформе Windows Azure

На платформе Windows Azure тарифицируются передачи данных только на входе и выходе, а локальные перемещения данных внутри информационного центра игнорируются. Любые данные, записываемые в Windows Azure Queues, не тарифицируются по занимаемой полосе пропускания и месту в хранилище, так как использование ими места в хранилище является в высшей степени кратковременным. Однако операции с очередями оплачиваются индивидуально за каждую транзакцию. Выборка, считывание или запись элемента очереди считается транзакцией.

Тарифы на использование серверов в Windows Azure зависят от количества ролей и времени размещения приложения. То есть, даже если приложение не получает запросы от конечных пользователей, биллинговая система в Windows Azure будет начислять почасовую плату для каждого экземпляра роли в состоянии «suspended» (приостановлена) и «started» (запущена). Поэтому рекомендуется самостоятельно позаботиться о том, чтобы количество активных ролей уменьшалось, если интенсивность использования приложения падает. На данный момент это ручной процесс; однако вы могли бы автоматически масштабировать приложение, применяя шаблоны масштабирования и используя диагностические данные и API управления сервисами. За пользование Windows Azure Tables, очередями и большими объектами данных (Blobs) взимается ежемесячная плата за хранение данных в соответствующих хранилищах, причем расчеты осуществляются применительно к каждому гигабайту на запись. Подробнее о ценообразовании в Windows Azure изложено в табл. 1 (приведена та информация, которая была опубликована на момент написания этой статьи).

Табл. 1. Тарифы в Windows Azure

Ценообразование на платформе Windows Azure очень простое за исключением оплаты хранилища, используемого под большие объекты данных и таблицы. Использование Windows Azure Storage в каждой учетной записи определяется ежедневно в цикле биллинга и вычисляется ежедневное среднее значение. Конечная оплата вычисляется умножением среднего ежедневного значения на $0,15/Гб. Например, если вы сохраняете 20 Гб в первый день, добавляете 10 Гб на второй день, потом еще 5 Гб на третий день, а на четвертый удаляете 5 Гб и не выполняете никаких операций в течение остального цикла биллинга, цена подсчитывается так:

((20 +10 + 5 – 5)/30) * 0.15 = $0.15

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

Как уже упоминалось, архитектура — важный фактор, вляющий на ежемесячную стоимость эксплуатации приложения. Например, если приложение генерирует большие объемы данных и лишь самые свежие данные (скажем, за последние две недели) нуждаются в обработке, то архитектуру можно спроектировать так, чтобы ненужные данные удалялись или периодически переносились в системы на самом предприятии. (Возможно, лучше один раз оплатить использование полосы пропускани, чем нести последующие расходы на хранение.) То же самое относится к справочным данным, которые больше не являются частью активного набора данных. Данный вариант отлично подходит для компаний, Которые уже вложили средства в решения по архивации данных.

Пример с конкретным приложением

Я рассмотрю различные аспекты платформы Windows Azure в контексте приложения для электронной коммерции промышленного масштаба — Shopping List. Мы создадим список продовольственных товаров и сохраним его на последующего применения при покупках в магазине. Web UI формирует список предлагаемых товаров и спомощью веб-сервисов сохраняет его в Windows Azure Storage. Для масштабируемости веб-уровень записывает списки товаров в Windows Azure Queues, откуда процесс пакетной обработки периодически извлекает списки и сохраняет их в Windows Azure Tables. Для демонстрации аспектов реального приложения я воспользуюсь аутентификацией средствами Windows Azure и защитой на основе ролей (рис. 5).

Рис. 5. Приложение Shopping List на платформе Windows Azure

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

1. скорость накопления справочных данных;
2. скорость накопления транзакционных данных;
3. частота захвата данных профилирования;
4. скорость накопления данных бизнес-событий;
5. частота захвата данных системных событий;
6. медийный контент, относящийся к товарам;
7. использование очередей или прямая интеграция с постоянным хранилищем.

Мой пример с Shopping List не включал много медийного контента, так что он не был значимым фактором в оценке расходов, но мог бы оказаться очень важным для сайтов, предлагающих разнообразный медийный контент от видео до аудиопотоков. На рис. 6 показаны ежемесячные расходы на эксплуатацию типичного приложения на платформе Windows Azure. В калькуляцию не включены затраты на персонал, занятый разработкой, эксплуатацией и поддержкой конечных пользователей.

Рис. 6. Калькулятор эксплуатационных затрат в Windows Azure для приложения электронной коммерции

Среда вычислений в облаке уменьшит численность персонала, отвечающего за поддержку эксплуатации, так что это нужно учесть при сравнении окупаемости инвестиций в приложение, размещенное на предприятии и в облаке. Кроме того, важно включить в подсчет окупаемости инвестиций капитальные затраты на электропитание и амортизацию в расчете на приложение. Нынешние модели расходов на локальные корпоративные приложения зачастую не учитывают эти затраты, так как очень трудно определить энергопотребление индивидуально для каждого приложения. То же самое относится к расходам на охлаждение и занимаемые площади. При подсчете окупаемости инвестиций приходится пользователься обоснованными предположениями из-за отсутствия объективной разбивки по стоимости.

Простой калькулятор затрат, представленный на рис. 6, дает оценку расходов на эксплуатацию приложения, размещаемого на платформе Windows Azure. Этот инструмент на основе Microsoft Excel позволяет указывать различные вводные параметры для типичного приложения электронной коммерции и вычислять ежемесячные эксплуатационные расходы на основе таблицы тарифов в Windows Azure, показанной в табл. 1.. Помните, что параметры по умолчанию, используемые этим инструментом, фиктивны; вам нужно будет учесть особенности своей системы, прежде чем принимать решения на основе выходных данных этого инструмента. Калькулятор затрат управляется таким показателем, как количество посетителей в месяц, и предполагает определенное число просмотров страниц, объем транзакционных данных и информации о события. Группа разработки платформы Windows Azure создала более полный инструмент для расчета ежемесячных затрат на приложение, который вдобавок позволяет сравнивать показатель TCO (совокупной стоимости владения) приложений на предприятиях с приложениями, размещенными в Windows Azure. К этому инструменту вы можете обратиться по ссылке microsoft.com/windowsazure/tco.

Как видно на рис. 6, наше фиктивное приложение генерирует 9000 Гб данных в месяц, что обойдется примерно в $1350 ежемесячно, если бы мы хранили эти данные в Windows Azure Tables. Пожалуйста, не забывайте, что на рис. 6 учтено только хранение за определенный промежуток времени, а стоимость данных событий может аккумулироваться по мере того, как приложение продолжает работать. Такие расходы можно оптимизировать настройкой объемов данных захватываемых событий по мере стабилизации эксплуатации приложения. Как я уже говорил, калькулятор цены управляется количеством посетителей в месяц и использует гипотетическое число веб-ролей (10) и рабочих ролей (3). Полный счет за месяц получается равным $3571.

В качестве альтернативы архитектуру приложения можно спроектировать так, чтобы отправлять данные событий, оплачивая лишь разовые затраты на использование полосы пропускания ($0,10/Гб исходящих данных), в систему хранения на предприятии, если таковая имеется. Аналогичные стратегии применимы к транзакционных и профилирующим данным, которые позволяют избегать оплаты за накопительное хранение.

Затраты на вычислительные ресурсы, не являющиеся накопительными по своей природе, оказывают гораздо меньшее влияние на общие расходы, связанные с эксплуатацией приложения. Однако есть возможность настраивать число активных экземпляров веб-ролей и ролей пакетной обработки в зависимости от интенсивности использования приложения; это позволяет добиться небольшого уменьшения операционных затрат. Если расходами на вычислительные ресурсы можно управлять в любой момент, то расходы на хранение зависят от принятых вами архитектурных решений, которые не так-то просто изменить после создания приложения. Так что мое предложение — заранее принимайте правильные решения по архитектуре хранения.

Помимо модели расходов на приложение, крупные предприятия должны уделять пристальное внимание безопасности приложения, о чем я и расскажу в следующих разделах.

Защита вычислений

Предприятия придирчиво требовательны к безопасности приложений и данных в облаке. Если за безопасность информационного центра, инфраструктуры и операционной системы отвечает Microsoft, то безопасность приложения по-прежнему является прерогативой его владельцев. Я рассмотрю защиту приложения на примере своего веб-приложения Shopping List. Защита приложения на платформе Windows Azure обеспечивается аналогично тому, как это делается на предприятиях. Платформа Windows Azure предоставляет различные системные компоненты, помогающие разработчикам интегрировать средства защиты в приложения. Эти системные компоненты обеспечивают аутентификацию и авторизацию в сценариях с федеративной защитой для крупных предприятий.

Базовая идентификация

Модель базовой идентификации (basic identity model), как и предполагает ее название, реализует самодостаточную архитектуру идентификации, отвечающую потребностям одного приложения или совместно размещенной группы приложений, с которыми работает одно и то же множество пользователей и которые тесно связаны с одной системой идентификации на уровне реализации. Примеры для платформы Windows Azure содержат набор провайдеров ASP.NET (управление членством в группах, роли, профили и сеансы), с помощью которых можно реализовать решение базовой идентификации. ASP.NET-провайдеры Windows Azure реализуются в Windows Azure Storage, которое включает Windows Azure Tables and Blobs. Эти провайдеры реализуют контракты и используют StorageClient API, являющийся частью Windows Azure SDK. Схема провайдеров представлена на рис. 7.

Рис. 7. ASP.NET-провайдеры Windows Azure

Чтобы приложения использовали ASP.NET-провайдеры Windows Azure, файл web.config нужно модифицировать: удалить из него провайдеры по умолчанию и добавить новые. Изменения в конфигурации показаны на рис. 8; они аналогичны изменениям, которые нужно вносить в конфигурацию для использования собственных ASP.NET-провайдеров для приложений, размещенных на предприятии.

Рис. 8. Изменения в web.config для ASP.NET-провайдеров Windows Azure

<system.web>
  ... ... ... ...
<authentication mode="Forms" />
<!-- Membership Provider Configuration -->
<membership defaultProvider="TableStorageMembershipProvider"
userIsOnlineTimeWindow="20">
<providers>
<clear/>
<add name="TableStorageMembershipProvider"
type="Microsoft...AspProviders.TableStorageMembershipProvider"
description="Membership provider using Azure storage"
applicationName="ShoppingList"
... ... ... ... ...
minRequiredNonalphanumericCharacters="0"
requiresUniqueEmail="true"
passwordFormat="Hashed"/>
</providers>
</membership>
<sessionState mode="Custom"
customProvider="TableStorageSessionStateProvider">
<providers>
<clear />
<add name="TableStorageSessionStateProvider"
type="Microsoft...AspProviders.TableStorageSessionStateProvider"
applicationName="ShoppingList"/>
</providers>
</sessionState>
<roleManager enabled="true"
defaultProvider="TableStorageRoleProvider"
cacheRolesInCookie="true"
cookieName=".ASPXROLES"
cookieTimeout="30"
... ... ... ... ...
cookieProtection="All">
<providers>
<clear/>
<add name="TableStorageRoleProvider"
type="Microsoft....AspProviders.TableStorageRoleProvider"
description="Role provider using table storage"
applicationName="ShoppingList" />
</providers>
</roleManager>
... ... ... ...
</system.web>

Как только ASP.NET-провайдеры сконфигурированы, можно реализовать аутентификацию, авторизацию и профили пользователей по аналогии с традиционными ASP.NET-приложениями. Заметьте, что конфигурация на рис. 8 содержит провайдер сеанса на основе хранилища Windows Azure, что позволяет сохранять состояния сеанса в надежной среде. Так как балансировщики нагрузки в Windows Azure не поддерживают закрепленные (за определенным сервером) сеансы (sticky sessions), хранение сеансовых данных в Windows Azure Storage обеспечивает более высокий уровень удобства в использовании за счет персонализации на основе сеансов. Модель базовой идентификации подходит для приложений, в которых жизненный цикл пользовательской идентификации (от создания учетной записи до ее закрытия) начинается и заканчивается в одном и том же приложении. Реализация базовой идентификации может быть выбрана по самым разнообразным причинам, включая следующие:

• приложение должно сохранять полный и единоличный контроль над записями пользовательских идентификаций;
• отсутствие инфраструктуры для реализации хранилища федеративных идентификаций и вспомогательных сервисов;
• приложения с очень коротким жизненным циклом, требующие регистрации пользователя.

ASP.NET-провайдеры Windows Azure также можно использовать для аутентификации из приложений AJAX и Silverlight. Классы AuthenticationService, ProfileService и RoleService, которые можно вызывать из AJAX и которые находятся в System.Web.Extensions.dll, допускается публиковать как конечные точки .svc через веб-роль Windows Azure. Учтите, что эти сервисы требуют совместимости с ASP.NET для доступа к контекстно-зависимым данным HTTP. Детальное описание настройки этих сервисов для их вызова из Silverlight или AJAX см. в статье «Build Line-Of-Business Enterprise Apps with Silverlight, Part 2» (msdn.microsoft.com/magazine/dd434653).

Модель федеративной идентификации

Федеративная идентификация нужна приложениям, взаимодействующим с сетями поставщиков и производителями добавочной стоимости, программам для коллективной работы, приложениям социальных сетей, а также приложениям, которые интегрируют популярные в Интернете хранилища идентификаций. Стек ASP.NET в Windows Azure можно комбинировать с Windows Identity Foundation (WIF) для интеграции с одним или более провайдерами сервисов маркеров защиты. WIF работает при наличии предварительно установленных доверительных отношений, поддерживаемых WS-Trust и WS-Federation. На рис. 9 показана концептуальная схема приложения Shopping List, работающего с двумя провайдерами маркеров, один из которых размещен локально, на предприятии, а другой находится у партнера.

Рис. 9. В приложениях Windows Azure можно регистрировать несколько сервисов маркеров

В дескрипторе доверия указываются конечные точки Secure Token Service (STS) и необходимые сертификаты X509 для подписания запросов маркеров и ответов. На рис. 10 приведена схема дескриптора доверия, XML-представление которого будет включено в конфигурацию приложения Shopping List при развертывании. Пользователи аутентифицируются в своих системах, и получаемый SAML-маркер (Security Assertion Markup Language) передается запросившему приложению.

Рис. 10. Дескриптор федеративного доверия

Как видно из рис. 10, когда пользователь обращается к защищенному веб-контенту в приложении Shopping List, размещенном на платформе Windows Azure, WIF пересылает запрос на указанный в конфигурации доверия URL сервиса STS приложения Shopping List. Shopping List STS принимает удостоверения, аутентифицирует пользователей с помощью Active Directory, конструирует SAML-маркер, применяя Active Directory Federation Services (ADFS) (ранее называлась «Geneva Server»), и пересылает его в приложение Shopping List через веб-браузер. WIF, работающий на сайте Shopping List в Windows Azure, извлекает SAML-заявки и выполняет проверки, связанные с авторизацией.

При участии нескольких STS веб-сайт должен реализовать логику преобразования разнообразных маркеров в канонический формат. Чтобы минимизировать влияние от введения в систему нового STS, логика преобразования маркеров может быть инкапсулирована в компонент, который можно модифицировать, не нарушая работу приложений. Преобразование маркеров с применением WIF схематично отражено на рис. 11.

Рис. 11. Система федеративной идентификации с несколькими провайдерами маркеров

Модель федеративной защиты будет поддерживать следующие сценарии:

• хранение идентификационных записей на предприятии для соответствия нормативно-правовым документам;
• использование существуюшей на предприятии инфраструктуры защиты приложения;
• интеграцию с партнерами в сетях поставщиков и производителей добавочной стоимости;
• единый вход в приложение на предприятии и на платформе Windows Azure.

Зачастую на крупных предприятиях уже реализованы сервисы аутентификации и серверы каталога, необходимые для защиты приложений. Платформа Windows Azure позволяет развертывать приложение в облаке и в то же время задействовать преимущества существующей инфраструктуры безопасности. Кроме того, платформа Windows Azure по своей архитектуре поддерживает использование федеративных идентификаций, что открывает возможность различных вариантов интеграции между партнерами по бизнесу и сетями производителей добавочной стоимости.

Windows Azure Storage

Приложения и сервисы, развернутые на платформе Windows Azure, могут использовать Windows Azure Storage для постоянного хранения неструктурированного и частично структурированного контента. Windows Azure Storage обеспечивает три фундаментальные возможности, необходимые для создания приложений и сервисов промышленного класса: Tables (таблицы), Blobs (большие объекты данных) и Queues (очереди). Windows Azure Storage — масштабируемый и высоконадежный механизм хранения, который доступен и приложениям, размещенным на предприятиях, через стандартный интерфейс веб-сервисов вроде REST. Для защиты сетевых коммуникаций Windows Azure Storage поддерживает SSL (HTTPS) в дополнение к стандартному протоколу HTTP. Масштабируемость и другие важнейшие характеристики достигаются за счет размещения хранилища на большой ферме серверов и использования дисковых массивов, управляемых программным обеспечением Windows Azure Storage. Обращения к харанилищу автоматически распределяются по набору узлов — это повышает масштабируемость и доступность. Каждый узел отвечает за конечный объем физического хранилища. Доступ к хранилищу вне области действия узла осуществляется через одноранговый интерфейс (peer-to-peer interface). Надежность достигается за счет избыточного хранения сущностей (например, ShoppingList) на множестве узлов. Программное обеспечение хранилища автоматически создает несколько копий (реплик) данных (три — на момент написания этой статьи), как только выполняется операция записи. Хранилище поддерживает атомарные транзакционные операции записи, и транзакция фиксируется только после успешной записи на диски всех копий. На рис. 12 показан набор узлов хранилища, образующих сервис хранения — Windows Azure Storage Service.

Рис. 12. Сервис хранения

В процессе использования любой диск хранилища может выйти из строя, и возможность этого обозначена крестиком на узлах 4 и 11. Как только сервис хранения обнаруживает сбойный диск, он реплицирует данные с другого функционирующего диска в новый узел. Сервис хранения всегда работает в соответствии с политиками репликации. Как уже упоминалось, трафик запросов от приложений будет распределяться между несколькими узлами.

Архитектура такого рода способствует массовому масштабированию, которое требуется PaaS-предложениям общедоступного облака вроде платформы Windows Azure. Как показано на рис. 12, мы предполагаем, что узлы 4, 11 и 14 владеют тремя начальными копиями (репликами) данных. В случае отказа узлов 4 и 11 узел 14 продолжит обслуживать запросы, а также быстро реплицирует данные по меньшей мере на два дополнительных узла (2 и 8).

Защита хранилища

Windows Azure Storage аутентифицирует веб-запросы REST с применением HMAC (Hash-based Message Authentication Code). При вычислении 256-байтового хеша общий секретный ключ, сопоставленный с проектом Windows Azure Storage, объединяется с HTTP-запросом, и этот хеш встраивается в заголовок «авторизации» веб-запроса. Тот же процесс повторяется на сервере для проверки аутентичности запроса. Windows Azure Table, Queue and Blobs следуют одинаковому процессу аутентификации, но полезные данные и целевые URL различаются для каждого типа хранилища. Ниже перечислены URL для доступа к трем хранилищам (таблицам, очередям и большим объектам данных) по проекту, скажем, «hkshoppinglist»:

• http(s)://hkshoppinglist.blob.core.windows.net/
• http(s)://hkshoppinglist.queue.core.windows.net/
• http(s)://hkshoppinglist.table.core.windows.net/

Пример кода на рис. 13 демонстрирует создание нескольких таблиц Windows Azure в процессе подготовки хранилища к развертыванию приложения.

Рис. 13. Псевдокод, показывающий, как создать таблицы Windows Azure

[DataServiceKey("TableName")]
Public class StorageTable
{
  Private string _tableName;
  Public string TableName
{
  get { return this._tableName; }
  set { this._tableName = value; }
}
}

Public class Customer: TableServiceEntity
{
  Public string Name { get; set; }
  Public string CustomerID { get; set; }
  public Customer()
{
  PartitionKey = "enterprise";
  RowKey = string.Format("{0:10}_{1}", DateTime.MaxValue.Ticks –
  DateTime.Now.Ticks, Guid.NewGuid());
}
}
CloudStorageAccount _storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

Public void CreateMultipleCustomers(List<Customer> customers)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri,
  _storageAccount.Credentials);
  foreach (Customer cust in customers)
{
  tsc.AddObject("customers", cust);
}
try
{
  DataServiceResponse resp =  tsc.SaveChanges(SaveChangesOptions.Batch);
  foreach (ChangeOperationResponse cor in resp)
{
  if (cor.Error != null)
{
//cor.Headers["Location"] can be parsed to find out the failed
//requests which can be retried after correcting the error condition
}
}
}
catch (Exception ex){ //do something with the exception }
}

protectedvoid linkCreateTables_Click(object sender, EventArgs e)
{
  labelStatus.Text = string.Empty;
try
{
  CreateTable("customers");
  CreateTable("products");
}
catch (DataServiceRequestException ex)
{
  labelStatus.ForeColor = System.Drawing.Color.Red;
  labelStatus.Text = "Error: Table creation error : " + ex.Message;
}
}
//Use ADO.NET services directly to create an Windows Azure Table
Public void CreateTableUsingContext(AzureStorageTable storageTable)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri,
  _storageAccount.Credentials); tsc.AddObject("Tables", storageTable);
try
{
  DataServiceResponse resp = tsc.SaveChanges(SaveChangesOptions.None);
//handle errors
}
catch (Exception ex){//do something here}
}
//much simpler way of creating an Windows Azure Table
  publicvoid CreateTable(string tableName)
{
CloudTableClient ctc = _storageAccount.CreateCloudTableClient();
try
{
  ctc.CreateTable(tableName);
}
catch(Exception e) { //handle exception }
}

Используя Windows Azure Tables как пример, я покажу некоторые простые способы подготовки Windows Azure Storage для транзакционного заполнения данными. В примерах кода создаются таблицы «customers» и «products» с помощью TableServiceContext, а также CloudTableClient для иллюстрации гибкости взаимодействия на основе REST. По сути, вы также можете создавать неструктурированные полезные данные (raw payload), подключать HMAC к веб-запросу и посылать HTTP-запрос POST на URL таблицы, но это требует большого объема кода и годится лишь в качестве академического упражнения. Рекомендуемый подход — использование StorageClient, который является частью Windows Azure SDK.

Функция CreateTableUsingContext с помощью класса AzureStorageTable создает таблицу и генерирует данные для ее заполнения через ADO.NET Data Services. TableServiceContext автоматически генерирует HMAC и присоединяет его к запросу, используя ключ, который содержится в свойстве CloudStorageAccount.Credentials.

Хранилище Windows Azure Tables поддерживает пакетные транзакции, как показано в функции CreateMultipleCustomers на рис. 13. В пакете не должно быть более 100 операций для данного набора изменений, и размер одного пакета не должен превышать 4 Мб. За более подробными сведениями обращайтесь к документации Windows Azure Storage. Пакетные транзакции допустимы только для сущностей, принадлежащих к одному разделу.

Удостоверения, необходимые для генерации HMAC, указываются в конфигурации сервиса соответствующей роли Windows Azure. Ниже показан формат строки подключения к локальному хранилищу и к хранилищу в облаке:

Локальное хранилище

<Setting name="DataConnectionString"
value="UseDevelopmentStorage=true"/>

Хранилище в облаке

<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=
http;AccountName=
<your account>;AccountKey=<your account key"/>

Понятия ролевой защиты в Windows Azure Storage нет; поэтому аутентифицированный запрос получит полный доступ к хранилищу в контексте проекта хранилища. Исключением является контейнер больших объектов данных (blob container), который может быть общедоступным (анонимным) или закрытым. Авторизация возлагается на приложение, которое использует сервисы хранилища.

Заключение

В этой статье я лишь поверхностно обрисовал платформу Windows Azure. Уверен, что в будущем появится масса публикаций о Microsoft SQL Azure, AppFabric, различных серверных ролях и вариантах защиты, которые здесь не рассматривались. Windows Azure — платформа вычислений в облаке, архитектура которой обеспечивает использование вычислительных ресурсов как коммунальной услуги для разработки и хостинга приложений и сервисов.

Специальное, почти полностью автоматизированное ПО обеспечивает высокую надежность больших пулов оборудования промышленного класса. Низкие тарифы дают клиентам экономические преимущества. Оплата с подписчиков взимается на основе использования пропускной способности, хранилища и вычислительных ресурсов в соответствии с месячным циклом биллинга. Платформа Windows Azure предоставляет компоненты, необходимые для создания корпоративных приложений и сервисов, и при этом не требует больших заблаговременных вложений капиталов или долгосрочных контрактов.