Javaslatok rendelkezésre állási zónák és régiók használatához
Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslat:
| RE:05 | Redundancia hozzáadása különböző szinteken, különösen kritikus folyamatok esetén. Redundancia alkalmazása a számítási, adat-, hálózati és egyéb infrastruktúraszintekre az azonosított megbízhatósági céloknak megfelelően. |
|---|
Kapcsolódó útmutatók: Magas rendelkezésre állású többrégiós kialakítás | redundancia
Ez az útmutató a számítási feladatok rendelkezésre állási zónákban vagy régiókban való üzembe helyezésének meghatározására vonatkozó javaslatokat ismerteti.
Az Azure-hoz készült megoldás tervezésekor el kell döntenie, hogy egy régió több rendelkezésre állási zónájában fog-e üzembe helyezni, vagy több régióban helyezi-e üzembe. Ez a döntés hatással van a megoldás megbízhatóságára, költségére és teljesítményére, valamint arra, hogy csapata képes-e a megoldás üzemeltetésére. Ez az útmutató tájékoztatást nyújt a döntését befolyásoló legfontosabb üzleti követelményekről, a megfontolható megközelítésekről, az egyes megközelítésekben érintett kompromisszumokról, valamint arról, hogy az egyes megközelítések milyen hatással vannak az Azure Well-Architected Framework alappilléreire.
A megoldáshoz leginkább használható Azure-régiókról való döntés kritikus fontosságú. Az Azure-régiók kiválasztása útmutató azt ismerteti, hogyan választhat és üzemeltethet több földrajzi régióban. A régiók és a rendelkezésre állási zónák megoldáson belüli használatának megválasztása a well-architected keretrendszer több pillérére is hatással van:
- Megbízhatóság: Az üzembe helyezési módszer kiválasztása segíthet a különböző típusú kockázatok enyhítésében. Általánosságban elmondható, hogy a számítási feladatok földrajzilag elosztott területeken való terjesztésével nagyobb rugalmasság érhető el.
- Költségoptimalizálás: Egyes architekturális megközelítésekhez több erőforrást kell üzembe helyezni, mint mások, ami növelheti az erőforrásköltségeket. Más megközelítések közé tartozik az adatok földrajzilag elkülönített rendelkezésre állási zónák vagy régiók közötti küldése, amelyek hálózati forgalmi díjakat vonhatnak maguk után. Fontos figyelembe venni az erőforrások kezelésének folyamatos költségeit is, ami általában magasabb, ha átfogó üzleti követelményekkel rendelkezik.
- Teljesítményhatékonyság: A rendelkezésre állási zónák nagy sávszélességű, alacsony késésű hálózati kapcsolaton keresztül csatlakoznak egymáshoz, ami elegendő a legtöbb számítási feladat számára a szinkron replikáció és a zónák közötti kommunikáció engedélyezéséhez. Ha azonban a számítási feladatot tesztelték, és érzékeny a zónák közötti hálózati késésre, érdemes lehet fizikailag közelítenie a számítási feladat összetevőit, hogy minimálisra csökkentse a kommunikáció során fellépő késést.
- Működési kiválóság: Az összetett architektúra több erőfeszítést igényel az üzembe helyezéshez, konfiguráláshoz és kezeléshez. Emellett egy magas rendelkezésre állású megoldás esetében előfordulhat, hogy meg kell terveznie a feladatátvételt egy másodlagos erőforráskészletre. A feladatátvétel, a feladat-visszavétel és a forgalom transzparens átirányítása összetett lehet, különösen akkor, ha manuális lépésekre van szükség. Ajánlott eljárás az üzembe helyezési és felügyeleti folyamatok automatizálása. További információkért tekintse meg az Operational Excellence alappilléres útmutatóját, beleértve az OE:05-infrastruktúra mint kód, az OE:09 feladatautomatizálás, az OE:10 Automation-tervezés és az OE:11 üzembe helyezési eljárásait.
A megoldás tervezésekor a Biztonsági pillér érvényes. A rendelkezésre állási zónák és régiók használatának és használatának módjával kapcsolatos döntések általában nem változtatnak a biztonsági helyzeten. Az Azure ugyanezt a biztonsági szigort alkalmazza minden régióra és rendelkezésre állási zónára.
Tipp.
Számos éles számítási feladat esetében a zónaredundáns üzembe helyezés biztosítja a kompromisszumok legjobb egyensúlyát. Ezt a megközelítést az aszinkron adatmentés egy másik régióra is kiterjesztheti. Ha nem biztos abban, hogy melyik megközelítést válassza, kezdje az ilyen típusú üzembe helyezéssel.
Fontolja meg a számítási feladatok egyéb megközelítéseit, ha az adott megközelítések által biztosított konkrét előnyökre van szüksége, de vegye figyelembe az érintett kompromisszumokat.
Meghatározások
| Időszak | Definíció |
|---|---|
| Aktív-aktív | Olyan architektúra, amelyben egy megoldás több példánya egyszerre dolgoz fel aktívan kérelmeket. |
| Aktív-passzív | Olyan architektúra, amelyben a megoldás egy példánya elsődlegesként van kijelölve, és feldolgozza a forgalmat, és egy vagy több másodlagos példány van üzembe helyezve a forgalom kiszolgálására, ha az elsődleges nem érhető el. |
| Aszinkron replikáció | Adatreplikációs módszer, amelyben az adatok írása és lekötése egy helyen történik. Egy későbbi időpontban a rendszer replikálja a módosításokat egy másik helyre. |
| A rendelkezésre állási zóna | Egy régióban lévő adatközpontok elkülönített csoportja. Minden rendelkezésre állási zóna független a többiekétől, saját energiaellátási, hűtési és hálózati infrastruktúrával. Számos régió támogatja a rendelkezésre állási zónákat. |
| Adatközpont | Olyan létesítmény, amely kiszolgálókat, hálózati berendezéseket és egyéb hardvereket tartalmaz az Azure-erőforrások és számítási feladatok támogatásához. |
| Helyileg redundáns üzembe helyezés | Olyan üzemi modell, amelyben egy erőforrás egyetlen régióban van üzembe helyezve, rendelkezésre állási zónára való hivatkozás nélkül. A rendelkezésre állási zónákat támogató régióban az erőforrás a régió rendelkezésre állási zónáinak bármelyikében üzembe helyezhető. |
| Többrégiós üzembe helyezés | Üzembehelyezési modell, amelyben az erőforrások több Azure-régióban vannak üzembe helyezve. |
| Párosított régiók | Kapcsolat két Azure-régió között. Egyes Azure-régiók egy másik meghatározott régióhoz csatlakoznak a többrégiós megoldások bizonyos típusainak engedélyezéséhez. Az újabb Azure-régiók nincsenek párosítva. |
| Régió | Egy földrajzi szegély, amely adatközpontokat tartalmaz. |
| Régióarchitektúra | Az Azure-régió konkrét konfigurációja, beleértve a rendelkezésre állási zónák számát és azt, hogy a régió párosítva van-e egy másik régióval. |
| Szinkron replikáció | Adatreplikációs módszer, amelyben az adatok több helyen is meg lesznek írva és lekötöttek. Minden helynek nyugtáznia kell az írási művelet befejezését, mielőtt a teljes írási műveletet befejezettnek tekintené. |
| Zonal (rögzített) üzembe helyezés | Olyan üzembehelyezési modell, amelyben egy erőforrás egy adott rendelkezésre állási zónába van üzembe helyezve. |
| Zónaredundáns üzembe helyezés | Olyan üzemi modell, amelyben egy erőforrás több rendelkezésre állási zónában van üzembe helyezve. A Microsoft kezeli az adatszinkronizálást, a forgalomelosztást és a feladatátvételt, ha egy zóna leállást tapasztal. |
Főbb tervezési stratégiák
Az Azure nagy globális lábnyomokkal rendelkezik. Az Azure-régió egy földrajzi szegély, amely adatközpontokat tartalmaz. Ismernie kell az Azure-régiókat és a rendelkezésre állási zónákat.
Az Azure-régiók számos konfigurációval rendelkeznek, amelyeket régióarchitektúráknak is neveznek.
Számos Azure-régió biztosít rendelkezésre állási zónákat, amelyek adatközpontok különálló csoportjai. Egy régión belül a rendelkezésre állási zónák elég közel vannak ahhoz, hogy alacsony késésű kapcsolatokat létesíthessenek más rendelkezésre állási zónákkal, de elég messze vannak egymástól ahhoz, hogy csökkenjen annak a valószínűsége, hogy egynél többre hatással lesznek a helyi kimaradások vagy az időjárás. A rendelkezésreállási zónák független áramellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Úgy vannak kialakítva, hogy ha az egyik zóna kimaradást tapasztal, akkor a fennmaradó zónák támogatják a regionális szolgáltatásokat, a kapacitást és a magas rendelkezésre állást.
Az alábbi ábra több Azure-régiót mutat be. Az 1. és a 2. régió támogatja a rendelkezésre állási zónákat.
Ha egy rendelkezésre állási zónákat tartalmazó Azure-régióban települ, több rendelkezésre állási zónát is használhat együtt. Több rendelkezésre állási zóna használatával külön másolatot készíthet az alkalmazásról és az adatokról külön fizikai adatközpontokban egy nagy nagyvárosban.
A rendelkezésre állási zónák kétféleképpen használhatók a megoldásokban:
- A zónaalapú erőforrások egy adott rendelkezésreállási zónához vannak rögzítve. A magas szintű megbízhatóság iránti követelmények teljesítése érdekében lehetősége van a többzónás telepítés különböző zónák közötti kombinálására. Ön felel az adatreplikáció kezeléséért és a kérelmek zónák közötti elosztásáért. Ha egy rendelkezésreállási zónában kimaradás következik be, Ön a felelős a másik rendelkezésreállási zónába történő feladatátvételért.
- A zónaredundáns erőforrások több rendelkezésreállási zóna között vannak elosztva. A Microsoft felügyeli a kérelmek zónák közötti elosztását és az adatok zónák közötti replikációját. Ha egy rendelkezésreállási zónában kimaradás következik be, a Microsoft automatikusan felügyeli a feladatátvételt.
Az Azure-szolgáltatások ezen megközelítések egyikét vagy mindkettőt támogatják. A szolgáltatásként nyújtott platformszolgáltatások (PaaS) általában támogatják a zónaredundáns üzembe helyezéseket. Az infrastruktúra szolgáltatásként (IaaS) általában támogatja a zónatelepítéseket. Az Azure-szolgáltatások rendelkezésre állási zónákkal való használatáról további információt a rendelkezésre állási zónák támogatásával rendelkező Azure-szolgáltatásokban talál.
Amikor a Microsoft frissítéseket helyez üzembe a szolgáltatásokon, megpróbáljuk a legkevésbé zavaró módszereket használni. Célunk például, hogy egyszerre egyetlen rendelkezésre állási zónában helyezzünk üzembe frissítéseket. Ez a módszer csökkentheti a frissítések aktív számítási feladatokra gyakorolt hatását, mivel a számítási feladat továbbra is futhat más zónákban, amíg a frissítés folyamatban van. Végső soron azonban a számítási feladatokért felelős csapat feladata annak biztosítása, hogy a számítási feladatok továbbra is működjenek a platformfrissítések során. Ha például virtuálisgép-méretezési csoportokat használ rugalmas vezénylési móddal vagy a legtöbb Azure PaaS-szolgáltatással, az Azure intelligensen helyezi el az erőforrásokat a platformfrissítések hatásának csökkentése érdekében. Emellett megfontolhatja a túlterjedést – egy erőforrás több példányának üzembe helyezését –, hogy egyes példányok elérhetők maradjanak a többi példány frissítése során. Az Azure frissítéseinek üzembe helyezésével kapcsolatos további információkért tekintse meg a biztonságos üzembehelyezési eljárások előmozdítását ismertető témakört.
Számos régió is rendelkezik párosított régióval. A párosított régiók támogatják a többrégiós üzembe helyezés bizonyos típusait. Néhány újabb régió több rendelkezésre állási zónával rendelkezik , és nem rendelkezik párosított régióval. Ezekben a régiókban továbbra is üzembe helyezhet többrégiós megoldásokat, de a használt megközelítések eltérőek lehetnek.
További információ arról, hogy az Azure hogyan használja a régiókat és a rendelkezésre állási zónákat: Mik azok az Azure-régiók és rendelkezésre állási zónák?
A megosztott felelősségek ismertetése
A megosztott felelősség elve azt írja le, hogyan oszlanak meg a felelősségek a felhőszolgáltató (Microsoft) és Ön között. A használt szolgáltatások típusától függően előfordulhat, hogy többé-kevésbé felelősséget vállal a szolgáltatás működtetéséért.
A Microsoft rendelkezésre állási zónákat és régiókat biztosít, hogy rugalmasan tervezze meg a megoldást a követelményeknek megfelelően. Felügyelt szolgáltatások használata esetén a Microsoft több felügyeleti feladatot vállal az erőforrásokért, ami akár adatreplikálást, feladatátvételt, feladat-visszavételt és az elosztott rendszer működtetésével kapcsolatos egyéb feladatokat is magában foglalhat.
A saját kódnak ajánlott eljárásokra és tervezési mintákra van szüksége a hibák kecses kezeléséhez. Ezek a gyakorlatok még fontosabbak a feladatátvételi műveletek során, például azok, amelyek egy rendelkezésre állási zóna vagy régió feladatátvétele során történnek, mivel a zónák vagy régiók közötti feladatátvétel általában megköveteli, hogy az alkalmazás újra megkísérlje a kapcsolatokat a szolgáltatásokhoz.
A legfontosabb üzleti és számítási feladatokra vonatkozó követelmények azonosítása
Ahhoz, hogy megalapozott döntést hozzon a rendelkezésre állási zónák és régiók megoldásban való használatáról, ismernie kell a követelményeket. Ezeket a követelményeket a megoldástervezők és az üzleti érdekelt felek közötti megbeszéléseknek kell vezérelniük.
Kockázattűrés
A különböző szervezetek különböző kockázati tűrési fokokkal rendelkeznek. A kockázattűrés még a szervezeten belül is gyakran különbözik az egyes számítási feladatoktól. A legtöbb számítási feladathoz nincs szükség rendkívül magas rendelkezésre állásra. Bizonyos számítási feladatok azonban annyira fontosak, hogy még a nem valószínű kockázatokat is érdemes enyhíteni, például a nagy földrajzi területet érintő súlyos természeti katasztrófákat.
Ez a táblázat felsorol néhányat a felhőkörnyezetben megfontolandó gyakori kockázatok közül:
| Kockázat | Példák | Valószínűség |
|---|---|---|
| Hardverkimaradás | Probléma a merevlemezzel vagy a hálózati berendezéssel. A gazdagép újraindítása. |
Magas. Minden rugalmassági stratégiának figyelembe kell vennie ezeket a kockázatokat. |
| Adatközpont-kimaradás | Energiaellátási, hűtési vagy hálózati hiba egy teljes adatközpontban. Természeti katasztrófa egy nagyváros egyik részén. |
Közepes |
| Régiókimaradás | Jelentős természeti katasztrófa, amely egy széles földrajzi területet érint. Hálózati vagy szolgáltatási probléma, amely egy vagy több Azure-szolgáltatást elérhetetlenné tesz egy teljes régióban. |
Alacsony |
Ideális megoldás lenne minden számítási feladat minden lehetséges kockázatának mérséklésére, de ez nem praktikus vagy költséghatékony. Fontos, hogy az üzleti érdekelt felekkel nyílt megbeszélést tarthassunk, hogy megalapozott döntéseket hozhassunk a mérsékelendő kockázatokról.
Tipp.
A megbízhatósági céloktól függetlenül minden számítási feladatnak rendelkeznie kell valamilyen kockázatcsökkentéssel a vészhelyreállításhoz. Ha a számítási feladatok magas megbízhatósági célokat igényelnek, akkor a kockázatcsökkentési stratégiáknak átfogónak kell lenniük, és csökkenteniük kell a még alacsony valószínűségű események kockázatát. Egyéb számítási feladatok esetén hozzon megalapozott döntést arról, hogy mely kockázatokat hajlandó elfogadni, és milyen kockázatokat kell enyhítenie.
Rugalmassági követelmények
Fontos tisztában lenni a számítási feladat rugalmassági követelményeivel, beleértve a helyreállítási idő célkitűzését (RTO) és a helyreállítási pont célkitűzését (RPO). Ezek a célkitűzések segítenek eldönteni, hogy mely megközelítéseket érdemes kizárni. Ha nem rendelkezik egyértelmű követelményekkel, nem hozhat megalapozott döntést arról, hogy melyik megközelítést kell követnie. További információ: A cél funkcionális és nem funkcionális követelményei.
Szolgáltatási szintű célkitűzések
Ismernie kell a megoldás várható üzemidejű szolgáltatásiszint-célkitűzését (SLO). Előfordulhat például, hogy a megoldásnak 99,9%-os üzemidőt kell teljesítenie.
Az Azure minden szolgáltatáshoz szolgáltatásiszint-szerződéseket (SLA-kat) biztosít. Az SLA jelzi a szolgáltatástól elvárt üzemidő szintjét, valamint azokat a feltételeket, amelyeknek meg kell felelnie a várt SLA eléréséhez. Ne feledje azonban, hogy az Azure SLA a szolgáltatás rendelkezésre állását jelzi, nem mindig egyezik meg azzal, ahogyan a számítási feladat állapotát figyelembe veszi.
Az architekturális döntések hatással vannak a megoldás összetett SLO-jára. Általában minél több redundanciát épít be a megoldásba, annál nagyobb valószínűséggel lesz az SLO. Számos Azure-szolgáltatás magasabb SLA-kat biztosít a szolgáltatások zónaredundáns vagy többrégiós konfigurációban történő üzembe helyezésekor. Tekintse át az egyes Azure-szolgáltatások SLA-ját annak érdekében, hogy megértse, hogyan maximalizálható a szolgáltatás rugalmassága és SLA-ja.
Adattárolási hely
Egyes szervezetek korlátozásokat léptetnek életbe azon fizikai helyeken, ahol az adataik tárolhatók és feldolgozhatók. Néha ezek a követelmények jogi vagy szabályozási szabványokon alapulnak. Más esetekben a szervezet dönthet úgy, hogy egy adattárolási szabályzatot fogad el az ügyfelek aggodalmainak elkerülése érdekében. Ha szigorú adattárolási követelményekkel rendelkezik, előfordulhat, hogy egyrégiós üzembe helyezést kell használnia, vagy az Azure-régiók és -szolgáltatások egy részhalmazát kell használnia.
Feljegyzés
Kerülje az adattárolási követelményekkel kapcsolatos alaptalan feltételezéseket. Ha meg kell felelnie bizonyos szabályozási szabványoknak, ellenőrizze, hogy ezek a szabványok valójában mit határoznak meg.
Felhasználó helye
Ha tisztában van a felhasználók tartózkodási helyére, megalapozott döntést hozhat arról, hogyan optimalizálhatja a késést és a megbízhatóságot az igényeinek megfelelően. Az Azure számos lehetőséget kínál a földrajzilag elosztott felhasználói bázisok támogatására.
Ha a felhasználók egy területre koncentrálódnak, az egyrégiós üzembe helyezés leegyszerűsítheti az üzemeltetési követelményeket, és csökkentheti a költségeket. Meg kell azonban fontolnia, hogy egy egyrégiós üzemelő példány megfelel-e a megbízhatósági követelményeknek. Kritikus fontosságú alkalmazások esetén még akkor is többrégiós üzembe helyezést kell használnia, ha a felhasználókat áthelyezték.
Ha a felhasználók földrajzilag el vannak oszlva, érdemes lehet több régióban üzembe helyezni a számítási feladatot. Az Azure-szolgáltatások különböző képességeket biztosítanak a többrégiós üzemelő példányok támogatásához, és az Azure globális lábnyomával javíthatja felhasználói élményét, és közelebb hozhatja alkalmazásait a felhasználói bázishoz. Használhatja a Központi telepítési bélyegek vagy a Geodéziai mintát, vagy replikálhatja az erőforrásokat több régióban.
Még akkor is, ha a felhasználók különböző földrajzi területeken vannak, fontolja meg, hogy többrégiós üzembe helyezésre van-e szüksége. Fontolja meg, hogy egy régióban el tudja-e érni a követelményeket globális forgalomgyorsítással, például az Azure Front Door által biztosított gyorsítással.
Költségvetés
Ha korlátozott költségvetéssel dolgozik, fontos figyelembe venni a redundáns számítási feladatok összetevőinek üzembe helyezésével járó költségeket. Ezek a költségek további erőforrásköltségeket, hálózatkezelési költségeket, valamint a több erőforrás kezelésének működési költségeit és egy összetettebb környezetet is magukban foglalhatnak.
Összetettség
Célszerű elkerülni a megoldásarchitektúra szükségtelen összetettségét. Minél összetettebb a bevezetés, annál nehezebb döntéseket hozni az architektúráról. Az összetett architektúrák nehezebben kezelhetők, biztonságosabbak és gyakran kevésbé teljesíthetők. Kövesse az egyszerűség elvét.
Az Azure megkönnyítése
Régiók és rendelkezésre állási zónák biztosításával az Azure lehetővé teszi az igényeinek megfelelő üzembe helyezési megközelítés kiválasztását. Számos megközelítés közül választhat, amelyek mindegyike előnyöket és költségekkel jár.
A használható üzembehelyezési megközelítések szemléltetéséhez tekintsen meg egy példaforgatókönyvet. Tegyük fel, hogy egy olyan új megoldás üzembe helyezésén gondolkodik, amely egy olyan alkalmazást tartalmaz, amely adatokat ír valamilyen tárolóba:
Ez a példa nem konkrét Azure-szolgáltatásokra vonatkozik. Ez egy egyszerű példát kínál az alapvető fogalmak szemléltetésére.
A megoldás többféleképpen is üzembe helyezhető. Minden megközelítés különböző előnyöket biztosít, és különböző költségekkel jár. Magas szinten helyileg redundáns, zónaredundáns vagy többrégiós üzembe helyezést is megfontolhat. Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Helyileg redundáns | Zonal (rögzített) | Zónaredundáns | Többrégió |
|---|---|---|---|---|
| Megbízhatóság | Alacsony megbízhatóság | A megközelítéstől függ | Magas vagy nagyon magas megbízhatóság | Magas vagy nagyon magas megbízhatóság |
| Költségoptimalizálás | Alacsony költség | A megközelítéstől függ | Mérsékelt költség | Magas költség |
| Teljesítménybeli hatékonyság | Elfogadható teljesítmény (a legtöbb számítási feladat esetében) | Nagy teljesítmény | Elfogadható teljesítmény (a legtöbb számítási feladat esetében) | A megközelítéstől függ |
| Működésbeli kiválóság | Alacsony üzemeltetési követelmények | Magas üzemeltetési követelmények | Alacsony üzemeltetési követelmények | Magas üzemeltetési követelmények |
Ez a táblázat összefoglalja a használható megközelítések némelyikét, valamint az architektúrára gyakorolt hatásokat:
| Architekturális probléma | Helyileg redundáns | Zonal (rögzített) | Zónaredundáns | Többrégió |
|---|---|---|---|---|
| Az adattárolás megfelelősége | Magas | Magas | Magas | Régiótól függ |
| Regionális elérhetőség | Minden régió | Rendelkezésre állási zónákkal rendelkező régiók | Rendelkezésre állási zónákkal rendelkező régiók | Régiótól függ |
A cikk további része az előző táblázatban felsorolt megközelítéseket ismerteti. A megközelítések listája nem teljes. Dönthet úgy, hogy több megközelítést kombinál, vagy különböző megközelítéseket használ a megoldás különböző részeiben.
1. üzembe helyezési megközelítés: Helyileg redundáns üzemelő példányok
Ha nem ad meg több rendelkezésre állási zónát vagy régiót az erőforrások üzembe helyezésekor, az Azure nem garantálja, hogy az erőforrások egyetlen adatközpontban vannak-e üzembe helyezve, vagy a régió több adatközpontja között vannak-e felosztva. Bizonyos esetekben az Azure is áthelyezheti az erőforrást a rendelkezésre állási zónák között.
A legtöbb Azure-erőforrás alapértelmezés szerint magas rendelkezésre állású, magas SLA-kkal és beépített redundanciával a platform által felügyelt adatközpontban. Megbízhatósági szempontból azonban, ha a régió bármely része üzemkimaradást tapasztal, fennáll annak az esélye, hogy a számítási feladat érintett lehet. Ha igen, előfordulhat, hogy a megoldás nem érhető el, vagy az adatok elveszhetnek.
A nagy késésre érzékeny számítási feladatok esetében ez a megközelítés alacsonyabb teljesítményt is eredményezhet. Előfordulhat, hogy a számítási feladatok összetevői nem ugyanabban az adatközpontban vannak, ezért előfordulhat, hogy a régión belüli forgalom némi késést észlel. Az Azure transzparens módon is áthelyezheti a szolgáltatáspéldányokat a rendelkezésre állási zónák között, ami kis mértékben befolyásolhatja a teljesítményt. Ez azonban a legtöbb számítási feladat esetében nem okoz problémát.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Alacsony megbízhatóság. Egy adatközpont meghibásodása esetén a szolgáltatások kimaradásnak vannak kitéve. Létrehozhat azonban egy alkalmazást, hogy ellenálló legyen más típusú hibákhoz. |
| Költségoptimalizálás | Legalacsonyabb költség. Csak az egyes erőforrások egyetlen példányával kell rendelkeznie, és nem merülnek fel régiók közötti sávszélesség-költségek. |
| Teljesítménybeli hatékonyság | A legtöbb számítási feladat esetében: Elfogadható teljesítmény. Ez a megközelítés valószínűleg kielégítő teljesítményt nyújt. Nagy késésre érzékeny számítási feladatok esetén: Alacsony teljesítmény. Az összetevők nem garantáltan ugyanabban a rendelkezésre állási zónában találhatók, így a nagy késésre érzékeny összetevők teljesítménye alacsonyabb lehet. |
| Működésbeli kiválóság | Magas működési hatékonyság. Csak az egyes erőforrások egyetlen példányát kell üzembe helyeznie és kezelnie. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | Magas. Ha ezt a megközelítést használó megoldást helyez üzembe, az adatok a kiválasztott Azure-régióban lesznek tárolva. |
| Regionális elérhetőség | Magas. Ez a megközelítés bármely Azure-régióban használható. |
Helyileg redundáns üzemelő példányok régiók közötti biztonsági mentéssel
A helyileg redundáns üzembe helyezést úgy terjesztheti ki, hogy rendszeresen biztonsági másolatot készít az infrastruktúráról és az adatokról egy másodlagos régióra. Ez a megközelítés egy további védelmi réteget ad hozzá az elsődleges régióban történő kimaradás elleni védekezéshez. A következőképpen néz ki:
Ennek a megközelítésnek a megvalósításakor gondosan figyelembe kell vennie az RTO-t és az RPO-t:
- Helyreállítási idő: Regionális kimaradás esetén előfordulhat, hogy újra kell építenie a megoldást egy másik Azure-régióban, ami hatással van a helyreállítási időre. Fontolja meg a megoldás kiépítését egy kódként használható infrastruktúra(IaC) megközelítéssel, hogy nagy katasztrófa esetén gyorsan újra üzembe helyezhető legyen egy másik régióban. Győződjön meg arról, hogy az üzembehelyezési eszközök és folyamatok ugyanolyan rugalmasak, mint az alkalmazások, így használatuk segítségével újra üzembe helyezheti a megoldást, még akkor is, ha kimaradás történik. Tervezze meg és próbálja ki a megoldás működő állapotba való visszaállításához szükséges lépéseket.
- Helyreállítási pont: A biztonsági mentés gyakorisága határozza meg, hogy mekkora adatvesztést tapasztalhat (a helyreállítási pont). Általában szabályozhatja a biztonsági mentések gyakoriságát, hogy megfeleljen az RPO-nak.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Közepes megbízhatóság. Egy adatközpont meghibásodása esetén a szolgáltatások kimaradásnak vannak kitéve. Az adatokról aszinkron módon készít biztonsági másolatot egy földrajzilag elválasztott régióra, amely az adatvesztés minimalizálásával csökkenti a teljes régió kimaradásának hatását. A teljes régió kimaradása esetén manuálisan visszaállíthatja a műveleteket egy másik régióba. A helyreállítási folyamatok azonban összetettek lehetnek, és időbe telhet a másik régióba való manuális visszaállítás. |
| Költségoptimalizálás | Alacsony költség. A biztonsági mentés egy másik régióhoz való hozzáadása általában csak valamivel többe kerül, mint egy helyileg redundáns erőforrás üzembe helyezése. |
| Teljesítménybeli hatékonyság | A legtöbb számítási feladat esetében: Elfogadható teljesítmény. Ez a megközelítés valószínűleg kielégítő teljesítményt nyújt. Nagy késésre érzékeny számítási feladatok esetén: Alacsony teljesítmény. Az összetevők nem garantáltan ugyanabban a rendelkezésre állási zónában találhatók, így a nagy késésre érzékeny összetevők teljesítménye alacsonyabb lehet. |
| Működésbeli kiválóság | Egy régión belüli üzemkimaradás esetén: Alacsony működési hatékonyság. A feladatátvétel az Ön feladata, és manuális műveleteket és újratelepítéseket igényelhet. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | A régió kiválasztásától függ. Az adatok tárolása elsősorban a megadott Azure-régióban történik. Azonban ki kell választania egy másik régiót a biztonsági másolatok tárolásához, ezért fontos, hogy olyan régiót válasszon ki, amely kompatibilis az adattárolási követelményekkel. |
| Regionális elérhetőség | Magas. Ezt a megközelítést bármely Azure-régióban használhatja. |
2. üzembe helyezési módszer: Zonal (rögzített) üzembe helyezések
A zonális üzemelő példányban meg kell adnia, hogy az erőforrásokat egy adott rendelkezésre állási zónában kell üzembe helyezni. Ezt a megközelítést zóna által rögzített üzembe helyezésnek is nevezik.
Az zonális megközelítés csökkenti az összetevők közötti késést. Önmagában azonban nem növeli a megoldás rugalmasságát. A rugalmasság növeléséhez több összetevőpéldányt kell üzembe helyeznie több rendelkezésre állási zónában, és el kell döntenie, hogyan irányíthatja a forgalmat az egyes példányok között. Ez a példa egy aktív-passzív forgalomirányítási megközelítést mutat be:
Az előző példában a terheléselosztó több rendelkezésre állási zónában van üzembe helyezve. Fontos megfontolni, hogyan irányíthatja a forgalmat a különböző rendelkezésre állási zónák példányai között, mert a zónakimaradás hatással lehet az adott zónában üzembe helyezett hálózati erőforrásokra is. Megfontolhatja egy globális terheléselosztó használatát is, például az Azure Front Doort vagy az Azure Traffic Managert, amely egyáltalán nincs üzembe helyezve egy régióban.
A zonális üzembehelyezési modell használata során számos feladatot vállal:
- Minden rendelkezésre állási zónában üzembe kell helyeznie az erőforrásokat, és egyenként kell konfigurálnia és kezelnie ezeket az erőforrásokat.
- El kell döntenie, hogyan és mikor replikálja az adatokat a rendelkezésre állási zónák között, majd konfigurálnia és kezelnie kell a replikációt.
- Ön a felelős a kérések megfelelő erőforrásokhoz való elosztásáért, például egy terheléselosztó használatával. Gondoskodnia kell arról, hogy a terheléselosztó megfeleljen a rugalmassági követelményeknek. Azt is el kell döntenie, hogy aktív-passzív vagy aktív-aktív kérelemterjesztési modellt szeretne-e használni.
- Ha egy rendelkezésre állási zóna leállást tapasztal, a feladatátvételt úgy kell kezelnie, hogy forgalmat küldjön egy másik rendelkezésre állási zónában lévő erőforrásoknak.
Az aktív-passzív üzembe helyezést több rendelkezésre állási zónában néha régión belüli DR-nek vagy Metro DR-nek is nevezik.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Ha egyetlen rendelkezésre állási zónában van üzembe helyezve: Alacsony megbízhatóság. A zónabeli üzembe helyezés nem biztosít semmilyen rugalmasságot az adatközpontokban vagy a rendelkezésre állási zónákban történő kimaradásokkal szemben. A magas rugalmasság érdekében redundáns erőforrásokat kell üzembe helyeznie több rendelkezésre állási zónában. Több rendelkezésre állási zónában üzembe helyezve: Magas megbízhatóság. A szolgáltatások rugalmassá tehetők az adatközpontokkal vagy a rendelkezésre állási zónák kimaradásokkal szemben. |
| Költségoptimalizálás | Egyetlen rendelkezésre állási zónában üzembe helyezve: Alacsony költség. Az egyzónás üzembe helyezéshez csak az egyes erőforrások egyetlen példánya szükséges. Ha több rendelkezésre állási zónában van üzembe helyezve: magas költség. Az erőforrások több példányát is üzembe helyezheti, amelyek mindegyike külön számlázva van. |
| Teljesítménybeli hatékonyság | Nagy teljesítmény. A késés nagyon alacsony lehet, ha a kérést kiszolgáló összetevők ugyanabban a rendelkezésre állási zónában találhatók. |
| Működésbeli kiválóság | Alacsony működési hatékonyság. A szolgáltatás több példányát kell konfigurálnia és kezelnie. Adatokat kell replikálnia a rendelkezésre állási zónák között. A rendelkezésre állási zónák leállása során a feladatátvétel az Ön feladata. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | Magas. Ha ezt a megközelítést használó megoldást helyez üzembe, az adatok a kiválasztott Azure-régióban lesznek tárolva. |
| Regionális elérhetőség | Rendelkezésre állási zónákkal rendelkező régiók. Ez a megközelítés bármely olyan régióban elérhető, amely támogatja a rendelkezésre állási zónákat. |
Ezt a megközelítést általában virtuális gépeken alapuló számítási feladatokhoz használják. A zónatelepítéseket támogató szolgáltatások teljes listáját a Rendelkezésre állási zóna szolgáltatás és a regionális támogatás című témakörben találja.
Ha zónaalapú üzembe helyezést tervez, ellenőrizze, hogy az Ön által használt Azure-szolgáltatások támogatottak-e a használni kívánt rendelkezésre állási zónákban. Ha például listázni szeretné, hogy mely virtuálisgép-termékváltozatok érhetők el az egyes rendelkezésre állási zónákban, tekintse meg a virtuálisgép-termékváltozat rendelkezésre állásának ellenőrzését.
Tipp.
Amikor egy erőforrást egy adott rendelkezésre állási zónába helyez üzembe, ki kell választania a zóna számát. A zónaszámok sorrendje minden Azure-előfizetés esetében eltérő. Ha több Azure-előfizetésben helyez üzembe erőforrásokat, ellenőrizze az egyes előfizetésekben használni kívánt zónaszámokat. További információ: Fizikai és logikai rendelkezésre állási zónák.
3. üzembe helyezési megközelítés: Zónaredundáns üzemelő példányok
Ha ezt a megközelítést használja, az alkalmazásszint több rendelkezésre állási zónában is el van osztva. A kérések érkezésekor a szolgáltatásba beépített terheléselosztó (amely magában a rendelkezésre állási zónákra is kiterjed) eloszlatja a kéréseket az egyes rendelkezésre állási zónák példányai között. Ha egy rendelkezésre állási zóna üzemkimaradást tapasztal, a terheléselosztó a forgalmat az kifogástalan rendelkezésre állási zónák példányaihoz irányítja.
A tárolási szint több rendelkezésre állási zónában is el van osztva. Az alkalmazás adatainak másolatai több rendelkezésre állási zónában vannak elosztva szinkron replikációval. Amikor az alkalmazás módosítja az adatokat, a tárolási szolgáltatás több rendelkezésre állási zónára írja a módosítást, és a tranzakció csak akkor tekinthető befejezettnek, ha az összes módosítás befejeződött. Ez a folyamat biztosítja, hogy az egyes rendelkezésre állási zónák mindig naprakész másolatot készítsenek az adatokról. Ha egy rendelkezésre állási zóna leállást tapasztal, egy másik rendelkezésre állási zóna is használható ugyanazon adatok eléréséhez.
A zónaredundáns megközelítés növeli a megoldás rugalmasságát az olyan problémákkal szemben, mint az adatközpont-kimaradások. Mivel azonban az adatok szinkron módon vannak replikálva, az alkalmazásnak meg kell várnia, hogy az adatok több különböző helyen legyenek megírva, amelyek egy nagyváros különböző részein lehetnek. A legtöbb alkalmazás esetében a zónák közötti kommunikáció késése elhanyagolható. Néhány nagy késésre érzékeny számítási feladat esetében azonban a rendelkezésre állási zónák közötti szinkron replikáció hatással lehet az alkalmazás teljesítményére.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Nagy megbízhatóság. A szolgáltatások rugalmasak az adatközpontok vagy a rendelkezésre állási zónák kimaradásával szemben. A rendszer szinkron módon replikálja az adatokat a rendelkezésre állási zónák között, és késedelem nélkül. |
| Költségoptimalizálás | Mérsékelt költség. A használt szolgáltatásoktól függően előfordulhat, hogy a zónaredundanciát lehetővé tevő magasabb szolgáltatási szintek bizonyos költségekkel járnak. |
| Teljesítménybeli hatékonyság | A legtöbb számítási feladat esetében: Elfogadható teljesítmény. Ez a megközelítés valószínűleg kielégítő teljesítményt nyújt. Nagy késésre érzékeny számítási feladatok esetén: Alacsony teljesítmény. Egyes összetevők a zónaközi forgalom vagy az adatreplikációs idő miatt érzékenyek lehetnek a késésre. |
| Működésbeli kiválóság | Magas működési hatékonyság. Általában csak az egyes erőforrások egyetlen logikai példányát kell kezelnie. A legtöbb szolgáltatás esetében a rendelkezésre állási zónák leállása során a feladatátvétel a Microsoft feladata, és automatikusan megtörténik. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | Magas. Ha ezt a megközelítést használó megoldást helyez üzembe, az adatok a kiválasztott Azure-régióban lesznek tárolva. |
| Regionális elérhetőség | Rendelkezésre állási zónákkal rendelkező régiók. Ez a megközelítés bármely olyan régióban elérhető, amely támogatja a rendelkezésre állási zónákat. |
Ez a megközelítés számos Azure-szolgáltatással lehetséges, beleértve az Azure-beli virtuálisgép-méretezési csoportokat, Azure-alkalmazás szolgáltatást, az Azure Functionst, az Azure Kubernetes Service-t, az Azure Storage-t, az Azure SQL-t, az Azure Service Bust és még sok más szolgáltatást. A zónaredundanciát támogató szolgáltatások teljes listáját a Rendelkezésre állási zóna szolgáltatás és a regionális támogatás című témakörben találja.
Zónaredundáns üzemelő példányok régiók közötti biztonsági mentéssel
A zónaredundáns üzembe helyezést úgy terjesztheti ki, hogy rendszeresen biztonsági másolatot készít az infrastruktúráról és az adatokról egy másodlagos régióra. Ez a megközelítés a zónaredundáns megközelítés előnyeit nyújtja, és egy védelmi réteget ad hozzá, hogy enyhítse a teljes régió kimaradásának rendkívül valószínűtlen eseményét.
Ennek a megközelítésnek a megvalósításakor gondosan figyelembe kell vennie az RTO-t és az RPO-t:
Helyreállítási idő: Ha regionális kimaradás történik, előfordulhat, hogy újra kell építenie a megoldást egy másik Azure-régióban, ami hatással van a helyreállítási időre. Fontolja meg a megoldás kiépítését IaC-megközelítéssel, hogy egy nagyobb katasztrófa során gyorsan újra üzembe helyezhesse a másik régiót. Győződjön meg arról, hogy az üzembehelyezési eszközök és folyamatok ugyanolyan rugalmasak, mint az alkalmazások, így azok használatával újra üzembe helyezheti a megoldást, még akkor is, ha kimaradás történik. Tervezze meg és próbálja ki a megoldás működő állapotba való visszaállításához szükséges lépéseket.
Helyreállítási pont: A biztonsági mentés gyakorisága határozza meg, hogy mekkora adatvesztést tapasztalhat (a helyreállítási pont). Az RPO-nak való megfelelés érdekében általában szabályozhatja a biztonsági mentések gyakoriságát.
Tipp.
Ez a megközelítés gyakran jó egyensúlyt biztosít minden építészeti szempont számára. Ha nem biztos abban, hogy melyik megközelítést használja, kezdje az ilyen típusú üzembe helyezéssel.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Nagyon nagy megbízhatóság. A szolgáltatások rugalmasak az adatközpontok vagy a rendelkezésre állási zónák kimaradásával szemben. A legtöbb szolgáltatás esetében az adatok automatikusan és késedelem nélkül replikálódnak a zónák között. Az adatok biztonsági mentése aszinkron módon történik egy földrajzilag elkülönített régióba. Ez a biztonsági mentés csökkenti a teljes régió kimaradásának hatását az adatvesztés minimalizálásával. A teljes régió leállása után manuálisan visszaállíthatja a műveleteket egy másik régióba. A helyreállítási folyamatok azonban összetettek lehetnek, és időbe telhet a másik régióba való manuális visszaállítás. |
| Költségoptimalizálás | Mérsékelt költség. A biztonsági mentés egy másik régióhoz való hozzáadása általában csak valamivel többe kerül, mint a zónaredundancia implementálása. |
| Teljesítménybeli hatékonyság | A legtöbb számítási feladat esetében: Elfogadható teljesítmény. Ez a megközelítés valószínűleg kielégítő teljesítményt nyújt. Nagy késésre érzékeny számítási feladatok esetén: Alacsony teljesítmény. Egyes összetevők a zónaközi forgalom vagy az adatreplikációs idő miatt érzékenyek lehetnek a késésre. |
| Működésbeli kiválóság | Rendelkezésre állási zóna kimaradása esetén: Magas működési hatékonyság. A feladatátvétel a Microsoft feladata, és automatikusan megtörténik. Regionális üzemkimaradás esetén: Alacsony működési hatékonyság. A feladatátvétel az Ön feladata, és manuális műveleteket és újratelepítéseket igényelhet. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | A régió kiválasztásától függ. Az adatok tárolása elsősorban a megadott Azure-régióban történik, de a biztonsági mentések tárolásához másik régiót kell választania. Válasszon ki egy olyan régiót, amely kompatibilis az adattárolási követelményekkel. |
| Regionális elérhetőség | Rendelkezésre állási zónákkal rendelkező régiók. Ez a megközelítés bármely olyan régióban elérhető, amely támogatja a rendelkezésre állási zónákat. |
4. üzembe helyezési megközelítés: Többrégiós üzemelő példányok
Több Azure-régióval is eloszthatja a megoldást egy széles földrajzi területen. Ezzel a többrégiós megközelítéssel javíthatja a megoldás megbízhatóságát, vagy támogathatja a földrajzilag elosztott felhasználókat. Több régióban való üzembe helyezéssel csökkentheti azt a kockázatot is, hogy egy adott régióban átmeneti erőforrás-kapacitáskorlátozás lép fel. Ha az adattárolás fontos szempont a megoldás szempontjából, gondosan gondolja át, hogy mely régiókat használja annak biztosítására, hogy az adatok tárolása csak a követelményeknek megfelelő helyeken történjen.
Aktív és passzív régiók
A többrégiós architektúrák összetettek, és számos módon tervezhet többrégiós megoldást. Egyes számítási feladatok esetében érdemes több régióval egyidejűleg feldolgozni a kéréseket (aktív-aktív üzemelő példányok). Más számítási feladatok esetében jobb, ha kijelöl egy elsődleges régiót , és egy vagy több másodlagos régiót használ a feladatátvételhez (aktív-passzív üzemelő példányok). Ez a szakasz a második forgatókönyvre összpontosít, amelyben az egyik régió aktív, a másik pedig passzív. Az aktív-aktív többrégiós megoldásokról további információt az Üzembehelyezési bélyegek és a Geode minta című témakörben talál.
Adatreplikáció
A régiók közötti kommunikáció sokkal lassabb, mint egy régión belüli kommunikáció. A két régió közötti nagyobb földrajzi távolság általában nagyobb hálózati késéssel jár, mivel az adatoknak hosszabb fizikai távolságra van szükségük. A két régió közötti csatlakozás várható hálózati késési statisztikáinak megtekintése az Azure-ban.
A régiók közötti hálózati késés jelentősen befolyásolhatja a megoldás kialakítását, mivel alaposan át kell gondolnia, hogy a többletkésés hogyan befolyásolja az adatreplikálást és az egyéb tranzakciókat. Számos megoldás esetében a régiók közötti architektúra aszinkron replikációt igényel a régiók közötti forgalom teljesítményre gyakorolt hatásának minimalizálása érdekében.
Aszinkron adatreplikálás
Amikor régiók közötti aszinkron replikációt implementál, az alkalmazás nem várja meg, hogy az összes régió nyugtázza a változást. Miután a módosítás véglegesítése megtörtént az elsődleges régióban, a tranzakció befejezettnek minősül. A rendszer később replikálja a módosítást a másodlagos régiókba. Ez a megközelítés biztosítja, hogy a régiók közötti kapcsolat késése ne befolyásolja közvetlenül az alkalmazás teljesítményét. A replikáció késése miatt azonban a régióra kiterjedő kimaradás némi adatvesztést okozhat. Ez az adatvesztés azért fordulhat elő, mert előfordulhat, hogy egy régió leáll, miután az írás befejeződött az elsődleges régióban, de mielőtt a módosítás replikálható lenne egy másik régióba.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Nagy megbízhatóság. A megoldás ellenáll egy adatközpont, egy rendelkezésre állási zóna vagy egy teljes régió üzemkimaradásának. Az adatok replikálva vannak, de előfordulhat, hogy nem szinkronizálódnak, így egy feladatátvételi forgatókönyvben lehetséges némi adatvesztés. |
| Költségoptimalizálás | Magas költség. Minden régióban külön erőforrásokat kell üzembe helyeznie, és minden erőforrás üzembe helyezési és karbantartási költségeket von maga után. A régiók közötti adatreplikálás szintén jelentős költségekkel járhat. |
| Teljesítménybeli hatékonyság | Nagy teljesítmény. Az alkalmazáskérések nem igényelnek régiók közötti forgalmat, ezért a forgalom általában alacsony késésű. |
| Működésbeli kiválóság | Alacsony működési hatékonyság. Több régióban kell telepítenie és kezelnie az erőforrásokat. Ön felelős a régiók közötti feladatátvételért is egy regionális kimaradás során. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | A régió kiválasztásától függ. Ehhez a megközelítéshez több régiót kell kijelölnie a számítási feladat futtatásához. Válassza ki az adattárolási követelményekkel kompatibilis régiókat. |
| Regionális elérhetőség | Számos Azure-régió van párosítva. Egyes Azure-szolgáltatások párosított régiókat használnak az adatok automatikus replikálásához. Ha a számítási feladatot egy olyan régióban futtatja, amely nem rendelkezik párkal, előfordulhat, hogy más megközelítést kell használnia az adatok replikálásához. |
Szinkron adatreplikálás
Ha szinkron többrégiós megoldást implementál, az alkalmazásnak meg kell várnia, amíg az írási műveletek befejeződnek az egyes Azure-régiókban, mielőtt a tranzakció befejezettnek minősül. Az írási műveletekre való várakozás késése a régiók közötti távolságtól függ. Sok számítási feladat esetén a régiók közötti késés túl lassúvá teheti a szinkron replikációt, hogy hasznos legyen.
Ez a táblázat az alappillérek néhány aggályát foglalja össze:
| Pillér | Hatás |
|---|---|
| Megbízhatóság | Nagyon nagy megbízhatóság. A megoldás ellenáll egy adatközpont, egy rendelkezésre állási zóna vagy egy teljes régió üzemkimaradásának. Az adatok mindig szinkronizálva lesznek a régiók között, így még akkor is, ha teljes régióvesztés történik, az adatok egy másik régióban érhetők el és fejeződnek be. |
| Költségoptimalizálás | Magas költség. Minden régióban külön erőforrásokat kell üzembe helyeznie, és minden erőforrás üzembe helyezési és karbantartási költségeket von maga után. A régiók közötti adatreplikálás szintén jelentős költségekkel járhat. |
| Teljesítménybeli hatékonyság | Alacsony teljesítmény. Az alkalmazáskérések régióközi forgalmat igényelnek. A régiók közötti távolságtól függően a szinkron replikáció jelentős késést okozhat a kérelmekben. |
| Működésbeli kiválóság | Alacsony működési hatékonyság. Több régióban kell telepítenie és kezelnie az erőforrásokat. Ön felelős a régiók közötti feladatátvételért is egy regionális kimaradás során. |
Ez a táblázat az architektúra szempontjából összefoglal néhány aggályt:
| Architekturális probléma | Hatás |
|---|---|
| Az adattárolás megfelelősége | A régió kiválasztásától függ. Ehhez a megközelítéshez több régiót kell kijelölnie a számítási feladat futtatásához. Válassza ki az adattárolási követelményekkel kompatibilis régiókat. |
| Regionális elérhetőség | Számos Azure-régió van párosítva. Egyes Azure-szolgáltatások párosított régiókat használnak az adatok automatikus replikálásához. Ha a számítási feladatot egy olyan régióban futtatja, amely nem rendelkezik párkal, előfordulhat, hogy más megközelítést kell használnia az adatok replikálásához. |
Régióarchitektúrák
Többrégiós megoldás tervezésekor fontolja meg, hogy a használni kívánt Azure-régiók párosítva vannak-e.
Többrégiós megoldást akkor is létrehozhat, ha a régiók nincsenek párosítva. A többrégiós architektúrák implementálásához használt megközelítések azonban eltérőek lehetnek. Az Azure Storage-ban például georedundáns tárolást (GRS) használhat párosított régiókkal. Ha a GRS nem érhető el, fontolja meg az Olyan funkciók használatát, mint az Azure Storage-objektumreplikáció, vagy tervezze meg az alkalmazást, hogy több régióba írjon.
Többzónás és többrégiós megközelítések kombinálása
Többzónás és többrégiós utasításokat kell kombinálnia, ha az üzleti követelmények ilyen megoldást igényelnek. Üzembe helyezhet például zónaredundáns összetevőket az egyes régiókban, és konfigurálhatja a régiók közötti replikációt is. Néhány megoldás esetében ez a megközelítés nagyon magas megbízhatóságot biztosít. Az ilyen típusú megközelítés konfigurálása azonban bonyolult lehet, és ez a megközelítés költséges lehet.
Fontos
A kritikus fontosságú számítási feladatoknak több rendelkezésre állási zónát és több régiót kell használniuk. A kritikus fontosságú számítási feladatok tervezésekor megfontolandó szempontokról további információt a kritikus fontosságú számítási feladatok dokumentációjában talál.
Hogyan támogatják az Azure-szolgáltatások az üzembe helyezési módszereket?
Fontos megérteni a használt Azure-szolgáltatások részleteit. Egyes Azure-szolgáltatások esetében például a rendelkezésre állási zóna konfigurációját kell konfigurálni az erőforrás első üzembe helyezésekor, míg mások támogatják az üzembe helyezési módszer későbbi módosítását. Hasonlóképpen előfordulhat, hogy egyes szolgáltatásfunkciók nem érhetők el minden üzembe helyezési megközelítéssel.
Ha többet szeretne megtudni az egyes Azure-szolgáltatásokra vonatkozó üzembe helyezési lehetőségekről és megközelítésekről, látogasson el a Megbízhatósági központba.
Példák
Ez a szakasz néhány gyakori használati esetet és azokat a fő követelményeket ismerteti, amelyeket általában figyelembe kell vennie az egyes számítási feladatokhoz. Minden számítási feladathoz egy vagy több javasolt üzembe helyezési módszert biztosítunk a cikkben ismertetett követelmények és megközelítések alapján.
Vállalati üzletági alkalmazás
A Contoso, Ltd. egy nagy gyártó vállalat. A vállalat egy üzletági alkalmazást implementál a pénzügyi folyamatok egyes összetevőinek kezelésére.
Üzleti követelmények: A rendszer által kezelt információkat nehéz lecserélni, ezért az adatokat megbízhatóan kell őrizni. Az építészek szerint a rendszernek a lehető legkevesebb állásidőt és adatvesztést kell eredményeznie. A Contoso alkalmazottai a teljes munkanap alatt használják a rendszert, ezért a magas teljesítmény fontos a csapattagok várakozásának elkerülése érdekében. A költségek is aggodalomra adnak okot, mivel a pénzügyi csapatnak fizetnie kell a megoldásért.
Javasolt megközelítés: A régiók közötti biztonsági mentéssel rendelkező zónaredundáns üzembe helyezés több rugalmassági réteget biztosít nagy teljesítménnyel.
Belső alkalmazás
A negyedik kávé egy kis üzlet. A vállalat egy új belső alkalmazást fejleszt, amellyel az alkalmazottak munkaidő-nyilvántartásokat küldhetnek be.
Üzleti követelmények: Ehhez a számítási feladathoz elsődleges szempont a költséghatékonyság. A Fourth Coffee kiértékelte az állásidő üzleti hatását, és úgy döntött, hogy az alkalmazásnak nem kell rangsorolnia a rugalmasságot vagy a teljesítményt. A vállalat elfogadja annak kockázatát, hogy egy Azure rendelkezésre állási zónában vagy régióban történő kimaradás ideiglenesen elérhetetlenné teheti az alkalmazást.
Javasolt megközelítések:
- A helyileg redundáns üzembe helyezés a régiók közötti biztonsági mentésekkel a legalacsonyabb költséggel jár, de jelentős kockázatokkal is jár.
- A régiók közötti biztonsági mentéssel rendelkező zónaredundáns üzembe helyezés nagyobb rugalmasságot biztosít, de valamivel magasabb költséggel.
Örökölt alkalmazásmigrálás
A Fabrikam, Inc. egy örökölt alkalmazást migrál egy helyszíni adatközpontból az Azure-ba. Az implementáció egy virtuális gépeken alapuló IaaS-megközelítést fog használni. Az alkalmazást nem felhőkörnyezethez tervezték, és az alkalmazásszint és az adatbázis közötti kommunikáció nagyon beszédes.
Üzleti követelmények: A teljesítmény az alkalmazás egyik prioritása. A rugalmasság is fontos, és az alkalmazásnak továbbra is működnie kell, még akkor is, ha egy Azure-adatközpont leállást tapasztal.
Javasolt megközelítés:
- A Fabrikannek először ki kell próbálnia egy zónaredundáns üzembe helyezést. Ellenőrizniük kell, hogy a teljesítmény megfelel-e a követelményeknek.
- Ha a zónaredundáns megoldás teljesítménye nem elfogadható, fontolja meg a zónaalapú (rögzített) üzembe helyezést, amely több rendelkezésre állási zónában (régión belüli DR) passzív üzembe helyezéseket is alkalmaz.
Egészségügyi alkalmazás
A Lamna Healthcare Company új elektronikus egészségügyi rekordrendszert vezet be az Azure-ban.
Üzleti követelmények: A megoldás által tárolt adatok jellegéből adódóan az adattárolás kritikus fontosságú. A Lamna szigorú szabályozási keretben működik, amely előírja, hogy az adatoknak egy adott helyen kell maradniuk.
Javasolt megközelítések:
- Többzónás többrégiós üzembe helyezés, ha több régió is megfelel a Lamna adattárolási követelményeinek.
- Ha csak egyetlen régió felel meg az igényeiknek, fontolja meg a zónaredundáns üzembe helyezést vagy a régiók közötti biztonsági mentéssel rendelkező zónaredundáns üzembe helyezést, amely egyrégiós megoldást biztosít
Banki rendszer
A Woodgrove Bank az Azure-ban üzembe helyezett nagy megoldásból futtatja alapvető banki műveleteit.
Üzleti követelmények: Ez egy kritikus fontosságú rendszer. A kimaradások jelentős pénzügyi hatással lehetnek az ügyfelekre. Ennek eredményeképpen a Woodgrove Bank nagyon alacsony kockázattűréssel rendelkezik. A rendszernek a lehető legmagasabb szintű megbízhatóságra van szüksége, és az architektúrának csökkentenie kell a elhárítható hibák kockázatát.
Javasolt megközelítés: Kritikus fontosságú rendszerek esetén használjon többzónás többrégiós üzembe helyezést. Győződjön meg arról, hogy a régiók megfelelnek a vállalat adattárolási követelményeinek.
Szolgáltatott szoftver (SaaS)
A Proseware, Inc. olyan szoftvereket fejleszt, amelyeket a világ különböző vállalatai használnak. A vállalat felhasználói bázisa földrajzilag széles körben elterjedt.
Üzleti követelmények: A Proseware-nek lehetővé kell tennie minden ügyfél számára, hogy az ügyfélhez közeli üzembehelyezési régiót válasszon. A választás engedélyezése fontos a késés és az ügyfelek adattárolási követelményei szempontjából.
Javasolt megközelítések:
- A többzónás többrégiós üzembe helyezés általában jó választás egy SaaS-szolgáltató számára, különösen akkor, ha az üzembehelyezési bélyegek mintájában használják.
- Egyrégiós zónaredundáns üzembe helyezés egy globális forgalomgyorsító megoldással, például az Azure Front Doornal együtt.
Kapcsolódó hivatkozások
Az alábbiakban néhány referenciaarchitektúrát és példaforgatókönyvet láthat a többzónás és többrégiós megoldásokhoz:
- Alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás
- Magas rendelkezésre állású többrégiós webalkalmazás
- Többrégiós N szintű alkalmazás
- Ha/DR-hez készült többrétegű webalkalmazás
Számos Azure-szolgáltatás nyújt útmutatást több rendelkezésre állási zóna használatához, beleértve az alábbi példákat:
- Azure Site Recovery: Azure-beli virtuális gépek vészhelyreállításának engedélyezése a rendelkezésre állási zónák között
- Azure NetApp Files: Az Azure NetApp Files zónák közötti replikációjának ismertetése
- Redundancia az Azure Storage szolgáltatásban
Megbízhatósági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.