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. De clusterbronbeheer verzendt statusrapporten wanneer het cluster niet in de gewenste configuratie kan worden geplaatst. Als er bijvoorbeeld onvoldoende capaciteit is, verzendt Cluster Resource Manager statuswaarschuwingen en -fouten 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.

Statusintegratie

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 deze regels niet voldoen of als er onvoldoende capaciteit is, worden statuswaarschuwingen en fouten verzonden. 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 statuswaarschuwingen 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

Dit statusbericht vertelt ons:

1. Alle replica's zelf zijn in orde: 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 RequireDomainDistribution plaatsingsbeleid. Inpakken geeft aan dat in dit geval DomainDistribution niet vereist was, dus we weten dat plaatsingsbeleid niet is opgegeven voor deze service.
6. Toen het rapport plaatsvond - 10-10-2015 17:13:02

Informatie zoals deze 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 niet tevreden.

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 statusberichten 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 fout van dat knooppunt ten onrechte van invloed is 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. Hiervoor zijn resterende oplossingen vereist voor het gebruik 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 traceren de momenteel geconfigureerde plaatsingsbeperkingen als onderdeel van dit bericht. Dit is normaal als u een plaatsingsbeperking hebt gedefinieerd. Als de plaatsingsbeperking echter onjuist is waardoor te veel knooppunten worden geëlimineerd, ziet u dit als u dat zou merken.
• NodeCapacity: Deze beperking betekent dat de clusterresourcebeheer de replica's niet op de aangegeven knooppunten kon plaatsen, omdat deze over capaciteit zouden beschikken.
• 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 een bepaalde fout of upgradedomein veroorzaakt. 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 statusbericht dat de Cluster Resource Manager-rapporten rapporteert, is wanneer knooppunten worden geblokkeerd. 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 exemplaren van dat servicetype. 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 wordt de blokkeringslijst vaak 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. Met blokkeren kunnen ook zoveel knooppunten worden verwijderd die niet voldoende zijn om de service te starten om 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, denk ik dat foutdomeinbeperkingen het belangrijkste 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. De volgende stappen moeten worden uitgevoerd:

• "hard" (0)
• "zacht" (1)
• "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 is de flexibiliteit van de infrastructuur voor beperkingsprioriteit zeer goed gelukt, maar dit is niet vaak nodig. Meestal ligt alles aan 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 upgradedomeinbeperkingen

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 verpakking zelfs in deze situaties, kunt u het RequireDomainDistribution plaatsingsbeleid 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.

Upgrades

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

De regels blijven afdwingen

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 wordt uitgeschakeld voor een update, zijn er mogelijk enkele opties voor waar deze kan worden gebruikt.

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 van het betreffende knooppunt en één verplaatsing terug. 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 verloop

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 verdeeld tijdens de upgrade. Beperkingscontroles blijven actief, alleen beweging op basis van de proactieve verdeling van metrische gegevens wordt uitgeschakeld.

Gebufferde capaciteit en upgrade

Over het algemeen wilt u dat de upgrade wordt voltooid, zelfs als het cluster is beperkt 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

• Begin vanaf het begin en krijg een inleiding tot het Service Fabric-cluster Resource Manager