Hello Windows Azure

Разобравшись в теории, что такое Windows Azure OS, хочется попробовать все на практике. Для этого давайте создадим простой сервис для облака, в котором используем одну Web роль, а также 2 вида объектов поддерживаемых Storage: Blob и Table. Для того чтобы не изобретать велосипед, возьмем одно из демо-приложений из Windows Azure Training Kit.

Шаг 1. Создание проекта

Итак, приступим. Создадим новый проект в Visual Studio.

Для этого выберите шаблон Windows AzureCloud Service и введите имя проекта GuestBook.

В открывшемся диалоге New Cloud Service Project выберите ASP.NET Web Role добавьте ее в проект и переименуйте в GuestBook_WebRole.

Давайте теперь посмотрим на Solution Explorer. Для нашего сервиса были созданы 2 проекта. Один из них называется GuestBook и содержит схему и конфигурацию самого сервиса, а также конфигурацию для всех Web и Worker ролей, включенных в сервис. Второй проект называется GuestBook_WebRole и является обычным ASP.Net Web приложением. Единственное его отличие в том, что он содержит класс WebRole, который позволяет управлять поведением роли при ее инициализации, запуске и остановке.

  
Давайте боле детально рассмотрим все элементы проекта GuestBook. Их всего три:

• Файл ServiceDefinition.csdef описывает модель сервиса. Он содержит метаданные необходимые Windows Azure для того чтобы корректно настроить и запустить сервис: список ролей сервиса с необходимыми размерами виртуальных машин, список эндпоинтов и сертификатов для каждой роли, а также определения настроек для локального хранилища. Обратите внимание, что после публикации сервиса в облако, его модель уже нельзя будет изменить.

• Файл ServiceConfiguration.cscfg содержит количество экземпляров для каждой роли и значения для параметров конфигурации определенных в файле модели. В отличие от модели конфигурацию сервиса можно изменять в любой момент. Для этого нужно просто загрузить в облако новый файл конфигурации.

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

Шаг 2. Создание модели данных

Наша гостевая книга будет хранить свои записи в таблице GuestBook в Azure Storage, для доступа к которой мы будем использовать библиотеку ADO.NET Data Services.

Добавим к нашему сервису новый проект: библиотеку классов GuestBook_Data. Добавим в новую библиотеку ссылку на Microsoft.WindowsAzure.StorageClient и System.Data.Service.Client.

 Удалим из библиотеки класс Class1 и добавим GuestBookEntry, который будет описывать одну запись нашей гостевой книги. Измените файл GuestBookEntry.cs так, чтобы он соответствовал листингу приведенному ниже:

Обратите внимание, мы использовали класс TableServiceEntry как базовый для GuestBookEntry. В этом классе уже определены свойства PartitionKey, RowKey и TimeStamp, обязательные для всех сущностей сохраняемых в таблицах хранилища Windows Azure.

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

Добавим теперь в библиотеку класс GuestBookDataContext, в котором реализуем доступ к таблице GuestBook. Для этого унаследуем его от TableServiceContext и реализуем свойство IQueryable<GuestBookEntry>. Окончательный вид класса GuestBookDataContext должен соответствовать приведенному в листинге.

Теперь добавим в библиотеку класс GuestBookEntryDataSource. Мы будем использовать его для привязки к данных к элементам управления на ASP.Net странице. Кроме того именно этот класс будет отвечать за создание таблицы GuestBook в хранилище. (Метод CreateTablesFromModel класса CloudTableClient пробегается по всем открытым IQueryable<Т> свойствам класса GuestBookDataContext и создает для них соответствующие таблицы, если они еще не существуют). Сейчас GuestBookEntryDataSource должен выглядеть следующим образом:

Добавим в него метод для выборки сегодняшних записей из таблицы:

Метод для добавления новых записей:

И последний метод, который будет обновлять URI для картинки связанной с записью из таблицы GuestBook.

Шаг 3. Модификация Web роли.

Теперь давайте обновим Web роль, так чтобы она могла добавлять и отображать записи гостевой книги. Для начала давайте добавим в GuestBook_WebRole ссылки на Microsoft.WindowsAzure.StorageClient и GuestBook_Data.

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

Разобравшись с разметкой, давайте добавим странице нужной функциональности. Для этого в классе страницы объявим такие поля:

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

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

Для того чтобы наша веб роль могла получить доступ к Azure Storage нам надо добавить параметры аккаунта в ее конфигурацию. Для этого в свойствах веб роли на закладке настроек добавим строку соединения. Назовем ее DataConnectionString, а в значение ей подставим “UseDevelopmentStorage=true”. Это допустимо т.к. мы не планируем публиковать свой сервис в облаке, а только потестируем его на локальном компьютере.

Теперь для получения полностью функциональной веб роли нам осталось только инициализировать ConfigurationPublisher’а для того чтобы в дальнейшем вызов метода FromConfigurationSetting мог создать нам экземпляр класса CloudStorageAccount. Для чего это надо можно прочитать здесь. Итак, давайте добавим в метод OnStart класса WebRole непосредственно перед оператором return следующий код:

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

После того, как вы отладите и протестируете свой сервис локально, нужно будет опубликовать его в облаке. Сделать это достаточно просто. В контекстном меню проекта GuestBook выберите Publish. В открывшемся диалоговом окне вы сможете опубликовать свой сервис в облаке прямо из Visual Studio, либо только создать установочный пакет. Используя этот пакет вы сможете позже опубликовать свой сервис с портала Windows Azure.

Ссылки:

• Исходный код проекта для VS2010
• About Development Storage
• Differences Between Development Storage and Windows Azure Storage Services
• Windows Azure Platform Training Kit

Windows Azure OS

Как я уже писал ранее облачная операционная система Windows Azure является одним из четырех основных компонентов облачной платформы Майкрософт Windows Azure Platform и отвечает за выполнение приложений и хранение данных на серверах в датацентрах Майкрософт, а также предоставляет средства для мониторинга и управления. Если не вдаваться в детали, то датацентр представляет собой большой склад, набитый стандартными морскими контейнерами, в которых стоят стойки с серверами. Когда вы размещаете свой сервис в облаке, то для вас создается и запускается виртуальная машина, на которую устанавливается ваше приложение. Операционная система виртуальной машины называется гостевой ОС и представляет собой оптимизированную для облака версию Windows Server 2008.  В отличие от гостевой ОС, Windows Azure OS как раз управляет всей инфраструктурой датацентра, всеми серверами, виртуальными машинами, сервисами.

Сейчас доступны 4 размера виртуальных машин.

VM Size	CPU Cores	Memory	Local Storage
Small	1	1.7 GB	250 GB
Medium	2	3.5 GB	500 GB
Large	4	7 GB	1000 GB
ExtraLarge	8	14 GB	2000 GB

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

Compute

Итак какие же приложения можно размещать в облаке? То, что Windows Azure умеет хостить .Net приложения наверняка не вызывает удивления. Это как бы обязательная программа. Поддерживаются 3.5 SP1 и 4.0 версии фреймворка. Но кроме этого Azure позволяет хостить приложения скомпилированные в native code , а также написанные на Java и PHP.

Все сервисы размещаемые в Azure состоят из одной или нескольких так называемых “ролей”. Сейчас доступны всего  два вида этих ролей.

• Web Role представляет собой ASP.Net Web приложение (сайт или WCF сервис) доступное по HTTP, HTTPS.
• Worker Role является приложением, которое может решать любые задачи для вашего сервиса, доступное по HTTP, HTTPS или TCP и реализованное, например, как сервис Windows.

Число ролей, из которых состоит ваше приложение, можно изменять на ходу. При этом надо понимать что каждый экземпляр роли – это отдельная виртуалка.

Storage

Кроме хостинга приложений Windows Azure предоставляет еще сервисы для хранения данных. Обратите внимание, что Storage это не SQL Azure, а отдельный сервис, который позволяет хранить в облаке следующие типы объектов:

• Blob’ы (Binary Large OBjects) – для больших текстовых и бинарных данных
• Таблицы – для структурированных данных
• Очереди – для обеспечения надежного обмена сообщениями между сервисами.
• Drive – для приложения в облаке Drive выглядит как подключенный сетевой диск NTFS. На самом деле каждый Drive представляет собой Page Blob отформатированный как NTFS раздел.

Для обеспечения надежности хранения данных в Storage всегда хранится три копии. Сейчас они хранятся в рамках одного датацентра, но раскидываются по разным стойкам и контейнерам. В планах Майкрософт хранить их в разных датацентрах, вплоть до того, что на разных материках.

Доступ ко всем типам объектов хранилища осуществляется  через стандартный HTTP REST PUT/GET/DELETE интерфейс. Для .Net приложений поставляется библиотека Windows Azure Storage Client Library, оборачивающая вызовы REST методов в удобную объектную модель.

Ниже приведен общий вид URI для доступа к объектам хранилища:

• http://<account>.blob.core.windows.net/<container>/<blob>
• http://<account>.table.core.windows.net/<Table>
• http://<account>.queue.core.windows.net/<Queue>

Хочу обратить ваше внимание на то, что Storage можно использовать сам по себе (например, для десктопных приложений), а не только для приложений размещенных в облаке.

Blob

На рисунке выше показана структура хранилища blob’ов. Аккаунт является точкой доступа к хранилищу. Каждый аккаунт может иметь несколько контейнеров. Каждый контейнер может содержать несколько blob’ов.

Существует два вида blob’ов:

• Block blob –оптимизированные для потокового доступа. Максимальный размер блока тут составляет 4MB, blob поддерживает до 50 тысяч блоков. Максимальный размер blob’а – 200GB.
• Paged – оптимизированные для произвольного доступа к страницам blob’а. Максимальный размер такого blob’а – 1TB.

Таблицы

Таблицы в Azure Storage хранят наборы сущностей. Однако в отличие от реляционных таблиц они не имеют фиксированной схемы данных. Каждая сущность (строка) в таблице представляет собой список свойств (столбцов). А каждое свойство хранит пару значений; имя свойства и значение свойства.

Общий объем данных каждой сущности не должен превышать 1MB. Типы данных, которые можно хранить в таблицах:

Property Type	Details
Binary	An array of bytes up to 64 KB in size.
Bool	A Boolean value.
DateTime	A 64-bit value expressed as UTC time. The supported range of values is 1/1/1601 to 12/31/9999.
Double	A 64-bit floating point value.
GUID	A 128-bit globally unique identifier.
Int	A 32-bit integer.
Int64	A 64-bit integer.
String	A UTF-16-encoded value. String values may be up to 64 KB in size.

Каждая строка в таблице должна иметь два обязательных поля:

• PartitionKey – Используется для разбиения таблицы на разделы. Система использует это поле для того, чтобы автоматически разнести записи различных разделов  таблицы по разным узлам хранилища.
• RowKey – уникальный идентификатор записи внутри раздела.

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

Очереди

 

Очереди используются для обмена сообщениями между приложениями (необязательно размещенными в облаке). Azure Queues это облачный аналог MSMQ.

• Нет никаких ограничений на количество сообщений в очереди (единственное ограничение – 100TB – максимальный объем доступный для аккаунта).
• Сообщения в очереди могут храниться до недели. Потом они будут автоматически удалены.
• Максимальный размер сообщения – 8KB. Данные большего размера можно сохранить в Blob или таблицу, а в сообщение поместить только ссылку.

Однако Azure Queues  не являются традиционным FIFO контейнером. Сообщения остаются в очереди до тех пор пока не будут явно удалены из нее. Если сообщение будет прочитано каким-то приложением, то оно будет помечено как “невидимое”. Невидимым сообщение может оставаться от 30сек (значение по умолчанию) до 2х часов. Если за это время сообщение не будет удалено, то невидимость будет снята, и сообщение станет доступно для обработки другими приложениями. Понятно что в такой реализации ни о каком порядке обработки сообщений речи быть не может.

Цены

Коммерческая эксплуатация Windows Azure началась с 1 января 2010 года. Цены у Майкрософт получились такими:

• Compute = $0.12 / instance / hour
• Storage = $0.15 / GB stored / month
• Storage transactions = $0.01 / 10K
• Data transfers (excluding CDN) = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)
• CDN data transfers = $0.15 GB for North America and Europe ($0.20 GB elsewhere)
• CDN transactions = $0.01 / 10K

Обратите внимание, что минимальной единицей оплаты вычислительных ресурсов является астрономический час, а не вычислительный. Это означает, что если вы запустите 100 экземпляров в 9:30 утра и остановите их в 9:45, то вам насчитают 100 экземпляров * 1 час * 0,12 центов = $12.

Исключением являются следующие моменты:

• запуск за 5 минут до наступления полного астрономического часа (11:56). В этом случае вам не насчитают час работы с 11:56 до 12:00.
• остановка в течение 5 минут после наступления полного астрономического часа (13:03). В этом случае вам не насчитают 1 час работы с 13:00 до 13:03.

Итого

На этом с теорией, я думаю, пора заканчивать. В следующей статье, я покажу как создать простой сервис для Windows Azure.

Ссылки:

• Windows Azure Highlights
• Overview of Service Architecture
• Windows Azure Pricing

Коллекции в WCF

Вчера я написал про рекомендации по использованию коллекций в .Net. Сегодня я хочу описать особенности работы со списками (list collections) в WCF. Для словарей (dictionary collections) есть свои нюансы, поэтому про них в следующий раз.

Итак, коллекция передаваемая в WCF через границы сервиса, перед отправкой будет сериализована в XML формат, и затем, на другой стороне десериализована. Это означает, что типы используемые клиентом являются независимыми от типов используемых сервисом.

Кроме того, коллекции с одинаковым типом элементов сериализуются в XML одинакового формата. Т.е. при десериализации абсолютно все равно в какой конкретно тип коллекции разворачивать полученный XML.  Не имеет значения возвращает метод сервиса int[] или List<int>, на клиенте по умолчанию будет int[].

В Visual Studio клиентские прокси-классы для WCF создаются утилитой svcutil.exe. Ее конфигурация позволяет изменять дефолтный тип для коллекций. Список доступных типов приведен на скриншоте.

Такая взаимозаменяемость коллекций может быть полезна. Например, можно использовать оптимизированный по производительности List<T> на сервере, а на клиенте ObservableCollection<T>, который удобно привязывать к пользовательским элементам управления.

Ссылки:

1. Collection Types in Data Contracts
2. CollectionDataContractAttribute Class

Использование коллекций

Недавно возникла у меня необходимость определиться с тем, какие типы коллекций лучше использовать для публичного API. Оказалось, что наша библиотека светит наружу как обычные массивы, так и коллекции List<T> и Collection<T>.

Использовать массивы в публичном API  – плохая идея. Объяснения почему это так смотрите в статье Эрика Липперта Arrays considered somewhat harmful.

Почему стоит использовать Collection<T> вместо List<T> смотрите здесь и здесь.

Кроме того "Framework Design Guidelines" в разделе 8.3 содержит множество рекомендаций относительно использования коллекций. Основные из них:

• DO NOT provide settable collection properties.
• DO use Collection<T> or a subclass of Collection<T> for properties or return values representing read/write collections.
• DO use ReadOnlyCollection<T>, a subclass of ReadOnlyCollection<T>, or in rare cases IEnumerable<T> for properties or return values representing read-only collections.

Тренинг по Windows Azure

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

Честно говоря, я сомневался, идти мне или нет. Во-первых, тренинг немаленький - два полных рабочих дня. А тут ведь спринт в самом разгаре. Во-вторых, есть у меня осадок после подобных тренингов, когда тренер, рассказывая программистам о программировании, говорил: «Я уже, слава богу, три года не программирую».

Однако я зарегистрировался, чему в итоге очень рад. Оказалось, что тренинг ведет Костя Косинский. Года полтора назад, Костя был в Донецке с презентацией SQL Server 2008. Я помню, что тогда меня очень впечатлил его уровень квалификации и опыт. С облачным тренингом все повторилось. Костя рассказал массу интересных вещей про Windows Azure. Чувствовалось, что человек разбирается в теме и активно ею интересуется. В итоге к концу тренинга у меня сложилось достаточно цельное представление об облачной технологии от Майкрософт, о том, что она позволяет делать, и когда может пригодиться.

Хочу заметить, что меня очень сильно удивило количество слушателей. Четверо. Вроде бы тема интересная. А где народ? :)

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

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

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

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

Число компаний предоставляющих облачные сервисы растет как грибы после дождя и давно уже перевалило за сотню. Среди лидеров такие известные компании как Amazon, Google, VMware, Microsoft, IBM. Все предоставляемые ими облачные решения можно разделить на четыре группы:

Инфраструктура как сервис (IaaS - Infrastructure-as-a-Service). Поставщик предоставляет вам свою аппаратную инфраструктуру. Вместо того чтобы самостоятельно покупать сервера, сетевое оборудование и программное обеспечение, вы можете арендовать все это у поставщика и дальше настраивать и использовать по собственному желанию. Решения этого типа поставляют, например, Amazon и Rackspace.

Платформа как сервис (PaaS - Platform-as-a-Service). Поставщик предоставляет платформу для разработки, тестирования, развертывания и поддержки ваших сервисов в облаке. Примерами таких решения являются Microsoft Azure и Google AppEngine.

Программа как сервис (SaaS - Software-as-a-Service). Поставщик продает доступ к своим приложениям или сервисам развернутым в интернете. Примером такого решения является сайт Saleforce.com, продающий онлайн CRM систему.

Данные как сервис (Data-as-a-Service(DaaS). Поставщик хранит в облаке ваши данные и предоставляет вам средства для управления ими, анализа и построения отчетов. Примером такого решения является SQL Azure.

Итак, что же такое Windows Azure Platform? Это набор облачных технологий, которые предоставляют широкий спектр сервисов для размещения, управления и поддержки программ и данных в облаке.

На данный момент Windows Azure Platform состоит из трех компонентов: операционной системы Windows Azure, базы данных SQL Azure и AppFabric, который позволяет организовывать взаимодействие между различными сервисами, а также осуществлять контроль доступа к сервисам и данным. Четвертый компонент платформы Dallas еще находится в разработке на стадии CTP. Он позволяет облегчить процесс обмена данными между поставщиками и потребителями данных.

Для решения своих задач вы можете использовать как все компоненты Windows Azure Platform одновременно, так и каждый по отдельности. Например, абсолютно нормальным является сценарий, когда вы используете SQL Azure как хранилище данных для каких-то своих десктопных приложений. Или, например, используете AppFabric для того чтобы организовать обмен сообщениями между приложениями.

На этом, наверное, все. Кому интересна тема Azure, я рекомендую скачать Training Kit и поделать лабы. Кроме того обязательно посмотрите видео с Channel9.

Ссылки:
1. Windows Azure Platform Training Kit
2. Windows Azure Platform Training Course
3. Windows Azure Getting Started
4. What is the Windows Azure Platform?
5. По дороге с облаками