Share via

Introdução ao Auto Scaling

  • Artigo

O dimensionamento automático é outro recurso do Service Fabric para dimensionar dinamicamente seus serviços com base na carga que os serviços estão relatando ou com base no uso de recursos. O dimensionamento automático proporciona grande elasticidade e permite o provisionamento de instâncias ou partições extras do seu serviço sob demanda. Todo o processo de dimensionamento automático é automatizado e transparente e, depois de configurar suas políticas em um serviço, não há necessidade de operações de dimensionamento manual no nível de serviço. O dimensionamento automático pode ser ativado no momento da criação do serviço ou a qualquer momento, atualizando o serviço.

Um cenário comum em que o dimensionamento automático é útil é quando a carga em um determinado serviço varia ao longo do tempo. Por exemplo, um serviço como um gateway pode ser dimensionado com base na quantidade de recursos necessários para lidar com solicitações de entrada. Vamos dar uma olhada em um exemplo de como essas regras de dimensionamento poderiam parecer:

  • Se todas as instâncias do meu gateway estiverem usando mais de dois núcleos em média, expanda o serviço de gateway adicionando mais uma instância. Faça essa adição a cada hora, mas nunca tenha mais de sete instâncias no total.
  • Se todas as instâncias do meu gateway estiverem usando menos de 0,5 núcleos em média, dimensione o serviço removendo uma instância. Faça essa remoção a cada hora, mas nunca tenha menos de três instâncias no total.

O dimensionamento automático é suportado para contêineres e serviços regulares do Service Fabric. Para usar o dimensionamento automático, você precisa estar executando na versão 6.2 ou superior do tempo de execução do Service Fabric.

O restante deste artigo descreve as políticas de dimensionamento, maneiras de habilitar ou desabilitar o dimensionamento automático e fornece exemplos sobre como usar esse recurso.

Descrição do dimensionamento automático

As políticas de dimensionamento automático podem ser definidas para cada serviço em um cluster do Service Fabric. Cada política de dimensionamento consiste em duas partes:

  • O gatilho de dimensionamento descreve quando o dimensionamento do serviço é executado. As condições definidas no gatilho são verificadas periodicamente para determinar se um serviço deve ser dimensionado ou não.

  • O mecanismo de dimensionamento descreve como o dimensionamento é executado quando é acionado. O mecanismo só é aplicado quando as condições do gatilho são satisfeitas.

Todos os gatilhos suportados atualmente funcionam com métricas de carga lógica ou com métricas físicas, como uso de CPU ou memória. De qualquer forma, o Service Fabric monitora a carga relatada para a métrica e avalia o gatilho periodicamente para determinar se o dimensionamento é necessário.

Existem dois mecanismos que são atualmente suportados para o dimensionamento automático. O primeiro destina-se a serviços sem estado ou a contêineres em que o dimensionamento automático é executado adicionando ou removendo instâncias. Para serviços com e sem monitoração de estado, o dimensionamento automático também pode ser executado adicionando ou removendo partições nomeadas do serviço.

Nota

Atualmente, há suporte para apenas uma política de dimensionamento por serviço e apenas um gatilho de dimensionamento por política de dimensionamento.

Gatilho de carga média de partição com dimensionamento baseado em instância

O primeiro tipo de gatilho é baseado na carga de instâncias em uma partição de serviço sem monitoração de estado. As cargas métricas são primeiro suavizadas para obter a carga para cada instância de uma partição e, em seguida, esses valores são calculados em média em todas as instâncias da partição. Há três fatores que determinam quando o serviço é dimensionado:

  • Limite de carga mais baixo é um valor que determina quando o serviço é dimensionado. Se a carga média de todas as instâncias das partições for inferior a esse valor, o serviço será dimensionado.
  • O limite de carga superior é um valor que determina quando o serviço é expandido. Se a carga média de todas as instâncias da partição for maior do que esse valor, o serviço será expandido.
  • O intervalo de dimensionamento determina a frequência com que o gatilho é verificado. Uma vez que o gatilho é verificado, se o dimensionamento for necessário, o mecanismo é aplicado. Se o dimensionamento não for necessário, nenhuma ação será tomada. Em ambos os casos, o gatilho não é verificado novamente antes que o intervalo de dimensionamento expire novamente.

Esse gatilho só pode ser usado com serviços sem monitoração de estado (contêineres sem estado ou serviços do Service Fabric). No caso de um serviço ter várias partições, o gatilho é avaliado para cada partição separadamente, e cada partição tem o mecanismo especificado aplicado a ela independentemente. Assim, os comportamentos de dimensionamento das partições de serviço podem variar com base em sua carga. É possível que algumas partições do serviço sejam dimensionadas, enquanto outras são dimensionadas. Algumas partições podem não ser dimensionadas ao mesmo tempo.

O único mecanismo que pode ser usado com esse gatilho é PartitionInstanceCountScaleMechanism. Existem três fatores que determinam a forma como este mecanismo é aplicado:

  • O Incremento de Escala determina quantas instâncias são adicionadas ou removidas quando o mecanismo é acionado.
  • A contagem máxima de instâncias define o limite superior para dimensionamento. Se o número de instâncias da partição atingir esse limite, o serviço será expandido, independentemente da carga. É possível omitir esse limite especificando o valor de -1 e, nesse caso, o serviço é expandido tanto quanto possível (o limite é o número de nós disponíveis no cluster).
  • A Contagem Mínima de Instâncias define o limite inferior para dimensionamento. Se o número de instâncias da partição atingir esse limite, o serviço não será dimensionado, independentemente da carga.

Definindo a política de dimensionamento automático para dimensionamento baseado em instância

Usando o manifesto do aplicativo

<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>

Usando APIs 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);

Através do 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

Gatilho de carga de serviço médio com dimensionamento baseado em partição

O segundo gatilho é baseado na carga de todas as partições de um serviço. As cargas métricas são primeiro suavizadas para obter a carga para cada réplica ou instância de uma partição. Para serviços com monitoração de estado, a carga da partição é considerada a carga da réplica primária, enquanto para serviços sem estado, a carga da partição é a carga média de todas as instâncias da partição. Esses valores são calculados em média em todas as partições do serviço, e esse valor é usado para acionar o dimensionamento automático. Assim como no mecanismo anterior, há três fatores que determinam quando o serviço é dimensionado:

  • Limite de carga mais baixo é um valor que determina quando o serviço é dimensionado. Se a carga média de todas as partições do serviço for inferior a esse valor, o serviço será dimensionado.
  • O limite de carga superior é um valor que determina quando o serviço é expandido. Se a carga média de todas as partições do serviço for maior do que esse valor, o serviço será expandido.
  • O intervalo de dimensionamento determina a frequência com que o gatilho é verificado. Uma vez que o gatilho é verificado, se o dimensionamento for necessário, o mecanismo é aplicado. Se o dimensionamento não for necessário, nenhuma ação será tomada. Em ambos os casos, o gatilho é verificado novamente antes que o intervalo de dimensionamento expire novamente.

Esse gatilho pode ser usado com serviços com e sem monitoração de estado. O único mecanismo que pode ser usado com esse gatilho é AddRemoveIncrementalNamedPartitionScalingMechanism. Quando o serviço é expandido, uma nova partição é adicionada e quando o serviço é dimensionado em uma das partições existentes é removido. Há restrições que são verificadas quando o serviço é criado ou atualizado e a criação/atualização do serviço falha se estas condições não forem atendidas:

  • O esquema de partição nomeada deve ser usado para o serviço.
  • Os nomes de partição devem ser números inteiros consecutivos, como "0", "1", ...
  • O nome da primeira partição deve ser "0".

Por exemplo, se um serviço é inicialmente criado com três partições, a única possibilidade válida para nomes de partição é "0", "1" e "2".

A operação de dimensionamento automático real que é executada também respeita esse esquema de nomenclatura:

  • Se as partições atuais do serviço forem nomeadas "0", "1" e "2", a partição adicionada para dimensionamento será denominada "3".
  • Se as partições atuais do serviço forem nomeadas "0", "1" e "2", a partição removida para dimensionamento será a partição com nome "2".

Assim como acontece com o mecanismo que usa dimensionamento adicionando ou removendo instâncias, há três parâmetros que determinam como esse mecanismo é aplicado:

  • O Incremento de Escala determina quantas partições foram adicionadas ou removidas quando o mecanismo é acionado.
  • A Contagem Máxima de Partições define o limite superior para dimensionamento. Se o número de partições do serviço atingir esse limite, o serviço não será expandido, independentemente da carga. É possível omitir esse limite especificando o valor de -1 e, nesse caso, o serviço é expandido tanto quanto possível (o limite é a capacidade real do cluster).
  • A Contagem Mínima de Partições define o limite inferior para dimensionamento. Se o número de partições do serviço atingir esse limite, o serviço não será dimensionado independentemente da carga.

Aviso

Quando AddRemoveIncrementalNamedPartitionScalingMechanism é usado com serviços com monitoração de estado, o Service Fabric adicionará ou removerá partições sem notificação ou aviso. O reparticionamento de dados não será executado quando o mecanismo de dimensionamento for acionado. Em caso de operação de expansão, novas partições estarão vazias e, em caso de escala em operação, a partição será excluída juntamente com todos os dados que ela contém.

Definindo a política de dimensionamento automático para dimensionamento baseado em partição

Usando o manifesto do aplicativo

<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>

Usando APIs 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);

Através do 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

Dimensionamento automático com base em recursos

Para permitir que o serviço de monitor de recursos seja dimensionado com base em recursos reais, você pode adicionar o ResourceMonitorService recurso da seguinte maneira:

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

O Service Fabric oferece suporte à governança de CPU e memória usando duas métricas internas: servicefabric:/_CpuCores para CPU e servicefabric:/_MemoryInMB para memória. O Serviço de Monitor de Recursos é responsável por controlar o uso da CPU e da memória e atualizar o Gerenciador de Recursos de Cluster com o uso atual dos recursos. Este serviço aplica uma média móvel ponderada para contabilizar potenciais picos de curta duração. O monitoramento de recursos é suportado para aplicativos em contêineres e não conteinerizados no Windows e para aplicativos em contêineres no Linux.

Nota

O consumo de CPU e memória monitorado no Serviço de Monitor de Recursos e atualizado para o Gerenciador de Recursos de Cluster não afeta nenhum processo de tomada de decisão fora do dimensionamento automático. Se a governança de recursos for necessária, ela poderá ser configurada sem interferir nas funcionalidades de dimensionamento automático e vice-versa.

Importante

O dimensionamento automático baseado em recursos é suportado apenas para serviços ativados no modelo de processo exclusivo.

Próximos passos

Saiba mais sobre a escalabilidade do aplicativo.