Балансировка кластера Service Fabric

Диспетчер кластерных ресурсов Service Fabric поддерживает динамическое изменение нагрузки, реагируя на добавление и удаление узлов или служб. Он также автоматически исправляет нарушения ограничений и упреждающе перераспределяет нагрузку в кластере. Но как часто выполняются эти действия и что их инициирует?

Существует три различных категории работы, которые выполняет диспетчер кластерных ресурсов:

• Размещение: на этом этапе происходит размещение отсутствующих метрик с отслеживанием состояния или без. Размещаются как новые службы, так и реплики с отслеживанием состояния или экземпляры без отслеживания состояния, которые вызвали сбой. Тут выполняется удаление реплик и экземпляров.
• Проверка ограничений: на этом этапе проверяются и устраняются нарушения различных ограничений (правил) размещения в системе. Примерами правил являются такие вещи, как обеспечение того, чтобы узлы не были переполнены емкостью и что выполняются ограничения размещения службы.
• Балансировка — этот этап проверяет, требуется ли перебалансирование на основе настроенного уровня баланса для разных метрик. Если это необходимо, предпринимается попытка найти более сбалансированную схему упорядочения в кластере.

Настройка таймеров диспетчера кластерных ресурсов

Первый набор элементов управления балансировкой — это набор таймеров. Они определяют, как часто диспетчер кластерных ресурсов проверяет состояние кластера и выполняет корректирующие действия.

Каждым из типов исправлений, которые может внести Cluster Resource Manager, управляет соответствующий таймер, который определяет частоту их применения. При каждом срабатывании таймера задача добавляется в расписание. По умолчанию диспетчер ресурсов:

• проверяет состояние и применяет обновления (например, записывает, что узел не работает) каждые 1/10 секунды;
• каждую секунду устанавливает флаг проверки размещения;
• каждую секунду устанавливает флаг проверки ограничений;
• каждые пять секунд устанавливает флаг распределения нагрузки.

Ниже приведены примеры конфигураций, устанавливающих эти таймеры.

ClusterManifest.xml:

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PLBRefreshGap" Value="0.1" />
            <Parameter Name="MinPlacementInterval" Value="1.0" />
            <Parameter Name="MinConstraintCheckInterval" Value="1.0" />
            <Parameter Name="MinLoadBalancingInterval" Value="5.0" />
        </Section>

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

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PLBRefreshGap",
          "value": "0.10"
      },
      {
          "name": "MinPlacementInterval",
          "value": "1.0"
      },
      {
          "name": "MinConstraintCheckInterval",
          "value": "1.0"
      },
      {
          "name": "MinLoadBalancingInterval",
          "value": "5.0"
      }
    ]
  }
]

На сегодняшний день диспетчер кластерных ресурсов выполняет эти действия только по очереди. Именно поэтому мы называем таймеры минимальными интервалами, а действия, которые выполняются при срабатывании таймеров, — флагами параметров. Например, Cluster Resource Manager обрабатывает ожидающие запросы, чтобы создать службы перед балансировкой кластера. Как можно видеть, заданные интервалы времени по умолчанию означают, что диспетчер кластерных ресурсов часто проверяет, какие задачи ему необходимо выполнять. Обычно это означает, что набор изменений, вносимых на каждом шаге, мал. Небольшие частые изменения позволяют диспетчеру кластерных ресурсов реагировать на события в кластере. Таймеры по умолчанию обеспечивают своего рода пакетную обработку, поскольку обычно множество событий одного типа происходят одновременно.

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

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

Пороговые значения балансировки

Пороговое значение балансировки — это основной элемент управления для запуска перераспределения нагрузки. Пороговое значение балансировки для метрики представляет собой коэффициент. Если нагрузка для метрики на наиболее загруженном узле, деленная на объем нагрузки на наименее загруженном узле, превышает пороговое значение балансировки, то кластер считается несбалансированным. В результате балансировка запускается при очередной проверке службой Cluster Resource Manager. Таймер MinLoadBalancingInterval задает частоту, с которой диспетчер кластерных ресурсов проверяет необходимость перераспределения нагрузки. Проверка не означает, что что-то действительно произойдет.

Пороговые значения балансировки задаются в определении кластера на основе метрик. Дополнительные сведения о метриках см. в статье о метриках.

ClusterManifest.xml

    <Section Name="MetricBalancingThresholds">
      <Parameter Name="MetricName1" Value="2"/>
      <Parameter Name="MetricName2" Value="3.5"/>
    </Section>

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

"fabricSettings": [
  {
    "name": "MetricBalancingThresholds",
    "parameters": [
      {
          "name": "MetricName1",
          "value": "2"
      },
      {
          "name": "MetricName2",
          "value": "3.5"
      }
    ]
  }
]

В этом примере каждая служба использует одну единицу определенной метрики. В верхнем примере максимальная нагрузка на узле составляет пять, а минимальная — два. Предположим, что пороговое значение балансировки для метрики — три. Так как коэффициент для кластера 5/2 = 2,5, что меньше указанного порогового значения балансировки, равного трем, кластер сбалансирован. При очередной проверке службой Cluster Resource Manager балансировка не запускается.

В примере ниже максимальная нагрузка на узле составляет десять, а минимальная — два (значит, коэффициент будет равен пяти). Пять больше установленного порогового значения балансировки для этой метрики, равного трем. В результате при следующем срабатывании таймера будет запланирован запуск перераспределения кластера. В такой ситуации некоторые нагрузки обычно распределяются по узлам 3. Так как Диспетчер кластерных ресурсов Service Fabric не использует жадный подход, некоторые нагрузки также могут быть распределены по node 2.

Примечание.

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

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

пороговые значения активности

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

Предположим, что для этой метрики задано пороговое значение балансировки, равное 3. Также предположим, что пороговое значение активности равно 1536. В первом случае согласно пороговому значению балансировки кластер несбалансирован, однако ни один из узлов не превышает пороговое значение активности, поэтому ничего не происходит. В нижнем примере узел 1 превышает пороговое значение действия. Так как для метрики превышены пороговые значения балансировки и активности, планируется балансировка. Например, рассмотрим схему ниже.

Как и пороговые значения балансировки, пороговые значения активности определяются в определении кластера на основе метрик:

ClusterManifest.xml

    <Section Name="MetricActivityThresholds">
      <Parameter Name="Memory" Value="1536"/>
    </Section>

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

"fabricSettings": [
  {
    "name": "MetricActivityThresholds",
    "parameters": [
      {
          "name": "Memory",
          "value": "1536"
      }
    ]
  }
]

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

Примечание.

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

Одновременная балансировка служб

Несбалансированность кластера определяется на уровне кластера. Однако мы исправим ее путем перемещения отдельных реплик и экземпляров службы. Звучит разумно, не правда ли? Если память накапливается в одном узле, это может быть вызвано сразу несколькими репликами или экземплярами. Для устранения дисбаланса может потребоваться перемещение всех реплик с отслеживанием состояния или экземпляров без отслеживания состояния, для которых используется несбалансированная метрика.

В отдельных случаях перемещается служба, которая сама по себе не была несбалансированной (вспомните обсуждение локальных и глобальных весов, приведенное ранее). Почему же служба перемещается, если все ее метрики сбалансированы? Рассмотрим пример.

• Предположим, что есть четыре службы, служба 1, служба 2, служба 3 и служба 4.
• Служба 1 сообщает метрики метрики 1 и метрики 2.
• Служба 2 сообщает метрики метрики 2 и метрики 3.
• Служба 3 сообщает метрики метрики 3 и метрики 4.
• Служба 4 сообщает метрики 99.

Мы имеем дело не с четырьмя независимыми службами, а с тремя связанными службами и одной отдельной службой.

Из-за этой цепочки вполне возможно, что дисбаланс в метриках Metric1–Metric4 может привести к перемещению реплик или экземпляров, относящихся к службам Service1–Service3. Мы также знаем, что дисбаланс в метриках 1, 2 или 3 не может привести к перемещению в службе 4. Нет смысла, так как перемещение реплик или экземпляров, принадлежащих службе 4, не может сделать абсолютно ничего, чтобы повлиять на баланс метрик 1-3.

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

Балансировка кластера на тип узла

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

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

Как балансировка на тип узла влияет на кластер

Во время балансировки кластера на тип узла диспетчер кластеров Service Fabric вычисляет состояние дисбаланса для каждого типа узла. Если по крайней мере один тип узла несбалансирован, будет активирован этап балансировки. Этап балансировки не перемещает реплики на типы узлов, которые несбалансированные, при временной приостановке балансировки на этих типах узлов (например, минимальный интервал балансировки не прошел с предыдущего этапа балансировки). Обнаружение несбалансированного состояния использует общие механизмы, уже доступные для классической балансировки кластера, но повышает степень детализации конфигурации и гибкость. Механизмы, используемые для балансировки на тип узла для обнаружения дисбаланса, приведены в следующем списке:

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

Описание балансировки на тип узла

Чтобы включить балансировку на тип узла, необходимо включить параметр SeparateBalancingStrategyPerNodeType в манифесте кластера. Кроме того, необходимо включить функцию подкластеринга. Пример раздела "Размещение манифеста кластераAndLoadBalancing" для включения функции:

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

ClusterConfig.json для автономных развертываний или Template.json для размещенных кластеров Azure:

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

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

• Пороговые значения балансировки метрик для каждого типа узла
• Пороговые значения активности метрик для каждого типа узла
• Минимальный интервал балансировки на тип узла

Пороговые значения балансировки на тип узла

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

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricBalancingThresholdsPerNodeType>
                <BalancingThreshold Name="Metric1" Value="2.5">
                <BalancingThreshold Name="Metric2" Value="4">
                <BalancingThreshold Name="Metric3" Value="3.25">
            </MetricBalancingThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Если пороговое значение балансировки для метрики не определено для типа узла, пороговое значение наследует пороговое значение балансировки метрик, определенное глобально в разделе PlacementAndLoadBalancing . В противном случае, если порог балансировки для метрики не определен ни для типа узла, ни глобально в разделе PlacementAndLoadBalancing , пороговое значение по умолчанию будет иметь значение по умолчанию.

Пороговые значения действий для каждого типа узла

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

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricActivityThresholdsPerNodeType>
                <ActivityThreshold Name="Metric1" Value="500">
                <ActivityThreshold Name="Metric2" Value="40">
                <ActivityThreshold Name="Metric3" Value="1000">
            </MetricActivityThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Если пороговое значение действия для метрики не определено для типа узла, пороговое значение наследует от порогового значения действия метрик, определенного глобально в разделе PlacementAndLoadBalancing . В противном случае, если пороговое значение действия для метрики не определено ни для типа узла, ни глобально в разделе PlacementAndLoadBalancing, пороговое значение по умолчанию равно нулю.

Минимальный интервал балансировки на тип узла

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

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MinLoadBalancingIntervalPerNodeType>100</MinLoadBalancingIntervalPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

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

Примеры

Пример 1

Рассмотрим случай, когда кластер содержит два типа узлов, тип узла A и тип узла B. Все службы сообщают одну и ту же метрику, и они разделяются между этими типами узлов, поэтому статистика загрузки отличается для них. В примере тип узла A имеет максимальную нагрузку 300 и не менее 100, а тип узла B имеет максимальную нагрузку 700 и минимальную нагрузку 500:

Клиент обнаружил, что рабочие нагрузки двух типов узлов имеют разные потребности в балансировке и решили задать разные пороговые значения балансировки и действий для каждого типа узла. Пороговое значение балансировки типа узла A равно 2,5, а пороговое значение действия — 50. Для типа узла B, для параметра балансировки клиента задано пороговое значение 1.2 и пороговое значение действия до 400.

Во время обнаружения дисбаланса для кластера в этом примере оба типа узлов нарушают пороговое значение действия. Максимальная нагрузка типа узла A 300 выше определенного порогового значения действия 50. Максимальная нагрузка типа узла B 700 выше определенного порогового значения действия 400. Тип узла A нарушает критерии порогового значения балансировки, так как текущее соотношение максимальной и минимальной нагрузки равно 3, а пороговое значение балансировки — 2,5. Напротив, тип узла B не нарушает критерии порогового значения балансировки, так как текущее соотношение максимальной и минимальной нагрузки для этого типа узла равно 1,2, но пороговое значение балансировки равно 1,4. Балансировка требуется только для реплик в типе A узла, а единственный набор реплик, которые будут иметь право на перемещение во время этапа балансировки, являются репликами, помещенными в тип A узла.

Пример 2

Рассмотрим случай, когда кластер содержит три типа узлов, тип узла A, B и C. Все службы сообщают одну и ту же метрику, и они разделяются между этими типами узлов, поэтому статистика загрузки отличается для них. В примере тип узла A имеет максимальную нагрузку 600 и не менее 100, тип узла B имеет максимальную нагрузку 900 и минимальную нагрузку 100, а тип узла C имеет максимальную нагрузку 600 и минимальную нагрузку 300:

Клиент обнаружил, что рабочие нагрузки этих типов узлов имеют разные потребности в балансировке и решили задать разные пороговые значения балансировки и действий для каждого типа узла. Пороговое значение балансировки типа A равно 5, а пороговое значение действия — 700. Для типа узла B, пороговое значение балансировки клиента — 10, а пороговое значение действия — 200. Для типа узла C клиент устанавливает пороговое значение балансировки 2 и пороговое значение действия до 300.

Максимальная нагрузка типа узла A 600 ниже определенного порогового значения действия 700, поэтому тип узла A не будет сбалансирован. Максимальная нагрузка типа узла B 900 выше определенного порогового значения действия 200. Тип узла B нарушает критерии порогового значения действия. Максимальная нагрузка типа узла C 600 выше определенного порогового значения действия 300. Тип узла C нарушает критерии порогового значения действия. Тип узла B не нарушает критерии порогового значения балансировки, так как текущее соотношение максимальной и минимальной нагрузки для этого типа узла равно 9, но пороговое значение балансировки равно 10. Тип узла C нарушает критерии порогового значения балансировки, так как текущее соотношение максимальной и минимальной нагрузки равно 2, а пороговое значение балансировки — 2. Балансировка требуется только для реплик в типе узла C, а единственный набор реплик, которые будут иметь право на перемещение во время этапа балансировки, являются репликами, размещенными в типе узла C.

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

• Метрики показывают, как диспетчер кластерных ресурсов Service Fabric управляет потреблением и емкостью в кластере. Дополнительные сведения о метриках и их настройке см. в статье о метриках
• Стоимость перемещения — один из способов сообщить диспетчеру кластерных ресурсов, что некоторые службы перемещать затратнее, чем остальные. Дополнительные сведения о стоимости перемещения см. в статье о стоимости перемещения
• В диспетчере кластерных ресурсов имеется несколько регулировок, которые можно настроить, чтобы замедлить отток в кластере. Они обычно не необходимы, но если вам нужны их, вы можете узнать о них статью о расширенном регулировании
• Диспетчер кластерных ресурсов может распознавать и обрабатывать подкластеризацию. Подкластеринг может возникать при использовании ограничений размещения и балансировки. Сведения о том, как подкластеринг может повлиять на балансировку и способ ее обработки, см. в статье о подкластеринге