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

Článek
08/25/2024

Resource Manager clusteru Service Fabric nesvádí upgrady v Service Fabric, ale týká se to. Prvním způsobem, jak Správce prostředků clusteru pomáhá se správou, je sledováním požadovaného stavu clusteru a služeb uvnitř clusteru. Správce prostředků clusteru odesílá zprávy o stavu, když nemůže cluster umístit do požadované konfigurace. Pokud například není dostatečná kapacita, Odešle Resource Manager upozornění na stav a chyby, které značí problém. Další součástí integrace je, jak fungují upgrady. Správce prostředků clusteru mění jeho chování mírně během upgradů.

Integrace stavu

Správce prostředků clusteru neustále sleduje pravidla, která jste definovali pro umístění služeb. Také sleduje zbývající kapacitu pro každou metriku na uzlech a v clusteru a v clusteru jako celek. Pokud tato pravidla nevyhovují nebo pokud není dostatečná kapacita, vygenerují se upozornění na stav a chyby. Pokud je například uzel nad kapacitou a Správce prostředků clusteru se pokusí situaci vyřešit přesunutím služeb. Pokud nemůže opravit situaci, vygeneruje upozornění na stav označující, který uzel je nad kapacitou a pro které metriky.

Dalším příkladem upozornění na stav Resource Manageru 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í (například omezení domény selhání a upgradování domény).

Tady je příklad jedné takové zprávy o stavu. V tomto případě je zpráva o stavu pro jeden z oddílů systémové služby. Zpráva o stavu označuje repliky tohoto oddílu dočasně zabalené do příliš málo 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

Tady je, co nám tato zpráva o stavu říká:

Všechny samotné repliky jsou v pořádku: Každý z nich má AggregatedHealthState : Ok
V současné době dochází k porušení omezení distribuce domény upgradu. To znamená, že konkrétní doména upgradu má z tohoto oddílu více replik, než by měla.
Který uzel obsahuje repliku, která způsobuje narušení. V tomto případě se jedná o uzel s názvem Node.8.
Jestli u tohoto oddílu aktuálně probíhá upgrade (Aktuálně probíhá upgrade – false)
Zásady distribuce pro tuto službu: "Zásady distribuce – Balení". To se řídí RequireDomainDistribution zásadami umístění. Balení indikuje, že v tomto případě Nebyla vyžadována služba DomainDistribution, takže víme, že pro tuto službu nebyla zadána zásada umístění.
Kdy se sestava stala - 10.8.2015 13:13:02

Informace, jako je tato funkce, upozorňují. Pomocí upozornění v produkčním prostředí můžete zjistit, že se něco nepovedlo. K detekci a zastavení chybných upgradů se také používá upozorňování. V tomto případě bychom chtěli zjistit, jestli můžeme zjistit, proč Resource Manager musel zabalit repliky do domény upgradu. Balení je obvykle přechodné, protože uzly v ostatních doménách upgradu byly mimo provoz, například.

Řekněme, že Se Správce prostředků clusteru pokouší umístit některé služby, ale neexistují žádná řešení, která fungují. Pokud se služby nedají umístit, obvykle je to z jednoho z následujících důvodů:

Některá přechodná podmínka znemožnila správně umístit tuto instanci služby nebo repliku.
Požadavky na umístění služby jsou nespokojitelné.

V těchto případech vám sestavy stavu z Resource Manageru clusteru pomůžou určit, proč se služba nedá umístit. Tento proces nazýváme posloupnost odstranění omezení. Během této doby systém provede nakonfigurovaná omezení ovlivňující službu a zaznamenává, co eliminují. Tímto způsobem, když se služby nedají umístit, můžete zjistit, které uzly byly odstraněny a proč.

Typy omezení

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

ReplicaExclusionStatic a ReplicaExclusionDynamic: Tato omezení naznač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í povoleno, protože selhání tohoto uzlu by příliš ovlivnilo tento oddíl. ReplicaExclusionStatic a ReplicaExclusionDynamic jsou téměř stejné pravidlo a rozdíly ve skutečnosti nezáleží. Pokud se zobrazí sekvence odstranění omezení obsahující buď omezení ReplicaExclusionStatic, nebo ReplicaExclusionDynamic, Správce prostředků clusteru si myslí, že neexistuje 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č se uzly na prvním místě eliminují.
PlacementConstraint: Pokud se tato zpráva zobrazí, znamená to, že jsme odstranili některé uzly, protože se neshodovaly s omezeními umístění služby. V rámci této zprávy sledujeme 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 příliš mnoho uzlů, aby bylo vyloučeno, je to způsob, jak byste si všimli.
NodeCapacity: Toto omezení znamená, že Správce prostředků clusteru nemohl umístit repliky na označené uzly, protože by je umístil přes kapacitu.
Spřažení: Toto omezení značí, že repliku se nepodařilo umístit 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í do konkrétní domény selhání nebo upgradu. Několik příkladů popisující toto omezení najdete v tématu týkajícím se omezení domény selhání a upgradu a výsledného chování.
PreferredLocation: Toto omezení byste neměli normálně vidět, protože se uzel odebere z řešení, protože se ve výchozím nastavení spouští jako optimalizace. Během upgradů se také nachází omezení upřednostňovaného umístění. Během upgradu se používá k přesunu služeb zpět do místa, kde byly při spuštění upgradu.

Uzly se seznamem blokovaných uzlů

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

Během vývoje se často spustí blokování: Některá chyba způsobí, že se hostitel služby při spuštění chybově ukončí, Service Fabric se několikrát pokusí vytvořit hostitele služby a stále dochází k selhání. Po několika pokusech se uzel zablokuje a Resource Manager clusteru se pokusí vytvořit službu jinde. Pokud se tato chyba stále opakuje na více uzlech, je možné, že všechny platné uzly v clusteru se zablokují. Zablokování může také odebrat tolik uzlů, které nestačí k úspěšnému spuštění služby, aby splňovalo požadované škálování. Obvykle se zobrazí další chyby nebo upozornění z Resource Manageru clusteru, které indikují, že služba je pod požadovaným počtem replik nebo instancí, a také zprávy o stavu označující selhání, které vede k blokování na prvním místě.

Seznam blokovaných položek není trvalou podmínkou. Po několika minutách se uzel odebere ze seznamu blokovaných položek a Service Fabric může znovu aktivovat služby na daném uzlu. Pokud služby nadále selžou, uzel je znovu pro tento typ služby zablokovaný.

Priority omezení

Upozorňující

Změna priorit omezení se nedoporučuje a může mít významný nepříznivý vliv na váš cluster. Níže uvedené informace jsou uvedeny pro referenci výchozích priorit omezení a jejich chování.

Se všemi těmito omezeními jste možná přemýšleli " Hey – myslím, že omezení domény selhání jsou nejdůležitější věcí v mém systému. Abych se ujistil, že omezení domény selhání není porušeno, jsem ochotný porušit další omezení."

Omezení je možné nakonfigurovat s různými úrovněmi priority. Jedná se o:

"hard" (0)
"soft" (1)
"optimalizace" (2)
"vypnuto" (-1).

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

Změna priority omezení je neobvyklá. V některých případech došlo k tomu, že se priority omezení potřebovaly změnit, obvykle aby se vyřešily některé jiné chyby nebo chování, které ovlivnilo prostředí. Obecně platí, že flexibilita infrastruktury priority omezení fungovala velmi dobře, ale není ji často potřeba. Ve většině případů se všechno nachází ve svých výchozích prioritách.

Úrovně priority neznamená, že dané omezení bude 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í. Všechna omezení můžou být obvykle splněna, pokud v prostředí nedochází k něčemu jinému. Některé příklady scénářů, které vedou k narušení omezení, jsou 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 spřažení vždy porušovalo v případě potřeby k vyřešení problémů s kapacitou uzlů. Abyste toho dosáhli, můžete nastavit prioritu omezení spřažení na "soft" (1) a ponechat omezení kapacity nastavenou na "hard" (0).

Výchozí hodnoty priority pro různá omezení jsou zadány 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"
      }
    ]
  }
]

Doména selhání a omezení domény upgradu

Správce prostředků clusteru chce udržovat služby rozložené mezi domény selhání a upgradu. Modeluje to jako omezení uvnitř modulu Resource Manageru clusteru. Další informace o tom, jak se používají a jejich konkrétní chování, najdete v článku o konfiguraci clusteru.

Správce prostředků clusteru může potřebovat zabalit několik replik do domény upgradu, aby bylo možné řešit upgrady, selhání nebo jiná porušení omezení. Balení do domén selhání nebo upgradu se obvykle děje 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 zabránit balení i v těchto situacích, můžete využít RequireDomainDistribution zásady umístění. Mějte na paměti, že to může mít vliv na dostupnost služeb a spolehlivost jako vedlejší účinek, proto je pečlivě zvažte.

Pokud je prostředí správně nakonfigurované, jsou všechna omezení plně respektována i během upgradů. Klíčovou věcí je, že Správce prostředků clusteru sleduje vaše omezení. Když zjistí porušení, okamžitě ho nahlásí a pokusí se problém opravit.

Upřednostňované omezení umístění

Omezení PreferredLocation se trochu liší, protože má dvě různá použití. Jedním z použití tohoto omezení je během upgradů aplikací. Správce prostředků clusteru toto omezení během upgradů automaticky spravuje. Používá se k zajištění toho, aby se po dokončení upgradů repliky vrátily do jejich počátečních umístění. Druhé použití omezení PreferredLocation je pro zásadu PreferredPrimaryDomainumístění. Obě tyto optimalizace jsou optimalizace, a proto je omezení PreferredLocation jediným omezením nastaveným na "Optimalizace" ve výchozím nastavení.

Upgrady

Správce prostředků clusteru také pomáhá během upgradů aplikací a clusterů, během kterých má dvě úlohy:

zajistěte, aby nedošlo k ohrožení pravidel clusteru.
pokuste se pomoct s upgradem hladce

Vynucování pravidel

Hlavní věcí, o které je potřeba vědět, je, že během upgradů se stále vynucují pravidla – striktní omezení, jako jsou omezení umístění a kapacity. Omezení umístění zajišťují, aby vaše úlohy běžely jenom tam, kde jsou povolené, i během upgradů. Pokud jsou služby vysoce omezené, upgrade může trvat déle. Když je služba nebo její uzel přenesena pro aktualizaci, může existovat několik možností, kde může jít.

Inteligentní nahrazení

Když se spustí upgrade, Resource Manager pořídí 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 doméně upgrade do původního uspořádání. Tímto způsobem se během upgradu pro službu používají maximálně dva přechody. Z ovlivněného uzlu se přesunete a pak se vrátíte zpátky. Vrácení clusteru nebo služby do stavu před upgradem také zajišťuje, že upgrade nemá vliv na rozložení clusteru.

Omezená četnost změn

Během upgradů vypne Správce prostředků clusteru také vyrovnávání. Zabránění vyrovnávání brání zbytečným reakcím na samotný upgrade, jako je přesun služeb do uzlů, které byly pro upgrade vyprázdněny. Pokud je daný upgradem clusteru upgrade, během upgradu se nevyrovná celý cluster. Kontroly omezení zůstávají aktivní, je zakázán pouze přesun založený na proaktivním vyvážení metrik.

Kapacita ve vyrovnávací paměti a upgrade

Obecně chcete, aby se upgrade dokončil, i když je cluster omezený nebo téměř plný. Správa kapacity clusteru je ještě důležitější během upgradů než obvykle. V závislosti na počtu upgradovaných domén je potřeba migrovat mezi 5 a 20 % kapacity při přechodu upgradu do clusteru. Ta práce musí někam jít. To je místo, kde je užitečný pojem vyrovnávací paměti kapacity . Během normálního provozu se respektuje kapacita uložená do vyrovnávací paměti. Správce prostředků clusteru může v případě potřeby vyplnit uzly až do celkové kapacity (spotřebovávají vyrovnávací paměť).

Další kroky

Začněte od začátku a získejte úvod do Resource Manageru clusteru Service Fabric.

Sdílet prostřednictvím