Üzembehelyezési bélyegek mintája

Az üzembehelyezési bélyegminta magában foglalja az erőforrások heterogén csoportjának kiépítését, kezelését és monitorozását több számítási feladat vagy bérlő üzemeltetéséhez és üzemeltetéséhez. Minden egyes példányt bélyegnek vagy néha szolgáltatási egységnek, skálázási egységnek vagy cellának nevezünk. Több-bérlős környezetben minden bélyeg- vagy méretezési egység előre meghatározott számú bérlőt képes kiszolgálni. Több bélyeg is üzembe helyezhető a megoldás szinte lineáris skálázásához, és egyre több bérlőt szolgál ki. Ez a megközelítés javíthatja a megoldás méretezhetőségét, lehetővé teszi a példányok több régióban való üzembe helyezését és az ügyféladatok elkülönítését.

Kontextus és probléma

Amikor alkalmazásokat üzemeltet a felhőben, fontos figyelembe venni az alkalmazás teljesítményét és megbízhatóságát. Ha a megoldás egyetlen példányát üzemelteti, előfordulhat, hogy a következő korlátozások vonatkoznak Önre:

• Méretezési korlátok. Az alkalmazás egyetlen példányának üzembe helyezése természetes skálázási korlátokat eredményezhet. Használhat például olyan szolgáltatásokat, amelyek korlátozzák a bejövő kapcsolatok, gazdagépnevek, TCP-szoftvercsatornák vagy egyéb erőforrások számát.
• Nem lineáris skálázás vagy költség. Előfordulhat, hogy a megoldás egyes összetevői nem skálázhatók lineárisan a kérések számával vagy az adatok mennyiségével. Ehelyett hirtelen csökkenhet a teljesítmény vagy nőhet a költség egy küszöbérték teljesülése után. Használhat például egy adatbázist, és felfedezheti, hogy a kapacitások (vertikális felskálázás) hozzáadásának marginális költsége tiltott lesz, és a horizontális felskálázás költséghatékonyabb stratégia.
• Az ügyfelek elkülönítése. Előfordulhat, hogy bizonyos ügyfelek adatait el kell különíteni más ügyfelek adataitól. Hasonlóképpen előfordulhat, hogy egyes ügyfelek több rendszererőforrást igényelnek a szolgáltatáshoz, mint mások, és érdemes lehet különböző infrastruktúra-csoportokba csoportosítani őket.
• Egy- és több-bérlős példányok kezelése. Előfordulhat, hogy vannak olyan nagy ügyfelek, akiknek a megoldás saját független példányára van szükségük. Előfordulhat, hogy kisebb ügyfelek készlete is van, akik megoszthatnak több-bérlős üzembe helyezést.
• Összetett üzembehelyezési követelmények. Előfordulhat, hogy a szolgáltatás frissítéseit szabályozott módon kell üzembe helyeznie, és különböző időpontokban kell üzembe helyeznie az ügyfélbázis különböző részhalmazaiban.
• Frissítés gyakorisága. Előfordulhat, hogy vannak olyan ügyfelei, akik tolerálják a rendszer gyakori frissítéseit, míg mások kockázatkerülőek lehetnek, és ritkán szeretnének frissítéseket kapni a kéréseiket ellátó rendszerről. Érdemes lehet ezeket az ügyfeleket elkülönített környezetekben üzembe helyezni.
• Földrajzi vagy geopolitikai korlátozások. Az alacsony késés vagy az adatelkülönítmények követelményeinek való megfelelés érdekében egyes ügyfeleket bizonyos régiókban helyezhet üzembe.

Ezek a korlátozások gyakran alkalmazhatók olyan független szoftvergyártókra (ISV-kre), akik szolgáltatásként (SaaS) fejlesztenek szoftvereket, amelyeket gyakran több-bérlős használatra terveztek. Ugyanezek a korlátozások azonban más forgatókönyvekre is érvényesek lehetnek.

Megoldás

A problémák elkerülése érdekében fontolja meg az erőforrások méretezési egységekbenvaló csoportosítását és a bélyegek több példányának kiépítését. Minden méretezési egység a bérlők egy részét fogja üzemeltetni és kiszolgálni. A bélyegek egymástól függetlenül működnek, és egymástól függetlenül telepíthetők és frissíthetők. Egyetlen földrajzi régió egyetlen bélyeget tartalmazhat, vagy több bélyeget is tartalmazhat, hogy lehetővé tegye a horizontális felskálázást a régión belül. A bélyegek az ügyfelek egy részét tartalmazzák.

Az üzembehelyezési bélyegek alkalmazhatók arra, hogy a megoldás az infrastruktúrát szolgáltatásként (IaaS) vagy szolgáltatásként (PaaS) használja-e, vagy mindkettő keverékét. Az IaaS-számítási feladatok általában több beavatkozást igényelnek a skálázáshoz, így a minta hasznos lehet az IaaS-alapú számítási feladatok esetében, hogy lehetővé tegye a horizontális felskálázást.

A bélyegek az üzembehelyezési gyűrűk implementálásához használhatók. Ha a különböző ügyfelek különböző gyakorisággal szeretnének szolgáltatásfrissítéseket kapni, különböző bélyegekre csoportosíthatók, és minden egyes bélyeg különböző ütemben üzembe helyezhető frissítéseket tartalmazhat.

Mivel a bélyegek egymástól függetlenül futnak, az adatok implicit módon vannak skálázva. Ezenkívül egyetlen bélyeg további horizontális skálázást is használhat, hogy belsőleg lehetővé tegye a skálázhatóságot és a rugalmasságot a bélyegen belül.

Az üzembehelyezési bélyegmintát számos Azure-szolgáltatás használja belsőleg, beleértve az App Service-t, az Azure Stacket és az Azure Storage-t.

Az üzembehelyezési bélyegek a geodéziához kapcsolódnak, de eltérnek a geodéziától. Az üzembe helyezési bélyegarchitektúrákban a rendszer több független példányát helyezi üzembe, és az ügyfelek és a felhasználók egy részhalmazát tartalmazza. A geodéziákban minden példány kiszolgálhatja a felhasználók kéréseit, de ez az architektúra gyakran összetettebb a tervezéshez és a létrehozáshoz. Megfontolhatja a két minta egy megoldáson belüli keverését is; A cikk későbbi részében ismertetett forgalomirányítási megközelítés egy ilyen hibrid forgatókönyv példája.

Telepítés

Az azonos összetevők azonos példányainak üzembe helyezésében részt vevő összetettség miatt a jó DevOps-eljárások kritikus fontosságúak a minta implementálása során a sikeresség biztosításához. Fontolja meg az infrastruktúra kódként való leírását, például a Bicep, jSON Azure Resource Manager-sablonok (ARM-sablonok), a Terraform és a szkriptek használatával. Ezzel a módszerrel biztosítható, hogy az egyes bélyegek üzembe helyezése kiszámítható és megismételhető legyen. Emellett csökkenti az emberi hibák, például a bélyegek közötti konfiguráció véletlen eltéréseinek valószínűségét.

A frissítéseket automatikusan üzembe helyezheti az összes bélyegen párhuzamosan, ebben az esetben az infrastruktúra és alkalmazások üzembe helyezésének koordinálása érdekében megfontolhatja az olyan technológiákat, mint a Bicep vagy a Resource Manager-sablonok. Másik lehetőségként dönthet úgy is, hogy először fokozatosan frissíti egyes bélyegek frissítéseit, majd fokozatosan másoknak. Fontolja meg egy kiadáskezelő eszköz, például az Azure Pipelines vagy a GitHub Actions használatát az üzembe helyezések egyes bélyegeken való vezényléséhez. További információkért lásd:

• A Bicep integrálása az Azure Pipelinessal
• JSON ARM-sablonok integrálása az Azure Pipelinessal

Alaposan gondolja át az Üzembe helyezéshez tartozó Azure-előfizetések és erőforráscsoportok topológiáját:

• Az előfizetések általában egyetlen megoldás összes erőforrását tartalmazzák, ezért általában érdemes egyetlen előfizetést használni az összes bélyeghez. Egyes Azure-szolgáltatások azonban előfizetés-szintű kvótákat írnak elő, ezért ha ezt a mintát használja a nagy mértékű felskálázás engedélyezéséhez, érdemes lehet a bélyegeket különböző előfizetések között üzembe helyezni.
• Az erőforráscsoportokat általában az azonos életciklusú összetevők üzembe helyezésére használják. Ha az összes bélyegen egyszerre szeretne frissítéseket üzembe helyezni, fontolja meg egyetlen erőforráscsoport használatát az összes bélyeg összes összetevőjének tartalmaznia, és az erőforrás-elnevezési konvenciók és címkék használatával azonosítsa az egyes bélyegekhez tartozó összetevőket. Ha azt tervezi, hogy a frissítéseket egymástól függetlenül helyezi üzembe az egyes bélyegeken, érdemes lehet az egyes bélyegeket a saját erőforráscsoportjában üzembe helyezni.

Kapacitástervezés

Terhelés- és teljesítménytesztelés használatával állapítsa meg, hogy egy adott bélyeg milyen közelítő terhelést képes elférni. A terhelési metrikák alapulhatnak azon ügyfelek/bérlők számán, amelyeket egy adott bélyeg el tud fogadni, vagy a bélyeg összetevői által kibocsátott szolgáltatások metrikái alapján. Győződjön meg arról, hogy elegendő eszköz áll rendelkezésre ahhoz, hogy egy adott bélyeg megközelítse a kapacitását, és hogy az új bélyegek gyorsan üzembe helyezhetők a keresletnek megfelelően.

Forgalom útválasztása

Az üzembehelyezési bélyeg minta jól működik, ha minden egyes bélyeget egymástól függetlenül kezelnek. Ha például a Contoso ugyanazt az API-alkalmazást több bélyegen helyezi üzembe, érdemes lehet DNS használatával átirányítani a forgalmat a megfelelő bélyegre:

• unit1.aus.myapi.contoso.com egy ausztrál régión belüli bélyegre unit1 irányítja a forgalmat.
• unit2.aus.myapi.contoso.com egy ausztrál régión belüli bélyegre unit2 irányítja a forgalmat.
• unit1.eu.myapi.contoso.com bélyegre irányítja a unit1 forgalmat egy európai régión belül.

Ezután az ügyfelek felelősek a megfelelő bélyegzőhöz való csatlakozásért.

Ha az összes forgalomhoz egyetlen bejövő pont szükséges, egy forgalomirányítási szolgáltatással feloldható egy adott kérés, ügyfél vagy bérlő bélyegzője. A forgalomirányítási szolgáltatás vagy a bélyegző megfelelő URL-címére irányítja az ügyfelet (például HTTP 302 válaszállapotkód használatával), vagy fordított proxyként működik, és a forgalmat a megfelelő bélyegzőre továbbítja anélkül, hogy az ügyfél értesülne róla.

A központosított forgalomirányítási szolgáltatás összetett összetevő lehet, különösen akkor, ha egy megoldás több régióban fut. Fontolja meg a forgalomirányítási szolgáltatás üzembe helyezését több régióban (beleértve az összes olyan régiót is, amelyben a bélyegek üzembe vannak helyezve), majd gondoskodjon arról, hogy az adattár (a bérlők leképezése a bélyegekre) szinkronizálva legyen. A forgalom-útválasztási összetevő maga is a geodéziai minta egy példánya lehet.

Az Azure API Management például üzembe helyezhető a forgalomirányítási szolgáltatás szerepkörben való működéshez. A kérések megfelelő pecsétjét úgy határozhatja meg, hogy adatokat keres egy Azure Cosmos DB-gyűjteményben , amely a bérlők és a bélyegek közötti leképezést tárolja. Az API Management ezután dinamikusan beállíthatja a háttér URL-címét a megfelelő bélyeg API-szolgáltatására.

A kérések földrajzi elosztásának és a forgalomirányítási szolgáltatás georedundanciáinak engedélyezéséhez az API Management több régióban is üzembe helyezhető, vagy az Azure Front Door a legközelebbi példányra irányíthatja a forgalmat. A Front Door egy háttérkészlettel konfigurálható, így a kérelmek a legközelebbi elérhető API Management-példányra irányíthatók. Ha az alkalmazás nem érhető el HTTP/S-n keresztül, egy régióközi Azure Load Balancerrel eloszthatja a bejövő hívásokat a regionális Azure Load Balancereknek. Az Azure Cosmos DB globális terjesztési funkciója segítségével az egyes régiók leképezési információi frissíthetők.

Ha egy forgalomirányítási szolgáltatás szerepel a megoldásban, fontolja meg, hogy átjáróként működik-e, és így képes-e átjáró-kiszervezést végezni a többi szolgáltatáshoz, például jogkivonat-ellenőrzéshez, szabályozáshoz és engedélyezéshez.

Példa forgalomirányítási architektúrára

Tekintse meg a következő példa forgalomirányítási architektúrát, amely az Azure Front Doort, az Azure API Managementet és az Azure Cosmos DB-t használja a globális forgalomirányításhoz, majd régióspecifikus bélyegek sorozatát:

Tegyük fel, hogy egy felhasználó általában New Yorkban tartózkodik. Adataikat az USA keleti régiójában, a 3. bélyegben tárolják.

Ha a felhasználó Kaliforniába utazik, majd hozzáfér a rendszerhez, a kapcsolat valószínűleg az USA 2. nyugati régióján keresztül lesz átirányítva, mert ez a legközelebb van ahhoz a helyhez, ahol földrajzilag a kérést intézik. A kérést azonban végső soron a 3. bélyeggel kell kézbesíteni, mert itt tárolják az adataikat. A forgalomirányítási rendszer biztosítja, hogy a kérés a megfelelő bélyegzőre legyen irányítva.

Problémák és megfontolandó szempontok

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

• Üzembe helyezési folyamat. Több bélyeg üzembe helyezésekor rendkívül ajánlott automatizált és teljes mértékben megismételhető üzembe helyezési folyamatokat végezni. Fontolja meg Bicep-, JSON ARM-sablonok vagy Terraform-modulok használatát a bélyegek deklaratív definiálásához és a definíciók konzisztensségéhez.
• Keresztbélyegzési műveletek. Ha a megoldás önállóan van üzembe helyezve több bélyegen, az olyan kérdések, mint a "hány ügyfél van az összes bélyegünkön?" kérdés összetettebbé válhat a válaszhoz. Előfordulhat, hogy a lekérdezéseket minden egyes bélyegen és az eredmények összesítésével kell végrehajtani. Másik lehetőségként fontolja meg, hogy az összes bélyeg közzétegye az adatokat egy központosított adattárházban konszolidált jelentéskészítés céljából.
• Vertikális felskálázási szabályzatok meghatározása. A bélyegek véges kapacitással rendelkeznek, amely proxymetrika használatával határozható meg, például a bélyegen üzembe helyezhető bérlők száma alapján. Fontos, hogy minden egyes bélyeghez figyelje a rendelkezésre álló kapacitást és a felhasznált kapacitást, és proaktív módon helyezzen üzembe további bélyegeket, hogy az új bérlők irányíthatók legyenek hozzájuk.
• A bélyegek minimális száma. Az Üzembehelyezési bélyegző minta használata esetén ajánlott a megoldás legalább két bélyegének üzembe helyezése. Ha csak egyetlen bélyeget helyez üzembe, könnyen előfordulhat, hogy a kódban vagy konfigurációban véletlenül olyan szigorú kódot feltételez, amely a vertikális felskálázáskor nem fog érvényesülni.
• Költségek. Az üzembehelyezési bélyeg mintája magában foglalja az infrastruktúra-összetevő több példányának üzembe helyezését, ami valószínűleg jelentős költségnövekedést fog eredményezni a megoldás üzemeltetési költségeiben.
• Mozgás a bélyegek között. Minden egyes bélyeget egymástól függetlenül helyeznek üzembe és üzemeltetnek, így a bérlők áthelyezése a bélyegek között nehézkes lehet. Az alkalmazásnak egyéni logikára van szüksége ahhoz, hogy egy adott ügyfél adatait egy másik bélyegre továbbítja, majd eltávolítsa a bérlő adatait az eredeti bélyegről. Ehhez a folyamathoz szükség lehet egy háttérsíkra a bélyegek közötti kommunikációhoz, ami tovább növeli a teljes megoldás összetettségét.
• Forgalomirányítás. A cikk korábbi részében leírtaknak megfelelően a forgalom átirányítása egy adott kérés megfelelő bélyegéhez további összetevőt igényelhet a bérlők bélyegekké történő feloldásához. Előfordulhat, hogy ezt az összetevőt magas rendelkezésre állásúvá kell tenni.
• Megosztott összetevők. Előfordulhat, hogy vannak olyan összetevők, amelyek megoszthatók a bélyegek között. Ha például minden bérlőhöz rendelkezik megosztott egyoldalas alkalmazással, érdemes lehet ezt egy régióban üzembe helyezni, és az Azure CDN használatával globálisan replikálni.

Mikor érdemes ezt a mintát használni?

Ez a minta akkor hasznos, ha:

• A méretezhetőség természetes korlátai. Ha például egyes összetevők nem vagy nem méretezhetők túl egy bizonyos számú ügyfélen vagy kérésen, fontolja meg a skálázást a bélyegek használatával.
• Követelmény bizonyos bérlők és mások elkülönítése között. Ha olyan ügyfelekkel rendelkezik, akik biztonsági okokból nem helyezhetők üzembe több-bérlős bélyegbe más ügyfelekkel, akkor azok a saját elkülönített bélyegükre helyezhetők üzembe.
• Szükség van néhány bérlőre a megoldás különböző verzióiban egyszerre.
• Többrégiós alkalmazások, ahol az egyes bérlők adatait és forgalmát egy adott régióba kell irányítani.
• A rugalmasság elérésének vágya a kimaradások során. Mivel a bélyegek egymástól függetlenek, ha egy kimaradás egyetlen bélyeget érint, akkor a többi bélyegre telepített bérlőket nem érinti. Ez az elkülönítés segít az incidensek vagy kimaradások "robbanási sugarának" megfékezésében.

Ez a minta nem alkalmas a következőkre:

• Egyszerű megoldások, amelyeknek nem kell nagy mértékben skálázniuk.
• Olyan rendszerek, amelyek egyszerűen méretezhetők ki vagy felskálázhatók egyetlen példányon belül, például az alkalmazásréteg méretének növelésével vagy az adatbázisok fenntartott kapacitásának és a tárolási szintnek a növelésével.
• Azok a megoldások, amelyekben az adatokat az összes üzembe helyezett példányon replikálni kell. Vegye figyelembe a forgatókönyv geodéziai mintáját .
• Olyan megoldások, amelyekben csak bizonyos összetevőket kell skálázni, másokat azonban nem. Fontolja meg például, hogy a megoldás skálázható-e úgy, hogy az adattárat skálázza ahelyett, hogy az összes megoldásösszetevő új példányát üzembe helyezné.
• Kizárólag statikus tartalomból álló megoldások, például egy előtérbeli JavaScript-alkalmazás. Fontolja meg az ilyen tartalmak tárfiókban való tárolását és az Azure CDN használatát.

Számítási feladatok tervezése

Az tervezőknek értékelniük kell, hogyan használható az Üzembehelyezési bélyegek minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Támogató technológiák

• Infrastruktúra kódként. Ilyenek például a Bicep, a Resource Manager-sablonok, az Azure CLI, a Terraform, a PowerShell, a Bash.
• Azure Front Door, amely a forgalmat egy adott bélyeghez vagy egy forgalomirányítási szolgáltatáshoz irányíthatja.

Példa

Az alábbi példa egy egyszerű PaaS-megoldás több bélyegét helyezi üzembe, mindegyik bélyegben egy app service és egy SQL Database található. Bár a bélyegek bármely olyan régióban konfigurálhatók, amely támogatja a sablonban üzembe helyezett szolgáltatásokat, illusztrációs célokra ez a sablon két bélyeget helyez üzembe az USA 2. nyugati régiójában és egy további bélyeget a nyugat-európai régióban. Egy bélyegen belül az app service megkapja a saját nyilvános DNS-állomásnevét, és az összes többi bélyegtől függetlenül fogadhat kapcsolatokat.

A megoldás üzembe helyezéséhez kattintson az alábbi hivatkozásra.

Példa forgalomirányítási megközelítésre

Az alábbi példa egy forgalomirányítási megoldás implementációját helyezi üzembe, amely egy hipotetikus API-alkalmazás üzembehelyezési bélyegzőinek készletével használható. A bejövő kérések földrajzi elosztásának lehetővé tétele érdekében a Front Door az API Management több példányával együtt van üzembe helyezve a fogyasztási szinten. Minden API Management-példány beolvassa a bérlőazonosítót a kérelem URL-címéből, majd megkeresi a kérelem megfelelő pecsétét egy földrajzilag elosztott Azure Cosmos DB-adattárból. A kérelmet ezután a megfelelő háttérbélyegre továbbítja.

A megoldás üzembe helyezéséhez kattintson az alábbi hivatkozásra.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• John Downs | Fő programmenedzser

Egyéb közreműködők:

• Daniel Larsen | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
• Angel Lopez | Vezető szoftvermérnök, Azure-minták és gyakorlatok
• Paolo Salvatori | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
• Arsen Vladimirskiy | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Kapcsolódó erőforrások

• A horizontális skálázás egy másik, egyszerűbb megközelítésként használható az adatszint horizontális felskálázásához. A bélyegek implicit módon megszilárdulnak az adataikon, de a horizontális skálázáshoz nincs szükség üzembehelyezési bélyegre. További információkért lásd a horizontális particionálási mintát.
• Forgalmi útválasztási szolgáltatás üzembe helyezése esetén az átjáró-útválasztási és átjáró-kiszervezési minták együttesen használhatók az összetevő legjobb kihasználása érdekében.