Хранение и обработка данных с Windows Azure Storage и Windows Azure SQL Databases

Диагностика хранилища

Сервис Windows Azure Storage Analytics предоставляет клиенту возможность отслеживать и анализировать использование данных, хранящихся в аккаунте хранилища (блобы, таблицы и очереди), используя эти данные для адаптации приложения к реальным нагрузкам. Аналитические данные состоят из логов (выполненные запросы к аккаунтам хранилища) и метрик (статистика по объему и запросам блобов, таблиц и очередей).

Логи хранятся в виде блочных блобов в специальном контейнере блобов ($logs). Каждая запись-лог в блобе отображает один сделанный запрос и содержит служебную информацию (ID запроса, URL запроса. HTTP-статусы, имя аккаунта клиента, имя аккаунта хозяина, IP-адрес клиента и т.д.). Логи позволяют выяснить:

• Сколько анонимных запросов было выполнено от определенного диапазона IP-адресов?
• К каким контейнерам блобов был наиболее активный доступ?
• Сколько раз и каким образом был запрошен конкретный URL с Shared Access Signature?
• Кто запросил удаление контейнера блобов?
• Пришел ли запрос на сервер или нет.

Метрики сводят воедино основную статистику для блобов, таблиц и очередей. При этом статистику можно подразделить на два типа - информацию о запросах (количество запросов по часам, средняя задержка на стороне серверов, средняя задержка E2E, средняя полоса пропускания, общее количество успешных и неуспешных запросов и т.д., и эта информация предоставляется на уровне сервиса и API и доступна для блобов, таблиц и очередей) и информацию об объеме (ежедневная статистика потребленного сервисом пространства, количество контейнеров и количество объектов, хранящихся внутри сервиса, доступна только для блобов). Метрики хранятся внутри специальной служебной таблицы в сервисе таблиц.

Все аналитические логи, статистика и данные метрик хранятся внутри пользовательского аккаунта, и получить к ним доступ можно через стандартное REST API сервисов блобов и таблиц и с помощью портала управления Windows Azure. Кроме этого, логи и метрики могут быть потреблены из любого сервиса, размещенного как в Windows Azure, так и в интернете или локального приложения, которое умеет работать и обрабатывать HTTP/HTTPS-запросы. Выключить или включить логи и метрики можно как с помощью REST API, так и с помощью портала управления Windows Azure. Также можно настроить срок, после которого данные будут автоматически удаляться.

Обеспечение безопасности с помощью Shared Access Signatures

Shared Access Signatures доступны для всех сервисов Windows Azure Storage. Функциональность Shared Access Signature заключается в предоставлении возможности детального контроля доступа к ресурсам; определения, какие операции может совершить пользователь над ресурсом, имея Shared Access Signature. К списку доступных для определения SAS операций относятся:

• Чтение и запись контента - в случае блобов дополнительно их свойства и метаданные, а также блок-списки.
• Удаление, лизинг, создание снапшотов блобов.
• Получение списков элементов контента.
• Добавление, удаление, обновление сообщений в очередях.
• Получение метаданных очередей, включая количество сообщений в очереди.
• Чтение, добавление, обновление и вставка сущностей в таблицу.

Параметры Shared Access Signature включают в себя всю информацию, необходимую для выдачи доступа к ресурсам хранилища - параметры запроса в URL определяют временной промежуток, через который Shared Access Signature будет деактивирована, разрешения, предоставляемые данной Shared Access Signature, ресурсы, к которым предоставляется доступ и сигнатуру, с помощью которой происходит аутентификация. Кроме этого, в URL Shared Access Signature можно включить ссылку на хранимую политику доступа, с помощью которой можно обеспечить более гибкий контроль доступа.

Shared Access Signature должны распространяться с использованием HTTPS и разрешать доступ на максимально короткий временной промежуток, необходимый для выполнения операций.

Строение Shared Access Signature

В составе URL Shared Access Signature находятся компоненты, специфичные для REST и специфичные для Shared Access Signature.

Параметр signedversion

Содержит версию сервиса, обеспечивающего Shared Access Signature. При этом, если Shared Access Signature указывает на сервис хранилища версии, более ранней, нежели 2012-02-12, этот Shared Access Signature может оперировать только блобом или контейнером.

Сервисы Windows Azure Storage могут принимать запросы, которые указывают конкретную версию каждой операции (сервиса), при этом разработчик может указать версию, используя заголовок x-ms-version. Функциональность различных версий и механизмы работы (не концептуальные) могут различаться.

Request Headers:
x-ms-version: 2011-08-18

Если URL Shared Access Signature использует этот параметр со значением версии, которая является более новой, нежели клиентское приложение, использующее этот URL, могут возникнуть функциональные различия. Например, в версиях, более ранних нежели 2011-08-18, операция Get Blob не возвратит заголовок Accept-Ranges.

Параметр Signed Resource (только для блобов)

Значение параметра определяет ресурсы, к которым обеспечивается доступ данной SAS. Имеет значение либо b (блоб), что обеспечивает доступ к контенту и метаданным блоба, либо c (контейнер), что обеспечивает доступ к контенту и метаданным любого блоба в контейнере и получение списка блобов в этом контейнере.

Параметр Table Name (только для таблиц)

Определяет имя таблицы.

Параметр Access Policy

Определяет значения временного промежутка, в течение которого будет работать данная Shared Access Signature, и набор разрешений. Состоит из следующих частей:

signedstart – начальный момент времени в ISO 8061 (например, так - YYYY-MM-DDThh:mm:ssTZD), когда сигнатура будет активирована. Если опущено, сигнатура будет активирована в момент получения запроса.

signedexpiry – конечный момент времени в ISO 8061, когда сигнатура станет неактивной. Опускается, если соответствующее значение указано в хранимой политике доступа.

signedpermissions – набор разрешений, ассоциированных с сигнатурой (r, w, d для блобов r и w для контейнеров блобов, r a (add) u p (process, забор и удаление и r a(add) u d (delete) для сущностей таблиц) для сообщений в очередях). Опускается, если соответствующее значение указано в хранимой политике доступа. Пример: sp=rwdl, sp=rw, sp=r. Нельзя выдавать разрешения на создание и удаление контейнеров, очередей и таблиц, получения списка сущностей в них, получения и редактирования метаданных и свойств контейнеров блобов и очистки метаданных и очистки очередей от сообщений.

Startpk, startrk – только для таблиц. Минимальное значение partition key и row key, которое доступно пользователю.

Endpk, endrk – только для таблиц. Максимальное значение partition key и row key, которое доступно пользователю.

Параметр Signed Identifier

Определяет соответствующую Shared Access Signature хранимую политику доступа. Хранимые политики доступа предоставляют определенную степень контроля над одной или более Shared Access Signature, включая отзыв Shared Access Signature. Каждый контейнер блобов, очередь или таблица может иметь до 5 ассоциированных с ней хранимых политик доступа.

К сценариям использования Shared Access Signature можно отнести два примера:

1. Сервис должен давать доступ клиентам к каким-то частям аккаунта хранилища с определенными разрешениями, например, приложение Windows Phone для сервиса, который запущен в Windows Azure. Токен Shared Access Signature должен распространяться клиентам (приложениям Windows Phone) для обеспечения доступа к хранилищу Windows Azure.
2. Сервис должен выдавать доступ к ресурсам по необходимости, также быстро закрывая его после окончания срока действия токенов.

Генерация токенов может проходить согласно следующим моделям:

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

Локальный эмулятор Windows Azure Storage

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

К общим различиям относятся количество аккаунтов и ключ аутентификации: локальный эмулятор хранилища поддерживает только один фиксированный аккаунт и один ключ аутентификации, при этом они не меняются и равны, например:

Имя аккаунта: devstoreaccount1

Ключ аккаунта: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

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

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

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