Představení Správce prostředků clusteru Service Fabric
Správa systémů IT nebo online služby tradičně 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ě. Existuje webová vrstva a vrstva "data" nebo "úložiště". Aplikace by měly vrstvu zasílání zpráv, kam se požadavky tekají a odjížděly, a také sadu počítačů vyhrazených pro ukládání do mezipaměti. Každá úroveň nebo typ úlohy měla 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, na kterých byly, byly příliš horké, pak jste do této vrstvy přidali další počítače se stejnou konfigurací. Ne všechny úlohy by se ale daly škálovat tak snadno – zejména u datové vrstvy byste obvykle nahradili počítače většími počítači. Snadné. Pokud počítač selhal, tato část celkové aplikace běžela s nižší kapacitou, dokud ho nebylo možné obnovit. Stále poměrně snadné (pokud ne nutně zábavné).
Teď se ale svět služeb a architektury softwaru změnil. Běžnější je, že aplikace přijaly návrh škálování na více instancí. Vytváření aplikací pomocí kontejnerů nebo mikroslužeb (nebo obojího) je běžné. Teď sice můžete mít jenom několik počítačů, ale nespouštějí jenom jednu instanci úlohy. Můžou dokonce současně spouštět několik různých úloh. Teď máte desítky různých typů služeb (žádná z nich nevyužití prostředků celého 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 zajištění vysoké dostupnosti(HA). V závislosti na velikosti těchto úloh a jejich vytížení se můžete setkat se stovkami nebo tisíci počítačů.
Správa prostředí není najednou 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 (přeci jen jste přepnuli názory z domácích zvířat na dobytek ). Konfigurace není o počítačích a více o samotných službách. Hardware, který je vyhrazený pro jednu instanci úlohy, je z velké části minulostí. Služby samotné se staly malými distribuovanými systémy, které pokrývají několik menších částí komoditního hardwaru.
Vzhledem k tomu, že vaše aplikace už není řadou monolitů rozložených do několika úrovní, můžete si poradit s mnoha dalšími kombinacemi. Kdo rozhoduje o tom, jaké typy úloh můžou běžet na jakém hardwaru nebo kolik? Které úlohy fungují dobře na stejném hardwaru a které konflikty? Jak víte, co tam na tom počítači běželo? Kdo má na starosti zajištění toho, aby úloha začala znovu běžet? Počkáte, až se počítač (virtuální?) vrátí, nebo se úlohy automaticky převezou na jiné počítače a budou dál spuštěné? Vyžaduje se zásah člověka? A co upgrady v tomto prostředí?
Jako vývojáři a operátoři pracující v tomto prostředí budeme potřebovat pomoc se správou této složitosti. Nábor a snaží se skrýt složitost s lidmi pravděpodobně není správná odpověď, takže co máme dělat?
Představení orchestrátorů
"Orchestrator" je obecný termín pro software, který správcům pomáhá spravovat tyto typy prostředí. Orchestrátory jsou komponenty, které přebírají požadavky typu "Chci, aby v mém prostředí běželo pět kopií této služby". Snaží se, aby prostředí odpovídalo požadovanému stavu, bez ohledu na to, co se stane.
Orchestrátory (ne lidé) jsou to, co provede 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 zabývá více než jen selháním. Mezi další funkce, které má, patří správa nových nasazení, zpracování upgradů a řešení spotřeby prostředků a zásad správného řízení. Všechny orchestrátory jsou v podstatě o udržování požadovaného stavu konfigurace v prostředí. Chcete mít možnost říct orchestrátorovi, co chcete, a nechat ho udělat těžkou práci. Mezi příklady orchestrátorů patří Aurora nad Mesosem, Datacentrum Dockeru nebo Docker Swarm, Kubernetes a Service Fabric. Tyto orchestrátory jsou aktivně vyvíjeny tak, aby splňovaly potřeby skutečných úloh v produkčních prostředích.
Orchestrace jako služba
Cluster Resource Manager je systémová komponenta, která zpracovává orchestraci v Service Fabric. Úloha Resource Manager clusteru je rozdělená do tří částí:
- Vynucování pravidel
- Optimalizace prostředí
- Pomoc s dalšími procesy
Co to není
V tradičních N-vrstvých aplikacích je vždy Load Balancer. Obvykle se jednalo o síťovou Load Balancer (NLB) nebo Load Balancer aplikace (ALB) v závislosti na tom, kde se nacházela v síťovém zásobníku. Některé nástroje pro vyrovnávání zatížení jsou založené na hardwaru, jako je například nabídka BigIP od F5, jiné jsou softwarové, například 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 dostávaly (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. Jiné poskytovaly připnutí relace nebo přilnutí. Pokročilejší nástroje pro vyrovnávání 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 snažily zajistit, aby webová nebo pracovní vrstva zůstala zhruba vyvážená. Strategie vyrovnávání datové vrstvy se liší a závisely na mechanismu ukládání dat. Vyrovnávání datové vrstvy se spoléhalo na horizontální dělení dat, ukládání do mezipaměti, spravovaná zobrazení, uložené procedury a další mechanismy specifické 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ě nebo mezipaměť. Síťová Load Balancer 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, a očekává, že provoz nebo zatížení bude následovat. Může například přesunout služby do uzlů, které jsou momentálně studené, protože služby, které jsou tam, neprovádí mnoho práce. Uzly můžou být studené, protože služby, které byly k dispozici, byly odstraněny nebo přesunuty jinam. Dalším příkladem může být Resource Manager clusteru, který může 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 ze strany služeb, které na něm běží. Případně se mohly zvýšit požadavky na prostředky služby. V důsledku toho není na tomto počítači dostatek prostředků k tomu, aby bylo možné ho dál používat.
Vzhledem k tomu, že clusterový Resource Manager zodpovídá za přesun služeb, obsahuje jinou sadu funkcí v porovnání s tím, co byste našli v nástroji pro vyrovnávání zatížení sítě. Je to proto, že nástroje pro vyrovnávání zatížení sítě doručují síťový provoz tam, kde už služby jsou, a to i v případě, že toto umístění není ideální pro spuštění samotné služby. Cluster Service Fabric Resource Manager používá zásadně odlišné strategie, jak zajistit efektivní využití prostředků v clusteru.
Další kroky
- Informace o architektuře a toku informací v rámci Resource Manager clusteru najdete v tomto článku.
- Resource Manager clusteru nabízí mnoho možností popisu clusteru. Další informace o metrikách najdete v tomto článku popisujícího cluster Service Fabric.
- Další informace o konfiguraci služeb najdete v tématu Informace o konfiguraci služeb.
- Metriky představují 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.
- Cluster Resource Manager funguje s možnostmi správy Service Fabric. Další informace o této integraci najdete v tomto článku.
- Informace o tom, jak clusterová Resource Manager spravuje a vyrovnává zatížení v clusteru, najdete v článku věnovaném vyrovnávání zatížení.