Introduzione alla scalabilità automatica

La scalabilità automatica è un'altra funzionalità di Service Fabric per ridimensionare in modo dinamico i servizi in base al carico che i servizi segnalano o in base all'utilizzo delle risorse. Il ridimensionamento automatico offre un'elevata elasticità e consente il provisioning di istanze o partizioni aggiuntive del servizio su richiesta. L'intero processo di scalabilità automatica è automatizzato e trasparente e, dopo aver configurato i criteri in un servizio, non è necessario eseguire operazioni di ridimensionamento manuale a livello di servizio. La funzione di scalabilità automatica può essere attivata al momento della creazione del servizio o in qualsiasi momento tramite l'aggiornamento del servizio.

Uno scenario comune in cui il ridimensionamento automatico è utile è quando il carico su un determinato servizio varia nel tempo. Ad esempio, un servizio quale un gateway può essere ridimensionato in base all'ammontare delle risorse necessarie per gestire le richieste in ingresso. Esaminiamo una possibile regola di scalabilità:

• Se tutte le istanze del gateway usano in media più di due core, aumentare il numero di istanze del servizio gateway aggiungendo un'altra istanza. Eseguire questa aggiunta ogni ora, ma non avere mai più di sette istanze in totale.
• Se tutte le istanze del gateway utilizzano in media meno di 0,5 core, ridimensionare il servizio tramite la rimozione di un'istanza. Eseguire questa rimozione ogni ora, ma non avere mai meno di tre istanze in totale.

La scalabilità automatica è supportata sia per i contenitori sia per i normali servizi di Service Fabric. Per usare la scalabilità automatica è necessario che sia in esecuzione la versione 6.2 o versioni successive del runtime di Service Fabric.

Il resto di questo articolo descrive i criteri di scalabilità e le modalità per abilitare o disabilitare la scalabilità automatica; inoltre, fornisce alcuni esempi su come usare questa funzionalità.

Descrizione della scalabilità automatica

È possibile definire i criteri di scalabilità automatica per ogni servizio in un cluster di Service Fabric. Ogni criterio di scalabilità automatica è costituito da due parti:

• Il trigger di ridimensionamento descrive quando viene eseguita la scalabilità del servizio. Le condizioni definite nel trigger vengono controllate periodicamente per determinare se un servizio deve essere ridimensionato.

• Il meccanismo di ridimensionamento descrive come viene eseguita la scalabilità quando viene attivata. Il meccanismo viene applicato solo quando vengono soddisfatte le condizioni stabilite dal trigger.

Tutti i trigger che sono attualmente supportati funzionano con le metriche di carico logiche o con le metriche fisiche, quali l’utilizzo della CPU o della memoria. In entrambi i casi, Service Fabric monitora il carico segnalato per la metrica e valuta periodicamente il trigger per determinare se è necessaria la scalabilità.

Sono disponibili due meccanismi che sono attualmente supportati per la scalabilità automatica. Il primo è progettato per i servizi senza stato o per i contenitori in cui la scalabilità automatica viene eseguita aggiungendo o rimuovendo istanze. Per i servizi con stato e senza stato, la scalabilità automatica può essere eseguita anche tramite l'aggiunta o la rimozione di partizioni denominate del servizio.

Trigger di carico medio della partizione con scalabilità basata sull’istanza

Il primo tipo di trigger è basato sul carico delle istanze in una partizione del servizio senza stato. I carichi della metrica vengono innanzitutto livellati per ottenere il carico di ogni istanza di una partizione, quindi viene calcolata una media di questi valori per tutte le istanze della partizione. Esistono tre fattori che determinano quando il servizio viene ridimensionato:

• Una soglia di carico inferiore è un valore che determina quando il servizio viene ridimensionato. Se il carico medio di tutte le istanze delle partizioni è inferiore a questo valore, il servizio viene ridimensionato.
• La soglia di carico superiore è un valore che determina quando il servizio viene ridimensionato. Se il carico medio di tutte le istanze della partizione è superiore a questo valore, il servizio viene ridimensionato.
• L'intervallo di ridimensionamento determina la frequenza con cui viene controllato il trigger. Dopo aver controllato il trigger, se è necessario il ridimensionamento, viene applicato il meccanismo. Se il ridimensionamento non è necessario, non viene eseguita alcuna azione. In entrambi i casi, il trigger non viene nuovamente controllato prima che l'intervallo di ridimensionamento scada di nuovo.

Questo trigger può essere utilizzato solo con i servizi senza stato (contenitori senza stato o servizi di Service Fabric). Nel caso in cui un servizio abbia più partizioni, il trigger viene valutato separatamente per ogni partizione e a ogni partizione viene applicato il meccanismo specificato in modo indipendente. Di conseguenza, i comportamenti di ridimensionamento delle partizioni del servizio possono variare in base al carico. È possibile che alcune partizioni del servizio vengano ridimensionate, mentre altre vengono ridimensionate. Alcune partizioni potrebbero non essere ridimensionate contemporaneamente.

L'unico meccanismo che può essere utilizzato con questo trigger è PartitionInstanceCountScaleMechanism. Esistono tre fattori che determinano il modo in cui viene applicato questo meccanismo:

• L'incremento della scala determina il numero di istanze aggiunte o rimosse quando viene attivato il meccanismo.
• Il numero massimo di istanze definisce il limite superiore per la scalabilità. Se il numero di istanze della partizione raggiunge questo limite, il servizio viene ridimensionato, indipendentemente dal carico. È possibile omettere questo limite specificando il valore -1 e in tal caso il servizio viene ridimensionato il più possibile (il limite è il numero di nodi disponibili nel cluster).
• Il numero minimo di istanze definisce il limite inferiore per la scalabilità. Se il numero di istanze della partizione raggiunge questo limite, il servizio non viene ridimensionato indipendentemente dal carico.

Impostazione dei criteri di ridimensionamento automatico per il ridimensionamento basato su istanze

Tramite il manifesto dell'applicazione

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

Tramite le API 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);

Con 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

Trigger di carico medio del servizio con scalabilità basata sulla partizione

Il secondo tipo di trigger è basato sul carico di tutte le partizioni di un servizio. I carichi della metrica vengono innanzitutto livellati per ottenere il carico per ogni replica o istanza di una partizione. Per i servizi con stato, il carico della partizione è considerato il carico della replica primaria, mentre per i servizi senza stato il carico della partizione è il carico medio di tutte le istanze della partizione. Questi valori sono calcolati in media tra tutte le partizioni del servizio e questo valore viene utilizzato per attivare la scalabilità automatica. Come nel meccanismo precedente, esistono tre fattori che determinano quando il servizio viene ridimensionato:

• Una soglia di carico inferiore è un valore che determina quando il servizio viene ridimensionato. Se il carico medio di tutte le partizioni del servizio è inferiore a questo valore, il servizio viene ridimensionato.
• La soglia di carico superiore è un valore che determina quando il servizio viene ridimensionato. Se il carico medio di tutte le partizioni del servizio è superiore a questo valore, il servizio viene ridimensionato.
• L'intervallo di ridimensionamento determina la frequenza con cui viene controllato il trigger. Dopo aver controllato il trigger, se è necessario il ridimensionamento, viene applicato il meccanismo. Se il ridimensionamento non è necessario, non viene eseguita alcuna azione. In entrambi i casi, il trigger viene controllato di nuovo prima che l'intervallo di ridimensionamento scada di nuovo.

Questo trigger può essere utilizzato sia con i servizi con stato sia con i servizi senza stato. L'unico meccanismo che può essere usato con questo trigger è AddRemoveIncrementalNamedPartitionScalingMechanism. Quando il servizio viene aumentato, viene aggiunta una nuova partizione; quando il servizio viene ridotto, viene rimossa una delle partizioni esistenti. Quando viene creato o aggiornato il servizio, l'aggiornamento o la creazione o l'aggiornamento del servizio ha esito negativo se queste condizioni non vengono soddisfatte:

• Lo schema di partizione denominata deve essere utilizzato per il servizio.
• I nomi delle partizioni devono essere numeri interi consecutivi, ad esempio "0", "1", ...
• Il nome della prima partizione deve essere "0".

Ad esempio, se un servizio viene creato inizialmente con tre partizioni, gli unici possibili nomi validi per le partizioni sono "0", "1" e "2".

L'operazione di ridimensionamento automatico effettiva eseguita rispetta anche questo schema di denominazione:

• Se le partizioni correnti del servizio sono denominate "0", "1" e "2", la partizione aggiunta per il ridimensionamento orizzontale è denominata "3".
• Se le partizioni correnti del servizio sono denominate "0", "1" e "2", la partizione rimossa per il ridimensionamento è la partizione con nome "2".

Come per il meccanismo che usa la scalabilità per aggiungere o rimuovere istanze, esistono tre parametri che determinano il modo in cui viene applicato tale meccanismo:

• L'incremento della scala determina il numero di partizioni aggiunte o rimosse quando viene attivato il meccanismo.
• Il numero massimo di partizioni definisce il limite superiore per la scalabilità. Se il numero di partizioni del servizio raggiunge questo limite, il servizio non viene ridimensionato, indipendentemente dal carico. È possibile omettere questo limite specificando il valore -1 e in tal caso il servizio viene ridimensionato il più possibile (il limite è la capacità effettiva del cluster).
• Il numero minimo di partizioni definisce il limite inferiore per il ridimensionamento. Se il numero di partizioni del servizio raggiunge questo limite, il servizio non viene ridimensionato indipendentemente dal carico.

Impostazione dei criteri di ridimensionamento automatico per il ridimensionamento basato su partizioni

Tramite il manifesto dell'applicazione

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

Tramite le API 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);

Con 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

Ridimensionamento automatico in base alle risorse

Per abilitare il servizio di monitoraggio delle risorse per la scalabilità in base alle risorse effettive, è possibile aggiungere la ResourceMonitorService funzionalità come indicato di seguito:

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

Service Fabric supporta la governance della CPU e della memoria usando due metriche predefinite: servicefabric:/_CpuCores per LA CPU e servicefabric:/_MemoryInMB per la memoria. Il servizio Monitoraggio risorse è responsabile del rilevamento dell'utilizzo della CPU e della memoria e dell'aggiornamento di Cluster Resource Manager con l'utilizzo corrente delle risorse. Questo servizio applica una media mobile ponderata per tenere conto di potenziali picchi di breve durata. Il monitoraggio delle risorse è supportato sia per le applicazioni in contenitori che per le applicazioni non in contenitori in Windows e per le applicazioni in contenitori in Linux.

Passaggi successivi

Ulteriori informazioni sulla scalabilità delle applicazioni.