Skálázás a Service Fabricben

Az Azure Service Fabric megkönnyíti a skálázható alkalmazások létrehozását a fürtök csomópontjainak szolgáltatásainak, partícióinak és replikáinak kezelésével. Számos számítási feladat ugyanazon a hardveren való futtatása maximális erőforrás-kihasználtságot tesz lehetővé, de rugalmasságot is biztosít a számítási feladatok méretezésének megválasztása szempontjából. Ez a Channel 9 videó bemutatja, hogyan hozhat létre méretezhető mikroszolgáltatás-alkalmazásokat:

A Service Fabricben a skálázás többféleképpen is elvégezhető:

1. Skálázás állapot nélküli szolgáltatáspéldányok létrehozásával vagy eltávolításával
2. Skálázás új nevesített szolgáltatások létrehozásával vagy eltávolításával
3. Skálázás új nevesített alkalmazáspéldányok létrehozásával vagy eltávolításával
4. Skálázás particionált szolgáltatások használatával
5. Skálázás csomópontok hozzáadásával és a fürtből való eltávolításával
6. Skálázás fürt Resource Manager metrikák használatával

Skálázás állapot nélküli szolgáltatáspéldányok létrehozásával vagy eltávolításával

A Service Fabricen belüli skálázás egyik legegyszerűbb módja az állapot nélküli szolgáltatásokkal működik. Állapot nélküli szolgáltatás létrehozásakor lehetőséget kap egy definiálására InstanceCount. InstanceCount azt határozza meg, hogy a szolgáltatás indításakor hány futó példány jön létre a szolgáltatás kódjában. Tegyük fel például, hogy a fürtben 100 csomópont található. Tegyük fel azt is, hogy egy 10-ből álló szolgáltatás jön létre InstanceCount . Futásidőben a kód 10 futó példánya túl elfoglalt lehet (vagy nem lehet elég elfoglalt). A számítási feladat méretezésének egyik módja a példányok számának módosítása. Egyes figyelési vagy felügyeleti kód például a meglévő példányok számát 50-re vagy 5-re módosíthatja attól függően, hogy a számítási feladatnak a terhelés alapján kell-e vertikálisan fel- vagy leskáláznia.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Dinamikus példányszám használata

Az állapot nélküli szolgáltatások esetében a Service Fabric automatikus módot kínál a példányok számának módosítására. Ez lehetővé teszi, hogy a szolgáltatás dinamikusan skálázzon az elérhető csomópontok számával. Ezt a viselkedést úgy választhatja ki, hogy beállítja a példányok számát = -1. InstanceCount = -1 a Service Fabricnek az "Állapot nélküli szolgáltatás futtatása minden csomóponton" utasítás. Ha a csomópontok száma megváltozik, a Service Fabric automatikusan egyezőre módosítja a példányszámot, biztosítva, hogy a szolgáltatás az összes érvényes csomóponton fusson.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Skálázás új nevesített szolgáltatások létrehozásával vagy eltávolításával

A nevesített szolgáltatáspéldány egy adott szolgáltatástípus példánya (lásd : Service Fabric-alkalmazás életciklusa) a fürt néhány nevesített alkalmazáspéldányán belül.

Új nevesített szolgáltatáspéldányok hozhatók létre (vagy távolíthatók el), amint a szolgáltatások többé-kevésbé elfoglaltak lesznek. Ez lehetővé teszi, hogy a kérések több szolgáltatáspéldány között legyenek elosztva, ami általában lehetővé teszi a meglévő szolgáltatások terhelésének csökkentését. Szolgáltatások létrehozásakor a Service Fabric-fürt Resource Manager elosztott módon helyezi el a szolgáltatásokat a fürtben. A pontos döntéseket a fürt metrikái és más elhelyezési szabályok szabályozzák. A szolgáltatások többféleképpen is létrehozhatóak, de a leggyakoribbak vagy olyan rendszergazdai műveleteken keresztül, mint például a hívása New-ServiceFabricService, vagy kódhívással CreateServiceAsync. CreateServiceAsync a fürtben futó más szolgáltatásokból is meghívható.

A szolgáltatások dinamikus létrehozása sokféle forgatókönyvben használható, és gyakori minta. Vegyünk például egy állapotalapú szolgáltatást, amely egy adott munkafolyamatot jelöl. A munkát jelképező hívások megjelennek ebben a szolgáltatásban, és ez a szolgáltatás végrehajtja a munkafolyamat lépéseit, és rögzíti az előrehaladást.

Hogyan méretezné ezt a szolgáltatást? A szolgáltatás lehet több-bérlős valamilyen formában, és fogadja a hívásokat, és elindítja a lépéseket ugyanazon munkafolyamat számos különböző példányán egyszerre. Ez azonban összetettebbé teheti a kódot, mivel most ugyanannak a munkafolyamatnak számos különböző példánya miatt kell aggódnia, amelyek mindegyike különböző fázisokban és különböző ügyfelektől származik. Emellett több munkafolyamat egyidejű kezelése nem oldja meg a skálázási problémát. Ennek az az oka, hogy egy bizonyos ponton ez a szolgáltatás túl sok erőforrást fog használni ahhoz, hogy elférjen egy adott gépen. Sok olyan szolgáltatás, amelyet nem erre a mintára építettek, szintén nehézségekbe ütközik a kódban rejlő szűk keresztmetszet vagy lassulás miatt. Az ilyen típusú problémák miatt a szolgáltatás nem fog működni, ha az egyidejűleg nyomon követett munkafolyamatok száma megnő.

A megoldás a szolgáltatás egy példányának létrehozása a nyomon követni kívánt munkafolyamat minden különböző példányához. Ez egy nagyszerű minta, és működik, hogy a szolgáltatás állapot nélküli vagy állapotalapú. Ahhoz, hogy ez a minta működjön, általában van egy másik szolgáltatás, amely "Workload Manager-szolgáltatásként" működik. A szolgáltatás feladata a kérések fogadása és a kérések más szolgáltatásokhoz való átirányítása. A felettes dinamikusan létrehozhatja a számításifeladat-szolgáltatás egy példányát, amikor megkapja az üzenetet, majd továbbíthatja a kéréseket ezeknek a szolgáltatásoknak. A kezelőszolgáltatás visszahívásokat is fogadhat, ha egy adott munkafolyamat-szolgáltatás befejezi a feladatát. Amikor a felettes megkapja ezeket a visszahívásokat, törölheti a munkafolyamat-szolgáltatás adott példányát, vagy elhagyhatja, ha további hívások várhatók.

Az ilyen típusú kezelő speciális verziói akár az általa kezelt szolgáltatások készleteit is létrehozhatják. A készlet segít biztosítani, hogy amikor új kérés érkezik, ne kelljen megvárnia a szolgáltatás üzembe helyezését. Ehelyett a felettes egyszerűen kiválaszthat egy munkafolyamat-szolgáltatást, amely jelenleg nincs elfoglalva a készletből, vagy véletlenszerűen irányíthat. A szolgáltatások készletének rendelkezésre állása felgyorsítja az új kérések kezelését, mivel kevésbé valószínű, hogy a kérésnek várnia kell egy új szolgáltatás meggyorsítására. Az új szolgáltatások létrehozása gyors, de nem ingyenes vagy azonnali. A készlet segít minimalizálni azt az időtartamot, amíg a kérésnek várnia kell a kiszolgálás előtt. Ez a kezelő- és készletminta gyakran akkor jelenik meg, ha a válaszidő számít a legjobban. A kérés várólistára helyezése és a szolgáltatás létrehozása a háttérben, majd továbbadása szintén népszerű kezelői minta, ahogy a szolgáltatások létrehozása és törlése is a szolgáltatás által jelenleg függőben lévő munka mennyiségének nyomon követése alapján.

Skálázás új nevesített alkalmazáspéldányok létrehozásával vagy eltávolításával

A teljes alkalmazáspéldányok létrehozása és törlése hasonló a szolgáltatások létrehozásának és törlésének mintájához. Ebben a mintában van néhány kezelői szolgáltatás, amely a megjelenő kérések és a fürt többi szolgáltatásától kapott információk alapján hoz döntést.

Mikor érdemes új nevesített alkalmazáspéldányt létrehozni ahelyett, hogy új nevesített szolgáltatáspéldányokat hoz létre néhány már meglévő alkalmazásban? Van néhány eset:

• Az új alkalmazáspéldány olyan ügyfél számára készült, akinek a kódját bizonyos identitás- vagy biztonsági beállítások mellett kell futtatnia.
  • A Service Fabric lehetővé teszi, hogy különböző kódcsomagok meghatározott identitások alatt fussanak. Ahhoz, hogy ugyanazt a kódcsomagot különböző identitások alatt lehessen elindítani, az aktiválásoknak különböző alkalmazáspéldányokban kell történnie. Fontolja meg azt az esetet, amikor egy meglévő ügyfél számítási feladatai vannak üzembe helyezve. Előfordulhat, hogy ezek egy adott identitás alatt futnak, így figyelheti és szabályozhatja más erőforrásokhoz, például távoli adatbázisokhoz vagy más rendszerekhez való hozzáférésüket. Ebben az esetben, amikor egy új ügyfél regisztrál, valószínűleg nem szeretné ugyanabban a környezetben (folyamattérben) aktiválni a kódot. Bár lehetséges, ez megnehezíti, hogy a szolgáltatáskód egy adott identitás kontextusában működjön. Általában nagyobb biztonsággal, elkülönítéssel és identitáskezelési kóddal kell rendelkeznie. Ahelyett, hogy különböző nevesített szolgáltatáspéldányokat használne ugyanazon az alkalmazáspéldányon belül, és így ugyanazt a folyamatteret, használhat különböző nevű Service Fabric-alkalmazáspéldányokat. Ez megkönnyíti a különböző identitáskörnyezetek meghatározását.
• Az új alkalmazáspéldány konfigurációs eszközként is szolgál
  • Alapértelmezés szerint egy adott szolgáltatástípus összes megnevezett szolgáltatáspéldánya ugyanabban a folyamatban fut egy adott csomóponton. Ez azt jelenti, hogy bár az egyes szolgáltatáspéldányokat eltérően konfigurálhatja, ez bonyolult feladat. A szolgáltatásoknak rendelkezniük kell valamilyen jogkivonattal, amelyet a konfigurációs csomag konfigurációjának kereséséhez használnak. Általában ez csak a szolgáltatás neve. Ez jól működik, de a konfigurációt az adott alkalmazáspéldányon belüli egyedi nevesített szolgáltatáspéldányok nevével párosítja. Ez zavaró lehet és nehezen kezelhető, mivel a konfiguráció általában egy tervezési idő összetevő, amely alkalmazáspéldány-specifikus értékekkel rendelkezik. A további szolgáltatások létrehozása mindig több alkalmazásfrissítést jelent a konfigurációs csomagokban lévő információk módosításához vagy újak üzembe helyezéséhez, hogy az új szolgáltatások megkereshessék a konkrét információkat. Gyakran egyszerűbb egy teljesen új, elnevezett alkalmazáspéldányt létrehozni. Ezután az alkalmazásparaméterekkel beállíthatja a szolgáltatásokhoz szükséges konfigurációt. Így a nevesített alkalmazáspéldányon belül létrehozott összes szolgáltatás örökölheti az adott konfigurációs beállításokat. Például ahelyett, hogy egyetlen konfigurációs fájllal rendelkezik, amely minden ügyfél beállításait és testreszabásait , például titkos kódokat vagy ügyfélerőforrás-korlátokat használná, ehelyett minden ügyfélhez más-más alkalmazáspéldányt kellene használnia, amely felülbírálná ezeket a beállításokat.
• Az új alkalmazás frissítési határként szolgál
  • A Service Fabricben a különböző nevesített alkalmazáspéldányok határként szolgálnak a frissítéshez. Az egyik elnevezett alkalmazáspéldány frissítése nem befolyásolja azt a kódot, amelyet egy másik nevesített alkalmazáspéldány futtat. A különböző alkalmazások végül ugyanazon kód különböző verzióit futtatják ugyanazon a csomóponton. Ez tényező lehet, ha méretezési döntést kell hoznia, mert eldöntheti, hogy az új kódnak ugyanazokat a frissítéseket kell-e követnie, mint egy másik szolgáltatás, vagy sem. Tegyük fel például, hogy egy hívás érkezik a felettesi szolgáltatáshoz, amely egy adott ügyfél számítási feladatainak skálázásáért felelős a szolgáltatások dinamikus létrehozásával és törlésével. Ebben az esetben azonban a hívás egy új ügyfélhez társított számítási feladathoz tartozik. A legtöbb ügyfél szereti, ha nem csak a korábban felsorolt biztonsági és konfigurációs okok miatt különülnek el egymástól, hanem azért is, mert nagyobb rugalmasságot biztosít a szoftver adott verzióinak futtatása és a frissítés időpontjának kiválasztása szempontjából. Létrehozhat egy új alkalmazáspéldányt is, és ott hozhatja létre a szolgáltatást egyszerűen a szolgáltatások mennyiségének további particionálása érdekében, amelyet egy frissítés érint. A különálló alkalmazáspéldányok nagyobb részletességet biztosítanak az alkalmazásfrissítések során, valamint lehetővé teszik az A/B-tesztelést és a kék/zöld üzemelő példányokat.
• A meglévő alkalmazáspéldány megtelt
  • A Service Fabricben az alkalmazáskapacitás egy olyan fogalom, amellyel szabályozhatja az egyes alkalmazáspéldányokhoz elérhető erőforrások mennyiségét. Dönthet például úgy, hogy egy adott szolgáltatásnak egy másik példányt kell létrehoznia a skálázáshoz. Ez az alkalmazáspéldány azonban nem rendelkezik kapacitással egy adott metrika esetében. Ha az adott ügyfélnek vagy számítási feladatnak továbbra is több erőforrást kell biztosítania, akkor növelheti az adott alkalmazás meglévő kapacitását, vagy létrehozhat egy új alkalmazást.

Skálázás a partíció szintjén

A Service Fabric támogatja a particionálást. A particionálás több logikai és fizikai szakaszra osztja fel a szolgáltatást, amelyek mindegyike egymástól függetlenül működik. Ez az állapotalapú szolgáltatások esetében hasznos, mivel egyetlen replikakészletnek sem kell egyszerre kezelnie az összes hívást, és módosítania az összes állapotot. A particionálás áttekintése információt nyújt a támogatott particionálási sémák típusairól. Az egyes partíciók replikái el vannak osztva a fürt csomópontjai között, elosztva a szolgáltatás terhelését, és biztosítják, hogy sem a szolgáltatás egésze, sem bármely partíció egyetlen meghibásodási ponttal rendelkezzen.

Fontolja meg egy olyan szolgáltatást, amely egy tartományos particionálási sémát használ alacsony 0 kulccsal, 99-ből álló magas kulccsal és 4 partíciószámmal. Egy háromcsomópontos fürtön a szolgáltatás négy replikával helyezhető el, amelyek az erőforrásokat az egyes csomópontokon osztják meg az itt látható módon:

Ha növeli a csomópontok számát, a Service Fabric áthelyezi a meglévő replikák egy részét. Tegyük fel például, hogy a csomópontok száma négyre nő, és a replikák újraelosztásra kerülnek. Most a szolgáltatás három replikát futtat minden csomóponton, mindegyik különböző partíciókhoz tartozik. Ez jobb erőforrás-kihasználtságot tesz lehetővé, mivel az új csomópont nem ritka. Általában javítja a teljesítményt is, mivel minden szolgáltatás több erőforrással rendelkezik.

Skálázás a Service Fabric-fürt Resource Manager és metrikáinak használatával

A metrikák azt jelzik , hogy a szolgáltatások hogyan fejezik ki az erőforrás-használatukat a Service Fabricnek. A metrikák használatával a fürt Resource Manager lehetőséget nyújt a fürt elrendezésének átrendezésére és optimalizálására. Előfordulhat például, hogy rengeteg erőforrás található a fürtben, de előfordulhat, hogy nem lesznek lefoglalva a jelenleg munkát végző szolgáltatásokhoz. A metrikák használatával a Fürt Resource Manager átrendezi a fürtöt, hogy a szolgáltatások hozzáférhessenek a rendelkezésre álló erőforrásokhoz.

Skálázás csomópontok hozzáadásával és a fürtből való eltávolításával

A Service Fabrictel való skálázás másik lehetősége a fürt méretének módosítása. A fürt méretének módosítása azt jelenti, hogy csomópontokat ad hozzá vagy távolít el a fürt egy vagy több csomóponttípusához. Vegyük például azt az esetet, amikor a fürt összes csomópontja gyakori. Ez azt jelenti, hogy a fürt erőforrásai szinte mind fel vannak használva. Ebben az esetben a méretezés legjobb módja, ha több csomópontot ad hozzá a fürthöz. Miután az új csomópontok csatlakoznak a fürthöz, a Service Fabric-fürt Resource Manager áthelyezi a szolgáltatásokat, ami kevesebb terhelést eredményez a meglévő csomópontokon. A példányszám = -1 állapot nélküli szolgáltatások esetében a rendszer automatikusan további szolgáltatáspéldányokat hoz létre. Ez lehetővé teszi egyes hívások áthelyezését a meglévő csomópontokról az új csomópontokra.

További információ: fürtskálázás.

Platform kiválasztása

Az operációs rendszerek közötti megvalósítási különbségek miatt a Service Fabric windowsos vagy linuxos használata elengedhetetlen része lehet az alkalmazás skálázásának. Az egyik lehetséges akadály a szakaszos naplózás végrehajtása. A Windows rendszeren futó Service Fabric kernelillesztőt használ egy gépenkénti naplóhoz, amely meg van osztva az állapotalapú szolgáltatásreplikák között. Ez a napló súlya körülbelül 8 GB. A Linux viszont minden replikához 256 MB-os előkészítési naplót használ, így kevésbé ideális az olyan alkalmazások számára, amelyek maximalizálni szeretnék az adott csomóponton futó egyszerűsített szolgáltatásreplikák számát. Az ideiglenes tárolási követelmények különbségei potenciálisan tájékoztathatják a Service Fabric-fürt üzembe helyezéséhez kívánt platformot.

Végső összeállítás

Vegyük át az itt tárgyalt összes ötletet, és beszéljünk egy példán keresztül. Vegye figyelembe a következő szolgáltatást: olyan szolgáltatást próbál létrehozni, amely címjegyzékként működik, és a nevekhez és a kapcsolattartási adatokhoz ragaszkodik.

A skálázható mennyiséggel kapcsolatban számos kérdés merült fel: Hány felhasználóval fog rendelkezni? Hány névjegyet tárolnak az egyes felhasználók? Nehéz kitalálni ezt az egészet, amikor első alkalommal áll a szolgáltatás mellett. Tegyük fel, hogy egy adott partíciószámmal rendelkező statikus szolgáltatással akart menni. A helytelen partíciószám kiválasztásának következményei később skálázási problémákat okozhatnak. Hasonlóképpen, még ha a megfelelő számot választja is, előfordulhat, hogy nem minden szükséges információval rendelkezik. Például a fürt méretét is előre kell eldöntenie, mind a csomópontok száma, mind a méretük szempontjából. Általában nehéz megjósolni, hogy egy szolgáltatás hány erőforrást fog felhasználni az élettartama során. Az is nehéz lehet előre tudni, hogy milyen forgalmi mintát lát a szolgáltatás. Előfordulhat például, hogy az emberek csak reggel felveszik és eltávolítják a névjegyeiket, vagy a nap folyamán egyenletesen oszlanak el. Ennek alapján előfordulhat, hogy dinamikusan kell felskáláznia a skálázást. Lehet, hogy megtanulhatja előre jelezni, hogy mikor kell vertikálisan felskáláznia, de mindkét esetben valószínűleg reagálnia kell a szolgáltatás erőforrás-felhasználásának változására. Ez magában foglalhatja a fürt méretének módosítását, hogy több erőforrást biztosítson, ha a meglévő erőforrások újraszervezése nem elegendő.

De miért is próbál meg egyetlen partíciós sémát választani az összes felhasználó számára? Miért érdemes egy szolgáltatásra és egy statikus fürtre korlátozni magát? A valós helyzet általában dinamikusabb.

Ha méretezésre készül, vegye figyelembe az alábbi dinamikus mintát. Előfordulhat, hogy a helyzethez kell igazítania:

1. Ahelyett, hogy mindenki számára szeretne particionálási sémát választani, hozzon létre egy "kezelőszolgáltatást".
2. A kezelői szolgáltatás feladata, hogy az ügyféladatokat megtekintse, amikor regisztrálnak a szolgáltatásra. Ezután attól függően, hogy milyen információkat tartalmaz, a kezelő szolgáltatás létrehoz egy példányt a tényleges contact-storage szolgáltatásból csak az adott ügyfél számára. Ha adott konfigurációt, elkülönítést vagy frissítést igényelnek, dönthet úgy is, hogy elindít egy alkalmazáspéldányt az ügyfél számára.

Ez a dinamikus létrehozási minta számos előnnyel jár:

• Nem próbálja kitalálni a megfelelő partíciószámot az összes felhasználó számára, vagy egyetlen olyan szolgáltatást kell létrehoznia, amely önmagában végtelenül méretezhető.
• A különböző felhasználóknak nem kell ugyanazt a partíciószámot, replikaszámot, elhelyezési korlátozásokat, metrikákat, alapértelmezett terheléseket, szolgáltatásneveket, DNS-beállításokat vagy a szolgáltatás vagy alkalmazás szintjén megadott egyéb tulajdonságokat megadniuk.
• További adatszegmentálást kap. Minden ügyfélnek saját példánya van a szolgáltatásról
  • Minden ügyfélszolgálat különböző módon konfigurálható, és több vagy kevesebb erőforrást adhat meg, szükség szerint több vagy kevesebb partícióval vagy replikával a várt méret alapján.
    • Tegyük fel például, hogy az ügyfél az "Arany" szintért fizetett – több replikát vagy nagyobb partíciószámot kaphat, és potenciálisan a szolgáltatásaikhoz dedikált erőforrásokat is kaphat metrikákkal és alkalmazáskapacitásokkal.
    • Vagy tegyük fel, hogy olyan információkat adtak meg, amelyek jelzik, hogy a szükséges névjegyek száma "Kicsi" volt – csak néhány partíciót kapnak, vagy akár más ügyfelekkel is megosztott szolgáltatáskészletbe helyezhetők.
• Nem futtat egy csomó szolgáltatáspéldányt vagy replikát, amíg az ügyfelekre vár, hogy megjelenjenek
• Ha egy ügyfél távozik, akkor az adatainak eltávolítása a szolgáltatásból olyan egyszerű, mintha a felettes törölné az általa létrehozott szolgáltatást vagy alkalmazást.

Következő lépések

A Service Fabric fogalmaival kapcsolatos további információkért tekintse meg a következő cikkeket:

• A Service Fabric-szolgáltatások rendelkezésre állása
• Service Fabric-szolgáltatások particionálása