Hantera resursförbrukning och belastning i Service Fabric med mått

Mått är de resurser som dina tjänster är viktiga för och som tillhandahålls av noderna i klustret. Ett mått är allt som du vill hantera för att förbättra eller övervaka tjänsternas prestanda. Du kan till exempel titta på minnesförbrukning för att se om tjänsten är överbelastad. Ett annat sätt är att ta reda på om tjänsten kan flyttas någon annanstans där minnet är mindre begränsat för att få bättre prestanda.

Saker som minnes-, disk- och processoranvändning är exempel på mått. Dessa mått är fysiska mått, resurser som motsvarar fysiska resurser på noden som behöver hanteras. Mått kan också vara (och är ofta) logiska mått. Logiska mått är saker som "MyWorkQueueDepth" eller "MessagesToProcess" eller "TotalRecords". Logiska mått är programdefinierade och motsvarar indirekt en viss fysisk resursförbrukning. Logiska mått är vanliga eftersom det kan vara svårt att mäta och rapportera förbrukningen av fysiska resurser per tjänst. Komplexiteten med att mäta och rapportera dina egna fysiska mått är också anledningen Service Fabric tillhandahåller vissa standardmått.

Standardmått

Anta att du vill komma igång med att skriva och distribuera tjänsten. I det här läget vet du inte vilka fysiska eller logiska resurser den förbrukar. Det är ok! Den Service Fabric Klusterresurshanteraren använder vissa standardmått när inga andra mått har angetts. De är:

• PrimaryCount – antal primära repliker på noden
• ReplicaCount – antalet totalt antal tillståndsful replicas på noden
• Antal – antalet tjänstobjekt (tillståndslösa och tillståndslösa) på noden

För grundläggande arbetsbelastningar ger standardmåtten en rimlig fördelning av arbetet i klustret. I följande exempel ska vi se vad som händer när vi skapar två tjänster och förlitar oss på standardmåtten för utjämning. Den första tjänsten är en tillståndsfull tjänst med tre partitioner och en målreplikuppsättningsstorlek på tre. Den andra tjänsten är en tillståndslös tjänst med en partition och ett instansantal på tre.

Det här får vi:

Några saker att tänka på:

• Primära repliker för den tillståndsfulla tjänsten distribueras över flera noder
• Repliker för samma partition finns på olika noder
• Det totala antalet primär- och secondaries distribueras i klustret
• Det totala antalet tjänstobjekt allokeras jämnt på varje nod

Bra!

Standardmåtten fungerar bra som en början. Standardmåtten kommer dock bara att ha dig så långt. Exempel: Vad är sannolikheten att partitioneringsschemat du valde resulterar i perfekt jämn användning av alla partitioner? Vad är chansen att belastningen för en viss tjänst är konstant över tid eller till och med samma över flera partitioner just nu?

Du kan köra med bara standardmåtten. Men om du gör det innebär det vanligtvis att klusteranvändningen är lägre och mer ojämn än du vill. Det beror på att standardmåtten inte är anpassningsbara och förutsätter att allt är ekvivalent. Till exempel en primär som är upptagen och en som inte båda bidrar med "1" till måttet PrimaryCount. I värsta fall kan endast standardmåtten resultera i överplanerade noder, vilket resulterar i prestandaproblem. Om du är intresserad av att få ut mesta mesta av klustret och undvika prestandaproblem måste du använda anpassade mått och dynamisk belastningsrapportering.

Anpassade mått

Mått konfigureras per namngiven tjänstinstans när du skapar tjänsten.

Ett mått har vissa egenskaper som beskriver det: ett namn, en vikt och en standardbelastning.

• Måttnamn: Namnet på måttet. Måttnamnet är en unik identifierare för måttet i klustret från Resource Manager perspektivet.
• Vikt: Måttvikt definierar hur viktigt det här måttet är i förhållande till de andra måtten för den här tjänsten.
• Standardinläsning: Standardbelastningen representeras på olika sätt beroende på om tjänsten är tillståndslös eller tillståndsfull.
  • För tillståndslösa tjänster har varje mått en enda egenskap med namnet DefaultLoad
  • För tillståndsful-tjänster definierar du:
    • PrimaryDefaultLoad: Standardmängden för det här måttet som den här tjänsten använder när den är en primär
    • SecondaryDefaultLoad: Standardmängden för det här måttet som den här tjänsten använder när den är en sekundär

Definiera mått för din tjänst – ett exempel

Anta att du vill ha följande konfiguration:

• Din tjänst rapporterar ett mått med namnet "ConnectionCount"
• Du vill också använda standardmåtten
• Du har gjort några mätningar och vet att normalt tar en primär replik av tjänsten upp till 20 enheter av "ConnectionCount"
• De andra använder 5 enheter av "ConnectionCount"
• Du vet att "ConnectionCount" är det viktigaste måttet när det gäller att hantera prestanda för den här specifika tjänsten
• Du vill fortfarande att primära repliker ska balanseras. Att balansera primära repliker är vanligtvis en bra idé oavsett vad. Detta förhindrar att förlust av en nod eller feldomän påverkar en majoritet av de primära replikerna tillsammans med den.
• Annars fungerar standardmåtten bra

Här är den kod som du skulle skriva för att skapa en tjänst med den måttkonfigurationen:

Kod:

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
StatefulServiceLoadMetricDescription connectionMetric = new StatefulServiceLoadMetricDescription();
connectionMetric.Name = "ConnectionCount";
connectionMetric.PrimaryDefaultLoad = 20;
connectionMetric.SecondaryDefaultLoad = 5;
connectionMetric.Weight = ServiceLoadMetricWeight.High;

StatefulServiceLoadMetricDescription primaryCountMetric = new StatefulServiceLoadMetricDescription();
primaryCountMetric.Name = "PrimaryCount";
primaryCountMetric.PrimaryDefaultLoad = 1;
primaryCountMetric.SecondaryDefaultLoad = 0;
primaryCountMetric.Weight = ServiceLoadMetricWeight.Medium;

StatefulServiceLoadMetricDescription replicaCountMetric = new StatefulServiceLoadMetricDescription();
replicaCountMetric.Name = "ReplicaCount";
replicaCountMetric.PrimaryDefaultLoad = 1;
replicaCountMetric.SecondaryDefaultLoad = 1;
replicaCountMetric.Weight = ServiceLoadMetricWeight.Low;

StatefulServiceLoadMetricDescription totalCountMetric = new StatefulServiceLoadMetricDescription();
totalCountMetric.Name = "Count";
totalCountMetric.PrimaryDefaultLoad = 1;
totalCountMetric.SecondaryDefaultLoad = 1;
totalCountMetric.Weight = ServiceLoadMetricWeight.Low;

serviceDescription.Metrics.Add(connectionMetric);
serviceDescription.Metrics.Add(primaryCountMetric);
serviceDescription.Metrics.Add(replicaCountMetric);
serviceDescription.Metrics.Add(totalCountMetric);

await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Powershell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ConnectionCount,High,20,5”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Som en påminnelse: Om du bara vill använda standardmåtten behöver du inte röra måttsamlingen alls eller göra något speciellt när du skapar din tjänst. Standardmåtten används automatiskt när inga andra definieras.

Nu ska vi gå igenom var och en av de här inställningarna mer detaljerat och prata om det beteende som det påverkar.

Inläsning

Hela poängen med att definiera mått är att representera viss belastning. Belastningen är hur mycket av ett visst mått som förbrukas av en tjänstinstans eller replik på en viss nod. Belastningen kan konfigureras vid nästan vilken punkt som helst. Ett exempel:

• Inläsning kan definieras när en tjänst skapas. Den här typen av inläsningskonfiguration kallas för standardinläsning.
• Måttinformationen, inklusive standardinbelastningar, för en tjänst kan uppdateras när tjänsten har skapats. Den här måttuppdateringen görs genom att uppdatera en tjänst.
• Inbelastningar för en viss partition kan återställas till standardvärdena för den tjänsten. Den här måttuppdateringen kallas att återställa partitionsbelastningen.
• Belastningen kan rapporteras dynamiskt under körningen per tjänstobjekt. Den här måttuppdateringen kallas rapporteringsbelastning.
• Inläsning för partitionens repliker eller instanser kan också uppdateras genom att rapportera inläsningsvärden via ett Fabric API-anrop. Den här måttuppdateringen kallas rapporteringsbelastning för en partition.

Alla dessa strategier kan användas inom samma tjänst under hela livslängden.

Standardinläsning

Standardbelastningen är hur mycket av måttet som varje tjänstobjekt (tillståndslös instans eller tillståndsful replik) av den här tjänsten förbrukar. Den Klusterresurshanteraren använder det här numret för inläsningen av tjänstobjektet tills det tar emot annan information, till exempel en dynamisk inläsningsrapport. För enklare tjänster är standardbelastningen en statisk definition. Standardinläsningen uppdateras aldrig och används under tjänstens livslängd. Standardinbelastningar fungerar utmärkt för enkla kapacitetsplaneringsscenarier där vissa mängder resurser är dedikerade till olika arbetsbelastningar och inte ändras.

Med Klusterresurshanteraren tillståndsful-tjänster kan du ange en annan standardbelastning för deras primär- och de secondaries-tjänster. Tillståndslösa tjänster kan bara ange ett värde som gäller för alla instanser. För tillståndsful-tjänster är standardbelastningen för primära och sekundära repliker vanligtvis olika eftersom repliker gör olika typer av arbete i varje roll. Till exempel hanterarprimärfiler vanligtvis både läsningar och skrivningar, och hanterar det mesta av beräkningsbelastningen, medan de andra inte gör det. Standardbelastningen för en primär replik är vanligtvis högre än standardbelastningen för sekundära repliker. De verkliga talen bör bero på dina egna mått.

Dynamisk inläsning

Anta att du har kört tjänsten ett tag. Med viss övervakning har du märkt att:

1. Vissa partitioner eller instanser av en viss tjänst förbrukar mer resurser än andra
2. Vissa tjänster har belastning som varierar över tid.

Det finns många saker som kan orsaka dessa typer av belastningsvariationer. Olika tjänster eller partitioner är till exempel associerade med olika kunder med olika krav. Belastningen kan också ändras eftersom mängden arbete som tjänsten gör varierar under dagen. Oavsett orsak finns det vanligtvis inget enskilt tal som du kan använda som standard. Detta gäller särskilt om du vill få ut mest användning av klustret. Ett värde som du väljer för standardinläsning är fel en del av tiden. Felaktiga standardinbelastningar resulterar i att Klusterresurshanteraren över eller under allokerar resurser. Därför har du noder som är över- eller under utnyttjas även om Klusterresurshanteraren tror att klustret är balanserat. Standardinbelastningar är fortfarande bra eftersom de ger viss information för inledande placering, men de är inte en fullständig berättelse för verkliga arbetsbelastningar. För att korrekt avbilda föränderliga resurskrav kan Klusterresurshanteraren varje tjänstobjekt uppdatera sin egen belastning under körning. Detta kallas dynamisk inläsningsrapportering.

Med dynamiska inläsningsrapporter kan repliker eller instanser justera sin allokering/rapporterade belastning av mått under livslängden. En tjänstreplik eller instans som var kall och inte gjorde något arbete skulle vanligtvis rapportera att den använder låga mängder av ett visst mått. En upptagen replik eller instans rapporterar att de använder mer.

Rapporteringsbelastning per replik eller instans gör att Klusterresurshanteraren kan organisera om de enskilda tjänstobjekten i klustret. Omorganisering av tjänsterna hjälper till att säkerställa att de får de resurser som de behöver. Upptagna tjänster kan effektivt "återta" resurser från andra repliker eller instanser som för närvarande är kalla eller utför mindre arbete.

I Reliable Services ser koden för att rapportera inläsning dynamiskt ut så här:

Kod:

this.Partition.ReportLoad(new List<LoadMetric> { new LoadMetric("CurrentConnectionCount", 1234), new LoadMetric("metric1", 42) });

En tjänst kan rapportera om de mått som definierats för den när den skapas. Om en tjänst rapporterar inläsning för ett mått som den inte är konfigurerad att använda Service Fabric ignorerar den rapporten. Om andra mått rapporteras samtidigt som är giltiga godkänns dessa rapporter. Tjänstkoden kan mäta och rapportera alla mått som den vet hur den ska, och operatörer kan ange vilken måttkonfiguration som ska användas utan att behöva ändra tjänstkoden.

Rapporteringsbelastning för en partition

I föregående avsnitt beskrivs hur tjänstrepliker eller instanser av rapporten läses in själva. Det finns ytterligare ett alternativ för dynamisk rapportbelastning för en partitions repliker eller instanser via Service Fabric API. När du rapporterar belastningen för en partition kan du rapportera för flera partitioner samtidigt.

Dessa rapporter används på exakt samma sätt som inläsningsrapporter som kommer från själva replikerna eller instanserna. Rapporterade värden är giltiga tills nya inläsningsvärden rapporteras, antingen av repliken eller instansen eller genom att rapportera ett nytt inläsningsvärde för en partition.

Med det här API:et finns det flera sätt att uppdatera belastningen i klustret:

• En tillståndsfull tjänstpartition kan uppdatera den primära replikbelastningen.
• Både tillståndslösa och tillståndslösa tjänster kan uppdatera belastningen på alla sekundära repliker eller instanser.
• Både tillståndslösa och tillståndslösa tjänster kan uppdatera belastningen på en specifik replik eller instans på en nod.

Det är också möjligt att kombinera alla dessa uppdateringar per partition på samma gång. Kombinationen av inläsningsuppdateringar för en viss partition ska anges via objektet PartitionMetricLoadDescription, som kan innehålla motsvarande lista över inläsningsuppdateringar som det visas i exemplet nedan. Inläsningsuppdateringar representeras via objektet MetricLoadDescription, som kan innehålla aktuellt eller förutsagt belastningsvärde för ett mått, angivet med ett måttnamn.

Det går att uppdatera belastningar för flera partitioner med ett enda API-anrop, i vilket fall utdata innehåller ett svar per partition. Om partitionsuppdateringen inte har tillämpats av någon anledning hoppas uppdateringar för den partitionen över och motsvarande felkod för en målpartition tillhandahålls:

• PartitionNotFound – Det angivna partitions-ID:t finns inte.
• Omkonfiguration Väntar – Partitionen konfigureras för närvarande om.
• InvalidForStatelessServices – Ett försök gjordes att ändra belastningen på en primär replik för en partition som tillhör en tillståndslös tjänst.
• ReplicaDoesNotExist – Den sekundära repliken eller instansen finns inte på en angiven nod.
• InvalidOperation – Kan inträffa i två fall: uppdatering av belastningen för en partition som tillhör systemprogrammet eller uppdatering av förväntad belastning är inte aktiverat.

Om några av dessa fel returneras kan du uppdatera indata för en specifik partition och försöka uppdatera för den igen.

Kod:

Guid partitionId = Guid.Parse("53df3d7f-5471-403b-b736-bde6ad584f42");
string metricName0 = "CustomMetricName0";
List<MetricLoadDescription> newPrimaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 100)
};

string nodeName0 = "NodeName0";
List<MetricLoadDescription> newSpecificSecondaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 200)
};

OperationResult<UpdatePartitionLoadResultList> updatePartitionLoadResults =
    await this.FabricClient.UpdatePartitionLoadAsync(
        new UpdatePartitionLoadQueryDescription
        {
            PartitionMetricLoadDescriptionList = new List<PartitionMetricLoadDescription>()
            {
                new PartitionMetricLoadDescription(
                    partitionId,
                    newPrimaryReplicaLoads,
                    new List<MetricLoadDescription>(),
                    new List<ReplicaMetricLoadDescription>()
                    {
                        new ReplicaMetricLoadDescription(nodeName0, newSpecificSecondaryReplicaLoads)
                    })
            }
        },
        this.Timeout,
        cancellationToken);

I det här exemplet utför du en uppdatering av den senast rapporterade belastningen för en partition 53df3d7f-5471-403b-b736-bde6ad584f42. Den primära replikbelastningen för måttet CustomMetricName0 uppdateras med värdet 100. Samtidigt uppdateras inläsningen för samma mått för en specifik sekundär replik som finns på noden NodeName0 med värdet 200.

Uppdatera en tjänsts måttkonfiguration

Listan över mått som är associerade med tjänsten och egenskaperna för dessa mått kan uppdateras dynamiskt medan tjänsten är live. Detta möjliggör experimentering och flexibilitet. Några exempel på när detta är användbart är:

• inaktivera ett mått med en buggrapport för en viss tjänst
• konfigurera om måttens vikter baserat på önskat beteende
• aktivera ett nytt mått först när koden redan har distribuerats och verifierats via andra mekanismer
• ändra standardbelastningen för en tjänst baserat på observerat beteende och förbrukning

De viktigaste API:erna för att ändra måttkonfiguration FabricClient.ServiceManagementClient.UpdateServiceAsync finns i C# Update-ServiceFabricService och i PowerShell. Den information som du anger med dessa API:er ersätter den befintliga måttinformationen för tjänsten omedelbart.

Blanda standardinläsningsvärden och dynamiska inläsningsrapporter

Standardinläsning och dynamiska inläsningar kan användas för samma tjänst. När en tjänst använder både standardinläsningsrapporter och dynamiska inläsningsrapporter fungerar standardbelastningen som en uppskattning tills dynamiska rapporter visas. Standardinläsningen är bra eftersom den ger Klusterresurshanteraren något att arbeta med. Standardbelastningen gör att Klusterresurshanteraren kan placera tjänstobjekten på bra platser när de skapas. Om ingen standardinläsningsinformation anges är placeringen av tjänster i praktiken slumpmässig. När inläsningsrapporter kommer senare är den inledande slumpmässiga placeringen ofta felaktig och Klusterresurshanteraren måste flytta tjänster.

Låt oss ta vårt föregående exempel och se vad som händer när vi lägger till några anpassade mått och dynamisk belastningsrapportering. I det här exemplet använder vi "MemoryInMb" som exempelmått.

Vi antar att vi först skapade den tillståndsful-tjänsten med följande kommando:

Powershell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("MemoryInMb,High,21,11”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Som en påminnelse är den här syntaxen ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

Nu ska vi se hur en möjlig klusterlayout kan se ut:

Några saker som är värda att notera:

• Sekundära repliker inom en partition kan ha sin egen belastning
• De övergripande måtten ser balanserade ut. För minne är förhållandet mellan den högsta och lägsta belastningen 1,75 (noden med mest belastning är N3, minst N2 och 28/16 = 1,75).

Det finns några saker som vi fortfarande behöver förklara:

• Vad fastställde om förhållandet 1,75 var rimligt eller inte? Hur vet Klusterresurshanteraren om det är tillräckligt bra eller om det finns mer arbete att göra?
• När sker belastningsutjämning?
• Vad betyder det att minne viktades "Högt"?

Måttvikter

Det är viktigt att spåra samma mått för olika tjänster. Den globala vyn är det som gör att Klusterresurshanteraren kan spåra förbrukning i klustret, balansera förbrukning mellan noder och se till att noderna inte går över kapaciteten. Tjänsterna kan dock ha olika vyer vad gäller vikten av samma mått. I ett kluster med många mått och många tjänster kanske dessutom perfekt balanserade lösningar inte finns för alla mått. Hur ska Klusterresurshanteraren hantera dessa situationer?

Med måttvikter kan Klusterresurshanteraren bestämma hur klustret ska balanseras när det inte finns något perfekt svar. Måttvikter gör också att Klusterresurshanteraren kan balansera specifika tjänster på olika sätt. Mått kan ha fyra olika viktnivåer: Noll, Låg, Medel och Hög. Ett mått med en vikt på noll bidrar inte med något när du överväger om saker är balanserade eller inte. Belastningen bidrar dock fortfarande till kapacitetshantering. Mått med noll vikt är fortfarande användbara och används ofta som en del av tjänstens beteende och prestandaövervakning. Den här artikeln innehåller mer information om hur du använder mått för övervakning och diagnostik av dina tjänster.

Den verkliga effekten av olika måttvikter i klustret är att Klusterresurshanteraren genererar olika lösningar. Måttvikter visar Klusterresurshanteraren vissa mått är viktigare än andra. När det inte finns någon perfekt lösning kan Klusterresurshanteraren lösningar som balanserar de högre viktade måtten bättre. Om en tjänst anser att ett visst mått är oviktigt kan användningen av måttet vara obalanserad. Detta gör att en annan tjänst kan få en jämn fördelning av vissa mått som är viktiga för den.

Nu ska vi titta på ett exempel på vissa inläsningsrapporter och hur olika måttvikter resulterar i olika allokeringar i klustret. I det här exemplet ser vi att växling av måttens relativa vikt gör att Klusterresurshanteraren skapa olika tjänster.

I det här exemplet finns det fyra olika tjänster som alla rapporterar olika värden för två olika mått, MetricA och MetricB. I ett fall definierar alla tjänster MetricA som det viktigaste (Vikt = Hög) och MetricB som oviktigt (Vikt = Låg). Därför ser vi att Klusterresurshanteraren placerar tjänsterna så att MetricA är bättre balanserat än MetricB. "Bättre balanserad" innebär att MetricA har en lägre standardavvikelse än MetricB. I det andra fallet omvänder vi måttvikterna. Därför växlar Klusterresurshanteraren tjänster A och B för att få fram en allokering där MetricB är bättre balanserat än MetricA.

Globala måttvikter

Låt oss säga att ServiceA definierar MetricA som weight High (hög vikt) och Att ServiceB anger vikten för MetricA till Low (Låg) eller Zero (noll). Vad är den faktiska vikt som används?

Det finns flera vikter som spåras för varje mått. Den första vikten är den som definieras för måttet när tjänsten skapas. Den andra vikten är en global vikt som beräknas automatiskt. Den Klusterresurshanteraren använder båda dessa vikter vid bedömningslösningar. Det är viktigt att ta hänsyn till båda vikterna. Detta gör att Klusterresurshanteraren kan balansera varje tjänst enligt sina egna prioriteringar och även se till att klustret som helhet allokeras korrekt.

Vad skulle hända om Klusterresurshanteraren inte bryr sig om både global och lokal balans? Det är enkelt att skapa lösningar som är globalt balanserade, men som leder till dålig resursbalans för enskilda tjänster. I följande exempel ska vi titta på en tjänst som konfigurerats med bara standardmåtten och se vad som händer när endast globalt saldo beaktas:

I det översta exemplet som endast baseras på global balans är klustret som helhet verkligen balanserat. Alla noder har samma antal försök och samma totala antal repliker. Men om du tittar på den faktiska effekten av den här allokeringen är den inte så bra: förlusten av en nod påverkar en viss arbetsbelastning oproportionerligt, eftersom den tar bort alla sina försök. Om den första noden till exempel misslyckas går de tre försöken för de tre olika partitionerna i Circle-tjänsten förlorade. Omvänt förlorar tjänsterna Triangle och Sexhörning sina partitioner en replik. Detta orsakar inga avbrott, förutom att du behöver återställa repliken som är nere.

I det nedre exemplet har Klusterresurshanteraren distribuerat replikerna baserat på både det globala saldot och per tjänst-saldot. Vid beräkning av poängen för lösningen ger den största delen av vikten till den globala lösningen och en (konfigurerbar) del till enskilda tjänster. Det globala saldot för ett mått beräknas baserat på genomsnittet av måttvikterna från varje tjänst. Varje tjänst balanseras enligt sina egna definierade måttvikter. Detta säkerställer att tjänsterna balanseras inom sig själva utifrån sina egna behov. Därför distribueras felet över alla partitioner för alla tjänster om samma första nod misslyckas. Påverkan på var och en är densamma.

Nästa steg

• Mer information om hur du konfigurerar tjänster finns i Lär dig hur dukonfigurerar tjänster (service-fabric-cluster-resource-manager-configure-services.md)
• Att definiera defragmenteringsmått är ett sätt att konsolidera belastningen på noder i stället för att sprida ut den. Information om hur du konfigurerar defragmentering finns i den här artikeln
• Mer information om hur Klusterresurshanteraren hanterar och balanserar belastningen i klustret finns i artikeln om belastningsutjämning
• Börja från början och få en introduktion till Service Fabric Klusterresurshanteraren
• Rörelsekostnad är ett sätt att signalera till Klusterresurshanteraren att vissa tjänster är dyrare att flytta än andra. Mer information om rörelsekostnader finns i den här artikeln