Vészhelyreállítási stratégiák rugalmas Azure SQL Database-készleteket használó alkalmazásokhoz

A következőkre vonatkozik:Azure SQL Database

Az Azure SQL Database számos lehetőséget kínál az alkalmazás üzletmenet-folytonosságának biztosítására katasztrofális incidensek esetén. rugalmas készletek és önálló adatbázisok ugyanazokat a vészhelyreállítási (DR) képességeket támogatják. Ez a cikk az Azure SQL Database üzletmenet-folytonossági funkcióit kihasználó rugalmas készletekre vonatkozó dr. stratégiákat ismerteti.

Ez a cikk a következő általánosan elfogadott SaaS független szoftverszállító (ISV) alkalmazásmintát használja:

Egy modern felhőalapú webalkalmazás minden végfelhasználó számára egy adatbázist helyez üzembe. Az ISV-nek sok ügyfele van, ezért számos adatbázist, más néven bérlői adatbázist használ. Mivel a bérlői adatbázisok általában kiszámíthatatlan tevékenységmintákat használnak, az ISV rugalmas készletet használ az adatbázis költségeinek hosszú időn keresztül történő nagyon kiszámíthatóvá tétele érdekében. A rugalmas készlet leegyszerűsíti a teljesítménykezelést is, ha a felhasználói tevékenység kiugróan magas. A bérlői adatbázisok mellett az alkalmazás több adatbázist is használ a felhasználói profilok kezeléséhez, a biztonsághoz, a használati minták gyűjtéséhez stb. Az egyes bérlők rendelkezésre állása nem befolyásolja az alkalmazás teljes rendelkezésre állását. A felügyeleti adatbázisok rendelkezésre állása és teljesítménye azonban kritikus fontosságú az alkalmazás működéséhez, és ha a felügyeleti adatbázisok offline állapotban vannak, a teljes alkalmazás offline állapotban van.

Ez a cikk a katasztrófa utáni helyreállítási stratégiákat ismerteti, amelyek számos forgatókönyvet fednek le a költségérzékeny startup alkalmazásoktól a szigorú rendelkezésre állási követelményekkel rendelkező alkalmazásokig.

Jegyzet

Ha prémium vagy üzletileg kritikus fontosságú adatbázisokat és rugalmas készleteket használ, a zónaredundáns üzembehelyezési konfigurációvá alakításával rugalmassá teheti őket a regionális kimaradások esetén. Lásd zónaredundáns adatbázisok.

1. forgatókönyv. Költségérzékeny indítás

Startup vállalkozás vagyok, és rendkívül költségérzékeny vagyok. Egyszerűsíteni szeretném az alkalmazás üzembe helyezését és kezelését, és korlátozott SLA-val rendelkezhetek az egyes ügyfelek számára. De szeretném biztosítani, hogy az alkalmazás egésze soha ne legyen offline.

Az egyszerűség követelményének kielégítése érdekében helyezze üzembe az összes bérlői adatbázist egy rugalmas készletben az Ön által választott Azure-régióban, és telepítse a felügyeleti adatbázisokat georeplikált önálló adatbázisokként. A bérlők vészhelyreállításához használja georeduktúra-visszaállítási, amely további költségek nélkül jár. A felügyeleti adatbázisok rendelkezésre állásának biztosításához georeplikálása egy másik régióba feladatátvételi csoport használatával (1. lépés). Ebben a forgatókönyvben a vészhelyreállítási konfiguráció folyamatos költsége megegyezik a másodlagos adatbázisok teljes költségével. Ez a konfiguráció a következő ábrán látható.

Ha az elsődleges régióban kimaradás történik, az alkalmazás online állapotba helyezésének helyreállítási lépéseit a következő diagram szemlélteti.

• A feladatátvételi csoport kezdeményezi a felügyeleti adatbázis automatikus átvételét a katasztrófaelhárítási régióba. Az alkalmazás automatikusan újra csatlakozik az új elsődlegeshez, és minden új fiók és bérlői adatbázis létrejön a DR régióban. A meglévő ügyfelek ideiglenesen elérhetetlennek látják az adataikat.
• Hozza létre a rugalmas csoportot ugyanazzal a beállítással, mint az eredeti csoport (2).
• A bérlői adatbázisok másolatainak létrehozásához használja a georeduktúra-visszaállítást (3). Érdemes lehet az egyes visszaállításokat a végfelhasználói kapcsolatokon keresztül aktiválni, vagy más alkalmazásspecifikus prioritási sémát használni.

Ezen a ponton az alkalmazás újra online állapotban van a DR régióban, de egyes ügyfelek késést tapasztalnak az adataik elérésekor.

Ha a kimaradás ideiglenes volt, lehetséges, hogy az elsődleges régiót az Azure helyreállítja, mielőtt az összes adatbázis-visszaállítás befejeződik a DR régióban. Ebben az esetben vezénylje vissza az alkalmazást az elsődleges régióba. A folyamat a következő diagramon látható lépéseket végzi el.

• Törölje az összes fennmaradó geovisszaállítási kérést.
• A felügyeleti adatbázisok átvitele az elsődleges régióba (5). A régió helyreállítása után a régi előválasztások automatikusan másodfokúvá váltak. Most ismét szerepköröket váltanak.
• Módosítsa az alkalmazás kapcsolati sztringjét úgy, hogy az az elsődleges régióra mutasson. Most az összes új fiók és bérlői adatbázis létrejön az elsődleges régióban. Egyes meglévő ügyfelek ideiglenesen elérhetetlennek látják az adataikat.
• Állítsa be a DR-készletben lévő összes adatbázist írásvédettre, hogy azok ne módosíthatók legyenek a DR régióban (6).
• A helyreállítás óta megváltozott dr. készletben lévő összes adatbázis esetében nevezze át vagy törölje az elsődleges készlet megfelelő adatbázisait (7).
• Másolja a frissített adatbázisokat a DR-készletből az elsődleges készletbe (8).
• DR-készlet törlése (9)

Jelenleg az alkalmazás online állapotban van az elsődleges régióban az összes bérlői adatbázissal, amelyek elérhetők az elsődleges csoportban.

Haszon

Ennek a stratégiának a fő előnye az adatréteg-redundancia alacsony folyamatos költsége. Az Azure SQL Database automatikusan biztonsági másolatot készít az alkalmazások átírása nélkül, további költségek nélkül. A költségek csak a rugalmas adatbázisok visszaállításakor merülnek fel.

Kompromisszum

A kompromisszum az, hogy az összes bérlői adatbázis teljes helyreállítása jelentős időt vesz igénybe. Az időtartam a DR régióban kezdeményezett visszaállítások teljes számától és a bérlői adatbázisok teljes méretétől függ. Még ha egyes bérlők visszaállítását előnyben részesíti is másokkal szemben, akkor is versenyez az összes többi visszaállítással, amelyet ugyanabban a régióban kezdeményeznek, mivel a szolgáltatás dönti el és korlátozza, hogy minimalizálják az ügyfelek meglévő adatbázisaira gyakorolt összhatást. Emellett a bérlői adatbázisok helyreállítása csak akkor kezdődhet meg, ha létre nem jön az új rugalmas készlet a DR régióban.

2. forgatókönyv. Kiforrott alkalmazás rétegzett szolgáltatással

Érett SaaS-alkalmazás vagyok, rétegzett szolgáltatási ajánlatokkal és különböző SLA-kkal a próbaverziós ügyfelek és a fizető ügyfelek számára. A próbaverziós ügyfelek számára a lehető legnagyobb mértékben csökkenteni kell a költségeket. A próbaverziós ügyfelek állásidőt vehetnek igénybe, de szeretném csökkenteni a valószínűségét. Fizető ügyfelek számára bármilyen leállás üzleti kockázatot jelent. Ezért gondoskodni szeretnék arról, hogy a fizető ügyfelek mindig hozzáférhessenek az adataikhoz.

A forgatókönyv támogatásához különítse el a próbaverziós bérlőket a fizetős bérlőktől úgy, hogy külön rugalmas készletekbe helyezi őket. A próbaverziós ügyfelek bérlőnként kevesebb eDTU-val vagy virtuális maggal, valamint alacsonyabb SLA-val és hosszabb helyreállítási idővel rendelkeznek. A fizető ügyfelek bérlőnként magasabb eDTU-val vagy virtuális magokkal és magasabb SLA-val rendelkező készletben vannak. A legalacsonyabb helyreállítási idő biztosítása érdekében a fizető ügyfelek bérlői adatbázisai georeplikáltak. Ez a konfiguráció a következő ábrán látható.

Az első forgatókönyvhöz hasonlóan a felügyeleti adatbázisok is nagyon aktívak, ezért egyetlen georeplikált adatbázist használ (1). Ez biztosítja az új ügyfél-előfizetések, profilfrissítések és egyéb felügyeleti műveletek kiszámítható teljesítményét. Az a régió, amelyben a felügyeleti adatbázisok elsődleges adatai találhatók, az elsődleges régió, és az a régió, amelyben a felügyeleti adatbázisok másodsorban találhatók, a DR régió.

A fizető ügyfelek bérlői adatbázisai aktív adatbázisokkal rendelkeznek az elsődleges régióban kiépített fizetős készletben. Azonos nevű másodlagos készlet kiépítése a DR régióban. Minden bérlő georeplikálva van a másodlagos poolhoz (2). Ez lehetővé teszi az összes bérlői adatbázis gyors helyreállítását a feladatátvétel révén.

Ha az elsődleges régióban kimaradás történik, az alkalmazás online állapotba helyezésének helyreállítási lépéseit a következő diagram szemlélteti:

• A felügyeleti adatbázisok azonnali áthelyezése a DR-régióba (3).
• Módosítsa az alkalmazás kapcsolati sztringjét úgy, hogy a DR régióra mutasson. Most az összes új fiók és bérlői adatbázis létrejön a DR régióban. A meglévő próbaverziós ügyfelek ideiglenesen elérhetetlennek látják az adataikat.
• A fizetős bérlők adatbázisainak átváltása a DR régió készletébe a rendelkezésre állás azonnali visszaállítása érdekében (4). Mivel az átkapcsolás gyors metaadat szintű változás, fontolja meg az optimalizálást, amely során az egyes átkapcsolások a végfelhasználói kapcsolatok kérésére aktiválódnak.
• Ha a másodlagos készlet eDTU-mérete vagy virtuálismag-értéke alacsonyabb volt az elsődlegesnél, mert a másodlagos adatbázisok csak a módosítási naplók feldolgozásához szükséges kapacitást igényelték, akkor azonnal növelje a készlet kapacitását az összes bérlő teljes számítási feladatainak ellátásához (5).
• Hozza létre az új rugalmas készletet ugyanazzal a névvel és ugyanazzal a konfigurációval a DR régióban a próbaverziós ügyfelek adatbázisaihoz (6).
• A próbaverziós ügyfelek készletének létrehozása után geo-helyreállítással állítsa vissza az egyes próbaverziós bérlők adatbázisait az új készletbe (7). Fontolja meg az egyes visszaállítások végfelhasználói kapcsolatok általi aktiválását, vagy használjon más alkalmazásspecifikus prioritási sémát.

Ezen a ponton az alkalmazás újra online állapotban van a DR régióban. Minden fizető ügyfél hozzáfér az adataihoz, míg a próbaverziós ügyfelek késést tapasztalnak az adataik elérésekor.

Ha az elsődleges régiót az Azure állítja helyre, miután visszaállította az alkalmazást a DR régióban, folytathatja az alkalmazás futtatását az adott régióban, vagy dönthet úgy, hogy vissza szeretne állni az elsődleges régióba. Ha az elsődleges régió helyreállt mielőtt a feladatátvételi folyamat befejeződik, fontolja meg az azonnali feladat-visszavételt. Az ábra a visszaállítás lépéseit mutatja be:

• Törölje az összes fennmaradó geovisszaállítási kérést.
• Átkapcsolás a felügyeleti adatbázisokra (8). A régió helyreállítása után a régi elsődleges automatikusan másodlagossá válik. Most ismét ez lesz az elsődleges.
• Átállás a fizetős bérlői adatbázisok esetén (9). Hasonlóképpen, a régió helyreállítása után a régi elsődlegesek automatikusan másodlagossá válnak. Most ismét ők válnak a főszereplőkké.
• Állítsa be a DR régióban módosított próbaadatbázisokat visszaállítva csak olvashatóvá (10).
• A próbaverziós ügyfelek dr. készletének minden olyan adatbázisa esetében, amely a helyreállítás óta módosult, nevezze át vagy törölje a megfelelő adatbázist a próbaverziós ügyfelek elsődleges készletében (11).
• Másolja a frissített adatbázisokat a DR-készletből az elsődleges készletbe (12).
• Törölje a DR-készletet (13).

Jegyzet

A feladatátvételi művelet aszinkron módon történik. A helyreállítási idő minimalizálása érdekében fontos, hogy a bérlői adatbázisok feladatátvételi parancsát legalább 20 adatbázis kötegeiben hajtsa végre.

Haszon

A stratégia fő előnye, hogy a legmagasabb SLA-t biztosítja a fizető ügyfelek számára. Amint a DR próbaverziós készlet létrejön, garantált az új próbaverziók felszabadulása.

Kompromisszum

A kompromisszum az, hogy ez a beállítás növeli a bérlői adatbázisok teljes költségét a fizetős ügyfelek másodlagos DR-készletének költségével. Ezenkívül ha a másodlagos készlet mérete eltérő, a fizető ügyfelek a feladatátvétel után alacsonyabb teljesítményt tapasztalnak, amíg a készlet frissítése a DR régióban be nem fejeződik.

3. forgatókönyv. Földrajzilag elosztott alkalmazás rétegzett szolgáltatással

Van egy érett SaaS-alkalmazásom rétegzett szolgáltatási ajánlatokkal. Nagyon agresszív SLA-t szeretnék kínálni fizetős ügyfeleimnek, és minimalizálni a kimaradások hatásának kockázatát, mert még a rövid megszakítás is okozhatja az ügyfelek elégedetlenségét. Kritikus fontosságú, hogy a fizető ügyfelek mindig hozzáférhessenek az adataikhoz. A próbaverziók ingyenesek, és a próbaidőszak alatt nem kínálunk SLA-t.

A forgatókönyv támogatásához használjon három különálló rugalmas készletet. Két egyenlő méretű készletet hozzanak létre magas eDTU-kkal vagy virtuális magokkal adatbázisonként két különböző régióban, hogy ezekben helyezzék el a fizetős ügyfelek bérlői adatbázisait. A próbabérlőket tartalmazó harmadik készlet adatbázisonként alacsonyabb eDTU-kkal vagy virtuális magokkal rendelkezhet, és a két régió egyikében építhető ki.

A szolgáltatáskimaradások során a legalacsonyabb helyreállítási idő biztosítása érdekében a fizető ügyfelek bérlői adatbázisai a két régióban lévő elsődleges adatbázisok 50% százalékának használatával földrajzilag replikáltak. Hasonlóképpen, minden régióban 50% található a másodlagos adatbázisokból. Így, ha egy régió offline állapotban van, a fizetős ügyfelek adatbázisainak csak 50% van hatással, és feladatátvételt kell végrehajtania. A többi adatbázis érintetlen marad. Ezt a konfigurációt az alábbi diagram szemlélteti:

Az előző forgatókönyvekhez hasonlóan a felügyeleti adatbázisok is meglehetősen aktívak, ezért egyetlen georeplikált adatbázisként konfigurálják őket (1). Ez biztosítja az új ügyfél-előfizetések, profilfrissítések és egyéb felügyeleti műveletek kiszámítható teljesítményét. Az A régió a felügyeleti adatbázisok elsődleges régiója, a B régió pedig a felügyeleti adatbázisok helyreállítására szolgál.

A fizető ügyfelek bérlői adatbázisai szintén georeplikáltak, de az elsődlegesek és másodlagosak az A régió és a B régió között vannak megosztva. Így a kimaradás által érintett bérlők elsődleges adatbázisai átkapcsolhatnak a másik régióba, és elérhetővé válhatnak. A bérlői adatbázisok másik fele egyáltalán nem lesz hatással.

A következő diagram az A régióban történő kimaradás esetén követendő helyreállítási lépéseket mutatja be.

• Azonnal állítsa át a felügyeleti adatbázisokat a B régióba (3).
• Módosítsa az alkalmazás kapcsolati sztringjét úgy, hogy a B régióban lévő felügyeleti adatbázisokra mutasson. Módosítsa a felügyeleti adatbázisokat, hogy az új fiókok és bérlői adatbázisok a B régióban legyenek létrehozva, és a meglévő bérlői adatbázisok is ott legyenek. A meglévő próbaverziós ügyfelek ideiglenesen elérhetetlennek látják az adataikat.
• A fizetős bérlő adatbázisainak áthelyezése a 2-es készletre a B régióban, hogy azonnal helyreállítsuk a rendelkezésre állásukat (4). Mivel az átállás egy gyors metaadatszintű változás, érdemes lehet egy olyan optimalizációt mérlegelni, amelyben az egyes átállásokat a végfelhasználói kapcsolatok igény szerint aktiválják.
• Mivel a 2. készlet jelenleg csak elsődleges adatbázisokat tartalmaz, a készlet teljes számítási feladatai növekednek, és azonnal növelhetik az eDTU méretét (5) vagy a virtuális magok számát.
• Hozza létre az új rugalmas készletet ugyanazzal a névvel és ugyanazzal a konfigurációval a B régióban a próbaverziós ügyfelek adatbázisaihoz (6).
• A készlet létrehozása után használja a geo-visszaállítást az egyes próbaverziós bérlő adatbázisának visszaállításához a készletbe (7). Érdemes lehet az egyes visszaállításokat a végfelhasználói kapcsolatokon keresztül aktiválni, vagy más alkalmazásspecifikus prioritási sémát használni.

Jegyzet

A feladatátvételi művelet aszinkron módon történik. A helyreállítási idő minimalizálása érdekében fontos, hogy a bérlői adatbázisok feladatátvételi parancsát legalább 20 adatbázis kötegeiben hajtsa végre.

Ezen a ponton az alkalmazás újra online állapotban van a B régióban. Minden fizető ügyfél hozzáfér az adataihoz, míg a próbaverziós ügyfelek késést tapasztalnak az adataik elérésekor.

Amikor az A régió helyreáll, el kell döntenie, hogy a B régiót szeretné-e használni a próbaverziós ügyfelek számára, vagy visszaállítva az A régióban található próbaverziós ügyfelek készletének használatára. Az egyik szempont lehet a helyreállítás óta módosított próbaverziós bérlői adatbázisok %. Ettől a döntéstől függetlenül újra kell egyensúlyoznia a fizetős bérlőket két csoport között. A következő ábra azt a folyamatot mutatja be, amikor a kísérleti bérlő adatbázisok visszaállnak az A régióba.

• Törölje a próbaverziós dr. készlethez érkező összes fennmaradó geo-visszaállítási kérést.
• Átváltás a felügyeleti adatbázisra (8). A régió helyreállítása után a régi elsődleges automatikusan másodlagossá vált. Most ismét ez lesz az elsődleges.
• Válassza ki, hogy mely fizetős bérlői adatbázisok álljanak vissza az 1. készletbe, és kezdjék meg az áttérést a másodlagosukra (9). A régió helyreállítása után az 1. készlet összes adatbázisa automatikusan másodfokúvá vált. Most 50% újra elsődleges lesz.
• Csökkentse a 2. pool méretét az eredeti eDTU-ra (10), vagy választhatja az eredeti virtuális magok számát.
• Állítsa be az összes visszaállított próbaadatbázist a B régióban írásvédettre (11).
• A helyreállítás óta megváltozott próbaverziós készletben lévő összes adatbázis esetében nevezze át vagy törölje a megfelelő adatbázist a próbaverzió elsődleges készletében (12).
• Másolja a frissített adatbázisokat a DR-készletből az elsődleges készletbe (13).
• Törölje a DR-készletet (14).

Haszon

A stratégia fő előnyei a következők:

• Támogatja a legagresszívabb SLA-t a fizető ügyfelek számára, mivel biztosítja, hogy a kimaradás ne érintsen több mint 50% bérlői adatbázist.
• Garantálja, hogy az új próbák feloldódnak, amint a visszaállítás során létrejön a próbák DR-poolja.
• Ez lehetővé teszi a készletkapacitás hatékonyabb használatát, mivel az 1. és a 2. készletben lévő másodlagos adatbázisok 50% garantáltan kevésbé aktívak, mint az elsődleges adatbázisok.

Kompromisszumok

A fő kompromisszumok a következők:

• A felügyeleti adatbázisok CRUD-műveletei kisebb késéssel rendelkeznek az A régióhoz csatlakozó végfelhasználók számára, mint a B régióhoz csatlakozó végfelhasználók esetében, mivel azokat az elsődleges felügyeleti adatbázisokon hajtják végre.
• A felügyeleti adatbázis összetettebb kialakítását igényli. Például minden bérlőrekordhoz tartozik egy helycímke, amelyet átállás és visszaállás során módosítani kell.
• A fizető ügyfelek a szokásosnál alacsonyabb teljesítményt tapasztalhatnak, amíg a készlet frissítése be nem fejeződik a B régióban.

Összefoglalás

Ez a cikk az SaaS ISV több-bérlős alkalmazás által használt adatbázisszint vészhelyreállítási stratégiáit ismerteti. A választott stratégia az alkalmazás igényein alapul, például az üzleti modellen, az ügyfeleknek nyújtani kívánt SLA-n, a költségvetési korlátozásokon stb. Minden leírt stratégia felvázolja az előnyöket és a kompromisszumot, így megalapozott döntést hozhat. Az adott alkalmazás valószínűleg más Azure-összetevőket is tartalmaz. Ezt követően áttekinted az üzletmenet-folytonossági útmutatójukat, és vezényled velük az adatbázisszint helyreállítást. Ha többet szeretne megtudni az adatbázis-alkalmazások Azure-beli helyreállításának kezeléséről, tekintse meg Felhőmegoldások tervezése vészhelyreállítási.

Következő lépések

• Az Azure SQL Database automatikus biztonsági mentéseinek megismeréséhez tekintse meg Azure SQL Database automatikus biztonsági mentéseit.
• Az üzletmenet-folytonosság áttekintését és forgatókönyveit Üzletmenet-folytonosság áttekintésecímű témakörben talál.
• Az automatikus biztonsági mentések helyreállítási célú használatáról a szolgáltatás által kezdeményezett biztonsági másolatok adatbázis visszaállítása című témakörben olvashat.
• A gyorsabb helyreállítási lehetőségekről az Aktív georeplikáció és a Failover csoportokcímű témakörben olvashat.
• Az automatikus biztonsági mentések archiváláshoz való használatáról további információt adatbázis-másolásicímű témakörben talál.