Skip to content
March 27, 2012 / ahriman hpc mode

Основы хранилища Windows Azure. Партиции.

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

image

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

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

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

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

Разреженность значений PartitionKey Размер партиции Достоинства Недостатки
Одно значение Маленькое/большое количество сущностей в одной партиции Можно использовать batch transactions/Entity Group Transactions Ограниченное масштабирование, ограниченная пропускная способность, так как используется один сервер.
Много значений Много партициий, количество зависит от распределения сущностей Возможно использование Batch transactions/sinfle request, можно балансировать нагрузку по серверам, в том числе динамическим образом
Уникальные для каждой сущности значения Много маленьких партиций Высокая масштабируемость, возможно появление партиций-диапазонов (о партициях-диапазонах далее в статье) Запросы на диапазоны могут обходить несколько серверов, невозможно использование batch transactions.

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

При отказе оборудования и потере, соответственно, всех наборов данных, которые хранились на данном оборудовании, запросы на эти данные распределяются между оставшимися в репликационной группе 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 RowKey SomeColumn
1
2
3
4
5

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

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

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

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

image

image

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: