Дефрагментация метрик и нагрузки в Service Fabric

Статья
08/25/2024

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

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

Когда следует использовать дефрагментацию

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

Если перемещать нужно большое число служб и состояний, на размещение большой рабочей нагрузки в кластере потребуется много времени. Это еще более вероятно, если другие рабочие нагрузки в кластере тоже большие, и их реорганизация требует много времени. Разработчики Service Fabric замерили время создания службы, смоделировав такой сценарий. Мы обнаружили, что создание больших служб занимает гораздо больше времени, когда использование кластера находится в пределах 30–50 %. Чтобы решить эту проблему, мы создали стратегию балансировки, основанную на дефрагментации. Мы обнаружили, что для крупных рабочих нагрузок, особенно чувствительных к задержкам при создании, дефрагментация существенно оптимизирует размещение нагрузок в кластере.

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

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

Достоинства и недостатки дефрагментации

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

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

Сравнение методов балансировки и дефрагментации кластеров

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

Преимущества и недостатки дефрагментации

О каких компромиссах идет речь? Вот на что следует обратить внимание:

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

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

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

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

Настройка метрик для дефрагментации

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

ClusterManifest.xml:

<Section Name="DefragmentationMetrics">
    <Parameter Name="Metric1" Value="true" />
    <Parameter Name="Metric2" Value="false" />
</Section>

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

"fabricSettings": [
  {
    "name": "DefragmentationMetrics",
    "parameters": [
      {
          "name": "Metric1",
          "value": "true"
      },
      {
          "name": "Metric2",
          "value": "false"
      }
    ]
  }
]

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

В Cluster Resource Manager предусмотрено много параметров для описания кластера. Дополнительные сведения об этих параметрах см. в статье с описанием кластера Service Fabric.
Метрики показывают, как диспетчер кластерных ресурсов Service Fabric управляет потреблением и емкостью в кластере. Чтобы узнать больше о метриках и их настройке, ознакомьтесь с этой статьей.

Поделиться через