Share via

Resourceverbruik en -belasting in Service Fabric beheren met metrische gegevens

  • Artikel

Metrische gegevens zijn de resources die belangrijk zijn voor uw services en die worden geleverd door de knooppunten in het cluster. Een metrische waarde 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 of uw service overbelast is. Een ander gebruik is om erachter te komen of de service naar een andere locatie kan worden verplaatst waar het geheugen minder beperkt is om betere prestaties te krijgen.

Zaken als 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 (en meestal) logische metrische gegevens zijn. Logische metrische gegevens zijn zaken als 'MyWorkQueueDepth' of 'MessagesToProcess' of 'TotalRecords'. Logische metrische gegevens zijn door de toepassing gedefinieerd en komen indirect overeen met een bepaald verbruik van fysieke resources. Logische metrische gegevens zijn gebruikelijk omdat het moeilijk 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 waarom Service Fabric enkele 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 worden gebruikt. Dat is prima. Het Service Fabric-cluster Resource Manager gebruikt een aantal standaard metrische gegevens wanneer er geen andere metrische gegevens zijn opgegeven. Dit zijn:

  • PrimaryCount - aantal primaire replica's op het knooppunt
  • ReplicaCount : het aantal stateful replica's op het knooppunt
  • Count: het aantal serviceobjecten (stateless en stateful) op het knooppunt
Metrisch Stateless exemplaar laden Stateful secundaire belasting Stateful primaire belasting Gewicht
PrimaryCount 0 0 1 Hoog
ReplicaCount 0 1 1 Normaal
Count 1 1 1 Beperkt

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

Dit is het resultaat:

Clusterindeling met standaard metrische gegevens

Let op het volgende:

  • Primaire replica's voor de stateful service worden verdeeld over verschillende knooppunten
  • Replica's voor dezelfde partitie bevinden zich op verschillende knooppunten
  • Het totale aantal primaries en secundaire databases wordt verdeeld in het cluster
  • Het totale aantal serviceobjecten wordt gelijkmatig toegewezen op elk knooppunt

Goede!

De standaard metrische gegevens werken prima als begin. De standaard metrische gegevens dragen u echter alleen tot nu toe mee. Bijvoorbeeld: Wat is de kans dat het partitieschema dat u hebt gekozen, resulteert in een perfect gelijkmatig gebruik door alle partities? Hoe groot is de kans dat de belasting voor een bepaalde service in de loop van de tijd constant is, of zelfs op dit moment hetzelfde is voor meerdere partities?

U kunt uitvoeren met alleen de standaard metrische gegevens. Dit betekent echter meestal dat het clustergebruik lager en ongelijk is dan u zou willen. Dit komt doordat de standaard metrische gegevens niet adaptief zijn en ervan uitgaan dat alles gelijkwaardig is. Bijvoorbeeld: een Primary die bezet is en een die niet beide '1' is, draagt bij aan de metrische waarde PrimaryCount. In het ergste geval kan het gebruik van alleen de standaard metrische gegevens ook leiden tot te veel geplande knooppunten, wat resulteert in prestatieproblemen. Als u uw cluster optimaal wilt benutten en prestatieproblemen wilt voorkomen, moet u aangepaste metrische gegevens en dynamische belastingrapportage gebruiken.

Aangepaste metrische gegevens

Metrische gegevens worden geconfigureerd per benoemd-service-exemplaar wanneer u de service maakt.

Een metrische waarde heeft een aantal eigenschappen die het beschrijven: een naam, een gewicht en een standaardbelasting.

  • Naam van metrische waarde: de naam van de metrische waarde. De metrische naam is een unieke id voor de metrische waarde binnen het cluster vanuit het perspectief van de Resource Manager.

Notitie

Naam van aangepaste metrische gegevens mag geen van de metrische namen van het systeem zijn, zoals servicefabric:/_CpuCores of servicefabric:/_MemoryInMB omdat dit kan leiden tot niet-gedefinieerd gedrag. Vanaf Service Fabric versie 9.1 wordt voor bestaande services met deze aangepaste metrische namen een statuswaarschuwing uitgegeven om aan te geven dat de metrische naam onjuist is.

  • Gewicht: metrische waarde bepaalt hoe belangrijk deze metrische gegevens zijn 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 elk metrische gegeven één eigenschap met de naam DefaultLoad
    • Voor stateful services die u definieert:
      • PrimaryDefaultLoad: de standaardhoeveelheid van deze metrische waarde die deze service verbruikt wanneer het een primaire waarde is
      • SecondaryDefaultLoad: de standaardhoeveelheid van deze metrische waarde die deze service verbruikt wanneer het een secundaire waarde is

Notitie

Als u aangepaste metrische gegevens definieert en u ook de standaard metrische gegevens wilt gebruiken, moet u de standaard metrische gegevens expliciet toevoegen en hiervoor gewichten en waarden definiëren. Dit komt omdat u de relatie tussen de standaard metrische gegevens en uw aangepaste metrische gegevens moet definiëren. Misschien geeft u bijvoorbeeld meer om ConnectionCount of WorkQueueDepth dan primaire distributie. Het gewicht van de metrische waarde PrimaryCount is standaard Hoog, dus u wilt deze verlagen naar Gemiddeld wanneer u uw andere metrische gegevens toevoegt om ervoor te zorgen dat deze prioriteit hebben.

Metrische gegevens definiëren voor uw service - een voorbeeld

Stel dat u de volgende configuratie wilt:

  • Uw service rapporteert een metrische waarde met de naam 'ConnectionCount'
  • U wilt ook de standaard metrische gegevens gebruiken
  • U hebt enkele metingen uitgevoerd en weet dat normaal gesproken een primaire replica van die service 20 eenheden van 'ConnectionCount' in beslag neemt
  • Secundaire instanties gebruiken 5 eenheden van 'ConnectionCount'
  • U weet dat 'ConnectionCount' de belangrijkste metrische waarde is voor het beheren van de prestaties van deze specifieke service
  • U wilt nog steeds dat primaire replica's in balans zijn. Het in balans brengen van primaire replica's is over het algemeen een goed idee, ongeacht wat. Dit helpt voorkomen dat het verlies van een knooppunt of foutdomein een meerderheid van de primaire replica's beïnvloedt.
  • 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”)

Notitie

In de bovenstaande voorbeelden en de rest van dit document wordt het beheren van metrische gegevens per benoemde service beschreven. Het is ook mogelijk om metrische gegevens voor uw services te definiëren op het niveau van het servicetype . Dit wordt bereikt door ze op te geven in uw servicemanifesten. Het definiëren van metrische gegevens op typeniveau wordt om verschillende redenen niet aanbevolen. De eerste reden is dat metrische namen vaak omgevingsspecifiek zijn. Tenzij er een vast contract is, kunt u er niet zeker van zijn dat de metrische waarde 'Kernen' in de ene omgeving niet 'MiliCores' of 'CoReS' is in andere omgevingen. Als uw metrische gegevens zijn gedefinieerd in uw manifest, moet u nieuwe manifesten per omgeving maken. Dit leidt meestal tot een verspreiding van verschillende manifesten met slechts kleine verschillen, wat kan leiden tot beheerproblemen.

Belasting van metrische gegevens wordt doorgaans toegewezen per benoemde service-instantie. Stel dat u één exemplaar van de service maakt voor CustomerA die van plan is deze slechts licht te gebruiken. Stel ook dat u een andere maakt voor CustomerB die een grotere workload heeft. In dit geval wilt u waarschijnlijk de standaardbelastingen voor deze services aanpassen. Als u metrische gegevens en belastingen hebt gedefinieerd via manifesten en u dit scenario wilt ondersteunen, zijn voor elke klant verschillende toepassings- en servicetypen vereist. De waarden die zijn gedefinieerd tijdens het maken van de service, overschrijven de waarden die zijn gedefinieerd in het manifest, zodat u die kunt gebruiken om de specifieke standaardwaarden in te stellen. Dit zorgt er echter voor dat de waarden die in de manifesten zijn gedeclareerd, niet overeenkomen met de waarden waarmee de service daadwerkelijk wordt uitgevoerd. Dit kan tot verwarring leiden.

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 worden gedefinieerd.

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

Laden

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

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

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

Standaard laden

Standaardbelasting is hoeveel van de metrische gegevens elk serviceobject (staatloos exemplaar 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 rapport over dynamische belasting. Voor eenvoudigere services is de standaardbelasting een statische definitie. De standaardbelasting wordt nooit bijgewerkt en wordt gebruikt voor de levensduur van de service. Standaardbelastingen werken uitstekend voor eenvoudige scenario's voor capaciteitsplanning waarbij bepaalde hoeveelheden resources zijn toegewezen aan verschillende workloads en niet veranderen.

Notitie

Raadpleeg dit artikel voor meer informatie over capaciteitsbeheer en het definiëren van capaciteiten voor de knooppunten in uw cluster.

Met de Cluster-Resource Manager kunnen stateful services een andere standaardbelasting opgeven voor hun primaire en secundaire taken. 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 anders omdat replica's verschillende soorten werk doen in elke rol. Primaries dienen bijvoorbeeld meestal zowel lees- als schrijfbewerkingen en verwerken het grootste deel van de rekenkundige belasting, terwijl secundaire bestanden dat niet doen. Meestal is de standaardbelasting voor een primaire replica hoger dan de standaardbelasting voor secundaire replica's. De reële getallen moeten afhankelijk zijn van uw eigen metingen.

Dynamische belasting

Stel dat u uw service al een tijdje uitvoert. Bij enige controle 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 loop van de tijd varieert.

Er zijn veel dingen die dit soort belastingsschommelingen kunnen veroorzaken. Er zijn bijvoorbeeld verschillende services of partities gekoppeld aan verschillende klanten met verschillende vereisten. De belasting kan ook veranderen omdat de hoeveelheid werk die de service doet, gedurende de dag varieert. Ongeacht de reden is er meestal geen enkel getal dat u als standaardwaarde kunt gebruiken. Dit geldt met name als u het meeste gebruik van het cluster wilt halen. Elke waarde die u kiest voor standaardbelasting, is soms onjuist. Onjuiste standaardbelastingen resulteren in het Resource Manager cluster over of onder toewijzing van resources. Als gevolg hiervan hebt u knooppunten die te veel of te weinig worden gebruikt, hoewel de cluster-Resource Manager denkt dat het cluster evenwichtig is. Standaardbelastingen zijn nog steeds goed omdat ze informatie bieden voor de eerste plaatsing, maar ze zijn geen volledig verhaal voor echte workloads. Om veranderende resourcevereisten nauwkeurig vast te leggen, staat de cluster-Resource Manager toe dat elk serviceobject zijn eigen belasting bijwerkt tijdens runtime. Dit wordt dynamische belastingrapportage 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 koud was en geen werk deed, rapporteert meestal dat er lage hoeveelheden van een bepaalde metrische waarde worden gebruikt. Een bezet replica of exemplaar meldt dat ze meer gebruiken.

Met rapportagebelasting per replica of exemplaar kan de cluster-Resource Manager de afzonderlijke serviceobjecten in het cluster opnieuw organiseren. Als u de services opnieuw indeelt, zorgt u ervoor dat ze de resources krijgen die ze nodig hebben. Drukke services krijgen effectief toegang tot het vrijmaken van resources van andere replica's of exemplaren die momenteel koud zijn of minder werk doen.

Binnen Reliable Services ziet de code voor het dynamisch laden van rapporten er als volgt uit:

Code:

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

Een service kan rapporteren over elk van de metrische gegevens die tijdens het maken ervan zijn gedefinieerd. Als een service belasting rapporteert voor een metrische waarde die niet is geconfigureerd voor gebruik, negeert Service Fabric dat rapport. 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 dat ze de servicecode hoeven te wijzigen.

Rapportagebelasting voor een partitie

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

Deze rapporten worden op precies 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, hetzij door de replica of instantie, hetzij 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 servicepartitie kan de primaire replicabelasting bijwerken.
  • Zowel stateless als stateful services kunnen de belasting van alle secundaire replica's of exemplaren bijwerken.
  • Zowel stateless als 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 tegelijkertijd te combineren. De combinatie van laadupdates voor een bepaalde partitie moet worden opgegeven via het object PartitionMetricLoadDescription, dat de bijbehorende lijst met updates voor laden 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.

Notitie

Voorspelde belastingswaarden voor metrische gegevens is momenteel een preview-functie. Hiermee kunnen voorspelde belastingswaarden worden gerapporteerd en gebruikt aan de zijde van Service Fabric, maar die functie is momenteel niet ingeschakeld.

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

  • 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 deel uitmaakt van een staatloze service.
  • ReplicaDoesNotExist - Secundaire replica of instantie bestaat niet op een opgegeven knooppunt.
  • InvalidOperation: kan in twee gevallen optreden: het bijwerken van de belasting voor een partitie die deel uitmaakt van de systeemtoepassing of het bijwerken van de voorspelde belasting is niet ingeschakeld.

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

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. Primaire replicabelasting voor een metrische waarde CustomMetricName0 wordt bijgewerkt met de waarde 100. Tegelijkertijd wordt de belasting voor dezelfde metrische waarde voor een specifieke secundaire replica op het knooppunt NodeName0 bijgewerkt met de waarde 200.

De metrische configuratie van een service bijwerken

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

  • een metrische waarde uitschakelen met een buggy-rapport voor een bepaalde service
  • het gewicht van metrische gegevens opnieuw configureren op basis van gewenst gedrag
  • nieuwe metrische gegevens pas inschakelen 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 bevinden zich FabricClient.ServiceManagementClient.UpdateServiceAsync in C# en Update-ServiceFabricService in PowerShell. De gegevens die u bij deze API's opgeeft, vervangen onmiddellijk de bestaande metrische gegevens voor de service.

Standaardlaadwaarden en dynamische belastingsrapporten combineren

Standaardbelasting en dynamische belasting kunnen worden gebruikt voor dezelfde service. Wanneer een service gebruikmaakt van zowel standaardbelastings- als dynamische belastingsrapporten, dient de standaardbelasting als schatting totdat dynamische rapporten worden weergegeven. De standaardbelasting is goed omdat het cluster hierdoor Resource Manager iets biedt om mee te werken. Met de standaardbelasting kan de cluster-Resource Manager de serviceobjecten op goede locaties plaatsen wanneer ze worden gemaakt. Als er geen standaard laadinformatie wordt opgegeven, is de plaatsing van services in feite willekeurig. Wanneer laadrapporten later binnenkomen, is de eerste willekeurige plaatsing vaak onjuist en moet de cluster-Resource Manager services verplaatsen.

Laten we het vorige voorbeeld nemen en kijken wat er gebeurt wanneer we een aantal aangepaste metrische gegevens en dynamische belastingrapportage toevoegen. In dit voorbeeld gebruiken we 'MemoryInMb' als voorbeeldmetriek.

Notitie

Geheugen is een van de metrische gegevens van het systeem die door Service Fabric kunnen worden beheerd en het zelf rapporteren is doorgaans moeilijk. We verwachten niet dat u het geheugenverbruik rapporteert; Geheugen wordt hier gebruikt om meer te weten te komen over de mogelijkheden van de cluster-Resource Manager.

We gaan ervan uit dat we de stateful service in eerste instantie hebben gemaakt 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 één mogelijke clusterindeling eruit zou kunnen zien:

Cluster gebalanceerd met zowel standaard- als aangepaste metrische gegevens

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, het minste is N2 en 28/16 = 1,75).

Er zijn enkele dingen die we nog moeten uitleggen:

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

Metrische gewichten

Het bijhouden van dezelfde metrische gegevens in verschillende services is belangrijk. Dankzij deze globale weergave kan de cluster-Resource Manager het verbruik in het cluster bijhouden, het verbruik over knooppunten verdelen en ervoor zorgen dat knooppunten niet over de capaciteit gaan. Services kunnen echter verschillende weergaven hebben met betrekking tot het belang van dezelfde metrische gegevens. Bovendien bestaat in een cluster met veel metrische gegevens en veel services mogelijk niet voor alle metrische gegevens perfect uitgebalanceerde oplossingen. Hoe moet het cluster Resource Manager omgaan met deze situaties?

Metrische gewichten kunnen de cluster-Resource Manager bepalen hoe het cluster moet worden afgestemd wanneer er geen perfect antwoord is. Metrische gewichten kunnen de cluster-Resource Manager ook specifieke services anders verdelen. Metrische gegevens kunnen vier verschillende gewichtsniveaus hebben: Nul, Laag, Gemiddeld en Hoog. Een metrische waarde met een gewicht van Nul draagt niets bij wanneer wordt overwogen of dingen wel of niet in balans zijn. De belasting draagt echter nog steeds bij aan capaciteitsbeheer. Metrische gegevens met zero weight 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 bewaking en diagnose van uw services.

De werkelijke impact van verschillende metrische gewichten in het cluster is dat het cluster Resource Manager verschillende oplossingen genereert. Metrische gewichten geven aan de cluster-Resource Manager aan dat bepaalde metrische gegevens belangrijker zijn dan andere. Als er geen perfecte oplossing is, kunnen de cluster-Resource Manager de voorkeur geven aan oplossingen die de hogere gewogen metrische gegevens beter in balans houden. Als een service denkt dat een bepaalde metrische waarde onbelangrijk is, kan het gebruik van die metrische gegevens onevenwichtig zijn. Hierdoor kan een andere service een gelijkmatige distributie krijgen van bepaalde metrische gegevens die belangrijk voor de service zijn.

Laten we eens kijken naar een voorbeeld van enkele belastingsrapporten en hoe verschillende metrische gewichten leiden tot verschillende toewijzingen in het cluster. In dit voorbeeld zien we dat het wijzigen van het relatieve gewicht van de metrische gegevens ertoe leidt dat de Cluster-Resource Manager verschillende rangschikkingen van services maakt.

Voorbeeld van metrische gewicht en de impact ervan op balanceringsoplossingen

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 de services zo plaatst dat MetricA beter in balans is dan MetricB. 'Beter gebalanceerd' betekent dat MetricA een lagere standaarddeviatie heeft dan Metrische waardeB. In het tweede geval keren we de metrische gewichten om. Als gevolg hiervan wisselt de Cluster-Resource Manager services A en B om een toewijzing te bedenken waarbij MetricB beter in balans is dan Metrische gegevens.

Notitie

Metrische gewichten bepalen hoe de cluster-Resource Manager moet balanceren, maar niet wanneer het verdelen moet plaatsvinden. Raadpleeg dit artikel voor meer informatie over balanceren

Globale gewichten voor metrische gegevens

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 voor elke metrische waarde worden bijgehouden. Het eerste gewicht is het gewicht dat is gedefinieerd voor de metrische waarde 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. Het is belangrijk om beide gewichten in aanmerking te nemen. Hierdoor kan de cluster-Resource Manager elke service op basis van zijn eigen prioriteiten verdelen en er ook voor zorgen dat het cluster als geheel correct wordt toegewezen.

Wat zou er gebeuren als het cluster Resource Manager niet om zowel de globale als de lokale balans gaf? Het is eenvoudig om oplossingen te bouwen die globaal in balans zijn, maar die resulteren in een slechte resourcebalans voor afzonderlijke services. In het volgende voorbeeld bekijken we een service die is geconfigureerd met alleen de standaard metrische gegevens en kijken wat er gebeurt wanneer alleen rekening wordt gehouden met globaal saldo:

De impact van een wereldwijde oplossing

In het bovenste voorbeeld, alleen op basis van een globaal saldo, is het cluster als geheel inderdaad evenwichtig. Alle knooppunten hebben hetzelfde aantal primaries en hetzelfde aantal totale replica's. Als u echter kijkt naar de werkelijke impact van deze toewijzing, is dit niet zo goed: het verlies van een knooppunt heeft onevenredig veel invloed op een bepaalde workload, omdat alle primaire functies worden verwijderd. Als het eerste knooppunt bijvoorbeeld mislukt, gaan de drie primaries voor de drie verschillende partities van de Circle-service allemaal verloren. Omgekeerd verliezen de services Triangle en Hexagon hun partities een replica. Dit veroorzaakt geen onderbreking, behalve dat de offlinereplica moet worden hersteld.

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

Volgende stappen

  • Meer informatie over services configureren (service-fabric-cluster-resource-manager-configure-services.md) voor meer informatie over het configureren van services
  • Het definiëren van metrische defragmentatiegegevens is een 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 hoe de Cluster-Resource Manager de taak in het cluster beheert en verdeeld
  • Begin bij het begin en krijg een inleiding tot het Service Fabric-cluster Resource Manager
  • Verplaatsingskosten is een manier om het cluster te signaleren Resource Manager dat bepaalde services duurder zijn om te verplaatsen dan andere. Raadpleeg dit artikel voor meer informatie over verplaatsingskosten