Dela via

Klusterresurshanterarens integrering med Service Fabric-klusterhantering

  • Artikel

Resource Manager för Service Fabric-kluster driver inte uppgraderingar i Service Fabric, men det är inblandat. Det första sättet som Klusterresurshanteraren hjälper till med hanteringen är genom att spåra det önskade tillståndet för klustret och tjänsterna i det. Klusterresurshanteraren skickar ut hälsorapporter när det inte kan placera klustret i önskad konfiguration. Om det till exempel inte finns tillräckligt med kapacitet skickar Klusterresurshanteraren ut hälsovarningar och fel som anger problemet. En annan del av integreringen har att göra med hur uppgraderingar fungerar. Klusterresurshanteraren ändrar sitt beteende något under uppgraderingarna.

Hälsointegrering

Klusterresurshanteraren spårar ständigt de regler som du har definierat för att placera dina tjänster. Den spårar också den återstående kapaciteten för varje mått på noderna och i klustret och i klustret som helhet. Om det inte kan uppfylla dessa regler eller om det inte finns tillräckligt med kapacitet genereras hälsovarningar och fel. Om en nod till exempel är över kapaciteten och Klusterresurshanteraren försöker åtgärda situationen genom att flytta tjänster. Om den inte kan korrigera situationen genererar den en hälsovarning som anger vilken nod som överskrider kapaciteten och för vilka mått.

Ett annat exempel på Resource Manager-hälsovarningar är överträdelser av placeringsbegränsningar. Om du till exempel har definierat en placeringsbegränsning (till exempel “NodeColor == Blue”) och Resource Manager upptäcker en överträdelse av den begränsningen genererar den en hälsovarning. Detta gäller för anpassade begränsningar och standardbegränsningar (till exempel begränsningarna feldomän och uppgraderingsdomän).

Här är ett exempel på en sådan hälsorapport. I det här fallet gäller hälsorapporten för en av systemtjänstens partitioner. Hälsomeddelandet anger att replikerna av partitionen tillfälligt är packade i för få uppgraderingsdomäner.

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

Här är vad det här hälsomeddelandet säger oss är:

  1. Alla repliker i sig är felfria: Var och en har AggregatedHealthState : Ok
  2. Distributionsbegränsningen för uppgraderingsdomänen överträds för närvarande. Det innebär att en viss uppgraderingsdomän har fler repliker från den här partitionen än den borde.
  3. Vilken nod innehåller repliken som orsakar överträdelsen. I det här fallet är det noden med namnet Node.8
  4. Om en uppgradering pågår för den här partitionen ("Uppgraderar för närvarande – falskt")
  5. Distributionsprincipen för den här tjänsten: "Distributionsprincip – Packning". Detta styrs av RequireDomainDistribution placeringsprincipen. Packning anger att domaindistribution i det här fallet inte krävdes, så vi vet att placeringsprincipen inte har angetts för den här tjänsten.
  6. När rapporten inträffade – 2015-08-10 19:13:02

Information som den här aktiverar aviseringar. Du kan använda aviseringar i produktion för att informera dig om att något har gått fel. Aviseringar används också för att identifiera och stoppa felaktiga uppgraderingar. I det här fallet vill vi se om vi kan ta reda på varför Resource Manager var tvungen att packa replikerna i uppgraderingsdomänen. Vanligtvis är paketeringen tillfällig eftersom noderna i de andra uppgraderingsdomänerna till exempel var nere.

Anta att Klusterresurshanteraren försöker placera vissa tjänster, men det finns inga lösningar som fungerar. När tjänster inte kan placeras är det vanligtvis av någon av följande orsaker:

  1. Ett tillfälligt villkor har gjort det omöjligt att placera den här tjänstinstansen eller repliken korrekt
  2. Tjänstens placeringskrav är inte tillfredsställande.

I dessa fall hjälper hälsorapporter från Cluster Resource Manager dig att avgöra varför tjänsten inte kan placeras. Vi kallar den här processen för begränsningselimineringssekvensen. Under den går systemet igenom de konfigurerade begränsningar som påverkar tjänsten och registrerar vad de eliminerar. På så sätt kan du se vilka noder som har eliminerats och varför när tjänster inte kan placeras.

Villkorstyper

Nu ska vi prata om var och en av de olika begränsningarna i dessa hälsorapporter. Hälsomeddelanden som är relaterade till dessa begränsningar visas när repliker inte kan placeras.

  • ReplicaExclusionStatic och ReplicaExclusionDynamic: Dessa begränsningar anger att en lösning avvisades eftersom två tjänstobjekt från samma partition måste placeras på samma nod. Detta är inte tillåtet eftersom ett fel på noden skulle påverka partitionen alltför mycket. ReplicaExclusionStatic och ReplicaExclusionDynamic är nästan samma regel och skillnaderna spelar ingen roll. Om du ser en begränsningselimineringssekvens som innehåller begränsningen ReplicaExclusionStatic eller ReplicaExclusionDynamic, anser Klusterresurshanteraren att det inte finns tillräckligt med noder. Detta kräver återstående lösningar för att använda dessa ogiltiga placeringar, som inte tillåts. De andra begränsningarna i sekvensen talar vanligtvis om för oss varför noder elimineras i första hand.
  • PlacementConstraint: Om du ser det här meddelandet innebär det att vi har eliminerat vissa noder eftersom de inte matchade tjänstens placeringsbegränsningar. Vi spårar de för närvarande konfigurerade placeringsbegränsningarna som en del av det här meddelandet. Detta är normalt om du har definierat en placeringsbegränsning. Men om placeringsbegränsningen felaktigt orsakar att för många noder elimineras är det så här du skulle märka det.
  • NodeCapacity: Den här begränsningen innebär att Klusterresurshanteraren inte kunde placera replikerna på de angivna noderna eftersom det skulle placera dem över kapaciteten.
  • Tillhörighet: Den här begränsningen anger att vi inte kunde placera repliken på de berörda noderna eftersom det skulle orsaka en överträdelse av tillhörighetsbegränsningen. Mer information om tillhörighet finns i den här artikeln
  • FaultDomain och UpgradeDomain: Den här begränsningen eliminerar noder om en placering av repliken på de angivna noderna skulle orsaka packning i en viss fel- eller uppgraderingsdomän. Flera exempel som beskriver den här begränsningen visas i avsnittet om begränsningar för fel- och uppgraderingsdomäner och resulterande beteende
  • PreferredLocation: Du bör normalt inte se den här begränsningen ta bort noder från lösningen eftersom den körs som optimering som standard. Den önskade platsbegränsningen finns också under uppgraderingar. Under uppgraderingen används den för att flytta tillbaka tjänster till platsen där de var när uppgraderingen startade.

Blockera noder

Ett annat hälsomeddelande som Klusterresurshanteraren rapporterar är när noder blockeras. Du kan se blocklistning som en tillfällig begränsning som tillämpas automatiskt för dig. Noder blockeras när de får upprepade fel när instanser av den tjänsttypen startas. Noder blockeras per tjänsttyp. En nod kan blockeras för en tjänsttyp men inte en annan.

Blocklistning startar ofta under utveckling: En del buggar gör att tjänstvärden kraschar vid start, Service Fabric försöker skapa tjänstvärden några gånger och felet fortsätter att inträffa. Efter några försök blockeras noden och Klusterresurshanteraren försöker skapa tjänsten någon annanstans. Om felet fortsätter att inträffa på flera noder är det möjligt att alla giltiga noder i klustret blockeras. Blocklistning kan också ta bort så många noder att inte tillräckligt många kan starta tjänsten för att uppfylla den önskade skalan. Du ser vanligtvis ytterligare fel eller varningar från Klusterresurshanteraren som anger att tjänsten ligger under det önskade antalet repliker eller instanser, samt hälsomeddelanden som anger vad felet är som leder till blocklistningen i första hand.

Blocklistning är inte ett permanent villkor. Efter några minuter tas noden bort från blocklistan och Service Fabric kan aktivera tjänsterna på noden igen. Om tjänsterna fortsätter att misslyckas blockeras noden för den tjänsttypen igen.

Begränsningsprioriteringar

Varning

Ändring av begränsningsprioriteringar rekommenderas inte och kan ha betydande negativa effekter på klustret. Informationen nedan tillhandahålls som referens för standardvillkorsprioriteringar och deras beteende.

Med alla dessa begränsningar kan du ha tänkt "Hej - jag tror att begränsningar för feldomänen är det viktigaste i mitt system. För att säkerställa att begränsningen för feldomänen inte överträds är jag villig att bryta mot andra begränsningar."

Begränsningar kan konfigureras med olika prioritetsnivåer. Dessa är:

  • "hard" (0)
  • "mjuk" (1)
  • "optimering" (2)
  • "off" (-1).

De flesta av begränsningarna konfigureras som hårda begränsningar som standard.

Det är ovanligt att ändra prioriteten för begränsningar. Det har funnits tillfällen då begränsningsprioriteringar behövde ändras, vanligtvis för att kringgå andra buggar eller beteenden som påverkade miljön. Generellt sett har flexibiliteten i infrastrukturen för begränsningsprioritet fungerat mycket bra, men den behövs inte ofta. För det mesta ligger allt på deras standardprioriteringar.

Prioritetsnivåerna innebär inte att en viss begränsning överträds eller att den alltid uppfylls. Villkorsprioriteringar definierar en ordning i vilken begränsningar tillämpas. Prioriteringar definierar kompromisserna när det är omöjligt att uppfylla alla begränsningar. Vanligtvis kan alla begränsningar uppfyllas om det inte är något annat som händer i miljön. Några exempel på scenarier som leder till begränsningsöverträdelser är motstridiga begränsningar eller ett stort antal samtidiga fel.

I avancerade situationer kan du ändra begränsningsprioriteterna. Anta till exempel att du vill se till att tillhörigheten alltid överträds när det behövs för att lösa problem med nodkapaciteten. För att uppnå detta kan du ange prioriteten för tillhörighetsbegränsningen till "mjuk" (1) och lämna kapacitetsbegränsningen inställd på "hård" (0).

Standardprioritetsvärdena för de olika begränsningarna anges i följande konfiguration:

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

via ClusterConfig.json för fristående distributioner eller Template.json för Azure-värdbaserade kluster:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

Begränsningar för feldomäner och uppgraderingsdomäner

Klusterresurshanteraren vill hålla tjänsterna utspridda bland fel- och uppgraderingsdomäner. Den modellerar detta som en begränsning i Klusterresurshanterarens motor. Mer information om hur de används och deras specifika beteende finns i artikeln om klusterkonfiguration.

Klusterresurshanteraren kan behöva packa ett par repliker i en uppgraderingsdomän för att hantera uppgraderingar, fel eller andra begränsningar. Paketering i fel- eller uppgraderingsdomäner sker normalt bara när det finns flera fel eller annan omsättning i systemet som förhindrar korrekt placering. Om du vill förhindra förpackning även under dessa situationer kan du använda RequireDomainDistribution placeringsprincipen. Observera att detta kan påverka tjänstens tillgänglighet och tillförlitlighet som en bieffekt, så tänk noga på det.

Om miljön är korrekt konfigurerad respekteras alla begränsningar fullt ut, även under uppgraderingar. Det viktigaste är att Klusterresurshanteraren håller utkik efter dina begränsningar. När den upptäcker en överträdelse rapporterar den omedelbart den och försöker åtgärda problemet.

Den önskade platsbegränsningen

Begränsningen PreferredLocation är lite annorlunda eftersom den har två olika användningsområden. En användning av den här begränsningen är under programuppgraderingar. Klusterresurshanteraren hanterar automatiskt den här begränsningen under uppgraderingar. Den används för att säkerställa att replikerna återgår till sina ursprungliga platser när uppgraderingarna är slutförda. Den andra användningen av begränsningen PreferredLocation är för PreferredPrimaryDomain placeringsprincipen. Båda dessa är optimeringar, och därför är preferredLocation-begränsningen den enda begränsningen inställd på "Optimering" som standard.

Uppgraderingar

Klusterresurshanteraren hjälper även under program- och klusteruppgraderingar, under vilka den har två jobb:

  • se till att reglerna i klustret inte komprometteras
  • försök att hjälpa uppgraderingen att gå smidigt

Fortsätt att framtvinga reglerna

Det viktigaste att vara medveten om är att reglerna – de strikta begränsningarna som placeringsbegränsningar och kapaciteter – fortfarande tillämpas under uppgraderingarna. Placeringsbegränsningar säkerställer att dina arbetsbelastningar bara körs där de tillåts, även under uppgraderingar. När tjänsterna är mycket begränsade kan uppgraderingar ta längre tid. När tjänsten eller dess nod tas bort för en uppdatering kan det finnas få alternativ för vart den kan gå.

Smarta ersättningar

När en uppgradering startar tar Resource Manager en ögonblicksbild av klustrets aktuella ordning. När varje uppgraderingsdomän slutförs försöker den returnera de tjänster som fanns i uppgraderingsdomänen till deras ursprungliga arrangemang. På så sätt finns det högst två övergångar för en tjänst under uppgraderingen. Det finns en flytt från den berörda noden och en går tillbaka in. Om du returnerar klustret eller tjänsten till hur det var före uppgraderingen ser du också till att uppgraderingen inte påverkar klustrets layout.

Minskad omsättning

Under uppgraderingar inaktiverar Klusterresurshanteraren även utjämningen. Att förhindra balansering förhindrar onödiga reaktioner på själva uppgraderingen, till exempel att flytta tjänster till noder som tömdes för uppgraderingen. Om uppgraderingen i fråga är en klusteruppgradering balanseras inte hela klustret under uppgraderingen. Begränsningskontroller förblir aktiva, endast förflyttning baserat på proaktiv balansering av mått inaktiveras.

Buffrad kapacitet och uppgradering

Vanligtvis vill du att uppgraderingen ska slutföras även om klustret är begränsat eller nästan fullt. Det är ännu viktigare att hantera klustrets kapacitet under uppgraderingar än vanligt. Beroende på antalet uppgraderingsdomäner måste mellan 5 och 20 procent av kapaciteten migreras när uppgraderingen rullar genom klustret. Det arbetet måste gå någonstans. Det är här begreppet buffrade kapaciteter är användbart. Buffrad kapacitet respekteras under normal drift. Klusterresurshanteraren kan fylla noder upp till sin totala kapacitet (förbruka bufferten) under uppgraderingar om det behövs.

Nästa steg