Introducción al escalado automático

  • Artículo

El escalado automático es otra funcionalidad de Service Fabric para escalar dinámicamente los servicios en función de la carga que notifican los servicios o en función de su uso de recursos. El escalado automático proporciona una gran elasticidad y permite el aprovisionamiento de instancias o particiones adicionales del servicio a petición. Todo el proceso de escalado automático está automatizado y transparente y, una vez configurados las directivas en un servicio, no es necesario realizar operaciones de escalado manual en el nivel de servicio. El escalado automático se puede activar al crear el servicio o al actualizarlo en cualquier momento.

Un escenario común en el que el escalado automático es útil es cuando la carga en un servicio determinado varía con el tiempo. Por ejemplo, un servicio (como, una puerta de enlace) puede escalar en función de la cantidad de recursos necesarios para gestionar las solicitudes entrantes. Echemos un vistazo a un ejemplo del aspecto que tendrían estas reglas de escalado:

  • Si todas las instancias de mi puerta de enlace usan más de dos núcleos en promedio, escale horizontalmente el servicio de puerta de enlace agregando una instancia más. Realice esta adición cada hora, pero nunca tenga más de siete instancias en total.
  • Si todas las instancias de la puerta de enlace usan menos de 0,5 núcleos de media, quite una instancia para reducir el servicio horizontalmente. Realice esta eliminación cada hora, pero nunca tenga menos de tres instancias en total.

Se admite el escalado automático para contenedores y servicios normales de Service Fabric. Para poder usar el escalado automático, debe ejecutar la versión 6.2 o posterior del entorno de ejecución de Service Fabric.

En lo que queda de este artículo, se describen las directivas de escalado, cómo habilitar o deshabilitar el escalado automático y se proporcionan ejemplos sobre cómo usar esta característica.

Descripción del escalado automático

Las directivas de escalado automático pueden definirse para cada servicio de un clúster de Service Fabric. Cada directiva de escalado consta de dos partes:

  • Desencadenador de escalado describe cuándo se realiza el escalado del servicio. Las condiciones que se definen en el desencadenador se comprueban periódicamente para determinar si se debe escalar un servicio.

  • Mecanismo de escalado describe cómo se realiza el escalado cuando se desencadena. El mecanismo solo se aplica cuando se cumplen las condiciones del desencadenador.

Todos los desencadenadores que son compatibles actualmente funcionan con métricas de carga lógica o con métricas físicas, como uso de memoria o CPU. En cualquier caso, Service Fabric supervisa la carga notificada de la métrica y evalúa el desencadenador periódicamente para determinar si se necesita el escalado.

Hay dos mecanismos compatibles actualmente con el escalado automático. El primero está pensado para servicios sin estado o para contenedores en los que el escalado automático se realiza agregando o quitando instancias. Para servicios con y sin estado, también se puede realizar el escalado automático agregando o quitando particiones con nombre del servicio.

Nota

Actualmente se admite una única directiva de escalado por servicio y solo un desencadenador de escalado por directiva de escalado.

Desencadenador de carga de partición media con escalado basado en instancias

El primer tipo de desencadenador se basa en la carga de instancias de una partición de servicio sin estado. En primer lugar, se suavizan las cargas de métricas para obtener la carga de cada instancia de una partición y, a continuación, se realiza la media de estos valores entre todas las instancias de la partición. Hay tres factores que determinan cuándo se escala el servicio:

  • Umbral de carga inferior es un valor que determina cuándo se escala el servicio en. Si la carga media de todas las instancias de las particiones es inferior a este valor, el servicio se escala.
  • Umbral de carga superior es un valor que determina cuándo se escalado horizontal del servicio. Si la carga media de todas las instancias de la partición es mayor que este valor, el servicio se escala horizontalmente.
  • Intervalo de escalado determina la frecuencia con la que se comprueba el desencadenador. Una vez comprobado el desencadenador, si se necesita el escalado, se aplica el mecanismo. Si no se necesita el escalado, no se realiza ninguna acción. En ambos casos, el desencadenador no se vuelve a comprobar antes de que expire de nuevo el intervalo de escalado.

Este desencadenador solo se puede usar con servicios sin estado (contenedores sin estado o servicios de Service Fabric). En caso de que un servicio tenga varias particiones, el desencadenador se evalúa para cada partición por separado y cada partición tiene el mecanismo especificado aplicado de forma independiente. Por lo tanto, los comportamientos de escalado de las particiones de servicio pueden variar en base de su carga. Es posible que algunas particiones del servicio se escalen horizontalmente, mientras que otras se escalan horizontalmente. Es posible que algunas particiones no se escalen al mismo tiempo.

El único mecanismo que se puede usar con este desencadenador es PartitionInstanceCountScaleMechanism. Hay tres factores que determinan cómo se aplica este mecanismo:

  • Incremento de escalado determina cuántas instancias se agregan o quitan cuando se desencadena el mecanismo.
  • El recuento máximo de instancias define el límite superior para el escalado. Si el número de instancias de la partición alcanza este límite, el servicio se escala horizontalmente, independientemente de la carga. Es posible omitir este límite especificando el valor -1 y, en ese caso, el servicio se escala horizontalmente tanto como sea posible (el límite es el número de nodos disponibles en el clúster).
  • El recuento mínimo de instancias define el límite inferior para el escalado. Si el número de instancias de la partición alcanza este límite, el servicio no se escala en independientemente de la carga.

Establecimiento de la directiva de escalado automático para el escalado basado en instancias

Uso del manifiesto de aplicación

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

Uso de las API de 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);

Usar 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

Desencadenador de carga de servicio media con escalado basado en particiones

El segundo desencadenador se basa en la carga de todas las particiones de un servicio. En primer lugar, se suavizan las cargas de métricas para obtener la carga de cada réplica o instancia de una partición. Para los servicios con estado, la carga de la partición es la carga de la réplica principal, mientras que para los servicios sin estado, la carga de la partición es la carga media de todas las instancias de la partición. Se realiza la media de estos valores entre todas las particiones del servicio y este valor se usa para desencadenar el escalado automático. Igual que en el mecanismo anterior, hay tres factores que determinan cuándo se escala el servicio:

  • Umbral de carga inferior es un valor que determina cuándo se escala el servicio en. Si la carga media de todas las particiones del servicio es inferior a este valor, el servicio se escala.
  • Umbral de carga superior es un valor que determina cuándo se escalado horizontal del servicio. Si la carga media de todas las particiones del servicio es mayor que este valor, el servicio se escala horizontalmente.
  • Intervalo de escalado determina la frecuencia con la que se comprueba el desencadenador. Una vez comprobado el desencadenador, si se necesita el escalado, se aplica el mecanismo. Si no se necesita el escalado, no se realiza ninguna acción. En ambos casos, el desencadenador se vuelve a comprobar antes de que expire el intervalo de escalado de nuevo.

Este desencadenador se puede usar con servicios con y sin estado. El único mecanismo que se puede usar con este desencadenador es AddRemoveIncrementalNamedPartitionScalingMechanism. Cuando el servicio se escala horizontalmente, se agrega una partición nueva, mientras que, cuando el servicio se reduce horizontalmente, se quita una de las particiones existentes. Hay restricciones que se comprueban cuando se crea o actualiza el servicio y se produce un error en la creación o actualización del servicio si no se cumplen estas condiciones:

  • El esquema de partición con nombre se debe usar para el servicio.
  • Los nombres de partición deben ser números enteros consecutivos, como "0", "1", ...
  • El nombre de la primera partición debe ser "0."

Por ejemplo, si un servicio se crea inicialmente con tres particiones, la única posibilidad válida para los nombres de la partición es "0", "1" y "2".

La operación de escalado automático real que se realiza respeta también este esquema de nomenclatura:

  • Si las particiones actuales del servicio se denominan "0", "1" y "2", la partición agregada para el escalado horizontal se denomina "3."
  • Si las particiones actuales del servicio se denominan "0", "1" y "2", la partición eliminada para el escalado en es la partición con el nombre "2."

Igual que el mecanismo que usa el escalado agregando o quitando instancias, hay tres parámetros que determinan cómo se aplica este mecanismo:

  • Incremento de escalado determina cuántas particiones se agregan o quitan cuando se desencadena el mecanismo.
  • El recuento máximo de particiones define el límite superior para el escalado. Si el número de particiones del servicio alcanza este límite, el servicio no se escala horizontalmente, independientemente de la carga. Es posible omitir este límite especificando el valor -1 y, en ese caso, el servicio se escala horizontalmente tanto como sea posible (el límite es la capacidad real del clúster).
  • Número mínimo de particiones define el límite inferior para el escalado. Si el número de particiones del servicio alcanza este límite, el servicio no se escala en independientemente de la carga.

Advertencia

Cuando se usa AddRemoveIncrementalNamedPartitionScalingMechanism con servicios con estado, Service Fabric agrega o quita las particiones sin ninguna notificación o advertencia. No se volverán a particionar los datos cuando se desencadene el mecanismo de escalado. En caso de una operación de escalado horizontal, las nuevas particiones estarán vacías y en el caso de una operación de reducción horizontal, la partición se eliminará junto con todos los datos que contiene.

Establecimiento de la directiva de escalado automático para el escalado basado en particiones

Uso del manifiesto de aplicación

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

Uso de las API de 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);

Usar 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

Escalado automático basado en recursos

Para permitir que el servicio de supervisión de recursos se escale en función de los recursos reales, puede agregar la característica ResourceMonitorService de la siguiente manera:

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

Service Fabric admite la gobernanza de CPU y memoria mediante dos métricas integradas: servicefabric:/_CpuCores para CPU y servicefabric:/_MemoryInMB para memoria. El servicio Resource Monitor es responsable de realizar un seguimiento del uso de CPU y memoria y actualizar Cluster Resource Manager con el uso actual de los recursos. Este servicio aplica una media móvil ponderada para tener en cuenta posibles picos de corta duración. La supervisión de recursos se admite tanto para aplicaciones en contenedores como para aplicaciones no contenerizadas en Windows y para aplicaciones en contenedor en Linux.

Nota:

El consumo de CPU y memoria supervisados en el servicio Resource Monitor y actualizados a Cluster Resource Manager no afectan a ningún proceso de toma de decisiones fuera del escalado automático. Si se necesita gobernanza de recursos, se puede configurar sin interferir con las funcionalidades de escalado automático y viceversa.

Importante

El escalado automático basado en recursos solo se admite para los servicios activados en el modelo de proceso exclusivo.

Pasos siguientes

Obtenga más información sobre la escalabilidad de aplicaciones.