Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az Azure Well-Architected-keretrendszer megbízhatósági ellenőrzőlistájára vonatkozó javaslat:
| RE:05 | Adjon hozzá redundanciát különböző szinteken, különösen a kritikus folyamatokhoz, hogy megfeleljen a megbízhatósági céloknak. Fontolja meg a redundáns infrastruktúra-összetevőket, például a számítást és a hálózatot, valamint a megoldás több példányát. |
|---|
Ez az útmutató ismerteti azokat a javaslatokat, amelyek a különböző számítási feladatok rétegeihez tartozó kritikus folyamatok redundanciájának hozzáadására szolgálnak, ami optimalizálja a rugalmasságot. A meghatározott megbízhatósági célok követelményeinek való megfeleléshez alkalmazza a megfelelő redundanciaszinteket a számítási, adat-, hálózatkezelési és egyéb infrastruktúraszintekre. Használja ezt a redundanciát, hogy a munka erős, megbízható alapot kapjon, amire építhet. Ha infrastruktúra-redundancia nélkül hozza létre a számítási feladatokat, a lehetséges hibák miatt nagy a kockázata a hosszabb állásidőnek.
Definíciók
| Kifejezés | Definíció |
|---|---|
| Redundancia | Egy számítási feladat összetevő több azonos példányának implementálása. |
| Régió | Egy Azure-adatközpont helye. |
| Többplatformos adatmegőrzés | A különböző tárolási technológiák ugyanazon alkalmazással vagy megoldással történő használatának fogalma az egyes összetevők legjobb képességeinek kihasználásához. |
| Adatkonzisztencia | Egy adott adathalmaz szinkronban levésének vagy nincs szinkronban levésének mértéke több áruházban. |
| Particionálás | Az adatok külön adattárakba való fizikai felosztásának folyamata. |
| Szilánk | Horizontális adatbázisparticionálási stratégia, amely több, közös sémával rendelkező tárpéldányt támogat. Az adatok nem replikálódnak minden példányban. |
A megbízhatóság érdekében a redundancia használatával korlátozza azokat a problémákat, amelyek egyetlen erőforrást érintenek, és biztosítsa, hogy ezek a problémák ne befolyásolják a teljes rendszer megbízhatóságát. Az egyes folyamatok redundanciához szükséges megalapozott döntések meghozatalához használja a kritikus folyamatokra és a megbízhatósági célokra vonatkozó információkat.
Előfordulhat például, hogy egyszerre több webkiszolgáló-csomópont is fut. Ha az általuk támogatott folyamat kritikus, minden csomópontnak szüksége lehet olyan replikákra, amelyek azonnal fogadják a forgalmat, ha egy probléma a teljes készletet érinti, például egy teljes adatközpont-leállást. Alternatív megoldásként, mivel a nagy léptékű problémák ritkán fordulnak elő, és költséges a replikák teljes készletének üzembe helyezése, korlátozott számú replikát helyezhet üzembe, hogy a folyamat csökkentett állapotban működjön, amíg meg nem oldja a problémát.
Ha a teljesítményhatékonyság kontextusában tervez redundanciát, ossza el a terhelést több redundáns csomópont között, hogy az egyes csomópontok optimálisan teljesíthessenek. A megbízhatóság kontextusában építsen tartalék kapacitást az egy vagy több csomópontot érintő hibák vagy meghibásodások elnyelésére. Győződjön meg arról, hogy a tartalék kapacitás az érintett csomópontok helyreállításához szükséges teljes időre képes elnyelni a hibákat. Ezt a különbséget szem előtt tartva mindkét stratégiának együtt kell működnie. Ha a forgalom két csomópont között oszlik el a teljesítmény szempontjából, és mindkettő 60% kihasználtságnál fut, és egy csomópont meghibásodik, a fennmaradó csomópont túlterheltté válik, mert nem működik 120%. Ossza meg a terhelést egy másik csomópont között, hogy a teljesítmény- és megbízhatósági célok teljesüljenek.
Kompromisszumok:
A több számítási feladat redundancia több költséggel egyenlő. Körültekintően vegye fontolóra a redundancia hozzáadását, és rendszeresen tekintse át architektúráját, hogy biztosítsa a költségek kezelését, különösen akkor, ha túlméretezést használ. Ha rugalmassági stratégiaként túlméretezést használ, egyensúlyozza ki azt egy jól meghatározott skálázási stratégiával, a költséghatékonyság minimalizálása érdekében.
Nagy mértékű redundancia esetén teljesítménybeli kompromisszumok is lehetnek. A rendelkezésre állási zónákban vagy helyeken szétterjedő erőforrások például hatással lehetnek a teljesítményre, mert a forgalmat a redundáns erőforrások, például webkiszolgálók vagy adatbázispéldányok közötti nagy késésű kapcsolatokon keresztül kell elküldeni.
Az ugyanazon számítási feladaton belüli különböző folyamatok eltérő megbízhatósági követelményekkel rendelkezhetnek. A folyamatspecifikus redundanciatervek összetettebbé tehetik a teljes kialakítást.
Az alacsony késésű redundancia kialakítása azt jelenti, hogy elfogadja az összetevők elvesztésének kockázatát egy olyan nagy méretű esemény, például egy földrajzi katasztrófa esetén, amely minden példányt offline állapotba hoz. A földrajzilag távoli vészhelyreállítási (DR) környezet segít csökkenteni ezt a kockázatot, de növeli a költségeket.
A kiszolgáló nélküli és a teljes körűen felügyelt szolgáltatások előnyben részesítve a működési terheket
Használja ki a kiszolgáló nélküli, a szolgáltatásként nyújtott szoftver (SaaS) és a szolgáltatásként nyújtott platform (PaaS) megoldásokat, hogy egyszerűen bővítse a redundanciát a számítási feladathoz anélkül, hogy kezelnie kellene az adatreplikációt vagy a feladatátvételi műveleteket. Ezek a szolgáltatások transzparens módon valósítják meg a redundanciát, ami megszünteti a saját redundanciamechanizmusok tervezésének és fenntartásának működési terheit. A szolgáltatásbeállítások kiértékelésekor rangsorolja a redundanciát automatikusan kezelő felügyelt szolgáltatásokat a manuális redundanciakonfigurációt igénylő infrastruktúra-alapú megközelítésekkel szemben.
Az Azure által felügyelt szolgáltatások különböző modelleken keresztül biztosítanak redundanciát. Minden modell különböző absztrakciós szinteket és működési egyszerűséget biztosít.
Beépített redundanciával rendelkező globális szolgáltatások: Az olyan szolgáltatások, mint a Microsoft Entra ID, az Azure DNS és az Azure Key Vault, globális szolgáltatásként működnek, több régióban automatikus redundanciával. Ezek a szolgáltatások belső rugalmasságot biztosítanak anélkül, hogy redundanciakonfigurációt kellene igényelnie Öntől. A feladatátvételi és helyreállítási forgatókönyveket automatikusan transzparensen kezelik.
Absztrakciós kapacitásmodellek: Az olyan ajánlatok, mint az Azure Cosmos DB, az Azure Databricks és az Azure OpenAI által felügyelt végpontok absztrakciója a mögöttes infrastruktúra összetettségét a kapacitásegységek, a DTU-k vagy más logikai metrikák mögött. Ezek a szolgáltatások automatikusan elosztják a számítási feladatokat több példány, zóna és régió között, miközben egyszerűsített számlázási és felügyeleti modellt mutatnak be. Az egyes redundáns példányok kezelése helyett kapacitási követelményeket kell megadnia.
A megoldás kialakításakor az infrastruktúra-alapú redundancia implementálása előtt értékelje ki, hogy létezik-e felügyelt szolgáltatáslehetőség az egyes összetevőkhöz. A felügyelt szolgáltatások csökkentik az üzemeltetési többletterhelést, és gyakran robusztusabb redundancia-implementációkat biztosítanak, mint az egyéni megoldások, bár az irányítás terén kompromisszumot vonhatnak maguk után, és az egyes kapacitásegységek költségei is magasabbak lehetnek.
Redundancia létrehozása a számítási feladatba több összetevőpéldány használatával
Az infrastruktúra-összetevők és -szolgáltatások több példányának üzembe helyezése a számítási feladat igényeinek megfelelő rugalmasság érdekében. Ez az alapvető redundanciastratégia biztosítja, hogy ha egy példány meghibásodik, a többi példány továbbra is kezelni tudja a számítási feladatot. Több példányt is elérhet különböző megközelítésekkel. Egyes forgatókönyvek megkövetelik, hogy manuálisan konfigurálja a redundanciát több erőforrás egyenkénti üzembe helyezésével, például több Azure ExpressRoute-kapcsolatcsoporttal vagy az Azure Traffic Manager több régióban történő konfigurálásával. Más szolgáltatások úgy vannak kialakítva, hogy közvetlenül több példányt is támogassanak, például az Azure Virtual Machine Scale Sets öt példányra való beállítását vagy az Azure App Service 10 példány futtatására való konfigurálását. Ha lehetséges, előnyben részesítse azokat a szolgáltatásokat, amelyek több példány beépített támogatását és automatikus skálázási képességeket biztosítanak, mivel leegyszerűsítik a redundanciakezelést, és a megbízhatósági és teljesítményigényekre is reagálhatnak.
Redundáns infrastruktúra-összetevők telepítésekor határozza meg, hogy az egyes összetevők hány példánya felel meg a megbízhatósági céloknak. Fontolja meg, hogy az összes összetevő több példányára vagy csak meghatározott kritikus összetevőkre van-e szüksége, és határozza meg ezeknek a példányoknak a földrajzi eloszlását a rugalmassági követelményeknek való megfelelés érdekében. Redundáns infrastruktúra üzembe helyezésekor vegye figyelembe az alábbi javaslatokat.
Számítási erőforrások:
A beépített redundancia támogatásával rendelkező szolgáltatásokat részesíti előnyben. Ezek a szolgáltatások lehetővé teszik a szükséges példányok számának megadását, és kezelheti a példányok terjesztését és kezelését.
Tartsa a számítási réteget mentesen minden állapottól, mert a kéréseket kiszolgáló egyes csomópontok bármikor törölhetők, meghibásodhatnak vagy lecserélhetők.
A skálázási stratégiát úgy tervezheti meg és tesztelheti, hogy megfeleljen a redundancia megközelítésének.
Adaterőforrások:
Adatok replikálása földrajzi régiók között, hogy rugalmasságot biztosítson a regionális kimaradásokkal és a katasztrofális hibákkal szemben.
Ismerje meg a használt állapotalapú platformszolgáltatások beépített replikációs és redundanciaképességeit .
Határozza meg, hogy szükség van-e szinkron vagy aszinkron adatreplikálásra a számítási feladat működéséhez. További információ: Rendelkezésre állási zónák és régiókhasználatára vonatkozó javaslatok.
A földrajzilag honosított hibák hatásának minimalizálása érdekében terjessze el az adatokat földrajzilag, a szolgáltatás által támogatott módon.
Automatizálhatja a feladatátvételt egy adatbázispéldány meghibásodása után. Az automatizált feladatátvételt több Azure PaaS-adatszolgáltatásban is konfigurálhatja. Nem szükséges automatizált feladatátvétel a többrégiós írást támogató adattárakhoz, például az Azure Cosmos DB-hez. További információkért lásd a DR-stratégia tervezésére vonatkozó javaslatokat.
Használja az adataihoz a legjobb adattárt. Használja a többplatformos adatmegőrzést vagy az adattártechnológiák kombinációját használó megoldásokat. Az adatok nem csak a tárolt alkalmazásadatokat tartalmazzák. Emellett alkalmazásnaplókat, eseményeket, üzeneteket és gyorsítótárakat is tartalmaz.
Vegye figyelembe az adatkonzisztencia követelményeit, és használja végleges konzisztencia, amikor a követelmények lehetővé teszik. Az adatok elosztásakor a megfelelő koordinációval kényszerítse ki az erős konzisztenciára vonatkozó garanciákat. A koordináció csökkentheti az átviteli sebességet, és szorosan összekapcsolhatja a rendszereket, ami gyengébbé teheti őket. Ha például egy művelet két adatbázist frissít, ahelyett, hogy egyetlen tranzakciós hatókörbe helyezné, jobb, ha a rendszer képes a végleges konzisztenciára.
Particionálási adatok a rendelkezésre álláshoz. adatbázis particionálási javítja a méretezhetőséget, és a rendelkezésre állást is javíthatja. Ha az egyik szegmens leesik, a többi szegmens továbbra is elérhető. Egy szegmens meghibásodása csak a teljes tranzakciók egy részhalmazát zavarja meg.
Ha a horizontális skálázás nem lehetőség, a Command Query Responsibility Szegregáció (CQRS) mintával elválaszthatja az írásvédett és írásvédett adatmodelleket. Adjon hozzá több redundáns írásvédett adatbázispéldányt, hogy nagyobb rugalmasságot biztosítson.
Hálózati erőforrások:
Megbízható és méretezhető hálózati topológia kiválasztása. Küllős modell vagy Azure Virtual WAN-modell használatával a felhőinfrastruktúra olyan logikai mintákba rendezhető, amelyek megkönnyítik a redundancia kialakítását és méretezését.
Válassza ki a megfelelő hálózati szolgáltatás a kérések régiókon belüli vagy régiók közötti elosztásához és átirányításához. Ha lehetséges, használjon globális vagy zónaredundáns terheléselosztási szolgáltatásokat a megbízhatósági célok eléréséhez.
Győződjön meg arról, hogy elegendő IP-címteret foglalt le a virtuális hálózatokban és alhálózatokban a tervezett használat figyelembe vételéhez, beleértve a vertikális felskálázási követelményeket is.
Győződjön meg arról, hogy az alkalmazás méretezhető a választott alkalmazás-üzemeltetési platform portkorlátjai között. Ha egy alkalmazás több kimenő átviteli vezérlési protokollt (TCP) vagy User Datagram Protocol-kapcsolatot (UDP) kezdeményez, az az összes elérhető portot kimerítheti, és gyenge alkalmazásteljesítményt okozhat.
Válassza ki az SKU-kat, és konfiguráljon olyan hálózati szolgáltatásokat, amelyek megfelelnek a sávszélességre és a rendelkezésre állásra vonatkozó követelményeknek. A VPN-átjáró átviteli sebessége az SKU-juktól függően változik. A zónaredundancia támogatása csak bizonyos terheléselosztó termékváltozatokhoz érhető el.
Győződjön meg arról, hogy a tartománynévrendszer (DNS) kezelésére szolgáló terv a rugalmasságra összpontosít, és támogatja a redundáns infrastruktúrát.
Az Üzembehelyezési bélyegek mintával egyszerűsítheti a redundancia-megközelítést
Az egyes infrastruktúra-összetevők és -szolgáltatások redundancián túl a redundanciastratégiát a számítási feladatok szintjére is kiterjesztheti a teljes számítási feladat vagy logikai erőforráscsoport több példányának üzembe helyezésével. Kövesse az Üzembehelyezési bélyegek tervezési mintáját , és hozzon létre megismételhető, önálló egységeket, amelyek tartalmazzák a számítási feladatnak a felhasználók vagy követelmények egy adott részhalmazához való biztosításához szükséges összes erőforrást.
Az üzembehelyezési bélyegek az összetevőszintről a számítási feladatszintű redundanciára való váltást jelölik. Minden egyes bélyeg egy teljes skálázási egység, amely az összes szükséges erőforrást – számítást, tárolást, hálózatkezelést és függőséget – tartalmazza, amelyek egymástól függetlenül működhetnek. Ez a megközelítés kulcsfontosságú előnyöket biztosít, beleértve a robbanási sugarat tartalmazó izolált hibatartományokat, az egyes összetevők skálázása helyett a horizontális skálázást, a földrajzi hely vagy követelmények szerinti rugalmas szegmentálást, valamint az azonos megismételhető egységeken keresztüli egyszerűsített műveleteket.
Függetlenül attól, hogy bélyegeket helyez üzembe egy aktív-aktív modellben (ahol az összes bélyeg egyszerre szolgálja ki a forgalmat) vagy az aktív-passzív modellt (ahol az egyik bélyeg a forgalmat szolgálja, míg mások készenléti állapotban maradnak), úgy tervezze meg az egyes bélyegeket, hogy egy teljes, önellátó üzembe helyezés legyen, amely önállóan képes kezelni a kijelölt számítási feladatot.
Nulla állásidő elérése aktív-aktív redundancián keresztül
Az aktív-aktív üzemelő példányok maximalizálják a szolgáltatások rendelkezésre állását, ha egyszerre több számítási feladatot futtatnak, és mindegyik aktívan kezeli a forgalmat. Ez a beállítás biztosítja az azonnali feladatátvételt, kiküszöböli az állásidőt, és optimalizálja az erőforrás-használatot az összes példány hatékonyságának megőrzésével. Ha egy példány meghibásodik, a rendszer automatikusan átirányítja a forgalmat az kifogástalan állapotú példányokra a szolgáltatás megzavarása nélkül.
Egy e-kereskedelmi platform például a főszezonban akkor is képes zökkenőmentes működést fenntartani, ha egy üzembe helyezés során problémák merülnek fel. Az aktív-aktív konfigurációk ideálisak olyan kritikus fontosságú számítási feladatokhoz, amelyek folyamatos rendelkezésre állást igényelnek, de magasabb infrastrukturális költségekkel és összetettséggel rendelkeznek. Speciális üzemeltetési stratégiákra van szükség több élő környezet kezeléséhez, az adatok konzisztenciájának biztosításához és a frissítések koordinálásához minden példányban.
A következő szakaszok az aktív-aktív üzemelő példányok konfigurációs beállításait ismertetik.
Aktív-aktív kapacitás: Tükrözött üzembehelyezési bélyegek két vagy több helyen, amelyek mindegyike az általuk kiszolgált helyek vagy helyek éles számítási feladatainak kezelésére van konfigurálva, és skálázható a más helyekről érkező terhelések kezelésére regionális kimaradás esetén.
Hálózati:Használjon késést vagy súlyozott globális útválasztást a helyek közötti forgalom elterjesztéséhez.
Adatreplikálás és konzisztencia: A többrégiós olvasási és írási képességekhez használjon globálisan elosztott adattárat, például az Azure Cosmos DB-t . Relációs adatbázisok esetén használjon olvasható másolatokat csak olvasható kapcsolati sztringekkel.
A kialakítás előnye: Alacsonyabb üzemeltetési költségek, mint a túlterjedt kialakítás.
Ennek a kialakításnak a hátránya: A felhasználói élmény lehetséges romlása a teljes terhelés igényeinek való megfelelés érdekében történő felskálázáskor, ha egy másik helyen leállás történik.
Aktív-aktív túlterjedt: Tükrözött üzembehelyezési bélyegek két vagy több helyen, amelyek mindegyike túlterhelt az általuk kiszolgált hely vagy helyek éles számítási feladatainak kezelésére, valamint a más helyekről érkező terhelések kezelésére regionális kimaradás esetén.
Hálózati:Használjon késést vagy súlyozott globális útválasztást a helyek közötti forgalom elterjesztéséhez.
Adatreplikálás és konzisztencia: A többrégiós olvasási és írási képességekhez használjon globálisan elosztott adattárat, például az Azure Cosmos DB-t . Relációs adatbázisok esetén használjon olvasható másolatokat csak olvasható kapcsolati sztringekkel.
A kialakítás előnye: A lehető legrugalmasabb kialakítás.
Ennek a kialakításnak a hátránya: Magasabb üzemeltetési költségek, mint a méretezhető kialakítás.
Mindkét kialakítás gyakori előnyei: Nagy rugalmasság és alacsony a számítási feladatok teljes kimaradásának kockázata.
Mindkét kialakítás gyakori hátrányai: A különböző tényezők miatt magasabb üzemeltetési költségek és felügyeleti terhek, beleértve az alkalmazásállapot és az adatok szinkronizálásának kezelését is.
Aktív-passzív architektúraterv használata költséghatékony DR-megközelítésként
Az aktív-passzív üzembehelyezési konfigurációk költséghatékony megoldást nyújtanak a dr. vészhelyreállítás biztosítására egy olyan elsődleges példány futtatásával, amely az összes forgalmat kezeli, miközben a másodlagos példányok tétlenek maradnak, de készen állnak. Ezek a készenléti példányok csak akkor aktiválódnak, ha az elsődleges példány meghibásodik vagy karbantartáson megy keresztül. Ez a megközelítés minimálisra csökkenti az erőforrás-használatot, miközben megbízható feladatátvételi képességeket biztosít.
Egy pénzügyi kereskedési platform például ezt a beállítást használhatja a szolgáltatás folytonosságának fenntartásához. Az elsődleges rendszer kezeli az összes tranzakciót, míg a másodlagos rendszer szinkronizálva marad a háttérben. Ha az elsődleges rendszer leáll, a másodlagos rendszer gyorsan átveszi és visszaállítja a műveleteket minimális megszakítással. Ez a megközelítés kiegyensúlyozza a megbízhatóságot és a költségeket, ami ideálissá teszi olyan számítási feladatokhoz, amelyek az aktív-aktív üzemelő példányok összetettsége vagy költsége nélkül képesek eltűrni a rövid helyreállítási időt.
Fontolja meg a következő konfigurációs beállításokat az aktív-passzív üzemelő példányokhoz.
Meleg tartalék: Egy elsődleges hely és egy vagy több másodlagos hely. A másodlagos hely a lehető legkisebb számítási és adatméretezéssel van üzembe helyezve, és terhelés nélkül fut. Ezt a helyet meleg tartalék helynek nevezzük. A feladatátvételt követően a számítási és adaterőforrások skálázva lesznek az elsődleges helyről érkező terhelés kezelésére.
Hálózati:Használjon prioritású globális útválasztást.
Adatreplikálás és konzisztencia: Replikálja az adatbázist a passzív helyre, és használja az olyan PaaS-megoldások automatikus feladatátvételi képességeit, mint az Azure Cosmos DB és az Azure SQL Database.
A kialakítás előnye: Az aktív-passzív kialakítások közül a legrövidebb helyreállítási idő.
Ennek a kialakításnak a hátránya: A legmagasabb üzemeltetési költség az aktív-passzív kialakítások között.
Hideg tartalék: Egy elsődleges hely és egy vagy több másodlagos hely. A másodlagos hely a teljes terhelés kezelésére van skálázva, de minden számítási erőforrás leáll. Ezt a helyet hideg tartalék helynek nevezik. A feladatátvétel előtt el kell indítania az erőforrásokat.
Hálózati:Használjon prioritású globális útválasztást.
Adatreplikálás és konzisztencia: Replikálja az adatbázist a passzív helyre, és használja az olyan PaaS-megoldások automatikus feladatátvételi képességeit, mint az Azure Cosmos DB és az SQL Database.
A kialakítás előnye: Alacsonyabb üzemeltetési költségek, mint a meleg tartalék kialakítás.
Ennek a kialakításnak a hátránya: Hosszabb helyreállítási idő, mint a meleg tartalék kialakítás.
Számítási feladatok elosztása a proximán független infrastruktúra között
A számítási feladatok közeli független adatközpontokban vagy adatközpont-szektorokban való üzembe helyezése redundanciát biztosít a teljesítmény veszélyeztetése nélkül. A földrajzilag közeli, de fizikailag különálló létesítmények használatával ez a beállítás minimális késéssel biztosítja a hibaelkülönítést. Biztosítja az elosztott infrastruktúra rugalmasságát, miközben fenntartja az egyhelyes üzembe helyezés válaszkészségét. Az Azure-ban a rendelkezésre állási zónák biztosítják ezt a funkciót. A rendelkezésre állási zónák fizikailag független adatközpontok vagy adatközpont-szektorok, amelyek lehetővé teszik a hibatűrő, alacsony késésű számítási feladatok egyszerű üzembe helyezését.
A késésre érzékeny alkalmazások, például a valós idejű játékok esetében ez a megközelítés zökkenőmentes feladatátvételt és folyamatos felhasználói élményt tesz lehetővé. A helyi adatközpontok között elosztott játékkiszolgálók azonnal átirányíthatják a forgalmat a kimaradások során, átlátható terheléselosztással és közel valós idejű adatreplikálással megőrizve a játékmenet folytonosságát. Ez a stratégia azonban kockázatot jelent, mivel a nagy méretű regionális események továbbra is hatással lehetnek az összes helyszínre egyszerre.
Hibatűrés megerősítése földrajzilag távoli üzembe helyezésekkel
A földrajzilag elosztott adatközpontok közötti üzembe helyezés a legnagyobb védelmet nyújtja a nagy méretű katasztrófák ellen a számítási feladatok régiók közötti több száz vagy több ezer mérföldes szétosztásával. Ez a megközelítés biztosítja az üzletmenet folytonosságát olyan események során, mint a természeti katasztrófák, az infrastruktúra hibái vagy a teljes nagyvárosi területeket érintő geopolitikai zavarok. Az Azure-ban számítási feladatokat helyezhet üzembe olyan régiókban, amelyek világszerte elterjedtek. Ha ezt a tervezési módszert használja, válasszon olyan régiókat, amelyek közel vannak a felhasználókhoz, de földrajzilag távoliak, például az USA nyugati régiója és az USA keleti régiója.
Egy globális pénzügyi platform például zavartalan szolgáltatást tarthat fenn úgy, hogy a forgalmat nem érintett régiókba irányítja, ha egy terület jelentős leállást tapasztal. Ez a megközelítés maximalizálja a rugalmasságot, és támogatja a szabályozási megfelelőséget a joghatóságok között, de magasabb késést, összetett adatkonzisztencia-követelményeket és nagyobb működési többletterhelést vezet be. Ezeket a tényezőket gondosan mérlegelni kell a globális redundancia előnyeinek megfelelően.
Az Azure megkönnyítése
Az Azure-platform az alábbi műveletek végrehajtásával segít optimalizálni a számítási feladat rugalmasságát, és redundancia hozzáadását:
A többrégiós architektúra legjobb Azure-régióinak kiválasztásához nyújt segítséget az Azure-régiók kiválasztása útmutatóval.
Beépített redundanciát biztosít számos PaaS- és SaaS-megoldással, amelyek közül néhány konfigurálható.
Olyan globális felügyelt szolgáltatásokat biztosít, mint a Microsoft Entra ID, az Azure DNS és a Key Vault, amelyek transzparens módon implementálják a redundanciát konfiguráció nélkül.
Lehetővé teszi a régión belüli redundancia tervezését és megvalósítását a rendelkezésre állási zónák és a régiók közötti redundancia használatával.
Zónaredundáns számítási megoldásokat biztosít, például virtuálisgép-méretezési csoportokat, amelyek automatikusan egyenletesen elosztják a számítást a rendelkezésre állási zónák között a virtuális gépek (virtuális gépek) telepítésekor.
Replikaérzékeny terheléselosztási szolgáltatásokat biztosít, például az Azure Application Gatewayt, az Azure Front Doort és az Azure Load Balancert.
Könnyen implementált georeplikációs megoldásokat biztosít, például az SQL Database aktív georeplikálását . Valósítsa meg a globális elosztást és a transzparens replikációt az Azure Cosmos DB használatával. Az Azure Cosmos DB két lehetőséget kínál az ütköző írások kezelésére. Válassza ki a számítási feladathoz leginkább megfelelő lehetőséget.
Időponthoz kötött visszaállítási (PITR) képességeket biztosít számos PaaS-adatszolgáltatáshoz.
Csökkenti a portok kimerülését az Azure NAT Gateway vagy az Azure Firewall használatával.
DNS-specifikus Azure-beli könnyítés
Belső névfeloldási forgatókönyvek esetén használja az Azure DNS privát zónáit, amelyek beépített zónaredundanciával és georedundanciával rendelkeznek. További információ: Azure DNS privát zóna rugalmassága.
Külső névfeloldási forgatókönyvekhez használja az Azure DNS nyilvános zónáit, amelyek beépített zónaredundanciával és georedundanciával rendelkeznek.
A nyilvános és privát Azure DNS-szolgáltatások olyan globális szolgáltatások, amelyek ellenállnak a regionális kimaradásoknak, mivel a zónaadatok globálisan elérhetők.
A helyszíni és a felhőkörnyezetek közötti hibrid névfeloldási forgatókönyvekhez használja az Azure DNS Private Resolvert. Ez a szolgáltatás támogatja a zónaredundanciát, ha a számítási feladat olyan régióban található, amely támogatja a rendelkezésre állási zónákat. A zónaszintű kimaradás nem igényel műveletet a zóna helyreállítása során. A szolgáltatás automatikusan öngyógyít és visszaállítja az egyensúlyt, hogy kihasználja az egészséges zónákat. További információ az Azure DNS Private Resolver rugalmasságáról a részen található.
Egy hibapont kiküszöbölése és a régiók közötti rugalmasabb hibrid névfeloldás érdekében helyezzen üzembe két vagy több Privát Azure DNS-feloldót a különböző régiókban. A DNS-feladatátvétel feltételes továbbítási forgatókönyvben egy feloldó elsődleges DNS-kiszolgálóként való hozzárendelésével érhető el. A másik régióban lévő feloldót rendelje hozzá másodlagos DNS-kiszolgálóként. A DNS-feladatátvétel magánfeloldók használatával történő beállításáról további információk: .
Törlési védelem alkalmazása a redundancia megőrzése érdekében
A redundancia csak akkor segít, ha az azt biztosító összetevők a helyén maradnak. Az adattár, a DNS-zóna vagy a forgalom-útválasztási réteg véletlen törlése összecsukja a rugalmasságot, és teljes helyreállítási műveleteket kényszerít ki. Csökkentse az emberi hibák következményeit az Azure-erőforrásokon alkalmazott
Kompromisszum: A zárolások alkalmazása lelassítja a jogos helyreállítási műveleteket, és működési súrlódást okozhat. A zárolás az erőforrás törlését gátolja, de nem akadályozza a módosításokat vagy az adatokat az erőforráson belül. Kezelje a zárolásokat vékony biztonsági hálóként, amely kiegészíti, soha nem cseréli le, biztonsági mentéseket, replikációt és hozzáférés-szabályozást.
Példa
Többrégiós redundáns üzembe helyezésre példa: Alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás.
Az alábbi ábrán egy másik példa látható.
Kapcsolódó hivatkozások
A redundanciával kapcsolatos további információkért tekintse meg a következő erőforrásokat:
- Azure-régiók útmutatója
- Azure Storage-redundancia
- zónaredundáns tárolás
- SQL Database aktív georeplikálása
- Két felügyelt példány közötti replikáció konfigurálása
Megbízhatósági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.