Поделиться через

Глобальное распределение данных в Azure Cosmos DB — взгляд изнутри

  • Статья

Область применения: Nosql Mongodb Кассандра Гремлин Таблица

Azure Cosmos DB является базовой службой Azure, поэтому она развернута во всех регионах Azure по всему миру, включая общедоступные, национальные облака, облака Министерства обороны (DOD) и государственных организаций.

На высоком уровне данные контейнера Azure Cosmos DB являются горизонтально секционированными на несколько наборов реплик, которые реплицируют операции записи, в каждом регионе. Наборы реплик надежно фиксируют операции записи с помощью кворума большинства.

Каждый регион содержит все секции данных контейнера Azure Cosmos DB и может обслуживать операции чтения, а также обслуживать записи при включенной записи в нескольких регионах. Если ваша учетная запись Azure Cosmos DB распределена по регионам N Azure, будут по крайней мере N x 4 копии всех данных.

В центре обработки данных мы развертываем службу Azure Cosmos DB и управляем ей на больших метках машин, каждая из которых имеет выделенное локальное хранилище. В центре обработки данных Azure Cosmos DB развертывается во многих кластерах, каждый из которых потенциально запускает несколько поколений оборудования. Компьютеры в кластере обычно распределяются между 10–20 доменами сбоя для обеспечения высокой доступности в пределах региона. На следующем рисунке показана топология глобальной системы распространения Azure Cosmos DB:

Топология системы

Глобальное распределение в Azure Cosmos DB готово. В любое время с несколькими щелчками или программным путем с одним вызовом API можно добавить или удалить географические регионы, связанные с базой данных Azure Cosmos DB. База данных Azure Cosmos DB, в свою очередь, состоит из набора контейнеров Azure Cosmos DB. В Azure Cosmos DB контейнеры служат логическими единицами распределения и масштабируемости. Создаваемые коллекции, таблицы и графы —это только контейнеры Azure Cosmos DB. Контейнеры полностью независимы от схем и предоставляют область для запроса. Данные в контейнере Azure Cosmos DB автоматически индексируются при приеме. Автоматическое индексирование позволяет пользователям запрашивать данные без трудностей управления схемами или индексами, особенно в глобально распределенной инфраструктуре.

  • В конкретном регионе данные в контейнере распределяются с помощью ключа секции, который вы предоставляете и с помощью которого прозрачно управляете базовыми секциями ресурсов (локальное распределение).

  • Каждая физическая секция также реплицируется по географическим регионам (глобальное распределение).

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

Как показано на следующем рисунке, данные в контейнере распределяются по двум измерениям — в пределах региона и в разных регионах по всему миру.

физические секции

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

Реплика однозначно принадлежит клиенту Azure Cosmos DB. Каждая реплика размещает экземпляр ядра СУБД Azure Cosmos DB, который управляет ресурсами, а также связанными индексами. Ядро СУБД Azure Cosmos DB работает с системой типов на основе atom-record-sequence (ARS). Ядро не зависит от концепции схемы и размывает границы между значениями структуры и экземпляров записей. Azure Cosmos DB обеспечивает полную гибкость схемы путем автоматического индексирования всего при приеме, что позволяет пользователям запрашивать глобально распределенные данные без необходимости работать с управлением схемами или индексами.

Ядро СУБД Azure Cosmos DB состоит из компонентов, включая реализацию нескольких примитивов координации, языковых сред выполнения, обработчика запросов и подсистемы хранения и индексирования, отвечающих за хранение транзакций и индексирование данных соответственно. Чтобы обеспечить устойчивость и высокую доступность, ядро СУБД сохраняет свои данные и индексы на дисках SSD и реплицирует их среди экземпляров ядра СУБД в наборах реплик соответственно. Большие клиенты соответствуют более высокой шкале пропускной способности и хранения и имеют либо большие реплики, либо большее количество реплик, или и то и другое. Каждый компонент системы полностью асинхронен — ни один поток никогда не блокирует другой, и каждый поток работает кратковременно без каких-либо ненужных переключателей потоков. Ограничение скорости и обратной реакции передаются по всему стеку из контроля допуском на все каналы ввода-вывода. Ядро СУБД Azure Cosmos DB предназначено для использования точного параллелизма и обеспечения высокой пропускной способности при работе в неустраченных объемах системных ресурсов.

Глобальное распределение Azure Cosmos DB зависит от двух ключевых абстракций — реплик и наборов секций. Набор реплик представляет собой модульный блок "Лего" для координации, а набор секций — это динамическое наложение одного или нескольких географически распределенных физических секций. Чтобы понять, как работает глобальное распределение, необходимо понимать эти две ключевые абстракции.

Наборы реплик

Физическая секция, которая материализуется как самоуправляемая и динамически сбалансированная по нагрузке группа реплик, распределенная между несколькими доменами сбоя, называется набором реплик. Этот набор совместно реализует протокол реплицированного состояния машины, чтобы сделать данные в физической секции доступными, устойчивыми и согласованными. Членство в наборе реплик N является динамическим — оно постоянно меняется между NMin и NMax на основе сбоев, административных операций и времени для повторного создания или восстановления неудачных реплик. Исходя из изменений членства, протокол репликации также перенастраивает размер кворумов чтения и записи. Для равномерного распределения пропускной способности, назначенной физической секции, мы используем два принципа.

  • Во-первых, стоимость обработки запросов на запись в лидере выше стоимости применения обновлений на подписчике. Соответственно, лидеру предусмотрено больше системных ресурсов, чем подписчику.

  • Во-вторых, насколько это возможно, кворум чтения для заданного уровня согласованности состоит исключительно из реплик подписчиков. Мы избегаем контакта с лидером для выполнения операций чтения, если этого не требуется. Мы используем ряд идей из исследований, выполненных в связи нагрузки и емкости в системах на основе кворума для пяти моделей согласованности, поддерживаемых Azure Cosmos DB.

Наборы секций

Группа физических секций, одна из каждой из настроенных с помощью регионов базы данных Azure Cosmos DB, состоит для управления одним набором ключей, реплицируемых во всех настроенных регионах. Этот более высокий координационный примитив называется набором секций — географически распределенное динамическое наложение физических секций, управляющих заданным набором ключей. Хотя данная физическая секция (набор реплик) находится в пределах кластера, набор секций может охватывать несколько кластеров, центры обработки данных и географические регионы, как показано на следующем рисунке.

Наборы секций

Набор секций можно считать географически распределенным "супернабором реплик", который состоит из нескольких наборов реплик, обладающих тем же набором ключей. Аналогично набору реплик, членство в наборе секций также является динамическим. Оно изменяется на основе неявных операций управления физическими секциями для добавления и удаления новых секций в заданный набор секций (например, при горизонтальном масштабировании пропускной способности контейнера, добавлении и удалении региона в базу данных Azure Cosmos DB или при возникновении сбоев). Благодаря тому что каждая из секций (набора секций) управляет членством в наборе секций в пределах своего собственного набора реплик, членство является полностью децентрализованным и высокодоступным. Во время перенастройки набора секций также устанавливается топология наложения между физическими секциями. Топология динамически выбирается на основе уровня согласованности, географического расстояния и доступной пропускной способности сети между исходными и целевыми физическими секциями.

Служба позволяет настроить базы данных Azure Cosmos DB с одним регионом записи или несколькими регионами записи, а в зависимости от выбора наборы секций настроены для приема записей в одном или всех регионах. Система использует двухуровневый протокол на основе консенсуса — один уровень работает в репликах набора реплик физической секции, принимая записи, а другой работает на уровне набора секций, чтобы обеспечить полные гарантии упорядочения для всех зафиксированных записей в наборе секций. Этот многоуровневый вложенный консенсус имеет решающее значение для реализации наших строгих соглашений об уровне обслуживания для обеспечения высокой доступности, а также реализации моделей согласованности, которые Azure Cosmos DB предлагает своим клиентам.

Разрешение конфликтов

Наша разработка для распространения обновлений, разрешения конфликтов и отслеживания причин вдохновляется предыдущей работой по алгоритмам эпидемии и системе Bayou. Хотя ядра идей выжили и обеспечивают удобный кадр ссылок для общения системы Azure Cosmos DB, они также прошли значительное преобразование, так как мы применяли их к системе Azure Cosmos DB. Это необходимо, так как предыдущие системы не были разработаны ни с управлением ресурсами, ни с масштабом, с которыми требуется работать Azure Cosmos DB, ни для предоставления возможностей (например, ограниченной согласованности устаревших условий), а также строгих и комплексных соглашений об уровне обслуживания, предоставляемых Azure Cosmos DB своим клиентам.

Помните, что набор секций распределяется по нескольким регионам и следует протоколу репликации Azure Cosmos DB (многорегионные записи), чтобы реплицировать данные между физическими секциями, содержащими заданный набор секций. Каждая физическая секция (из набора секций) принимает записи и обычно служит для чтения клиентам из этого региона. Записи, принятые физической секцией в регионе, надежно зафиксированы и сделаны высокодоступными в пределах физической секции, прежде чем быть подтвержденными для клиента. Эти предварительные записи распространяются на другие физические секции в наборе секций с помощью канала защиты от энтропии. Клиенты могут запрашивать либо предварительные, либо зафиксированные записи путем передачи заголовка запроса. Распространение защиты от энтропии (включая частоту распространения) является динамическим, основанным на топологии набора секций, региональной близости физических секций и настроенном уровне согласованности. В наборе секций Azure Cosmos DB следует основной схеме фиксации с динамически выбранным разделом arbiter. Выбор арбитра динамический. Он является неотъемлемой частью перенастройки набора секций на основе топологии наложения. Заказы зафиксированных записей (включая многострочные или пакетные обновления) гарантируются.

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

Для баз данных Azure Cosmos DB, настроенных с несколькими регионами записи, система предлагает ряд гибких политик автоматического разрешения конфликтов для разработчиков, в том числе:

  • Приоритет последней записи (LWW), при котором по умолчанию используется свойство метки времени, назначенное системой (на основе протокола синхронизации времени). Azure Cosmos DB также позволяет указать любое другое пользовательское числовое свойство, которое будет использоваться для разрешения конфликтов.
  • Определенная приложением политика пользовательского разрешения конфликтов (выраженная через процедуры слияния), которая предназначена для определяемой приложением семантики выверки конфликтов. Эти процедуры вызываются при обнаружении конфликтов "запись — запись" во время обработки транзакции в базе данных на стороне сервера. Система гарантирует только однократное выполнение слияния в рамках протокола обязательств. Вам доступно несколько примеров разрешения конфликтов.

Модели согласованности

Независимо от того, настроена ли база данных Azure Cosmos DB с одним или несколькими регионами записи, можно выбрать из пяти четко определенных моделей согласованности. При использовании поддержки нескольких регионов записи нужно учитывать некоторые важные аспекты уровней согласованности:

Согласованность ограниченного устаревания гарантирует, что все операции чтения будут находиться в пределах K префиксов или T секунд от последней записи в любом из регионов. Кроме того, операции чтения с согласованностью ограниченного устаревания гарантируют монотонность и постоянность префикса. Протокол защиты от энтропии работает с ограничением скорости и гарантирует, что префиксы не накапливаются и обратная реакция при записи не применяется. Согласованность сеанса гарантирует монотонное чтение, монотонную запись, чтение ваших собственных писем, запись после чтения и гарантии постоянного префикса по всему миру. Базы данных с заданной строгой согласованностью лишены преимущества, обеспечиваемого наличием нескольких регионов для записи (малая задержка записи, высокий уровень доступности для записи), вследствие их синхронной репликации в регионах.

Здесь описана семантика пяти моделей согласованности в Azure Cosmos DB и математически описана с помощью высокоуровневых спецификаций TLA+.

Следующие шаги

Дополнительные сведения о том, как настроить политики глобального распределения, можно узнать в приведенных ниже статьях.