Очарование балансировки нагрузки OceanBase

OB июнь: 21 сентября на конференции Yunqi была выпущена версия OceanBase 2.0. Мы продолжим развертывание для вас в следующий раз"Серия технического анализа OceanBase 2.0», углубленный анализ новых функций продукта OceanBase 2.0 и технических принципов, лежащих в его основе, с пяти аспектов: работоспособность, распределенная архитектура, доступность данных, экономичность и совместимость.
Я поделился с вами тремя статьями о работоспособности и ремонтопригодности.Сегодня мы начнем с распределенной архитектуры и поделимся с вами архитектурным опытом реляционных баз данных в балансировке нагрузки. Более увлекательно, обратите внимание на публичный аккаунт OceanBase и продолжайте подписываться на эту серию контента!

Автор этой статьи: Цин Тао

В настоящее время он является экспертом по технической поддержке базы данных OceanBase компании Ant Financial, отвечающим за внешнее техническое продвижение и поддержку базы данных OceanBase. Он поддерживал предприятия B2B, Tmall и Alibaba Cloud и знаком с эксплуатацией и обслуживанием Oracle/SQL Server/MySQL/OceanBase, а также с проектированием архитектурных решений, связанных с базами данных.

введение

С ростом популярности интернет-сервисов хранение больших объемов данных и доступ к ним стали распространенной проблемой при проектировании архитектуры приложений. Как база данных может поддерживать стабильность и масштабируемость, когда приложение запрашивает миллионы и десятки миллионов в часы пик? Предпочтительным методом является разделение данных в сочетании с балансировкой нагрузки. В этой статье обобщается архитектурный опыт реляционной базы данных в балансировке нагрузки, а затем рассказывается об уникальном очаровании балансировки нагрузки распределенной базы данных OceanBase.

Традиционное понимание балансировки нагрузки

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

В соответствии с этим принципом схема балансировки нагрузки может работать на втором уровне (MAC-уровень канала передачи данных), третьем уровне (IP-сетевой уровень), четвертом уровне (транспортный уровень TCP) и седьмом уровне (прикладной уровень) OSI. семислойная модель. Чем выше уровень, тем сложнее принцип, тем умнее и гибче конструкция.

На рынке есть два типа продуктов для балансировки нагрузки.Один из них — аппаратная реализация.: Есть независимое оборудование типа F5, а также интегрированное в сетевое оборудование.Другой - программное обеспечение, установленный на центральном сервере. Такие как LVS, HAProxy, Keepalive, DNS LoadBalance и т. д. Преимуществами программного решения являются простота настройки, гибкая работа и низкая стоимость; недостатком является то, что оно зависит от системы, имеет дополнительные накладные расходы на ресурсы и не очень безопасно и стабильно. Преимущество аппаратного решения в том, что оно не зависит от системы, с хорошей производительностью и множеством стратегий, недостаток в том, что оно дорогое.

Существуют различные алгоритмы переадресации запросов, такие как Round Robin (RR), взвешенный круглый робин, случайный, случайный вес, время отклика, минимальное количество соединений, баланс DNS и т. Д., Которые можно выбрать в соответствии с фактическими сценариями.

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

Проект балансировки нагрузки централизованной реляционной базы данных

1. Кластерная база данных

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

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

[Рис. 1] Архитектура ORACLE RAC

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

2. Промежуточное ПО распределенной базы данных

С развитием технологии промежуточного программного обеспечения появился тип распределенного кластера MySQL. Принцип состоит в том, чтобы разделить данные на несколько экземпляров MySQL по горизонтали, а затем развернуть набор кластеров промежуточного программного обеспечения перед MySQL для ответа на клиентские SQL-запросы. Это промежуточное ПО имеет логику для синтаксического анализа SQL, расчета маршрутизации и агрегации данных, оно является распределенным и не имеет состояния. На переднем конце промежуточного ПО клиентские запросы принимаются через продукт балансировки нагрузки (например, SLB или LVS и другие подобные продукты) и распределяются по каждому узлу промежуточного ПО.

[Рисунок 2] Архитектура промежуточного программного обеспечения распределенной базы данных

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

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

Проект балансировки нагрузки распределенной базы данных

Компания Google опубликовала документ об архитектуре, эксплуатации и обслуживании продуктов Spanner & F1, возглавив разработку технологии NewSQL, которая представляет собой технологию распределенных баз данных. Это настоящая распределенная архитектура базы данных. В этой архитектуре данные представляют собой срез, хранящийся на множестве узлов, и их можно свободно перемещать с помощью внешнего инструмента между множеством узлов.

[Рис. 3] Архитектура Google F1

Узел Google F1 не имеет состояния. Запросы клиентов распределяются по нагрузке на узел F1. F1 не хранит данные и запрашивает данные у Spanner. Если F1 добавит машину, она автоматически выполнит балансировку нагрузки шардов. Логика балансировки нагрузки распределенной базы данных, описанная Google, должна быть целью проектирования архитектуры распределенной базы данных.

В 2010 году Alibaba и Ant Financial начали независимую разработку распределенной реляционной базы данных OceanBase.Что касается дизайна балансировки нагрузки, OceanBase не только реализует автоматическую балансировку нагрузки между узлами после добавления и уменьшения узлов и автоматически перераспределяет хранилище данных, но и дополнительно поддерживает требования балансировки нагрузки в различных бизнес-сценариях.

Дизайн балансировки нагрузки OceanBase 2.0

1. Архитектура OceanBase

Прежде чем рассматривать структуру балансировки нагрузки OceanBase, давайте рассмотрим архитектуру OceanBase 1.0. В версии 1.x процесс-наблюдатель включает в себя как вычислительные функции, так и функции хранения. Статус каждого узла одинаков (три узла с корневым сервисом главной службы управления немного особенные), данные каждого узла в каждой зоне являются частью полных данных, и каждые данные находятся в нескольких других зонах. обычно не менее трех порций. Таким образом, согласно архитектурной схеме вычисления и хранение OceanBase распределены. Отличие от Google в том, что в версии 1.x вычисления и хранилище не были разделены. Но не влияет на функцию распределенной базы данных.

[Рисунок 4] Архитектура OceanBase 1.x

2. Разделы, реплики и OBProxy

Минимальная степень детализации распределения данных в OceanBase — это разделение.Раздел — это раздел или вторичный раздел многораздельной таблицы, или сама неразделенная таблица — это раздел. Принцип балансировки нагрузки OceanBase связан с разделением. Каждый раздел (раздел) будет иметь как минимум три копии данных во всем кластере, что обычно называют тремя копиями (реплика). Три роли реплик: 1 ведущая реплика и 2 ведомые реплики. Обычно для чтения и записи по умолчанию используется ведущая реплика. На серверную комнату (зону), в которой реплики лидеров распределяются по умолчанию, влияет атрибут основной зоны по умолчанию и атрибут локальности таблицы. В удаленной многоактивной архитектуре роль этого атрибута локальности используется полностью.

Поскольку место распространения копии Leader является внутренней информацией OceanBase и прозрачно для клиента, для клиентских запросов требуется обратный прокси-сервер OBProxy. Этот OBProxy имеет только функцию маршрутизации и отправляет SQL-запросы только на тот узел, где находится ведущая копия таблицы. В отличие от HAProxy, он не имеет балансировки нагрузки и не нуждается в ней. Однако OBProxy не имеет состояния, вы можете развернуть несколько, а затем добавить перед ним продукт балансировки нагрузки для собственной балансировки нагрузки и высокой доступности OBProxy.

[Рисунок 5] Раздел OceanBase, OBProxy

3. Метрики балансировки нагрузки

Статус каждого узла (OBServer) OceanBase одинаков (роль узла, на котором находится корневой сервис главного управляющего сервиса, несколько особенная). версии 2.x) разделение вычислений и хранения). OceanBase будет поддерживать максимально сбалансированное использование ресурсов и загрузку каждого узла. Этот эффект заключается в том, что когда в большом кластере OceanBase работает несколько арендаторов с разными спецификациями ресурсов, OceanBase будет избегать некоторых узлов с высоким использованием ресурсов и некоторых узлов без доступа или с низким использованием ресурсов и т. д. Эта метрика относительно сложна и все еще находится в стадии постоянного изучения и улучшения. Поэтому в настоящее время нет определенной простой формулы, которую можно было бы описать напрямую. Но можно сказать, что это будет связано со следующими факторами:

• пространство: общее используемое пространство Раздела на каждом узле и доля его квоты; общее пространство Единицы каждого арендатора на этом узле и доля занимаемой им квоты.
• ОЗУ: Выделенная память в OB-памяти каждого узла и доля занимаемой им квоты
• CPU: общий выделенный ЦП модуля в каждом узле и доля его общей занимаемой квоты.
• разное: максимальное количество подключений, IOPS и т. д. Эти спецификации в настоящее время определены, но еще не используются для стратегий балансировки.
• Количество групп разделов (PartitionGroup): количество групп разделов в каждом узле. Разделы с одинаковыми номерами одной и той же группы таблиц являются группой разделов. Если таблица A и таблица B являются таблицами разделов и метод разделения одинаков, то их раздел № 0 является группой разделов, а их раздел № 1 — группой разделов. И так далее.

4. Эволюция логики балансировки нагрузки

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

В распределенных условиях задержка запросов между узлами снижает производительность. Особенно, когда кластер развернут в нескольких компьютерных залах. Следовательно, неконтролируемая балансировка нагрузки — это не очень хорошо для бизнеса. На бизнес-уровне некоторые таблицы имеют бизнес-связи, при чтении соответствующий Partition предпочтительно должен находиться внутри узла. Кроме того, архитектура OceanBase также поддерживает функции мультиарендности. Хранилище данных под разными арендаторами будет выделено в одном или нескольких Единицах. Разделы — это не случайные бесплатные раздачи. Для бизнеса очень важно иметь возможность контролировать стратегию балансировки нагрузки. Это упрощает проектирование общей архитектуры приложения, чтобы поддерживать соответствие правил распределения трафика приложений верхнего уровня с базовыми правилами разделения данных, что является предпосылкой для многозадачности в разных местах, а также определяет границы возможностей балансировки нагрузки.

Поэтому распространение Разделов фактически ограничено несколькими правилами. Во-первых, все разделы каждого арендатора входят в одну или несколько групп модулей. Миграция раздела не может выходить за рамки раздела. В кластере OceanBase много арендаторов, а также много модулей. Сначала OceanBase регулирует распределение юнитов между узлами. Это называется «единичное равновесие». Просто конкретный процесс миграции юнитов по-прежнему раздел за разделом. Во-вторых, разделы одной и той же группы разделов должны находиться на одном узле. Окончательное состояние миграции разделов заключается в том, что разделы одной и той же PartitionGroup должны находиться в одном и том же узле OBServer.

[6] арендаторы, Unit, PartitionGroup и Partition

На первый взгляд, стратегия балансировки нагрузки фактически добавляет правила к поведению раздела и устанавливает границы. По мере увеличения масштаба бизнеса бизнес будет разделять общие данные на несколько арендаторов по модулям. Поэтому некоторые данные между арендаторами связаны на бизнес-уровне. Это концепция группы арендаторов (TenantGroup). При балансировке нагрузки будет учитываться, что Раздел в Единице под арендатором одной и той же TenantGroup будет выделен на том же узле. Цель этого состоит в том, чтобы избежать возникновения нескольких вызовов базы данных в компьютерном зале, применяя бизнес-логику.

Наконец, резюмируя, цель различных стратегий балансировки нагрузки OceanBase — максимально сбалансировать использование ресурсов и контролировать его влияние на производительность в определенном диапазоне. По мере расширения масштабов бизнеса и более глубокого использования политики и правила балансировки нагрузки будут улучшаться.

5. Риски и методы балансировки нагрузки

Эффект балансировки нагрузки может быть неодинаков в разных бизнес-сценариях. Необходим также конкретный анализ конкретных вопросов.

Если структура кластера часто изменяется, например, при частой смене компьютеров, добавлении и удалении или добавлении и удалении арендаторов, могут выполняться частые операции балансировки нагрузки. Этот внутренний процесс переноса данных будет занимать определенные ресурсы ЦП и ввода-вывода узла. Могут быть затронуты некоторые предприятия, которые очень чувствительны к производительности базы данных. Следовательно, необходимо, чтобы эксплуатационный и обслуживающий персонал правильно использовал некоторые жесткие правила и ограничения балансировки нагрузки. Например, задав свойства локальности арендаторов и таблиц, ведущий раздел ограничивается несколькими допустимыми зонами. Другой пример — установить одинаковые ограничения группировки таблиц для таблиц с тесно связанными предприятиями. Если вы принимаете эти меры и часто обнаруживаете, что операция балансировки оказывает влияние, вы также можете отключить операцию автоматической балансировки нагрузки. Распределение всех Единиц и Разделов может быть задано командами, то есть ручной балансировкой.

6. Разделение вычислений и хранения

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

Суммировать

Балансировка нагрузки OceanBase заключается в косвенном изменении запрошенного объема каждого узла OBServer путем корректировки распределения внутренних разделов данных, тем самым изменяя нагрузку каждого узла. Миграция данных в процессе настройки выполняется внутренне асинхронно, без использования внешних инструментов синхронизации и без вмешательства администратора баз данных. В течение этого периода всегда действует механизм высокой доступности, и его влияние на операции чтения и записи можно контролировать.

Балансировка нагрузки OceanBase ограничивается определенными политиками, чтобы избежать значительного влияния на производительность приложений. Неограниченная балансировка нагрузки может не стоить затрат для бизнеса.

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

следующее уведомление

Эта статья является четвертой в серии "Технический анализ OceanBase 2.0", следующая статья будет для вас.Всесторонний анализ глобально согласованной функции моментальных снимков OceanBase 2.0. Следите за обновлениями!