Microsoft Windows Azure. Начнем с простого (или локальная разработка для «облака»). Часть 4

В предыдущих частях данного обзора (см. часть 1, часть 2, часть 3) мы познакомились с набором расширений для Microsoft Visual Studio, который позволяет разрабатывать приложения для Windows Azure, которые могут работать и локально, с использованием эмуляторов как самой платформы, так и облачного хранилища. Также мы посмотрели, из чего состоит «облачное» приложение и обсудили жизненный цикл роли и объектную модель Windows Azure.

В этой части мы остановимся на основных возможностях облачного хранилища – Windows Azure Storage, но перед этим, скажем несколько слов о локальном хранилище, доступном каждому экземпляру роли для временного хранения файлов.

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

Локальное хранилище задается в конфигурационном файле ServiceDefinition. csdef в секции LocalResources следующим образом:

В конфигурационном файле указывается имя локального хранилища – атрибут name, его объем – атрибут sizeInMB (по умолчанию – размер хранилища равен 1Мбайт) и флаг, указывающий на необходимость очистки хранилища при завершении работы экземпляра роли – атрибут cleanOnRoleRecycle. Общий объем локального хранилища, выделяемого для экземпляра роли, не должен превышать максимального размера, доступного для соответствующей виртуальной машины:

Размер виртуальной машины	Объем локального хранилища
Ультра-малая	20 Гбайт
Малая	250 Гбайт
Средняя	500 Гбайт
Большая	1024 Гбайт
Супер-большая	2048 Гбайт

При использовании Visual Studio локальное хранилище может быть описано в панели свойств соответствующей роли.

В коде, для доступа к локальному хранилищу используется метод GetLocalResource() класса RoleEnvironment, который, как мы помним из предыдущей части, описывает среду Windows Azure, в которой выполняется экземпляр роли. Метод GetLocalResource() возвращает на объект LocalResource, который представляет собой ... каталог в файловой системе виртуальной машины, в которой выполняется данный экземпляр роли.

Так как объект LocalResource представляет собой каталог, для манипуляции с его содержимым можно использовать стандартные классы .NET для файлового ввода/вывода. Свойство RootPath возвращает полное имя данного каталога. При использовании эмулятора Windows Azure значение этого свойства может выглядеть, например, так:

C:\Users\myaccount\AppData\Local\dftmp\s0\deployment(1)\res\deployment(1).MyService.MyService_WebRole.0\directory\localStoreOne\

а после развертывания приложения в Windows Azure – так:

C:\Resources\directory\<GUID>.MyService_WebRole.localStoreOne\

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

Windows Azure Storage Services

Платформа Windows Azure предоставляет масштабируемое, надежное и высоко-доступное «облачное» хранилище, обращение к которому происходит через веб-сервисы по протоколу REST (поэтому оно и называется «сервисом»). «Облачное» хранилище предоставляется в виде следующих «абстракций»:

• Таблицы – структурированное хранилище. Таблица – это набор сущностей, сущность – набор свойств
• Бинарные объекты – именованные файлы с метаданными
• Очереди – механизм надежного хранения и доставки сообщений
• Диски – надежные NTFS-тома для использования в приложениях

Для доступа к «облачному» хранилищу (таблицы, бинарные объекты и очереди) из кода на Microsoft .NET используются классы, описанные в пространстве имен Microsoft.WindowsAzure.StorageClient. Эти классы представляют собой оболочку вокруг REST-вызовов соответствующих сервисов хранения.

Учетная запись хранилища (Storage Account)

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

Таблицы

Таблицы (табличные сервисы) могут использоваться для хранения не реляционных данных. Сервисы поддерживают операции Create, Read, Update и Delete (CRUD). Таблицы высоко масштабируемы – в них можно хранить миллиарды записей, достаточно гибки - не требуют использования предопределенной схемы – каждая запись может иметь различное число свойств. Так как таблицы не предназначены для хранения реляционных данных, они не поддерживают внешних ключей и объединений. Язык запросов к таблицам базируется на программном интерфейсе REST, который совместим с ADO.NET Data Services, что означает, например, возможность использования LINQ.

Таблицы в Windows Azure базируются на следующих концепциях:

• Таблицы
• Сущности
• Свойства

Таблица представляет собой контейнер для данных. Таблицы создаются под учетной записью хранилища и одна учетная запись может иметь любое число таблиц. Данные хранятся в таблицах в виде сущностей. В терминах СУБД, сущность – это запись в базе данных. Таблицы поддерживают операции Create, Query и Delete. Если таблицы являются единицей запроса – запросы не могут распространяться на более чем одну таблицу, то сущность – это единица чтения и записи. Сущности имеют два специальных свойства – RowKey и PartitionKey. Они управляют распределением таблиц и будучи использованными совместно задают первичный ключ сущности. Свойства эквивалентны столбцам в СУБД, одна сущность может иметь до 255 свойств. Свойства не имеют фиксированной схемы – две сущности в одной таблице могут иметь различное число свойств. Сущности поддерживают операции Insert, Update, Merge (частичное обновление), Replace (полное обновление сущности), Delete, Query и атомарные транзакции для группы операций Create/Update/Delete.

В следующей таблице показаны основные ограничения для табличных сервисов Windows Azure.

Ресурс/тип	Размер/Диапазон/Ограничение
PartitionKey	До 64 Кбайт
RowKey (String)	До 64 Кбайт
String	UTF-16, до 64 Кбайт
Bool	True/False
DateTime	8 байт, от 1/1/1600 до 31/12/9999
GUID	16 байт
Int	32 бита
Long	64 бита
Double	64 байта
Entity	1 Мбайт
Число свойств сущности	252 + RowKey + PartitionKey + TimeStamp
Имя свойства	255 символов
Максимальное число сущностей, возвращаемых в одном запросе	1000
Число таблиц	Без ограничений
Число сущностей	Без ограничений
Общий размер сущности	1 Мбайт (включая имена свойств)
Общий размер таблицы	Без ограничений (но есть ограничение у учетной записи хранилища – 100 Тбайт)

Бинарные объекты

Сервис хранения бинарных объектов обеспечивает простой интерфейс для хранения именованных файлов с метаданными. Бинарные объекты хранятся в контейнере, который грубо можно считать аналогом каталога в традиционной файловой системе. Каждый бинарный объект и контейнер имеет уникальный адрес (URL) и бинарные объекты могут создаваться, удаляться и обновляться через программные интерфейсы REST.

Контейнеры также используются для задания прав доступа к объектам. Если задать публичную доступность контейнера, все бинарные объекты, находящиеся в нем, будут доступны всем пользователям Интернет. Так как все работает по протоколу HTTP, такой доступ к бинарному объекту означает простое указание его адреса (URL) в браузере.

Программные интерфейсы REST обеспечивают доступ к двум типам ресурсов – контейнерам и бинарным объектам внутри них. Сервис хранения бинарных объектов поддерживает два типа бинарных объектов – блочные объекты, которые оптимизированы для потокового вывода и страничные объекты, оптимизированные для случайных операций чтения/записи и поддерживают операцию записи набора байтов в бинарный объект.

Бинарные объекты доступны для чтения операцией Get Blob, которая поддерживает как чтение всего объекта, так и отдельного набора байтов. Бинарные объекты объемом до 64 Мбайт могут быть загружены с помощью операции Put Blob. Бинарные объекты объемом более 64 Мбайт должны загружаться как наборы блоков, где каждый блок не должен превышать 4 Мбайт. Страничные объекты создаются и инициализируются с помощью вызова операции Put Blob. Для записи содержимого страничного объекта используется операция Put Blob. Максимальный размер страничного объекта не должен превышать 1Тбайта. Ограничение на размер блочного объекта составляет 200 Гбайт.

Помимо перечисленных выше, бинарные объекты поддерживают операции DeleteBlob (удалить объект), CopyBlob (скопировать объект в рамках одной учетной записи хранилища), SnapshotBlob (создать копию объекта с доступом только для чтения) и LeaseBlob (установить блокировку на запись объекта).

С бинарными объектами могут быть ассоциированы стандартные HTTP метаданные (Cache-Control, Content-Encoding, Content-Type, и т.п.), а также дополнительные метаданные в формате пар <название, значение> - объем таких данных для одного объекта не должен превышать 8 Кбайт.

В следующей части мы продолжим знакомство с «облачным» хранилищем и обсудим очереди и диски.