Integrace Správce prostředků clusteru se správou clusteru Service Fabric

Článek
06/01/2023

Resource Manager clusteru Service Fabric nenásadí upgrady v Service Fabric, ale je to potřeba. První způsob, jak Resource Manager clusteru pomáhá se správou, je sledování požadovaného stavu clusteru a služeb uvnitř clusteru. Cluster Resource Manager odesílá sestavy stavu, když cluster nemůže umístit do požadované konfigurace. Pokud je například nedostatečná kapacita, Resource Manager clusteru odešle upozornění stavu a chyby, které udávají problém. Další část integrace se zabývá fungováním upgradů. Cluster Resource Manager během upgradů mírně mění své chování.

Integrace stavu

Cluster Resource Manager neustále sleduje pravidla, která jste definovali pro umístění služeb. Sleduje také zbývající kapacitu pro každou metriku na uzlech a v clusteru a v clusteru jako celku. Pokud nemůže splňovat tato pravidla nebo pokud není dostatečná kapacita, vygenerují se upozornění stavu a chyby. Pokud je například uzel nad kapacitou a Resource Manager clusteru se pokusí situaci vyřešit přesunem služeb. Pokud se mu nedaří situaci opravit, vygeneruje upozornění na stav, který uzel překročil kapacitu a pro které metriky.

Dalším příkladem upozornění na stav Resource Manager je porušení omezení umístění. Pokud jste například definovali omezení umístění (například “NodeColor == Blue”) a Resource Manager zjistí porušení tohoto omezení, vygeneruje upozornění na stav. To platí pro vlastní omezení a výchozí omezení (jako jsou omezení domény selhání a domény upgradu).

Tady je příklad jedné takové zprávy o stavu. V tomto případě je sestava stavu určená pro jeden z oddílů systémové služby. Zpráva o stavu znamená, že repliky tohoto oddílu jsou dočasně zabalené do příliš malého počtu upgradovaných domén.

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

Tato zpráva o stavu nám říká toto:

Všechny samotné repliky jsou v pořádku: Každá z nich má AggregatedHealthState : Ok
Aktuálně dochází k porušení distribučního omezení upgradovat doménu. To znamená, že konkrétní upgradovací doména má z tohoto oddílu více replik, než by měla.
Který uzel obsahuje repliku způsobující narušení. V tomto případě je to uzel s názvem Node.8.
Jestli právě probíhá upgrade tohoto oddílu (Aktuální upgrade – false)
Zásady distribuce pro tuto službu: "Zásady distribuce – balení". To se řídí RequireDomainDistributionzásadami umístění. Zabalení znamená, že v tomto případě nebyla vyžadována distribuce domény, takže víme, že pro tuto službu nebyly zadány zásady umístění.
Když se sestava stala - 10. 8. 2015 19:13:02

Podobné informace pohání upozorňování. Upozornění můžete použít v produkčním prostředí, abyste věděli, že se něco nepovedlo. Upozorňování se také používá ke zjištění a zastavení chybných upgradů. V tomto případě bychom chtěli zjistit, proč Resource Manager musel zabalit repliky do domény upgradu. Obvykle je balení přechodné, například proto, že uzly v ostatních doménách upgradu byly mimo provoz.

Řekněme, že Resource Manager clusteru se pokouší umístit některé služby, ale neexistují žádná řešení, která by fungovala. Pokud není možné služby umístit, je to obvykle z jednoho z následujících důvodů:

Některé přechodné podmínky znemožňovaly správné umístění této instance služby nebo repliky.
Požadavky na umístění služby jsou neuspokojitelné.

V těchto případech vám zprávy o stavu z clusteru Resource Manager pomůžou určit, proč se služba nedá umístit. Tento proces nazýváme posloupnost odstranění omezení. Během ní systém provede nakonfigurovaná omezení, která službu ovlivňují, a zaznamená, co eliminují. Když se služby nedají umístit, můžete tak zjistit, které uzly byly eliminovány a proč.

Typy omezení

Pojďme si promluvit o jednotlivých omezeních v těchto sestavách stavu. Pokud repliky nejde umístit, zobrazí se zprávy o stavu související s těmito omezeními.

ReplicaExclusionStatic a ReplicaExclusionDynamic: Tato omezení označují, že řešení bylo odmítnuto, protože dva objekty služby ze stejného oddílu by musely být umístěny na stejném uzlu. To není povolené, protože selhání tohoto uzlu by nadměrně ovlivnilo tento oddíl. ReplicaExclusionStatic a ReplicaExclusionDynamic jsou téměř stejné pravidlo a na rozdílech ve skutečnosti nezáleží. Pokud vidíte posloupnost odstranění omezení obsahující omezení ReplicaExclusionStatic nebo ReplicaExclusionDynamic, cluster Resource Manager si myslí, že není dostatek uzlů. To vyžaduje, aby zbývající řešení používala tato neplatná umístění, která jsou zakázána. Ostatní omezení v sekvenci nám obvykle řeknou, proč jsou uzly eliminovány.
PlacementConstraint: Pokud se zobrazí tato zpráva, znamená to, že jsme některé uzly vyloučili, protože neodpovídaly omezením služby pro umístění. V rámci této zprávy vysledujeme aktuálně nakonfigurovaná omezení umístění. To je normální, pokud máte definované omezení umístění. Pokud však omezení umístění nesprávně způsobuje odstranění příliš velkého počtu uzlů, je to, jak byste si všimli.
NodeCapacity: Toto omezení znamená, že Resource Manager clusteru nemohla umístit repliky na uvedené uzly, protože by se tím překročila kapacita.
Spřažení: Toto omezení označuje, že jsme nemohli umístit repliku na ovlivněné uzly, protože by to způsobilo porušení omezení spřažení. Další informace o spřažení najdete v tomto článku.
FaultDomain a UpgradeDomain: Toto omezení eliminuje uzly, pokud by umístění repliky na uvedené uzly způsobilo balení v konkrétní chybě nebo upgradované doméně. Několik příkladů, které toto omezení popisují, je uvedeno v tématu věnovaném omezením domény selhání a upgradu a výsledném chování.
PreferredLocation: Toto omezení by se obvykle nemělo zobrazovat odebrání uzlů z řešení, protože se ve výchozím nastavení spouští jako optimalizace. Během upgradů existuje také omezení upřednostňovaného umístění. Během upgradu se používá k přesunu služeb zpět tam, kde byly v době zahájení upgradu.

Uzly pro vytváření seznamu bloků

Další zprávou o stavu, kterou cluster Resource Manager hlásí, je, když jsou uzly na seznamu blokovaných uzlů. Seznam blokovaných bloků si můžete představit jako dočasné omezení, které se pro vás automaticky použije. Uzly se získají na seznam blokovaných uzlů, když při spouštění instancí tohoto typu služby dochází k opakovaným selháním. Uzly jsou na seznamu blokovaných pro jednotlivé typy služeb. Uzel může být v seznamu blokovaných pro jeden typ služby, ale ne pro jiný.

Během vývoje se často objeví seznam blokovaných bloků: Některá chyba způsobí chybové ukončení hostitele služby při spuštění, Service Fabric se několikrát pokusí vytvořit hostitele služby a k selhání stále dochází. Po několika pokusech se uzel dostane na seznam blokovaných a Resource Manager clusteru se pokusí vytvořit službu jinde. Pokud se toto selhání opakuje na více uzlech, je možné, že se všechny platné uzly v clusteru zablokují. Seznam bloků může také odebrat tolik uzlů, že není možné službu úspěšně spustit, aby se splnilo požadované škálování. Obvykle se zobrazí další chyby nebo upozornění z Resource Manager clusteru, která značí, že je služba pod požadovaným počtem replik nebo instancí, a také zprávy o stavu, které indikují, o jaké selhání se jedná, což vede k zařazení na seznam blokovaných.

Přidání na seznam blokovaných není trvalou podmínkou. Po několika minutách se uzel odebere ze seznamu blokovaných a Service Fabric může služby na daném uzlu znovu aktivovat. Pokud služby nadále selhávají, uzel se pro daný typ služby znovu zablokuje.

Priority omezení

Upozornění

Změna priorit omezení se nedoporučuje a může mít významný nepříznivý dopad na cluster. Níže uvedené informace slouží k referenčním informacím o prioritách výchozích omezení a jejich chování.

Se všemi těmito omezeními si možná myslíte: "Hej, myslím, že omezení domény selhání jsou nejdůležitější věcí v mém systému. Abychom zajistili, že není porušeno omezení domény selhání, jsem ochoten porušit další omezení."

Omezení je možné nakonfigurovat s různými úrovněmi priority. Jsou to:

"tvrdý" (0)
"měkké" (1)
"optimalizace" (2)
"off" (-1).

Většina omezení je ve výchozím nastavení nakonfigurovaná jako pevná.

Změna priority omezení je neobvyklá. V některých případech bylo potřeba změnit priority omezení, obvykle kvůli řešení nějaké jiné chyby nebo chování, které mělo vliv na prostředí. Obecně platí, že flexibilita infrastruktury priority omezení funguje velmi dobře, ale není často potřeba. Ve většině případů je všechno podle svých výchozích priorit.

Úrovně priority neznamená, že bude dané omezení porušeno ani že bude vždy splněno. Priority omezení definují pořadí, ve kterém se omezení vynucují. Priority definují kompromisy, pokud není možné splnit všechna omezení. Obvykle lze všechna omezení splnit, pokud se v prostředí neděje něco jiného. Mezi příklady scénářů, které povedou k porušení omezení, patří konfliktní omezení nebo velký počet souběžných selhání.

V pokročilých situacích můžete změnit priority omezení. Řekněme například, že jste chtěli zajistit, aby se v případě potřeby vždy porušovalo spřažení, aby se vyřešily problémy s kapacitou uzlu. Abyste toho dosáhli, můžete nastavit prioritu omezení spřažení na "měkké" (1) a ponechat omezení kapacity nastavené na "pevné" (0).

Výchozí hodnoty priority pro různá omezení se zadají v následující konfiguraci:

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>

Prostřednictvím ClusterConfig.json pro samostatná nasazení nebo Template.json pro clustery hostované v Azure:

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

Omezení domény selhání a domény upgradu

Cluster Resource Manager chce zajistit, aby se služby rozprostřely mezi domény selhání a upgrady. Modeluje to jako omezení uvnitř modulu clusteru Resource Manager. Další informace o tom, jak se používají a jaké jsou jejich konkrétní chování, najdete v článku o konfiguraci clusteru.

Clusterová Resource Manager možná bude muset zabalit několik replik do upgradované domény, aby se mohla vypořádat s upgrady, selháními nebo jinými porušeními omezení. K zabalení do domén selhání nebo upgradu obvykle dochází pouze v případě, že v systému dochází k několika selháním nebo jiným změnám, které brání správnému umístění. Pokud chcete balení zabránit i v těchto situacích, můžete využít RequireDomainDistributionzásady umístění. Upozorňujeme, že to může mít vliv na dostupnost a spolehlivost služby jako vedlejší účinek, proto to pečlivě zvažte.

Pokud je prostředí správně nakonfigurované, jsou všechna omezení plně respektována, a to i během upgradů. Klíčové je, že Resource Manager clusteru si hlídá vaše omezení. Když zjistí porušení zásad, okamžitě ho nahlásí a pokusí se problém opravit.

Omezení upřednostňovaného umístění

Omezení PreferredLocation se mírně liší, protože má dvě různá použití. Jedním z použití tohoto omezení je během upgradů aplikací. Cluster Resource Manager toto omezení během upgradů automaticky spravuje. Používá se k zajištění toho, aby se po dokončení upgradu repliky vrátily do svých počátečních umístění. Druhé použití omezení PreferredLocation je pro PreferredPrimaryDomain zásady umístění. Obě tyto možnosti jsou optimalizace, a proto je omezení PreferredLocation ve výchozím nastavení jediným omezením nastaveným na "Optimalizace".

Upgrady

Cluster Resource Manager také pomáhá při upgradech aplikací a clusterů, během kterých má dvě úlohy:

zajistit, aby nedošlo k ohrožení pravidel clusteru
zkuste, aby upgrade proběhl hladce

Vynucování pravidel

Hlavní věc, o které je potřeba vědět, je, že pravidla – striktní omezení, jako jsou omezení umístění a kapacity – se během upgradů stále vynucují. Omezení umístění zajistí, aby se vaše úlohy spouštěly jenom tam, kde mají povolené, a to i během upgradů. Pokud jsou služby vysoce omezené, upgrady můžou trvat déle. Když je služba nebo její uzel z provozu kvůli aktualizaci, může existovat jen málo možností, kam může jít.

Inteligentní nahrazení

Po spuštění upgradu pořídí Resource Manager snímek aktuálního uspořádání clusteru. Po dokončení každé domény upgradu se pokusí vrátit služby, které byly v této upgradační doméně, do původního uspořádání. Během upgradu tak existují maximálně dva přechody pro službu. Existuje jeden přesun z ovlivněného uzlu a jeden přesun zpět. Vrácení clusteru nebo služby do stavu před upgradem také zajistí, že upgrade nebude mít vliv na rozložení clusteru.

Snížená četnost změn dat

Během upgradů Resource Manager clusteru také vypne vyrovnávání. Zabránění vyrovnávání zabraňuje zbytečným reakcím na samotný upgrade, jako je přesun služeb do uzlů, které byly pro upgrade vyprázdněny. Pokud se jedná o upgrade clusteru, pak se během upgradu nevyrovná celý cluster. Kontroly omezení zůstanou aktivní, zakáže se pouze pohyb na základě proaktivního vyrovnávání metrik.

Kapacita ve vyrovnávací paměti a upgrade

Obecně platí, že chcete, aby se upgrade dokončil i v případě, že je cluster omezený nebo téměř plný. Správa kapacity clusteru je během upgradů ještě důležitější než obvykle. V závislosti na počtu upgradovaných domén se při přechodu na cluster musí migrovat 5 až 20 procent kapacity. Ta práce musí někam jít. Tady je užitečný pojem vyrovnávacích kapacit . Za běžného provozu se respektuje kapacita vyrovnávací paměti. Cluster Resource Manager může během upgradů v případě potřeby zaplnit uzly až do své celkové kapacity (spotřebovávají vyrovnávací paměť).

Další kroky

Začněte od začátku a získejte úvod ke clusteru Service Fabric Resource Manager

Sdílet prostřednictvím