Globálisan elérhető szolgáltatások tervezése az Azure SQL Database használatával
A következőre vonatkozik:
Azure SQL Database
Felhőszolgáltatások Azure SQL Database-beli létrehozásakor és üzembe helyezésekor aktív georeplikációs vagy feladatátvételi csoportokkal biztosít rugalmasságot a regionális kimaradásokkal és katasztrofális hibákkal szemben. Ugyanezzel a funkcióval globálisan elosztott, az adatokhoz való helyi hozzáférésre optimalizált alkalmazásokat hozhat létre. Ez a cikk a gyakori alkalmazásmintákat ismerteti, beleértve az egyes lehetőségek előnyeit és kompromisszumoit.
Megjegyzés:
Ha prémium szintű vagy üzletileg kritikus adatbázisokat és rugalmas készleteket használ, akkor a zónaredundáns üzembehelyezési konfigurációvá alakításával rugalmassá teheti őket a regionális kimaradásokkal szemben. Lásd: Zónaredundáns adatbázisok.
1. forgatókönyv: Két Azure-régió használata az üzletmenet folytonosságához minimális állásidővel
Ebben a forgatókönyvben az alkalmazások a következő jellemzőkkel rendelkeznek:
- Az alkalmazás aktív egy Azure-régióban
- Minden adatbázis-munkamenethez olvasási és írási hozzáférés (RW) szükséges az adatokhoz
- A késés és a forgalmi költségek csökkentése érdekében a webes réteget és az adatréteget össze kell csoportosítani
- Az állásidő alapvetően nagyobb üzleti kockázatot jelent ezen alkalmazások esetében, mint az adatvesztés
Ebben az esetben az alkalmazástelepítési topológia regionális katasztrófák kezelésére van optimalizálva, amikor az összes alkalmazásösszetevőnek együtt kell feladatátvételt végrehajtania. Az alábbi ábrán ez a topológia látható. A földrajzi redundancia esetében az alkalmazás erőforrásai az A és a B régióban vannak üzembe helyezve. A B régió erőforrásai azonban nem lesznek kihasználva, amíg az A régió meghibásodik. A két régió között feladatátvételi csoport van konfigurálva az adatbázis-kapcsolat, a replikáció és a feladatátvétel kezelésére. A webszolgáltatás mindkét régióban úgy van konfigurálva, hogy az írásvédett figyelő <feladatátvételi-csoportnév.database.windows.net> (1) használatával férhessen hozzá az adatbázishoz. Az Azure Traffic Manager a prioritási útválasztási módszer (2) használatára van beállítva.
Megjegyzés:
Az Azure Traffic Managert a jelen cikk egészében csak illusztrációs célokra használjuk. Bármilyen terheléselosztási megoldást használhat, amely támogatja a prioritásos útválasztási módszert.
Az alábbi ábra a kimaradás előtti konfigurációt mutatja be:
Az elsődleges régió leállása után az SQL Database észleli, hogy az elsődleges adatbázis nem érhető el, és az automatikus feladatátvételi szabályzat (1) paraméterei alapján elindítja a feladatátvételt a másodlagos régióba. Az alkalmazás SLA-jától függően konfigurálhat egy türelmi időszakot, amely szabályozza a kimaradás észlelése és maga a feladatátvétel közötti időt. Lehetséges, hogy az Azure Traffic Manager kezdeményezi a végpont feladatátvételét, mielőtt a feladatátvételi csoport elindítja az adatbázis feladatátvételét. Ebben az esetben a webalkalmazás nem tud azonnal újracsatlakozni az adatbázishoz. Az újracsatlakozások azonban automatikusan sikeresek lesznek, amint az adatbázis feladatátvétele befejeződik. A sikertelen régió visszaállításakor és online állapotának visszaállításakor a régi elsődleges automatikusan újracsatlakozik új másodlagosként. Az alábbi ábra a feladatátvétel utáni konfigurációt mutatja be.
Megjegyzés:
A feladatátvétel után lekötött összes tranzakció elveszik az újracsatlakozás során. A feladatátvétel befejezése után a B régióban lévő alkalmazás újracsatlakozhat, és újraindíthatja a felhasználói kérések feldolgozását. A webalkalmazás és az elsődleges adatbázis is a B régióban található, és továbbra is közösen találhatók.
Ha a B régióban kimaradás történik, az elsődleges és a másodlagos adatbázis közötti replikációs folyamat fel lesz függesztve, de a kettő közötti kapcsolat érintetlen marad (1). A Traffic Manager észleli, hogy a B régióhoz való kapcsolat megszakadt, és a 2. végponti webalkalmazást csökkentett (2) állapotúként jelöli meg. Ebben az esetben az alkalmazás teljesítményének nincs hatása, de az adatbázis nyilvánosságra kerül, ezért nagyobb az adatvesztés kockázata abban az esetben, ha az A régió egymás után meghiúsul.
Megjegyzés:
A vészhelyreállításhoz javasoljuk, hogy az alkalmazás üzembe helyezését két régióra korlátozza. Ennek az az oka, hogy az Azure legtöbb földrajzi régiója csak két régióval rendelkezik. Ez a konfiguráció nem védi meg az alkalmazást mindkét régió egyidejű katasztrofális meghibásodásától. Ilyen hiba esetén georedundáns visszaállítási művelettel helyreállíthatja az adatbázisokat egy harmadik régióban. További információkért tekintse meg az Azure SQL Database vészhelyreállítási útmutatóját.
A kimaradás mérséklése után a másodlagos adatbázis automatikusan újraszinkronizálódik az elsődleges adatbázissal. A szinkronizálás során az elsődleges teljesítmény befolyásolható. A konkrét hatás a feladatátvétel óta az új elsődlegesen beszerzett adatok mennyiségétől függ.
Megjegyzés:
A kimaradás mérséklése után a Traffic Manager magasabb prioritású végpontként megkezdi a kapcsolatok átirányítását az alkalmazáshoz az A régióban. Ha egy ideig meg szeretné tartani az elsődlegest a B régióban, ennek megfelelően módosítania kell a Traffic Manager-profil prioritási táblát.
Az alábbi ábra a másodlagos régióban történt kimaradást szemlélteti:
A tervezési minta fő előnyei a következők:
- Ugyanez a webalkalmazás mindkét régióban régióspecifikus konfiguráció nélkül van üzembe helyezve, és nem igényel további logikát a feladatátvétel kezeléséhez.
- Az alkalmazás teljesítményét nem befolyásolja a feladatátvétel, mivel a webalkalmazás és az adatbázis mindig együtt található.
A fő kompromisszum az, hogy a B régióban az alkalmazás erőforrásai az idő nagy részében kihasználatlanok.
2. forgatókönyv: Azure-régiók az üzletmenet folytonosságához a maximális adatmegőrzéssel
Ez a beállítás a következő jellemzőkkel rendelkező alkalmazásokhoz ideális:
- Az adatvesztés magas üzleti kockázattal jár. Az adatbázis feladatátvétele csak akkor használható végső megoldásként, ha a leállást katasztrofális hiba okozza.
- Az alkalmazás támogatja az írásvédett és írásvédett üzemmódokat, és egy ideig "írásvédett módban" is működik.
Ebben a mintában az alkalmazás írásvédett üzemmódra vált, amikor az olvasási-írási kapcsolatok időtúllépési hibákat tapasztalnak. A webalkalmazás mindkét régióban üzembe van helyezve, és tartalmaz egy kapcsolatot az írásvédett figyelő végponttal, valamint a csak olvasható figyelő végponttal (1). A Traffic Manager-profilnak prioritási útválasztást kell használnia. Minden régióban engedélyezni kell a végpontfigyelést az alkalmazásvégponton (2).
Az alábbi ábra a kimaradás előtti konfigurációt szemlélteti:
Amikor a Traffic Manager az A régió csatlakozási hibáját észleli, automatikusan átváltja a felhasználói forgalmat a B régióban található alkalmazáspéldányra. Ezzel a mintával fontos, hogy az adatvesztéssel járó türelmi időszakot megfelelően magas értékre állítsa, például 24 órára. Biztosítja, hogy az adatvesztés megelőzhető legyen, ha a kimaradás ezen idő alatt csökken. A B régióban lévő webalkalmazás aktiválása után az írási-olvasási műveletek meghiúsulnak. Ekkor át kell váltania az írásvédett módra (1). Ebben a módban a rendszer automatikusan átirányítja a kéréseket a másodlagos adatbázisba. Ha a kimaradást katasztrofális hiba okozza, valószínűleg nem enyhíthető a türelmi időszakon belül. Ha lejár, a feladatátvételi csoport aktiválja a feladatátvételt. Ezt követően az olvasási-írási figyelő elérhetővé válik, és a vele létesített kapcsolatok leállnak (2). Az alábbi ábra a helyreállítási folyamat két szakaszát mutatja be.
Megjegyzés:
Ha az elsődleges régióban a kimaradás a türelmi időszakon belül csökken, a Traffic Manager észleli a kapcsolat helyreállítását az elsődleges régióban, és visszaállítja a felhasználói forgalmat az A régióban lévő alkalmazáspéldányra. Ez az alkalmazáspéldány írás-olvasás módban folytatódik és működik az A régió elsődleges adatbázisának használatával, ahogyan azt az előző diagram is szemlélteti.
Ha kimaradás történik a B régióban, a Traffic Manager észleli a B régióban a 2. végponti webalkalmazás hibáját, és megjelöli azt (1). Addig is a feladatátvételi csoport az írásvédett figyelőt az A régióra (2) váltja. Ez a kimaradás nem befolyásolja a végfelhasználói élményt, de az elsődleges adatbázis a kimaradás során jelenik meg. Az alábbi ábra a másodlagos régióban előforduló hibát szemlélteti:
A kimaradás csökkentése után a másodlagos adatbázis azonnal szinkronizálódik az elsődleges adatbázissal, és a csak olvasható figyelő visszaáll a B régió másodlagos adatbázisára. Az elsődleges szinkronizálási teljesítmény a szinkronizálandó adatok mennyiségétől függően kis mértékben befolyásolható.
Ez a kialakítási minta számos előnnyel rendelkezik:
- Az ideiglenes kimaradások során elkerüli az adatvesztést.
- Az állásidő csak attól függ, hogy a Traffic Manager milyen gyorsan észleli a konfigurálható csatlakozási hibát.
A kompromisszum az, hogy az alkalmazásnak írásvédett módban kell működnie.
Üzletmenet-folytonosság tervezése: Alkalmazásterv kiválasztása a felhőbeli vészhelyreállításhoz
Az adott felhőbeli vészhelyreállítási stratégia kombinálhatja vagy kiterjesztheti ezeket a tervezési mintákat az alkalmazás igényeinek leginkább megfelelőre. Ahogy korábban említettük, a választott stratégia az ügyfeleknek nyújtani kívánt SLA-n és az alkalmazástelepítési topológián alapul. A döntés irányításához az alábbi táblázat összehasonlítja a helyreállítási pont célkitűzése (RPO) és a becsült helyreállítási idő (ERT) alapján választott lehetőségeket.
| Minta | RPO | ERT |
|---|---|---|
| Aktív-passzív üzembe helyezés vészhelyreállításhoz közös elérésű adatbázis-hozzáféréssel | Olvasási-írási hozzáférés < 5 másodperc | Hibaészlelési idő + DNS TTL |
| Aktív-aktív üzembe helyezés az alkalmazás terheléselosztásához | Olvasási-írási hozzáférés < 5 másodperc | Hibaészlelési idő + DNS TTL |
| Aktív-passzív üzembe helyezés az adatmegőrzéshez | Írásvédett hozzáférés < 5 másodperc | Írásvédett hozzáférés = 0 |
| Olvasási-írási hozzáférés = nulla | Olvasási-írási hozzáférés = Hibaészlelési idő + türelmi időszak adatvesztéssel |
További lépések
- Az üzletmenet-folytonosság áttekintését és forgatókönyveit lásd : Üzletmenet-folytonosság áttekintése
- Az aktív georeplikációs adatokról az Aktív georeplikációs című témakörben olvashat.
- A feladatátvételi csoportokról további információt a Feladatátvételi csoportok című témakörben talál.
- A rugalmas készletekkel végzett aktív georeplikációs műveletekről további információt a rugalmas készlet vészhelyreállítási stratégiáiban talál.