Udostępnij za pośrednictwem

Wprowadzenie do automatycznego skalowania

  • Artykuł

Automatyczne skalowanie to kolejna funkcja usługi Service Fabric umożliwiająca dynamiczne skalowanie usług na podstawie obciążenia, które są raportowane przez usługi lub na podstawie ich użycia zasobów. Skalowanie automatyczne zapewnia dużą elastyczność i umożliwia aprowizację dodatkowych wystąpień lub partycji usługi na żądanie. Cały proces automatycznego skalowania jest zautomatyzowany i przezroczysty, a po skonfigurowaniu zasad w usłudze nie ma potrzeby ręcznego skalowania na poziomie usługi. Automatyczne skalowanie można włączyć w czasie tworzenia usługi lub w dowolnym momencie przez zaktualizowanie usługi.

Typowym scenariuszem, w którym automatyczne skalowanie jest przydatne, jest to, że obciążenie określonej usługi różni się w czasie. Na przykład usługa taka jak brama może być skalowana na podstawie ilości zasobów niezbędnych do obsługi żądań przychodzących. Przyjrzyjmy się przykładowi tego, jak te reguły skalowania mogą wyglądać następująco:

  • Jeśli wszystkie wystąpienia bramy używają średnio więcej niż dwóch rdzeni, przeprowadź skalowanie w poziomie usługi bramy przez dodanie jeszcze jednego wystąpienia. Zrób to co godzinę, ale nigdy nie ma więcej niż siedmiu wystąpień w sumie.
  • Jeśli wszystkie wystąpienia bramy używają średnio mniej niż 0,5 rdzeni, przeprowadź skalowanie usługi, usuwając jedno wystąpienie. Zrób to usunięcie co godzinę, ale nigdy nie ma mniej niż trzech wystąpień w sumie.

Automatyczne skalowanie jest obsługiwane zarówno w przypadku kontenerów, jak i zwykłych usług Service Fabric. Aby można było używać skalowania automatycznego, należy uruchomić system w wersji 6.2 lub nowszej środowiska uruchomieniowego usługi Service Fabric.

W pozostałej części tego artykułu opisano zasady skalowania, sposoby włączania lub wyłączania automatycznego skalowania oraz przedstawiono przykłady użycia tej funkcji.

Opisywanie automatycznego skalowania

Zasady automatycznego skalowania można zdefiniować dla każdej usługi w klastrze usługi Service Fabric. Każda zasada skalowania składa się z dwóch części:

  • Wyzwalacz skalowania opisuje skalowanie usługi. Warunki zdefiniowane w wyzwalaczu są okresowo sprawdzane w celu określenia, czy usługa powinna być skalowana, czy nie.

  • Mechanizm skalowania opisuje sposób wykonywania skalowania po wyzwoleniu. Mechanizm jest stosowany tylko po spełnieniu warunków z wyzwalacza.

Wszystkie wyzwalacze, które są obecnie obsługiwane, działają z metrykami obciążenia logicznego lub z metrykami fizycznymi, takimi jak użycie procesora CPU lub pamięci. Tak czy inaczej usługa Service Fabric monitoruje zgłoszone obciążenie metryki i okresowo ocenia wyzwalacz w celu określenia, czy skalowanie jest potrzebne.

Istnieją dwa mechanizmy, które są obecnie obsługiwane do automatycznego skalowania. Pierwszy z nich jest przeznaczony dla usług bezstanowych lub kontenerów, w których skalowanie automatyczne jest wykonywane przez dodawanie lub usuwanie wystąpień. W przypadku usług stanowych i bezstanowych skalowanie automatyczne może być również wykonywane przez dodanie lub usunięcie nazwanych partycji usługi.

Uwaga

Obecnie istnieje obsługa tylko jednej zasady skalowania na usługę i tylko jeden wyzwalacz skalowania na zasady skalowania.

Średni wyzwalacz obciążenia partycji ze skalowaniem opartym na wystąpieniach

Pierwszy typ wyzwalacza jest oparty na obciążeniu wystąpień w partycji usługi bezstanowej. Obciążenia metryk są najpierw wygładzone w celu uzyskania obciążenia dla każdego wystąpienia partycji, a następnie te wartości są uśredniane we wszystkich wystąpieniach partycji. Istnieją trzy czynniki, które określają, kiedy usługa jest skalowana:

  • Niższy próg obciążenia to wartość, która określa, kiedy usługa jest skalowana. Jeśli średnie obciążenie wszystkich wystąpień partycji jest mniejsze niż ta wartość, usługa jest skalowana w poziomie.
  • Górny próg obciążenia to wartość określająca, kiedy usługa jest skalowana w poziomie. Jeśli średnie obciążenie wszystkich wystąpień partycji jest wyższe niż ta wartość, usługa jest skalowana w poziomie.
  • Interwał skalowania określa, jak często jest sprawdzany wyzwalacz. Po sprawdzeniu wyzwalacza, czy skalowanie jest wymagane, mechanizm jest stosowany. Jeśli skalowanie nie jest potrzebne, nie zostanie podjęta żadna akcja. W obu przypadkach wyzwalacz nie jest ponownie sprawdzany przed ponownym wygaśnięciem interwału skalowania.

Ten wyzwalacz może być używany tylko w przypadku usług bezstanowych (kontenerów bezstanowych lub usług Service Fabric). W przypadku, gdy usługa ma wiele partycji, wyzwalacz jest obliczany osobno dla każdej partycji, a każda partycja ma określony mechanizm zastosowany do niej niezależnie. W związku z tym zachowania skalowania partycji usługi mogą się różnić w zależności od ich obciążenia. Istnieje możliwość, że niektóre partycje usługi są skalowane w poziomie, podczas gdy niektóre inne są skalowane w poziomie. Niektóre partycje mogą nie być skalowane w ogóle w tym samym czasie.

Jedynym mechanizmem, który może być używany z tym wyzwalaczem, jest PartitionInstanceCountScaleMechanism. Istnieją trzy czynniki, które określają sposób stosowania tego mechanizmu:

  • Przyrost skalowania określa, ile wystąpień jest dodawanych lub usuwanych po wyzwoleniu mechanizmu.
  • Maksymalna liczba wystąpień definiuje górny limit skalowania. Jeśli liczba wystąpień partycji osiągnie ten limit, usługa zostanie przeskalowana w poziomie, niezależnie od obciążenia. Można pominąć ten limit, określając wartość -1, a w takim przypadku usługa jest skalowana w poziomie jak najwięcej (limit to liczba węzłów, które są dostępne w klastrze).
  • Minimalna liczba wystąpień definiuje niższy limit skalowania. Jeśli liczba wystąpień partycji osiągnie ten limit, usługa nie jest skalowana niezależnie od obciążenia.

Ustawianie zasad automatycznego skalowania dla skalowania opartego na wystąpieniach

Korzystanie z manifestu aplikacji

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

Korzystanie z interfejsów API języka 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);

Korzystanie z programu 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

Średni wyzwalacz obciążenia usługi ze skalowaniem na podstawie partycji

Drugi wyzwalacz jest oparty na obciążeniu wszystkich partycji jednej usługi. Obciążenia metryki są najpierw wygładzone w celu uzyskania obciążenia dla każdej repliki lub wystąpienia partycji. W przypadku usług stanowych obciążenie partycji jest uważane za obciążenie repliki podstawowej, podczas gdy w przypadku usług bezstanowych obciążenie partycji jest średnim obciążeniem wszystkich wystąpień partycji. Te wartości są uśrednione we wszystkich partycjach usługi, a ta wartość jest używana do wyzwalania automatycznego skalowania. Podobnie jak w poprzednim mechanizmie, istnieją trzy czynniki, które określają, kiedy usługa jest skalowana:

  • Niższy próg obciążenia to wartość, która określa, kiedy usługa jest skalowana. Jeśli średnie obciążenie wszystkich partycji usługi jest mniejsze niż ta wartość, usługa jest skalowana w poziomie.
  • Górny próg obciążenia to wartość określająca, kiedy usługa jest skalowana w poziomie. Jeśli średnie obciążenie wszystkich partycji usługi jest wyższe niż ta wartość, usługa jest skalowana w poziomie.
  • Interwał skalowania określa, jak często jest sprawdzany wyzwalacz. Po sprawdzeniu wyzwalacza, czy skalowanie jest wymagane, mechanizm jest stosowany. Jeśli skalowanie nie jest potrzebne, nie zostanie podjęta żadna akcja. W obu przypadkach wyzwalacz jest ponownie sprawdzany przed ponownym wygaśnięciem interwału skalowania.

Ten wyzwalacz może być używany zarówno z usługami stanowymi, jak i bezstanowymi. Jedynym mechanizmem, który może być używany z tym wyzwalaczem, jest AddRemoveIncrementalNamedPartitionScalingMechanism. Gdy usługa jest skalowana w poziomie, zostanie dodana nowa partycja, a gdy usługa zostanie skalowana w jednej z istniejących partycji, zostanie usunięta. Istnieją ograniczenia, które są sprawdzane, kiedy usługa jest tworzona lub aktualizowana, a tworzenie/aktualizowanie usługi kończy się niepowodzeniem, jeśli te warunki nie zostaną spełnione:

  • Nazwany schemat partycji musi być używany dla usługi.
  • Nazwy partycji muszą być kolejnymi liczbami całkowitymi, takimi jak "0", "1", ...
  • Nazwa pierwszej partycji musi mieć wartość "0".

Jeśli na przykład usługa jest początkowo tworzona z trzema partycjami, jedyną prawidłową możliwością dla nazw partycji jest "0", "1" i "2".

Rzeczywista operacja automatycznego skalowania, która jest wykonywana, uwzględnia również ten schemat nazewnictwa:

  • Jeśli bieżące partycje usługi mają nazwy "0", "1" i "2", partycja dodana do skalowania wyprzedaje nosi nazwę "3".
  • Jeśli bieżące partycje usługi mają nazwy "0", "1" i "2", partycja usunięta do skalowania w partycji to partycja o nazwie "2".

Podobnie jak w przypadku mechanizmu, który używa skalowania przez dodawanie lub usuwanie wystąpień, istnieją trzy parametry określające sposób stosowania tego mechanizmu:

  • Przyrost skalowania określa liczbę dodanych lub usuniętych partycji po wyzwoleniu mechanizmu.
  • Maksymalna liczba partycji definiuje górny limit skalowania. Jeśli liczba partycji usługi osiągnie ten limit, usługa nie jest skalowana w poziomie, niezależnie od obciążenia. Można pominąć ten limit, określając wartość -1, a w takim przypadku usługa jest skalowana w poziomie jak najwięcej (limit jest rzeczywistą pojemnością klastra).
  • Minimalna liczba partycji definiuje niższy limit skalowania. Jeśli liczba partycji usługi osiągnie ten limit, usługa nie jest skalowana niezależnie od obciążenia.

Ostrzeżenie

Gdy element AddRemoveIncrementalNamedPartitionScalingMechanism jest używany z usługami stanowymi, usługa Service Fabric doda lub usunie partycje bez powiadomienia lub ostrzeżenia. Ponowne partycjonowanie danych nie będzie wykonywane podczas wyzwalania mechanizmu skalowania. W przypadku operacji skalowania w poziomie nowe partycje będą puste, a w przypadku skalowania w operacji partycja zostanie usunięta wraz ze wszystkimi danymi, które zawiera.

Ustawianie zasad automatycznego skalowania na potrzeby skalowania na podstawie partycji

Korzystanie z manifestu aplikacji

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

Korzystanie z interfejsów API języka 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);

Korzystanie z programu 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

Automatyczne skalowanie na podstawie zasobów

Aby włączyć usługę monitorowania zasobów w celu skalowania na podstawie rzeczywistych zasobów, możesz dodać ResourceMonitorService tę funkcję w następujący sposób:

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

Usługa Service Fabric obsługuje ład procesora CPU i pamięci przy użyciu dwóch wbudowanych metryk: servicefabric:/_CpuCores dla procesora CPU i servicefabric:/_MemoryInMB pamięci. Usługa Monitor zasobów jest odpowiedzialna za śledzenie użycia procesora CPU i pamięci oraz aktualizowanie menedżera zasobów klastra przy użyciu bieżącego użycia zasobów. Ta usługa stosuje ważoną średnią ruchomą, aby uwzględnić potencjalne krótkotrwałe wzrosty. Monitorowanie zasobów jest obsługiwane zarówno w przypadku konteneryzowanych, jak i niekontenerowanych aplikacji w systemie Windows oraz dla konteneryzowanych aplikacji w systemie Linux.

Uwaga

Użycie procesora CPU i pamięci monitorowane w usłudze Monitor zasobów i zaktualizowane do menedżera zasobów klastra nie ma wpływu na żaden proces podejmowania decyzji poza skalowaniem automatycznym. Jeśli wymagany jest nadzór nad zasobami, można go skonfigurować bez zakłócania funkcji automatycznego skalowania i na odwrót.

Ważne

Automatyczne skalowanie oparte na zasobach jest obsługiwane tylko w przypadku usług aktywowanych w modelu procesu wyłącznego.

Następne kroki

Dowiedz się więcej o skalowalności aplikacji.