Перейти к содержимому
Последнее обновление

Привязка Workload Group к Compute Group: изоляция ресурсов между рабочими нагрузками

Зачем привязывать Workload Group к Compute Group​

Doris поддерживает логическое объединение узлов BE в кластере с помощью Compute Group. Такие группы образуют независимые подкластеры, которые изолируют вычислительные ресурсы разных рабочих нагрузок.

В ранних версиях действие Workload Group распространялось на все Compute Group, поэтому разным рабочим нагрузкам приходилось использовать общий набор настроек квот ресурсов. Например:

  • Рабочие нагрузки A и B создали собственные Workload Group, и сумма их квот ресурсов уже достигла 100%.
  • Рабочая нагрузка A больше не могла создать ни одной Workload Group.
  • Требования этих рабочих нагрузок к настройкам Workload Group существенно различались, но прежняя архитектура не позволяла управлять ими независимо для каждой нагрузки.

Для решения этой проблемы в текущей версии появился механизм привязки Workload Group к Compute Group, благодаря которому каждая Compute Group может иметь собственный независимый набор настроек Workload Group.

Связь между Compute Group и Resource Group​

Тип архитектурыСоответствующее понятиеОписание
С разделением хранения и вычисленийCompute GroupЕдиница логического разделения на независимые подкластеры
С совмещением хранения и вычисленийResource GroupФункциональный эквивалент Compute Group

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

Как это работает​

Устройство в ранних версиях​

Предположим, в кластере есть Compute Group A, обслуживающая рабочую нагрузку A, и Compute Group B, обслуживающая рабочую нагрузку B, а также две Workload Group, group_a и group_b, сумма квот ресурсов которых составляет 100%.

В ранних версиях group_a и group_b действовали на всех узлах BE независимо от границ Compute Group, как показано ниже:

Ранние версии: Workload Group действует глобально

Это приводило к следующим последствиям:

  • После создания group_a рабочей нагрузкой A квота ресурсов была полностью исчерпана, и создать дополнительные Workload Group было невозможно.
  • Настройки Workload Group для этих двух рабочих нагрузок влияли друг на друга, затрудняя раздельное управление.

Устройство в текущей версии​

В текущей версии Workload Group можно привязать к определённой Compute Group. Каждая Compute Group имеет собственные независимые настройки Workload Group, как показано ниже:

Текущая версия: изоляция Workload Group по Compute Group

Использование​

Compute Group по умолчанию

В Doris предусмотрен механизм Compute Group по умолчанию: если при добавлении нового узла BE не указана его принадлежность к группе, он автоматически помещается в Compute Group по умолчанию.

Тип архитектурыИмя Compute Group по умолчанию
С разделением хранения и вычисленийdefault_compute_group
С совмещением хранения и вычисленийdefault
предупреждение
Поведение предложения FOR зависит от архитектуры
  • Облачный режим (с разделением хранения и вычислений): операторы CREATE / ALTER / DROP WORKLOAD GROUP обязательно должны явно включать предложение FOR <compute_group>. Если оно отсутствует, возникает ошибка: Must specify compute group via 'FOR <compute_group>' in cloud mode.
  • Необлачный режим (с совмещением хранения и вычислений): предложение FOR <compute_group> необязательно. Указанное в нём значение фактически обозначает группу ресурсов (Tag), а не Compute Group. Общий с облачным режимом синтаксис используется исключительно для единообразия. Если предложение не указано, используется группа ресурсов по умолчанию (default).

Создание Workload Group​

С привязкой к определённой Compute Group:

CREATE WORKLOAD GROUP group_a FOR compute_group_a PROPERTIES ('cpu_share'='1024');

Без указания Compute Group (только в необлачном режиме, с привязкой к группе ресурсов по умолчанию):

CREATE WORKLOAD GROUP group_a PROPERTIES ('cpu_share'='1024');

Удаление Workload Group​

Из определённой Compute Group:

DROP WORKLOAD GROUP group_a FOR compute_group_a;

Без указания Compute Group (только в необлачном режиме, удаление из группы ресурсов по умолчанию):

DROP WORKLOAD GROUP group_a;

Изменение свойств Workload Group​

Изменение свойств Workload Group в определённой Compute Group:

ALTER WORKLOAD GROUP group_a FOR compute_group_a PROPERTIES ('cpu_share'='2048');

Без указания Compute Group (только в необлачном режиме, изменение Workload Group в группе ресурсов по умолчанию):

ALTER WORKLOAD GROUP group_a PROPERTIES ('cpu_share'='2048');
примечание

Оператор ALTER используется только для изменения свойств Workload Group. С его помощью нельзя изменить привязку Workload Group к Compute Group.

Ссылка на Workload Group в Workload Policy​

Поскольку Workload Group принадлежит Compute Group, значение свойства workload_group в операторах CREATE WORKLOAD POLICY / ALTER WORKLOAD POLICY должно соответствовать следующим правилам:

  • Облачный режим (с разделением хранения и вычислений): требуется полностью квалифицированное имя вида <compute_group>.<workload_group>, например:

    CREATE WORKLOAD POLICY p1 CONDITIONS(query_time > 3000) ACTIONS(cancel_query)
    PROPERTIES('workload_group'='compute_group_a.wg1');

  • Необлачный режим (с совмещением хранения и вычислений): допускаются как <workload_group> (группа ресурсов по умолчанию), так и <resource_group>.<workload_group>.

Примечания​

  1. Привязку нельзя изменить: при создании Workload Group закрепляется за определённой Compute Group и не может быть перенесена в другую Compute Group.

  2. Поведение при обновлении: при обновлении с ранней версии до текущей система на основе существующих Workload Group автоматически создаёт для каждой Compute Group новые Workload Group с прежними именами, но другими ID. Например, если в ранней версии были две Compute Group и одна group_a, то после обновления у каждой Compute Group появится собственная новая Workload Group с именем group_a, а исходная group_a, не принадлежавшая ни одной Compute Group, будет автоматически удалена.

  3. Управление привилегиями не меняется: проверка привилегий для Workload Group по-прежнему выполняется по имени Workload Group, а подход к управлению остаётся таким же, как в ранних версиях.

  4. Жизненный цикл Workload Group normal: в Doris есть Workload Group по умолчанию с именем normal. При создании новой Compute Group система автоматически создаёт для неё соответствующую Workload Group normal; при удалении Compute Group связанная с ней Workload Group normal также автоматически удаляется. Жизненный цикл Workload Group normal полностью управляется системой и не требует ручных действий.

Report issue