Az alkalmazásplatform szempontjai a kritikus fontosságú számítási feladatokhoz

Minden kritikus fontosságú architektúra kulcsfontosságú tervezési területe az alkalmazásplatform. A platform azokat az infrastruktúra-összetevőket és Azure-szolgáltatásokat jelenti, amelyeket ki kell építenünk az alkalmazás támogatásához. Íme néhány átfogó javaslat.

• Tervezés rétegekben. Válassza ki a megfelelő szolgáltatáskészletet, azok konfigurációját és az alkalmazásspecifikus függőségeket. Ez a rétegzett megközelítés segít a logikai és fizikai szegmentálás létrehozásában. A szerepkörök és függvények meghatározásában, valamint a megfelelő jogosultságok és üzembehelyezési stratégiák hozzárendelésében hasznos. Ez a megközelítés végső soron növeli a rendszer megbízhatóságát.

• A kritikus fontosságú alkalmazásoknak rendkívül megbízhatónak és ellenállónak kell lenniük az adatközpontokkal és a regionális hibákkal szemben. Az aktív-aktív konfigurációban a területi és regionális redundancia kiépítése a fő stratégia. Amikor az azure-szolgáltatásokat választja az alkalmazás platformjához, fontolja meg a rendelkezésre állási zónák támogatását, valamint az üzembe helyezési és működési mintákat, hogy több Azure-régiót használjon.

• Méretezési egységeken alapuló architektúra használata a megnövekedett terhelés kezeléséhez. A skálázási egységek lehetővé teszik az erőforrások logikai csoportosítását, és egy egység skálázható az architektúra többi egységétől vagy szolgáltatásától függetlenül. A kapacitásmodell és a várható teljesítmény használatával határozza meg az egyes egységek határait, számát és alapszintű skáláját.

Ebben az architektúrában az alkalmazásplatform globális, üzembe helyezési bélyegből és regionális erőforrásokból áll. A regionális erőforrások üzembehelyezési bélyegző részeként vannak kiépítve. Minden egyes bélyeg egy skálázási egységnek felel meg, és ha nem megfelelő állapotúvá válik, teljes mértékben lecserélhető.

Az egyes rétegek erőforrásai különböző jellemzőkkel rendelkeznek. További információ: Egy tipikus kritikus fontosságú számítási feladat architektúrájának mintája.

Jellemzők	Considerations
Életre	Mi az erőforrás várható élettartama a megoldás többi erőforrásához képest? Az erőforrásnak ki kell múlnia vagy meg kell osztania az élettartamot a teljes rendszerrel vagy régióval, vagy ideiglenesnek kell lennie?
State	Milyen hatással lesz az ebben a rétegben megmaradó állapot a megbízhatóságra vagy a kezelhetőségre?
Elérés	Szükség van az erőforrás globális elosztására? Kommunikálhat az erőforrás más erőforrásokkal globálisan vagy régiókban?
Függőségek	Mi a függőség más erőforrásoktól globálisan vagy más régiókban?
Méretezési korlátok	Mi az adott erőforrás várható átviteli sebessége ezen a rétegen? Mennyi skálát biztosít az erőforrás az adott igénynek megfelelően?
Rendelkezésre állás/vészhelyreállítás	Milyen hatással van a rendelkezésre állásra vagy a katasztrófákra ezen a rétegen? Rendszerszintű kimaradást okoz, vagy csak honosított kapacitással vagy rendelkezésre állással kapcsolatos problémát okoz?

Globális erőforrások

Az architektúra egyes erőforrásait a régiókban üzembe helyezett erőforrások osztják meg. Ebben az architektúrában a forgalom több régió közötti elosztására, a teljes alkalmazás állandó állapotának tárolására és a globális statikus adatok gyorsítótárazására szolgálnak.

Jellemzők	Rétegekkel kapcsolatos szempontok
Életre	Ezek az erőforrások várhatóan hosszú ideig élnek. Élettartamuk a rendszer élettartamát vagy hosszabb időtartamát öleli fel. Az erőforrásokat gyakran helyszíni adatokkal és vezérlősík-frissítésekkel kezelik, feltéve, hogy támogatják a leállási idő nélküli frissítési műveleteket.
State	Mivel ezek az erőforrások legalább a rendszer élettartama alatt léteznek, ez a réteg gyakran felelős a globális, georeplikált állapot tárolásáért.
Elérés	Az erőforrásokat globálisan el kell osztani. Javasoljuk, hogy ezek az erőforrások kis késéssel és a kívánt konzisztenciával kommunikáljanak a regionális vagy más erőforrásokkal.
Függőségek	Az erőforrásoknak el kell kerülniük a regionális erőforrásoktól való függőségeket, mert azok elérhetetlensége globális meghibásodást okozhat. Az egyetlen tárolóban tárolt tanúsítványok vagy titkos kódok például globális hatással lehetnek, ha regionális hiba történik a tároló helyének helyében.
Méretezési korlátok	Ezek az erőforrások gyakran egypéldányos példányok a rendszerben, ezért olyan skálázhatónak kell lenniük, hogy képesek legyenek kezelni a rendszer egészének átviteli sebességét.
Rendelkezésre állás/vészhelyreállítás	Mivel a regionális és a bélyeg típusú erőforrások használhatják a globális erőforrásokat, vagy azok előtérbe kerülnek, kritikus fontosságú, hogy a globális erőforrások magas rendelkezésre állással és vészhelyreállítással legyenek konfigurálva a teljes rendszer állapotához.

Ebben az architektúrában a globális réteg erőforrásai az Azure Front Door, az Azure Cosmos DB, az Azure Container Registry és az Azure Log Analytics, amelyek naplókat és metrikákat tárolnak más globális rétegbeli erőforrásokból.

Ebben a kialakításban más alapvető erőforrások is találhatók, például a Microsoft Entra ID és az Azure DNS. Ezeket a képeken kihagyták a rövidség kedvéért.

Globális terheléselosztó

Az Azure Front Door az egyetlen belépési pont a felhasználói forgalom számára. Az Azure garantálja, hogy az Azure Front Door az idő 99,99%-ában hiba nélkül kézbesíti a kért tartalmat. További részletekért tekintse meg a Front Door szolgáltatás korlátait. Ha a Front Door elérhetetlenné válik, a végfelhasználó azt fogja látni, hogy a rendszer leállt.

A Front Door-példány forgalmat küld a konfigurált háttérszolgáltatásoknak, például az API-t üzemeltető számítási fürtnek és az előtérbeli SPA-nak. A Front Door háttérbeli helytelen konfigurációi kimaradásokhoz vezethetnek. A helytelen konfigurációk miatti kimaradások elkerülése érdekében alaposan tesztelje a Front Door beállításait.

Egy másik gyakori hiba a helytelenül konfigurált vagy hiányzó TLS-tanúsítványokból eredhet, ami megakadályozhatja, hogy a felhasználók az előtérben vagy a Front Doorban kommunikáljanak a háttérrendszerrel. A kockázatcsökkentés manuális beavatkozást igényelhet. Előfordulhat például, hogy visszaállítja az előző konfigurációt, és lehetőség szerint újra kibocsátja a tanúsítványt. Függetlenül attól, hogy a módosítások érvénybe lépnek, várhatóan nem érhető el. A Front Door által kínált felügyelt tanúsítványok használata ajánlott a működési terhelés csökkentése érdekében, például a lejárat kezelése érdekében.

A Front Door számos további funkciót kínál a globális forgalomirányítás mellett. Fontos képesség a webalkalmazási tűzfal (WAF), mivel a Front Door képes megvizsgálni az áthaladó forgalmat. Ha megelőzési módban van konfigurálva, az blokkolni fogja a gyanús forgalmat, mielőtt bármelyik háttérrendszert elérnénk.

A Front Door képességeivel kapcsolatos információkért tekintse meg az Azure Front Doorra vonatkozó gyakori kérdéseket.

A forgalom globális elosztásával kapcsolatos további szempontokért tekintse meg a Misson-kritikus útmutatást a Jól kigondolt keretrendszer: Globális útválasztás című témakörben.

Container Registry

Az Azure Container Registry az Open Container Initiative (OCI) összetevők, különösen a helm-diagramok és a tárolólemezképek tárolására szolgál. Nem vesz részt a kérelemfolyamatban, és csak időszakosan érhető el. A tárolóregisztrációs adatbázisnak léteznie kell a bélyegerőforrások üzembe helyezése előtt, és nem szabad függőséggel rendelkeznie a regionális réteg erőforrásaitól.

Engedélyezze a zónaredundanciát és a regisztrációs adatbázisok georeplikálását, hogy a rendszerképekhez való futásidejű hozzáférés gyors és rugalmas legyen a hibákhoz. Elérhetetlenség esetén a példány feladatátvételt végezhet a replikarégiókon, és a kérések automatikusan át lesznek irányítva egy másik régióba. Átmeneti hibákra számíthat a rendszerképek lekérése során a feladatátvétel befejezéséig.

Hibák akkor is előfordulhatnak, ha a rendszerképeket véletlenül törlik, az új számítási csomópontok nem tudják lekérni a rendszerképeket, de a meglévő csomópontok továbbra is használhatnak gyorsítótárazott lemezképeket. A vészhelyreállítás elsődleges stratégiája az újratelepítés. A tárolóregisztrációs adatbázisban lévő összetevők újragenerálhatók folyamatokból. A tárolóregisztrációs adatbázisnak képesnek kell lennie ellenállni számos egyidejű kapcsolatnak az összes üzemelő példány támogatásához.

Javasoljuk, hogy a prémium termékváltozatot használja a georeplikálás engedélyezéséhez. A zónaredundancia funkció rugalmasságot és magas rendelkezésre állást biztosít egy adott régión belül. Regionális kimaradás esetén a más régiókban lévő replikák továbbra is elérhetők az adatsík-műveletekhez. Ezzel a termékváltozattal privát végpontokon keresztül korlátozhatja a képekhez való hozzáférést.

További részletekért tekintse meg az Azure Container Registry ajánlott eljárásait.

Database

Javasoljuk, hogy minden állapotot globálisan tároljon egy, a regionális bélyegektől elkülönített adatbázisban. Redundancia kiépítése az adatbázis régiók közötti üzembe helyezésével. A kritikus fontosságú számítási feladatok esetében az adatok régiók közötti szinkronizálásának kell elsődleges szempontnak lennie. Hiba esetén az adatbázisba irányuló írási kérelmeknek továbbra is működőképesnek kell lenniük.

Az aktív-aktív konfigurációban az adatreplikálás erősen ajánlott. Az alkalmazásnak azonnal csatlakoznia kell egy másik régióhoz. Minden példánynak képesnek kell lennie az olvasási és írási kérelmek kezelésére.

További információ: Adatplatform a kritikus fontosságú számítási feladatokhoz.

Globális monitorozás

Az Azure Log Analytics az összes globális erőforrás diagnosztikai naplóinak tárolására szolgál. Javasoljuk, hogy korlátozza a napi tárterületkvótát, különösen a terhelésteszteléshez használt környezetekben. Emellett állítsa be a megőrzési szabályzatot is. Ezek a korlátozások megakadályozzák az olyan túlköltekezéseket, amelyek olyan adatok tárolásával merülnek fel, amelyekre nincs szükség a korláton túl.

Alapszolgáltatásokkal kapcsolatos szempontok

A rendszer valószínűleg más kritikus platformszolgáltatásokat is használ, amelyek a teljes rendszert veszélyeztethetik, például az Azure DNS-t és a Microsoft Entra-azonosítót. Az Azure DNS 100%-os rendelkezésre állási SLA-t biztosít az érvényes DNS-kérésekhez. A Microsoft Entra legalább 99,99%-os üzemidőt garantál. Ennek ellenére tisztában kell lennie a hiba következményeivel.

Az alapszolgáltatásoktól való szigorú függőség elkerülhetetlen, mert sok Azure-szolgáltatás függ tőlük. Ha nem érhetők el, fennakadásra számíthat a rendszerben. Ilyenek például a következők:

• Az Azure Front Door az Azure DNS használatával éri el a háttérrendszert és más globális szolgáltatásokat.
• Az Azure Container Registry az Azure DNS használatával feladatátvételi kérelmeket küld egy másik régióba.

Mindkét esetben mindkét Azure-szolgáltatásra hatással lesz, ha az Azure DNS nem érhető el. A Front Doortól érkező felhasználói kérések névfeloldása sikertelen lesz; A Docker-rendszerképek nem lesznek lekértek a beállításjegyzékből. A külső DNS-szolgáltatás biztonsági mentésként való használata nem csökkenti a kockázatot, mivel számos Azure-szolgáltatás nem engedélyezi az ilyen konfigurációt, és belső DNS-re támaszkodik. Teljes kimaradás várható.

Hasonlóképpen a Microsoft Entra ID-t is használják a vezérlősík-műveletekhez, például új AKS-csomópontok létrehozásához, lemezképek lekéréséhez a Container Registryből, vagy a Key Vault eléréséhez podindításkor. Ha a Microsoft Entra-azonosító nem érhető el, a meglévő összetevőket nem szabad érinteni, de az általános teljesítmény csökkenhet. Az új podok vagy AKS-csomópontok nem lesznek működőképesek. Így ha ez idő alatt vertikális felskálázási műveletekre van szükség, csökkenhet a felhasználói élmény.

Regionális üzembehelyezési bélyegző erőforrásai

Ebben az architektúrában az üzembe helyezési bélyeg üzembe helyezi a számítási feladatot, és kiépít olyan erőforrásokat, amelyek részt vesznek az üzleti tranzakciók végrehajtásában. A bélyegek általában egy Azure-régióban üzemelő példánynak felelnek meg. Bár egy régió több bélyeggel is rendelkezhet.

Jellemzők	Considerations
Életre	Az erőforrások várhatóan rövid élettartammal (rövid élettartammal) rendelkeznek azzal a szándékkal, hogy dinamikusan hozzáadhatók és eltávolíthatók, miközben a bélyegen kívüli regionális erőforrások továbbra is megmaradnak. A rövid élettartamra azért van szükség, hogy nagyobb rugalmasságot, skálázást és a felhasználók közelségét biztosítsa.
State	Mivel a bélyegek rövid élettartamúak, és bármikor megsemmisíthetők, a bélyegnek állapot nélkülinek kell lennie, amennyire csak lehetséges.
Elérés	Képes kommunikálni a regionális és globális erőforrásokkal. A más régiókkal vagy más bélyegekkel való kommunikációt azonban kerülni kell. Ebben az architektúrában nincs szükség arra, hogy ezeket az erőforrásokat globálisan elosztják.
Függőségek	A bélyegerőforrásoknak függetlennek kell lenniük. Vagyis más régiókban nem szabad más bélyegekre vagy összetevőkre támaszkodniuk. Ezek várhatóan regionális és globális függőségekkel rendelkeznek. A fő megosztott összetevő az adatbázisréteg és a tárolóregisztrációs adatbázis. Ez az összetevő futásidőben szinkronizálást igényel.
Méretezési korlátok	Az átviteli sebesség teszteléssel jön létre. A teljes bélyeg átviteli sebessége a legkevésbé teljesítő erőforrásra korlátozódik. A bélyegek átviteli sebességének figyelembe kell vennie a becsült magas szintű keresletet és a feladatátvételt, mivel a régióban egy másik bélyeg elérhetetlenné válik.
Rendelkezésre állás/vészhelyreállítás	A bélyegek ideiglenes jellege miatt a vészhelyreállítás a bélyeg ismételt üzembe helyezésével történik. Ha az erőforrások állapota nem megfelelő, a bélyeg egésze megsemmisíthető és újra üzembe helyezhető.

Ebben az architektúrában a bélyegerőforrások az Azure Kubernetes Service, az Azure Event Hubs, az Azure Key Vault és az Azure Blob Storage.

Skálázási egység

A bélyegek skálázási egységnek (SU) is tekinthetők. Az adott bélyegen belüli összes összetevő és szolgáltatás konfigurálva van és tesztelve van, hogy egy adott tartományban kiszolgálja a kéréseket. Íme egy példa a megvalósításban használt skálázási egységre.

Minden méretezési egység üzembe van helyezve egy Azure-régióban, ezért elsősorban az adott területről érkező forgalmat kezeli (bár szükség esetén átveheti a forgalmat más régiókból). Ez a földrajzi eloszlás valószínűleg olyan terhelési mintákat és munkaidőt eredményez, amelyek régiónként eltérőek lehetnek, és így minden su úgy van kialakítva, hogy tétlen állapotban fel- és leskálázható legyen.

Egy új bélyeget skálázhat. Egy bélyegen belül az egyes erőforrások skálázási egységek is lehetnek.

Íme néhány skálázási és rendelkezésre állási szempont az Azure-szolgáltatások egységben való kiválasztásakor:

• Kapacitáskapcsolatok kiértékelése egy skálázási egység összes erőforrása között. Például 100 bejövő kérés kezeléséhez 5 bejövő vezérlő podra és 3 katalógusszolgáltatás-podra és 1000 kérelemegységre lenne szükség az Azure Cosmos DB-ben. A bejövő podok automatikus skálázása során tehát a katalógusszolgáltatás és az Azure Cosmos DB RU-k skálázására kell számítani ezen tartományok alapján.

• Töltse be a szolgáltatásokat a kérelmek kézbesítési tartományának meghatározásához. Az eredmények alapján konfigurálja a minimális és maximális példányokat és a célmetrikát. A cél elérésekor dönthet úgy, hogy automatizálja a teljes egység skálázását.

• Tekintse át az Azure-előfizetések méretezési korlátait és kvótáit az üzleti követelmények által meghatározott kapacitás- és költségmodell támogatásához. Ellenőrizze az egyes szolgáltatások korlátait is. Mivel az egységek általában együtt vannak üzembe helyezve, vegye figyelembe a kanári-telepítésekhez szükséges előfizetési erőforráskorlátokat. További információkért tekintse meg az Azure szolgáltatási korlátait.

• Válassza ki a rendelkezésre állási zónákat támogató szolgáltatásokat a redundancia létrehozásához. Ez korlátozhatja a technológiai lehetőségeket. További részletekért tekintse meg a rendelkezésre állási zónákat .

Az egység méretével és az erőforrások kombinációjával kapcsolatos egyéb szempontokért tekintse meg a Misson-kritikus útmutatást a jól felépített keretrendszer: skálázási egység architektúrájában.

Számítási fürt

A számítási feladat tárolóba helyezése érdekében minden egyes bélyegnek futtatnia kell egy számítási fürtöt. Ebben az architektúrában az Azure Kubernetes Service (AKS) azért van kiválasztva, mert a Kubernetes a modern, tárolóalapú alkalmazások legnépszerűbb számítási platformja.

Az AKS-fürt élettartama a bélyegző rövid élettartamához van kötve. A fürt állapot nélküli , és nem rendelkezik állandó kötetekkel. Rövid élettartamú operációsrendszer-lemezeket használ felügyelt lemezek helyett, mert nem várható, hogy alkalmazás- vagy rendszerszintű karbantartást kapjanak.

A megbízhatóság növelése érdekében a fürt úgy van konfigurálva, hogy az adott régió mindhárom rendelkezésre állási zónát használja. Ez lehetővé teszi, hogy a fürt olyan AKS Üzemidő SLA-t használjon, amely garantálja az AKS vezérlősík 99,95%-os SLA-rendelkezésre állását.

Más tényezők, például a méretezési korlátok, a számítási kapacitás és az előfizetési kvóta szintén hatással lehetnek a megbízhatóságra. Ha nincs elegendő kapacitás vagy korlát, a vertikális felskálázás és a vertikális felskálázási műveletek sikertelenek lesznek, de a meglévő számítás várhatóan működni fog.

A fürt automatikus skálázása lehetővé teszi, hogy a csomópontkészletek szükség esetén automatikusan felskálázhatók legyenek, ami javítja a megbízhatóságot. Ha több csomópontkészletet használ, az összes csomópontkészletet automatikusan skáláznia kell.

A pod szintjén a Vízszintes pod automatikus skálázása (HPA) a podokat a konfigurált PROCESSZOR-, memória- vagy egyéni metrikák alapján skálázza. Töltse be a számítási feladat összetevőit az automatikus skálázási és HPA-értékek alapkonfigurációjának meghatározásához.

A fürt automatikus csomópontrendszerkép-frissítésekhez is konfigurálva van, és a frissítések során megfelelően méretezhető. Ez a skálázás nulla állásidőt tesz lehetővé a frissítések végrehajtása közben. Ha az egyik bélyegen lévő fürt sikertelen a frissítés során, a többi bélyegben lévő többi fürtöt nem szabad érinteni, de a különböző bélyegek közötti frissítéseknek különböző időpontokban kell történnie a rendelkezésre állás fenntartása érdekében. Emellett a fürtfrissítések automatikusan átgördültek a csomópontokon, hogy ne legyenek egyszerre elérhetetlenek.

Egyes összetevők, például a cert-manager és az ingress-nginx tárolólemezképeket igényelnek külső tárolóregisztrációs adatbázisokból. Ha ezek az adattárak vagy képek nem érhetők el, előfordulhat, hogy az új csomópontok új példányai (ahol a rendszerkép nem gyorsítótárazva van) nem indulhatnak el. Ez a kockázat csökkenthető, ha importálja ezeket a lemezképeket a környezet Azure Container Registry-adatbázisba.

A megfigyelhetőség kritikus fontosságú ebben az architektúrában, mert a bélyegek rövid élettartamúak. A diagnosztikai beállítások úgy vannak konfigurálva, hogy az összes napló- és metrikaadatokat egy regionális Log Analytics-munkaterületen tárolják. Az AKS-tároló Elemzések is engedélyezve van egy fürtön belüli OMS-ügynökön keresztül. Ez az ügynök lehetővé teszi, hogy a fürt monitorozási adatokat küldjön a Log Analytics-munkaterületre.

A számítási fürtre vonatkozó további szempontokért tekintse meg a Misson-kritikus útmutatást a jól kiépített keretrendszerben: Container Orchestration és Kubernetes.

Key Vault

Az Azure Key Vault olyan globális titkos kulcsok tárolására szolgál, mint például kapcsolati sztring az adatbázisba, és titkos kulcsokat bélyegz, például az Event Hubs kapcsolati sztring.

Ez az architektúra egy Titkos kulcstár CSI-illesztőprogramot használ a számítási fürtben, hogy titkos kulcsokat szerezzen be a Key Vaultból. Titkos kódokra van szükség az új podok ívásakor. Ha a Key Vault nem érhető el, előfordulhat, hogy az új podok nem indulnak el. Ennek eredményeképpen megszakadhat a rendszer; a vertikális felskálázási műveletek befolyásolhatók, a frissítések meghiúsulhatnak, az új üzembe helyezéseket nem lehet végrehajtani.

A Key Vault korlátozza a műveletek számát. A titkos kódok automatikus frissítése miatt a korlát akkor érhető el, ha sok pod van. A helyzet elkerülése érdekében csökkentheti a frissítések gyakoriságát.

A titkos kódok kezelésével kapcsolatos további szempontokért tekintse meg a Misson-kritikus útmutatást a jól kiépített keretrendszerben: Az adatintegritás védelme című témakörben.

Event Hubs

A bélyeg egyetlen állapotalapú szolgáltatása az üzenetközvetítő, az Azure Event Hubs, amely rövid ideig tárolja a kéréseket. A közvetítő a pufferelés és a megbízható üzenetküldés szükségességét szolgálja. A feldolgozott kérések megmaradnak a globális adatbázisban.

Ebben az architektúrában a standard termékváltozatot használja a rendszer, és a zónaredundancia engedélyezve van a magas rendelkezésre álláshoz.

Az Event Hubs állapotát a számítási fürtön futó HealthService-összetevő ellenőrzi. Rendszeres ellenőrzéseket végez a különböző erőforrásokon. Ez hasznos a nem megfelelő állapotok észleléséhez. Ha például az üzenetek nem küldhetők el az eseményközpontba, a bélyeg bármilyen írási művelethez használhatatlanná válna. A HealthService-nek automatikusan észlelnie kell ezt a feltételt, és jelentenie kell a Front Doornak a nem megfelelő állapotot, amely a bélyeget kivenné a forgatásból.

A méretezhetőség érdekében ajánlott engedélyezni az automatikus felfújást.

További információ: Üzenetkezelési szolgáltatások a kritikus fontosságú számítási feladatokhoz.

Az üzenetkezeléssel kapcsolatos további szempontokért tekintse meg a Misson-kritikus útmutatást a jól kiépített keretrendszerben: Aszinkron üzenetkezelés.

Storage fiókok

Ebben az architektúrában két tárfiók van kiépítve. Mindkét fiók zónaredundáns módban (ZRS) van üzembe helyezve.

Az Event Hubs-ellenőrzőpontokhoz egy fiók használható. Ha ez a fiók nem válaszol, a bélyeg nem fogja tudni feldolgozni az Event Hubs üzeneteit, és akár a bélyeg más szolgáltatásaira is hatással lehet. Ezt a feltételt rendszeres időközönként ellenőrzi a HealthService, amely a számítási fürtben futó alkalmazásösszetevők egyike.

A másik a felhasználói felület egyoldalas alkalmazásának üzemeltetésére szolgál. Ha a statikus webhely kiszolgálása problémákat tapasztal, a Front Door észleli a problémát, és nem küld forgalmat ebbe a tárfiókba. Ez idő alatt a Front Door gyorsítótárazott tartalmat használhat.

A helyreállítással kapcsolatos további információkért lásd : Vészhelyreállítás és tárfiók feladatátvétele.

Regionális erőforrások

Egy rendszer rendelkezhet olyan erőforrásokkal, amelyek a régióban vannak üzembe helyezve, de túllépik a bélyegerőforrásokat. Ebben az architektúrában a bélyegerőforrások megfigyelhetőségi adatai regionális adattárakban vannak tárolva.

Jellemzők	Szempont
Életre	Az erőforrások megosztják a régió élettartamát, és a bélyegerőforrásokat élőben is megosztják.
State	A régióban tárolt állapot nem élhet a régió élettartamán túl. Ha az állapotot régiók között kell megosztani, fontolja meg egy globális adattár használatát.
Elérés	Az erőforrásokat nem kell globálisan elosztani. A más régiókkal való közvetlen kommunikációt minden áron el kell kerülni.
Függőségek	Az erőforrások függhetnek a globális erőforrásoktól, de a bélyegerőforrásoktól nem, mert a bélyegek rövid élettartamúak.
Méretezési korlátok	A régióban lévő összes bélyeg kombinálásával meghatározhatja a regionális erőforrások skálázási korlátját.

Bélyegerőforrások adatainak monitorozása

A monitorozási erőforrások üzembe helyezése tipikus példa a regionális erőforrásokra. Ebben az architektúrában minden régióhoz külön Log Analytics-munkaterület van konfigurálva, amely a bélyegerőforrásokból kibocsátott összes napló- és metrikaadat tárolására van konfigurálva. Mivel a regionális erőforrások túllépik a bélyegerőforrásokat, az adatok a bélyeg törlésekor is elérhetők.

Az Azure Log Analytics és Azure-alkalmazás Elemzések a naplók és metrikák platformról való tárolására szolgálnak. Javasoljuk, hogy korlátozza a napi tárterületkvótát, különösen a terhelésteszteléshez használt környezetekben. Emellett állítsa be az adatmegőrzési szabályzatot az összes adat tárolására. Ezek a korlátozások megakadályozzák az olyan túlköltekezéseket, amelyek olyan adatok tárolásával merülnek fel, amelyekre nincs szükség a korláton túl.

Hasonlóképpen, az Alkalmazás Elemzések is regionális erőforrásként van üzembe helyezve az összes alkalmazásmonitorozási adat gyűjtéséhez.

A monitorozással kapcsolatos tervezési javaslatokért tekintse meg a Misson-kritikus útmutatást a Jól megtervezett keretrendszer: Állapotmodellezés című témakörben.

Következő lépések

A referencia-implementáció üzembe helyezése az architektúra erőforrásainak és konfigurációjának teljes körű megismeréséhez.

Megvalósítás: Kritikus fontosságú online