Vészhelyreállítás több-bérlős SaaS-alkalmazáshoz adatbázis-georeplikációval

A következőre vonatkozik: Azure SQL Database

Ebben az oktatóanyagban egy teljes vészhelyreállítási forgatókönyvet ismerhet meg egy több-bérlős SaaS-alkalmazáshoz, amely az adatbázis-bérlőnkénti modellel van implementálva. Az alkalmazás leállása elleni védelem érdekében georeplikációval replikákat hozhat létre a katalógushoz és a bérlői adatbázisokhoz egy alternatív helyreállítási régióban. Ha kimaradás történik, gyorsan át kell adnia ezeket a replikákat a normál üzleti műveletek folytatásához. Feladatátvételkor az eredeti régióban lévő adatbázisok a helyreállítási régióban lévő adatbázisok másodlagos replikáivá válnak. Miután ezek a replikák újra online állapotba kerülnek, automatikusan felzárkóznak a helyreállítási régióban lévő adatbázisok állapotához. A kimaradás feloldása után vissza kell adnia a feladatokat az eredeti éles régió adatbázisaihoz.

Ez az oktatóanyag a feladatátvételi és a feladat-visszavételi munkafolyamatokat is ismerteti. A következőket fogja megtanulni:

• Adatbázis és rugalmas készlet konfigurációs adatainak szinkronizálása a bérlőkatalógusba
• Helyreállítási környezet beállítása egy másik régióban, amely alkalmazásokat, kiszolgálókat és készleteket tartalmaz
• A georeplikációs szolgáltatással replikálhatja a katalógust és a bérlői adatbázisokat a helyreállítási régióba
• Feladatátvétel az alkalmazás- és katalógus- és bérlői adatbázisoknak a helyreállítási régióba
• Később feladatátvételt hajthat végre az alkalmazás, a katalógus és a bérlői adatbázisok az eredeti régióba a kimaradás feloldása után
• Frissítse a katalógust, mert az egyes bérlői adatbázisok feladatátvétele az egyes bérlői adatbázisok elsődleges helyének nyomon követéséhez
• Győződjön meg arról, hogy az alkalmazás és az elsődleges bérlői adatbázis mindig ugyanabban az Azure-régióban található a késés csökkentése érdekében

Az oktatóanyag megkezdése előtt győződjön meg arról, hogy a következő előfeltételek teljesülnek:

• A Wingtip Tickets SaaS-adatbázis bérlőnkénti alkalmazásonként van üzembe helyezve. Ha öt percnél rövidebb üzembe helyezést szeretne, olvassa el a Wingtip Tickets SaaS-adatbázis üzembe helyezése és felfedezése bérlőnkénti alkalmazásonként című témakört .
• Az Azure PowerShell telepítve van. Részletes információk: Ismerkedés az Azure PowerShell-lel

A georeplikációs helyreállítási minta bemutatása

A vészhelyreállítás (DR) számos alkalmazás esetében fontos szempont, akár megfelelőségi okokból, akár üzletmenet-folytonosságból. Ha hosszabb ideig tartó szolgáltatáskimaradás történik, egy jól előkészített DR-terv minimalizálhatja az üzleti fennakadásokat. A georeplikálás a legalacsonyabb RPO-t és RTO-t biztosítja azáltal, hogy egy helyreállítási régióban tartja fenn az adatbázisreplikákat, amelyek rövid időn belül feladatátvételt végezhetnek.

A georeplikációs alapú DR-terv három különböző részből áll:

• Beállítás – a helyreállítási környezet létrehozása és karbantartása
• Helyreállítás – az alkalmazás és az adatbázisok feladatátvétele a helyreállítási környezetbe, ha leállás történik,
• Újratelepítés – az alkalmazás és az adatbázisok feladatátvétele az eredeti régióba az alkalmazás feloldása után

Minden alkatrészt gondosan kell figyelembe venni, különösen, ha nagy léptékben működik. Összességében a tervnek több célt kell elérnie:

• Beállít
  • Hozzon létre és tartson fenn egy tükörkép-környezetet a helyreállítási régióban. A rugalmas készletek létrehozása és az adatbázisok replikálása ebben a helyreállítási környezetben kapacitást foglal le a helyreállítási régióban. A környezet fenntartása magában foglalja az új bérlői adatbázisok replikálását a kiépítésükkor.
• Helyreállítási
  • Ha a napi költségek minimalizálása érdekében vertikálisan leskálázott helyreállítási környezetet használnak, a készleteket és az adatbázisokat fel kell skálázni, hogy teljes működési kapacitást szerezzenek be a helyreállítási régióban
  • Új bérlő kiépítésének engedélyezése a helyreállítási régióban a lehető leghamarabb
  • Optimalizálva kell lennie a bérlők prioritási sorrendben történő visszaállításához
  • A bérlők lehető leggyorsabb online állapotba helyezéséhez optimalizálható a lépések párhuzamos végrehajtásával, ahol gyakorlati
  • Legyen ellenálló a hibák, újraindítható és idempotens
  • Lehetőség van a folyamat megszakítására a repülés közepén, ha az eredeti régió visszatér az on-line.
• Hazaszállítás
  • Az adatbázisok feladatátvétele a helyreállítási régióból a replikákba az eredeti régióban, minimális hatással a bérlőkre: nincs adatvesztés és bérlőnkénti minimális időszak.

Ebben az oktatóanyagban ezeket a kihívásokat az Azure SQL Database és az Azure platform funkcióival oldjuk meg:

• Azure Resource Manager-sablonok az összes szükséges kapacitás lehető leggyorsabb lefoglalásához. Az Azure Resource Manager-sablonok a helyreállítási régió éles kiszolgálóinak és rugalmas készleteinek tükörképének kiépítésére szolgálnak.
• Georeplikálás az összes adatbázis aszinkron módon replikált írásvédett másodpéldányainak létrehozásához. A kimaradás során feladatátvételt hajt végre a helyreállítási régió replikáin. A kimaradás feloldása után az eredeti régióban lévő adatbázisokba nem kell adatvesztést végrehajtania.
• Bérlői prioritási sorrendben küldött aszinkron feladatátvételi műveletek, hogy nagy számú adatbázis feladatátvételi ideje minimalizálható legyen.
• Szegmenskezelési helyreállítási funkciók a katalógus adatbázis-bejegyzéseinek módosításához a helyreállítás és az újratelepítés során. Ezek a funkciók lehetővé teszik, hogy az alkalmazás helytől függetlenül, az alkalmazás újrakonfigurálása nélkül csatlakozzon a bérlői adatbázisokhoz.
• SQL Server DNS-aliasok, amelyek lehetővé teszik az új bérlők zökkenőmentes kiépítését, függetlenül attól, hogy az alkalmazás melyik régióban működik. A DNS-aliasokkal a katalógus szinkronizálási folyamata a helyétől függetlenül is csatlakozhat az aktív katalógushoz.

Vészhelyreállítási szkriptek lekérése

Fontos

A Wingtip Tickets felügyeleti szkriptjeihez hasonlóan a DR-szkriptek is mintaminőséget jelentenek, és nem használhatók éles környezetben.

Az oktatóanyagban és a Wingtip-alkalmazás forráskódjában használt helyreállítási szkriptek bérlőnkénti GitHub-tárházban érhetők el a Wingtip Tickets SaaS-adatbázisban. Tekintse meg a Wingtip Tickets felügyeleti szkriptek letöltésének és letiltásának feloldásához szükséges általános útmutatót .

Oktatóanyagok áttekintése

Ebben az oktatóanyagban először georeplikációval hozza létre a Wingtip Tickets alkalmazás replikáit és adatbázisait egy másik régióban. Ezután feladatátvételt hajt végre ebbe a régióba, hogy szimulálja a leállások utáni helyreállítást. Ha elkészült, az alkalmazás teljes mértékben működőképes a helyreállítási régióban.

Később egy külön újratelepítési lépésben feladatátvételt kell végrehajtania a helyreállítási régió katalógus- és bérlői adatbázisainak az eredeti régióba. Az alkalmazás és az adatbázisok az újratelepítés során is elérhetők maradnak. Ha elkészült, az alkalmazás teljesen működőképes az eredeti régióban.

Megjegyzés:

Az alkalmazás helyreállítása annak a régiónak a párosított régiójába történik, amelyben az alkalmazás telepítve van. További információt az Azure párosított régióiban talál.

Az alkalmazás kifogástalan állapotának áttekintése

A helyreállítási folyamat megkezdése előtt tekintse át az alkalmazás normál kifogástalan állapotát.

1. A webböngészőben nyissa meg a Wingtip Tickets Eseményközpontot (http://events.wingtip-dpt.<user.trafficmanager.net> – cserélje le <a felhasználót> az üzembe helyezés felhasználói értékére).

   • Görgessen a lap aljára, és figyelje meg a katalóguskiszolgáló nevét és helyét az élőlábban. A hely az a régió, ahol üzembe helyezte az alkalmazást. TIPP: Vigye az egérmutatót a hely fölé a kijelző nagyításához.

2. Kattintson a Contoso Koncertterem bérlőjére, és nyissa meg az eseményoldalát.

   • Az élőlábban figyelje meg a bérlőkiszolgáló nevét. A hely megegyezik a katalóguskiszolgáló helyével.

3. Az Azure Portalon nyissa meg azt az erőforráscsoportot, amelyben az alkalmazás telepítve van

   • Figyelje meg azt a régiót, amelyben a kiszolgálók üzembe vannak helyezve.

Bérlőkonfiguráció szinkronizálása katalógusba

Ebben a feladatban elindít egy folyamatot, amely szinkronizálja a kiszolgálók, rugalmas készletek és adatbázisok konfigurációját a bérlőkatalógusba. A folyamat naprakészen tartja ezeket az információkat a katalógusban. A folyamat az aktív katalógussal működik, akár az eredeti régióban, akár a helyreállítási régióban. A konfigurációs információk a helyreállítási folyamat részeként kerülnek felhasználásra annak biztosítására, hogy a helyreállítási környezet összhangban legyen az eredeti környezettel, majd később az újratelepítés során annak érdekében, hogy az eredeti régió összhangban legyen a helyreállítási környezetben végrehajtott módosításokkal. A katalógus a bérlői erőforrások helyreállítási állapotának nyomon követésére is használható

Fontos

Az egyszerűség kedvéért a szinkronizálási folyamat és a hosszú ideig futó helyreállítási és újratelepítési folyamatok helyi PowerShell-feladatokként vagy az ügyfél felhasználói bejelentkezése alatt futó munkamenetekként vannak implementálva ezekben az oktatóanyagokban. A bejelentkezéskor kibocsátott hitelesítési jogkivonatok több óra elteltével lejárnak, és a feladatok sikertelenek lesznek. Éles környezetben a hosszú ideig futó folyamatokat megbízható, szolgáltatásnév alatt futó Azure-szolgáltatásként kell implementálni. Lásd: Az Azure PowerShell használata szolgáltatásnév tanúsítványsal való létrehozásához.

1. A PowerShell I Standard kiadás nyissa meg a ...\Tanulás Modules\UserConfig.psm1 fájlt. Cserélje le <resourcegroup> a 10. és <user> a 11. sorra az alkalmazás üzembe helyezésekor használt értéket. Mentse a fájlt!

2. A PowerShell I Standard kiadás nyissa meg a ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 szkriptet, és állítsa be a következőt:

   • $DemoScenario = 1, A bérlőkiszolgálót szinkronizáló háttérfeladat és a készletkonfigurációs adatok katalógusba való szinkronizálása

3. A szinkronizálási szkript futtatásához nyomja le az F5 billentyűt. Megnyílik egy új PowerShell-munkamenet a bérlői erőforrások konfigurációjának szinkronizálásához.

Hagyja a Háttérben futó PowerShell-ablakot, és folytassa az oktatóanyag többi részével.

Megjegyzés:

A szinkronizálási folyamat DNS-aliason keresztül csatlakozik a katalógushoz. Ez az alias a visszaállítás és az újratelepítés során módosul, hogy az aktív katalógusra mutasson. A szinkronizálási folyamat naprakészen tartja a katalógust a helyreállítási régióban végrehajtott adatbázis- vagy készletkonfigurációs módosításokkal. Az újratelepítés során ezek a módosítások az eredeti régió egyenértékű erőforrásaira lesznek alkalmazva.

Másodlagos adatbázisreplikák létrehozása a helyreállítási régióban

Ebben a feladatban elindít egy folyamatot, amely egy ismétlődő alkalmazáspéldányt helyez üzembe, és replikálja a katalógust és az összes bérlői adatbázist egy helyreállítási régióba.

Megjegyzés:

Ez az oktatóanyag georeplikációs védelmet ad a Wingtip Tickets mintaalkalmazáshoz. A georeplikációt használó alkalmazások éles forgatókönyvében az egyes bérlők már a kezdettől fogva georeplikált adatbázissal lesznek kiépítve. Lásd: Magas rendelkezésre állású szolgáltatások tervezése az Azure SQL Database használatával

1. A PowerShell I Standard kiadás nyissa meg a ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 szkriptet, és állítsa be a következő értékeket:

   • $DemoScenario = 2, tükörkép-helyreállítási környezet létrehozása és katalógus- és bérlői adatbázisok replikálása

2. A szkriptek futtatásához nyomja le az F5 billentyűt. Megnyílik egy új PowerShell-munkamenet a replikák létrehozásához.

A normál alkalmazásállapot áttekintése

Ezen a ponton az alkalmazás normál módon fut az eredeti régióban, és most georeplikáció védi. Az írásvédett másodlagos replikák az összes adatbázis helyreállítási régiójában léteznek.

1. Az Azure Portalon tekintse meg az erőforráscsoportokat, és figyelje meg, hogy egy erőforráscsoport jött létre -recovery utótaggal a helyreállítási régióban.

2. Ismerkedjen meg a helyreállítási erőforráscsoport erőforrásaival.

3. Kattintson a Contoso Koncertterem adatbázisára a tenants1-dpt-user-recovery<> kiszolgálón. Kattintson a bal oldalon található georeplikációs elemre.

   

Az Azure-régiók térképén jegyezze fel az eredeti régió elsődleges és a helyreállítási régió másodlagos régiója közötti georeplikációs kapcsolatot.

Az alkalmazás feladatátvétele a helyreállítási régióba

A georeplikációs helyreállítási folyamat áttekintése

A helyreállítási szkript a következő feladatokat hajtja végre:

1. Letiltja a webalkalmazás Traffic Manager-végpontját az eredeti régióban. A végpont letiltása megakadályozza, hogy a felhasználók érvénytelen állapotban csatlakozzanak az alkalmazáshoz, ha az eredeti régió online állapotba kerül a helyreállítás során.

2. A helyreállítási régióban lévő katalógusadatbázis kényszerített feladatátvételével elsődleges adatbázissá teszi, és frissíti az activecatalog aliast, hogy a helyreállításikatalógus-kiszolgálóra mutasson.

3. Frissítések az új aliast, hogy a helyreállítási régióban lévő bérlőkiszolgálóra mutasson. Az alias módosítása biztosítja, hogy az új bérlők adatbázisai ki legyenek építve a helyreállítási régióban.

4. A helyreállítási katalógusban lévő összes meglévő bérlőt offline állapotúként jelöli meg, hogy megakadályozza a bérlői adatbázisokhoz való hozzáférést a feladatátvétel előtt.

5. Frissítések a helyreállítási régióban lévő összes rugalmas készlet és replikált önálló adatbázis konfigurációját, hogy tükrözzék a konfigurációjukat az eredeti régióban. (Erre a feladatra csak akkor van szükség, ha a helyreállítási környezet készletei vagy replikált adatbázisai a normál műveletek során leskálázva vannak a költségek csökkentése érdekében).

6. Engedélyezi a Traffic Manager-végpontot a webalkalmazáshoz a helyreállítási régióban. A végpont engedélyezésével az alkalmazás új bérlőket építhet ki. Ebben a szakaszban a meglévő bérlők továbbra is offline állapotban vannak.

7. A feladatátvételi adatbázisok prioritási sorrendben történő kényszerítésére irányuló kérelmek kötegeit küldi el.

   • A kötegek úgy vannak rendszerezve, hogy az adatbázisok az összes készletben párhuzamosan legyenek feladatátvételre.
   • A feladatátvételi kérelmek aszinkron műveletekkel vannak elküldve, így gyorsan elküldhetők, és egyszerre több kérés is feldolgozható.

   Megjegyzés:

   Kimaradás esetén az eredeti régióban lévő elsődleges adatbázisok offline állapotban vannak. A másodlagos feladatátvétel kényszerítése megszakítja az elsődleges kapcsolatát anélkül, hogy megpróbálna reziduális várólistán lévő tranzakciókat alkalmazni. Az oktatóanyaghoz hasonló dr. részletezési forgatókönyvben, ha a feladatátvételkor valamilyen frissítési tevékenység történik, adatvesztés történhet. Később, az újratelepítés során, amikor a helyreállítási régióban lévő adatbázisokat visszahelyezi az eredeti régióba, a rendszer egy normál feladatátvételt használ annak biztosítására, hogy ne legyen adatvesztés.

8. Figyeli a szolgáltatást annak megállapításához, hogy mikor lettek feladatátvételi adatbázisok. A bérlői adatbázis feladatátvétele után frissíti a katalógust a bérlői adatbázis helyreállítási állapotának rögzítéséhez és a bérlő online állapotának megjelöléséhez.

   • A bérlői adatbázisokat az alkalmazás azonnal elérheti, amint online megjelöli őket a katalógusban.
   • A bérlői adatbázisban található rowversion értékek összege a katalógusban van tárolva. Ez az érték ujjlenyomatként működik, amely lehetővé teszi az újratelepítési folyamat számára annak megállapítását, hogy az adatbázis frissült-e a helyreállítási régióban.

Futtassa a szkriptet a helyreállítási régióba történő feladatátvételhez

Képzelje el, hogy kimaradás van abban a régióban, amelyben az alkalmazás üzembe van helyezve, és futtassa a helyreállítási szkriptet:

1. A PowerShell I Standard kiadás nyissa meg a ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 szkriptet, és állítsa be a következő értékeket:

   • $DemoScenario = 3, Az alkalmazás helyreállítása helyreállítási régióba a replikák feladatátvételével

2. A szkriptek futtatásához nyomja le az F5 billentyűt.

   • A szkript megnyílik egy új PowerShell-ablakban, majd elindítja a párhuzamosan futó PowerShell-feladatok sorozatát. Ezek a feladatok feladatokat adnak át a bérlői adatbázisoknak a helyreállítási régióba.
   • A helyreállítási régió ahhoz az Azure-régióhoz társított párosított régió , amelyben üzembe helyezte az alkalmazást. További információt az Azure párosított régióiban talál.

3. A helyreállítási folyamat állapotának figyelése a PowerShell-ablakban.

Megjegyzés:

A helyreállítási feladatok kódjának megismeréséhez tekintse át a ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\RecoveryJobs mappában található PowerShell-szkripteket.

Az alkalmazás állapotának áttekintése a helyreállítás során

Bár az alkalmazásvégpont le van tiltva a Traffic Managerben, az alkalmazás nem érhető el. Miután a katalógus feladatátvételt végzett a helyreállítási régióban, és az összes bérlő offline állapotban van megjelölve, az alkalmazás újra online állapotba kerül. Bár az alkalmazás elérhető, minden bérlő offline állapotban jelenik meg az eseményközpontban, amíg az adatbázisát nem sikerül feladatátvételre használni. Fontos, hogy az alkalmazást úgy tervezzen meg, hogy offline bérlői adatbázisokat kezeljen.

1. A katalógusadatbázis helyreállítása után azonnal frissítse a Wingtip Tickets Eseményközpontot a webböngészőben.

   • Az élőlábban figyelje meg, hogy a katalóguskiszolgáló neve mostantól - recovery utótaggal rendelkezik, és a helyreállítási régióban található.

   • Figyelje meg, hogy a még nem visszaállított bérlők offlineként vannak megjelölve, és nem választhatók ki.

     Megjegyzés:

     Ha csak néhány adatbázist szeretne helyreállítani, előfordulhat, hogy a helyreállítás befejezése előtt nem tudja frissíteni a böngészőt, ezért előfordulhat, hogy offline állapotban nem látja a bérlőket.

     

   • Ha közvetlenül egy offline bérlő Események lapját nyitja meg, az "offline bérlő" értesítést jelenít meg. Ha például a Contoso Koncertterem offline állapotban van, próbálja meg megnyitni http://events.wingtip-dpt.<a user.trafficmanager.net/contosoconcerthall>

Új bérlő kiépítése a helyreállítási régióban

Még az összes meglévő bérlői adatbázis feladatátvétele előtt kiépítheti az új bérlőket a helyreállítási régióban.

1. A PowerShell I Standard kiadás nyissa meg a ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 szkriptet, és állítsa be a következő tulajdonságot:

   • $DemoScenario = 4, Új bérlő kiépítése a helyreállítási régióban

2. Nyomja le az F5 billentyűt a szkript futtatásához és az új bérlő kiépítéséhez.

3. A Hawthorn Hall eseményoldala a böngészőben nyílik meg, amikor befejeződik. Jegyezze fel a láblécből, hogy a Hawthorn Hall adatbázis ki van építve a helyreállítási régióban.

4. A böngészőben frissítse a Wingtip Tickets Events Hub oldalát a Hawthorn Hall megtekintéséhez.

   • Ha a Hawthorn Hallot úgy állította ki, hogy nem várta a többi bérlő visszaállítását, előfordulhat, hogy a többi bérlő továbbra is offline állapotban van.

Az alkalmazás helyreállított állapotának áttekintése

Amikor a helyreállítási folyamat befejeződik, az alkalmazás és az összes bérlő teljes mértékben működőképes lesz a helyreállítási régióban.

1. Ha a PowerShell-konzolablakban látható megjelenítés azt jelzi, hogy az összes bérlő helyreállt, frissítse az Eseményközpontot. A bérlők mind online jelennek meg, beleértve az új bérlőt, a Hawthorn Hallt.

   

2. Az Azure Portalon nyissa meg az erőforráscsoportok listáját.

   • Figyelje meg az üzembe helyezett erőforráscsoportot, valamint a helyreállítási erőforráscsoportot a -recovery utótaggal együtt. A helyreállítási erőforráscsoport tartalmazza a helyreállítási folyamat során létrehozott összes erőforrást, valamint a kimaradás során létrehozott új erőforrásokat.

3. Nyissa meg a helyreállítási erőforráscsoportot, és figyelje meg a következő elemeket:

   • A katalógus és a bérlői1 kiszolgálók helyreállítási verziói a -recovery utótaggal. A visszaállított katalógus és a bérlői adatbázisok mind rendelkeznek az eredeti régióban használt névvel.

   • A bérlők2-dpt-user-recovery<> SQL Server. Ez a kiszolgáló új bérlők kiépítésére szolgál a kimaradás során.

   • Az App Service neve: events-wingtip-dpt-recoveryregion-user<<>>, amely az Események alkalmazás helyreállítási példánya.

     

4. Nyissa meg a tenants2-dpt-user-recovery<> SQL Servert. Figyelje meg, hogy a hawthornhall adatbázist és a rugalmas készletet, a Pool1-et tartalmazza. A galagonya-adatbázis rugalmas adatbázisként van konfigurálva a Pool1 rugalmas készletben.

5. Lépjen vissza az erőforráscsoporthoz, és kattintson a Contoso Koncertterem adatbázisára a tenants1-dpt-user-recovery<> kiszolgálón. Kattintson a bal oldalon található georeplikációs elemre.

   

Bérlői adatok módosítása

Ebben a feladatban frissítenie kell az egyik bérlői adatbázist.

1. A böngészőben keresse meg a Contoso Koncertterem eseménylistáját, és jegyezze fel az utolsó esemény nevét.
2. A PowerShell I Standard kiadás ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 szkriptjében állítsa be a következő értéket:
   • $DemoScenario = 5 Esemény törlése egy bérlőből a helyreállítási régióban
3. Nyomja le az F5 billentyűt a szkript végrehajtásához
4. Frissítse a Contoso Koncertterem eseményoldalát (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall> – helyettesítse a <felhasználót> az üzemelő példány felhasználói értékével), és figyelje meg, hogy az utolsó esemény törölve lett.

Az alkalmazás újratelepítése az eredeti éles régióba

Ez a feladat újratelepíti az alkalmazást az eredeti régióba. Valós forgatókönyv esetén a kimaradás feloldása után újratelepítést kezdeményezhet.

A hazatelepítési folyamat áttekintése

A hazatelepítési folyamat:

1. Megszakítja a folyamatban lévő vagy a repülés közbeni adatbázis-visszaállítási kéréseket.
2. Frissítések az új aliast, hogy a bérlői kiszolgálóra mutasson a forrásrégióban. Ennek az aliasnak a módosítása biztosítja, hogy az új bérlők adatbázisai most már ki lesznek építve a forrásrégióban.
3. A módosított bérlői adatok az eredeti régióba lesznek beállítva
4. A bérlői adatbázisok feladatátvétele prioritási sorrendben.

A feladatátvétel hatékonyan áthelyezi az adatbázist az eredeti régióba. Ha az adatbázis meghibásodik, a rendszer megszakítja a nyitott kapcsolatokat, és az adatbázis néhány másodpercig nem érhető el. Az alkalmazásokat újrapróbálkozásos logikával kell írni, hogy biztosan újra csatlakozzanak. Bár ezt a rövid leválasztást gyakran nem észlelik, dönthet úgy, hogy az adatbázisokat munkaidőn kívülre repatigálja.

Az újratelepítési szkript futtatása

Tegyük fel, hogy a kimaradás feloldva van, és futtassa az újratelepítési szkriptet.

1. A PowerShell I Standard kiadás ...\Tanulás Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 szkriptben.

2. Ellenőrizze, hogy a katalógusszinkronizálási folyamat továbbra is fut-e a PowerShell-példányban. Szükség esetén indítsa újra a következő beállítással:

   • $DemoScenario = 1, A bérlőkiszolgáló, a készlet és az adatbázis konfigurációs adatainak szinkronizálása a katalógusba
   • A szkriptek futtatásához nyomja le az F5 billentyűt.

3. Ezután az újratelepítési folyamat elindításához állítsa be a következőt:

   • $DemoScenario = 6, az alkalmazás újratelepítése az eredeti régióba
   • A helyreállítási szkript egy új PowerShell-ablakban való futtatásához nyomja le az F5 billentyűt. Az újratelepítés több percet vesz igénybe, és a PowerShell-ablakban is nyomon követhető.

4. Amíg a szkript fut, frissítse az Event Hub lapot (http://events.wingtip-dpt.<user.trafficmanager.net>)

   • Figyelje meg, hogy az összes bérlő online állapotban van, és a folyamat során elérhető.

5. A hazatelepítés befejezése után frissítse az Események központot, és nyissa meg a Hawthorn Hall eseményoldalát. Figyelje meg, hogy az adatbázis az eredeti régióba lett átirányítva.

Az alkalmazás megtervezése annak érdekében, hogy az alkalmazás és az adatbázis együtt legyen helyezve

Az alkalmazás úgy lett kialakítva, hogy mindig a bérlői adatbázissal azonos régióban lévő példányból csatlakozzon. Ez a kialakítás csökkenti az alkalmazás és az adatbázis közötti késést. Ez az optimalizálás feltételezi, hogy az alkalmazások közötti interakció csevegősebb, mint a felhasználók közötti interakció.

A bérlői adatbázisok a helyreállítás és az eredeti régiók között egy ideig elterülhetnek az újratelepítés során. Az alkalmazás minden adatbázis esetében megkeresi azt a régiót, amelyben az adatbázis található egy DNS-kereséssel a bérlőkiszolgáló nevére. Az SQL Database-ben a kiszolgáló neve alias. Az aliasolt kiszolgáló neve tartalmazza a régió nevét. Ha az alkalmazás nem ugyanabban a régióban található, mint az adatbázis, akkor a kiszolgálóval azonos régióban lévő példányra irányítja át. Az adatbázissal azonos régióban lévő példányra való átirányítás minimálisra csökkenti az alkalmazás és az adatbázis közötti késést.

További lépések

Ez az oktatóanyag bemutatta, hogyan végezheti el az alábbi műveleteket:

• Adatbázis és rugalmas készlet konfigurációs adatainak szinkronizálása a bérlőkatalógusba
• Helyreállítási környezet beállítása egy másik régióban, amely alkalmazásokat, kiszolgálókat és készleteket tartalmaz
• A georeplikációs szolgáltatással replikálhatja a katalógust és a bérlői adatbázisokat a helyreállítási régióba
• Feladatátvétel az alkalmazás- és katalógus- és bérlői adatbázisoknak a helyreállítási régióba
• Feladat-visszavétel az alkalmazás-, katalógus- és bérlői adatbázisoknak az eredeti régióba a kimaradás feloldása után

Az Üzletmenet-folytonossági áttekintés dokumentációjában többet is megtudhat az Azure SQL Database üzletmenet-folytonosságot lehetővé tevő technológiáiról.

További információforrások

• További oktatóanyagok, amelyek a Wingtip SaaS-alkalmazásra épülnek