Több-bérlős SaaS-alkalmazás helyreállítása adatbázis-biztonsági másolatokból georeduktúra-visszaállítással

A következőre vonatkozik: Azure SQL Database

Ez az oktatóanyag egy bérlői modellenkénti adatbázissal implementált több-bérlős SaaS-alkalmazás teljes vészhelyreállítási forgatókönyvét mutatja be. Georedundáns visszaállítással helyreállíthatja a katalógus és a bérlői adatbázisok automatikusan karbantartott georedundáns biztonsági mentéseit egy alternatív helyreállítási régióba. A kimaradás feloldása után georeplikálással újratelepítheti a módosított adatbázisokat az eredeti régióba.

A georeduktúra az Azure SQL Database legalacsonyabb költségű vészhelyreállítási megoldása. A georedundáns biztonsági másolatokból történő visszaállítás azonban akár egy óra adatvesztést is eredményezhet. Az egyes adatbázisok méretétől függően jelentős időt vehet igénybe.

Megjegyzés:

A lehető legalacsonyabb RPO-val és RTO-val rendelkező alkalmazások helyreállítása georeplikációval a georeduktúra helyett.

Ez az oktatóanyag a visszaállítási és az újratelepítési munkafolyamatokat is ismerteti. Az alábbiak végrehajtásának módját ismerheti meg:

• Szinkronizálja az adatbázis és a rugalmas készlet konfigurációs adatait a bérlőkatalógusba.
• Hozzon létre egy tükrözött képkörnyezetet egy olyan helyreállítási régióban, amely alkalmazásokat, kiszolgálókat és készleteket tartalmaz.
• A katalógus- és bérlői adatbázisok helyreállítása georeduktúra-visszaállítással.
• A bérlőkatalógus ismételt replikálásához és a bérlői adatbázisok módosításához használja a georeplikálást a kimaradás feloldása után.
• Frissítse a katalógust az egyes adatbázisok visszaállításával (vagy újratelepítésével) az egyes bérlői adatbázis aktív példányának aktuális helyének nyomon követéséhez.
• A késés csökkentése érdekében győződjön meg arról, hogy az alkalmazás és a bérlői adatbázis mindig ugyanabban az Azure-régióban található.

Az oktatóanyag megkezdése előtt végezze el a következő előfeltételeket:

• A Wingtip Tickets SaaS-adatbázis üzembe helyezése bérlői alkalmazásonként. Ha öt percnél rövidebb üzembe helyezést szeretne, tekintse meg a Wingtip Tickets SaaS-adatbázis üzembe helyezését és használatát bérlőnkénti alkalmazásonként.
• Telepítse az Azure PowerShellt. További részletekért tekintse meg az Azure PowerShell használatának első lépéseit.

A georeduktúra helyreállítási mintájának 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 hosszan tartó szolgáltatáskimaradás áll fenn, egy jól előkészített dr. terv minimalizálhatja az üzleti fennakadásokat. A georedukción alapuló dr. tervnek több célt is el kell érnie:

• Foglaljon le minden szükséges kapacitást a kiválasztott helyreállítási régióban a lehető leggyorsabban, hogy elérhető legyen a bérlői adatbázisok visszaállításához.
• Hozzon létre egy tükrözött rendszerkép-helyreállítási környezetet, amely az eredeti készletet és adatbázis-konfigurációt tükrözi.
• Engedélyezze a visszaállítási folyamat törlését a repülés közepén, ha az eredeti régió újra online állapotba kerül.
• Engedélyezze a bérlők gyors kiépítését, hogy az új bérlői előkészítés a lehető leghamarabb újraindulhasson.
• Legyen optimalizálva a bérlők prioritási sorrendben történő visszaállítására.
• Úgy kell optimalizálni, hogy a bérlők a lehető leghamarabb online állapotba kerülhessenek a lépések párhuzamos végrehajtásával, ahol gyakorlatiasak.
• Legyen ellenálló a hibák, újraindítható és idempotens.
• Az adatbázisok az eredeti régióba való visszatelepítése minimális hatással van a bérlőkre a kimaradás feloldásakor.

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.

Ez az oktatóanyag az Azure SQL Database és az Azure platform funkcióit használja az alábbi kihívások megoldásához:

• 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óban lévő eredeti kiszolgálók és rugalmas készletek tükörképének kiépítésére szolgálnak. A rendszer külön kiszolgálót és készletet is létrehoz az új bérlők kiépítéséhez.
• Rugalmas adatbázis-ügyfélkódtár (EDCL) bérlői adatbázis-katalógus létrehozásához és karbantartásához. A kiterjesztett katalógus rendszeresen frissített készletet és adatbáziskonfigurációs információkat tartalmaz.
• Az EDCL szegmenskezelési helyreállítási funkciói , amelyek a helyreállítás és az újratelepítés során megőrzik az adatbázis helyadatait a katalógusban.
• Georedundáns visszaállítás a katalógus és a bérlői adatbázisok automatikusan karbantartott georedundáns biztonsági másolataiból való helyreállításához.
• A bérlői prioritási sorrendben küldött aszinkron visszaállítási műveleteket a rendszer minden készlethez várólistára állítja, és kötegekben dolgozza fel, hogy a készlet ne legyen túlterhelve. Ezeket a műveleteket szükség esetén a végrehajtás előtt vagy közben is megszakíthatja.
• Georeplikálás az adatbázisok az eredeti régióba való visszareplikálásához a kimaradás után. Georeplikálás használatakor nincs adatvesztés és minimális hatás a bérlőre.
• SQL Server DNS-aliasok, amelyek lehetővé teszik, hogy a katalógus szinkronizálási folyamata a helyétől függetlenül csatlakozzon az aktív katalógushoz.

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

Az oktatóanyagban használt DR-szkriptek a Wingtip Tickets SaaS-adatbázisban érhetők el bérlőnkénti GitHub-adattárként. 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 .

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 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. Válassza ki a Contoso Koncertterem bérlőjét, és nyissa meg az eseményoldalt.

   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 tekintse át és nyissa meg azt az erőforráscsoportot, amelyben üzembe helyezte az alkalmazást.

   Figyelje meg azokat az erőforrásokat és régiót, amelyben az App Service-összetevők és az SQL Database telepítve van.

A bérlő konfigurációjának szinkronizálása a 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. Ezek az információk később egy tükrözött képkörnyezet konfigurálására szolgálnak a helyreállítási régióban.

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élfelhasználói bejelentkezés alatt futó munkamenetekként vannak implementálva ezekben a mintákban. A bejelentkezéskor kiadott 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 ISE-ben nyissa meg a ...\Learning 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 ISE-ben nyissa meg a ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 szkriptet.

   Ebben az oktatóanyagban az egyes forgatókönyveket ebben a PowerShell-szkriptben futtatja, ezért tartsa nyitva ezt a fájlt.

3. Állítsa be a következőket:

   $DemoScenario = 1: Olyan háttérfeladat indítása, amely szinkronizálja a bérlőkiszolgáló és a készlet konfigurációs adatait a katalógusba.

4. A szinkronizálási szkript futtatásához válassza az F5 lehetőséget.

   Ezek az információk később arra szolgálnak, hogy a helyreállítás tükrözött rendszerképet hozhasson létre a helyreállítási régióban lévő kiszolgálókról, készletekről és adatbázisokról.

   

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. 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.

A georeduktúra helyreállítási folyamatának áttekintése

A georedundáns helyreállítási folyamat üzembe helyezi az alkalmazást, és visszaállítja az adatbázisokat a biztonsági másolatokból a helyreállítási régióba.

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

1. Letiltja a webalkalmazás Azure 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. Kiépít egy helyreállításikatalógus-kiszolgálót a helyreállítási régióban, georedundánsan visszaállítja a katalógus-adatbázist, és frissíti az activecatalog aliast, hogy a visszaállított katalóguskiszolgálóra mutasson. A katalógus aliasának módosítása biztosítja, hogy a katalógus szinkronizálási folyamata mindig szinkronizálva legyen az aktív katalógussal.

3. A helyreállítási katalógusban lévő összes meglévő bérlőt offline állapotúként jelöli meg a bérlői adatbázisokhoz való hozzáférés megakadályozása érdekében a visszaállítás előtt.

4. Üzembe helyezi az alkalmazás egy példányát a helyreállítási régióban, és konfigurálja a visszaállított katalógus használatára az adott régióban. A késés minimálisra csökkentése érdekében a mintaalkalmazás úgy van kialakítva, hogy mindig csatlakozzon egy bérlői adatbázishoz ugyanabban a régióban.

5. Kiépít egy kiszolgálót és egy rugalmas készletet, amelyben új bérlők vannak kiépítve. Ezeknek az erőforrásoknak a létrehozása biztosítja, hogy az új bérlők kiépítése ne zavarja a meglévő bérlők helyreállítását.

6. Frissíti az új bérlői aliast, hogy a helyreállítási régióban lévő új bérlői adatbázisok 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.

7. Kiszolgálókat és rugalmas készleteket helyez üzembe a helyreállítási régióban a bérlői adatbázisok visszaállításához. Ezek a kiszolgálók és készletek az eredeti régió konfigurációjának tükrözött képét képezik. A készletek előzetes üzembe helyezése fenntartja az összes adatbázis visszaállításához szükséges kapacitást.

   Egy régióban a kimaradás jelentős nyomást jelenthet a párosított régióban elérhető erőforrásokra. Ha a dr. georeduktivitás-visszaállításra támaszkodik, akkor ajánlott gyorsan lefoglalni az erőforrásokat. Fontolja meg a georeplikációt, ha kritikus fontosságú egy alkalmazás helyreállítása egy adott régióban.

8. 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.

9. Kérelmek kötegeit küldi el az adatbázisok prioritási sorrendben történő visszaállításához.

   • A kötegek úgy vannak rendszerezve, hogy az adatbázisok az összes készletben párhuzamosan legyenek visszaállítva.

   • A visszaállítási kérelmeket aszinkron módon küldi el a rendszer, így azok gyorsan és várólistára kerülnek az egyes készletekben történő végrehajtás céljából.

   • Mivel a visszaállítási kérelmek feldolgozása párhuzamosan történik az összes készletben, célszerű a fontos bérlőket több készlet között elosztani.

10. Figyeli a szolgáltatást annak megállapításához, hogy mikor állíthatók vissza az adatbázisok. A bérlői adatbázis visszaállítása után a rendszer online megjelöli azt a katalógusban, és a rendszer rögzíti a bérlői adatbázis sorfordítási összegét.

    • 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 összeg 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.

A helyreállítási szkript futtatása

Fontos

Ez az oktatóanyag georedundáns biztonsági másolatokból állítja vissza az adatbázisokat. Bár ezek a biztonsági másolatok általában 10 percen belül érhetők el, akár egy órát is igénybe vehet. A szkript addig szünetel, amíg el nem érhetőek.

Tegyük fel, 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 ISE ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 szkriptjében állítsa be a következő értéket:

   $DemoScenario = 2: Az alkalmazás helyreállítása helyreállítási régióba georedundáns biztonsági másolatokból való visszaállítással.

2. A szkript futtatásához válassza az F5 lehetőséget.

   • A szkript megnyílik egy új PowerShell-ablakban, majd elindít egy párhuzamosan futó PowerShell-feladatkészletet. Ezek a feladatok visszaállítják a kiszolgálókat, készleteket és adatbázisokat 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 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\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. A katalógus visszaállítva, és az összes bérlő offline állapotban van megjelölve. A helyreállítási régióban lévő alkalmazásvégpont ezután engedélyezve van, és az alkalmazás újra online állapotban van. Bár az alkalmazás elérhető, a bérlők offline állapotban jelennek meg az eseményközpontban, amíg vissza nem állítja az adatbázisukat. Fontos, hogy az alkalmazást úgy tervezzen meg, hogy offline bérlői adatbázisokat kezeljen.

• A katalógusadatbázis helyreállítása után, de mielőtt a bérlők újra online állapotba kerülnek, 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.

    

  • Ha közvetlenül a bérlő eseményoldalát nyitja meg, miközben a bérlő offline állapotban van, a lapon egy offline bérlői értesítés jelenik 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 a bérlői adatbázisok visszaállítása előtt kiépítheti az új bérlőket a helyreállítási régióban. A helyreállítási régióban kiépített új bérlői adatbázisok később a helyreállított adatbázisokkal lesznek újratelepítve.

1. A PowerShell ISE ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 szkriptjében állítsa be a következő tulajdonságot:

   $DemoScenario = 3: Új bérlő kiépítése a helyreállítási régióban.

2. A szkript futtatásához válassza az F5 lehetőséget.

3. A Hawthorn Hall eseményoldala megnyílik a böngészőben, amikor a kiépítés befejeződik.

   Figyelje meg, hogy a Hawthorn Hall adatbázis a helyreállítási régióban található.

   

4. A böngészőben frissítse a Wingtip Tickets eseményközpont 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 más bérlők továbbra is offline állapotban vannak.

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. Miután 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. Kattintson a Contoso Koncertteremre, és nyissa meg az események oldalát.

   Az élőlábban figyelje meg, hogy az adatbázis a helyreállítási régióban található helyreállítási kiszolgálón található.

   

3. 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.

4. 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ényalkalmazás helyreállítási példánya.

     

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

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

Ebben a feladatban frissítenie kell az egyik visszaállított bérlői adatbázist. Az újratelepítési folyamat visszaállított adatbázisokat másol, amelyeket az eredeti régióra módosítottak.

1. A böngészőben keresse meg a Contoso Koncertterem eseménylistáját, görgessen végig az eseményeken, és figyelje meg az utolsó eseményt, a Seriously Strausst.

2. A PowerShell ISE ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 szkriptjében állítsa be a következő értéket:

   $DemoScenario = 4: Esemény törlése egy bérlőből a helyreállítási régióban.

3. A szkript végrehajtásához válassza az F5 lehetőséget.

4. Frissítse a Contoso Koncertterem eseményoldalát (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>), és figyelje meg, hogy hiányzik a Súlyosan Strauss esemény.

Az oktatóanyag ezen szakaszában helyreállította az alkalmazást, amely most a helyreállítási régióban fut. Kiépített egy új bérlőt a helyreállítási régióban, és módosította az egyik visszaállított bérlő adatait.

Megjegyzés:

A mintában szereplő egyéb oktatóanyagok nem úgy vannak kialakítva, hogy az alkalmazással helyreállítási állapotban fussanak. Ha más oktatóanyagokat szeretne megismerni, először mindenképpen végezze el az alkalmazás újratelepítését.

A hazatelepítési folyamat áttekintése

A kimaradás feloldása után az újratelepítési folyamat visszaállítja az alkalmazást és adatbázisait az eredeti régióba.

A folyamat:

1. Leállítja a folyamatban lévő visszaállítási tevékenységeket, és megszakítja a folyamatban lévő vagy a repülés közbeni adatbázis-visszaállítási kérelmeket.

2. Újraaktiválja az eredeti régió bérlői adatbázisait, amelyek a kimaradás óta nem változtak. Ezek az adatbázisok közé tartoznak a még nem helyreállított és a helyreállított, de később nem módosított adatbázisok. Az újraaktivált adatbázisok pontosan a bérlőik által utoljára elért adatbázisok.

3. Az új bérlő kiszolgálójának és rugalmas készletének tükrözött képe az eredeti régióban. A művelet befejezése után az új bérlői alias frissül, hogy erre a kiszolgálóra mutasson. Az alias frissítése miatt az új bérlő előkészítése az eredeti régióban történik a helyreállítási régió helyett.

4. Georeplikálással áthelyezi a katalógust az eredeti régióba a helyreállítási régióból.

5. Frissíti a készletkonfigurációt az eredeti régióban, hogy összhangban legyen a helyreállítási régióban a kimaradás során végrehajtott módosításokkal.

6. Létrehozza a szükséges kiszolgálókat és készleteket a kimaradás során létrehozott új adatbázisok üzemeltetéséhez.

7. Georeplikálással replikálja a visszaállítás után frissített visszaállított bérlői adatbázisokat és a kimaradás során kiépített összes új bérlői adatbázist.

8. Törli a helyreállítási régióban a visszaállítási folyamat során létrehozott erőforrásokat.

Az újratelepítendő bérlői adatbázisok számának korlátozásához az 1–3. lépés azonnal megtörténik.

A 4. lépés csak akkor történik meg, ha a helyreállítási régió katalógusa módosult a kimaradás során. A katalógus frissül, ha új bérlők jönnek létre, vagy ha az adatbázis vagy a készlet konfigurációja módosul a helyreállítási régióban.

Fontos, hogy a 7. lépés minimális fennakadást okoz a bérlők számára, és ne vesszenek el adatok. A cél elérése érdekében a folyamat georeplikálást használ.

Az egyes adatbázisok georeplikálása előtt a rendszer törli a megfelelő adatbázist az eredeti régióban. A helyreállítási régióban lévő adatbázis ezután georeplikált lesz, és létrehoz egy másodlagos replikát az eredeti régióban. A replikáció befejezése után a bérlő offline állapotban lesz megjelölve a katalógusban, ami megszakítja a helyreállítási régióban lévő adatbázissal való kapcsolatokat. Ezt követően az adatbázis feladatátvétele miatt a függőben lévő tranzakciók a másodlagoson lesznek feldolgozva, így nem vesznek el adatok.

Feladatátvételkor az adatbázisszerepkörök vissza lesznek fordítva. Az eredeti régióban a másodlagos lesz az elsődleges olvasási-írási adatbázis, a helyreállítási régióban lévő adatbázis pedig írásvédett másodlagossá válik. A katalógus bérlői bejegyzése frissül, hogy az eredeti régióban lévő adatbázisra hivatkozzon, és a bérlő online van megjelölve. Ezen a ponton az adatbázis újratelepítése befejeződött.

Az alkalmazásokat újrapróbálkozási logikával kell írni, hogy a kapcsolatok megszakadása esetén automatikusan újracsatlakozhassanak. Amikor a katalógus használatával közvetítik az újracsatlakozást, az eredeti régióban található újratelepített adatbázishoz csatlakoznak. Bár a rövid leválasztást gyakran nem észleli, előfordulhat, hogy az adatbázisokat munkaidőn kívülre szeretné visszatelepíteni.

Az adatbázis újratelepítése után a helyreállítási régióban lévő másodlagos adatbázis törölhető. Az eredeti régióban lévő adatbázis ezután ismét a DR-védelem georedundáns visszaállítására támaszkodik.

A 8. lépésben a helyreállítási régió erőforrásai, beleértve a helyreállítási kiszolgálókat és a készleteket is, törlődnek.

Az újratelepítési szkript futtatása

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

Ha követte az oktatóanyagot, a szkript azonnal újraaktiválja a Fabrikam Jazz Clubot és a Dogwood Dojo-t az eredeti régióban, mert változatlanok. Ezt követően visszahelyezi az új bérlőt, a Hawthorn Hallt és a Contoso Koncerttermet, mert módosították. A szkript a katalógust is újra megismétli, amely a Hawthorn Hall kiépítésekor frissült.

1. A PowerShell ISE ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 szkriptjében 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: Indítsa el a bérlőkiszolgáló, a készlet és az adatbázis konfigurációs adatainak szinkronizálását a katalógusba.

   A szkript futtatásához válassza az F5 lehetőséget.

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

   $DemoScenario = 5: Az alkalmazás újratelepítése az eredeti régióba.

   Ha egy új PowerShell-ablakban szeretné futtatni a helyreállítási szkriptet, válassza az F5 lehetőséget. Az újratelepítés több percet vesz igénybe, és a PowerShell-ablakban is nyomon követhető.

3. Amíg a szkript fut, frissítse az eseményközpont oldalát (http://events.wingtip-dpt.<user.trafficmanager.net>).

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

4. Nyissa meg a Fabrikam Jazz Clubot. Ha nem módosította ezt a bérlőt, figyelje meg az élőlábból, hogy a kiszolgáló már visszaállt az eredeti kiszolgálóra.

5. Nyissa meg vagy frissítse a Contoso Koncertterem eseményoldalát. Figyelje meg az élőlábból, hogy az adatbázis kezdetben még a -recovery kiszolgálón van.

6. Frissítse a Contoso Koncertterem eseményoldalát, amikor az újratelepítési folyamat befejeződik, és figyelje meg, hogy az adatbázis most már az eredeti régióban található.

7. Frissítse újra az eseményközpontot, és nyissa meg a Hawthorn Hallt. Figyelje meg, hogy az adatbázis az eredeti régióban is található.

Helyreállítási régió erőforrásainak törlése az újratelepítés után

Az újratelepítés befejezése után biztonságosan törölheti a helyreállítási régió erőforrásait.

Fontos

Törölje ezeket az erőforrásokat azonnal, hogy leállítsák az összes számlázást.

A visszaállítási folyamat létrehozza az összes helyreállítási erőforrást egy helyreállítási erőforráscsoportban. A törlési folyamat törli ezt az erőforráscsoportot, és eltávolítja az erőforrásokra mutató összes hivatkozást a katalógusból.

1. A PowerShell ISE-ben a ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 szkriptben állítsa be a következőt:

   $DemoScenario = 6: Elavult erőforrások törlése a helyreállítási régióból.

2. A szkript futtatásához válassza az F5 lehetőséget.

Miután megtisztította a szkripteket, az alkalmazás újra ott van, ahol elindult. Ezen a ponton újra futtathatja a szkriptet, vagy kipróbálhat más oktatóanyagokat.

Az alkalmazás megtervezése annak biztosítása érdekében, hogy az alkalmazás és az adatbázis közösen legyen elhelyezve

Az alkalmazás úgy lett kialakítva, hogy mindig a bérlő adatbázisával 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ó.

Előfordulhat, hogy a bérlői adatbázisok egy ideig a helyreállítási és az eredeti régiók között el vannak osztva 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. 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:

• A bérlőkatalógus használatával rendszeresen frissített konfigurációs információkat tárolhat, így egy tükrözött rendszerkép-helyreállítási környezet hozható létre egy másik régióban.
• Adatbázisok helyreállítása a helyreállítási régióba georedundáns visszaállítással.
• Frissítse a bérlőkatalógust a visszaállított bérlői adatbázis helyeinek megfelelően.
• DNS-alias használatával engedélyezheti, hogy egy alkalmazás újrakonfigurálás nélkül csatlakozzon a bérlőkatalógushoz.
• A georeplikálással a kimaradás feloldása után a helyreállított adatbázisokat az eredeti régióba másolhatja.

Próbálja ki a több-bérlős SaaS-alkalmazások vészhelyreállítását adatbázis-georeplikációs oktatóanyag használatával, amelyből megtudhatja, hogyan használhat georeplikációt a nagy léptékű több-bérlős alkalmazások helyreállításához szükséges idő drasztikus csökkentéséhez.

További erőforrások

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