Добрый день, уважаемые коллеги! WAS — это облачная система хранения данных, которая предоставляет клиентам возможность хранить практически неограниченные объемы данных в течение любого периода времени.
WAS был представлен в промышленной версии в ноябре 2008 года.
Ранее он использовался во внутренних целях Microsoft для таких приложений, как, например, хранение видео, музыки и игр, хранение медицинских записей и т. д. Статья написана на основе работы с хранилищем сервисов и посвящен принципам работы этих сервисов.
Клиенты WAS имеют доступ к своим данным из любого места в любое время и платят только за то, что они используют и хранят. Данные, хранящиеся в WAS, используют как локальную, так и географическую репликацию для восстановления после серьезных сбоев.
В настоящее время хранилище WAS состоит из трёх абстракций — больших двоичных объектов (файлов), таблиц (структурированное хранилище) и очередей (доставки сообщений).
Эти три абстракции данных охватывают потребность в различных типах хранимых данных для большинства приложений.
Распространенным вариантом использования является хранение данных в больших двоичных объектах; очереди используются для передачи данных в эти BLOB-объекты; промежуточные данные, состояние и подобные временные данные хранятся в таблицах или больших двоичных объектах.
При разработке WAS были учтены пожелания заказчика, а наиболее значимыми характеристиками архитектуры стали:
- Сильная консистенция – Многим клиентам нужна надежная согласованность, особенно корпоративным клиентам, перемещающим инфраструктуру в облако.
Они также хотят иметь возможность выполнять операции чтения, записи и удаления в соответствии с некоторыми условиями для оптимистического контроля над строго согласованными данными — для этого Windows Azure Storage предоставляет то, что теорема CAP (согласованность, доступность, устойчивость к разделению) описывает как сложную задачу.
для одновременного достижения: строгой согласованности, высокой доступности и устойчивости к разделению.
- Глобальные и масштабируемые пространства имен.
– для упрощения использования хранилища WAS реализовала глобальное пространство имен, позволяющее хранить данные и получать к ним доступ из любой точки мира.
Поскольку одной из основных целей WAS является предоставление возможности хранить большие объемы данных, это глобальное пространство имен должно быть способно обрабатывать эксабайты данных.
- Восстановление после сбоев – WAS хранит данные клиентов в нескольких центрах обработки данных, расположенных на расстоянии нескольких сотен километров друг от друга, и такая избыточность обеспечивает эффективную защиту от потери данных из-за различных ситуаций, таких как землетрясения, пожары, торнадо и так далее.
- Затраты на мультиарендность и хранение – для снижения стоимости хранения несколько клиентов обслуживаются из одной общей инфраструктуры хранения, и WAS, использующая эту модель, где хранилища множества разных клиентов с разным объемом требуемого хранилища группируются в одном месте, значительно снижает общий требуемый объем хранилище, чем если бы WAS выделила отдельное оборудование для каждого клиента.
Основная цель хранилища Windows Azure — предоставить единое глобальное пространство имен, которое позволит клиентам размещать и масштабировать любые объемы данных в облаке.
Чтобы предоставить глобальное пространство имен, WAS использует DNS как часть пространства имен, а пространство имен состоит из трех частей: имени учетной записи хранения, имени раздела и имени объекта.
Пример: http(s):// ИмяУчетной записи.
core.windows.net/ИмяРаздела/ИмяОбъекта Имя учетной записи – имя учетной записи хранения, выбранное клиентом, является частью имени DNS. Эта часть используется для поиска основного кластера хранилища и, по сути, дата-центра, в котором хранятся необходимые данные и куда должны отправляться все запросы данных для этого аккаунта.
Клиент в одном приложении может использовать несколько имен учетных записей и хранить данные совершенно в разных местах.
Имя раздела — имя раздела, определяющее расположение данных при получении кластером хранения запроса.
PartitionName используется для вертикального масштабирования доступа к данным на нескольких узлах хранения в зависимости от трафика.
ИмяОбъекта – если в разделе много объектов, ObjectName используется для уникальной идентификации объекта.
Система поддерживает атомарные транзакции для объектов внутри одного и того же PartitionName. Значение ObjectName является необязательным; для некоторых типов данных PartitionName может однозначно идентифицировать объект в учетной записи.
В WAS вы можете использовать полное имя большого двоичного объекта в качестве имени раздела для больших двоичных объектов.
В случае с таблицами необходимо учитывать, что каждая сущность в таблице имеет первичный ключ, состоящий из PartitionName и ObjectName, что позволяет группировать сущности в одну партицию для выполнения атомарной транзакции.
Для очередей PartitionName — это значение имени очереди, и каждое сообщение, помещенное в очередь, имеет свое собственное имя объекта, которое однозначно идентифицирует сообщение в очереди.
WAS-архитектура
Контроллер ткани занимается управлением, мониторингом, обеспечением отказоустойчивости и многими другими задачами в дата-центре.Это механизм, который знает обо всем, что происходит в системе, от сетевых подключений до состояния операционных систем на виртуальных машинах.
Контроллер постоянно общается со своими собственными агентами, установленными в операционных системах, и отправляет полную информацию о том, что происходит с этой операционной системой, включая версию ОС, конфигурации сервисов, пакеты конфигурации и так далее.
Что касается хранилища, Fabric Controller распределяет ресурсы и управляет репликацией и распределением данных по дискам, а также балансировкой нагрузки и трафика.
Архитектура хранилища Windows Azure показана на рисунке 1. 
Рис.
1. Архитектура хранилища Windows Azure. Штамп хранения (SS).
Под этим термином понимается кластер, состоящий из N рек (стойки) узлов хранения, где каждая река находится в своей области ошибок с избыточной сетевой и электрической мощностью.
Кластеры обычно содержат от 10 до 20 рек по 18 узлов на каждую реку, тогда как первое поколение Storage Stamps содержало около 2 петабайт. Следующий — до 30 петабайт. Также Storage Stamp стараются сделать максимально используемым, то есть процент использования каждого SS должен быть примерно 70 по загрузке мощности, количеству транзакций и пропускной способности, но не более 80, так как должен быть резерв для более эффективное выполнение дисковых операций.
Как только загрузка SS достигает 70 %, служба определения местоположения переносит учетные записи на другие SS, используя репликацию между SS. Служба определения местоположения (LS).
Эта служба управляет всеми SS и пространствами имен учетных записей для всех SS. LS распределяет учетные записи по SS и реализует балансировку нагрузки и другие задачи управления.
Сам сервис распределен по двум географически разнесенным местам в целях собственной безопасности.
Потоковый уровень (SL).
Этот уровень хранит данные на диске и отвечает за распространение и репликацию данных между серверами для хранения данных в SS. SL можно рассматривать как уровень распределенной файловой системы внутри каждого SS, понимающий файлы («потоки»), способы хранения этих файлов, их репликации и так далее.
Данные хранятся на SL, но доступны через Partition Layer. SL по сути предоставляет интерфейс, используемый только PL, и файловую систему с API, который позволяет выполнять операции записи только с добавлением, позволяя PL открывать, закрывать, удалять, переименовывать, читать, добавлять части и объединять большие файлы».
потоки», упорядоченные списки больших фрагментов данных, называемых «экстентами» (рис.
2).
Рис.
2. Визуальное представление потока, состоящего из экстентов.
Поток может содержать несколько указателей на экстенты, и каждый экстент содержит набор блоков.
В этом случае экстенты могут быть «запечатаны», то есть в них нельзя добавлять новые фрагменты данных.
Если будут предприняты попытки прочитать данные из потока, данные будут получены последовательно от экстента E1 к экстенту E4. Каждый поток обрабатывается уровнем разделов как один большой файл, и содержимое потока может быть изменено или прочитано в произвольном режиме.
Блокировать .
Наименьшая единица данных, которую можно записать и прочитать, размер которой может достигать определенных N байт. Все записанные данные записываются в виде одного или нескольких объединенных блоков, причем блоки не обязательно должны быть одинакового размера.
Эxтент. Экстенты — это единицы репликации на уровне потока, и по умолчанию Storage Stamp хранит три реплики для каждого экстента, хранящегося в файле NTFS и состоящего из блоков.
Размер экстента, используемого Partition Layer, составляет 1 ГБ, тогда как более мелкие объекты расширяются Partition Layer до одного экстента, а иногда и до одного блока.
Для хранения очень больших объектов (например, больших двоичных объектов) объект разделяется на несколько экстентов слоем раздела.
При этом, конечно, уровень разделов отслеживает, какие экстенты и блоки каким объектам принадлежат. 
Менеджер потока (SM).
Stream Manager отслеживает пространство имен потоков, управляет состоянием всех активных потоков и экстентов и их расположением между узлами расширения, следит за работоспособностью всех узлов расширения, создает и распределяет экстенты (но не блоки — Stream Manager ничего о них не знает) , и выполняет ленивую повторную репликацию экстентов, реплики которых были потеряны из-за аппаратных ошибок или просто недоступны, и собирает «мусорные экстенты».
Stream Manager периодически опрашивает и синхронизирует состояние всех узлов расширения и хранимых в них экстентов.
Если SM обнаруживает, что экстент был повторно реплицирован с числом EN, меньшим ожидаемого, SM выполняет повторную репликацию.
В этом случае объём состояния, если его можно так назвать, может быть достаточно мал, чтобы уместиться в памяти одного Stream Manager. Единственным потребителем и клиентом Stream Layer является Partition Layer, и они устроены так, что не могут использовать более 50 миллионов экстентов и не более 100 000 Stream для одной Storage Stamp (блоки не учитываются, так как могут быть их совершенно бесчисленное количество), что прекрасно вписывается в 32 гигабайта памяти Stream Manager. Узлы экстента (EN).
Каждый EN управляет хранилищем набора реплик экстентов, назначенных ему SM. EN имеет N подключенных дисков, находящихся под его полным контролем, для хранения реплик экстентов и их блоков.
При этом EN ничего не знает о Stream (в отличие от Stream Manager, который ничего не знает о блоках) и управляет только экстентами и блоками, которые (экстенты) по сути являются файлами на дисках, содержащими блоки данных и их контрольные суммы + карту ассоциации.
смещений экстентов соответствующих блоков и их физического расположения.
Каждый EN содержит некоторое представление о его экстентах и о том, где расположены реплики для конкретных экстентов.
Когда ни один поток больше не ссылается на определенные экстенты, диспетчер потоков собирает эти ненужные экстенты и уведомляет EN о необходимости освободить пространство.
В этом случае данные можно добавлять только в Stream; существующие данные не могут быть изменены.
Операции добавления являются атомарными — либо добавляется весь блок данных, либо ничего не добавляется.
Несколько блоков могут быть добавлены в один момент времени в рамках одной атомарной операции «добавление нескольких блоков».
Минимальный размер, который можно прочитать из потока, составляет один блок.
Операция добавления нескольких блоков позволяет клиенту записывать большие объемы последовательных данных за одну операцию.
Как уже упоминалось, каждый экстент имеет определенный потолок размера, и когда он заполнен, экстент запечатывается, и в новом экстенте выполняются дальнейшие записи.
Никакие данные не могут быть добавлены в запечатанный экстент, и он является неизменяемым.
Существует несколько правил относительно экстентов: 1. После добавления записи и подтверждения операции клиенту все дальнейшие операции чтения этой записи из любой реплики должны возвращать одни и те же данные (данные неизменяемы).
2. После запечатывания экстента все операции чтения из любой запечатанной реплики должны возвращать одно и то же содержимое экстента.
Например, при создании Потока SM назначает первому экстенту три реплики (одну первичную и две вторичные) для трех Узлов Экстента, которые, в свою очередь, выбираются SM для случайного распределения между разными доменами обновлений и ошибок и принятия учитывать возможность балансировки нагрузки.
Кроме того, SM решает, какая реплика будет Primary для экстента, и все операции записи в экстент выполняются сначала на первичном EN, и только после этого первичный EN записывается на два вторичных EN. Первичный EN и расположение трех реплик не меняются в зависимости от экстента.
Когда SM выделяет экстент, информация о экстенте отправляется обратно клиенту, который затем знает, какие EN содержат три реплики и какая из них является основной.
Эта информация становится частью метаданных Stream и кэшируется на клиенте.
Когда последний экстент в потоке запечатывается, процесс повторяется.
SM выделяет еще один экстент, который теперь становится последним экстентом в потоке, и все новые записи происходят в новом последнем экстенте.
Для экстента каждая операция добавления реплицируется три раза во всех репликах экстента, и клиент отправляет все запросы на запись в основной EN, но операции чтения можно выполнять из любой реплики, даже для незапечатанных экстентов.
Операция добавления отправляется на основной EN, а основной EN отвечает за определение смещения в экстенте, а также упорядочивание всех записей в случае, если есть параллельные записи в один экстент, отправку операции добавления с необходимым смещением.
на два вторичных EN и отправку клиенту подтверждения операции, которое отправляется только в том случае, если операция добавления была подтверждена на всех трех репликах.
Если одна из реплик не отвечает или произошла (или произошла) какая-то аппаратная ошибка, клиенту возвращается ошибка записи.
В этом случае клиент связывается с SM, и степень, в которой произошла операция записи, фиксируется SM. Затем SM выделяет новый экстент с репликами на других доступных EN и помечает этот экстент как последний в потоке, и эта информация возвращается клиенту, который продолжает выполнять операции добавления к новому экстенту.
Стоит отметить, что вся последовательность действий по запечатыванию и выделению нового экстента занимает в среднем всего 20 миллисекунд. Что касается самого процесса герметизации.
Чтобы запечатать экстент, SM запрашивает у всех трех EN их текущую длину.
В процессе запечатывания возможны два сценария: либо все реплики имеют одинаковый размер, либо некоторые реплики длиннее или короче других.
Вторая ситуация возникает только при сбое операции добавления, когда некоторые EN (но не все) были недоступны.
При запечатывании экстента SM выбирает самую короткую длину на основе доступных EN. Это позволяет запечатать экстенты, чтобы все изменения, переданные клиенту, были запечатаны.
После запечатывания проверенная длина экстента больше не меняется, и, если SM не может связаться с EN во время запечатывания, но затем EN становится доступным, SM заставляет этот EN синхронизироваться с проверенной длиной, что приводит к идентичному набору битов.
Однако здесь может возникнуть и другая ситуация — SM не может общаться с EN, а Partition Server, являющийся клиентом, может. Partition Layer, о котором чуть позже, имеет два режима чтения — чтение записей в известных позициях и использование перебора всех записей в потоке.
Что касается первого, то уровень разделов использует два типа потока — запись и блоб.
Для этих потоков операции чтения всегда происходят в определенных позициях (экстент+смещение, длина).
Уровень раздела выполняет операции чтения для этих двух типов, используя информацию о положении, возвращенную из предыдущей успешной операции добавления на потоковый уровень, что происходит только тогда, когда все три реплики сообщили об успешной операции добавления.
Во втором случае, когда все записи в потоке повторяются последовательно, каждый раздел имеет два отдельных потока (метаданные и журнал подтверждений), которые уровень разделов будет читать последовательно от начала до конца.
В хранилище Windows Azure введен механизм, позволяющий экономить используемое дисковое пространство и трафик без снижения уровня доступности данных, и он называется кодами стирания.
Суть этого механизма заключается в том, что экстент разбивается на N фрагментов примерно равного размера (на практике это опять-таки файлы), после чего добавляются M фрагментов кодов, исправляющих ошибки, с помощью алгоритма Рида-Соломона.
Что это значит? Любые X из N фрагментов равны по размеру исходному файлу; чтобы восстановить исходный файл, достаточно собрать Х любых фрагментов и расшифровать их; оставшиеся фрагменты N-X можно удалить, повредить и так далее.
Пока в системе хранится более M фрагментов кода, исправляющего ошибки, система может полностью восстановить исходный экстент. Такая оптимизация запечатанных экстентов очень важна для гигантских объемов данных, хранящихся в облачных хранилищах, поскольку позволяет снизить стоимость хранения данных с трех полных реплик исходных данных до 1,3-1,5 исходных данных в зависимости от количества фрагментов.
используется, а также позволяет повысить «стабильность» данных по сравнению с хранением трёх реплик внутри Storage Stamp. При выполнении операций записи в экстенте, имеющем три реплики, выполнение всех операций запланировано на определенное время, и если операция не завершится в течение этого времени, ее не следует выполнять.
Если EN определяет, что операция чтения не может быть полностью завершена в течение определенного времени, она немедленно сообщает об этом клиенту.
Этот механизм позволяет клиенту запросить операцию чтения из другого EN. Аналогично с данными, для которых используется стирающее кодирование — когда операция чтения не успевает завершиться за определенный период времени из-за большой нагрузки, эта операция может не использоваться для чтения полного фрагмента данных, но может воспользоваться преимуществами возможность восстановления данных, при этом операция чтения относится ко всем фрагментам экстента с кодом стирания, а первые N ответов будут использованы для восстановления необходимого фрагмента.
Учитывая, что система WAS может обслуживать очень большие потоки, может возникнуть следующая ситуация: некоторые физические диски обслуживаются и блокируются для обслуживания больших операций чтения или записи, что начинает снижать пропускную способность для других операций.
Чтобы предотвратить эту ситуацию, WAS не назначает новые операции ввода-вывода диску, если ему уже назначены операции, выполнение которых может занять более 100 миллисекунд, или когда уже назначенные операции были назначены, но не были завершены в течение 200 миллисекунд. Когда уровень потока определяет данные как доступные для записи, дополнительный полный диск или твердотельный накопитель используется в качестве хранилища для регистрации всех записей в EN. Диск журналирования полностью отведен под один журнал, в который последовательно записываются все операции записи.
Когда каждый EN выполняет операцию добавления, он записывает все данные на диск журнала и начинает запись данных на диск.
Если диск журнала раньше возвращает код успеха, данные будут буферизованы в памяти, и до тех пор, пока все данные не будут записаны на диск данных, все операции чтения будут обслуживаться из памяти.
Использование диска журналирования дает важные преимущества, поскольку, например, операции добавления не должны конкурировать с операциями чтения с дисков данных для проверки операции для клиента.
Журнал позволяет операциям добавления с помощью Partition Layer быть более согласованными и иметь меньшую задержку.
Уровень раздела (PL).
Этот уровень содержит специальные серверы разделов (процессы-демоны) и предназначен для управления самими абстракциями хранения (блобы, таблицы, очереди), пространством имен, порядком транзакций, строгой согласованностью объектов, хранением данных на SL и кэшированием данных для уменьшения количества операций ввода-вывода.
O операции с диском.
PL также участвуют в секционировании объектов данных внутри SS по PartitionName и дальнейшей балансировке нагрузки между серверами разделов.
Уровень разделов предоставляет внутреннюю структуру данных, называемую таблицей объектов (OT), которая представляет собой большую таблицу, размер которой может достигать нескольких петабайт. В зависимости от нагрузки OT динамически делится на RangePartitions и распределяется по всем серверам разделов внутри Storage Stamp. RangePartition — это диапазон записей в OT, начиная с предоставленного наименьшего ключа до наибольшего ключа.
Существует несколько типов ОТ: • В таблице учетных записей хранятся метаданные и конфигурация для каждой учетной записи хранения, связанной со штампом хранения.
• В таблице больших двоичных объектов хранятся все объекты больших двоичных объектов для всех учетных записей, связанных со штампом хранения.
• Таблица сущностей хранит все записи сущностей для всех учетных записей хранения, связанных со штампом хранения, и используется для службы хранения таблиц Windows Azure. • В таблице сообщений хранятся все сообщения для всех очередей для всех учетных записей хранения, связанных со штампом хранения.
• Таблица схем отслеживает схемы для всех OT. • Таблица карты разделов отслеживает все текущие RangePartitions для всех таблиц объектов и то, какие серверы разделов обслуживают какие RangePartitions. Эта таблица используется серверами FE для перенаправления запросов на необходимый сервер разделов.
Все типы таблиц имеют фиксированные схемы, которые хранятся в таблице схем.
Для всех схем ОТ существует стандартный набор типов свойств — bool,binary,string,DateTime,double,GUID,int32 и int64, кроме того, система поддерживает два специальных свойства DictionaryType и BlobType, первое из которых позволяет добавлять свойства без конкретной схемы в виде записи.
Эти свойства хранятся внутри типа словаря в форме (имя, тип, значение).
Второе специальное свойство используется для хранения больших объемов данных и на данный момент используется только для Blob Table, при этом данные blob хранятся не в общем потоке записей, а в отдельном потоке для данных blob; по сути, сохраняется только ссылка на данные BLOB-объекта (список ссылок «экстент+сдвиг, длина»).
OT поддерживает стандартные операции — вставку, обновление, удаление и чтение, а также пакетные транзакции для записей с одним значением PartitionName. Транзакции в одном пакете подтверждаются как одна транзакция.
OT также поддерживают режим изоляции моментальных снимков, позволяющий операциям чтения выполняться параллельно с записью.
Архитектура уровня раздела
Рис.
4. Уровень раздела архитектуры и рабочего процесса Менеджер разделов (PM) отслеживает и разделяет большие OT на N RangePartitions в пределах Storage Stamp и назначает RangePartitions конкретным серверам разделов.
Информация о том, что и где хранится в Таблице карты разделов.
Один RangePartition назначается одному активному серверу разделов, что гарантирует, что два RangePartition не перекрываются.
Каждая отметка хранения имеет несколько экземпляров PM, и все они конкурируют за один замок лидера, хранящийся в службе блокировки.
Сервер разделов (PS) обслуживает запросы к RangePartitions, назначенным этому серверу PM, сохраняет все состояние разделов в потоках и управляет кешем в памяти.
PS способен обслуживать несколько RangePartitions из нескольких OT, в среднем до дюжины.
PS поддерживает следующие компоненты, сохраняя их в памяти: • Таблица памяти , версия журнала фиксации для RangePartition, содержащая все последние изменения, которые еще не были отмечены контрольными точками.
• Индексный кэш , кэш, содержащий позиции контрольных точек потока данных записей.
• Кэш данных строк , кэш в памяти для страниц данных записей контрольных точек.
Этот кэш доступен только для чтения.
При доступе к кэшу проверяются кэш данных строк и таблица памяти, отдавая предпочтение последнему.
• Фильтры Блума – если данные не найдены в Row Data Cache и Memory Table, то проверяются позиции и контрольные точки в потоке данных, и перебор будет неэффективен, поэтому для каждой контрольной точки используются специальные фильтры Блума, которые указывают, можно ли получить доступ к записям контрольных точек.
Сервис блокировки используется для выбора обслуживающего премьер-министра.
Каждый PS также управляет договором аренды с Lock Service для обслуживания разделов.
В случае сбоя PS все N RangePartitions, которые обслуживали этот PS, переназначаются доступному PS. PM выбирает N PS в зависимости от их рабочей нагрузки, затем назначает RangePartitions PS и обновляет таблицу карты разделов соответствующими данными, позволяя интерфейсному уровню найти расположение RangePartitions путем доступа к таблице карты разделов.
RangePartition использует лог-структурированное дерево слияния для сохранения данных.
Каждый RangePartition состоит из собственного набора потоков на уровне потока, и поток полностью принадлежит определенному RangePartition. Каждый RangePartition может состоять из одного из следующих потоков: • Поток метаданных – этот поток является основным для RangePartition. PM назначает PS разделу, предоставляя имя потока метаданных этого PS. • Поток журнала фиксации – этот поток предназначен для хранения журналов подтвержденных операций вставки, обновления и удаления, примененных к RangePartitions с момента последней точки, созданной для RangePartition. • Поток данных строки хранит данные записи и позицию для RangePartitions • Поток данных BLOB-объектов используется только для таблицы больших двоичных объектов для сохранения данных больших двоичных объектов.
Все перечисленные потоки являются разными потоками на уровне потока, управляемом OT RangePartition. Каждый RangePartition в OT имеет только один поток данных, за исключением таблицы больших двоичных объектов.
RangePartition в таблице больших двоичных объектов имеет поток данных записи для хранения данных последней контрольной точки для записи (положение большого двоичного объекта) и отдельный поток данных большого двоичного объекта для хранения данных для специального типа BlobType.
Балансировка нагрузки RangePartitions
Чтобы выполнить балансировку нагрузки между серверами разделов и определить общее количество разделов в Storage Stamp, PM выполняет три операции: • Балансировка нагрузки.Эта операция определяет, когда конкретный PS испытывает слишком большую нагрузку, а затем переназначает один или несколько RangePartitions менее загруженным PS. • Расколоть.
Эта операция определяет, когда определенный RangePartition испытывает слишком большую нагрузку, и разбивает этот RangePartition на два или более меньших раздела, после чего эти RangePartition распределяются по двум или более PS. PM отправляет команду Split, но решает, где будет разделен раздел PS, на основе AccountName и PartitionName. В этом случае, например, чтобы разделить RangePartition B на два RangePartition C и D, выполняются следующие операции: o PM отправляет команду PS разделить B на C и D. o PS блокирует пропускные пункты B и прекращает прием трафика.
o PS выполняет специальную команду MultiModify, собирая Потоки из B (метаданные, журналы подтверждений и данные) и создает новые наборы Потоков для C и D в том же порядке, что и в B (это происходит быстро, поскольку по сути только указатели на данные).
Затем PS добавляет в метаданные новые диапазоны ключей раздела для C и D. o PS возобновляет обслуживание трафика для новых разделов C и D. o PS уведомляет PM о том, что разделение выполняется, обновляет таблицу карты разделов и метаданные, затем передает разделенные разделы на разные PS. • Слияние.
С помощью этой операции два «холодных» или слегка загруженных RangePartition объединяются для формирования ключевого диапазона в их OT. Для этого PM выбирает два RangePartitions со смежными диапазонами PartitionName, имеющими низкую нагрузку, и выполняет следующую последовательность действий: o PM перемещает C и D так, чтобы они обслуживались одним PS, и дает указание PS объединить C и D в E. o PS сохраняет контрольную точку для C и D и на короткое время прекращает обслуживание трафика для C и D. o PS выполняет команду MultiModify для создания нового журнала подтверждений и потоков данных E. Каждый из этих потоков представляет собой объединение всех экстентов из соответствующих потоков из C и D. o PS создает поток метаданных E, содержащий имена журнала подтверждений и потока данных, объединенный диапазон ключей для E и указатели (экстент + смещение) для журнала подтверждений (из C и D).
o Начинается обслуживание трафика для RangePartition E. o PM обновляет таблицу карты разделов и метаданные.
Для балансировки нагрузки отслеживаются следующие метрики: • Количество транзакций в секунду.
• Среднее количество ожидающих транзакции.
• Загрузка процессора.
• Сетевая нагрузка.
• Запросить задержку.
• Размер данных RangePartition. PM управляет тактовым сигналом каждого PS, и информация об этом передается обратно в PM в ответ на тактовый сигнал.
Если PM видит, что RangePartition находится под слишком большой нагрузкой (на основе метрик), он разбивает раздел и отправляет команду PS для выполнения операции разделения.
Если большую нагрузку испытывает сам PS, но не RangePartition, то PM переназначает доступные для этого PS RangePartitions менее загруженным PS. Чтобы сбалансировать нагрузку на RangePartition, PM отправляет команду PS, которая имеет RangePartition, для записи текущей контрольной точки, после чего PS отправляет подтверждение PM, а PM переопределяет RangePartition на другой PS и обновляет карту разделов.
Стол.
Решение выбрать механизм секционирования на основе диапазона (на котором работают RangePartitions), а не индексирование на основе хэша (когда объекты назначаются серверу по их ключевым значениям хеш-функции) было основано на том факте, что секционирование на основе диапазона облегчает реализовать изоляцию производительности, поскольку объекты, специфичные для учетной записи, хранятся рядом в наборе RangePartitions, индексирование на основе хеша упрощает задачу балансировки нагрузки на серверы, но в то же время лишает преимуществ локальности объектов в целях изоляции и эффективности перечисление.
Секционирование на основе диапазона позволяет хранить объекты одного клиента вместе в одном наборе секций, что также дает возможность эффективно ограничивать или изолировать потенциально небезопасные учетные записи.
Одним из недостатков этого подхода является масштабирование в сценариях последовательного доступа — например, если клиент записывает все свои данные в самый конец диапазона ключей таблицы, то все записи будут перенаправлены в последний RangePartiti. Теги: #microsoft #windows azure #windows azure Storage #облачные сервисы #облачное хранилище #архитектура системы #Microsoft Azure
-
Почему Персонажи Терпят Неудачу
19 Oct, 24 -
Геймификация В Сфере Оплаты Труда
19 Oct, 24 -
Бизон Для Javascript
19 Oct, 24 -
Несколько Слов О Конвейерах В Fpga
19 Oct, 24 -
11 Декабря, Москва – Alfa Js Meetup
19 Oct, 24
