Sdílet prostřednictvím

Škálování clusterů Azure Service Fabric

  • Článek

Cluster Service Fabric je síťově propojená sada virtuálních nebo fyzických počítačů, ve kterých se nasazují a spravují vaše mikroslužby. Počítač nebo virtuální počítač, který je součástí clusteru, se nazývá uzel. Clustery můžou obsahovat tisíce uzlů. Po vytvoření clusteru Service Fabric můžete škálovat cluster horizontálně (změnit počet uzlů) nebo svisle (změnit prostředky uzlů). Cluster můžete škálovat kdykoli, i když jsou v clusteru spuštěné úlohy. S tím, jak se cluster škáluje, se automaticky škálují i vaše aplikace.

Proč škálovat cluster? Požadavky na aplikace se v průběhu času mění. Možná budete muset zvýšit prostředky clusteru, abyste vyhověli zvýšenému zatížení aplikací nebo síťovému provozu, nebo snížit prostředky clusteru při poklesu poptávky.

Horizontální navýšení a snížení kapacity nebo horizontální škálování

Změní počet uzlů v clusteru. Jakmile se nové uzly připojí ke clusteru, clusterová Resource Manager do nich přesune služby, což snižuje zatížení stávajících uzlů. Pokud se prostředky clusteru nevyužívá efektivně, můžete také snížit počet uzlů. Když uzly opustí cluster, služby se z nich přesunou a na zbývajících uzlech se zvýší zatížení. Snížení počtu uzlů v clusteru spuštěném v Azure vám může ušetřit peníze, protože platíte za počet virtuálních počítačů, které používáte, a ne za úlohy na těchto virtuálních počítačích.

  • Výhody: Nekonečné měřítko, teoreticky. Pokud je vaše aplikace navržená pro škálovatelnost, můžete povolit neomezený růst přidáním dalších uzlů. Nástroje v cloudových prostředích usnadňují přidávání nebo odebírání uzlů, takže je snadné upravit kapacitu a platit jenom za prostředky, které používáte.
  • Nevýhody: Aplikace musí být navrženy pro škálovatelnost. Databáze aplikací a trvalost můžou také vyžadovat další práci na architektuře pro škálování. Spolehlivé kolekce ve stavových službách Service Fabric ale výrazně usnadňují škálování dat aplikace.

Škálovací sady virtuálních počítačů jsou výpočetní prostředek Azure, který můžete použít k nasazení a správě kolekce virtuálních počítačů jako sady. Každý typ uzlu definovaný v clusteru Azure je nastavený jako samostatná škálovací sada. Každý typ uzlu se pak dá nezávisle škálovat nebo škálovat, má otevřené různé sady portů a může mít různé metriky kapacity.

Při škálování clusteru Azure mějte na paměti následující pokyny:

  • Primární typy uzlů, na kterých běží produkční úlohy, by měly mít vždy pět nebo více uzlů.
  • Jiné typy než primární uzly, na kterých běží stavové produkční úlohy, by měly mít vždy pět nebo více uzlů.
  • Typy neprimárních uzlů, na kterých běží bezstavové produkční úlohy, by měly mít vždy dva nebo více uzlů.
  • Každý typ uzlu úrovně stálosti gold nebo silver by měl mít vždy pět nebo více uzlů.
  • Neodstraňujte náhodné instance nebo uzly virtuálních počítačů z typu uzlu, vždy používejte funkci škálování škálovací sady virtuálních počítačů. Odstranění náhodných instancí virtuálních počítačů může nepříznivě ovlivnit schopnost systémů správně vyrovnávat zatížení.
  • Pokud používáte pravidla automatického škálování, nastavte je tak, aby se škálování na více instancí (odebírání instancí virtuálních počítačů) provádělo po jednotlivých uzlech. Vertikální snížení kapacity více instancí najednou není bezpečné.

Vzhledem k tomu, že typy uzlů Service Fabric ve vašem clusteru se skládají ze škálovacích sad virtuálních počítačů v back-endu, můžete nastavit pravidla automatického škálování nebo ručně škálovat jednotlivé typy uzlů nebo škálovací sadu virtuálních počítačů.

Programové škálování

V mnoha scénářích je vhodné škálovat cluster ručně nebo pomocí pravidel automatického škálování . Pro pokročilejší scénáře ale nemusí být vhodné. Mezi potenciální nevýhody těchto přístupů patří:

  • Ruční škálování vyžaduje, abyste se přihlásili a explicitně požádali o operace škálování. Pokud se operace škálování vyžadují často nebo v nepředvídatelných časech, nemusí být tento přístup vhodným řešením.
  • Když pravidla automatického škálování odeberou instanci ze škálovací sady virtuálních počítačů, neodeberou automaticky znalost tohoto uzlu z přidruženého clusteru Service Fabric, pokud typ uzlu nemá úroveň stálosti Silver nebo Gold. Vzhledem k tomu, že pravidla automatického škálování fungují na úrovni škálovací sady (nikoli na úrovni Service Fabric), můžou pravidla automatického škálování odebrat uzly Service Fabric bez jejich odkladu. Toto hrubé odebrání uzlu po operacích škálování na více instancí ponechá stav "ghost" uzlu Service Fabric. Jednotlivec (nebo služba) bude muset pravidelně vyčistit odebraný stav uzlu v clusteru Service Fabric.
  • Typ uzlu s úrovní stálosti Gold nebo Silver automaticky vyčistí odebrané uzly, takže není potřeba žádné další čištění.
  • I když pravidla automatického škálování podporují mnoho metrik , stále se jedná o omezenou sadu. Pokud váš scénář vyžaduje škálování na základě nějaké metriky, která není v této sadě popsaná, nemusí být pravidla automatického škálování vhodnou volbou.

Způsob, jakým byste měli přistupovat ke škálování Service Fabric, závisí na vašem scénáři. Pokud je škálování neobvyklé, je pravděpodobně dostatečná možnost přidat nebo odebrat uzly ručně. Pro složitější scénáře nabízejí výkonné alternativy pravidla automatického škálování a sady SDK, které zpřístupňuje možnost programového škálování.

Existují rozhraní API Azure, která aplikacím umožňují programově pracovat se škálovacími sadami virtuálních počítačů a clustery Service Fabric. Pokud stávající možnosti automatického škálování pro váš scénář nefungují, tato rozhraní API umožňují implementovat vlastní logiku škálování.

Jedním z přístupů k implementaci této "domácí" funkce automatického škálování je přidání nové bezstavové služby do aplikace Service Fabric, která bude spravovat operace škálování. Vytvoření vlastní služby škálování poskytuje nejvyšší stupeň kontroly a přizpůsobení chování vaší aplikace. To může být užitečné ve scénářích vyžadujících přesnou kontrolu nad tím, kdy a jak se aplikace škáluje nebo jak se škáluje. Tento ovládací prvek ale přináší kompromis mezi složitostí kódu. Tento přístup znamená, že potřebujete vlastní kód škálování, což není triviální. V rámci metody služby RunAsync může sada triggerů určit, jestli se vyžaduje škálování (včetně kontrolních parametrů, jako je maximální velikost clusteru a škálování).

Rozhraní API používané pro interakce škálovacích sad virtuálních počítačů (jak ke kontrole aktuálního počtu instancí virtuálních počítačů, tak k jeho úpravám) je plynulou výpočetní knihovnou azure management. Knihovna fluent compute poskytuje snadno použitelné rozhraní API pro interakci se škálovacími sadami virtuálních počítačů. K interakci se samotným clusterem Service Fabric použijte System.Fabric.FabricClient.

Škálovací kód se ale nemusí spouštět jako služba v clusteru, aby se škáloval. Ke svým přidruženým prostředkům Azure i IAzureFabricClient se můžou vzdáleně připojit, takže služba škálování může být snadno konzolová aplikace nebo služba windows spuštěná mimo aplikaci Service Fabric.

Na základě těchto omezení můžete chtít implementovat více přizpůsobené modely automatického škálování.

Vertikální navýšení a snížení kapacity nebo vertikální škálování

Změní prostředky (procesor, paměť nebo úložiště) uzlů v clusteru.

  • Výhody: Architektura softwaru a aplikací zůstává stejná.
  • Nevýhody: Konečné škálování, protože existuje limit, o kolik můžete zvýšit prostředky na jednotlivých uzlech. Výpadek, protože abyste mohli přidávat nebo odebírat prostředky, budete muset převést fyzické nebo virtuální počítače do offline režimu.

Škálovací sady virtuálních počítačů jsou výpočetní prostředek Azure, který můžete použít k nasazení a správě kolekce virtuálních počítačů jako sady. Každý typ uzlu definovaný v clusteru Azure je nastavený jako samostatná škálovací sada. Každý typ uzlu je pak možné spravovat samostatně. Škálování typu uzlu nahoru nebo dolů zahrnuje přidání nového typu uzlu (s aktualizovanou skladovou položkou virtuálního počítače) a odebrání starého typu uzlu.

Při škálování clusteru Azure mějte na paměti následující pokyny:

  • Při vertikálním snížení kapacity primárního typu uzlu byste nikdy neměli vertikálně snížit kapacitu, než umožňuje úroveň spolehlivosti .

Postup škálování typu uzlu nahoru nebo dolů se liší v závislosti na tom, jestli se jedná o neprimární nebo primární typ uzlu.

Škálování neprimárních typů uzlů

Vytvořte nový typ uzlu s prostředky, které potřebujete. Aktualizujte omezení umístění spuštěných služeb tak, aby zahrnovala nový typ uzlu. Postupně (postupně po jednom) snižte počet instancí starého typu uzlu na nulu, aby nedošlo k ovlivnění spolehlivosti clusteru. Služby budou postupně migrovat na nový typ uzlu, protože starý typ uzlu se vyřadí z provozu.

Škálování primárního typu uzlu

Nasaďte nový primární typ uzlu s aktualizovanou skladovou položkou virtuálního počítače a pak zakažte instance původního primárního typu uzlu jednu po druhé, aby se systémové služby migrovali do nové škálovací sady. Ověřte, že cluster a nové uzly jsou v pořádku, a pak odeberte původní škálovací sadu a stav uzlu pro odstraněné uzly.

Pokud to není možné, můžete vytvořit nový cluster a obnovit stav aplikace (pokud je k dispozici) ze starého clusteru. Nemusíte obnovovat žádný stav systémové služby, protože se znovu vytvoří při nasazení aplikací do nového clusteru. Pokud jste v clusteru jenom spouštěli bezstavové aplikace, pak stačí aplikace nasadit do nového clusteru a nemáte nic k obnovení.

Další kroky