Знакомство с автомасштабированием

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

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

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

Автоматическое масштабирование поддерживается как для контейнеров, так и для обычных служб Service Fabric. Чтобы использовать автоматическое масштабирование, вам понадобится среда выполнения Service Fabric версии 6.2 или более поздней.

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

Описание автомасштабирования

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

• Триггер масштабирования описывает, когда выполняется масштабирование службы. Условия, определенные в триггере, периодически проверяются, чтобы определить, нужно ли масштабировать службу.

• Механизм масштабирования описывает, как выполняется масштабирование при активации. Механизм применяется только при выполнении условий триггера.

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

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

Средний триггер загрузки раздела при масштабировании на основе экземпляра

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

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

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

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

• Увеличение масштаба определяет, сколько экземпляров добавляются или удаляются при активации механизма.
• Максимальное число экземпляров определяет верхний предел для масштабирования. Если число экземпляров секции достигает этого ограничения, служба масштабируется независимо от нагрузки. Это ограничение можно опустить, указав значение -1, и в этом случае служба масштабируется как можно больше (ограничение — это количество узлов, доступных в кластере).
• Минимальное число экземпляров определяет нижний предел для масштабирования. Если число экземпляров раздела достигает этого ограничения, служба не масштабируется независимо от уровня нагрузки.

Настройка политики автоматического масштабирования для экземплярного масштабирования

Использование манифеста приложения

<LoadMetrics>
<LoadMetric Name="MetricB" Weight="High"/>
</LoadMetrics>
<ServiceScalingPolicies>
<ScalingPolicy>
    <AveragePartitionLoadScalingTrigger MetricName="MetricB" LowerLoadThreshold="1" UpperLoadThreshold="2" ScaleIntervalInSeconds="100"/>
    <InstanceCountScalingMechanism MinInstanceCount="3" MaxInstanceCount="4" ScaleIncrement="1"/>
</ScalingPolicy>
</ServiceScalingPolicies>

Использование программных интерфейсов C#

FabricClient fabricClient = new FabricClient();
StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//set up the rest of the ServiceDescription
AveragePartitionLoadScalingTrigger trigger = new AveragePartitionLoadScalingTrigger();
PartitionInstanceCountScaleMechanism mechanism = new PartitionInstanceCountScaleMechanism();
mechanism.MaxInstanceCount = 3;
mechanism.MinInstanceCount = 1;
mechanism.ScaleIncrement = 1;
trigger.MetricName = "servicefabric:/_CpuCores";
trigger.ScaleInterval = TimeSpan.FromMinutes(20);
trigger.LowerLoadThreshold = 1.0;
trigger.UpperLoadThreshold = 2.0;
ScalingPolicyDescription policy = new ScalingPolicyDescription(mechanism, trigger);
serviceDescription.ScalingPolicies.Add(policy);
//as we are using scaling on a resource this must be exclusive service
//also resource monitor service needs to be enabled
serviceDescription.ServicePackageActivationMode = ServicePackageActivationMode.ExclusiveProcess
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Использование PowerShell

$mechanism = New-Object -TypeName System.Fabric.Description.PartitionInstanceCountScaleMechanism
$mechanism.MinInstanceCount = 1
$mechanism.MaxInstanceCount = 6
$mechanism.ScaleIncrement = 2
$trigger = New-Object -TypeName System.Fabric.Description.AveragePartitionLoadScalingTrigger
$trigger.MetricName = "servicefabric:/_CpuCores"
$trigger.LowerLoadThreshold = 0.3
$trigger.UpperLoadThreshold = 0.8
$trigger.ScaleInterval = New-TimeSpan -Minutes 10
$scalingpolicy = New-Object -TypeName System.Fabric.Description.ScalingPolicyDescription
$scalingpolicy.ScalingMechanism = $mechanism
$scalingpolicy.ScalingTrigger = $trigger
$scalingpolicies = New-Object 'System.Collections.Generic.List[System.Fabric.Description.ScalingPolicyDescription]'
$scalingpolicies.Add($scalingpolicy)
#as we are using scaling on a resource this must be exclusive service
#also resource monitor service needs to be enabled
Update-ServiceFabricService -Stateless -ServiceName "fabric:/AppName/ServiceName" -ScalingPolicies $scalingpolicies

Средняя загрузка службы как триггер при масштабировании на основе разделов

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

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

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

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

Например, если служба изначально создана с тремя разделами, единственные допустимые имена разделов — "0", "1" и "2".

Фактическая операция автоматического масштабирования, которая выполняется, также учитывает эту схему именования:

• Если текущие секции службы называются "0", "1" и "2", то раздел, добавленный для масштабирования, называется "3".
• Если текущие секции службы называются "0", "1" и "2", то раздел, удаленный для масштабирования, является секцией с именем "2".

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

• Увеличение масштаба определяет, сколько секций добавлено или удалено при активации механизма.
• Максимальное число разделов определяет верхний предел для масштабирования. Если количество секций службы достигает этого ограничения, служба не масштабируется независимо от нагрузки. Это ограничение можно опустить, указав значение -1, и в этом случае служба масштабируется как можно больше (это ограничение является фактической емкостью кластера).
• Минимальное число секций определяет нижнее ограничение масштабирования. Если количество секций службы достигает этого ограничения, служба не масштабируется независимо от нагрузки.

Настройка политики автомасштабирования для партитивного масштабирования

Использование манифеста приложения

<NamedPartition>
    <Partition Name="0" />
</NamedPartition>
<ServiceScalingPolicies>
    <ScalingPolicy>
        <AverageServiceLoadScalingTrigger MetricName="servicefabric:/_MemoryInMB" LowerLoadThreshold="300" UpperLoadThreshold="500" ScaleIntervalInSeconds="600"/>
        <AddRemoveIncrementalNamedPartitionScalingMechanism MinPartitionCount="1" MaxPartitionCount="3" ScaleIncrement="1"/>
    </ScalingPolicy>
</ServiceScalingPolicies>

Использование программных интерфейсов C#

FabricClient fabricClient = new FabricClient();
StatefulServiceUpdateDescription serviceUpdate = new StatefulServiceUpdateDescription();
AveragePartitionLoadScalingTrigger trigger = new AverageServiceLoadScalingTrigger();
PartitionInstanceCountScaleMechanism mechanism = new AddRemoveIncrementalNamedPartitionScalingMechanism();
mechanism.MaxPartitionCount = 4;
mechanism.MinPartitionCount = 1;
mechanism.ScaleIncrement = 1;
//expecting that the service already has metric NumberOfConnections
trigger.MetricName = "NumberOfConnections";
trigger.ScaleInterval = TimeSpan.FromMinutes(15);
trigger.LowerLoadThreshold = 10000;
trigger.UpperLoadThreshold = 20000;
ScalingPolicyDescription policy = new ScalingPolicyDescription(mechanism, trigger);
serviceUpdate.ScalingPolicies = new List<ScalingPolicyDescription>;
serviceUpdate.ScalingPolicies.Add(policy);
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/AppName/ServiceName"), serviceUpdate);

Использование PowerShell

$mechanism = New-Object -TypeName System.Fabric.Description.AddRemoveIncrementalNamedPartitionScalingMechanism
$mechanism.MinPartitionCount = 1
$mechanism.MaxPartitionCount = 3
$mechanism.ScaleIncrement = 2
$trigger = New-Object -TypeName System.Fabric.Description.AverageServiceLoadScalingTrigger
$trigger.MetricName = "servicefabric:/_MemoryInMB"
$trigger.LowerLoadThreshold = 5000
$trigger.UpperLoadThreshold = 10000
$trigger.ScaleInterval = New-TimeSpan -Minutes 25
$scalingpolicy = New-Object -TypeName System.Fabric.Description.ScalingPolicyDescription
$scalingpolicy.ScalingMechanism = $mechanism
$scalingpolicy.ScalingTrigger = $trigger
$scalingpolicies = New-Object 'System.Collections.Generic.List[System.Fabric.Description.ScalingPolicyDescription]'
$scalingpolicies.Add($scalingpolicy)
#as we are using scaling on a resource this must be exclusive service
#also resource monitor service needs to be enabled
New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -TargetReplicaSetSize 3 -MinReplicaSetSize 2 -HasPersistedState true -PartitionNames @("0","1") -ServicePackageActivationMode ExclusiveProcess -ScalingPolicies $scalingpolicies

Автоматическое масштабирование на основе ресурсов

Чтобы служба мониторинга ресурсов могла масштабироваться на основе фактических ресурсов, вы можете добавить функцию ResourceMonitorService следующим образом:

"fabricSettings": [
...   
],
"addonFeatures": [
    "ResourceMonitorService"
],

Service Fabric поддерживает управление ЦП и памятью с помощью двух встроенных метрик: servicefabric:/_CpuCores для ЦП и servicefabric:/_MemoryInMB памяти. Служба монитора ресурсов отвечает за отслеживание использования ЦП и памяти и обновление диспетчера кластерных ресурсов с текущим использованием ресурсов. Эта услуга применяет взвешенное скользящее среднее для учета потенциальных кратковременных пиков. Мониторинг ресурсов поддерживается как для контейнерных, так и неконтейнеризированных приложений в Windows и для контейнерных приложений в Linux.

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

Узнайте больше о масштабируемости приложений.