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

Сервис платформы Windows Azure Storage предоставляет масштабируемое хранилище, доступно как сервис REST – таким образом взаимодействие с сущностями, хранящимися в Windows Azure Storage, может быть произведено с любой платформы, которая поддерживает HTTP, что обеспечивает кроссплатформенность и универсальность. Сервис Windows Azure Storage может выступать как альтернативой, так и дополняющим решением для SQL Azure Databases, масштабируемой "облачной" версией SQL Server. Каждая сущность в Windows Azure Storage хранится в трёх экземплярах: сущности, хранящиеся в сервисах таблиц и блобов, записываются в еще один триплет в другом датацентре в этом же регионе. Все сущности трёх сервисов хранятся в едином контейнере первого уровня, который называется аккаунтом хранилища. На одну подписку Windows Azure можно создать до 20 аккаунтов, каждый из которых может содержать до 200 ТБ данных. Максимальное количество аккаунтов может быть расширено обращением в техническую поддержку на портале управления Windows Azure. Необходимо отметить, что подписка Windows Azure имеет собственное ограничение в 10 петабайт данных (200 ТБ * максимальное количество аккаунтов на подписку, равное 50).

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

При хранении данных Windows Azure Storage использует одну из трех абстракций:

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

Программная модель Windows Azure Storage состоит из следующих классов:

Сервис блобов также имеет дополнительный класс CloudBlobContainer, отображающий контейнер блобов, в котором находятся сами блобы.

Блобы

Сервис блобов в Windows Azure Storage имеет простую структуру. Будучи REST-сервисом, хранилище предоставляет к каждой из хранимых сущностей гиперссылку, которая состоит из нескольких сегментов:

Блобы делятся на два типа – блочные и страничные.

Блочные блобы используются для потоковых нагрузок. Блочный блоб выглядит как логическая последовательность блоков, каждый из которых определяется специальным идентификатором и максимальным размером 200Гб на один блоб. Для блочного блоба используется оптимистичный параллелизм через ETags. Модификация блочного блоба состоит из двух этапов: сначала блоки должны быть загружены в хранилище как неподтвержденные блоки для конкретного блоба, после чего для создания обновленного блоба используется метод PutBlockList.

Страничные блобы используются для операций случайного чтения и записи. Страничный блоб выглядит как массив страниц, при этом каждая страница определяется отступом от начала блоба. Размер ограничен 1Тб на блоб. Для страничных блобов используется либо оптимистичный, либо пессимистичный (блокировка) параллелизм через Leases. Обновление происходит сразу же по завершению запроса на запись последовательного набора страница, поэтому блоки не надо подтверждать (commit). Важной особенностью страничных блобов является то, что оплата за хранение страничных блобов производится только за непустые страницы.

К сценариям использования блобов можно отнести:

Рассмотрим базовые операции, доступные для управления блобами в хранилище Windows Azure:

Синхронное создание контейнера блобов:

Стандартным способом создания контейнера блобов является синхронная операция. Для выполнения этой операции должен быть создан экземпляр класса CloudBlobClient, необходимый для предоставления операций, доступных для управления блобами и контейнерами блобов, после чего, на основе этого экземпляра, получается ссылка на контейнер блобов (ссылка на контейнер может быть получена даже в том случае, если его не существовало ранее). С помощью выполнения метода CreateIfNotExists контейнер создается, если его ранее не было. Для создания контейнеров также доступен метод Create, однако в случае существования контейнера с таким именем будет выброшено исключение, поэтому с позиции безопасности лучше использовать CreateIfNotExists.

При создании контейнера блобов необходимо учитывать следующие ограничения:

Асинхронный вариант операции создания использует метод BeginCreateIfNotExist.

Удаление контейнера блобов

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

Создание блоба

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

Создание и привязка метаданных к контейнеру блобов и блобу

Блобы могут иметь ассоциированные с ними метаданные. Заголовки метаданных могут быть определены по запросу при создании нового контейнера или блоба, или при "привязке" метаданных к уже существующим ресурсам. Получение метаданных производится с помощью свойства Metadata.

Определение прав доступа для контейнера

Класс BlobContainerPublicAccessType является перечислением (enumeration), состоящим из следующих возможных значений прав доступа:

Управление доступом с помощью Shared Access Signatures и Shared Access Policies

Shared Access Policies и Shared Access Signatures могут быть использованы для создания некоторых правил доступа к блобу или контейнеру, регламентирующих права доступа и период доступа.

Shared Access Policy: Политика определяет время начала действия политики, время истечения и набор разрешений для Shared Access Signatures.

Shared Access Signature: URL, предоставляющий доступ к контейнеру и блобу.

Таблицы

Данные в сервисе таблиц Windows Azure хранятся в виде коллекций сущностей. Сущность имеет первичный ключ и набор свойств. Свойства являются парами ключ-значения, что аналогично столбцам. Сервис таблиц в Windows Azure не является реляционным, поэтому нельзя выполнять следующие операции:

Сервис таблиц подходит тогда, когда разработчику не требуется реляционное хранилище или не нужны операции объединения (joins) на стороне сервера, а также в тех случаях, когда набор данных не очень велик и операции объединения можно обрабатывать на стороне клиента с помощью LINQ. Для доступа к сервису таблиц разработчик может использовать REST API, совместимый с WCF Data Services (ранее ADO.NET Data Services Framework).

Сущность в таблицах состоит из следующих компонентов:

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

public class MyClass : TableServiceEntity
        {
            public MyClass()
            {
                base.PartitionKey = "Clients";
                base.RowKey = Guid.NewGuid().ToString();
            }
            public MyClass(string PartitionKey, string RowKey)
            {
                base.PartitionKey = PartitionKey;
                base.RowKey = RowKey;
            }
            public string FName { get; set; }
            public string LName { get; set; }
        }

Класс TableServiceEntity определяет системные свойства PartititionKey, RowKey и TimeStamp, необходимые для каждой сущности в таблице Windows Azure. В примере выше для свойства PartitionKey было определено фиксированное значение. В реальной ситуации необходимо выбирать такое значение, которое обеспечит балансировку нагрузки между узлами хранилища, динамическое вычисляемое значение, например, день добавления сущности.

Характерные особенности сервиса таблиц включают в себя:

Ссылка на таблицу выглядит стандартно для именования сущностей в сервисах хранилища Windows Azure:

http://<account>.table.core.windows.net/<TableName>

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

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

CreateTable – создание таблицы с определенным именем. В случае наличия таблицы с таким именем будет выброшено исключение StorageClientException. Наиболее предпочитаемым способом создания таблиц является их создание с помощью класса контекста.

CloudTableClient.CreateTablesFromModel(typeof(MyClassDataContext),
             account.TableEndpoint.AbsoluteUri, account.Credentials);
        }

CreateTableIfNotExist – создание таблицы с определенным именем только в том случае, если ее не существует.

DoesTableExist – проверка на существование таблицы с определенным именем.

DeleteTable – удаление таблицы и ее содержимого из хранилища. если этой таблицы не существует, будет выброшено исключение StorageClientException.

DeleteTableIfExist – удаление таблицы и содержимого из хранилища только в том случае если она существует.

ListTables – получение списка всех таблиц. Возможно указание префикса для фильтрации имен таблиц.

AddObject – добавление сущности в таблицу.

В том случае, если в приложении происходит создание множества сущностей, дешевле (с позиции количества транзакций) и быстрее будет выполнить пакет запросов. Для этого необходимо передать в SaveChangesWithRetries соответстующий аргумент SaveChangesOptions.Batch. При этом необходимо учитывать, что в пакете можно совершать запросы update, delete и insert; один пакет может содержать до 100 сущностей; все сущности в одном пакете должны иметь одно значение PartitionKey.

Получение объектов может быть реализовано с помощью LINQ-утверждения. Для возвращения всех записей в пределах одной партиции и имеющих определенное значение поля, можно воспользоваться следующим LINQ-утверждением:

CloudTableQuery<MyClass> qry =
    (from e in ctx.CreateQuery<MyClass>("mytable")
     where e.PartitionKey == "Belotserkovskiy"  
e.FName == "Alexander"
     select e).AsTableServiceQuery<MyClass>();

foreach (MyClass unit in qry)
{
    Console.WriteLine("{0}, {1}",  unit.PartitionKey, unit.FName);
}

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

MyClass unit = (from e in ctx.CreateQuery<MyClass>("mytable") 
where e.PartitionKey == "Belotserkovskiy"  e.FName == "Alexander"
 select e).AsTableServiceQuery<MyClass>().FirstOrDefault();
unit.FName= "Alex";
ctx.UpdateObject(unit); 
ctx.SaveChangesWithRetries(); 
ctx.DeleteObject(unit);
ctx.SaveChangesWithRetries();

Очереди

Механизм очередей Windows Azure Storage используется для надежного хранения и дальнейшей доставки сообщений. Очереди Windows Azure Storage являются стандартным Middleware-обеспечением, который используется для обеспечения однонаправленных коммуникаций между Web и Worker-ролями в Windows Azure Cloud Services – например, Web-роль кладёт сообщения в очередь, которую в бесконечном цикле опрашивает Worker-роль и, забрав сообщение, приступает к его обработке. Если экземпляры Worker-роли не могут забрать или обработать сообщение, оно будет храниться некоторое время в очереди.

Важным замечанием про очереди является то, что имя очереди должно быть именем в нижнем регистре и URL-friendly для удобства использования его в REST.

В очередях хранятся сообщения. Сообщения характеризуются:

Ссылка на очередь выглядит стандартно для именования сущностей в сервисах хранилища Windows Azure:

http://<account>.queue.core.windows.net/<QueueName>

К основным операциям над очередями с использованием клиента облачных очередей CloudQueueClient относятся получение ссылки на очередь (GetQueueReference, возвращает объект CloudQueue) и получение списка очередей (ListQueues).

У объекта CloudQueue доступно несколько базовых методов по управлению очередью:

Усеченный экспоненциальный алгоритм отката

Одним из подходов к опросу очереди и уменьшению нагрузки на сервис является использование усеченного экспоненциального алгоритма отката. Суть данного подхода заключается в том, что каждый "пустой" опрос увеличивает интервал опроса вдвое, не пустой же опрос ставит интервал обратно в 1. Код, приведенный ниже, показывает возможную реализацию данного подхода.

while (true)
 {
     var msg = queue.GetMessage();
     if (msg != null)
          {
                 string retrievedMsg = msg.AsString;
                 //логика
                 query.DeleteMessage(msg);

                 if (gradualDecrease)
                      if (curInterval > intervalFloor) curInterval = curInterval /2;
                      else curInterval = intervalFloor;
                 else curInterval = intervalFloor;   
           }
      else
       {
            if (curInterval <intervalCeiling) curInterval = curInterval * 2;
           
       }

Долгие очереди

Очередь, собирающая сообщения в период отключённого потребителя, называется долгой. В этом случае потребитель очереди может выходить в онлайн раз в день и забирать все сообщения, затем снова отключаться. Полезно для обмена сообщениями с внешними вендорами, а также для сокращения оплаты за время выполнения сервиса (в том случае, если потребитель является, например, Worker-ролью в Windows Azure).

Разбиение процесса

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

Партиции

Windows Azure Storage использует специальное системное поле PartitionKey для того, чтобы группировать сущности в партиции. Партиции – одно из важнейших понятий на платформе Windows Azure, так как именно оно позволяет виртуально неограниченно масштабировать хранилище, логически разделяя данные на группы. Для того, чтобы лучше понимать, как работают партиции, рассмотрим принципы работы всего хранилища Windows Azure Storage. Windows Azure Storage – это система, имеющая трёхслойную архитектуру. На первом уровне находится VIP (Virtual IP), конечная точка, по которой доступна система. Далее все запросы масштабируются на три экземпляра фронтендов (FE), серверов, принимающих запросы на сущности. На данном слое происходит логика определения прав, аутентификация клиента и маршрутизация запроса на следующий уровень. Следующий уровень, уровень партиций (Partition Layer), управляется серверами партиций и мастерами партиций. Каждому серверу партиций принадлежит определённый набор партиций, за который он "ответственен" - мастер партиций также контролирует загрузку всех серверов. На этом слое происходит балансировка нагрузки между серверами партиций и партициями.

На самом низком уровне находится распределенная файловая система – Distributed File System (DFS). На этом слое хранятся данные, доступные всем серверам партиций. DFS балансирует нагрузку на систему, распределяя запросы, и состоит из множества узлов, по которым распределены наборы данных (extents), причем каждый из наборов данных назначается одному primary server (первичному серверу) и нескольким secondary server (вторичным серверам). Каждый экстент имеет данных от 100 Мб до 1 Гб, одна сущность же может быть распределена по нескольким экстентам. При операциях записи сущностей эти операции сначала обрабатываются первичным сервером (но не выполняются), после чего передаются на выполнение операции записи какому-то из вторичных серверов. Первичный сервер в данном случае выполняет роль контроллера, распределяющего операции и следящего за их выполнением. Первичный сервер не подтверждает операцию записи до тех пор, пока как минимум два вторичных сервера не сообщат об успешной записи данных в три домена обновлений и неисправностей.

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

Размер партиции

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

Суть и цели масштабирования по партициям

Цель масштабирования, показатели, которые определяют, сколько может "выдержать" одна партиция, равно 500 сущностей в секунду. Партиции переносятся между серверами хранилища для обеспечения высокой степени эластичности и максимальной производительности. "Горячие", то есть испытывающие высокую степень нагрузки, партиции могут быть вертикально масштабированы - Windows Azure Fabric Controller способен выделить больше ресурсов для партиций с большим количеством транзакций. Таким образом, если на одном сервере расположены три партиции, то, если одна из партиций начинает испытывать высокие нагрузки и большое количество запросов, она может быть перемещена на второй сервер. После того, как нагрузка на нее спадёт, она может быть возвращена на исходный сервер.

Каждый тип хранилища определяет свою партицию:

Очередь->Одна очередь = Одна партиция. Сервис очереди использует имя очереди в качестве ключа партиции, и все сообщения для данной конкретной очереди будут находиться в одной партиции, что означает, что каждая очередь имеет собственную цель масштабирования. Необходимо, однако, учитывать виртуальное ограничение в 500 сущностей в секунду, поэтому, если очередь испытывает нагрузку более 500 сущностей в секунду, необходимо определить, каким образом можно разделить систему на несколько очередей для реализации высокопроизводительного механизма обмена сообщениями.

Таблица -> Одна партиция таблицы = Одна партиция. В сервисе таблиц разработчик сам определяет, как будет партиционироваться таблица, с помощью определения системного свойства PartitionKey. Рекомендуется создавать маленькие многочисленные партиции, так как именно в этом случае будет организована наиболее эффективная масштабируемость на уровне платформы, а вместе с этим и скорость обращения к данным. Каждая сущность будет принадлежать партиции, определенной в ее PartitionKey. Если разработчик использует распространенную практику инкрементирования (или декрементирования) значения PartitionKey, он можете столкнуться с характерным поведением платформы Windows Azure – созданием партиций-диапазонов. Это необходимо для повышения эффективности запросов на диапазоны, которые без партиций-диапазонов должны были бы выходить за пределы партиции или сервера, что понизило бы производительность. Рассмотрим это на примере таблицы ниже.

При использовании инкрементирования может произойти следующая ситуация: платформа объединит первые три сущности в партицию-диапазон и, если разработчик выполнит запрос на диапазон с использованием PartitionKey и запросит сущности с PartitionKey между 1 и 3, запрос будет выполнен быстро, так как партиция будет находиться в пределах одного сервера.

Блоб -> Один блоб = Одна партиция.

При записи в партицию операция считается завершённой по записи на все три реплики.

Избыточность хранилища Windows Azure Storage

В Windows Azure Storage доступно две опции избыточности: Locally Redundant Storage и Geo Redundant Storage.

Locally Redundant Storage (LRS) предоставляет хранилище с высокой степенью долговечности и доступности внутри одной географической локации (региона). Платформа хранит три реплики каждого элемента данных в одной первичной географической локации, что гарантирует, что эти данные можно будет восстановить после сбоя, несущего общий характер (например, выхода из строя диска, узла, корзины и так далее, что является нормальным событием в центре обработки данных) без потери функциональности для аккаунта хранилища и, соответственно, не влияя на доступность и долговечность хранилища. Все операции записи в хранилище выполняются синхронно в три реплики в трех различных доменах ошибок (fault domain), код об успешном завершении транзакции возвращается после успешного завершения всех трех операций. В случае использования локального избыточного хранилища, если центра обработки данных, в котором размещены реплики данных, подвергнется сбою, несущему характер катастрофы (стихийной, техногенной или любой другой, которая приведет к потере подключения к центру обработки данных либо потере самого центра), Microsoft свяжется с клиентом и сообщит о возможной потере информации и данных, используя контакты, приведенные в подписке клиента.

Вторая опция, Geo Redundant Storage (GRS) предоставляет гораздо более высокую степень долговечности и безопасности. Реплики данных в этом режиме размещаются не только в первичной географической локации, но и во вторичной, находящейся в том же регионе, но за сотни километров. Таким образом, в географически избыточном режиме платформа сохраняет три реплики, но в двух локациях, что гарантирует то, что, если центр обработки данных подвергнется сбою, несущему характер катастрофы, то данные будут доступны из вторичной локации. Как и в случае первой опции избыточности, операции записи данных в первичной географической локации должны быть подтверждены перед тем, как система вернет код успешного завершения операции. По подтверждению операции в асинхронном режиме будет инициирован процесс репликации в другую географическую локацию. Рассмотрим подробнее процесс географической репликации.

Когда осуществляются операции создания, удаления, обновления, транзакция полностью реплицируется в три узла хранилища в трех доменах ошибок и обновлений в первичной географической локации, после чего клиенту возвращается код успешного завершения операции и в асинхронном режиме подтвержденная транзакция реплицируется во вторичную локацию, где полностью реплицируется в три узла хранилища в разных доменах ошибок и обновлений. Общая производительность при этом не падает, так как всё совершается асинхронно. Если происходит серьезный сбой в первичной географической локации, применяются правила географической отказоустойчивости, то клиент оповещается о возникшей катастрофе в первичной локации, после чего соответствующие ресурсные DNS-записи изменяются и начинают вести не на первичную локацию, но на вторую (DNS-запись account.service.core.windows.net). В процессе перевода DNS-записей могут наблюдаться сбои в работе, но по его завершению существующие блобы и таблицы становятся доступными по их прежним URL-ам. После завершения процесса перевода вторичная локация повышается в статусе до первичной; по завершению процесса повышения статуса центра обработки данных инициируется процесс создания новой вторичной географической локации в этом же регионе и дальнейшей репликации данных.

Рассмотрим реальный пример, взятый из блога разработчиков Windows Azure Storage. В аккаунте хранилища размещено несколько блобов, foo и bar. Для блобов полное имя блоба равно значению PartitionKey. Разработчик выполняет две транзакции A и B на блобе foo, после чего выполняет две транзакции X и Y на блобе bar. Система гарантирует, что транзакция А будет географически реплицирована перед транзакцией B, и, соответственно, транзакция X будет географически реплицирована перед транзакцией Y.

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

Локально избыточное хранилище полезно тогда, когда необходимо сократить затраты на хранение некритичных либо легковоспроизводимых данных, тогда как географически избыточное может быть полезно при наличии важных данных.

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

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

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

Метрики сводят воедино основную статистику для блобов, таблиц и очередей. При этом статистику можно подразделить на два типа - информацию о запросах (количество запросов по часам, средняя задержка на стороне серверов, средняя задержка 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 можно отнести два примера:

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

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

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

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

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

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

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

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

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

Введение в Windows Azure SQL Databases

Windows Azure SQL Databases – это облачный сервис баз данных, основанный на технологиях, использующихся в классическом SQL Server. Windows Azure SQL Databases предоставляет доступную глобально инфраструктуру и функциональность базы данных как сервис (Database As A Service). Основанный на облачных технологиях сервис Windows Azure SQL Databases, предлагает большое количество характерных преимуществ, включающих быстрое развертывание, экономичное масштабирование, высокую доступность и сокращение издержек на управление. С точки зрения разработчика, Windows Azure SQL Databases предлагает знакомую реляционную модель программирования и методы доступа к данным и простые варианты развертывания, которые уже используются разработчиком. Как и любой облачный сервис, Windows Azure SQL Databases устраняет проблемы с инфраструктурой, тем самым предоставляя разработчикам больше свободы. С точки зрения IT, Windows Azure SQL Databases предлагает надежное и безопасное облачное решение, которое может быть интегрировано локальной инфраструктурой, с гибкими механизмами контроля и управления. Ключевым достоинством сервиса является простота масштабирования решения. При возрастании требований есть возможность горизонтального и вертикального масштабирования.

Знакомая модель разработки

При разработке локальных приложений с использованием SQL Server разработчики используют для взаимодействия с источником данных различные клиентские библиотеки (протокол TDS). Windows Azure SQL Databases имеет аналогичный интерфейс TDS, поэтому разработчики могут использовать те же самые инструменты и библиотеки в процессе создания клиентских приложений с использованием данных в облаке.

Windows Azure SQL Databases оперируют стандартными терминами, за исключением того, что "контейнером" верхнего уровня, который должен быть создан, является сервер Windows Azure SQL Databases. Внутри каждого сервера Windows Azure SQL Databases могут быть созданы стандартные объекты SQL Server - таблицы, представления, хранимые процедуры, индексы и т.д. Подобная модель позволяет использовать существующую архитектуру реляционной БД и Transact SQL и упрощает процесс миграции существующих приложений в Windows Azure SQL Databases. Для задач миграции существует набор утилит, упрощающих процесс (например, встроенная функция SQL Server Management Studio или AzureMW). Серверы и базы данных Windows Azure SQL Databases являются виртуальными объектами, не соответствующими физическим сущностям.

Редакции Windows Azure SQL Databases

В свободном доступе для разработчика имеется две редакции баз данных Windows Azure SQL Databases, которые можно свободно менять на портале управления либо с помощью SQL-запроса: Web и Business. Основная разница между редакциями заключается в максимально доступном размере каждой базы данных в данной редакции (Web – до 5 ГБ, Business – до 150 ГБ). Каждая из редакций несёт собственное назначение – например, базы данных Web-редакции подходят скорее для проектов, которые оперируют небольшим количеством данных, базы данных Business-редакции предназначены для корпоративных баз данных, которым необходимые большие объёмы хранилища.

В июле 2013 года было объявлено о дополнительном предложении Windows Azure SQL Databases Premium, в рамках которого предлагается использование более мощных ресурсов для обслуживания серверов Windows Azure SQL Databases. Это предложение подразумевает под собой предоставление пользователю эксклюзивно зарезервированных под его нужды ресурсов. Использование базы данных редакции Premium позволяет пользователям масштабировать программную инфраструктуру основываясь на пиковых нагрузках без того, чтобы учитывать при этом важную особенность облачных ресурсов – разделяемое использование одних и тех же ресурсов несколькими клиентами. Подобное предложение значительно упрощает разработку или миграцию локальных приложений в облако, которые проектируются с учётом пиковых нагрузок, и дает пользователю возможность масштабировать зарезервированные мощности таким образом, чтобы они удовлетворяли потребностям настоящего времени – например, в случае сезонных нагрузок приложению может понадобиться больше ресурсов; приложению необходимо большое количество ресурсов (CPU, RAM, IO) для выполнения операций с эксклюзивным доступом к ресурсам; приложение выполняет большое количество параллельных операций (запросов к базе данных); приложению должна гарантироваться минимальная латентность, и т.д. В таблице ниже сведены максимальные резервируемые мощности редакции Premium на стадии Preview.

Миграция в Windows Azure SQL Databases

При миграции или разработке гибридной инфраструктуры с использованием Windows Azure SQL Databases разработчик может оставить клиентское приложение в локальной инфраструктуре и перенести только данные, к которым можно получить доступ с помощью библиотек доступа к данным . Однако, если используется подобная архитектура, необходимо учитывать проблемы с задержками, которые происходят в связи с географической удалённостью и коммуникационной инфраструктурой, которые могут привести к более сложному коду в приложении. Рекомендацией в данном случае может служить перемещение логики доступа к данным в Windows Azure, таким образом приложение, использующее данные, находится там же, где и данные, в том же центре обработки данных. Например, в Windows Azure может быть расположен Web-интерфейс приложения.

Синхронизация данных

Сервис Windows Azure SQL Databases позволяет решать задачи по синхронизации данных. Например, в центральной базе данных в центре обработки данных на стороне клиента хранятся критичные данные, сотрудники же организации используют приложение, которое работает на мобильных устройствах, и хранилище данных в SQL Server Express. В целях безопасности администратор организации не имеет права открывать брандмауэр на локальном центре обработки данных. В этом случае, с помощью сервиса Windows Azure SQL Databases разработчик может обеспечить безопасное и полностью синхронизированное решение, создав базу данных в Windows Azure SQL Databases, провайдера Sync Framework для центра обработки данных, который позволит синхронизировать информацию между центром обработки данных и базой данных в Windows Azure SQL Databases, и второго провайдера Sync Framework для мобильных устройств сотрудников, который позволит синхронизировать информацию между этими устройствами и данными в Windows Azure SQL Databases.

Серверы SQL Azure

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

Для создания и управления сервером баз данных используется портал управления Windows Azure.

База данных Windows Azure SQL Databases

Каждый сервер Windows Azure SQL Databases может содержать до 148 баз данных. Каждый сервер содержит служебную базу данных master. В базах данных можно создавать стандартные объекты: таблицы, представления, индексы, хранимые процедуры и т.д. База данных может быть создана на портале управления аналогично созданию сервера. Фактически, пользователю доступно только операция только создания – далее присутствует выбор, необходимо ли использовать существующий сервер или создать новый.

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

Архитектура доступа к данным

База данных Windows Azure SQL Databases работает по стандартному протоколу TDS. TDS используется также в SQL Server, таким образом, приложения, использующие SQL Server, могут быть подключены к базе данных Windows Azure SQL Databases. Для этого, однако, необходима поддержка Secure Sockets Layer (SSL).

Подробнее про архитектуру Windows Azure SQL Databases можно прочитать в специально посвященном этому вопросу документе по адресу http://rutechnet.blob.core.windows.net/files/SQL_Azure_Database.pdf.

Модель безопасности Windows Azure SQL Databases

Многие базы данных содержат важные данные, поэтому необходимо правильно осуществлять контроль доступа, который особенно сложен в мультитенантном приложении, использующимся пользователями из различных организаций. Принципы безопасности Windows Azure SQL Databases аналогичны SQL Server с SQL Server Authentication:

SQL Azure Databases использует стандартный протокол SQL Server Tabular Data Stream (TDS), при этом разрешены исключительно зашифрованные коммуникации. В SQL Server 2008 было введено новое средство: прозрачное шифрование данных (transparent data encryption, TDE), позволяющее полностью шифровать данные с минимальными усилиями. На данный момент SQL Azure Databases не поддерживает шифрование на уровне базы данных. Следует заметить, что в настоящее время SQL Azure Databases доступен только через TCP-соединения и только через порт 1433, поэтому необходимо учитывать возможности шифрования ADO.NET и сертификаты. Второе средство защиты SQL Database Azure - брандмауэр SQL Azure Databases, которым изначально блокируется весь доступ к серверу SQL Azure Databases. Попытки подключения до соответствующей настройки будут безуспешны. Брандмауэром Windows Azure SQL Databases можно управлять через портал Windows Azure SQL Databases или напрямую в главной базе данных с помощью хранимых процедур, таких как sp_set_firewall_rule и sp_delete_firewall_rule.

При первой попытке управления созданным сервером портал Windows Azure предложит автоматически добавить IP-адрес пользователя в список разрешенных.

Как и в любой реализации SQL Server, управление пользовательскими учетными записями — еще один аспект, который нужно контролировать. Благодаря этим средствам Windows Azure SQL Azure является высокозащищенной управляемой платформой для приложений в облаке.

Между SQL Server и SQL Azure Databases в контексте безопасности существует список различий:

Масштабирование баз данных

Каждая база данных ограничена размером в 150 ГБ (в том случае, если используется режим Business). Для хранения более чем 150 Гб данных разработчик должен реализовывать механизм партиционирования или шардинга данных. Шардингом называется методика, используемая разработчиками для увеличения производительности, масштабирования и снижения стоимости в тех случаях, когда, например, приложение использует модель данных с четкими критериями индексирования, например, хранящие и обрабатывающие данные о продажах (дата и время). В этом случае методика шардинга может помочь оптимизировать и масштабировать решение, позволяя также параллельно обрабатывать данные - приложения могут располагать несколько партиций данных на несколько наборов вычислительных ресурсов и обрабатывать данные одновременно.

Windows Azure SQL Databases предоставляет встроенный механизм для шардинга данных - Windows Azure SQL Databases Federations. Подробнее про SQL Azure Federations: http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx

Заключение

Возрастание количества и сложности хранимых данных приводит к неизбежной проблеме нехватки ресурсов для осуществления их хранения. В сценарии, в котором важна производительность при доступе к таким данным, необходимо реализовывать сложные механизмы масштабирования, производить настройку, поддерживать работоспособность построенной инфраструктуры. Windows Azure предоставляет два типа хранилища, которые можно использовать в различных ситуациях и инфраструктурах (включая гибридные): Windows Azure Storage и Windows Azure SQL Databases. Windows Azure Storage предлагает три сервисы – таблицы, блобы и очереди – которые являются масштабируемыми, долговечными механизмами, реализующими глобально-доступное хранилище данных. Windows Azure SQL Databases является решением, позволяющим реализовывать более сложные сценарии хранения данных, в том числе реляционных.