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 .

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

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

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.

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

Имеется три специальных свойства: ключ раздела (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

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

6.11. Личный опыт автора

Рассмотрим основы работы в Azure Storage.

Для начала работы необходимо выбрать в левом верхнем углу основного окна пункт Создать учетную запись хранения (рис. 6.1).

Выбирается имя учетной записи.

Затем выбирается территориальная группа (рис. 6.2), где будет осуществляться хранение данных.

Выбирается подписка для выделения квоты на создание учетной записи хранения (рис. 6.3).

Новая учетная запись хранения может быть создана из контекстного меню (рис. 6.4).

Вводится URL-адрес новой учетной записи (рис. 6.5, рис. 6.6).

Выбирается область или территориальная группа для учетной записи хранения (рис. 6.7).

Наконец, новый Storage account создан (рис. 6.8).