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

  • Artikel

Mått är de resurser som dina tjänster bryr sig om 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 prestanda för dina tjänster. Du kan till exempel titta på minnesförbrukning för att veta om tjänsten är överbelastad. En annan användning ä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 minne, disk och CPU-anvä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 vanligtvis är) logiska mått. Logiska mått är saker som "MyWorkQueueDepth" eller "MessagesToProcess" eller "TotalRecords". Logiska mått är programdefinierade och motsvarar indirekt viss fysisk resursförbrukning. Logiska mått är vanliga eftersom det kan vara svårt att mäta och rapportera förbrukning av fysiska resurser per tjänst. Komplexiteten med att mäta och rapportera dina egna fysiska mått är också anledningen till att Service Fabric tillhandahåller vissa standardmått.

Standardmått

Anta att du vill komma igång med att skriva och distribuera tjänsten. Nu vet du inte vilka fysiska eller logiska resurser som används. Det är ingen fara! Service Fabric-klustrets Resource Manager använder vissa standardmått när inga andra mått anges. De är:

  • PrimaryCount – antalet primära repliker på noden
  • ReplicaCount – antalet totala tillståndskänsliga repliker på noden
  • Count – antalet tjänstobjekt (tillståndslösa och tillståndskänsliga) på noden
Metric Tillståndslös instansinläsning Tillståndskänslig sekundär belastning Tillståndskänslig primär belastning Vikt
PrimaryCount 0 0 1 Högt
ReplicaCount 0 1 1 Medel
Antal 1 1 1 Låg

För grundläggande arbetsbelastningar ger standardmåtten en bra 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åndskänslig tjänst med tre partitioner och en målreplikuppsättning 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:

Klusterlayout med standardmått

Några saker att tänka på:

  • Primära repliker för den tillståndskänsliga tjänsten distribueras över flera noder
  • Repliker för samma partition finns på olika noder
  • Det totala antalet primär- och sekundärfiler 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 tar dig dock bara så långt. Till exempel: Vad är sannolikheten att partitioneringsschemat som 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 bara samma över flera partitioner just nu?

Du kan köra med bara standardmåtten. Detta innebär dock 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 likvärdigt. 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 användning av endast standardmått också resultera i överplanerade noder som resulterar i prestandaproblem. Om du är intresserad av att få ut mesta möjliga 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.

Alla 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 perspektiv.

Anteckning

Namn på anpassade mått får inte vara något av systemmåttnamnen, t.ex. servicefabric:/_CpuCores eller servicefabric:/_MemoryInMB eftersom det kan leda till odefinierat beteende. Från och med Service Fabric version 9.1 utfärdas en hälsovarning för befintliga tjänster med dessa anpassade måttnamn som anger att måttnamnet är felaktigt.

  • 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: Standardinläsningen representeras på olika sätt beroende på om tjänsten är tillståndslös eller tillståndskänslig.
    • För tillståndslösa tjänster har varje mått en enda egenskap med namnet DefaultLoad
    • För tillståndskänsliga tjänster definierar du:
      • PrimaryDefaultLoad: Standardmängden för det här måttet som den här tjänsten förbrukar när den är en primär
      • SecondaryDefaultLoad: Standardmängden för det här måttet som den här tjänsten förbrukar när den är sekundär

Anteckning

Om du definierar anpassade mått och vill använda standardmåtten måste du uttryckligen lägga till standardmåtten och definiera vikter och värden för dem. Det beror på att du måste definiera relationen mellan standardmåtten och dina anpassade mått. Du kanske till exempel bryr dig om ConnectionCount eller WorkQueueDepth mer än primär distribution. Som standard är vikten för Måttet PrimaryCount Hög, så du vill minska det till Medel när du lägger till dina andra mått för att säkerställa att de har företräde.

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ått och vet att normalt tar en primär replik av den tjänsten upp 20 enheter "ConnectionCount"
  • Sekundärfiler 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 just den här 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 vissa noder eller feldomäner påverkar en majoritet av de primära replikerna tillsammans med den.
  • Annars är standardmåtten bra

Här är koden som du skulle skriva för att skapa en tjänst med 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”)

Anteckning

I exemplen ovan och resten av det här dokumentet beskrivs hur du hanterar mått per namngiven tjänst. Du kan också definiera mått för dina tjänster på tjänsttypsnivå . Detta åstadkoms genom att ange dem i tjänstmanifesten. Att definiera mått på typnivå rekommenderas inte av flera skäl. Den första orsaken är att måttnamn ofta är miljöspecifika. Om det inte finns ett fast kontrakt på plats kan du inte vara säker på att måttet "Kärnor" i en miljö inte är "MiliCores" eller "CoReS" i andra. Om dina mått definieras i manifestet måste du skapa nya manifest per miljö. Detta leder vanligtvis till en spridning av olika manifest med endast mindre skillnader, vilket kan leda till hanteringsproblem.

Måttbelastningar tilldelas ofta per namngiven tjänstinstans. Anta till exempel att du skapar en instans av tjänsten för CustomerA som planerar att endast använda den lättvindigt. Anta också att du skapar en till för CustomerB som har en större arbetsbelastning. I det här fallet skulle du förmodligen vilja justera standardbelastningarna för dessa tjänster. Om du har mått och belastningar som definierats via manifest och du vill stödja det här scenariot kräver det olika program- och tjänsttyper för varje kund. Värdena som definieras när tjänsten skapas åsidosätter de som definierats i manifestet, så du kan använda det för att ange de specifika standardvärdena. Detta gör dock att de värden som deklareras i manifesten inte matchar de som tjänsten faktiskt körs med. Detta kan leda till förvirring.

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 i detalj och prata om det beteende som det påverkar.

Inläsning

Hela poängen med att definiera mått är att representera viss belastning. Belastning är hur mycket av ett visst mått som används av någon tjänstinstans eller replik på en viss nod. Belastningen kan konfigureras nästan när som helst. Exempel:

  • Belastning kan definieras när en tjänst skapas. Den här typen av inläsningskonfiguration kallas för standardinläsning.
  • Måttinformationen, inklusive standardinläsningar, 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.
  • Belastningarna för en viss partition kan återställas till standardvärdena för tjänsten. Den här måttuppdateringen kallas för återställning av partitionsbelastning.
  • Belastningen kan rapporteras per tjänstobjekt, dynamiskt under körning. Den här måttuppdateringen kallas för rapporteringsbelastning.
  • Belastningen 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 dess livstid.

Standardinläsning

Standardinläsning är hur mycket av måttet varje tjänstobjekt (tillståndslös instans eller tillståndskänslig replik) för den här tjänsten förbrukar. Klustret Resource Manager 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. Standardbelastningen uppdateras aldrig och används under tjänstens livslängd. Standardbelastningar fungerar bra för enkla scenarier för kapacitetsplanering där vissa mängder resurser är dedikerade till olika arbetsbelastningar och inte ändras.

Anteckning

Mer information om kapacitetshantering och definition av kapaciteter för noderna i klustret finns i den här artikeln.

Kluster Resource Manager tillåter tillståndskänsliga tjänster att ange en annan standardbelastning för sina primär- och sekundärfiler. Tillståndslösa tjänster kan bara ange ett värde som gäller för alla instanser. För tillståndskänsliga tjänster är standardbelastningen för primära och sekundära repliker vanligtvis olika eftersom repliker utför olika typer av arbete i varje roll. Till exempel hanterar primärval vanligtvis både läsningar och skrivningar och hanterar merparten av beräkningsbördan, medan sekundärfiler inte gör det. Vanligtvis är standardbelastningen för en primär replik högre än standardbelastningen för sekundära repliker. De verkliga talen bör vara beroende av dina egna mått.

Dynamisk belastning

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 belastningsfluktuationer. Till exempel är olika tjänster eller partitioner associerade med olika kunder med olika krav. Belastningen kan också ändras eftersom mängden arbete som tjänsten utfö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 mesta möjliga av klustret. Alla värden som du väljer för standardinläsning är fel en del av tiden. Felaktiga standardinläsningar resulterar i att klustret Resource Manager över eller under allokering av resurser. Därför har du noder som är över eller underutnyttjade trots att klustret Resource Manager tror att klustret är balanserat. Standardbelastningar är fortfarande bra eftersom de ger viss information för den första placeringen, men de är inte en fullständig berättelse för verkliga arbetsbelastningar. Om du vill samla in ändrade resurskrav korrekt kan klustrets Resource Manager varje tjänstobjekt uppdatera sin egen belastning under körningen. Detta kallas dynamisk inläsningsrapportering.

Med dynamiska inläsningsrapporter kan repliker eller instanser justera allokeringen/den rapporterade belastningen på mått under livslängden. En tjänstreplik eller instans som var kall och som inte utför något arbete rapporterar vanligtvis att den använde 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 klustret Resource Manager omorganisera de enskilda tjänstobjekten i klustret. Genom att organisera om tjänsterna ser du till att de får de resurser de behöver. Upptagna tjänster får effektivt "frigöra" 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 rapportinlä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 något av 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 har konfigurerats att använda ignorerar Service Fabric rapporten. Om det finns andra mått som rapporteras samtidigt som är giltiga godkänns dessa rapporter. Tjänstkoden kan mäta och rapportera alla mått som den vet hur, och operatörer kan ange den 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 rapporterar inläsningen själva. Det finns ytterligare ett alternativ för att dynamiskt rapportera inläsning för en partitions repliker eller instanser via Service Fabric API. När du rapporterar belastning för en partition kan du rapportera för flera partitioner samtidigt.

Dessa rapporter används på exakt samma sätt som läses in rapporter som kommer från replikerna eller instanserna själva. 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åndskänslig tjänstpartition kan uppdatera sin primära replikbelastning.
  • Både tillståndslösa och tillståndskänsliga tjänster kan uppdatera belastningen på alla dess sekundära repliker eller instanser.
  • Både tillståndslösa och tillståndskänsliga tjänster kan uppdatera belastningen på en specifik replik eller instans på en nod.

Det går också att kombinera någon av dessa uppdateringar per partition på samma gång. Kombination av belastningsuppdateringar för en viss partition bör anges via objektet PartitionMetricLoadDescription, som kan innehålla motsvarande lista över inläsningsuppdateringar som 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, som anges med ett måttnamn.

Anteckning

Förutsagda måttinläsningsvärden är för närvarande en förhandsversionsfunktion. Det gör att förutsagda inläsningsvärden kan rapporteras och användas på Service Fabric-sidan, men den funktionen är för närvarande inte aktiverad.

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

  • PartitionNotFound – angivet partitions-ID 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 – Sekundär replik eller instans 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 aktiverad.

Om några av dessa fel returneras kan du uppdatera indata för en specifik partition och försöka uppdatera 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 partitionen 53df3d7f-5471-403b-b736-bde6ad584f42. Den primära replikbelastningen för måttet CustomMetricName0 uppdateras med värdet 100. Samtidigt uppdateras belastningen 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 vikt 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åttkonfigurationen finns FabricClient.ServiceManagementClient.UpdateServiceAsync i C# och Update-ServiceFabricService 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 rapporter för dynamisk inläsning

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 klustret Resource Manager något att arbeta med. Med standardinläsningen kan kluster Resource Manager placera tjänstobjekten på bra platser när de skapas. Om ingen standardinläsningsinformation anges är placeringen av tjänsterna i praktiken slumpmässig. När inläsningsrapporter kommer senare är den första slumpmässiga placeringen ofta fel och kluster Resource Manager måste flytta tjänster.

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

Anteckning

Minne är ett av systemmåtten som Service Fabric kan resursstyra, och att rapportera det själv är vanligtvis svårt. Vi förväntar oss faktiskt inte att du rapporterar om minnesförbrukning; Minnet används här som ett hjälpmedel för att lära sig mer om funktionerna i kluster Resource Manager.

Anta att vi först skapade den tillståndskänsliga 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:

Klusterbalanserat med både standardmått och anpassade mått

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

  • Sekundära repliker i en partition kan ha sin egen belastning
  • Sammantaget ser måtten ut att vara balanserade. 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 ett förhållande på 1,75 var rimligt eller inte? Hur vet klustrets Resource Manager om det är tillräckligt bra eller om det finns mer arbete att göra?
  • När sker balanseringen?
  • Vad betyder det att minnet viktades "High"?

Måttvikter

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

Med måttvikter kan klustrets Resource Manager bestämma hur klustret ska balanseras när det inte finns något perfekt svar. Måttvikter gör det också möjligt för kluster Resource Manager att 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 ingenting med tanke på om saker och ting är balanserade eller inte. Belastningen bidrar dock fortfarande till kapacitetshantering. Mått med nollvikt ä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 användningen av mått för övervakning och diagnostik av dina tjänster.

Den verkliga effekten av olika måttvikter i klustret är att klustret Resource Manager genererar olika lösningar. Måttvikter anger för klustret Resource Manager att vissa mått är viktigare än andra. När det inte finns någon perfekt lösning kan kluster Resource Manager föredra lösningar som balanserar de högre viktade måtten bättre. Om en tjänst tycker att ett visst mått är oviktigt kan deras användning 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å några inläsningsrapporter och hur olika måttvikter resulterar i olika allokeringar i klustret. I det här exemplet ser vi att om du växlar den relativa vikten för måtten får klustret Resource Manager att skapa olika ordningar för tjänster.

Exempel på måttvikt och dess inverkan på balanseringslösningar

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 är alla tjänster som definierar MetricA den viktigaste (Vikt = Hög) och MetricB som oviktig (Vikt = Låg). Därför ser vi att klustret Resource Manager 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 ändrar vi måttvikterna. Därför växlar Cluster Resource Manager tjänsterna A och B för att komma fram till en allokering där MetricB är bättre balanserad än MetricA.

Anteckning

Måttvikter avgör hur klustrets Resource Manager ska balansera, men inte när utjämningen ska ske. Mer information om utjämning finns i den här artikeln

Globala måttvikter

Anta att ServiceA definierar MetricA som hög vikt, och ServiceB anger vikten för MetricA till Låg eller Noll. Vad är den faktiska vikten som används i slutänden?

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. Klustrets Resource Manager använder båda dessa vikter vid bedömning av lösningar. Att ta hänsyn till båda vikterna är viktigt. På så sätt kan klustrets Resource Manager balansera varje tjänst enligt sina egna prioriteringar och även se till att klustret som helhet allokeras korrekt.

Vad skulle hända om klustret Resource Manager inte brydde sig om både global och lokal balans? Det är enkelt att skapa lösningar som är globalt balanserade, men som resulterar i 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:

Effekten av en global lösning

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

I det nedre exemplet har kluster Resource Manager distribuerat replikerna baserat på både det globala saldot och saldot per tjänst. När du beräknar poängen för lösningen ger den största delen av vikten till den globala lösningen och en (konfigurerbar) del av enskilda tjänster. Det globala saldot för ett mått beräknas baserat på medelvärdet 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 enligt sina egna behov. Om samma första nod misslyckas distribueras felet därför över alla partitioner i alla tjänster. Påverkan på var och en är densamma.

Nästa steg