Интеграция диспетчера кластерных ресурсов с управлением кластерами Service Fabric

Статья
08/25/2024

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

Интеграция функций работоспособности

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

Кроме того, он выводит предупреждения о работоспособности в случае нарушения ограничений размещения. Например, если определено ограничение размещения (например, “NodeColor == Blue”) и диспетчер ресурсов обнаруживает его нарушение, то он выводит предупреждение о работоспособности. Это делается для настраиваемых ограничений, а также для ограничений по умолчанию (например, ограничений для доменов сбоя и доменов обновления).

Ниже приведен пример такого отчета о работоспособности. В этом случае отчет о работоспособности формируется для одного из разделов системной службы. Сообщение о работоспособности указывает, что реплики этого раздела временно сгруппированы в слишком малое количество доменов обновления.

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

В сообщении о работоспособности содержатся следующие сведения:

Все реплики работоспособны, для каждой указано AggregatedHealthState : Ok
Ограничение распределения в доменах обновления в настоящее время нарушается. Это означает, что в определенном домене обновления больше реплик из данной секции, чем должно быть.
Какой из узлов содержит реплику, которая привела к нарушению. В нашем примере это узел с именем Node.8.
Выполняется ли в данный момент обновление этой секции ("Currently Upgrading -- false").
Политика распределения для этой службы ("Distribution Policy -- Packing"). Это регулируется политикой RequireDomainDistribution размещения. Значение Packing означает, что в этом случае распределение в доменах не требовалось, а значит для этой службы не была указана политика размещения.
Время создания отчета (10.08.2015 в 19:13:02).

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

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

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

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

Типы ограничений

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

ReplicaExclusionStatic и ReplicaExclusionDynamic. Эти ограничения указывают, что решение было отклонено из-за того, что пришлось бы разместить на одном узле два объекта службы из одной и той же секции. Это недопустимо, так как сбой данного узла чрезмерно повлиял бы на эту секцию. ReplicaExclusionStatic и ReplicaExclusionDynamic — это практически аналогичные правила, но с незначительными отличиями. Если вы видите последовательность устранения ограничений, содержащую ограничение ReplicaExclusionStatic или ReplicaExclusionDynamic, то диспетчер кластерных ресурсов считает, что узлов недостаточно. Для этого нужно, чтобы остальные решения использовали недопустимые размещения, а это запрещено. Другие ограничения в последовательности, как правило, позволяют определить, почему вообще исключаются узлы.
PlacementConstraint. Это сообщение означает, что некоторые узлы были устранены из-за несоответствия ограничениям на размещение службы. Мы рассматриваем текущие настроенные ограничения на размещения как часть этого сообщения. Это нормально, если определено ограничение размещения. Однако если в ограничении размещения имеется ошибка, которая приводит к исключению слишком большого числа узлов, то именно так вы заметите это.
NodeCapacity. Это ограничение означает, что диспетчер кластерных ресурсов не может размещать реплики на указанных узлах, так как это приведет к превышению их емкости.
Affinity. Это ограничение означает, что нельзя размещать реплики на затронутых узлах, так как это приведет к нарушению ограничения сходства. Дополнительные сведения о сходстве см. в этой статье.
FaultDomain и UpgradeDomain. Эти ограничения исключают узлы, если размещение реплики на указанных узлах привело к упаковке в конкретный домен сбоя или обновления. Несколько примеров, посвященных этому ограничению, представлены в разделе об ограничениях доменов сбоя и обновления и результирующем поведении.
PreferredLocation. Обычно это ограничение не отображается. Оно приводит к удалению узлов из решения, так как оно выполняется в качестве оптимизации по умолчанию. Предпочтительное ограничение размещения также действует во время обновлений. Оно используется для возврата служб в то расположение, в котором они находились при запуске обновления.

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

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

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

Добавление в список блокировки не является окончательным. Через несколько минут узел удаляется из списка блокировки, и Service Fabric может повторно активировать службы на этом узле. Если запуск служб по-прежнему завершается сбоем, узел снова добавляется в список блокировки для этого типа службы.

Приоритеты ограничений

Предупреждение

Изменение приоритетов ограничения не рекомендуется и может иметь значительное отрицательное воздействие на кластер. Ниже приведена справочная информация о приоритетах ограничений по умолчанию и их поведении.

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

Для ограничений можно настроить различные уровни приоритета, К ним относятся:

"жесткий" (0);
"мягкий" (1);
"оптимизационный" (2);
"отключен" (-1).

Большинство ограничений по умолчанию настроено как жесткие ограничения.

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

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

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

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

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

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

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

Ограничения доменов сбоя и обновления

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

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

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

Ограничение на предпочтительное расположение

Ограничение PreferredLocation немного отличается от остальных, так как имеет два варианта использования. Во-первых, это ограничение применяется во время обновления приложений. Диспетчер кластерных ресурсов автоматически управляет этим ограничением во время обновлений. Оно обеспечивает возврат реплик в исходные расположения после завершения обновлений. Во-вторых, ограничение PreferredLocation используется для политики размещенияPreferredPrimaryDomain. Оба варианта использования являются оптимизацией, поэтому ограничение PreferredLocation — единственное ограничение с "оптимизационным" приоритетом по умолчанию.

Обновления

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

обеспечивает соблюдение правил кластера;
обеспечивает плавное выполнение обновления.

Применение правил

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

Интеллектуальные замены

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

Сокращение оттока

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

Буферизованная емкость и обновление

Обычно возникает необходимость завершить обновление, даже если кластер ограничен или почти заполнен. Управление емкостью кластера во время обновлений даже важнее, чем обычно. При развертывании обновления в кластере требуется перенос от 5 до 20 процентов от общей емкости, в зависимости от числа доменов обновления. Эту нагрузку нужно перенаправить. Именно здесь пригодится понятие буферизованных емкостей. Буферизованная емкость учитывается во время обычной работы. При необходимости во время обновлений диспетчер кластерных ресурсов может заполнить узлы вплоть до их общей емкости (использовав буфер).

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

Начните с самого начала, изучив общие сведения о диспетчере кластерных ресурсов Service Fabric

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