Изучение сервиса хранилища в Windows Azure

[Intinger]

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

Большие двоичные объекты

Большие двоичные объекты (BLO:cool: зачастую очень необходимы в приложении. В них можно хранить самые различные данные — видео, аудио, заархивированные сообщения электронной почты или любую другую информацию. Чтобы использовать большие двоичные объекты, разработчик должен сначала создать один или несколько контейнеров в какой-либо учетной записи хранения. В каждом из таких контейнеров можно будет хранить один или несколько больших двоичных объектов.

Чтобы идентифицировать определенный большой двоичный объект, приложение может предоставлять универсальный код ресурса (URI) в следующем виде:

http://.blob.core.windows.net//,

где — это уникальный идентификатор, присвоенный при создании учетной записи хранения, а и — это наименования конкретного контейнера и большого двоичного объекта в этом контейнере.

Большие двоичные объекты бывают двух видов:

• Блочные BLOB-объекты, которые могут вмещать в себя до 200 гигабайт данных. Для более эффективной передачи они делятся на блоки. Если происходит сбой, отправку можно возобновить с последнего по времени блока, вместо того чтобы отправлять весь большой двоичный объект заново. После того как все блоки большого двоичного объекта загружены, его можно зафиксировать целиком. Страничные BLOB-объекты, каждый из которых может иметь размер до одного терабайта.
• Страничный BLOB-объект делится на 512-байтовые страницы, любые из которых может записывать и считывать приложение.

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

Еще один важный аспект больших двоичных объектов — это выполняемая ими функция в поддержке дисков Windows Azure. Чтобы лучше понять смысл выполняемой ими задачи, сначала нужно отметить, что экземпляры ролей могут по своему усмотрению осуществлять доступ к своей локальной файловой системе. Однако по умол-чанию это хранилище не является постоянным. Когда экземпляр прекращает работу, виртуальная машина и ее локальное хранилище уничтожаются. Однако если смонтировать диск Windows Azure для экземпляра, то можно сделать так, чтобы страничный BLOB-объект выглядел, как локальный диск с файловой системой NTFS. Данные, записываемые на диск, могут тут же записываться в базовый большой двоичный объект. Когда экземпляр не выполняется, эти данные постоянно хранятся в страничном BLOB-объекте и готовы для монтирования. Вот несколько примеров использования таких дисков: Разработчик может загрузить виртуальный жесткий диск с файловой системой NTFS, а затем смонтировать его в качестве диска Windows Azure. Это простой способ перемещения данных файловой системы между Windows Azure и локальной системой Windows Server.

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

Таблицы

Большой двоичный объект прост для понимания — это всего лишь множество байтов. А вот с таблицами все немного сложнее. На рис. 14 наглядно показано, как соотносятся между собой части таблицы.

[attachment=49:81fe536e8ad6daaa7a3d6ea849e8f6bb1.png]

Рис. 14. Таблицы предоставляют хранилище, основанное на сущностях.

Как показано на рисунке, в каждой таблице есть некоторое количество сущностей. У сущности может быть одно или несколько свойств, у каждого из которых есть имя, тип и значение. Поддерживаются разнообразные типы, в том числе Binary, Bool, DateTime, Double, GUID, Int, Int64 и String. Свойство может в разные моменты иметь разный тип в зависимости от хранящегося в нем значения. И не требуется, чтобы все свойства в одной сущности были одинакового типа, — разработчик может по своему усмотрению делать так, как удобно в разрабатываемом приложении.

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

Между таблицами хранилища Windows Azure и реляционными есть несколько отличий. Во-первых, они не являются таблицами в обычном смысле этого слова. Во-вторых, к ним нельзя осуществлять доступ с помощью обычных средств ADO.NET, и они не поддерживают запросы SQL. Таблицы в хранилище Windows Azure не обязаны придерживаться жесткой схемы — свойства одной сущности могут быть различных типов, причем они могут меняться со временем. Возникает естественный вопрос: зачем? почему бы просто не поддерживать обычные реляционные таблицы со стандартными запросами SQL?

Ответ кроется в главной задаче Windows Azure — поддержке приложений с высокой степенью масштабируемости. Традиционные реляционные базы данных могут масштабироваться, обслуживая все большее число пользователей, и для этого нужно, чтобы СУБД выполнялась на более мощных компьютерах. Однако для одновременной поддержки действительно огромного числа пользователей хранилище должно масштабироваться горизонтально, а не вертикально. Для этого механизм хранилища должен стать проще, а традиционные реляционные таблицы со стандартным SQL не очень для этого подходят. Решение данной задачи — это структура такого типа, как в таблицах Windows Azure.

Для применения таблиц разработчикам придется немного пересмотреть концепции, поскольку привычные реляционные принципы не получится применить без корректировок. И все же для создания хорошо масштабируемых приложений такой подход является оптимальным. Он позволяет разработчикам не беспокоиться о масштабах — они просто могут создавать новые таблицы, добавлять новые сущности, а об остальном позаботится Windows Azure. Также исключается значительная часть работы по поддержке СУБД, поскольку эту задачу Windows Azure берет на себя. В конечном итоге все это позволяет разработчикам сосредо-точиться на создаваемом приложении, не отвлекаясь на хранение и администрирование больших объемов данных.

Как и для всего остального в хранилище Windows Azure, для доступа к таблицам используется подход RESTful. Для этого приложение .NET может использовать сервисы данных WCF, скрывая базовые запросы HTTP. Любое приложение, созданное на основе .NET или других средств, также может по своему усмотрению использовать такие запросы напрямую. Например, запрос в отношении конкретной таблицы выражается как HTTP GET в отношении универсального кода ресурса (URI), форматированного следующим образом:

http://.table.core.windows.net/?$filter=

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

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

Очереди

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

http://.queue.core.windows.net/

Как описывалось ранее, очереди используются в основном для обеспечения взаимодействия между экземплярами Web-ролей и Worker-ролей. На рис. 15 показано, как это выглядит.

[attachment=50:9f6a2cdc312b8a6aaec68e60de4882851.png]

Рис. 15. Сообщения ставятся в очередь, выводятся из очереди, обрабатываются, а затем явным образом удаляются из очереди.

В типовом сценарии выполняется несколько экземпляров Web-роли, каждый из которых принимает задания от пользователей (шаг 1). Чтобы передать задание экземплярам Worker-роли, экземпляр Web-роли записывает сообщение в очередь (шаг 2). В таком сообщении, размер которого может доходить до 8 килобайт, может содержаться универсальный код ресурса (URI), указывающий на большой двоичный объект, сущность в таблице или на что-то еще — на усмотрение приложения. Экземпляры Worker-роли считывают сообщения из очереди (шаг 3) и затем выполняют задание, запрашиваемое в сообщении (шаг 4). Важно отметить, что при чтении сообщения из очереди сообщение фактически не удаляется. Вместо этого сообщение на определенный период времени (по умолчанию — на 30 секунд) становится невидимым для других читателей. Когда экземпляр Worker-роли завершает выполнение запрошенного в сообщении задания, он должен явным образом удалить это сообщение из очереди (шаг 5).

Разделение экземпляров Web-ролей и экземпляров Worker-ролей оправдано. За счет этого пользователю не придется ждать, пока будет обработано большое задание, а также упрощается масштабируемость — для этого достаточно просто добавить дополнительные экземпляры Web-роли или Worker-роли. Но зачем сделано так, что экземпляры должны явным образом удалять сообщения? Дело в том, что такой подход позволяет справ-ляться со сбоями. Если экземпляр Worker-роли, который извлекает сообщение, обрабатывает его успешно, то он удалит это сообщение, пока оно еще невидимо, то есть в течение 30-секундного промежутка. Но если экземпляр Worker-роли выводит сообщение из очереди, а затем происходит сбой, прежде чем указанная в этом сообщении работа выполнена, то он не удалит сообщение из очереди. Когда истечет срок невидимости сообщения, оно снова появится в очереди и будет прочитано другим экземпляром Worker-роли. Таким образом гарантируется, что каждое сообщение будет обработано хотя бы один раз.

Как следует из этого описания, семантика очередей хранилища Windows Azure отличается от очереди сообщений Microsoft Message Queuing (MSMQ) и других привычных технологий очередей. Например, традиционная система очередей может обеспечивать семантику «первым пришел — первым обслужен», гарантируя, что каждое сообщение будет доставлено в точности один раз. Очереди хранилища Windows Azure не дают таких обещаний. Как описывалось выше, сообщение может быть доставлено несколько раз и нет гарантии, что сообщения будут доставлены в каком-то определенном порядке. Работа в облаке имеет свои особенности, и разработчикам нужно к ним приспособиться.

При поддержке компании Microsoft

Далее мы рассмотрим Изучение Fabric Controller в Windows Azure

[Автор]

Сообщения