Балансировка метрик подкластеров

Что такое подкластеризация

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

Влияние подкластеризации на балансировку нагрузки

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

Например, предположим, что у нас есть четыре службы, и все они сообщают о нагрузке для метрики Метрика1.

  • Служба A имеет ограничение на размещение NodeType==Frontend, сообщает о нагрузке 10
  • Служба B имеет ограничение на размещение NodeType==Frontend, сообщает о нагрузке 10
  • Служба C имеет ограничение на размещение NodeType==Backend, сообщает о нагрузке 100
  • Служба D имеет ограничение на размещение NodeType==Backend, сообщает о нагрузке 100
  • И у нас есть четыре узла. Для двух из них задан параметр NodeType Frontend , а для двух других — Backend.

И у нас есть следующее размещение.

Пример размещения в подкластере

Кластер может выглядеть несбалансированным, у нас большая нагрузка на узлы 3 и 4, но это размещение создает лучший возможный баланс в данной ситуации.

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

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

Типы подкластеризации и их обработка

Ситуации подкластеризации можно классифицировать по трем различным категориям. Категория конкретной ситуации подкластеризации определяет, как она будет обрабатываться Диспетчером ресурсов.

Первая категория — плоская подкластеризация с несвязанными группами узлов

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

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

Вторая категория — подкластеризация с иерархическими группами узлов

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

Пример.

  • Служба A: нет ограничения размещения
  • Служба B: ограничение размещения NodeType==Frontend
  • Служба C: ограничение размещения NodeType==Backend

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

Подмножество подкластеров с надмножествами

В этом случае существует вероятность, что будет выполнена неоптимальная балансировка.

Диспетчер ресурсов распознает эту ситуацию и создает отчет о работоспособности, предлагая разделить службу а на две: службу A1, которую можно разместить на интерфейсных узлах, и службу A2, которую можно разместить на внутренних узлах. В результате мы вернемся к ситуации первой категории, в которой возможно создать оптимальную балансировку.

Третья категория — подкластеризация с частичным перекрытием между наборами узлов

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

Например, если у нас есть свойство узла с именем NodeColor и у нас есть три узла.

  • Узел 1: NodeColor = Red
  • Узел 2: NodeColor = Blue
  • Узел 3: NodeColor=Green

И у нас есть две службы.

  • Служба A: с ограничением размещения Color==Red | | Color==Blue
  • Служба B: с ограничением размещения Color==Red | | Color==Blue

По этой причине служба A может быть размещена на узлах 1 и 2, а служба B может быть размещена на узлах 2 и 3.

В этом случае существует вероятность, что будет выполнена неоптимальная балансировка.

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

В этой ситуации Диспетчер ресурсов не может создать предложение по разделению служб, так как можно выполнить несколько разбиений и определить, какой способ будет оптимальным для разделения служб.

Настройка подкластеризации

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

  • SubclusteringEnabled — параметр определяет, будет ли Диспетчер ресурсов учитывать подкластеризацию при выполнении балансировки нагрузки. Если этот параметр выключен, Диспетчер ресурсов будет игнорировать подкластеризацию и пытаться достичь оптимального баланса на глобальном уровне. Значение параметра по умолчанию — false.
  • SubclusteringReportingPolicy — определяет, как Диспетчер ресурсов будет выдавать отчеты о работоспособности для иерархической подкластеризации и подкластеризации с частичным перекрытием. Нулевое значение означает, что отчеты о работоспособности для подкластеризации отключены, "1" означает, что отчеты о работоспособности будут создаваться для неоптимальных ситуаций подкластеризации, а значение "2" приведет к созданию отчетов о работоспособности со статусом ОК. Значение параметра по умолчанию — "1".

ClusterManifest.xml:

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="SubclusteringEnabled" Value="true" />
            <Parameter Name="SubclusteringReportingPolicy" Value="1" />
        </Section>

Для автономных развертываний используется ClusterConfig.json, а для размещенных в Azure кластеров — Template.json.

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "SubclusteringEnabled",
          "value": "true"
      },
      {
          "name": "SubclusteringReportingPolicy",
          "value": "1"
      },
    ]
  }
]

Дальнейшие действия