Resourceverbruik en -belasting beheren in Service Fabric met metrische gegevens

Metrische gegevens zijn de resources die uw services belangrijk vinden en die worden geleverd door de knooppunten in het cluster. Een metriek is alles wat u wilt beheren om de prestaties van uw services te verbeteren of te bewaken. U kunt bijvoorbeeld het geheugenverbruik bekijken om te weten te komen of uw service overbelast is. Een ander gebruik is om te bepalen of de service kan worden verplaatst naar een andere plek waar het geheugen minder beperkt is om betere prestaties te krijgen.

Zaken zoals geheugen, schijf en CPU-gebruik zijn voorbeelden van metrische gegevens. Deze metrische gegevens zijn fysieke metrische gegevens, resources die overeenkomen met fysieke resources op het knooppunt die moeten worden beheerd. Metrische gegevens kunnen ook logische metrische gegevens zijn (en zijn meestal) logische metrische gegevens. Logische metrische gegevens zijn bijvoorbeeld 'MyWorkQueueDepth' of 'MessagesToProcess' of 'TotalRecords'. Logische metrische gegevens zijn door de toepassing gedefinieerd en komen indirect overeen met een bepaald fysiek resourceverbruik. Logische metrische gegevens zijn gebruikelijk omdat het lastig kan zijn om het verbruik van fysieke resources per service te meten en te rapporteren. De complexiteit van het meten en rapporteren van uw eigen fysieke metrische gegevens is ook de reden Service Fabric een aantal standaard metrische gegevens biedt.

Standaard metrische gegevens

Stel dat u aan de slag wilt met het schrijven en implementeren van uw service. Op dit moment weet u niet welke fysieke of logische resources er worden gebruikt. Dat is prima. De Service Fabric Cluster Resource Manager gebruikt enkele standaard metrische gegevens wanneer er geen andere metrische gegevens worden opgegeven. Dit zijn:

• PrimaryCount: aantal primaire replica's op het knooppunt
• ReplicaCount: het totale aantal stateful replica's op het knooppunt
• Aantal: het aantal serviceobjecten (staatloos en stateful) op het knooppunt

Voor basisworkloads bieden de standaard metrische gegevens een goede verdeling van het werk in het cluster. In het volgende voorbeeld zien we wat er gebeurt wanneer we twee services maken en vertrouwen op de standaard metrische gegevens voor taakverdeling. De eerste service is een stateful service drie partities en een doelreplicasetgrootte van drie. De tweede service is een stateless service met één partitie en een aantal exemplaren van drie.

Dit is het resultaat:

Let op het volgende:

• Primaire replica's voor de stateful service worden verdeeld over verschillende knooppunten
• Replica's voor dezelfde partitie staan op verschillende knooppunten
• Het totale aantal voorverzendingen en secondaries wordt gedistribueerd in het cluster
• Het totale aantal serviceobjecten wordt gelijkmatig toegewezen op elk knooppunt

Goede!

De standaard metrische gegevens werken als eerste goed. De standaard metrische gegevens zijn tot nu toe echter alleen beschikbaar. Bijvoorbeeld: Wat is de kans dat het partitieschema dat u hebt opgehaald perfect gelijkmatig wordt gebruikt door alle partities? Wat is de kans dat de belasting voor een bepaalde service constant is gedurende een bepaalde periode of zelfs op dit moment precies hetzelfde is voor meerdere partities?

U kunt uitvoeren met alleen de standaard metrische gegevens. Dit betekent echter meestal dat het clustergebruik lager en ongelijker is dan u zou willen. Dit komt doordat de standaard metrische gegevens niet adaptief zijn en ervan wordt uitgegaan dat alles gelijk is. Bijvoorbeeld een primaire die bezet is en een die niet beide '1' bijdraagt aan de metrische gegevens primarycount. In het ergste geval kan het gebruik van alleen de standaard metrische gegevens ook leiden tot achterstallige knooppunten, wat leidt tot prestatieproblemen. Als u het meeste uit uw cluster wilt krijgen en prestatieproblemen wilt voorkomen, moet u aangepaste metrische gegevens en dynamische belastingsrapportage gebruiken.

Aangepaste metrische gegevens

Metrische gegevens worden per benoemde service-instantie geconfigureerd wanneer u de service maakt.

Elk metrisch gegeven heeft enkele eigenschappen die dit beschrijven: een naam, een gewicht en een standaardbelasting.

• Metrische naam: de naam van de metrische gegevens. De naam van het metrische gegeven is een unieke id voor de metrische gegevens binnen het cluster vanuit Resource Manager perspectief van de organisatie.
• Gewicht: Het metrische gewicht definieert hoe belangrijk deze metrische waarde is ten opzichte van de andere metrische gegevens voor deze service.
• Standaardbelasting: de standaardbelasting wordt anders weergegeven, afhankelijk van of de service staatloos of stateful is.
  • Voor staatloze services heeft elke metrische waarde één eigenschap met de naam DefaultLoad
  • Voor stateful services definieert u:
    • PrimaryDefaultLoad: de standaardwaarde van deze metrische gegevens die deze service verbruikt wanneer deze een primaire is
    • SecondaryDefaultLoad: de standaardwaarde van deze metrische gegevens die deze service verbruikt wanneer het een secundaire is

Metrische gegevens voor uw service definiëren - een voorbeeld

Stel dat u de volgende configuratie wilt:

• Uw service rapporteert metrische gegevens met de naam ConnectionCount
• U wilt ook de standaard metrische gegevens gebruiken
• U hebt enkele metingen uitgevoerd en weet dat een primaire replica van die service normaal gesproken 20 eenheden van 'ConnectionCount' in gebruik neemt
• Secondaries gebruiken 5 eenheden van 'ConnectionCount'
• U weet dat ConnectionCount de belangrijkste metrische gegevens is voor het beheren van de prestaties van deze specifieke service
• U wilt nog steeds dat primaire replica's evenwichtig zijn. Het is over het algemeen een goed idee om een balans te vinden tussen primaire replica's. Dit helpt te voorkomen dat een of meer knooppunt- of foutdomeinen een meerderheid van de primaire replica's beïnvloeden.
• Anders zijn de standaard metrische gegevens prima

Dit is de code die u zou schrijven om een service te maken met die metrische configuratie:

Code:

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

Ter herinnering: als u alleen de standaard metrische gegevens wilt gebruiken, hoeft u de verzameling met metrische gegevens helemaal niet aan te raken of iets speciaals te doen bij het maken van uw service. De standaard metrische gegevens worden automatisch gebruikt wanneer er geen andere zijn gedefinieerd.

Laten we nu elk van deze instellingen in meer detail bekijken en het gedrag bespreken dat het beïnvloedt.

Laden

Het hele punt van het definiëren van metrische gegevens is om een bepaalde belasting weer te geven. Belasting is hoeveel van een bepaald metrisch gegeven wordt verbruikt door een service-exemplaar of replica op een bepaald knooppunt. De belasting kan op vrijwel elk moment worden geconfigureerd. Bijvoorbeeld:

• Laden kan worden gedefinieerd wanneer een service wordt gemaakt. Dit type belastingsconfiguratie wordt standaardbelasting genoemd.
• De metrische gegevens, inclusief standaardbelastingen, voor een service kunnen worden bijgewerkt nadat de service is gemaakt. Deze metrische update wordt uitgevoerd door een service bij te werken.
• De belastingen voor een bepaalde partitie kunnen worden ingesteld op de standaardwaarden voor die service. Deze update van metrische gegevens wordt het opnieuw instellen van de partitiebelasting genoemd.
• De belasting kan dynamisch worden gerapporteerd per serviceobject tijdens runtime. Deze metrische update wordt rapportagebelasting genoemd.
• De belasting voor de replica's of exemplaren van de partitie kan ook worden bijgewerkt door belastingswaarden te rapporteren via een Fabric-API-aanroep. Deze update van metrische gegevens wordt rapportagebelasting genoemd voor een partitie.

Al deze strategieën kunnen gedurende de levensduur binnen dezelfde service worden gebruikt.

Standaardbelasting

Standaardbelasting is hoeveel van de metrische gegevens elk serviceobject (staatloze instantie of stateful replica) van deze service verbruikt. De Cluster Resource Manager gebruikt dit nummer voor de belasting van het serviceobject totdat het andere informatie ontvangt, zoals een dynamisch belastingsrapport. Voor eenvoudigere services is de standaardbelasting een statische definitie. De standaardbelasting wordt nooit bijgewerkt en wordt gebruikt voor de levensduur van de service. Standaardbelasting werkt prima voor eenvoudige scenario's voor capaciteitsplanning waarbij bepaalde hoeveelheden resources zijn toegewezen aan verschillende workloads en niet worden gewijzigd.

De Cluster Resource Manager staat stateful services toe om een andere standaardbelasting op te geven voor hun voorvertalingen en secondaire bestanden. Staatloze services kunnen slechts één waarde opgeven die van toepassing is op alle exemplaren. Voor stateful services is de standaardbelasting voor primaire en secundaire replica's doorgaans verschillend, omdat replica's verschillende soorten werk in elke rol doen. Primaries dienen bijvoorbeeld meestal zowel lees- als schrijfwerk, en verwerken het grootste deel van de rekenbelasting, terwijl de tweede-bestanden dat niet doen. Meestal is de standaardbelasting voor een primaire replica hoger dan de standaardbelasting voor secundaire replica's. De werkelijke getallen moeten afhankelijk zijn van uw eigen metingen.

Dynamische belasting

Stel dat u uw service al een tijdje gebruikt. Met enige bewaking hebt u het volgende opgemerkt:

1. Sommige partities of exemplaren van een bepaalde service verbruiken meer resources dan andere
2. Sommige services hebben een belasting die in de tijd varieert.

Er zijn veel dingen die dit soort belastings fluctuaties kunnen veroorzaken. Verschillende services of partities zijn bijvoorbeeld gekoppeld aan verschillende klanten met verschillende vereisten. De belasting kan ook veranderen omdat de hoeveelheid werk die de service doet, in de loop van de dag varieert. Ongeacht de reden is er meestal geen enkel getal dat u voor de standaardinstelling kunt gebruiken. Dit geldt met name als u het meeste gebruik uit het cluster wilt halen. Elke waarde die u kiest voor standaardbelasting is een deel van de tijd onjuist. Onjuiste standaardbelastingen resulteren in de Cluster Resource Manager of onder het toewijzen van resources. Als gevolg hiervan hebt u knooppunten die boven of onder worden gebruikt, zelfs als de Cluster Resource Manager denkt dat het cluster evenwichtig is. Standaardbelastingen zijn nog steeds goed omdat ze enige informatie bieden voor de initiële plaatsing, maar ze zijn geen volledig verhaal voor echte workloads. Als u de veranderende resourcevereisten nauwkeurig wilt vastleggen, Cluster Resource Manager elk serviceobject de eigen belasting tijdens runtime bijwerken. Dit wordt dynamische belastingsrapportage genoemd.

Met dynamische laadrapporten kunnen replica's of exemplaren hun toewijzing/gerapporteerde belasting van metrische gegevens gedurende hun levensduur aanpassen. Een servicereplica of exemplaar dat niet goed werkt, meldt meestal dat er weinig metrische gegevens worden gebruikt. Een bezette replica of instantie zou rapporteren dat er meer worden gebruikt.

Door de belasting per replica of instantie te rapporteren, Cluster Resource Manager de afzonderlijke serviceobjecten in het cluster opnieuw indelen. Door de services opnieuw in te delen, kunnen ze ervoor zorgen dat ze de resources krijgen die ze nodig hebben. Bezette services kunnen resources effectief 'vrij maken' van andere replica's of instanties die momenteel niet werken of minder werk doen.

Binnen Reliable Services ziet de code voor het dynamisch laden van het rapport er als volgende uit:

Code:

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

Een service kan rapporteren over een van de metrische gegevens die voor de service zijn gedefinieerd tijdens het maken. Als een service een belasting rapporteert voor een metrische gegevens die niet is geconfigureerd voor gebruik, Service Fabric dat rapport genegeerd. Als er op hetzelfde moment andere metrische gegevens worden gerapporteerd die geldig zijn, worden deze rapporten geaccepteerd. Servicecode kan alle metrische gegevens meten en rapporteren, en operators kunnen de te gebruiken metrische configuratie opgeven zonder de servicecode te wijzigen.

Rapportagebelasting voor een partitie

In de vorige sectie wordt beschreven hoe servicereplica's of exemplaren zelf laden. Er is een extra optie voor het dynamisch rapporteren van de belasting voor replica's of exemplaren van een partitie via Service Fabric API. Wanneer u de belasting voor een partitie rapporteert, kunt u rapporteren voor meerdere partities tegelijk.

Deze rapporten worden op exact dezelfde manier gebruikt als het laden van rapporten die afkomstig zijn van de replica's of exemplaren zelf. Gerapporteerde waarden zijn geldig totdat nieuwe laadwaarden worden gerapporteerd, ofwel door de replica of het exemplaar, ofwel door een nieuwe belastingswaarde voor een partitie te rapporteren.

Met deze API zijn er meerdere manieren om de belasting in het cluster bij te werken:

• Een stateful service partitie kan de primaire replicabelasting bijwerken.
• Staatloze en stateful services kunnen de belasting van alle secundaire replica's of exemplaren bijwerken.
• Staatloze en stateful services kunnen de belasting van een specifieke replica of instantie op een knooppunt bijwerken.

Het is ook mogelijk om een van deze updates per partitie tegelijk te combineren. Een combinatie van load-updates voor een bepaalde partitie moet worden opgegeven via het object PartitionMetricLoadDescription, dat de bijbehorende lijst met belastingsupdates kan bevatten, zoals wordt weergegeven in het onderstaande voorbeeld. Laadupdates worden weergegeven via het object MetricLoadDescription, dat de huidige of voorspelde belastingswaarde voor een metrische waarde kan bevatten, opgegeven met een metrische naam.

Het bijwerken van de belasting voor meerdere partities is mogelijk met één API-aanroep. In dat geval bevat de uitvoer een antwoord per partitie. Als partitie-update om welke reden dan ook niet wordt toegepast, worden updates voor die partitie overgeslagen en wordt de bijbehorende foutcode voor een doelpartitie verstrekt:

• PartitionNotFound: de opgegeven partitie-id bestaat niet.
• ReconfigurationPending: partitie wordt momenteel opnieuw geconfigureerd.
• InvalidForStatelessServices: er is een poging gedaan om de belasting van een primaire replica te wijzigen voor een partitie die tot een stateless service.
• ReplicaDoesNotExist: secundaire replica of exemplaar bestaat niet op een opgegeven knooppunt.
• InvalidOperation: dit kan in twee gevallen gebeuren: het bijwerken van de belasting voor een partitie die bij de systeemtoepassing hoort of het bijwerken van voorspelde belasting is niet ingeschakeld.

Als sommige van deze fouten worden geretourneerd, kunt u de invoer voor een specifieke partitie bijwerken en de update opnieuw proberen.

Code:

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

In dit voorbeeld voert u een update uit van de laatst gerapporteerde belasting voor een partitie 53df3d7f-5471-403b-b736-bde6ad584f42. De primaire replicabelasting voor een metrische waarde CustomMetricName0 wordt bijgewerkt met waarde 100. Tegelijkertijd wordt de belasting voor dezelfde metrische waarde voor een specifieke secundaire replica op het knooppunt NodeName0 bijgewerkt met waarde 200.

De metrische configuratie van een service bijwerken

De lijst met metrische gegevens die aan de service zijn gekoppeld en de eigenschappen van deze metrische gegevens kunnen dynamisch worden bijgewerkt terwijl de service live is. Dit maakt experimenteren en flexibiliteit mogelijk. Enkele voorbeelden van wanneer dit handig is:

• uitschakelen van een metrische gegevens met een foutenrapport voor een bepaalde service
• het gewicht van metrische gegevens opnieuw configureren op basis van het gewenste gedrag
• het inschakelen van een nieuwe metrische gegevens pas nadat de code al is geïmplementeerd en gevalideerd via andere mechanismen
• de standaardbelasting voor een service wijzigen op basis van waargenomen gedrag en verbruik

De belangrijkste API's voor het wijzigen van de configuratie van metrische gegevens FabricClient.ServiceManagementClient.UpdateServiceAsync zijn in C# en Update-ServiceFabricService in PowerShell. Alle informatie die u met deze API's opgeeft, vervangt onmiddellijk de bestaande metrische gegevens voor de service.

Standaardbelastingswaarden en rapporten voor dynamische belasting combineren

Standaardbelasting en dynamische belastingen kunnen worden gebruikt voor dezelfde service. Wanneer een service gebruikmaakt van zowel standaardbelastingsrapporten als rapporten voor dynamische belasting, wordt de standaardbelasting als schatting gebruikt totdat dynamische rapporten worden weergegeven. De standaardbelasting is goed omdat het de Cluster Resource Manager iets biedt om mee te werken. Met de standaardbelasting kunnen Cluster Resource Manager serviceobjecten op een goede locatie plaatsen wanneer ze worden gemaakt. Als er geen standaardbelastingsinformatie wordt opgegeven, is de plaatsing van services in een willekeurige volgorde. Wanneer er later belastingsrapporten binnenkomen, is de eerste willekeurige plaatsing vaak verkeerd en Cluster Resource Manager moeten services worden verplaatst.

Laten we ons vorige voorbeeld nemen en zien wat er gebeurt wanneer we een aantal aangepaste metrische gegevens en dynamische belastingsrapportage toevoegen. In dit voorbeeld gebruiken we 'MemoryInMb' als voorbeeld van metrische gegevens.

Laten we ervan uit gaan dat we in eerste instantie de stateful service met de volgende opdracht:

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

Ter herinnering: deze syntaxis is ('MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad').

Laten we eens kijken hoe een mogelijke clusterindeling eruit kan zien:

Enkele dingen die het vermelden waard zijn:

• Secundaire replica's binnen een partitie kunnen elk hun eigen belasting hebben
• Over het algemeen zien de metrische gegevens er evenwichtig uit. Voor Geheugen is de verhouding tussen de maximale en minimale belasting 1,75 (het knooppunt met de meeste belasting is N3, de minste is N2 en 28/16 = 1,75).

Er zijn nog enkele dingen die we nog moeten uitleggen:

• Wat heeft bepaald of een verhouding van 1,75 redelijk was of niet? Hoe weet Cluster Resource Manager of dat goed genoeg is of dat er meer werk moet worden gedaan?
• Wanneer vindt de taakverdeling uit?
• Wat betekent het dat het geheugen gewogen 'Hoog' is?

Metrische gewichten

Het bijhouden van dezelfde metrische gegevens voor verschillende services is belangrijk. Met deze globale weergave kan de Cluster Resource Manager verbruik in het cluster bijhouden, het verbruik over knooppunten in balans brengen en ervoor zorgen dat knooppunten de capaciteit niet over hebben. Services kunnen echter verschillende weergaven hebben met het belang van dezelfde metrische waarde. Bovendien bestaan er in een cluster met veel metrische gegevens en veel services mogelijk geen perfect uitgebalanceerde oplossingen voor alle metrische gegevens. Hoe moet de Cluster Resource Manager omgaan met deze situaties?

Met metrische gewichten kan de Cluster Resource Manager bepalen hoe het cluster in balans moet worden brengen wanneer er geen perfect antwoord is. Met metrische gewichten kunnen de Cluster Resource Manager services op een andere manier in balans brengen. Metrische gegevens kunnen vier verschillende gewichtsniveaus hebben: Nul, Laag, Gemiddeld en Hoog. Een metrische gegevens met een gewicht van Nul dragen niets bij bij het overwegen of dingen wel of niet evenwichtig zijn. De belasting draagt echter nog steeds bij aan capaciteitsbeheer. Metrische gegevens met het gewicht Nul zijn nog steeds nuttig en worden vaak gebruikt als onderdeel van servicegedrag en prestatiebewaking. Dit artikel bevat meer informatie over het gebruik van metrische gegevens voor het bewaken en diagnostics van uw services.

De werkelijke impact van verschillende metrische gewichten in het cluster is dat de Cluster Resource Manager verschillende oplossingen genereert. Metrische gewichten geven aan Cluster Resource Manager dat bepaalde metrische gegevens belangrijker zijn dan andere. Wanneer er geen perfecte oplossing is, kan de Cluster Resource Manager de voorkeur geven aan oplossingen die de gewogen metrische gegevens beter in balans brengen. Als een service denkt dat een bepaalde metrische gegevens niet belangrijk zijn, is het gebruik van die metrische gegevens mogelijk niet in balans. Hierdoor kan een andere service een gelijkmatige verdeling krijgen van bepaalde metrische gegevens die belangrijk zijn voor de service.

Laten we eens kijken naar een voorbeeld van een aantal belastingsrapporten en hoe verschillende metrische gewichten tot verschillende toewijzingen in het cluster leiden. In dit voorbeeld zien we dat het schakelen tussen het relatieve gewicht van de metrische gegevens ervoor zorgt dat Cluster Resource Manager verschillende services kunt maken.

In dit voorbeeld zijn er vier verschillende services, die allemaal verschillende waarden rapporteren voor twee verschillende metrische gegevens: MetricA en MetricB. In één geval definiëren alle services MetricA het belangrijkste (Gewicht = Hoog) en MetricB als niet-belangrijk (Gewicht = Laag). Als gevolg hiervan zien we dat de Cluster Resource Manager services plaatst, zodat MetricA beter in balans is dan MetricB. 'Beter gebalanceerd' betekent dat MetricA een lagere standaarddeviatie heeft dan MetricB. In het tweede geval draaien we het metrische gewicht om. Als gevolg hiervan wisselt de Cluster Resource Manager services A en B om een toewijzing te krijgen waarbij MetricB beter in balans is dan MetricA.

Globale metrische gewichten

Stel dat ServiceA MetricA definieert als gewicht Hoog en ServiceB stelt het gewicht voor MetricA in op Laag of Nul. Wat is het werkelijke gewicht dat uiteindelijk wordt gebruikt?

Er zijn meerdere gewichten die worden bij te houden voor elke metriek. Het eerste gewicht is het gewicht dat is gedefinieerd voor de metrische gegevens wanneer de service wordt gemaakt. Het andere gewicht is een globaal gewicht, dat automatisch wordt berekend. De Cluster Resource Manager gebruikt beide gewichten bij het scoren van oplossingen. Rekening houden met beide gewichten is belangrijk. Hierdoor kan Cluster Resource Manager service op basis van zijn eigen prioriteiten in balans brengen en ervoor zorgen dat het cluster als geheel correct wordt toegewezen.

Wat zou er gebeuren als het Cluster Resource Manager niet belangrijk was voor zowel het globale als het lokale saldo? Het is eenvoudig om oplossingen te bouwen die globaal evenwichtig zijn, maar die leiden tot een slechte resource balance voor afzonderlijke services. In het volgende voorbeeld kijken we naar een service die is geconfigureerd met alleen de standaard metrische gegevens en zien we wat er gebeurt wanneer alleen een globaal saldo wordt overwogen:

In het bovenste voorbeeld, alleen gebaseerd op globaal saldo, is het cluster als geheel inderdaad evenwichtig. Alle knooppunten hebben hetzelfde aantal primaries en hetzelfde totale aantal replica's. Als u echter naar de werkelijke impact van deze toewijzing kijkt, is deze niet zo goed: het verlies van een knooppunt is onevenredig van invloed op een bepaalde werkbelasting, omdat alle voorvallen hierdoor worden overgeslagen. Als het eerste knooppunt bijvoorbeeld uitvalt, gaan de drie voor de drie verschillende partities van de Circle-service allemaal verloren. Omgekeerd verliezen de services Driehoek en Zeshoek hun partities een replica. Dit veroorzaakt geen onderbreking, anders dan dat u de downreplica moet herstellen.

In het onderste voorbeeld heeft Cluster Resource Manager replica's gedistribueerd op basis van zowel het globale saldo als het per service-saldo. Bij het berekenen van de score van de oplossing geeft deze het grootste deel van het gewicht aan de globale oplossing en een (configureerbaar) deel aan afzonderlijke services. Het globale saldo voor een metrische waarde wordt berekend op basis van het gemiddelde van het metrische gewicht van elke service. Elke service is evenwichtig volgens de eigen gedefinieerde metrische gewichten. Dit zorgt ervoor dat de services binnen zichzelf in balans zijn op basis van hun eigen behoeften. Als hetzelfde eerste knooppunt uitvalt, wordt de fout daarom verdeeld over alle partities van alle services. De impact op elk is hetzelfde.

Volgende stappen

• Meer informatie over het configureren van services vindt u in Services configureren(service-fabric-cluster-resource-manager-configure-services.md)
• Het definiëren van metrische defragmentatiegegevens is één manier om de belasting van knooppunten te consolideren in plaats van deze uit te spreiden. Raadpleeg dit artikel voor meer informatie over het configureren van defragmentatie
• Raadpleeg het artikel over taakverdeling voor meer informatie over Cluster Resource Manager hoe de taakverdeling in het cluster wordt uitgevoerd
• Begin bij het begin en krijg een inleiding tot de Service Fabric Cluster Resource Manager
• Verplaatsingskosten zijn een van de manier om aan de Cluster Resource Manager dat bepaalde services duurder zijn te verplaatsen dan andere. Raadpleeg dit artikel voor meer informatie over verplaatsingskosten