Рисунок 1. Платформа Windows Azure состоит из служб приложения, выполняющихся в центрах обработки данных Microsoft и доступных через Интернет
Перевод обзорной статьи статьи Дэвида Чэппелла (David Chappell).
Ссылка на оригинал: Introducing Windows Azure
Windows Azure — это платформа приложений фирмы Microsoft для публичного облака. Существует множество способов использования этой платформы. Например, вы можете использовать Windows Azure для создания веб-приложения, которое исполняется и хранит свои данные в центрах обработки данных Microsoft. Также вы можете применять Windows Azure только для хранения данных, которые будут использованы приложениями, установленными и исполняющимися локально (то есть вне публичного облака). Ещё платформу Windows Azure можно использовать для создания виртуальных машин для разработки и тестирования, или же для запуска на этих машинах SharePoint и других приложений. Кроме того, вы можете использовать Windows Azure для создания широко масштабируемых приложений, поддерживающих множества пользователей. Всё вышеперечисленное (и даже больше) становится возможным благодаря широкому кругу сервисов, предлагаемых платформой.
Однако чтобы воспользоваться чем-либо из этого, необходимо понимать основы. И даже если вы ничего не знаете об облачных вычислениях, эта статья познакомит вас с основополагающими принципами Windows Azure. Её цель — дать вам основание для понимания и использования этой облачной платформы.
Для того чтобы лучше представить, что предлагает платформа Windows Azure, полезно сгруппировать её сервисы в отдельные категории. На рисунке 1 представлен один из вариантов такой группировки.
Рисунок 1. Платформа Windows Azure состоит из служб приложения, выполняющихся в центрах обработки данных Microsoft и доступных через Интернет
Чтобы начать работать с платформой Windows Azure, вам необходимо изучить, по крайней мере, азы каждого из её компонентов. Оставшаяся часть статьи даёт разъяснения по поводу технологий, отображённых на рисунке, описывая, что каждая из них предлагает, и в каких случаях вы можете её использовать.
Одной из самых базовых функций облачной платформы является выполнение приложений. Как показано на рисунке 2, платформа Windows Azure предусматривает для этого три варианта.
VMs — виртуальные машины; VHDs — виртуальные жёсткие диски
Рисунок 2. Windows Azure реализует следующие модели: Инфраструктура как услуга (IaaS), Веб хостинг и Платформа как услуга (PaaS)
Каждый из этих трёх подходов (Виртуальные машины, Веб сайты и Облачные службы) может использоваться по отдельности. Также вы можете комбинировать их, создавая приложение, совместно использующее две и более модели выполнения.
Возможность создавать виртуальные машины по требованию (из стандартного образа или из образа, предоставленного вами) может быть очень полезной. Добавьте к этому возможность почасовой оплаты этих виртуальных машин, и польза станет ещё более ощутимой. Этот подход известен под названием «Инфраструктура как услуга» (IaaS) и это то, что предлагает компонент «Виртуальные машины» платформы Windows Azure.
Чтобы создать виртуальную машину, требуется указать какой образ виртуального жёсткого диска (VHD) использовать, а также размер виртуальной машины. Затем вы оплачиваете каждый час работы виртуальной машины. Как видно из рисунка 2, компонент «Виртуальные машины» платформы Windows Azure включает в себя галерею стандартных образов виртуальных жёстких дисков. В их число входят как варианты, предоставленные Microsoft (такие как Windows Server 2008 R2, Windows Server 2012 и Windows Server 2008 R2 с установленным SQL Server), так и образы на базе Linux, предоставленные партнёрами Microsoft. Вы также можете загружать свои собственные образы виртуальных жёстких дисков и создавать виртуальные машины на их основе.
Независимо от того, какой образ — стандартный или пользовательский — был выбран, вы имеете возможность постоянно хранить в нём любые изменения, сделанные во время работы виртуальной машины. Когда вы в следующий раз создадите виртуальную машину на основе этого образа жёсткого диска, все объекты будут такими, каким вы их оставили в предыдущем сеансе. Также имеется возможность выгрузить копию изменённого жёсткого диска из Windows Azure и затем использовать его локально.
Виртуальные машины Windows Azure могут быть использованы множеством разных способов. Вы можете с их помощью создать недорогую платформу для тестирования и разработки, которую можно демонтировать после завершения работы с ней. На этой платформе можно создавать и запускать приложения, использующие любые нравящиеся вам языки программирования и программные библиотеки. Эти приложения могут использовать любые предоставляемые платформой Windows Azure варианты управления данными. Также вы можете выбрать вариант использования сервера баз данных SQL Server или другой СУБД, выполняющихся в одной или более виртуальных машинах. Ещё один вариант применения виртуальных машин Windows Azure — это использование их как расширения вашего локального центра обработки данных для выполнения в них SharePoint или других приложений. Для реализации этого решения существует возможность создавать домены Windows в облаке, запуская службу каталога Active Directory на виртуальных машинах Windows Azure. Этот достаточно общий подход к облачным вычислениям может быть использован для решения различных проблем. Что именно сделаете вы, зависит только от вас.
Один из наиболее распространённых способов использования облачных платформ — это запуск в нём вебсайтов и веб-приложений. Компонент «Виртуальные машины» Windows Azure позволяет делать это, возлагая, однако, на вас все тяготы администрирования виртуальной машины (или даже нескольких). А что если вам просто нужен вебсайт, уже администрируемый кем-то другим?
Это именно то, что предоставляет вам компонент «Веб сайты» платформы Windows Azure. В рамках этой модели выполнения вы получаете управляемую веб среду на основе служб Internet Information Services (IIS). Вы можете перенести существующий вебсайт (работающий под управлением IIS) на платформу Windows Azure в неизменном виде, или же вы можете создать новый сайт прямо в облаке. После запуска вебсайта вы можете динамически добавлять или удалять его экземпляры, а компонент «Веб сайты» обеспечит между ними балансировку нагрузки, распределяя запросы. И, как видно из рисунка 2, «Веб сайты» платформы Windows Azure работают как в режиме разделения ресурсов (когда ваш вебсайт выполняется совместно с другими сайтами в рамках одной виртуальной машины), так и в режиме выделения отдельной виртуальной машины для сайта.
Компонент «Веб сайты» Windows Azure должен быть полезным, как веб-разработчикам, так и веб-дизайнерам. Для ведения разработки он поддерживает .NET, PHP и Node.js совместно с SQL Database и MySQL (от компании ClearDB, партнёра Microsoft) для хранения реляционных данных. Он также содержит встроенную поддержку нескольких популярных приложений, включая WordPress, Joomla и Drupal. Цель состоит в том, чтобы предложить недорогую, масштабируемую и широко используемую платформу для создания веб-сайтов и веб-приложений в публичном облаке.
Предположим, вы хотите создать облачное приложение, которое может поддерживать множество одновременных пользователей, не требует значительного администрирования, и работа которого никогда не прекращается. Такое желание может возникнуть, например, у традиционного производителя программного обеспечения, который решил задействовать бизнес-модель «Программное обеспечение как услуга» (SaaS), выпустив облачную версию одного из своих приложений. Или у стартапа, создающего потребительское приложение, которое, как ожидается будет быстро расти. Если вы собираетесь создавать это приложение на платформе Windows Azure, то какую модель выполнения следует выбрать?Предположим, вы хотите создать облачное приложение, которое может поддерживать множество одновременных пользователей, не требует значительного администрирования, и работа которого никогда не прекращается. Такое желание может возникнуть, например, у традиционного производителя программного обеспечения, который решил задействовать бизнес-модель «Программное обеспечение как услуга» (SaaS), выпустив облачную версию одного из своих приложений. Или у стартапа, создающего потребительское приложение, которое, как ожидается будет быстро расти. Если вы собираетесь создавать это приложение на платформе Windows Azure, то какую модель выполнения следует выбрать?
Компонент «Веб сайты» платформы Windows Azure Web Sites позволяет создавать веб-приложения такого типа, но с рядом ограничений. Например, у вас не будет административного доступа, что означает невозможность установки произвольного программного обеспечения. Компонент «Виртуальные машины» платформы Windows Azure предоставляет значительно большую гибкость, включая административный доступ, и вы, конечно можете использовать его для создания весьма масштабируемых приложений, но вам придётся самостоятельно решать множество вопросов администрирования и обеспечения надёжности. Предпочтительнее всё же был бы вариант, предоставляющий необходимый уровень управления системой, но самостоятельно выполняющий большую часть работы по администрированию, необходимой для обеспечения надёжности.
Как раз именно это и предлагает компонент «Облачные службы» платформы Windows Azure. Эта технология разработана специально для поддержки масштабируемых, надёжных и требующих минимальных административных усилий приложений. И это пример того, что обычно называют «Платформа как услуга» (PaaS). Чтобы воспользоваться этим, вы создаёте приложение на основе избранной вами технологии, такой как C#, Java, PHP, Python, Node.js или какой-то другой. Затем ваш код выполняется в виртуальных машинах (называемых экземплярами) под управлением версии операционной системы Windows Server.
Но эти виртуальные машины следует отличать от тех, которые создаются в компоненте «Виртуальные машины» платформы Windows Azure. Начнём с того, что платформа Windows Azure сама управляет ими, выполняя такие операции как установка обновлений операционной системы и автоматическое развёртывание исправленных образов. (Кстати, это означает, что ваше приложение не должно сохранять своё состояние в сети или в экземпляре рабочей роли: вместо этого состояние должно храниться с использованием одного из вариантов управления данными платформы Windows Azure, которые будут описаны в следующем разделе). Платформа Windows Azure также следит за состоянием этих виртуальных машин, при необходимости перезагружая те, в работе которых возникают сбои.
Как показано на рисунке 2, когда вы создаёте экземпляр, вы можете выбрать одну из двух ролей, каждая из которых базируется на операционной системе Windows Server. Основное различие между ними состоит в том, что в экземпляре веб-роли запускаются службы IIS, в то время как в экземпляре рабочей роли этого не происходит. Тем не менее, обе роли управляются одинаково, и использование приложением сразу обеих является общей практикой. Например, экземпляр веб-роли может принимать запросы от пользователей и затем передавать их экземпляру рабочей роли для обработки. Для масштабирования (в обе стороны) вашего приложения вы можете давать платформе Windows Azure указания создать дополнительные экземпляры любой роли или завершить работу имеющихся. И, как и в случае с компонентом «Виртуальные машины», вам выставляются счета за каждый час работы каждого экземпляра каждой роли.
Каждой из трёх моделей выполнения платформы Windows Azure отведена особая роль. Виртуальные машины платформы Windows Azure обеспечивают вычислительную среду общего назначения. Веб сайты платформы Windows Azure предлагают недорогой веб-хостинг. А Облачные службы платформы Windows Azure — это наилучший выбор для создания масштабируемых надёжных приложений с низкими затратами на администрирование. И, как упоминалось ранее, вы можете использовать эти технологии по отдельности или при необходимости сочетать их для создания хорошей основы для вашего приложения. Подход, который вы выберете, зависит от того, какие проблемы вы пытаетесь решить.
Приложениям нужны данные. Причём разным типам приложений нужны разные типы данных. Поэтому платформа Windows Azure предоставляет несколько различных способов для хранения и управления данными.
Один из них уже был упомянут: возможность запускать сервер баз данных SQL Server или другую СУБД в виртуальной машине, созданной в рамках компонента «Виртуальные машины» платформы Windows Azure. (Важно понимать, что этот вариант не ограничивает вас реляционными системами: вы также можете свободно использовать NoSQL-технологии, такие как MongoDB и Cassandra.) Развёртывание собственной системы управления базами данных — это простой и понятный путь, это повторение того, к чему мы привыкли в своих собственных центрах обработки данных, но этот способ также подразумевает занятие администрированием этой СУБД. Чтобы облегчить жизнь, платформа Windows Azure предлагает три варианта управления данными, в значительной степени беря это управление на себя. Эти варианты представлены на рисунке 3.
Рисунок 3. Для управления данными платформа Windows Azure предлагает реляционное хранилище, масштабируемые NoSQL-таблицы и неструктурированное хранилище двоичных данных
Каждый из этих трёх вариантов направлен на различные нужды: хранение реляционных данных, быстрый доступ к потенциально большим объёмам данных простых типов и хранение неструктурированных двоичных данных. Во всех трёх случаях данные автоматически реплицируются на три различных компьютера в центре обработки данных Windows Azure для обеспечения высокой доступности. Также стоит отметить, что во всех трёх вариантах данные могут быть доступны как из приложений платформы Windows Azure, так и из приложений, выполняющихся где-либо ещё, например, в вашем локальном центре обработки данных, на вашем ноутбуке или на вашем телефоне. Независимо от способов применения данных, оплата за все услуги управления ими, предоставляемые платформой Windows Azure, основывается на реальном использовании, включая месячную ставку за хранение гигабайта информации.
Для хранения реляционных данных, платформа Windows Azure содержит компонент «База данных SQL». Ранее называвшаяся «SQL Azure», База данных SQL предлагает все ключевые функции реляционной системы управления базами данных, включая атомарные транзакции, параллельный доступ к данным нескольких пользователей с обеспечением целостности данных, запросы к данным на языке ANSI SQL и знакомую модель программирования. Как и в случае с SQL Server, доступ к Базе данных SQL может быть осуществлён при помощи Entity Framework, ADO.NET, JDBC и других знакомых технологий доступа к данным. Также поддерживается большая часть языка T-SQL, а также инструменты SQL Server, такие как среда SQL Server Management Studio. Для любого человека, знакомого с SQL Server (или другой реляционной базой данных), использование Базы данных SQL является простым и понятным.
Но База данных SQL это не просто СУБД в облаке, это — сервис модели «Платформа как услуга». Вы по-прежнему управляете вашими данными и определяете круг тех, кто может получить к ним доступ, но База данных SQL берёт на себя всю тяжёлую административную работу, такую как управление аппаратной инфраструктурой и автоматическое поддержание программного обеспечения операционной системы и сервера баз данных в актуальном состоянии. База данных SQL также предоставляет услугу федерации данных, то есть может распределять данные между несколькими серверами. Это полезно для приложений, которые работают с большими объёмами данных или которым для улучшения производительности требуется распределить запросы к данным между несколькими серверами.
Если вы создаёте приложение для платформы Windows Azure (используя любую из трёх моделей выполнения), которому требуется хранилище реляционных данных, то База данных SQL может оказать подходящим вариантом. Впрочем, и приложения, выполняющиеся вне облака, также могут воспользоваться этим сервисом, так что в этом случае существует ещё масса вариантов. Например, доступ к данным, хранящимся в Базе данных SQL, может быть осуществлён из различных клиентских систем, включая настольные компьютеры, ноутбуки, планшеты и телефоны. И, поскольку при помощи встроенной репликации обеспечивается высокая доступность данных, использование Базы данных SQL может свести время простоя к минимуму.
Предположим, вы хотите создать приложение для платформы Windows Azure, которому требуется быстрый доступ к типизированным данным (причём, их может быть много), но которому не требуется осуществлять сложные SQL запросы к этим данным. Например, представьте, что вы создаёте потребительское приложение, которому нужно для каждого пользователя хранить информацию, составляющую его профиль. Ожидается, что приложение будет очень популярным, поэтому вам надо будет работать с большими объёмами данных, но вы не планируете особых операций с ними помимо хранения, кроме разве что несложных выборок. Этот как раз один из тех сценариев, когда применение Таблиц платформы Windows Azure имеет смысл.
Пусть вас не обманывает название «Таблицы»: эта технология не предполагает реляционного хранения данных. (На самом деле это пример подхода NoSQL, называемый «хранилище пар ключ/значение»). Вместо этого, Таблицы платформы Windows Azure позволяют приложению хранить свойства различных типов, таких как строки, целые числа и даты. Приложение может извлекать группу свойств по уникальному ключу этой группы. Хотя сложные операции, такие как объединения таблиц, не поддерживаются, таблицы обеспечивают быстрый доступ к типизированным данным. Кроме того, таблицы очень масштабируемы: в одной единственной таблице может храниться до терабайта данных. И, в соответствии с их простотой, таблицы обычно менее дороги в использовании по сравнению с реляционным хранилищем Базы данных SQL.
Третий вариант управления данными, Большие двоичные объекты (БДО) платформы Windows Azure Blobs, разработан для хранения неструктурированных двоичных данных. Как и Таблицы, Большие двоичные объекты являются недорогим хранилищем, и в одном БДО может храниться до терабайта данных. Приложения, которые хранят, например, видео, или резервные копии носителей информации, или другие двоичные данные могут использовать БДО в качестве простого, дешёвого хранилища. Приложения платформы Windows Azure могут также использовать накопители платформы Windows Azure, с помощью которых БДО играют роль постоянного хранилища для файловой системы Windows, смонтированной в экземпляре Windows Azure. Приложение видит обычные файлы Windows, однако их содержимое на самом деле хранится в Больших двоичных объектах.
В настоящее время платформа Windows Azure выполняется в нескольких распределённых центрах обработки данных, расположенных на территории Соединённых Штатов, Европы и Азии. Когда вы запускаете приложение или сохраняете данные, вы можете выбрать для использования один или несколько этих центров обработки данных. Также вы можете подключиться к этим центрам различными способами:
Вы можете использовать компонент «Виртуальная сеть» платформы Windows Azure для подключения вашей локальной сети к определённому набору Виртуальных машин платформы Windows Azure.
Вы можете использовать компонент «Connect» платформы Windows Azure для того, чтобы соединить один или более локально расположенных серверов Windows с определённым приложением платформы Windows Azure.
Если ваше приложение для платформы Windows Azure выполняется в нескольких центрах обработки данных, вы можете использовать компонент «Диспетчер трафика» платформы Windows Azure для интеллектуальной маршрутизации пользовательских запросов между экземплярами приложения.
Рисунок 4 иллюстрирует эти три варианта.
Рисунок 4. Платформа Windows Azure позволяет создавать облачные виртуальные частные сети, соединять приложение в облаке с локальными машинами, а также интеллектуально распределять запросы пользователей между центрами обработки данных
Полезный подход к использованию публичного облака — это относиться к нему как к расширению вашего собственного центра обработки данных. Поскольку вы можете создавать виртуальные машины по требованию, а затем, когда необходимость в них отпадёт, удалять их, то у вас есть возможность иметь компьютерные мощности только тогда, когда вы этого хотите. И поскольку компонент «Виртуальные машины» платформы Windows Azure позволяет вам создавать виртуальные машины, в которых могут быть запущены SharePoint, Active Directory и другое знакомое программное обеспечение, которое обычно устанавливается на локальных компьютерах, то этот подход может быть использован по отношению к имеющимся приложениям.
Хотя, чтобы этот подход стал по-настоящему полезным, и ваши пользователи должны иметь возможность относиться к этим приложениям так, как если бы они выполнялись в вашем собственном центре обработки данных. Именно это и позволяет сделать компонент «Виртуальная сеть» платформы Windows Azure. При помощи аппаратного VPN-шлюза, администратор может настроить виртуальную частную сеть между вашей локальной сетью и определённой группой виртуальных машин, работающих на платформе Windows Azure. Поскольку вы можете назначить виртуальным машинам в облаке свои собственные IPv4-адреса, то эти виртуальные машины будут казаться находящимися в вашей локальной сети. Пользователи в вашей организации смогут получить доступ к приложениям, содержащимся в этих виртуальных машинах, как если бы они выполнялись локально.
Создание виртуальной частной сети между вашей локальной сетью и группой виртуальных машин в облаке — это полезно, но в то же время требует наличия аппаратного VPN-шлюза и услуг сетевого администратора. Предположим, что вы разработчик, которому надо всего лишь связать единственное приложение на платформе Windows Azure с определённой группой компьютеров под управлением Windows, находящихся внутри вашей организации. Это может потребоваться, если вы создали приложение на основе Облачных служб, которому, к примеру, необходим доступ к базе данных, расположенной на одном из этих локальных серверов, а вы не хотите связываться с проблемой настройки шлюза виртуальной частной сети.
Компонент «Connect» платформы Windows Azure разработан для таких ситуаций. Он обеспечивает простой способ установки безопасного соединения между приложением платформы Windows Azure и группой компьютеров под управлением Windows. Разработчику достаточно установить программные компоненты Connect на локальных машинах (в этом случае нет никакой необходимости привлекать сетевого администратора) и настроить приложение платформы Windows Azure. После этого, приложение может взаимодействовать с локальными компьютерами, как если бы они были в одной локальной сети.
Приложение платформы Windows Azure, пользователи которого находятся лишь в одной части планеты, может выполняться в одном единственном центре обработки данных Windows Azure. А приложение, пользователи которого разбросаны по всему миру, скорее всего, будет выполняться в нескольких центрах обработки данных, может быть даже сразу во всех центрах платформы. Во втором случае вы столкнётесь с проблемой — как интеллектуально сопоставить пользователей с экземплярами приложения? Вероятно, вы предпочтёте, чтобы в течение большей части времени каждый пользователь имел доступ к ближайшему для себя центру обработки данных, что, скорее всего, обеспечит наилучшее время отклика. Но что делать, если эта копия приложения перегружена запросами или недоступна? В этом случае было бы неплохо перенаправить пользовательский запрос в другой центр обработки данных. В этом и заключается функция компонента «Диспетчер трафика» платформы Windows Azure.
Владелец приложения задаёт правила, определяющие алгоритмы, в соответствии с которыми запросы пользователей должны направляться в центры обработки данных, а затем полагается на Диспетчер трафика, который обеспечивает выполнение этих правил. Например, пользователи обычно должны направляться в ближайшие к ним центры обработки данных платформы Windows Azure, но, если время отклика от центра по умолчанию превысит некоторый порог, запрос будет перенаправлен в другой центр обработки данных. Для глобально распределённых приложений с большим числом пользователей весьма полезно иметь встроенную службу, решающую подобные проблемы.
Анализ данных — это основная форма использования бизнесом информационных технологий. Облачная платформа предоставляет набор ресурсов, доступных по требованию и оплачиваемых по мере использования, которые делают её хорошим основанием для подобного рода вычислений. Соответственно, платформа Windows Azure предлагает два варианта для бизнес аналитики. Рисунок 5 иллюстрирует этот выбор.
Рисунок 5. Для бизнес аналитики платформа Windows Azure предлагает службу отчётов и поддержку анализа больших объёмов данных
Анализ данных может принимать множество разных форм, поэтому эти два варианта совершенно разные. Стоит рассмотреть каждый из них по отдельности.
Одним из наиболее распространённых способов использования хранимых данных является создание отчётов на основе этих данных. Чтобы вы могли делать это с данными, хранящимися в компоненте «База данных SQL», платформа Windows Azure содержит компонент «Служба отчётов SQL Reporting». Этот компонент, являющийся подмножеством служб отчётов, поставляемых совместно с SQL Server, позволяет создавать отчёты в приложениях, выполняемых как в облаке Windows Azure, так и локально. Создаваемые вами отчёты могут быть различных форматов, включая HTML, XML, PDF, Excel и другие, и они могут, как встраиваться в приложения, так и просматриваться в веб браузере.
Другой вариант анализа данных, хранящихся в базе данных SQL, — это использование локальных инструментов бизнес аналитики. Для клиента облачная База данных SQL выглядит так же, как и локальный SQL Server, поэтому одинаковые технологии могут работать в обоих случаях. Например, вы можете использовать локальные службы SQL Server Reporting Services для создания отчётов на основе данных, хранящихся в Базе данных SQL.
На протяжении многих лет основная часть анализа данных осуществлялась над реляционными данными, помещёнными в хранилище, построенное на основе реляционной СУБД. Этот вид бизнес аналитики по-прежнему важен и останется таким ещё в течение длительного времени. Но что делать, если размер данных, которые нужно анализировать, настолько велик, что реляционные базы данных просто не могут с ним справиться? А если предположить, что эти данные и не являются реляционными? Это могут быть системные журналы серверов в центре обработки данных, или «исторические» показания разного рода датчиков, или что-нибудь подобное. В случаях, подобных этим, вы сталкиваетесь с тем, что называют «проблема больших данных». И здесь нужен другой подход.
Сегодня доминирующей технологией для анализа больших данных является Hadoop. Это проект с открытым исходным кодом, разрабатываемый фондом Apache Software Foundation. В рамках этой технологии данные сохраняются посредством распределённой файловой системы Hadoop (HDFS), и в дальнейшем разработчики получают возможность анализировать эти данные, создавая задания параллельных распределённых вычислений в соответствии с моделью MapReduce. Файловая система HDFS распределяет данные между множеством серверов и затем на каждом из них выполняются одинаковые элементарные операции, определённые заданием MapReduce, что позволяет обрабатывать данные параллельно.
Как показано на рисунке 5, служба платформы Windows Azure, реализующая технологию Apache Hadoop, позволяет файловой системе HDFS распределять данные между множеством виртуальных машин, а затем доводит логику задания MapReduce до каждой из них. Как и в случае с кластером Hadoop, расположенным вне облака, данные обрабатываются на виртуальных машинах, во-первых, локально (алгоритм их обработки загружается в каждую машину совместно со своим фрагментом данных) и, во-вторых, параллельно, что улучшает производительность. Служба платформы Windows Azure, реализующая технологию Apache Hadoop, поддерживает и другие компоненты этой технологии, включая проекты Hive и Pig. Microsoft также разработала подключаемый модуль Excel для создания Hive-запросов.
Программный код, независимо от того, что он делает, часто должен взаимодействовать с другим кодом. В некоторых случаях для этого достаточно обычной очереди сообщений. В других случаях требуется более сложное взаимодействие. Платформа Windows Azure предлагает несколько разных способов решения такого рода задач. Рисунок 6 иллюстрирует возможные варианты.
Рисунок 6. Для связи приложений платформа Windows Azure предлагает очереди, механизм публикации/подписки и синхронные соединения через облако
Очереди сообщений работают просто: одно приложение помещает сообщение в очередь, и это сообщение будет со временем прочитано другим приложением. Если вашему приложению требуется лишь этот простой механизм, то лучшим выбором для вас может стать компонент «Очереди» платформы Windows Azure.
Дать возможность экземпляру веб-роли общаться с экземпляром рабочей роли в рамках одного приложения Облачных служб — это наиболее распространённый способ применения Очередей в настоящее время. Например, предположим, вы создаёте на платформе Windows Azure приложение для предоставления видео контента в общий доступ. Приложение состоит из кода на PHP, работающего в веб-роли и позволяющего загружать видео на сервер и просматривать его. Также приложение включает в себя рабочую роль, реализованную на C#, которая конвертирует загруженное на сервер видео в различные форматы. Когда экземпляр веб-роли получает от пользователя новый видеоролик, он может сохранить его как Большой двоичный объект, а затем послать сообщение рабочей роли через очередь с информацией о месте хранения этого видео. Экземпляр рабочей роли (причём не важно, какой именно экземпляр) прочтёт сообщение из очереди и в фоновом режиме выполнит требуемые операции по конвертации видео. Структурирование приложения таким образом даёт возможность проводить асинхронную обработку, а также облегчает масштабирование приложения, поскольку количества экземпляров веб-роли и рабочей роли могут меняться независимо друг от друга.
Приложения должны взаимодействовать независимо от того исполняются ли они в облаке, или в вашем центре обработки данных, или на мобильном устройстве, или ещё где-либо. Цель Шины обслуживания Windows Azure заключается в том, чтобы приложения, работающие практически везде, где бы то ни было, могли обмениваться данными.
Как видно из рисунка 6, Шина обслуживания тоже предоставляет услугу очередей. Однако эта услуга не идентична только что описанным Очередям. Например, в отличие от Очередей Windows Azure, Шина сообщений использует механизм «публикация/подписка». Приложение может послать сообщение в «тему», в то время как другие приложения могут зарегистрировать подписки на эту тему. Это позволяет организовывать внутри набора приложений связь в режиме один ко многим так, что одно сообщение будет прочитано многими получателями. Впрочем, очереди — это не единственный вариант: Шина обслуживания также позволяет создание прямых связей через собственный сервис ретрансляции, обеспечивая безопасный путь взаимодействия через брандмауэры.
При помощи Шины обслуживания могут взаимодействовать как приложения платформы Windows Azure, так и программы, работающие на какой-либо иной облачной платформе. Также это могут быть и приложения, работающие вне облака. Для примера представьте себе авиакомпанию, которая разработала сервис регистрации на рейсы, выполняющийся на компьютерах, расположенных в её корпоративном центре обработки данных. Очевидно, есть необходимость сделать этот сервис доступным для многих клиентов, включая киоски регистрации в аэропортах, терминалы операторов на стойках регистрации и, возможно, даже телефоны пассажиров. Для того чтобы сделать это, можно воспользоваться Шиной обслуживания, создавая слабосвязанное взаимодействие между различными приложениями.
Приложения, как правило, обращаются к одним и тем же данным снова и снова. Один из способов повысить производительность — это хранить копию данных поближе к приложению, сводя к минимуму время, необходимое для их получения. Для реализации этого, платформа Windows Azure предлагает два различных сервиса. Это, во-первых, кэширование данных, используемых приложениями Windows Azure, в оперативной памяти, и, во-вторых, сеть доставки контента (CDN), которая кэширует данные из больших двоичных объектов на дисках серверов, расположенных как можно ближе к потребителям этих данных. Рисунок 7 иллюстрирует оба способа.
Рисунок 7. Приложение Windows Azure может кэшировать данные в памяти, а копии больших двоичных объектов могут кэшироваться на сайтах, расположенных по всему миру
Скорость доступа к данным, хранящимся в любой из служб управления данными платформы Windows Azure (в Таблицах, в Базе данных SQL, в Больших двоичных объектах), достаточно высока. Однако, скорость доступа к данным, хранящимся в оперативной памяти, ещё выше. По этой причине хранение в памяти копии часто запрашиваемых данных может улучшить производительность приложения. Для этого можно воспользоваться сервисом «Кэширование» платформы Windows Azure.
Приложение Облачных служб может сохранять данные в этом кэше, а затем извлекать их непосредственно, без необходимости доступа в постоянное хранилище. Как показано на рисунке 7, кэш может храниться как в виртуальной машине вашего приложения, так и в отдельной, специально выделенной для кэширования. В любом случае, кэш может быть распределённым, то есть хранящиеся в нём данные могут быть распределены по нескольким виртуальным машинам в рамках центра обработки данных платформы Windows Azure.
Например, приложение, которое неоднократно читает каталог продукции, может извлечь выгоду из использования такого кэширования, так как необходимые данные будут доступны быстрее. Эта технология также поддерживает блокировки, что позволяет ей не ограничиваться данными только для чтения, но и работать с изменяемыми данными. А приложения ASP.NET могут использовать этот сервис для хранения данных сессии. Для этого нужно лишь поменять настройки.
Предположим вам нужно хранить данные в виде больших двоичных объектов, к которым будут обращаться пользователи со всего мира. Например, это могут быть видеозаписи матчей последнего Кубка Мира, или обновления драйверов, или популярная электронная книга. Хранить копии данных в нескольких центрах обработки данных платформы Windows Azure может считаться решением, но если пользователей очень много, то такое решение недостаточно. Для ещё более высокой производительности вы можете воспользоваться Сетью доставки контента платформы Windows Azure.
Сеть доставки контента состоит из десятков сайтов по всему миру, каждый из которых способен хранить копии Больших двоичных объектов платформы Windows Azure. При первом обращении пользователя, находящегося в некотором уголке планеты, к определённому большому двоичному объекту, информация, содержащаяся в этом объекте, копируется из центра обработки данных платформы Windows Azure в локальное хранилище узла сети доставки контента в этом регионе. Затем, в ответ на последующие запросы из этого региона будет возвращаться копия большого двоичного объекта, сохранённая в сети доставки контента, — информации не потребуется проходить весь путь от ближайшего центра обработки данных платформы Windows Azure datacenter. В итоге пользователи из всех регионов мира получат более быстрый доступ к часто запрашиваемым данным.
Часть функционала большинства приложений составляет работа с удостоверениями. Например, решение о способе взаимодействия с пользователем принимается приложением в зависимости от того, кто этот пользователь. Предлагаемая Microsoft служба каталога Active Directory платформы Windows Azure, призвана помочь в этом процессе.
Как и большинство служб каталога, служба Active Directory платформы Windows Azure хранит информацию о пользователях и об организациях, к которым они принадлежат. Это позволяет пользователю войти в систему, получив при этом маркер, который он может предъявлять приложениям для удостоверения своей личности. Также эта служба позволяет синхронизировать информацию о пользователе со службой каталога Active Directory платформы Windows Server, выполняющейся в локальной сети организации. И хотя механизмы и форматы данных, используемые службой Active Directory платформы Windows Azure, не являются идентичными тем, что используются службой Active Directory платформы Windows Server, функции, выполняемые обеими службами весьма схожи.
Важно понимать, что служба Active Directory платформы Windows Azure создана в первую очередь для использования облачными приложениями. Например, она может быть использована приложениями, выполняющимися на платформе Windows Azure, или на другой облачной платформе. Она также используется и собственными облачными приложениями фирмы Microsoft, например, входящими в Office 365. Однако если вы хотите расширить ваш центр обработки данных в облако, используя Виртуальные машины и Виртуальные сети платформы Windows Azure, то выбрать для этого службу Active Directory платформы Windows Azure было бы неверным. Вместо этого, правильнее будет развернуть в облачной виртуальной машине службу Active Directory платформы Windows Server, как было описано выше.
Для организации доступа приложений к информации, хранимой в службе каталога Active Directory платформы Windows Azure, используется интерфейс (API), соответствующий принципам архитектуры REST, так называемый «граф службы Active Directory» (Windows Azure Active Directory Graph). Этот интерфейс позволяет приложениям, работающим на любой платформе, получать доступ к объектам каталога и к связям между ними. Например, авторизованное приложение может использовать этот интерфейс для получения сведений о пользователе, о группах, к которым он принадлежит и другую информацию. Приложения могут также видеть связи между пользователями (их социальный граф), что позволяет им работать более интеллектуально.
У службы каталога Active Directory платформы Windows Azure есть ещё одна возможность — «Контроль доступа» (Windows Azure Active Directory Access Control), которая облегчает для приложений получение идентификационной информации от Facebook, Google, Windows Live ID и других популярных провайдеров идентификации. Вместо того чтобы требовать от приложений понимания разнообразных форматов данных и протоколов, используемых этими провайдерами, компонент «Контроль доступа» переводит их все в один общий формат. Также этот компонент позволяет приложениям принимать регистрационную информацию от пользователей одного или нескольких доменов Active Directory. Например, организация-разработчик, предлагающая приложение типа «Программное обеспечение как услуга» может воспользоваться компонентом «Контроль доступа», чтобы предоставить пользователям каждого из своих клиентов единый вход в приложение.
Службы каталога являются ключевой основой локальной компьютеризации. Поэтому не должно удивлять, что они также важны и в облаке.
Один из наиболее привлекательных способов использования облачной платформы — это высокопроизводительные вычисления. Сущность таких вычислений — это одновременное выполнение кода на многих машинах. Применительно к платформе Windows Azure, это означает одновременный запуск множества виртуальных машин, параллельно работающих над решением некоторой задачи. Для осуществления этого, требуется некий способ задать расписание для приложений, то есть распределить их работу между экземплярами. Для этого платформа Windows Azure предлагает «Планировщик» (HPC Scheduler).
Этот компонент может работать с приложениями высокопроизводительных вычислений, реализующими стандартный интерфейс «Message Passing Interface» (MPI). Одним из множества примеров таких приложения является программа, осуществляющая анализ методом конечных элементов (скажем для моделирования краш-теста). Планировщик также может быть использован для приложений так называемого «усложнённого параллелизма», таких как имитационное моделирование по методу Монте-Карло. Независимо от этих конкретных методов, суть остаётся неизменной: Планировщик решает сложную задачу планирования параллельных вычислений, осуществляемых на множестве виртуальных машин платформы Windows Azure. Его цель — облегчить создание приложений высокопроизводительных вычислений, работающих в облаке.
Сегодня большую часть трафика в сети Интернет составляют видеоданные. А завтра эта доля ещё увеличится. Однако, предоставление видео контента в Сети — это непростая задача. Нужно учитывать множество факторов, таких как алгоритм кодирования или разрешение экрана пользовательского устройства. Спрос на видео контент также имеет склонность к всплескам, например известны пики по субботним вечерам, когда множество людей решают посмотреть фильм онлайн.
Учитывая популярность видео контента, можно с уверенностью сказать, что многие новые приложения будут созданы для его использования. И поскольку всем им придётся решать ряд одних и тех проблем, то не имеет смысла, чтобы каждый разработчик решал эти проблемы самостоятельно. Лучший подход заключается в создании платформы, которая обеспечивает общее решение, которое может использоваться многими приложениями. А построение этой платформы в облаке имеет ряд ясных преимуществ. Она может быть широко доступна, основываясь на принципах оплаты только за реальное использование, а также может справляться с изменчивостью спроса, с которой часто приходится сталкиваться видео приложениям.
Службы мультимедиа (Media Services) платформы Windows Azure призваны помочь в решении обозначенных проблем. В их состав входит набор облачных компонент, облегчающих жизнь людям, создающим и использующим приложения, работающие с видео и другим медийным контентом. Рисунок 8 иллюстрирует эту технологию.
Рисунок 8. Службы мультимедиа — это платформа для приложений, предоставляющих видео и другой медийный контент клиентам по всему миру
Как видно из рисунка, Службы мультимедиа предоставляют набор компонентов для приложений, работающих с видео и другим медийным контентом. Например, в этот набор входят: загрузочный компонент, позволяющий загружать видео контент для Служб мультимедиа (в которых он хранится в Больших двоичных объектах платформы Windows Azure); кодирующий компонент, поддерживающий разные видео и аудио форматы; компонент защиты контента, который обеспечивает управление цифровыми правами; компонент для вставки рекламы в видеопоток; компоненты для обеспечения потокового воспроизведения и другие. Партнёры Microsoft также могут предлагать компоненты для платформы, а Microsoft будет распространять их, а также, в интересах партнёров, выставлять счета за их использование.
Приложения, которые используют эти компоненты, могут выполняться как на платформе Windows Azure, так и где-либо ещё. Например, настольное приложение для создания и монтажа видео может позволить пользователю загружать видеоролики в облачные Службы мультимедиа и там различными способами обрабатывать. Другой пример: облачные службы управления контентом, выполняющиеся на платформе Windows Azure, могут использовать Службы мультимедиа для обработки и распространения видео контента. Любое приложение, где бы оно ни выполнялось и что бы оно ни делало, может выбирать какие компоненты ему использовать, обращаясь к ним при помощи интерфейсов, соответствующих принципам архитектуры REST.
Для распространения результатов своей работы, приложение может использовать Сеть доставки контента платформы Windows Azure, или альтернативную сеть доставки контента, или же отправлять данные напрямую пользователю. Однако, независимо от способов доставки, видео контент, созданный при помощи Служб мультимедиа, может быть потреблён различными клиентским системами, включая Windows, Macintosh, HTML 5, iOS, Android, Windows Phone, Flash, и Silverlight. Всё нацелено на облегчение создания современных медийных приложений.
Возникновение парадигмы «Программное обеспечение как услуга» (SaaS) меняет способ создания приложений. И также меняет способ их продажи. Поскольку приложения SaaS располагаются в облаке (то есть в Сети), то разумно предположить, что потенциальные покупатели будут искать программные решения онлайн. И это изменение относится не только к прикладным программам, но и к данным. Почему бы людям не обращаться в облако для приобретения коммерчески доступных наборов данных? Для решения обеих этих задач, Microsoft предлагает торговый сервис Marketplace платформы Windows Azure (см. рисунок 9).
Рисунок 9. Торговый сервис Marketplace платформы Windows Azure позволяет вам найти и приобрести приложения платформы Windows Azure, а также коммерческие наборы данных
Потенциальные покупатели могут воспользоваться поиском по сервису Marketplace, чтобы найти приложение платформы Windows Azure, удовлетворяющие их нужды, а затем подписаться на его использование у создателя приложения или напрямую через Marketplace. Покупатели также могут искать в Marketplace коммерческие наборы данных, включая демографические, финансовые, географические и многие другие виды данных. После того, как они найдут то, что им подходит, они могут получить доступ к этим наборам или от поставщика данных, или напрямую через Marketplace. Также, при помощи Marketplace, приложения могут использовать поисковый интерфейс Bing (Bing Search API), что позволит им получить доступ к результатам поиска в Интернет.
Первая предварительная версия платформы Windows Azure, вышедшая ещё в 2008 году, поддерживала только разработку в среде .NET. Однако сегодня вы можете создавать приложения для платформы Windows Azure практически на любом языке программирования. В настоящее время Microsoft предлагает комплекты разработчика (SDK), ориентированные на .NET, Java, PHP, Node.js и Python. Существует также общий комплект разработчика платформы Windows Azure, который обеспечивает базовую поддержку для любого языка программирования, включая C++.
Эти комплекты разработчика помогают вам создавать, развёртывать и управлять приложениями платформы Windows Azure. Они доступны на сайте www.windowsazure.com, а также на сервисе GitHub и могут быть использованы совместно со средами разработки Visual Studio и Eclipse. Платформа Windows Azure также предлагает инструменты командной строки, которые разработчики могут использовать совместно с любым редактором кода или средой разработки, включая инструменты развёртывания приложений в облако Windows Azure из систем под управлением Linux и Macintosh.
Наряду с помощью в построении приложений для платформы Windows Azure, эти комплекты разработчика также содержат клиентские библиотеки, которые помогут вам создавать программное обеспечение, работающее вне облака, но использующее сервисы платформы Windows Azure. Например, вы можете создать приложение, выполняющееся у хостера, которое использует большие двоичные объекты платформы Windows Azure, или же, применив интерфейс управления платформы Windows Azure, создать инструмент, осуществляющий развёртывание приложений для этой платформы.
Теперь, когда у вас есть общее представление, можно сделать следующий шаг — написать своё первое приложение для платформы Windows Azure. Выберите язык программирования, скачайте подходящий SDK и начинайте. Облачные вычисления — это новый стандарт. Начните работать с ними сейчас.
Дэвид Чэппелл (David Chappell) возглавляет Chappell & Associates (www.davidchappell.com) в Сан-Франциско, штат Калифорния. Своими выступлениями, статьями и консультациями он помогает людям во всём мире понимать и использовать новые технологии, а также принимать в их отношении более обоснованные решения.
Перевод: Андрей Мурзин