Integratie van clusterresourcebeheer met Service Fabric-clusterbeheer

Het Service Fabric-cluster Resource Manager zorgt niet voor upgrades in Service Fabric, maar is wel betrokken. De eerste manier waarop het cluster Resource Manager helpt bij het beheer, is door de gewenste status van het cluster en de services in het cluster bij te houden. De cluster-Resource Manager verzendt statusrapporten wanneer het cluster niet in de gewenste configuratie kan worden geplaatst. Als er bijvoorbeeld onvoldoende capaciteit is, verzendt het cluster Resource Manager statuswaarschuwingen en fouten die het probleem aangeven. Een ander stukje integratie heeft te maken met hoe upgrades werken. De cluster-Resource Manager wijzigt het gedrag enigszins tijdens upgrades.

Statusintegratie

De cluster-Resource Manager houdt voortdurend de regels bij die u hebt gedefinieerd voor het plaatsen van uw services. Ook wordt de resterende capaciteit bijgehouden voor elke metrische waarde op de knooppunten en in het cluster en in het cluster als geheel. Als er niet aan deze regels kan worden voldaan of als er onvoldoende capaciteit is, worden er statuswaarschuwingen en -fouten verzonden. Als een knooppunt bijvoorbeeld over capaciteit beschikt 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 de Resource Manager zijn schendingen van plaatsingsbeperkingen. Als u bijvoorbeeld een plaatsingsbeperking (zoals “NodeColor == Blue”) hebt gedefinieerd en de 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 het upgradedomein).

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 is wat dit statusbericht ons vertelt:

1. Alle replica's zelf zijn in orde: elk heeft AggregatedHealthState : Ok
2. De beperking Voor upgraden van domeindistributie wordt momenteel geschonden. Dit betekent dat een bepaald upgradedomein meer replica's van deze partitie heeft dan het zou moeten.
3. Welk knooppunt bevat de replica die de schending veroorzaakt. In dit geval is het het knooppunt met de naam Node.8
4. Of er momenteel een upgrade wordt uitgevoerd voor deze partitie ('Momenteel upgraden -- onwaar')
5. Het distributiebeleid voor deze service: 'Distributiebeleid -- Verpakking'. Dit wordt bepaald door het RequireDomainDistributionplaatsingsbeleid. Verpakken geeft aan dat in dit geval DomainDistribution niet vereist was, dus we weten dat plaatsingsbeleid niet is opgegeven voor deze service.
6. Wanneer het rapport is gebeurd - 10-8-2015 19:13:02

Informatie zoals deze zorgt voor waarschuwingen. U kunt waarschuwingen in productie gebruiken om u te laten weten dat er iets is misgegaan. Waarschuwingen worden ook gebruikt om slechte upgrades te detecteren en te stoppen. In dit geval willen we zien of we kunnen achterhalen waarom de Resource Manager de replica's moesten inpakken in het upgradedomein. Meestal is het verpakken tijdelijk omdat de knooppunten in de andere upgradedomeinen bijvoorbeeld niet beschikbaar waren.

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

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

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

Beperkingstypen

Laten we het hebben over 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 een storing van dat knooppunt dan te veel invloed heeft op die partitie. ReplicaExclusionStatic en ReplicaExclusionDynamic zijn bijna dezelfde regel en de verschillen zijn niet echt van belang. Als u een beperkingsverwijderingsreeks ziet die de beperking ReplicaExclusionStatic of ReplicaExclusionDynamic bevat, denkt de cluster-Resource Manager dat er onvoldoende knooppunten zijn. Hiervoor moeten de resterende oplossingen deze ongeldige plaatsingen gebruiken, die niet zijn toegestaan. De andere beperkingen in de reeks vertellen ons meestal waarom knooppunten in de eerste plaats worden geëlimineerd.
• PlacementConstraint: als u dit bericht ziet, betekent dit dat sommige knooppunten zijn 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 er echter ten onrechte voor zorgt dat er te veel knooppunten worden geëlimineerd, zou u dit merken.
• NodeCapacity: Deze beperking betekent dat de cluster-Resource Manager de replica's niet op de aangegeven knooppunten kon plaatsen, omdat ze dan over de capaciteit zouden beschikken.
• Affiniteit: deze beperking geeft aan dat we de replica niet op de betrokken knooppunten kunnen plaatsen, omdat dit 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 een bepaalde fout of upgradedomein. In het onderwerp over fout- en upgradedomeinbeperkingen en het resulterende gedrag worden verschillende voorbeelden besproken van deze beperking
• 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 deze gebruikt om services terug te verplaatsen naar waar ze zich bevonden toen de upgrade begon.

Knooppunten in de blokkeringslijst

Een ander statusbericht dat het cluster Resource Manager rapporteert, is wanneer knooppunten op de blokkeringslijst staan. U kunt een blokkeringslijst zien als een tijdelijke beperking die automatisch voor u wordt toegepast. Knooppunten worden geblokkeerd wanneer ze herhaalde fouten ondervinden bij het starten van exemplaren van dat servicetype. Knooppunten worden op de blokkeringslijst per servicetype weergegeven. Een knooppunt kan op de blokkeringslijst staan voor het ene servicetype, maar niet voor een ander.

Tijdens de ontwikkeling wordt de blokkeringslijst vaak geactiveerd: een fout zorgt ervoor dat uw servicehost vastloopt bij het opstarten, Service Fabric probeert de servicehost een paar keer te maken en de fout blijft optreden. Na een paar pogingen wordt het knooppunt op de blokkeringslijst geplaatst en probeert de 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 worden geblokkeerd. Met een blokkeringslijst kunnen ook zoveel knooppunten worden verwijderd dat de service niet voldoende kan worden gestart om aan de gewenste schaal te voldoen. Meestal ziet u aanvullende fouten of waarschuwingen van de cluster-Resource Manager die aangeven dat de service zich onder het gewenste aantal replica's of exemplaren bevindt, evenals statusberichten die aangeven wat de fout is die in de eerste plaats leidt tot de blokkeringslijst.

Blokkering is geen permanente voorwaarde. Na een paar minuten wordt het knooppunt verwijderd uit de blokkeringslijst en kan Service Fabric de services op dat knooppunt opnieuw activeren. Als services blijven mislukken, wordt het knooppunt opnieuw op de blokkeringslijst voor dat servicetype weergegeven.

Beperkingsprioriteiten

Waarschuwing

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

Met al deze beperkingen hebt u misschien gedacht: "Hey - ik denk dat beperkingen van foutdomeinen 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. Deze zijn:

• "hard" (0)
• "zacht" (1)
• "optimalisatie" (2)
• "uit" (-1).

De meeste beperkingen zijn standaard geconfigureerd als harde beperkingen.

Het wijzigen van de prioriteit van beperkingen is ongebruikelijk. Er zijn tijden geweest waarin beperkingsprioriteiten moesten worden gewijzigd, meestal om een andere fout of ander gedrag te omzeilen dat van invloed was op de omgeving. Over het algemeen heeft de flexibiliteit van de infrastructuur met prioriteit voor beperkingen zeer goed gewerkt, maar deze is niet vaak nodig. Meestal staat alles op de standaardprioriteiten.

De prioriteitsniveaus betekenen niet dat een bepaalde beperking wordt geschonden en dat er altijd aan wordt voldaan. Met beperkingsprioriteiten wordt een volgorde gedefinieerd waarin beperkingen worden afgedwongen. Prioriteiten definiëren de compromissen wanneer het onmogelijk is om aan alle beperkingen te voldoen. Normaal gesproken kan aan alle beperkingen worden voldaan, tenzij er iets anders aan de hand is 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 beperkingsprioriteiten wijzigen. Stel dat u ervoor wilt zorgen dat affiniteit altijd wordt geschonden wanneer dat nodig is om problemen met de knooppuntcapaciteit 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 door Azure gehoste 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"
      }
    ]
  }
]

Beperkingen voor domeinfouten en upgraden van domeinen

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

De cluster-Resource Manager moet mogelijk een paar replica's in een upgradedomein verpakken om upgrades, fouten of andere beperkingen te kunnen oplossen. 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 verhinderd. Als u zelfs in dergelijke situaties het verpakken wilt voorkomen, kunt u gebruikmaken van het RequireDomainDistributionplaatsingsbeleid. Houd er rekening mee dat dit als neveneffect van invloed kan zijn op de beschikbaarheid en betrouwbaarheid van de service, dus overweeg dit zorgvuldig.

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

De voorkeurslocatiebeperking

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

Upgrades

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

• zorg ervoor dat de regels van het cluster niet worden aangetast
• proberen de upgrade soepel te laten verlopen

Blijf de regels afdwingen

Het belangrijkste om rekening mee te 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 bijbehorende knooppunt wordt uitgeschakeld voor een update, zijn er mogelijk enkele opties voor waar deze naartoe kan gaan.

Slimme vervangingen

Wanneer een upgrade wordt gestart, maakt de Resource Manager een momentopname van de huidige rangschikking van het cluster. Wanneer elk upgradedomein is voltooid, probeert het de services die zich in dat upgradedomein bevonden, terug te zetten naar hun oorspronkelijke indeling. Op deze manier zijn er maximaal twee overgangen voor een service tijdens de upgrade. Er is één verplaatsing van het betrokken knooppunt en één verplaatsing terug naar binnen. Als u het cluster of de service retourneert naar de status van vóór de upgrade, zorgt u er ook voor dat de upgrade geen invloed heeft op de indeling van het cluster.

Verminderd verloop

Tijdens upgrades schakelt de cluster-Resource Manager ook de balancering uit. Het voorkomen van balancering voorkomt onnodige reacties op de upgrade zelf, zoals het verplaatsen van services naar knooppunten die zijn geleegd voor de upgrade. Als de upgrade in kwestie een clusterupgrade is, wordt het hele cluster niet in balans gebracht 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 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 de 5 en 20 procent van de capaciteit worden gemigreerd wanneer de upgrade door het cluster wordt uitgevoerd. Dat werk moet ergens heen. Hier is het begrip buffercapaciteit nuttig. Buffercapaciteit wordt in acht genomen tijdens normaal gebruik. De cluster-Resource Manager kunnen knooppunten vullen tot hun totale capaciteit (verbruiken van de buffer) tijdens upgrades, indien nodig.

Volgende stappen

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