Ezt a böngészőt már nem támogatjuk.
Frissítsen a Microsoft Edge-re, hogy kihasználhassa a legújabb funkciókat, a biztonsági frissítéseket és a technikai támogatást.
Ez a cikk egy kulcsfontosságú mintát mutat be az Azure-beli kritikus fontosságú architektúrákhoz. Alkalmazza ezt a mintát a tervezési folyamat megkezdésekor, majd válassza ki az üzleti igényeinek leginkább megfelelő összetevőket. A cikk egy északi star tervezési megközelítést javasol, és más példákat is tartalmaz a gyakori technológiai összetevőkkel.
Javasoljuk, hogy értékelje ki a legfontosabb tervezési területeket, határozza meg a mögöttes összetevőket használó kritikus felhasználói és rendszerfolyamatokat, és dolgozzon ki egy Azure-erőforrásokat és azok konfigurációját tartalmazó mátrixot, és tartsa szem előtt az alábbi jellemzőket.
| Jellemző | Megfontolandó szempontok |
|---|---|
| Életre | Mi az erőforrás várható élettartama a megoldás más erőforrásaihoz képest? Az erőforrásnak ki kell-e elégítenie vagy meg kell osztania az élettartamot a teljes rendszerrel vagy régióval, vagy ideiglenesnek kell lennie? |
| Állapot | Milyen hatással lesz az ebben a rétegben megőrzött á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, globálisan vagy az adott régióban található erőforrásokkal? |
| Függőségek | Mik a más erőforrásoktól való függőségek? |
| Skálázási korlátok | Mi az erőforrás várt átviteli sebessége? Mekkora skálázást 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 egy katasztrófa ezen a rétegen? Rendszerszintű kimaradást okoz, vagy csak honosított kapacitással vagy rendelkezésre állással kapcsolatos problémát okoz? |
Fontos
Ez a cikk az Azure Well-Architected kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a kritikus fontosságú számítási feladatokkal?
Bizonyos erőforrásokat globálisan osztanak meg az egyes régiókban üzembe helyezett erőforrások. Ilyenek például az erőforrások, amelyek a forgalom több régió közötti elosztására, a teljes alkalmazás állandó állapotának tárolására és az erőforrások figyelésére szolgálnak.
| Jellemző | Megfontolandó szempontok |
|---|---|
| Életre | Ezek az erőforrások várhatóan hosszú élettartamúak (nem rövid élettartamúak). Élettartamuk a rendszer élettartamára vagy hosszabb időtartamára terjed ki. Az erőforrásokat gyakran helyi adatokkal és vezérlősík-frissítésekkel kezelik, feltéve, hogy támogatják az állásidő nélküli frissítési műveleteket. |
| Állapot | Mivel ezek az erőforrások a rendszer legalább teljes élettartama alatt léteznek, gyakran ez a réteg felelős a globális, georeplikált állapotok tárolásáért. |
| Elérés | Az erőforrásokat globálisan el kell osztani és replikálni kell az erőforrásokat üzemeltető régiókba. 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én. |
| Skálázási korlátok | Ezek az erőforrások gyakran egyszeri példányok a rendszerben, és képesnek kell lenniük úgy méretezni, hogy képesek legyenek kezelni a rendszer egészének átviteli sebességét. |
| Rendelkezésre állás/vészhelyreállítás | A regionális és bélyeg típusú erőforrások globális erőforrásokat használhatnak. 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ára vonatkozóan. |
A bélyeg tartalmazza az üzleti tranzakciók végrehajtásában részt vevő alkalmazást és erőforrásokat. 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ő | Megfontolandó szempontok |
|---|---|
| É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 élettartamú természetre azért van szükség, hogy nagyobb rugalmasságot, skálázást és közelségi lehetőséget biztosítson a felhasználókhoz. |
| Állapot | Mivel a bélyegek rövid élettartamúak, és az egyes üzembe helyezésekkel együtt megsemmisülnek, a bélyegnek a lehető legnagyobb mértékben állapot nélkülinek kell lennie. |
| 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 el kell kerülni. |
| Függőségek | A bélyegerőforrásoknak függetlennek kell lenniük. Ezek várhatóan regionális és globális függőségekkel rendelkeznek, de nem támaszkodhatnak más bélyegek összetevőire ugyanazon vagy más régiókban. |
| Skálázá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élyeg átviteli sebességének meg kell becsülnie egy másik bélyeg feladatátvétele által okozott magas szintű keresletet. |
| 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ő. |
Egy rendszer rendelkezhet olyan erőforrásokkal, amelyek a régióban vannak üzembe helyezve, de kiugróan kiélezik a bélyegerőforrásokat. Például olyan megfigyelhetőségi erőforrások, amelyek regionális szinten figyelik az erőforrásokat, beleértve a bélyegeket is.
| Jellemző | Megfontolandó |
|---|---|
| Életre | Az erőforrások megosztják a régió élettartamát, és a bélyegerőforrásokat élőben osztják meg. |
| Állapot | 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, érdemes lehet globális adattárat használni. |
| Elérés | Az erőforrásokat nem kell globálisan elosztani. A más régiókkal folytatott 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, a bélyegerőforrásoktól azonban nem, mert a bélyegek rövid élettartamúak. |
| Skálázási korlátok | A régión belüli összes bélyeg kombinálásával meghatározhatja a regionális erőforrások skálázási korlátját. |
Ezek az alapkonfigurációs példák a kritikus fontosságú alkalmazásokhoz ajánlott északi star architektúrát szolgálják. Az alapkonfiguráció kifejezetten a tárolók használatát és egy tárolóvezénylő használatát javasolja az alkalmazásplatformhoz. Az alapkonfiguráció Azure Kubernetes Service (AKS) használ.
Lásd: Jól megtervezett, kritikus fontosságú számítási feladatok: Tárolóba helyezése.
Ha csak most kezdi meg a kritikus fontosságú folyamatot, használja referenciaként ezt az architektúrát. A számítási feladat nyilvános végponton keresztül érhető el, és nem igényel privát hálózati kapcsolatot más vállalati erőforrásokhoz.
Ez az architektúra az alaparchitektúra alapján épül. A kialakítás ki van terjesztve, hogy szigorú hálózati vezérlőket biztosítson, hogy megakadályozza az internetről a számítási feladatok erőforrásaihoz való jogosulatlan nyilvános hozzáférést.
Ez az architektúra akkor megfelelő, ha a számítási feladatot vállalati környezetben helyezi üzembe, ahol integrációra van szükség egy szélesebb szervezeten belül. A számítási feladat központosított megosztott szolgáltatásokat használ, helyszíni kapcsolatot igényel, és integrálható a vállalaton belüli egyéb számítási feladatokkal. Egy Azure-beli kezdőzóna-előfizetésben van üzembe helyezve, amely a Corp. felügyeleti csoporttól öröklődik.
Ez az architektúra kibővíti az alapkonfigurációt azáltal, hogy az App Servicest tekinti elsődleges alkalmazásüzemeltési technológiának, amely könnyen használható környezetet biztosít a tárolók üzembe helyezéséhez.
Javasoljuk, hogy a megadott tervezési útmutató segítségével navigáljon a legfontosabb tervezési döntések között az optimális megoldás elérése érdekében. További információ: Mik a legfontosabb tervezési területek?
Tekintse át a kritikus fontosságú alkalmazásforgatókönyvek tervezésére vonatkozó ajánlott eljárásokat.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: