Clusterresource manager-integratie met Service Fabric-clusterbeheer

De Service Fabric-clusterbronbeheer zorgt niet voor upgrades in Service Fabric, maar is wel betrokken. De eerste manier waarop Cluster Resource Manager helpt bij het beheer, is door de gewenste status van het cluster en de services erin bij te houden. Cluster Resource Manager verzendt statusrapporten wanneer het cluster niet in de gewenste configuratie kan worden geplaatst. Als er bijvoorbeeld onvoldoende capaciteit is, verzendt de Cluster Resource Manager waarschuwingen en foutmeldingen die het probleem aangeven. Een ander onderdeel van integratie moet te maken hebben met de werking van upgrades. Het gedrag van Cluster Resource Manager wordt enigszins gewijzigd tijdens upgrades.

Gezondheidsintegratie

Cluster Resource Manager houdt voortdurend de regels bij die u hebt gedefinieerd voor het plaatsen van uw services. Ook wordt de resterende capaciteit voor elke metriek op de knooppunten en in het cluster als geheel bijgehouden. Als aan deze regels niet kan worden voldaan of als er onvoldoende capaciteit is, worden gezondheidswaarschuwingen en fouten uitgezonden. Als een knooppunt bijvoorbeeld de capaciteit heeft overschreden en de Cluster Resource Manager probeert de situatie op te lossen door services te verplaatsen. Als de situatie niet kan worden gecorrigeerd, wordt er een statuswaarschuwing verzonden die aangeeft welk knooppunt de capaciteit heeft overschreden en voor welke metrische gegevens.

Een ander voorbeeld van de gezondheidswaarschuwingen van Resource Manager is schendingen van plaatsingsbeperkingen. Als u bijvoorbeeld een plaatsingsbeperking (zoals “NodeColor == Blue”) hebt gedefinieerd en Resource Manager een schending van die beperking detecteert, wordt er een statuswaarschuwing verzonden. Dit geldt voor aangepaste beperkingen en de standaardbeperkingen (zoals het foutdomein en upgradedomeinbeperkingen).

Hier volgt een voorbeeld van een dergelijk statusrapport. In dit geval is het statusrapport voor een van de partities van de systeemservice. Het statusbericht geeft aan dat de replica's van die partitie tijdelijk zijn verpakt in te weinig upgradedomeinen.

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

Hier is wat deze gezondheidsboodschap ons vertelt:

  1. Alle replica's zijn gezond: elk heeft AggregatedHealthState : Ok
  2. De beperking upgradedomeindistributie wordt momenteel geschonden. Dit betekent dat een bepaald upgradedomein meer replica's van deze partitie heeft dan het zou moeten.
  3. Welk knooppunt de replica bevat die de schending veroorzaakt. In dit geval is het het knooppunt met de naam Node.8
  4. Of er momenteel een upgrade plaatsvindt voor deze partitie ('Momenteel upgraden -- false')
  5. Het distributiebeleid voor deze service: 'Distributiebeleid -- Verpakking'. Dit wordt bepaald door het RequireDomainDistributionplaatsingsbeleid. Verpakken geeft aan dat in dit geval DomainDistribution niet vereist is, waaruit blijkt dat het plaatsingsbeleid voor deze dienst niet is opgegeven.
  6. Toen het rapport plaatsvond - 10-10-2015 17:13:02

Dit soort informatie zorgt voor waarschuwingen. U kunt waarschuwingen in productie gebruiken om u te laten weten dat er iets mis is gegaan. Waarschuwingen worden ook gebruikt om slechte upgrades te detecteren en te stoppen. In dit geval willen we zien of we kunnen achterhalen waarom resourcebeheer de replica's in het upgradedomein moet inpakken. Meestal is het verpakken tijdelijk omdat de knooppunten in de andere upgradedomeinen bijvoorbeeld niet beschikbaar waren.

Stel dat Cluster Resource Manager bepaalde services probeert te plaatsen, maar er zijn geen oplossingen die werken. Wanneer services niet kunnen worden geplaatst, is dit meestal een van de volgende redenen:

  1. Een tijdelijke voorwaarde heeft het onmogelijk gemaakt om dit service-exemplaar of de replica correct te plaatsen
  2. De plaatsingsvereisten van de service zijn onvervulbaar.

In deze gevallen helpen statusrapporten van Cluster Resource Manager u te bepalen waarom de service niet kan worden geplaatst. We noemen dit proces de sequentie voor het elimineren van beperkingen. Tijdens deze procedure doorloopt het systeem de geconfigureerde beperkingen die van invloed zijn op de service en registreert wat ze elimineren. Op deze manier kunt u zien welke knooppunten zijn verwijderd en waarom services niet kunnen worden geplaatst.

Typen beperkingen

Laten we het hebben over elk van de verschillende beperkingen in deze statusrapporten. U ziet gezondheidsberichten met betrekking tot deze beperkingen wanneer replica's niet kunnen worden geplaatst.

  • ReplicaExclusionStatic en ReplicaExclusionDynamic: deze beperkingen geven aan dat een oplossing is geweigerd omdat twee serviceobjecten van dezelfde partitie op hetzelfde knooppunt moeten worden geplaatst. Dit is niet toegestaan omdat de uitval van dat knooppunt een overmatige impact zou hebben op die partitie. ReplicaExclusionStatic en ReplicaExclusionDynamic zijn bijna dezelfde regel en de verschillen maken niet echt uit. Als u een beperkingsverwijderingsreeks ziet die de replicaExclusionStatic- of ReplicaExclusionDynamic-beperking bevat, denkt clusterbronbeheer dat er onvoldoende knooppunten zijn. Dit vereist dat resterende oplossingen gebruikmaken van deze ongeldige plaatsingen, die niet zijn toegestaan. De andere beperkingen in de reeks geven meestal aan waarom knooppunten in de eerste plaats worden geëlimineerd.
  • PlacementConstraint: Als u dit bericht ziet, betekent dit dat we een aantal knooppunten hebben verwijderd omdat ze niet overeenkomen met de plaatsingsbeperkingen van de service. We brengen de momenteel geconfigureerde plaatsingsbeperkingen in kaart als onderdeel van dit bericht. Dit is normaal als u een plaatsingsbeperking hebt gedefinieerd. Als de plaatsingsbeperking echter onjuist is en te veel knooppunten worden geëlimineerd, zou u dit opmerken op de volgende manier.
  • NodeCapacity: Deze beperking betekent dat de Cluster Resource Manager de replica's niet op de aangegeven knooppunten kon plaatsen, omdat dat ze over de capaciteit zou brengen.
  • Affiniteit: Deze beperking geeft aan dat we de replica niet op de betrokken knooppunten konden plaatsen, omdat deze een schending van de affiniteitsbeperking zou veroorzaken. Meer informatie over affiniteit vindt u in dit artikel
  • FaultDomain en UpgradeDomain: Deze beperking elimineert knooppunten als het plaatsen van de replica op de aangegeven knooppunten zou leiden tot clustering in een bepaald fout- of upgradedomein. Verschillende voorbeelden die deze beperking bespreken, worden weergegeven in het onderwerp over fout- en upgradedomeinbeperkingen en resulterend gedrag
  • PreferredLocation: normaal gesproken wordt deze beperking niet weergegeven om knooppunten uit de oplossing te verwijderen, omdat deze standaard wordt uitgevoerd als optimalisatie. De voorkeurslocatiebeperking is ook aanwezig tijdens upgrades. Tijdens de upgrade wordt het gebruikt om services terug te verplaatsen naar waar ze waren toen de upgrade werd gestart.

Knooppunten blokkeren

Een ander gezondheidsbericht dat de Cluster Resource Manager rapporteert, is wanneer knooppunten op de zwarte lijst worden geplaatst. U kunt blokkeren beschouwen als een tijdelijke beperking die automatisch voor u wordt toegepast. Knooppunten worden geblokkeerd wanneer er herhaalde fouten optreden bij het starten van die service. Knooppunten worden per service op de blokkeringslijst weergegeven. Een knooppunt kan worden geblokkeerd voor het ene servicetype, maar niet voor een ander servicetype.

Tijdens de ontwikkeling ziet u dat de blokkeringslijst vaak wordt geactiveerd: een fout veroorzaakt dat uw servicehost vastloopt bij het opstarten, Service Fabric probeert de servicehost een paar keer te maken en de fout blijft optreden. Na enkele pogingen wordt het knooppunt geblokkeerd en probeert Cluster Resource Manager de service ergens anders te maken. Als deze fout zich blijft voordoen op meerdere knooppunten, is het mogelijk dat alle geldige knooppunten in het cluster zijn geblokkeerd. Het op de zwarte lijst zetten kan ook zoveel knooppunten verwijderen dat er niet genoeg overblijven om de service te lanceren en aan de gewenste schaal te voldoen. Meestal ziet u aanvullende fouten of waarschuwingen van Cluster Resource Manager die aangeeft dat de service onder het gewenste aantal replica's of exemplaren ligt, evenals statusberichten die aangeven wat de fout is die leidt tot de blokkeringslijst.

Blokkeren is geen permanente voorwaarde. Na enkele minuten wordt het knooppunt verwijderd uit de bloklijst en kan Service Fabric de services op dat knooppunt opnieuw activeren. Als services blijven mislukken, wordt het knooppunt opnieuw geblokkeerd voor dat servicetype.

Beperkingsprioriteiten

Waarschuwing

Het wijzigen van beperkingsprioriteiten wordt niet aanbevolen en kan aanzienlijke nadelige gevolgen hebben voor uw cluster. De onderstaande informatie wordt verstrekt ter referentie van de standaardprioriteiten voor beperkingen en hun gedrag.

Met al deze beperkingen heb je misschien gedacht: "Hey, ik denk dat beperkingen van foutdomeinen het allerbelangrijkste zijn in mijn systeem." Om ervoor te zorgen dat de beperking van het foutdomein niet wordt geschonden, ben ik bereid om andere beperkingen te schenden."

Beperkingen kunnen worden geconfigureerd met verschillende prioriteitsniveaus. Dit zijn:

  • moeilijk
  • zacht
  • "optimalisatie" (2)
  • "uit" (-1).

De meeste beperkingen worden standaard geconfigureerd als harde beperkingen.

Het wijzigen van de prioriteit van beperkingen is ongebruikelijk. Er zijn situaties waarin beperkingsprioriteiten moesten worden gewijzigd, meestal om een andere fout of gedrag te omzeilen die van invloed waren op de omgeving. Over het algemeen heeft de flexibiliteit van de prioriteiteninfrastructuur voor beperkingen goed gewerkt, maar er is vaak niet veel vraag naar. Meestal blijft alles bij hun standaardprioriteiten.

De prioriteitsniveaus betekenen niet dat een bepaalde beperking wordt geschonden en dat er altijd aan wordt voldaan. Prioriteiten voor beperkingen definiëren een volgorde waarin beperkingen worden afgedwongen. Prioriteiten definiëren de compromissen wanneer het onmogelijk is om aan alle beperkingen te voldoen. Meestal kunnen alle beperkingen worden voldaan, tenzij er iets anders gebeurt in de omgeving. Enkele voorbeelden van scenario's die leiden tot schendingen van beperkingen zijn conflicterende beperkingen of grote aantallen gelijktijdige fouten.

In geavanceerde situaties kunt u de prioriteiten voor beperkingen wijzigen. Stel dat u ervoor wilt zorgen dat affiniteit altijd wordt geschonden wanneer dat nodig is om knooppuntcapaciteitsproblemen op te lossen. Hiervoor kunt u de prioriteit van de affiniteitsbeperking instellen op 'zacht' (1) en de capaciteitsbeperking ingesteld laten op 'hard' (0).

De standaardprioriteitswaarden voor de verschillende beperkingen worden opgegeven in de volgende configuratie:

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 voor zelfstandige implementaties of Template.json voor gehoste Azure-clusters:

"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"
      }
    ]
  }
]

Foutdomein- en upgrade-domeinbeperkingen

Cluster Resource Manager wil services verspreid houden over fout- en upgradedomeinen. Deze wordt als een beperking in de engine van Cluster Resource Manager gemodelled. Raadpleeg het artikel over clusterconfiguratie voor meer informatie over hoe ze worden gebruikt en hun specifieke gedrag.

De Cluster Resource Manager moet mogelijk een aantal replica's inpakken in een upgradedomein om te kunnen omgaan met upgrades, fouten of andere schendingen van beperkingen. Inpakken in fout- of upgradedomeinen gebeurt normaal gesproken alleen wanneer er verschillende fouten of ander verloop in het systeem zijn waardoor de juiste plaatsing wordt voorkomen. Als u wilt voorkomen dat er zelfs in zulke situaties wordt ingepakt, kunt u het RequireDomainDistributionplaatsingsbeleid gebruiken. Houd er rekening mee dat dit van invloed kan zijn op de beschikbaarheid en betrouwbaarheid van de service als neveneffect, dus overweeg het zorgvuldig.

Als de omgeving correct is geconfigureerd, worden alle beperkingen volledig gerespecteerd, zelfs tijdens upgrades. Het belangrijkste is dat Cluster Resource Manager op uw beperkingen let. Wanneer er een schending wordt gedetecteerd, wordt deze onmiddellijk gerapporteerd en wordt geprobeerd het probleem op te lossen.

De voorkeurslocatiebeperking

De preferredLocation-beperking is iets anders, omdat deze twee verschillende toepassingen heeft. Eén gebruik van deze beperking is tijdens het upgraden van toepassingen. Deze beperking wordt automatisch beheerd door Cluster Resource Manager tijdens upgrades. Het wordt gebruikt om ervoor te zorgen dat wanneer upgrades zijn voltooid, replica's terugkeren naar hun oorspronkelijke locaties. Het andere gebruik van de PreferredLocation-beperking is voor het PreferredPrimaryDomain plaatsingsbeleid. Beide zijn optimalisaties en daarom is de PreferredLocation-beperking de enige beperking die standaard is ingesteld op Optimalisatie.

Verbeteringen

Cluster Resource Manager helpt ook tijdens het upgraden van toepassingen en clusters, waarbij het twee taken heeft:

  • ervoor zorgen dat de regels van het cluster niet zijn aangetast
  • proberen om de upgrade soepel te laten verlopen

Blijf de regels handhaven

Het belangrijkste waar u rekening mee moet houden, is dat de regels, de strikte beperkingen, zoals plaatsingsbeperkingen en capaciteiten, nog steeds worden afgedwongen tijdens upgrades. Plaatsingsbeperkingen zorgen ervoor dat uw workloads alleen worden uitgevoerd waar ze zijn toegestaan, zelfs tijdens upgrades. Wanneer services zeer beperkt zijn, kunnen upgrades langer duren. Wanneer de service of het knooppunt ervan tijdelijk stilgelegd wordt voor een update, zijn er mogelijk weinig opties voor waar deze kan worden verplaatst.

Slimme vervangingen

Wanneer een upgrade wordt gestart, maakt Resource Manager een momentopname van de huidige rangschikking van het cluster. Wanneer elk upgradedomein is voltooid, wordt geprobeerd de services te retourneren die zich in dat upgradedomein bevonden naar de oorspronkelijke rangschikking. Op deze manier zijn er maximaal twee overgangen voor een service tijdens de upgrade. Er is één verplaatsing uit het betreffende knooppunt en één verplaatsing weer terug erin. Als u het cluster of de service retourneert naar hoe het vóór de upgrade was, zorgt u er ook voor dat de upgrade niet van invloed is op de indeling van het cluster.

Verminderd klantverloop

Tijdens upgrades schakelt Cluster Resource Manager ook de taakverdeling uit. Het voorkomen van evenwicht voorkomt onnodige reacties op de upgrade zelf, zoals het verplaatsen van services naar knooppunten die zijn geleegd voor de upgrade. Als de betreffende upgrade een clusterupgrade is, wordt het hele cluster niet gebalanceerd gedurende de upgrade. Beperkingscontroles blijven actief, alleen beweging op basis van de proactieve balancering van metrics wordt uitgeschakeld.

Gebufferde capaciteit en upgrade

Over het algemeen wilt u dat de upgrade wordt voltooid, zelfs als het cluster beperkt is of bijna vol is. Het beheren van de capaciteit van het cluster is nog belangrijker tijdens upgrades dan normaal. Afhankelijk van het aantal upgradedomeinen moet tussen 5 en 20 procent van de capaciteit worden gemigreerd wanneer de upgrade via het cluster wordt uitgevoerd. Dat werk moet ergens heen. Dit is waar het begrip buffercapaciteit nuttig is. De buffercapaciteit wordt tijdens de normale werking gerespecteerd. De Cluster Resource Manager kan knooppunten vullen tot hun totale capaciteit (waarbij de buffer wordt gebruikt) tijdens upgrades, indien nodig.

Volgende stappen

  • Last updated on