Úvod do automatického škálování

Automatické škálování je další funkcí Service Fabric pro dynamické škálování služeb na základě zatížení, které služby hlásí, nebo na základě jejich využití prostředků. Automatické škálování poskytuje velkou elasticitu a umožňuje zřizování dalších instancí nebo oddílů vaší služby na vyžádání. Celý proces automatického škálování je automatizovaný a transparentní a po nastavení zásad ve službě není nutné provádět ruční operace škálování na úrovni služby. Automatické škálování je možné zapnout buď při vytváření služby, nebo kdykoli aktualizací služby.

Běžným scénářem, kdy je automatické škálování užitečné, je, když se zatížení konkrétní služby v průběhu času liší. Například služba, jako je brána, se může škálovat na základě množství prostředků potřebných ke zpracování příchozích požadavků. Podívejme se na příklad toho, jak by tato pravidla škálování mohla vypadat:

  • Pokud všechny instance brány používají průměrně více než dvě jádra, můžete službu brány škálovat přidáním jedné další instance. Tento postup proveďte každou hodinu, ale nikdy nemáte celkem více než sedm instancí.
  • Pokud všechny instance brány používají průměrně méně než 0,5 jader, škálujte službu odebráním jedné instance. Toto odebrání proveďte každou hodinu, ale nikdy nemáte celkem méně než tři instance.

Automatické škálování se podporuje pro kontejnery i běžné služby Service Fabric. Abyste mohli používat automatické škálování, musíte běžet ve verzi 6.2 nebo vyšší modulu runtime Service Fabric.

Zbytek tohoto článku popisuje zásady škálování, způsoby povolení nebo zakázání automatického škálování a uvádí příklady použití této funkce.

Popis automatického škálování

Zásady automatického škálování je možné definovat pro každou službu v clusteru Service Fabric. Každá zásada škálování se skládá ze dvou částí:

  • Aktivační událost škálování popisuje, kdy se provádí škálování služby. Podmínky definované v triggeru se pravidelně kontrolují, aby se zjistilo, jestli se má služba škálovat nebo ne.

  • Mechanismus škálování popisuje, jak se škálování provádí při aktivaci. Mechanismus se použije pouze v případech, kdy jsou splněny podmínky z triggeru.

Všechny triggery, které jsou aktuálně podporované, fungují buď s metrikami logického zatížení, nebo s fyzickými metrikami, jako je využití procesoru nebo paměti. V obou případech Service Fabric monitoruje hlášené zatížení metriky a pravidelně vyhodnocuje trigger, aby zjistil, jestli je potřeba škálování.

Pro automatické škálování se v současné době podporují dva mechanismy. První je určený pro bezstavové služby nebo kontejnery, ve kterých se automatické škálování provádí přidáním nebo odebráním instancí. U stavových i bezstavových služeb je možné automatické škálování provádět také přidáním nebo odebráním pojmenovaných oddílů služby.

Poznámka:

V současné době existuje podpora pouze jedné zásady škálování na službu a pouze jedna aktivační událost škálování na zásadu škálování.

Průměrná aktivační událost zatížení oddílů se škálováním na základě instance

První typ triggeru je založený na zatížení instancí v bezstavovém oddílu služby. Načtení metriky se nejprve vyhladí, aby získalo zatížení pro každou instanci oddílu, a pak se tyto hodnoty zprůměrují napříč všemi instancemi oddílu. Existují tři faktory, které určují, kdy se služba škáluje:

  • Prahová hodnota nižšího zatížení je hodnota, která určuje, kdy se služba škáluje. Pokud je průměrné zatížení všech instancí oddílů nižší než tato hodnota, služba se škáluje.
  • Horní mezní hodnota zatížení je hodnota, která určuje, kdy se služba škáluje na více instancí. Pokud je průměrné zatížení všechinstancíchch
  • Interval škálování určuje, jak často se aktivační událost kontroluje. Jakmile se trigger zkontroluje, je-li potřeba provést škálování, použije se mechanismus. Pokud škálování není potřeba, neprovedou se žádné akce. V obou případech se trigger znovu nekontroluje, než vyprší platnost intervalu škálování znovu.

Tuto aktivační událost je možné použít pouze s bezstavovými službami (bezstavové kontejnery nebo služby Service Fabric). V případě, že má služba více oddílů, je aktivační událost vyhodnocena pro každý oddíl samostatně a každý oddíl má zadaný mechanismus použitý nezávisle na něm. Proto se chování škálování oddílů služby může lišit v závislosti na jejich zatížení. Je možné, že se některé oddíly služby škálují na více instancí, zatímco jiné se škálují na více instancí. Některé oddíly se nemusí škálovat najednou.

Jediným mechanismem, který lze použít s tímto triggerem, je PartitionInstanceCountScaleMechanism. Existují tři faktory, které určují způsob použití tohoto mechanismu:

  • Přírůstky škálování určují, kolik instancí se při aktivaci mechanismu přidá nebo odebere.
  • Maximální počet instancí definuje horní limit pro škálování. Pokud počet instancí oddílu dosáhne tohoto limitu, služba se škáluje na více instancí bez ohledu na zatížení. Tento limit je možné vynechat zadáním hodnoty -1 a v takovém případě se služba škáluje co nejvíce (limit je počet uzlů dostupných v clusteru).
  • Minimální počet instancí definuje nižší limit pro škálování. Pokud počet instancí oddílu dosáhne tohoto limitu, nebude služba škálována bez ohledu na zatížení.

Nastavení zásad automatického škálování pro škálování na základě instance

Použití manifestu aplikace

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

Použití rozhraní API jazyka 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);

Pomocí prostředí 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

Průměrná aktivační událost zatížení služby se škálováním na základě oddílů

Druhá aktivační událost je založená na zatížení všech oddílů jedné služby. Načtení metrik se nejprve vyhladí, aby se získalo zatížení pro každou repliku nebo instanci oddílu. U stavových služeb se zatížení oddílu považuje za zatížení primární repliky, zatímco u bezstavových služeb je zatížení oddílu průměrné zatížení všech instancí oddílu. Tyto hodnoty se průměrují napříč všemi oddíly služby a tato hodnota se používá k aktivaci automatického škálování. Stejně jako v předchozím mechanismu existují tři faktory, které určují, kdy se služba škáluje:

  • Prahová hodnota nižšího zatížení je hodnota, která určuje, kdy se služba škáluje. Pokud je průměrné zatížení všech oddílů služby nižší než tato hodnota, služba se škáluje.
  • Horní mezní hodnota zatížení je hodnota, která určuje, kdy se služba škáluje na více instancí. Pokud je průměrné zatížení všech oddílů služby vyšší než tato hodnota, služba se škáluje na více instancí.
  • Interval škálování určuje, jak často se aktivační událost kontroluje. Jakmile se trigger zkontroluje, je-li potřeba provést škálování, použije se mechanismus. Pokud škálování není potřeba, neprovedou se žádné akce. V obou případech se aktivační událost znovu zkontroluje před opětovnou platností intervalu škálování.

Tuto aktivační událost lze použít jak se stavovými, tak bezstavovými službami. Jediným mechanismem, který lze použít s tímto triggerem, je AddRemoveIncrementalNamedPartitionScalingMechanism. Když se služba škáluje na více instancí, přidá se nový oddíl a když se služba škáluje v jednom z existujících oddílů, odebere se. Při vytváření nebo aktualizaci služby se kontrolují omezení, pokud tyto podmínky nejsou splněné:

  • Pro službu se musí použít pojmenované schéma oddílů.
  • Názvy oddílů musí být po sobě jdoucí celá čísla, například 0, 1, ...
  • Název prvního oddílu musí být "0".

Pokud je například služba původně vytvořená se třemi oddíly, jedinou platnou možností pro názvy oddílů je "0", "1" a "2".

Skutečná operace automatického škálování, která se provádí, respektuje také toto schéma pojmenování:

  • Pokud jsou aktuální oddíly služby pojmenované "0", "1" a "2", pak se přidaný oddíl pro horizontální navýšení kapacity jmenuje "3".
  • Pokud jsou aktuální oddíly služby pojmenované "0", "1" a "2", oddíl odebraný pro horizontální navýšení kapacity je oddíl s názvem "2".

Stejné jako u mechanismu, který používá škálování přidáním nebo odebráním instancí, existují tři parametry, které určují způsob použití tohoto mechanismu:

  • Přírůstky škálování určují, kolik oddílů se při aktivaci mechanismu přidalo nebo odebralo.
  • Maximální počet oddílů definuje horní limit pro škálování. Pokud počet oddílů služby dosáhne tohoto limitu, služba se bez ohledu na zatížení škáluje. Tento limit je možné vynechat zadáním hodnoty -1 a v takovém případě se služba škáluje co nejvíce (limit je skutečná kapacita clusteru).
  • Minimální počet oddílů definuje nižší limit pro škálování. Pokud počet oddílů služby dosáhne tohoto limitu, nebude služba škálována bez ohledu na zatížení.

Upozorňující

Když se addRemoveIncrementalNamedPartitionScalingMechanism používá se stavovými službami, Service Fabric přidá nebo odebere oddíly bez oznámení nebo upozornění. Při aktivaci mechanismu škálování nebude provedeno opětovné rozdělení dat. V případě operace horizontálního navýšení kapacity budou nové oddíly prázdné a v případě operace škálování se oddíl odstraní společně se všemi daty, která obsahuje.

Nastavení zásad automatického škálování pro škálování na základě oddílů

Použití manifestu aplikace

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

Použití rozhraní API jazyka 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);

Pomocí prostředí 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

Automatické škálování na základě prostředků

Pokud chcete službě monitorování prostředků povolit škálování na základě skutečných prostředků, můžete tuto ResourceMonitorService funkci přidat následujícím způsobem:

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

Service Fabric podporuje zásady správného řízení procesoru a paměti pomocí dvou předdefinovaných metrik: servicefabric:/_CpuCores procesoru a servicefabric:/_MemoryInMB paměti. Služba Monitorování prostředků zodpovídá za sledování využití procesoru a paměti a aktualizaci Správce prostředků clusteru s aktuálním využitím prostředků. Tato služba používá vážený klouzavý průměr, aby zohlednila potenciální krátkodobé špičky. Monitorování prostředků je podporováno pro kontejnerizované i nekontejnerizované aplikace ve Windows i pro kontejnerizované aplikace v Linuxu.

Poznámka:

Využití procesoru a paměti monitorované ve službě Sledování prostředků a aktualizované na Správce prostředků clusteru nemá vliv na žádný rozhodovací proces mimo automatické škálování. Pokud je potřeba zásady správného řízení prostředků, můžete ho nakonfigurovat bez narušení funkcí automatického škálování a naopak.

Důležité

Automatické škálování založené na prostředcích se podporuje jenom pro služby aktivované ve výhradním modelu procesu.

Další kroky

Přečtěte si další informace o škálovatelnosti aplikací.