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

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

Рис.1. Трёхслойная архитектура партиций в Windows Azure

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

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

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

Отказоустойчивость

При отказе оборудования и потере, соответственно, всех наборов данных, которые хранились на данном оборудовании, запросы на эти данные распределяются между оставшимися в репликационной группе extent-ами, и в это же время потерянное оборудование будет заменено на новое и данные будут реплицированы на него. Таким образом реализуется отказоустойчивость в хранилище Windows Azure. Необходимо также отметить, что для механизма отказоустойчивости реализована функциональность георепликации – репликации в другие регионы/датацентры.

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

Цель масштабирования, а именно то, сколько может “выдержать” одна конкретная партиция, это примерно 500 сущностей в секунду. Подробнее можно почитать на MSDN – http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx.Партиции переносятся между серверами хранилища для эластичности и максимальной производительности. «Горячие» партиции могут быть вертикально масштабированы и Windows Azure Fabric может выделить больше ресурсов для партиций с большим количеством транзакций. Например, если у вас есть на одном сервере три партиции, и, если одна из партиций очень hot, то есть на нее приходится много запросов, она может быть перемещена на второй сервер. После того, как нагрузка на нее спадёт, она может быть возвращена на исходный сервер.

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

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

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

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

Использование партиций-диапазонов будет влиять не только на чтение, но и на такие операции как Insert. Использование Insert с инкрементируемым значением PartitionKey вынесено в отдельный паттерн Append Only (декрементируемым – Prepend Only).

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

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