Sdílet prostřednictvím


Přehled architektury Správce prostředků clusteru

Resource Manager clusteru Service Fabric je centrální služba, která běží v clusteru. Spravuje požadovaný stav služeb v clusteru, zejména s ohledem na spotřebu prostředků a případná pravidla umístění.

Ke správě prostředků v clusteru musí mít Resource Manager clusteru Service Fabric několik informací:

  • Které služby aktuálně existují
  • Aktuální (nebo výchozí) spotřeba prostředků každé služby
  • Zbývající kapacita clusteru
  • Kapacita uzlů v clusteru
  • Množství prostředků spotřebovaných v jednotlivých uzlech

Spotřeba prostředků dané služby se může v průběhu času měnit a služby se obvykle starají o více než jeden typ prostředku. Napříč různými službami se můžou měřit skutečné fyzické i fyzické prostředky. Služby můžou sledovat fyzické metriky, jako je využití paměti a disku. Častěji se služby můžou starat o logické metriky – například WorkQueueDepth nebo TotalRequests. Ve stejném clusteru je možné použít logické i fyzické metriky. Metriky můžou být sdílené napříč mnoha službami nebo specifické pro konkrétní službu.

Další důležité informace

Vlastníci a operátoři clusteru se můžou lišit od autorů služeb a aplikací nebo jsou minimálně stejní lidé s různými klobouky. Při vývoji aplikace víte několik věcí o tom, co vyžaduje. Máte odhad prostředků, které bude využívat, a způsobu nasazení různých služeb. Například webová vrstva musí běžet na uzlech vystavených na internetu, zatímco databázové služby by neměly. Dalším příkladem je, že webové služby jsou pravděpodobně omezené procesorem a sítí, zatímco služby datové vrstvy se více starají o využití paměti a disku. Osoba, která zpracovává incident živého webu pro danou službu v produkčním prostředí nebo která spravuje upgrade na službu, má ale jinou práci a vyžaduje jiné nástroje.

Cluster i služby jsou dynamické:

  • Počet uzlů v clusteru se může zvětšovat a zmenšovat
  • Uzly různých velikostí a typů můžou přicházet a odcházet
  • Služby je možné vytvářet, odebírat a měnit jejich požadované přidělování prostředků a pravidla umístění.
  • Upgrady nebo jiné operace správy se můžou provádět v clusteru na úrovni infrastruktury v aplikaci.
  • K selhání může dojít kdykoli.

Komponenty Cluster Resource Manageru a tok dat

Cluster Resource Manager musí sledovat požadavky jednotlivých služeb a spotřebu prostředků jednotlivými objekty služby v rámci těchto služeb. Cluster Resource Manager má dvě koncepční části: agenty, které běží na každém uzlu, a službu odolnou proti chybám. Agenti v každém uzlu sledují sestavy zatížení ze služeb, agregují je a pravidelně je hlásí. Služba Cluster Resource Manager agreguje všechny informace z místních agentů a reaguje na základě aktuální konfigurace.

Podívejme se na následující diagram:

Diagram znázorňující službu Cluster Resource Manager agreguje všechny informace z místních agentů a reaguje na základě aktuální konfigurace.

Během běhu může dojít k mnoha změnám. Řekněme například, že některé služby spotřebovávají změny prostředků, některé služby selžou a některé uzly se připojí ke clusteru a opustí ho. Všechny změny v uzlu se agregují a pravidelně odesílají do služby Cluster Resource Manager (1,2), kde se agregují, analyzují a ukládají. Každých několik sekund služba prohlédne změny a určí, jestli jsou potřeba nějaké akce (3). Může si například všimnout, že se do clusteru přidaly některé prázdné uzly. V důsledku toho se rozhodne přesunout některé služby do těchto uzlů. Resource Manager clusteru si také může všimnout, že je určitý uzel přetížený nebo že některé služby selhaly nebo byly odstraněny, a tím se uvolní prostředky jinde.

Podívejme se na následující diagram a podívejme se, co se stane dál. Řekněme, že Resource Manager clusteru určí, že je potřeba provést změny. Při provádění nezbytných změn koordinuje s dalšími systémovými službami (zejména se správcem převzetí služeb při selhání). Potřebné příkazy se pak odešlou do příslušných uzlů (4). Řekněme například, že si Resource Manager všimla přetížení Node5, a proto se rozhodla přesunout službu B z Node5 na Node4. Na konci rekonfigurace (5) vypadá cluster takto:

Architektura nástroje pro vyrovnávání prostředků

Další kroky