Představení Správce prostředků clusteru Service Fabric
Tradiční správa IT systémů nebo online služby znamenala vyhradit konkrétní fyzické nebo virtuální počítače těmto konkrétním službám nebo systémům. Služby byly navrženy jako úrovně. K dispozici by byla "webová" vrstva a "data" nebo "úložiště". Aplikace by měly vrstvu zasílání zpráv, ve které se požadavky přetékají a odsunou, a také sadu počítačů vyhrazených pro ukládání do mezipaměti. Každá úroveň nebo typ úlohy obsahovaly vyhrazené konkrétní počítače: databáze má několik vyhrazených počítačů, několik webových serverů. Pokud určitý typ úlohy způsobil, že počítače byly spuštěny příliš horké, pak jste do této úrovně přidali další počítače se stejnou konfigurací. Ne všechny úlohy se ale dají škálovat tak snadno – zejména u datové vrstvy, kterou byste obvykle nahradili většími počítači. Snadné. Pokud došlo k selhání počítače, tato část celkové aplikace běžela s nižší kapacitou, dokud se počítač neobnoví. Stále poměrně snadné (pokud ne nutně zábavné).
Nyní se ale změnil svět služeb a architektury softwaru. Je častější, že aplikace přijaly návrh se škálováním na více instancí. Vytváření aplikací pomocí kontejnerů nebo mikroslužeb (nebo obou) je běžné. I když teď možná máte jenom několik počítačů, neběží jenom jedna instance úlohy. Můžou dokonce současně spouštět více různých úloh. Nyní máte desítky různých typů služeb (bez využití plného počtu prostředků počítače), možná stovky různých instancí těchto služeb. Každá pojmenovaná instance má jednu nebo více instancí nebo replik pro vysokou dostupnost. V závislosti na velikostech těchto úloh a na tom, jak jsou zaneprázdněné, se můžete setkat se stovkami nebo tisíci počítačů.
Najednou není správa prostředí tak jednoduchá jako správa několika počítačů vyhrazených pro jednotlivé typy úloh. Vaše servery jsou virtuální a už nemají názvy (už jste přepnuli názory z domácích zvířat na dobytek ). Konfigurace je méně o počítačích a více o samotných službách. Hardware vyhrazený pro jednu instanci úlohy je z velké části věcí minulosti. Samotné služby se staly malými distribuovanými systémy, které pokrývají více menších částí komoditního hardwaru.
Vzhledem k tomu, že vaše aplikace už není řadou monolitických typů rozložených mezi několik vrstev, máte teď k dispozici mnoho dalších kombinací, se kterými se můžete vypořádat. Kdo rozhoduje, jaké typy úloh se můžou spouštět na kterém hardwaru nebo kolik? Které úlohy dobře fungují na stejném hardwaru a jaký konflikt? Když počítač přestane fungovat, jak poznáte, co tam na počítači běží? Kdo je zodpovědný za to, aby se úloha znovu spustila? Počkáte, až se počítač (virtuální?) vrátí, nebo vaše úlohy automaticky převezme služby při selhání na jiné počítače a budou dál spuštěné? Vyžaduje se lidský zásah? A co upgrady v tomto prostředí?
Jako vývojáři a operátoři pracující v tomto prostředí chceme pomoct se správou této složitosti. Nábor bingu a snaží se skrýt složitost s lidmi není pravděpodobně správnou odpovědí, takže co děláme?
Představení orchestrátorů
"Orchestrator" je obecný termín pro kus softwaru, který pomáhá správcům spravovat tyto typy prostředí. Orchestrátory jsou komponenty, které přebírají požadavky jako "Chci pět kopií této služby spuštěné v mém prostředí". Snaží se zajistit, aby prostředí odpovídalo požadovanému stavu bez ohledu na to, co se stane.
Orchestrátory (ne lidé) dělají akci, když počítač selže nebo se úloha z nějakého neočekávaného důvodu ukončí. Většina orchestrátorů se více než jen zabývá selháním. Další funkce, které mají, spravují nová nasazení, zpracovávají upgrady a řeší spotřebu prostředků a zásady správného řízení. Všechny orchestrátory jsou v podstatě o udržování požadovaného stavu konfigurace v prostředí. Chcete být schopni orchestrátorovi sdělit, co chcete, a mít to udělat těžké zvedání. Příkladem orchestrátorů jsou Aurora nad Mesosem, Datacentrem Dockeru/ Dockerem Swarm, Kubernetes a Service Fabric. Tyto orchestrátory se aktivně vyvíjejí tak, aby splňovaly potřeby skutečných úloh v produkčních prostředích.
Orchestrace jako služba
Správce prostředků clusteru je systémová komponenta, která zpracovává orchestraci v Service Fabric. Úloha Resource Manageru clusteru je rozdělená do tří částí:
- Vynucení pravidel
- Optimalizace prostředí
- Pomoc s jinými procesy
Na této stránce najdete školicí video, ve které se dozvíte, jak Cluster Resource Manager funguje:
Co to není
V tradičních n-vrstvých aplikacích je vždy Load Balancer. Obvykle se jednalo o nástroj pro vyrovnávání zatížení sítě (NLB) nebo nástroj pro vyrovnávání zatížení aplikace (ALB) v závislosti na tom, kde se nacházel v síťovém zásobníku. Některé nástroje pro vyrovnávání zatížení jsou hardwarové, jako je nabídka F5 BigIP, jiné jsou softwarové nástroje, jako je nlB od Microsoftu. V jiných prostředích se v této roli může zobrazit něco jako HAProxy, nginx, Istio nebo Envoy. V těchto architekturách je úlohou vyrovnávání zatížení zajistit, aby bezstavové úlohy přijímaly (zhruba) stejné množství práce. Strategie vyrovnávání zatížení se liší. Některé nástroje pro vyrovnávání by odesílaly každé jiné volání na jiný server. Ostatní poskytli připnutí/lepivost relace. Pokročilejší nástroje pro vyrovnávání zatížení používají odhad skutečného zatížení nebo generování sestav ke směrování volání na základě očekávaných nákladů a aktuálního zatížení počítače.
Nástroje pro vyrovnávání sítě nebo směrovače zpráv se pokusily zajistit, aby webová nebo pracovní vrstva zůstala zhruba vyvážená. Strategie vyrovnávání datové vrstvy se liší a závisely na mechanismu úložiště dat. Vyrovnávání datové vrstvy závisí na horizontálním dělení dat, ukládání do mezipaměti, spravovaných zobrazeních, uložených procedurách a dalších mechanismech specifických pro úložiště.
I když jsou některé z těchto strategií zajímavé, Resource Manager clusteru Service Fabric není nic jako nástroj pro vyrovnávání zatížení sítě ani mezipaměť. Nástroj pro vyrovnávání zatížení sítě vyrovnává front-endy rozložením provozu mezi front-endy. Resource Manager clusteru Service Fabric má jinou strategii. Service Fabric v podstatě přesouvá služby tam, kde mají největší smysl, očekávají provoz nebo zatížení. Může například přesunout služby na uzly, které jsou aktuálně studené, protože služby, které tam nejsou, moc nefungují. Uzly můžou být studené, protože služby, které byly přítomné, byly odstraněny nebo přesunuty jinam. Jako další příklad může Resource Manager clusteru přesunout službu mimo počítač. Možná se počítač chystá upgradovat nebo je přetížen kvůli prudkému nárůstu spotřeby službami, které na něm běží. Případně se můžou zvýšit požadavky na prostředky služby. V důsledku toho na tomto počítači není dostatek prostředků, aby ho mohli dál používat.
Vzhledem k tomu, že Správce prostředků clusteru zodpovídá za přesouvání služeb, obsahuje v porovnání s tím, co byste našli v nástroji pro vyrovnávání zatížení sítě, jinou sadu funkcí. Důvodem je to, že nástroje pro vyrovnávání zatížení sítě doručují síťový provoz tam, kde už jsou služby, i když toto umístění není ideální pro provozování samotné služby. Resource Manager clusteru Service Fabric využívá v podstatě různé strategie pro zajištění efektivního využití prostředků v clusteru.
Další kroky
- Informace o architektuře a toku informací v rámci Resource Manageru clusteru najdete v tomto článku.
- Správce prostředků clusteru má mnoho možností pro popis clusteru. Další informace o metrikách najdete v tomto článku popisující cluster Service Fabric.
- Další informace o konfiguraci služeb najdete v tématu o konfiguraci služeb.
- Metriky jsou způsob, jakým správce prostředků clusteru Service Fabric spravuje spotřebu a kapacitu v clusteru. Další informace o metrikách a jejich konfiguraci najdete v tomto článku.
- Správce prostředků clusteru funguje s možnostmi správy Service Fabric. Další informace o této integraci najdete v tomto článku.
- Pokud chcete zjistit, jak Resource Manager clusteru spravuje a vyrovnává zatížení v clusteru, přečtěte si článek o vyrovnávání zatížení.