Windows Azure Storage

Цель лекции: Ознакомление с Windows Azure Storage – основной компонентой Windows Azure для управления памятью; с компонентами самой Azure Storage и их возможностями для пользователей.

Презентацию к данной лекции Вы можете скачать здесь.

6.1. Введение

Windows Azure Storage – компонента для управления памятью в Windows Azure.

Компонента Windows Azure Storage Services обеспечивает устойчивое и надежное хранение информации в облаке.

Для доступа к сервисам Storage необходима учетная запись хранения (storage account), обеспечиваемая через Windows Azure Platform Management Portal .

Основные сервисы памяти включают:

• Сервис Blob (Binary Large OBjects) для хранения текста или бинарных данных
• Сервис Queue для надежного сохраняемого обмена сообщениями между сервисами
• Сервис Table для работы со структурированной памятью, к которой можно обращаться по запросам.

Windows Azure SDK предоставляет REST API (REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов) API и управляемый (managed) API для работы с сервисами памяти (managed API означает, что возможен доступ к Storage из .NET-приложений, см. главу 4). Доступ к сервисам Памяти возможен из сервиса, выполняемого в Windows Azure, или непосредственно через Интернет из любого приложения, которое может посылать и принимать данные по протоколам HTTP/HTTPS.

Более подробная информация о REST API для сервисов памяти приведена в документе Windows Azure Storage Services REST API Reference. Информация об управляемом API для сервисов памяти приведена в документе Windows Azure Managed Library Reference.

6.2. Основные возможности Windows Azure Storage

• - Binary Large Object (BLOB) Service, простейший способ хранения бинарных данных в Windows Azure.
• - Table Service - поддержка работы с таблицами
• - Queue Service -поддержка надежного обмена сообщениями между экземплярами Web-ролей и Worker-ролей.
• - Windows Azure Drive позволяет приложениям для Windows Azure смонтировать Page Blob на отдельный том файловой системы NTFS VHD.

6.3. Преимущества Windows Azure Storage

Устойчивость к ошибкам и встроенная сеть CDN

Вся пользовательская информация, хранящаяся в Windows Azure, дублируется три раза. Независимо от того, какую память использует клиент облака, его данные дублируются в нескольких дублирующих областях (fault domains), что обеспечивает большую устойчивость к ошибкам. Windows Azure Content Delivery Network (CDN) обеспечивает интеграцию "в один клик" с сервисами Памяти (Storage). CDN естественно улучшает производительность, автоматически размещая информацию пользователя поблизости от того места, где она наиболее часто используется.

REST и Managed API

В дополнение к сервисам Памяти Window Azure для приложений пользователя, выполняемых в Windows Azure, она также может работать с приложениями, выполняемыми на локальной машине или на другой облачной платформе. Скачайте SDK, чтобы получить как REST API (программный интерфейс без состояния), так и управляемый API для работы с сервисами Памяти. Более подробно REST API описан в документации MSDN.

6.4. Некоторые особенности предоставления сервисов Windows Azure. Storage

Объем использованной Памяти в Windows Azure вычисляется на основе Вашего использования ее в среднем (в течение какого-либо оплачиваемого периода какого-либо двоичного объекта, таблицы, очереди, либо Windows Azure Drive storage. Например, если Вы использовали 10 ГБ Памяти за первую половину месяца и ничего не использовали за вторую, Вам предъявят счет на использование (в среднем) 5 ГБ Памяти.

В СTP-версии Azure предоставляются три сервиса Памяти - таблицы (tables), очереди (queues) и бинарные объекты (blobs). В коммерческой версии они объединены под сервисами блокировки и кэширования. Они функционируют под управлением Azure Fabric.

Каждый сервис имеет программный .NET API и HTTP REST API. REST-узлы сети имеют следующий формат имен:

.[storage,blob,queue].core.windows.net. 

Имеются также утилиты командной строки для разработки и сопровождения данных на стадиях их разработки и сопровождения.

6.5. Таблицы

Возможности.

Таблица - это структурированные, не требующие описаний в виде схем, масштабируемые хранилища данных, похожие на хранилище данных App Engine. Последняя является распределенной системой, которая по стилю проектирования очень похожа на Bigtable. Она рассчитана на хранение миллиардов объектов и терабайтов данных.

Модель сущности в таблице

Каждый объект имеет имя таблицы и набор свойств вида ключ / значение. Явное представление информации о схеме данных не требуется. Ограничения на объекты: максимальный объем – 1 МБайт, максимальное число свойств – 255.

Поддерживаются следующие типы свойств:

• строка (string)
• двоичный объект (binary)
• целое число (int)
• длинное целое (long)
• булевское значение (bool)
• вещественное двойной точности (double)
• глобальный идентификатор объекта (guid)

Имеется три специальных свойства: ключ раздела (partition key), ключ строки в таблице (row key), и версия (version).

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

6.6. Очереди к таблицам

Кроме стандартных операций, таблицы поддерживают некоторую ограниченную форму очередей.

В CTP-версии поддерживается только отношение равенства для ключей с одним или несколькими свойствами. Результат выдается в лексикографическом порядке, в соответствии с ключом (partition, row). В коммерческой версии поддерживаются вторичные индексы, определяемые пользователем, для сортировки.

API для запросов из программ использует LINQ – упрощенный язык запросов, аналогичный языку запросов GQL, реализованный в Google App Engine. HTTP REST API использует интерфейс Astoria, основанный на использовании URL-адресов для обращения к сервисам для работы с данными ADO.NET.

6.7. Целостность и транзакции

Таблицы Azure полностью целостны, обращения к одному объекту строго синхронизированы, отсутствуют "dirty reads". Для работы с каждым объектом поддерживаются транзакции в стиле ACID (Asynchronous, Consistent, Isolated, Durable – известная парадигма для описания транзакций).

6.8. Реализация таблиц

Таблицы спроектированы аналогично хранилищам данных Bigtable and the App Engine.

Разделы (partitions) аналогичны блокнотам (tablets) Bigtable. Все объекты в разделе хранятся на одном сервере данных.

Транзакции реализованы аналогично App Engine datastore,. Используется управление версиями объектов.

6.9. Запросы. Возможности

Очереди аналогичны Amazon SQS. Они позволяют поставить сообщение в очередь и обрабатывать его позже, в слабо связанном виде.

Операции над очередями во время выполнения: enqueue (поставить сообщение в очередь), dequeue (удалить сообщение из очереди), delete (удалить из очереди все сообщения). Сообщения типизированы, их размер – до 8 КБайт.

Операция dequeue использует займы (lease) – средство синхронизации. Займ позволяет в течение определенного заданного интервала времени удерживать сообщение в состоянии, не видимом другим клиентам очереди. По умолчанию время завержки – до 30 секунд.

6.10. Бинарные объекты (Blobs)

Сервис blob служит для хранения "непрозрачных" бинарных объектов. Они аналогичны Amazon S3. Бинарные объекты могут создаваться и обрабатываться программным путем. Бинарные объекты идентифицируются уникальными, мнемоничными путями доступа в виде URL-адресов типа:

<account>.blob.core.windows.net

Размер бинарных объектов можнт быть до 50 ГБайт. Блоки до 64 МБайт могут обрабатываться непосредственно, большей длины – должны быть разделены на блоки. Каждый блок закачивается на сайт отдельно. В конце операции проверяется, все ли блоки закачаны.

Пространство имен для бинарных объектов – это иерархический URL-путь вида:

<account>.blob. core.windows.net

Бинарные объекты можно изменять или клонировать, они не являются неизменяемыми.