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

A következőre 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. A rugalmas készletek és az önálló adatbázisok ugyanazokat a vészhelyreállítási 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ő canonical SaaS 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 dr. vészhelyreállítási stratégiákat ismerteti, amelyek számos forgatókönyvet fednek le a költségérzékeny indítási alkalmazásoktól a szigorú rendelkezésre állási követelményekkel rendelkezőkig.

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.

Scenario 1. Költségérzékeny indítás

Startup vállalkozás vagyok, és rendkívül költséges 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áljon georeduktúra-visszaállítást, 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 feladatátvételét a dr. 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 készletet ugyanazzal a konfigurációval, mint az eredeti készlet (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ó georeduktúra-visszaállítási kérést.
• A felügyeleti adatbázisok feladatátvétele 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 sztring, hogy vissza mutasson az elsődleges régióra. 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).
• A DR-készlet törlése (9)

Ezen a ponton az alkalmazás online állapotban van az elsődleges régióban az elsődleges készletben elérhető összes bérlői adatbázissal.

Juttatás

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 rangsorolja is egyes bérlők visszaállítását másokkal szemben, akkor is versenyben van az összes többi visszaállítással, amelyet ugyanabban a régióban kezdeményeznek, mint a szolgáltatás választottbírói és szabályozásai, hogy minimalizálja a meglévő ügyfelek adatbázisára gyakorolt általános hatá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.

Scenario 2. 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. A fizető ügyfelek számára az állásidő a repülési kockázat. 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 alacsonyabb eDTU-val vagy virtuális magokkal rendelkeznek, és alacsonyabb SLA-val rendelkeznek, hosszabb helyreállítási idővel. 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ált a másodlagos készletbe (2). Ez lehetővé teszi az összes bérlői adatbázis gyors helyreállítását feladatátvétellel.

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 feladatátvétele a DR-régióba (3).
• Módosítsa az alkalmazás kapcsolati sztring, 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ő adatbázisainak feladatátvétele a dr. régió készletére a rendelkezésre állás azonnali visszaállításához (4). Mivel a feladatátvétel gyors metaadatszint-változás, fontolja meg az optimalizálást, ahol az egyes feladatátvételeket igény szerint aktiválják a végfelhasználói kapcsolatok.
• 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 georeduktúra-visszaállítással állítsa vissza az egyes próbaverziós bérlői adatbázisokat 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 azure helyreállítja az elsődleges régiót, 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ó a feladatátvételi folyamat befejezése előtt helyreáll, fontolja meg a feladat-visszavételt. A feladat-visszavétel a következő ábrán látható lépéseket veszi fel:

• Törölje az összes fennmaradó georeduktúra-visszaállítási kérést.
• Feladatátvétel a felügyeleti adatbázisokon (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.
• Feladatátvétel a fizetős bérlői adatbázisokon (9). Hasonlóképpen, a régió helyreállítása után a régi előválasztások automatikusan másodévesek lesznek. Most újra ők lesznek az előválasztások.
• Állítsa be a dr. régióban módosított visszaállított próbaadatbázisokat írásvédettre (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).

Megjegyzés:

A feladatátvételi művelet aszinkron. 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.

Juttatás

A stratégia fő előnye, hogy a legmagasabb SLA-t biztosítja a fizető ügyfelek számára. Azt is garantálja, hogy az új próbaverziók feloldódnak a próbaverziós dr. készlet létrehozása után.

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észlet kiépítése magas eDTU-kkal vagy virtuális magokkal adatbázisonként két különböző régióban, hogy a fizetős ügyfelek bérlői adatbázisait tartalmazza. 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 georeplikáltak a két régióban lévő elsődleges adatbázisok 50%-ával. Hasonlóképpen, minden régióban a másodlagos adatbázisok 50%-a található. Így, ha egy régió offline állapotban van, a fizetős ügyfelek adatbázisainak csak 50%-a érintett, é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 előválasztások és a másodfokok az A régió és a B régió (2) között oszlanak meg. Így a kimaradás által érintett elsődleges bérlői adatbázisok feladatátvételt végezhetnek a másik régióban, é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.

• A felügyeleti adatbázisok azonnali feladatátvétele a B régióba (3).
• Módosítsa az alkalmazás kapcsolati sztring, hogy a B régióban lévő felügyeleti adatbázisokra mutasson. Módosítsa a felügyeleti adatbázisokat, hogy meggyőződjön arról, hogy az új fiókok és bérlői adatbázisok a B régióban jönnek létre, és a meglévő bérlői adatbázisok is ott találhatók. A meglévő próbaverziós ügyfelek ideiglenesen elérhetetlennek látják az adataikat.
• A fizetős bérlő adatbázisainak feladatátvétele a 2. készletre a B régióban a rendelkezésre állás azonnali visszaállításához (4). Mivel a feladatátvétel gyors metaadatszint-változás, érdemes lehet optimalizálni, hogy az egyes feladatátvételeket igény szerint aktiválják a végfelhasználói kapcsolatok.
• 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 georeduktúra-visszaállítással állítsa vissza az egyes próbaverziós bérlői adatbázist 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.

Megjegyzés:

A feladatátvételi művelet aszinkron. 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.

Az A régió helyreállításakor el kell döntenie, hogy a "B" régiót szeretné-e használni a próbaverziós ügyfelek számára, vagy a feladat-visszavételt az A régióban található próbaverziós ügyfelek készletének használatához. Az egyik feltétel lehet a helyreállítás óta módosított próbaverziós bérlői adatbázisok %-a. Ettől a döntéstől függetlenül újra kell egyensúlyoznia a fizetős bérlőket két készlet között. A következő ábra azt a folyamatot mutatja be, amikor a próbabérlendő-adatbázisok visszakerülnek 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.
• Feladatátvétel a felügyeleti adatbázison (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 térjenek vissza az 1. készletbe, és kezdeményezzék a feladatátvételt a másodsorban (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%-uk lesz újra előválasztás.
• Csökkentse a 2. készlet méretét az eredeti eDTU-ra (10) vagy a virtuális magok számára.
• Á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).

Juttatás

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 befolyásolja a bérlői adatbázisok több mint 50%-át.
• Garantálja, hogy az új próbaverziók feloldódnak, amint létrejön a nyomvonal DR-készlete a helyreállítás során.
• Ez lehetővé teszi a készletkapacitás hatékonyabb használatát, mivel az 1. és a 2. készlet másodlagos adatbázisainak 50%-a garantáltan kevésbé aktív, 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 a feladatátvétel és a feladat-visszavétel során módosítani kell.
• A fizető ügyfelek a szokásosnál alacsonyabb teljesítményt tapasztalhatnak a készlet B régióban történő frissítésének befejezéséig.

Összesíté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áson 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. Ezért áttekintheti üzletmenet-folytonossági útmutatójukat, és vezénylheti velük az adatbázisszint helyreállítását. Az adatbázis-alkalmazások Azure-beli helyreállításának kezelésével kapcsolatos további információkért tekintse meg a felhőmegoldások vészhelyreállításhoz való tervezését.

További lépések

• Az Azure SQL Database automatikus biztonsági mentéseiről az Azure SQL Database automatikus biztonsági másolatai című témakörben olvashat.
• Az üzletmenet-folytonosság áttekintését és forgatókönyveit az üzletmenet-folytonosság áttekintésében tekintheti meg.
• Az automatikus biztonsági mentések helyreállítási célú használatáról további információt a szolgáltatás által kezdeményezett biztonsági másolatok adatbázisának visszaállításával kapcsolatban talál.
• A gyorsabb helyreállítási lehetőségekről az Aktív georeplikációs és feladatátvételi csoportok című témakörben olvashat.
• Az automatikus biztonsági mentések archiváláshoz való használatáról az adatbázis-másolatban olvashat.