A Service Fabric-fürt erőforrás-kezelőjének bemutatása

Az informatikai rendszerek vagy online szolgáltatások kezelése hagyományosan azt jelentette, hogy adott fizikai vagy virtuális gépeket ezeknek az adott szolgáltatásoknak vagy rendszereknek szántak. A szolgáltatások rétegként lettek összeállítva. Létezik egy "webes" szint és egy "data" vagy "storage" szint. Az alkalmazások egy üzenetkezelési szinttel rendelkeznének, ahol a kérések be- és kifelé áramlanak, valamint a gyorsítótárazással foglalkozó gépek készlete. A számítási feladatok egyes szintjeihez vagy típusaihoz külön gépek voltak dedikáltak: az adatbázishoz több dedikált gép, a webkiszolgálók is csatlakoztak. Ha egy adott típusú számítási feladat miatt a gépek túl gyakori működést eredményeztek, akkor több, azonos konfigurációjú gépet adott hozzá ehhez a szinthez. Azonban nem minden számítási feladat méretezhető fel ilyen könnyen – különösen az adatréteg esetében, ha a gépeket általában nagyobb gépekre cserélné. Nem nehéz. Ha egy gép meghibásodott, a teljes alkalmazás ezen része alacsonyabb kapacitással futott, amíg a gép vissza nem állítható. Még mindig meglehetősen könnyű (ha nem feltétlenül szórakoztató).

Most azonban megváltozott a szolgáltatás- és szoftverarchitektúra világa. Gyakoribb, hogy az alkalmazások kibővített kialakítást alkalmaztak. Gyakori, hogy tárolókkal vagy mikroszolgáltatásokkal (vagy mindkettővel) készít alkalmazásokat. Bár lehet, hogy még mindig csak néhány gépe van, azok nem csak egy számítási feladatpéldányt futtatnak. Előfordulhat, hogy egyszerre több különböző számítási feladatot is futtatnak. Most már több tucat különböző típusú szolgáltatással rendelkezik (amelyek egyike sem használja fel egy teljes gép erőforrásait), talán több száz különböző példánya van ezeknek a szolgáltatásoknak. Minden megnevezett példányhoz tartozik egy vagy több példány vagy replika a magas rendelkezésre álláshoz (HA). A számítási feladatok méretétől és elfoglaltságától függően több száz vagy több ezer géppel találkozhat.

A környezet hirtelen kezelése nem olyan egyszerű, mint néhány, az egyes számítási feladatokhoz dedikált gép kezelése. A kiszolgálók virtuálisak, és már nem rendelkeznek névvel (a háziállatokról a szarvasmarhákra váltott). A konfiguráció kevésbé a gépekről és magukról a szolgáltatásokról szól. A számítási feladatok egyetlen példányának dedikált hardver nagyrészt a múlté. Maguk a szolgáltatások kisméretű elosztott rendszerekké váltak, amelyek több kisebb árucikk-hardverre terjednek ki.

Mivel az alkalmazás már nem több szinten elterjedt monolitok sorozata, most már sokkal több kombinációval kell foglalkoznia. Ki dönti el, hogy milyen típusú számítási feladatok futtathatók a hardveren, vagy hányan? Mely számítási feladatok működnek jól ugyanazon a hardveren, és melyik ütközés? Ha egy gép leáll, honnan tudja, hogy mi futott ott azon a gépen? Ki felel annak biztosításáért, hogy a számítási feladat újra elinduljon? Megvárja, amíg a (virtuális?) gép visszatér, vagy a számítási feladatok automatikusan feladatátvételt hajtanak végre más gépeken, és továbbra is futnak? Szükség van emberi beavatkozásra? Mi a helyzet a frissítésekkel ebben a környezetben?

Ebben a környezetben tevékenykedő fejlesztőkként és üzemeltetőkként segítségre lesz szükségünk ennek az összetettségnek a kezelésében. A felvételi binge és próbálják elrejteni az összetettség az emberekkel valószínűleg nem a megfelelő válasz, szóval mit csinálunk?

Vezénylők bemutatása

Az "Orchestrator" egy szoftver általános kifejezése, amely segít a rendszergazdáknak az ilyen típusú környezetek kezelésében. A vezénylők azok az összetevők, amelyek a következő kéréseket fogadják el: "Szeretném, ha a szolgáltatás öt példánya futna a környezetemben". Megpróbálják elérni, hogy a környezet megfeleljen a kívánt állapotnak, függetlenül attól, hogy mi történik.

Az vezénylők (nem emberek) akkor hajtanak végre műveletet, ha egy gép meghibásodik, vagy egy számítási feladat valamilyen váratlan okból leáll. A legtöbb vezénylő nem csak a hibákkal foglalkozik. A többi funkciójuk az új üzemelő példányok kezelése, a frissítések kezelése, valamint az erőforrás-használat és az irányítás kezelése. Minden vezénylő alapvetően a kívánt konfigurációs állapot fenntartásáról szól a környezetben. El szeretné mondani egy vezénylőnek, hogy mit akar, és azt szeretné, hogy tegye meg a nehéz emelést. A Mesos, a Docker Datacenter/Docker Swarm, a Kubernetes és a Service Fabric tetején található Aurora mind példa a vezénylőkre. Ezeket a vezénylőket aktívan fejlesztik, hogy megfeleljenek az éles környezetekben található valós számítási feladatok igényeinek.

Vezénylés szolgáltatásként

A Fürt Resource Manager a Service Fabricben történő vezénylést kezelő rendszerösszetevő. A fürt Resource Manager feladata három részre oszlik:

1. Szabályok kényszerítése
2. A környezet optimalizálása
3. Segítségnyújtás más folyamatokhoz

Ezen a lapon talál egy oktatóvideót, amelyből megtudhatja, hogyan működik a fürt Resource Manager:

Mi nem az?

A hagyományos N szintű alkalmazásokban mindig van Load Balancer. Ez általában hálózati Load Balancer (NLB) vagy alkalmazás Load Balancer (ALB) volt attól függően, hogy hol volt a hálózati veremben. Egyes terheléselosztók hardveralapúak, például az F5 BigIP-ajánlata, mások szoftveralapúak, például a Microsoft NLB-jét. Más környezetekben például a HAProxy, az nginx, az Istio vagy az Envoy jelenhet meg ebben a szerepkörben. Ezekben az architektúrákban a terheléselosztás feladata annak biztosítása, hogy az állapot nélküli számítási feladatok nagyjából ugyanannyi munkát kapjanak. A terheléselosztási stratégiák változatosak. Egyes kiegyensúlyozók minden egyes hívást egy másik kiszolgálóra küldenek. Mások munkamenet-rögzítést/ragadósságot biztosítottak. A fejlettebb kiegyensúlyozók tényleges terhelésbecsléssel vagy jelentéskészítéssel irányítják a hívásokat a várható költségek és a gép aktuális terhelése alapján.

A hálózati kiegyensúlyozók vagy az üzenet útválasztói megpróbálták biztosítani, hogy a webes/feldolgozói szint nagyjából kiegyensúlyozott maradjon. Az adatszint kiegyensúlyozási stratégiái eltérőek voltak, és az adattárolási mechanizmustól függtek. Az adatszint kiegyensúlyozása az adatok horizontális felosztására, gyorsítótárazására, felügyelt nézetekre, tárolt eljárásokra és más tárolóspecifikus mechanizmusokra támaszkodott.

Bár néhány ilyen stratégia érdekes, a Service Fabric-fürt Resource Manager nem olyan, mint egy hálózati terheléselosztó vagy egy gyorsítótár. A hálózati Load Balancer az előtérrendszereket úgy egyensúlyba hozják, hogy elosztják a forgalmat az előtérben. A Service Fabric-fürt Resource Manager más stratégiával rendelkezik. A Service Fabric alapvetően oda helyezi át a szolgáltatásokat , ahol a legérthetőbbek, és elvárják a forgalom vagy a terhelés követését. Előfordulhat például, hogy olyan csomópontokra helyezi át a szolgáltatásokat, amelyek jelenleg hidegek, mert az ott található szolgáltatások nem végeznek sok munkát. Előfordulhat, hogy a csomópontok hidegek, mivel a jelen lévő szolgáltatásokat törölték vagy áthelyezték máshová. Egy másik példaként a Fürt Resource Manager is áthelyezhet egy szolgáltatást egy gépről. Lehet, hogy a gép hamarosan frissül, vagy túlterhelt, mert a rajta futó szolgáltatások kihasználtságában megnőtt a használat. Másik lehetőségként a szolgáltatás erőforrás-követelményeinek növekedése is előfordulhat. Ennek eredményeképpen a gépen nincs elegendő erőforrás a futtatás folytatásához.

Mivel a fürt Resource Manager feladata a szolgáltatások áthelyezése, a hálózati terheléselosztóban találhatóhoz képest más szolgáltatáskészletet tartalmaz. Ennek az az oka, hogy a hálózati terheléselosztók hálózati forgalmat biztosítanak oda, ahol a szolgáltatások már vannak, még akkor is, ha ez a hely nem ideális a szolgáltatás futtatásához. A Service Fabric-fürt Resource Manager alapvetően különböző stratégiákat alkalmaz a fürt erőforrásainak hatékony felhasználásának biztosítására.

Következő lépések

• A fürt Resource Manager belüli architektúrával és információáramlással kapcsolatos információkért tekintse meg ezt a cikket
• A Fürt Resource Manager számos lehetőséget kínál a fürt leírására. A metrikákkal kapcsolatos további információkért tekintse meg a Service Fabric-fürtök leírásáról szóló cikket.
• A szolgáltatások konfigurálásával kapcsolatos további információkért tekintse meg a szolgáltatások konfigurálását ismertető cikket.
• A metrikák segítségével a Service Fabric-fürt erőforrás-kezelője kezeli a fürtben lévő felhasználást és kapacitást. A metrikákkal és azok konfigurálásával kapcsolatos további információkért tekintse meg ezt a cikket
• A Fürt Resource Manager együttműködik a Service Fabric felügyeleti képességeivel. Ha többet szeretne megtudni erről az integrációról, olvassa el ezt a cikket
• Ha tudni szeretné, hogy a fürt Resource Manager hogyan kezeli és egyensúlyozza a fürt terhelését, tekintse meg a terheléselosztásról szóló cikket.