Балансировка кластера 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"
      }
    ]
  }
]

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

Например, когда происходит сбой узлов, то может выполняться одновременная обработка доменов сбоя целиком. Все эти сбои регистрируются во время следующего изменения состояния после 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.

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

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

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

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

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

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

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

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

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

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

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

<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 управляет потреблением и емкостью в кластере. Дополнительные сведения о метриках и их настройке см. в статье о метриках
• Стоимость перемещения — один из способов сообщить диспетчеру кластерных ресурсов, что некоторые службы перемещать затратнее, чем остальные. Дополнительные сведения о стоимости перемещения см. в статье о стоимости перемещения
• В диспетчере кластерных ресурсов имеется несколько регулировок, которые можно настроить, чтобы замедлить отток в кластере. Они обычно не необходимы, но если они вам нужны, вы можете узнать о них из статьи о расширенном регулировании.
• Диспетчер кластерных ресурсов может распознавать и обрабатывать подкластеризацию. Подкластеринг может возникать при использовании ограничений размещения и балансировки. Сведения о том, как подкластеринг может повлиять на балансировку и способ ее обработки, см. в статье о подкластеринге