A rendelkezésre állási zónák és régiók használatára vonatkozó architektúrastratégiák

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 szeretné-e üzembe helyezni, vagy több régióban szeretné üzembe helyezni. 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-keretrendszer alappilléreire.

A megoldáshoz használt Azure-régiók kritikus fontosságúak. A Select Azure régiók útmutatója ismerteti, hogyan választhatja ki és üzemeltetheti több földrajzi régióban történő műveleteket. A régiók és a rendelkezésre állási zónák megoldáson belüli használata a Well-Architected-keretrendszer több pillérére is hatással van:

• Megbízhatóság: Az üzembe helyezési módszer 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 helyeznie, mint más megközelítéseket, 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 gyakran 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 kapcsolódnak egymáshoz. Ez a hivatkozás 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 teszteli a számítási feladatot, és megállapítja, hogy az é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 minimalizálja a késést a kommunikáció során.

• 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. Magas rendelkezésre állású megoldás esetén előfordulhat, hogy azt is 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ása. További információért tekintse meg a Működési kiválóság pillér útmutatóit, beleértve a OE:05 kód szerinti infrastruktúrát, a OE:09 feladat automatizálást, a OE:10 automatizálás tervezését, és a OE:11 üzembe helyezési eljárásokat.

A biztonsági pillér a megoldás tervezésétől függetlenül é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.

Jótanács

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 kiterjesztheti aszinkron adatmentést egy másik régióra. 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 a kompromisszumokat.

Definíciók

Időszak	Definition
Aktív-aktív	Olyan architektúra, amelyben egy megoldás több példánya egyszerre dolgoz fel aktívan kérelmeket.
Active-passive	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 példány 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.
Elérhetőségi 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öbbi rendelkezésre állási zónától, és saját energiaellátási, hűtési és hálózati infrastruktúrával rendelkezik. Számos régió támogatja a rendelkezésre állási zónákat.
Datacenter	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é.
Zónás (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.

A régiók és a rendelkezésre állási zónák rendszerezése az Azure-ban

Az Azure számos adatközpontot működtet világszerte. Az Azure régió egy olyan 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 különböző konfigurációkkal 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ű kapcsolatok legyenek 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öbb zónát érintenek 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 lettek kialakítva, hogy ha egy zóna leállást tapasztal, a fennmaradó zónák továbbra is támogathatjá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 olyan Azure-régióban helyezi üzembe, amelyrendelkezésre állási zónákat tartalmaz, 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 zonális erőforrások egy adott rendelkezésre állási zónába vannak rögzítve. A nagy megbízhatósági követelményeknek való megfelelés érdekében több zónabeli üzembe helyezést kombinálhat különböző zónákban. Ön felel az adatreplikálás kezeléséért és a kérések zónák közötti elosztásáért. Ha egy szolgáltatáskimaradás egyetlen rendelkezésre állási zónában történik, ön felelős a feladatátvételért egy másik rendelkezésre állási zónába.

• 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 elosztását és az adatok zónák közötti replikálását. Ha egy kimaradás egyetlen rendelkezésre állási zónában 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 platform (PaaS) megoldások általában támogatják a zónaredundáns üzemelő példányokat. A szolgáltatásként nyújtott infrastruktúra (IaaS) megoldások általában támogatják a zónatelepítéseket. További információ az Azure-szolgáltatások rendelkezésre állási zónákkal való használatáról: Rendelkezésre állási zóna támogatásával rendelkező Azure-szolgáltatások.

A Microsoft olyan módszereket próbál használni, amelyek a legkevésbé zavaróak a szolgáltatásfrissítések telepítése során. A Microsoft például arra törekszik, hogy egyszerre egyetlen rendelkezésre állási zónában telepítse 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 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ális gép méretezési csoportokat használ rugalmas vezénylési módúmellett, vagy a legtöbb Azure PaaS-szolgáltatással, az Azure intelligensen helyezi el az erőforrásait, hogy csökkentse a platformfrissítések hatását. Fontolja meg a túlterjedést, amely egy erőforrás több példányát helyezi üzembe, így egyes példányok továbbra is elérhetők maradnak, míg más példányok frissülnek. Az Azure frissítéseinek üzembe helyezéséről további információt a Biztonságos üzembe helyezési eljárások fejlesztése című témakörben talál.

Számos régió párosított régióval is rendelkezik. 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 rendelkeznek több rendelkezésre állási zónával , és nincs párosított régiójuk. 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: 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ó é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. Ilyen feladat lehet például az adatreplikálás, a feladatátvétel, a feladat-visszavétel és az elosztott rendszer üzemeltetésével kapcsolatos egyéb feladatok.

A saját kódnak követnie kell az ajánlott eljárásokat és tervezési mintákat a hibák kecses kezeléséhez. Ezek a gyakorlatok különösen fontosak 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 bekövetkező műveletek, mivel a zónák vagy régiók közötti feladatátvétel gyakran 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. A megoldástervezők és az üzleti érdekelt felek közötti megbeszéléseknek meg kell felelniük ezeknek a követelményeknek.

Kockázattűrés

A különböző szervezetek eltérő mértékű kockázattűrést mutatnak. A kockázattűrés még egyetlen szervezeten belül is gyakran különbözik számítási feladatoktól. A legtöbb számítási feladat nem igényel rendkívül magas rendelkezésre állást. Egyes számítási feladatok azonban olyan kritikus fontosságúak, hogy érdemes enyhíteni a még nem valószínű kockázatokat is, például a nagy földrajzi területet érintő súlyos természeti katasztrófákat.

Az alábbi táblázat felsorol néhányat a felhőkörnyezetekben 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ésekkel - 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árosi terület egy részén	Közepes
Régiókimaradás	- Jelentős természeti katasztrófa, amely nagy 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	Low

Ideális megoldás minden számítási feladat lehetséges kockázatának csökkentésére. Ez a megközelítés azonban 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 kockázatokkal kapcsolatban, amelyeket enyhíteni kell.

Jótanács

A megbízhatósági céloktól függetlenül minden számítási feladatnak rendelkeznie kell valamilyen vészhelyreállítási (DR) kockázatcsökkentéssel. 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. Más számítási feladatok esetén megalapozott döntést kell hozni arról, hogy mely kockázatok elfogadhatók, és mely kockázatoknak kell mérséklést igényelnie.

Megbízhatósági követelmények

Fontos tisztában lenni a számítási feladat megbízhatósági követelményeivel, például a helyreállítási célok, például a helyreállítási idő célkitűzéseinek (RTO) és a helyreállítási pont célkitűzéseinek (RPO) elfogadásával. A megbízhatósági követelmények 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ót a folyamatok azonosítására és minősítésére vonatkozó architektúrastratégiákban talál.

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 van egy üzleti követelmény, amely szerint a megoldásnak 99,9%-os% üzemidőt kell biztosítania.

Az Azure szolgáltatásszintű szerződéseket (SLA-kat) biztosít minden szolgáltatáshoz. Az SLA jelzi a szolgáltatástól elvárt üzemidő szintjét, valamint azokat a feltételeket, amelyeknek meg kell felelnie ahhoz, hogy elérhesse a várt SLA-t. Ne feledje azonban, hogy az Azure SLA szolgáltatás rendelkezésre állásának meghatározása nem mindig felel meg a számítási feladat állapotának értékelésének.

Az architekturális döntések hatással vannak a megoldás összetett SLO -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ásokra vonatkozó SLA-kat, hogy biztosan 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 vezet be 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.

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ói hely

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. Fontos azonban megfontolnia, hogy egy egyrégiós üzembe helyezés megfelel-e a megbízhatósági követelményeinek. 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 a globális Azure-lábnyom segítségével 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 mintáját vagy a Geodes-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. Gondolja át, 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 további erőforrások kezelésének működési költségeit és egy összetettebb környezetet is magukban foglalhatnak.

Bonyolultsá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. Győződjön meg arról, hogy az egyszerűség elvét követi.

Példaforgatókönyv

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. Minden megközelítés konkrét előnyöket biztosít, é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 olyan új megoldást szeretne üzembe helyezni, amely tartalmaz egy olyan alkalmazást, amely adatokat ír valamilyen tárolóba.

Ez a példa nem konkrét Azure-szolgáltatásokra vonatkozik. Ez egy példa 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 szintű helyileg redundáns, zónaszintű (rögzített), zónaredundáns, vagy többrégiós üzembe helyezést. Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Helyileg redundáns	Övezeti (rögzített)	Zone-redundant	többrégiós
Reliability	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ényhaté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ési 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

Az alábbi táblázat összefoglalja a használható megközelítések némelyikét, valamint azt, hogy ezek hogyan befolyásolják az architektúrát.

Architekturális probléma	Helyileg redundáns	Övezeti (rögzített)	Zone-redundant	többrégiós
Az adatrezidencia megfelelősége	High	High	High	A régiótól függ
Regionális rendelkezésre állás	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	A 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. Telepítési megközelítés: Helyileg redundáns telepítések

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 kezelt 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 a teljesítménycsökkenés azonban nem okoz gondot a legtöbb számítási feladat számára.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	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ényhaté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. Előfordulhat, hogy az összetevők különböző rendelkezésre állási zónákban találhatók, így a nagy késésre érzékeny összetevők alacsonyabb teljesítményt tapasztalhatnak.
Működési 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.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	Magas. Ez a megközelítés bármely Azure-régióban használható.

Helyi redundanciájú telepítések 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.

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 infrastruktúra kódként (IaC) történő megközelítésével, 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 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 a helyreállítási pontként ismert adatvesztés mértékét. Általában szabályozhatja a biztonsági mentések gyakoriságát, hogy megfeleljen az RPO-nak.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	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ényhaté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. Előfordulhat, hogy az összetevők különböző rendelkezésre állási zónákban találhatók, így a nagy késésre érzékeny összetevők alacsonyabb teljesítményt tapasztalhatnak.
Működési kiválóság	A régión belüli üzemkimaradások során:Alacsony működési hatékonyság. Feladatátvétel az Ön feladata, és manuális műveleteket és ismételt üzembe helyezéseket igényelhet.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	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

Egy zóna szintű telepítés során meg kell határoznia, hogy az erőforrásokat egy adott rendelkezésre állási zónában kell telepíteni. 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í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. Megfontolhatja egy globális terheléselosztó használatát is, például Azure Front Door vagy Azure Traffic Manager, amely egyáltalán nincs üzembe helyezve egy régióban.

A zonális üzemi modell használata során számos felelősséget 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 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 metró DR-nek is nevezik.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	- 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. - 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özpontokkal vagy a rendelkezésre állási zónák kimaradásokkal szemben.
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 csak az egyes erőforrások egyetlen példánya szükséges. - Több rendelkezésre állási zónában ü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ényhaté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ési 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 kiesése során a feladatátvétel az Ön feladata.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	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 rendelkezésre állási zónákat.

Ezt a módszert általában virtuális gépeken (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ásicí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. Az egyes rendelkezésre állási zónákban elérhető virtuálisgép-termékváltozatok listáját a virtuálisgép-termékváltozat rendelkezésre állásának ellenőrzése című témakörben találja.

Jótanács

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. telepítési megközelítés: zónaredundáns telepítések

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ó az egyes rendelkezésre állási zónák példányai között szórja el a kéréseket. Maga a szolgáltatás a rendelkezésre állási zónákra terjed ki. Ha egy rendelkezésre állási zóna üzemkimaradást tapasztal, a terheléselosztó a forgalmat a működőképes 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ós. Amikor az alkalmazás módosítja az adatokat, a tárolási szolgáltatás több rendelkezésre állási zónába írja a módosítást. 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 up-to-date másolatot készítsen 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 replikálása történik, 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ónaközi 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.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	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, késleltetés 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ényhaté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ési 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.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	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 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, az Azure App Service-t, az Azure Functionst, az Azure Kubernetes Service-t (AKS), az Azure Storage-t, az Azure SQL-t, az Azure Service Bust és 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ásicímű témakörben találja.

Zónaredundáns telepítések 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 nagyszabású katasztrófa esetén gyorsan újra telepíthesse egy másik régióban. Győződjön meg arról, hogy az üzembehelyezési eszközök és folyamatok olyan 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 a helyreállítási pontként ismert adatvesztés mértékét. Az RPO-nak való megfelelés érdekében általában szabályozhatja a biztonsági mentések gyakoriságát.

Jótanács

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.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	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, 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ényhaté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ési 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.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	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 rendelkezésre állási zónákat.

4. telepítési megközelítés: Többrégiós telepítések

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 annak kockázatát is, hogy egy adott régióban ideiglenes 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 feladatok esetében érdemes több régióval egyidejű aktív feldolgozást végezni (aktív-aktív kiépítések). 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 az átváltáshoz (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álás

A régiók közötti kommunikáció sokkal lassabb, mint a 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ésével kapcsolatos további információkért tekintse meg az Azure-hálózat utazási késési statisztikáit.

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 a módosítás replikálása előtt egy másik régióba.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	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ényhaté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ési 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.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	Számos Azure-régió párosítva van. Egyes Azure-szolgáltatások párosított régiókat használnak az adatok automatikus replikálásához. Ha olyan régióban futtatja a számítási feladatot, amely nem rendelkezik pár, akkor lehet, hogy egy eltérő megközelítést kell alkalmaznia 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.

Az alábbi táblázat összefoglalja az alappillérek néhány aggályát.

Pillér	Hatás
Reliability	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 ha egy teljes régió meghibásodik is, az adatok teljesek maradnak, és egy másik régióban is elérhetők maradnak.
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ényhaté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ési 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.

Az alábbi táblázat az architektúra szempontjából összefoglal néhány aggályt.

Architekturális probléma	Hatás
Az adatrezidencia 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 rendelkezésre állás	Számos Azure-régió párosítva van. Egyes Azure-szolgáltatások párosított régiókat használnak az adatok automatikus replikálásához. Ha olyan régióban futtatja a számítási feladatot, amely nem rendelkezik pár, akkor lehet, hogy egy eltérő megközelítést kell alkalmaznia 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. A 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 olyan funkciók használatát, mint a 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 nyilatkozatokat 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 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.

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 be kell állítania a rendelkezésre állási zóna konfigurációját az erőforrás első üzembe helyezésekor, míg más szolgáltatá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özpont.

Példák az esetre

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 (LOB) 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észeknek a lehető legkevesebb állásidőre és adatvesztésre van szükségük a rendszernek. 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 azért is aggodalomra adnak okot, mert 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: Ebben a számítási feladatban 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 történő kimaradás ideiglenesen elérhetetlenné teheti az alkalmazást.

Javasolt megközelítések:

• Helyileg redundáns üzembe helyezés régiók közötti biztonsági másolatokkal, a legalacsonyabb költségekkel jár, de jelentős kockázatokkal is jár.

• Zónaredundáns üzembe helyezés régiók közötti biztonsági mentéssel jobb ellenállóképességet biztosít, de valamivel magasabb költséggel jár.

Hagyományos alkalmazásmigrálás

A Fabrikam, Inc. egy örökölt alkalmazást migrál egy helyszíni adatközpontból az Azure-ba. Virtuális gépeken alapuló IaaS-megközelítést terveznek használni. Az alkalmazás nem felhőkörnyezethez készült, é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 Fabrikamnak először zónaredundáns üzembe helyezést kellene megpróbálnia. 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ó, akkor érdemes megfontolni egy 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öbbrégiós többzóná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, érdemes megfontolniuk egy zónaredundáns üzembe helyezést vagy egy zónaredundáns üzembe helyezést, amely biztonsági mentést biztosít az egyrégiós megoldást biztosító régiók között.

Bankrendszer

A Woodgrove Bank az Azure-ban üzembe helyezett nagy megoldásból futtatja alapvető banki műveleteit.

Üzleti követelmények: Ez a rendszer kritikus fontosságú. 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 többzónás többrégiós üzembe helyezést kell használniuk, és biztosítaniuk kell, hogy a régiók megfeleljenek a vállalat adattárolási követelményeinek.

Szoftver mint szolgáltatás

A Proseware, Inc. olyan szoftvereket fejleszt, amelyeket a vállalatok világszerte 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 szolgáltatott szoftver (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 globális forgalomgyorsító megoldással, például az Azure Front Doornal.

Következő lépések

A következő referenciaarchitektúrák és példaforgatókönyvek többzónás és többrégiós megoldásokhoz használhatók:

• 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
• Többrétegű webalkalmazás magas rendelkezésre álláshoz és dr.

A következő Azure-szolgáltatások használatával több rendelkezésre állási zónában valósíthat meg megoldásokat:

• Azure Site Recovery: Az Azure-beli virtuális gépek dr. állapotá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