Javaslatok a 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ó javaslatra vonatkozik:

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 tervezés | redundancia

Ez az útmutató a számítási feladatok rendelkezésre állási zónákban vagy régiókban történő ü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 helyezi-e üzembe az üzembe helyezést, vagy több régióban helyezi ü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 a csapat 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ó kulcsfontosságú ü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-keretrendszer alapvető pilléreire.

A megoldáshoz használni kívánt legjobb Azure-régiókról való döntés kritikus választás. 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 rendelkezésreállási zónák megoldáson belüli használatának megválasztása a Well-Architected-keretrendszer számos 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 csökkentésében. Általánosságban elmondható, hogy a számítási feladatok földrajzilag elosztott területeken való elosztásával nagyobb rugalmasságot érhet el.
• Költségoptimalizálás: Egyes architekturális megközelítésekhez több erőforrást kell üzembe helyezni, mint a többit, 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, ami hálózati forgalmi díjakat vonhat maga 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ű, kis késésű hálózati kapcsolaton keresztül kapcsolódnak egymáshoz, ami elegendő a legtöbb számítási feladat számára a zónák közötti szinkron replikáció és kommunikáció engedélyezéséhez. Ha azonban a számítási feladat tesztelése megtörtént, és érzékeny a zónák közötti hálózati késésre, érdemes lehet fizikailag egymáshoz közel helyeznie a számítási feladat összetevőit, hogy minimálisra csökkentse a késést a kommunikáció során.
• Működési kiválóság: Az összetett architektúra nagyobb erőfeszítést igényel az üzembe helyezéshez, konfiguráláshoz és felügyelethez. Emellett egy magas rendelkezésre állású megoldás esetében előfordulhat, hogy meg kell terveznie, hogyan kell feladatátvételt végrehajtani 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ására. További információkért tekintse meg az Operational Excellence pillér útmutatóit, beleértve az OE:05-infrastruktúra mint kód, az OE:09 Feladatautomatizálás, az OE:10 Automation tervezése és az OE:11 üzembehelyezési eljárásait.

A megoldás megtervezése azonban a Biztonsági pillért is alkalmazza. A rendelkezésre állási zónák és régiók használatával kapcsolatos döntések általában nem változtatnak a biztonsági helyzeten. Az Azure ugyanazt 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éssel kiterjesztheti egy másik régióra. Ha nem biztos abban, hogy melyik módszert válassza, kezdje az ilyen típusú üzembe helyezéssel.

Vegye figyelembe a számítási feladatok egyéb megközelítéseit, ha az említett megközelítések által nyújtott konkrét előnyökre van szüksége, de vegye figyelembe az ezzel járó kompromisszumokat.

Definíciók

Időszak	Definíció
Aktív-aktív	Olyan architektúra, amelyben egy megoldás több példánya dolgoz fel aktívan kérelmeket egyszerre.
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ányt helyez üzembe a forgalom kiszolgálására, ha az elsődleges példány nem érhető el.
Aszinkron replikáció	Egy adatreplikációs módszer, amelyben az adatok egyetlen helyre lesznek megírva és véglegesítve. Később a rendszer replikálja a módosításokat egy másik helyre.
A rendelkezésre állási zóna	Egy régión belüli adatközpontok elkülönített csoportja. Minden rendelkezésre állási zóna független a többi zóná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 üzembehelyezési modell, amelyben egy erőforrás egyetlen régióban van üzembe helyezve anélkül, hogy rendelkezésre állási zónára hivatkozna. A rendelkezésre állási zónákat támogató régióban az erőforrás a régió bármelyik rendelkezésre állási zónájában üzembe helyezhető.
Többrégiós üzembe helyezés	Egy ü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.
Region	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 véglegesítve. Minden helynek nyugtáznia kell az írási művelet befejezését, mielőtt a teljes írási műveletet befejezettnek tekintené.
Zónaszintű (rögzített) üzembe helyezés	Egy ü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	Egy üzembehelyezési 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.

Kulcsfontosságú tervezési stratégiák

Az Azure-nak nagy globális lábnyoma van. 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 kis késésű kapcsolatokat létesíthessenek más rendelkezésre állási zónákkal, de elég messze vannak egymástól, 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 energiaellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Úgy vannak kialakítva, hogy ha egy zóna kimaradásba kerül, 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 helyezi üzembe az üzembe helyezést, 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 egy nagy nagyvárosi régióban található különálló fizikai adatközpontokban.

A rendelkezésre állási zónák kétféleképpen használhatók a megoldásokban:

• A zónaszintű erőforrások egy adott rendelkezésre állási zónához vannak rögzítve. Több zónaszintű üzembe helyezést kombinálhat különböző zónákban a magas megbízhatósági követelmények kielégítése érdekében. Ön felelős az adatreplikálás kezeléséért és a kérések zónák közötti elosztásáért. Ha egy rendelkezésre állási zónában kimaradás történik, a feladatátvétel egy másik rendelkezésre állási zónába történik.
• A zónaredundáns erőforrások több rendelkezésre állási zónában vannak elosztva. A Microsoft kezeli a kérések zónák közötti elosztását és az adatok zónák közötti replikálását. Ha egy rendelkezésre állási zónában kimaradás történik, a Microsoft automatikusan kezeli 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. A szolgáltatott infrastruktúra (IaaS) szolgáltatásai általában támogatják az zónaszintű üzembe helyezé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ások című témakörben talál.

Amikor a Microsoft frissítéseket helyez üzembe a szolgáltatásokban, olyan megközelítéseket próbálunk használni, amelyek a legkevésbé zavaróak Az Ön számára. Például arra törekszünk, hogy egyszerre egyetlen rendelkezésre állási zónában telepítsük a frissítéseket. Ez a megközelítés 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 biztosítani, 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úlépítést – egy erőforrás több példányának üzembe helyezését –, hogy egyes példányok elérhetők maradjanak, amíg más példányok frissülnek. További információ arról, hogy az Azure hogyan helyezi üzembe a frissítéseket: Biztonságos üzembehelyezési eljárások fejlesztése.

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. Egyes újabb régiók több rendelkezésre állási zónával rendelkeznek, és nem rendelkeznek 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 leírja, 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 a szolgáltatás működtetéséért több vagy kevesebb felelősséget is vállalhat.

A Microsoft rendelkezésre állási zónákat és régiókat biztosít, hogy rugalmasan tervezze meg a megoldását a követelményeknek megfelelően. Felügyelt szolgáltatások használata esetén a Microsoft nagyobb felügyeleti feladatokat vállal az erőforrásokért, amelyek akár adatreplikálást, feladatátvételt, feladat-visszavételt és az elosztott rendszerek működtetésével kapcsolatos egyéb feladatokat is magukban foglalhatnak.

A saját kódnak ajánlott eljárásokra és tervezési mintákra van szüksége a hibák szabályos kezeléséhez. Ezek a gyakorlatok még fontosabbak a feladatátvételi műveletek során, például a rendelkezésre állási zónák vagy a régiók feladatátvétele során, mivel a zónák vagy régiók közötti feladatátvételhez az alkalmazásnak újra meg kell próbálkoznia a szolgáltatásokhoz való csatlakozással.

Az üzleti és számítási feladatok legfontosabb követelményeinek 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, tisztában kell lenni a követelményekkel. 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 egy 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. Egyes számítási feladatok azonban annyira fontosak, hogy érdemes lehet enyhíteni azokat a kockázatokat, amelyek nem valószínűek, mint például a nagy földrajzi területeket érintő súlyos természeti katasztrófák.

Ez a táblázat felsorol néhány gyakori kockázatot, amelyeket érdemes figyelembe venni egy felhőkörnyezetben:

Kockázat	Példák	Valószínűsége
Hardverkimaradás	Merevlemezzel vagy hálózati berendezéssel kapcsolatos probléma. A gazdagép újraindul.	Magas. Minden rugalmassági stratégiának figyelembe kell vennie ezeket a kockázatokat.
Adatközpont-szolgáltatáskimaradás	Áramellá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óleállá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 csökkentésére, de ez nem praktikus vagy költséghatékony. Fontos, hogy az üzleti érdekelt felekkel nyílt párbeszédet folytassunk, hogy megalapozott döntéseket hozhassunk a kockázatokkal kapcsolatban, amelyeket csökkenteni kell.

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 feladat magas megbízhatósági célokat igényel, 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 kell elfogadnia, és melyeket 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 időkorlátot (RPO). Ezek a célkitűzések segítenek eldönteni, hogy mely megközelítéseket kell kizárni. Ha nem rendelkezik egyértelmű követelményekkel, nem hozhat tájékozott 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ásiszint-célkitűzések

Tisztában kell lennie a megoldás várható üzemidejű szolgáltatásiszint-célkitűzésével (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 által a szolgáltatás rendelkezésre állását jelző módszer 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 magasabb az SLO. Számos Azure-szolgáltatás magasabb SLA-kat biztosít, amikor zónaredundáns vagy többrégiós konfigurációban telepít szolgáltatásokat. Tekintse át az egyes Azure-szolgáltatások SLA-ját, hogy biztosan tisztában legyen azzal, hogyan maximalizálhatja a szolgáltatás rugalmasságát és SLA-ját.

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 helyzetekben a szervezetek dönthetnek úgy, hogy adattárolási szabályzatot vezetnek be az ügyfélproblémák elkerülése érdekében. Ha szigorú adattárolási követelményekkel rendelkezik, előfordulhat, hogy egyrégiós üzemelő példányt kell használnia, vagy az Azure-régiók és -szolgáltatások egy részhalmazát kell használnia.

Megjegyzé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álnak, 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 akkor is többrégiós üzemelő példányt kell használnia, ha a felhasználók egymás mellett vannak.

Ha a felhasználók földrajzilag el vannak osztva, érdemes lehet több régióban üzembe helyezni a számítási feladatokat. 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 a felhasználói élményt, és közelebb hozhatja alkalmazásait a felhasználói bázishoz. Használhatja az Üzembehelyezési bélyegek mintát vagy a Geodes mintát, vagy replikálhatja az erőforrásokat több régióban.

Még ha a felhasználók különböző földrajzi területeken is vannak, fontolja meg, hogy többrégiós üzembe helyezésre van-e szükség. Gondolja át, hogy el tudja-e érni a követelményeket egyetlen régióban 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ásifeladat-összetevők üzembe helyezésének költségeit. Ezek a költségek további erőforrásköltségeket, hálózati költségeket, valamint további erőforrások kezelésének működési költségeit és összetettebb környezetet is magukban foglalhatnak.

Összetettség

Érdemes elkerülni a megoldásarchitektúra szükségtelen összetettségét. Minél összetettebb, annál nehezebb döntéseket hozni az architektúráról. Az összetett architektúrák nehezebben kezelhetők, nehezebben védhetőek, és gyakran kevésbé teljesítők. Kövesse az egyszerűség elvét.

Azure-beli segítségnyújtás

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égeket jelent.

A használható üzembehelyezési módszerek szemléltetéséhez vegyünk 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 egy adott Azure-szolgáltatásra vonatkozik. Egyszerű példát kíván adni 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égeket von maga után. Magas szinten helyileg redundáns, zónaszintű (rögzített), zónaredundáns vagy többrégiós üzembe helyezést is figyelembe vehet. Ez a táblázat a pillérekkel kapcsolatos néhány aggályt foglalja össze:

Pillér	Helyileg redundáns	Zonal (rögzített)	Zónaredundáns	Többrégiós
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, és azt, hogy ezek milyen hatással vannak az architektúrára:

Architekturális probléma	Helyileg redundáns	Zonal (rögzített)	Zónaredundáns	Többrégiós
Az adattárolási hely 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 többi része az előző táblázatban felsorolt összes megközelítést 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özpontba vannak-e üzembe helyezve, vagy a régió több adatközpontja között oszlanak meg. 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, akkor lehetséges, hogy a számítási feladat is é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 áthelyezve, ezért előfordulhat, hogy a régión belüli forgalom késését észleli. Az Azure transzparens módon á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 nem jelent problémát a legtöbb számítási feladat esetében.

Ez a táblázat a pillérekkel kapcsolatos néhány aggályt foglalja össze:

Pillér	Hatás
Megbízhatóság	Alacsony megbízhatóság. A szolgáltatások kimaradnak, ha egy adatközpont meghibásodik. Létrehozhat azonban egy alkalmazást, hogy rugalmasan alkalmazkodjon más típusú hibákhoz.
Költségoptimalizálás	Legalacsonyabb költség. Minden erőforrásnak csak egyetlen példányával kell rendelkeznie, és nem kell zónák közötti vagy régiók közötti sávszélesség-költségekkel számolnia.
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 előfordulhat, hogy a nagy késésre érzékeny összetevők teljesítménye alacsonyabb lesz.
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ási hely megfelelősége	Magas. Ha ezt a módszert 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 üzembe helyezés 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 bekövetkező kimaradások elhárításához. A következőképpen néz ki:

A megközelítés megvalósításakor alaposan meg kell fontolnia 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 -megközelítéssel, hogy nagy katasztrófa esetén gyorsan újra üzembe helyezhesse a megoldást 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 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 mennyi 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 a pillérekkel kapcsolatos néhány aggályt foglalja össze:

Pillér	Hatás
Megbízhatóság	Mérsékelt megbízhatóság. A szolgáltatások kimaradnak, ha egy adatközpont meghibásodik. Az adatokról aszinkron módon készít biztonsági másolatot egy földrajzilag elkülönített régióra, ami csökkenti a teljes régió kimaradásának hatását az adatvesztés minimalizálásával. 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óba 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 előfordulhat, hogy a nagy késésre érzékeny összetevők teljesítménye alacsonyabb lesz.
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ási hely 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 módszert bármely Azure-régióban használhatja.

2. üzembehelyezési megközelítés: Zonal (rögzített) üzemelő példányok

A zónaszintű üzemelő példányokban megadhatja, 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ése érdekében az összetevők több példányát 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 egy terheléselosztó több rendelkezésre állási zónában van üzembe helyezve. Fontos figyelembe venni, hogyan irányítja 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. Érdemes lehet egy globális terheléselosztót is használni, például az Azure Front Doort vagy az Azure Traffic Managert, amely egyáltalán nincs üzembe helyezve egy régióban.

Ha zónaszintű üzemi modellt használ, számos felelősséget vállal:

• Erőforrásokat kell üzembe helyeznie az egyes rendelkezésre állási zónákban, é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.
• A kérések megfelelő erőforrásokba való elosztásáért ön felel, például egy terheléselosztó használatával. Meg kell győződnie arról, hogy a terheléselosztó megfelel 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 használ-e.
• Ha egy rendelkezésre állási zóna leállást tapasztal, akkor kezelnie kell a feladatátvételt, 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 a pillérekkel kapcsolatos néhány aggályt 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. Az zónaszintű üzemelő példányok nem biztosítanak 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 eléréséhez redundáns erőforrásokat kell üzembe helyeznie több rendelkezésre állási zónában. Ha több rendelkezésre állási zónában van üzembe helyezve:Magas megbízhatóság. A szolgáltatások rugalmassá tehetők az adatközpontok vagy a rendelkezésre állási zónák kimaradása ellen.
Költségoptimalizálás	Ha egyetlen rendelkezésre állási zónában van üzembe helyezve:Alacsony költség. Az egyzónás üzembe helyezéshez az egyes erőforrásoknak csak 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 van számlázva. Az adatreplikálás zónaközi forgalmáért is fizetnie kell.
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óna leállása során a feladatátvétel az Ön felelőssége.

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ási hely megfelelősége	Magas. Ha ezt a módszert 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 módszert általában virtuális gépeken alapuló számítási feladatokhoz használják. A zónaalapú üzemelő példányokat 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ónaszintű üzembe helyezést tervez, ellenőrizze, hogy a használni kívánt 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, olvassa el a Virtuálisgép-termékváltozat rendelkezésre állásának ellenőrzése című témakört.

Tipp

Amikor egy erőforrást egy adott rendelkezésre állási zónába helyez üzembe, ki kell választania a zónaszámot. A zónaszámok sorrendje az egyes Azure-előfizetések 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. üzembehelyezési megközelítés: Zónaredundáns üzemelő példányok

Ha ezt a módszert 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 foglalja a rendelkezésre állási zónákat) 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ó az kifogástalan rendelkezésre állási zónákban lévő példányokra irányítja a forgalmat.

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 minden rendelkezésre állási zóna mindig naprakész másolatot készítsen az adatokról. Ha egy rendelkezésre állási zóna kimaradást tapasztal, egy másik rendelkezésre állási zóna is használható ugyanazokhoz az adatokhoz való hozzáféréshez.

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árosi terület 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ó. Egyes nagy késésre érzékeny számítási feladatok 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 a pillérekkel kapcsolatos néhány aggályt foglalja össze:

Pillér	Hatás
Megbízhatóság	Nagy megbízhatóság. A szolgáltatások ellenállnak az adatközpontok vagy a rendelkezésre állási zónák kimaradásának. Az adatok szinkron módon replikálódnak 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ónaredundancia engedélyezéséhez magasabb szolgáltatási szintekhez vagy zónák közötti hálózati költségekhez kell fizetnie.
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ónák közötti 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 architekturális szempontból összefoglal néhány aggályt:

Architekturális probléma	Hatás
Az adattárolás megfelelősége	Magas. Ha ezt a módszert 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 minden 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ás esetében lehetséges, beleértve az Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus, és még sokan mások. A zónaredundanciát támogató szolgáltatások teljes listáját lásd: Rendelkezésre állási zóna szolgáltatás és regionális támogatás.

Zónaredundáns üzembe helyezések régiók közötti biztonsági mentéssel

A zónaredundáns üzembe helyezést úgy terjesztheti ki, hogy rendszeres biztonsági másolatot készít az infrastruktúráról és az adatokról egy másodlagos régióban. 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.

A megközelítés implementálásakor alaposan meg kell fontolnia 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 IaC-megközelítéssel történő kiépítését, hogy egy nagyobb katasztrófa esetén gyorsan újra üzembe helyezhesse magát 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 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 mennyi 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 teremt minden architekturális szempontnak. Ha nem biztos abban, hogy melyik megközelítést kell használnia, kezdje az ilyen típusú üzembe helyezéssel.

Ez a táblázat összefoglal néhány alappilléretet:

Pillér	Hatás
Megbízhatóság	Nagyon magas 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 adatokról aszinkron módon készül biztonsági mentés 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ókimaradás 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 történő 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óba való hozzáadása általában csak valamivel többe kerül, mint a zónaredundancia megvalósítá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ónák közötti 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 során:Magas működési hatékonyság. A feladatátvétel a Microsoft feladata, és automatikusan megtörténik. Regionális kimaradás esetén:Alacsony működési hatékonyság. A feladatátvétel az Ön feladata, és manuális műveleteket és ismételt üzembe helyezéseket igényelhet.

Ez a táblázat architekturális szempontbó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 másolatok tárolásához ki kell választania egy másik régiót. Válasszon ki egy 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 minden olyan régióban elérhető, amely támogatja a rendelkezésre állási zónákat.

4. üzembe helyezési módszer: Többrégiós üzembe helyezés

Több Azure-régiót is használhat a megoldás széles földrajzi területen való elosztásához. 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 annak kockázatát is, hogy egyetlen régióban ideiglenes erőforrás-kapacitási korlátozással kell szembesülni. 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 csak az Ön igényeinek megfelelő helyeken legyenek tárolva.

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 célszerű több régióval egyidejűleg aktívan 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. További információ az aktív-aktív többrégiós megoldásokról: Üzembehelyezési bélyegek mintája és Geode-minta.

Adatreplikáció

A régiók közötti kommunikáció sokkal lassabb, mint a régión belüli kommunikáció. Általánosságban elmondható, hogy a két régió közötti nagyobb földrajzi távolság nagyobb hálózati késést eredményez, mivel az adatoknak nagyobb fizikai távolságra van szükségük. Tekintse meg az Azure-hálózat két régió közötti csatlakozáskor várható hálózati késési statisztikáit ismertető cikket.

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 meg kell fontolnia, hogy a többletkésés milyen hatással van az adatreplikációra és más tranzakciókra. 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ítve lett 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 az egész régióra kiterjedő szolgáltatáskimaradás 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 összefoglal néhány alappilléretet:

Pillér	Hatás
Megbízhatóság	Magas megbízhatóság. A megoldás rugalmas egy adatközpont, egy rendelkezésre állási zóna vagy egy teljes régió kimaradásával szemben. Az adatok replikálva vannak, de előfordulhat, hogy nem szinkronok, így egy feladatátvételi forgatókönyvben adatvesztés lehetséges.
Költségoptimalizálás	Magas költség. Minden régióban külön erőforrásokat kell üzembe helyeznie, és mindegyik erőforrás üzembe helyezési és karbantartási költségekkel jár. 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 üzembe helyeznie és kezelnie az erőforrásokat. Ön felelős a régiók közötti feladatátvételért is egy regionális szolgáltatáskimaradás során.

Ez a táblázat architekturális szempontbó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 kiválasztania 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ében 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 összefoglal néhány alappilléretet:

Pillér	Hatás
Megbízhatóság	Nagyon magas megbízhatóság. A megoldás rugalmas egy adatközpont, egy rendelkezésre állási zóna vagy egy teljes régió kimaradásával szemben. 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 mindegyik erőforrás üzembe helyezési és karbantartási költségekkel jár. 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 közötti 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érésekben.
Működésbeli kiválóság	Alacsony működési hatékonyság. Több régióban kell üzembe helyeznie és kezelnie az erőforrásokat. Ön felelős a régiók közötti feladatátvételért is egy regionális szolgáltatáskimaradás során.

Ez a táblázat architekturális szempontbó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 kiválasztania a számítási feladat futtatásához. Válassza ki azokat a régiókat, amelyek kompatibilisek az adattárolási követelményekkel.
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úra implementálásához használt megközelítések azonban eltérőek lehetnek. Az Azure Storage-ban például használhat georedundáns tárolást (GRS) párosított régiókkal. Ha a GRS nem érhető el, fontolja meg olyan funkciók használatát, mint az Azure Storage objektumreplikációja, 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 minden régióban, és konfigurálhatja a régiók közötti replikációt is. Egyes megoldások esetében ez a megközelítés nagyon magas szintű 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 is 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 megközelítéseket?

Fontos tisztában lenni az Ön által használt Azure-szolgáltatások részleteinek részleteival. Egyes Azure-szolgáltatások például megkövetelik a rendelkezésre állási zónák konfigurálását 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. Ugyanígy 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ásokhoz megfontolandó üzembehelyezé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 üzembehelyezési megközelítés érhető el a cikkben ismertetett követelmények és megközelítések alapján.

Üzletági alkalmazás vállalatoknak

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 megőrizni. Az építészek szerint a rendszernek a lehető legkevesebb állásidőt és adatvesztést kell eredményeznie. A Contoso alkalmazottai a rendszert a munkanap folyamán használják, így a magas teljesítmény fontos a csapattagok várakozásának elkerülése érdekében. A költségek is aggodalomra ad 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 kisvállalkozás. 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 a költséghatékonyság az elsődleges szempont. 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 lévő szolgáltatáskimaradá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őalapú 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 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 szolgáltatáskimaradást tapasztal.

Javasolt megközelítés:

• A Fabrikannak 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ónaszintű (rögzített) üzembe helyezést, amelyben passzív üzembe helyezések több rendelkezésre állási zónában (régión belüli DR).

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 természetéből adódóan az adattárolás kritikus fontosságú. A Lamna szigorú jogszabályi keretek között 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 olyan régió is van, amely 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 nyújt

Banki rendszer

A Woodgrove Bank az Azure-ban üzembe helyezett nagy méretű 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ú rendszer 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 készít, 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án belül 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 a 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
• Magas rendelkezésre állásra és vészhelyreállításra tervezett többrétegű webalkalmazás

Számos Azure-szolgáltatás nyújt útmutatást a 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 rendelkezésre állási zónák között
• Azure NetApp Files: A 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.

Megbízhatósági ellenőrzőlista