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

A KÖVETKEZŐKRE VONATKOZIK: Azure SQL Database

Ebben az oktatóanyagban megismerheti egy több-bérlős SaaS-alkalmazás teljes vészhelyreállítási forgatókönyvét, amely a bérlőnkénti adatbázismodellel van megvalósítva. Az alkalmazás kimaradásokkal szembeni védelméhez georeplikációval replikákat hozhat létre a katalógushoz és a bérlői adatbázisokhoz egy másik helyreállítási régióban. Kimaradás esetén gyorsan átveheti a feladatátvételt ezekre a replikákra a normál üzleti működés folytatásához. Feladatátvétel során az eredeti régióban található adatbázisok a helyreállítási régióban található adatbázisok másodlagos replikáivá válnak. Miután ezek a replikák ismét online állapotba kerülnek, automatikusan be tudják látni az adatbázisok állapotát a helyreállítási régióban. A kimaradás megoldása után a rendszer visszaveszi a feladat-visszavételt az eredeti éles régióban található adatbázisokba.

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

  • Adatbázis- és rugalmaskészlet-konfigurációs adatok szinkronizálása a bérlői katalógusba
  • Helyreállítási környezet beállítása egy másik régióban, amely alkalmazásokból, kiszolgálókból és készletekből áll
  • Georeplikáció használata a katalógus és a bérlői adatbázisok replikálására a helyreállítási régióba
  • Az alkalmazás- és katalógus- és bérlői adatbázisok feladatátvétele a helyreállítási régióba
  • Később az alkalmazás,katalógus és bérlői adatbázisok feladatátvétele az eredeti régióba a szolgáltatáskimaradás feloldása után
  • Frissítse a katalógust, mivel a rendszer minden bérlői adatbázist átvesz, és nyomon követi az egyes bérlők adatbázisának elsődleges helyét
  • A késés csökkentése érdekében 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ó

Az oktatóanyag megkezdése előtt győződjön meg arról, hogy az alábbi előfeltételeknek megfelel:

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

Helyreállítási architektúra

A vészhelyreállítás (DR) számos alkalmazás esetében fontos szempont, akár megfelelőségi okokból, akár az üzletmenet folytonossága miatt. Ha hosszan tartó szolgáltatáskimaradást okoz, egy jól előkészített dr. terv minimalizálhatja az üzletkimaradást. A georeplikáció használata biztosítja a legalacsonyabb RPO-t és RTO-t azáltal, hogy az adatbázis-replikákat egy olyan helyreállítási régióban tartja, amelyről a rendszer rövid időn belül átveheti a adatokat.

A georeplikáción alapuló dr. terv három különálló 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 kimaradás esetén,
  • Újraküldetés – Az alkalmazás és az adatbázisok feladat-visszavétele az eredeti régióba az alkalmazás feloldása után

Minden részt alaposan meg kell vizsgálni, különösen akkor, ha nagy léptékben működik. A tervnek több cél elérésére is el kell érnie:

  • Telepítés
    • Tükrözött kép környezetének létrehozása és fenntartása 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 fenntartja a kapacitást a helyreállítási régióban. Ennek a környezetnek a fenntartása magában foglalja az új bérlői adatbázisok üzembe építésük szerinti replikálása.
  • Helyreállítási
    • Ha egy horizontálisan leskálált helyreállítási környezettel minimalizálják a napi költségeket, a készleteket és az adatbázisokat fel kell skálázni, hogy teljes működési kapacitást szerezzenek a helyreállítási régióban
    • Új bérlő üzembehelyezésének engedélyezése a helyreállítási régióban a lehető leghamarabb
    • A bérlők prioritási sorrendben való visszaállítására kell optimalizálni
    • A bérlőket úgy kell optimalizálni, hogy a lehető leghamarabb online állapotba legyenek ássa a lépéseket párhuzamosan, ahol ez a gyakorlatban is lehetséges
    • Ellenállónak kell lennie a meghibásodásokkal, az újraindítható és az idepotentokkal szemben
    • Félúton megszakíthatja a folyamatot, ha az eredeti régió újra online érkezik.
  • Hazaszállítás
    • Az adatbázisok feladatátvétele a helyreállítási régióból az eredeti régió replikáiba a bérlőkre gyakorolt minimális hatás mellett: nincs adatvesztés és bérlőnkénti minimális időszak.

Ebben az oktatóanyagban ezekkel a kihívásokkal foglalkozunk a Azure SQL Database és az Azure platform funkcióival:

  • Azure Resource Manager sablonokat,hogy a lehető leggyorsabban lefoglalja az összes szükséges kapacitást. Azure Resource Manager sablonokkal kiépíthet egy tükrözött képet az éles kiszolgálókról és a rugalmas készletekről a helyreállítási régióban.
  • Georeplikáció– aszinkron módon replikált, csak olvasható bináris fájlok létrehozása az összes adatbázishoz. Kimaradás esetén a rendszer feladatátvételt ad át a helyreállítási régióban található replikáknak. A kimaradás megoldása után adatvesztés nélkül visszaveszi a feladat-visszavételt az eredeti régióban található adatbázisokba.
  • A bérlői prioritási sorrendben elküldött aszinkron feladatátvételi műveletek, amelyek nagy számú adatbázis feladatátvételi idejét csökkentik.
  • A szegmenskezelés helyreállítási funkcióivalmódosíthatja a katalógus adatbázis-bejegyzését a helyreállítás és az újraparalógus során. Ezekkel a funkciókkal az alkalmazás helytől függetlenül csatlakozhat a bérlői adatbázisokhoz az alkalmazás újrakonfigurálása nélkül.
  • Az SQL Server DNS-aliasailehetővé teszik az új bérlők zökkenőmentes építését, függetlenül attól, hogy melyik régióban működik az alkalmazás. A DNS-aliasokkal a katalógusszinkronizálási folyamat helyétől függetlenül is csatlakozhat az aktív katalógushoz.

Vészhelyreállítási szkriptek leállítása

Fontos

Mint minden Wingtip Tickets felügyeleti szkript, a DR-szkriptek is mintaminőségek, és nem használhatók éles környezetben.

Az oktatóanyagban használt helyreállítási szkriptek és a Wingtip alkalmazás forráskódja bérlőnkénti GitHub-adattárban érhetők el a Wingtip Tickets SaaS-adatbázisban. Tekintse meg a Wingtip Tickets felügyeleti szkriptek letöltésének és feloldásának lépéseit az általános útmutatóban.

Az oktatóanyag áttekintése

Ebben az oktatóanyagban először georeplikációval hoz létre replikákat a Wingtip Tickets alkalmazásról és annak adatbázisairól egy másik régióban. Ezután feladatátvételt fog átveszni ebbe a régióba, hogy szimulálja a helyreállítást egy kimaradás után. Ha elkészült, az alkalmazás teljesen működőképes lesz a helyreállítási régióban.

Később egy külön újraparanálási lépésben feladatátvételt fog feladatátvételt a helyreállítási régióban található katalógus- és bérlői adatbázisokról az eredeti régióba. Az alkalmazás és az adatbázisok az újraparanálá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 annak a régiónak a párosított régiójába lesz helyreállítva, amelyben az alkalmazás üzembe van helyezni. További információ: Párosított Azure-régiók.

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

A helyreállítási folyamat elkezdé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 Events Hubot ( ;user .trafficmanager.net – cserélje le a felhasználót az üzemelő példány felhasználói http://events.wingtip-dpt.&lt > < > értékére).

    • Görgessen az oldal aljára, és figyelje meg a katalóguskiszolgáló nevét és helyét a láblécben. A hely az a régió, amelyben az alkalmazást üzembe helyezett. TIPP: Vigye az egérmutatót a hely fölé a megjelenítés nagyítása érdekében.  Az eseményközpont kifogástalan állapota az eredeti régióban
  2. Kattintson a Contoso Concert Hall bérlőre, és nyissa meg annak eseményoldalát.

    • A láblécben figyelje meg a bérlői kiszolgáló nevét. A hely megegyezik a katalóguskiszolgáló helyével.
  3. A Azure Portalnyissa meg azt az erőforráscsoportot, amelyben az alkalmazás üzembe van helyezni

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

Bérlői 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ői katalógusba. A folyamat naprakészen tartja 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 adatok a helyreállítási folyamat részeként használhatók annak érdekében, hogy a helyreállítási környezet konzisztens legyen az eredeti környezettel, majd az újraparanálás során később, hogy az eredeti régió konzisztens 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 ezekben az oktatóanyagokban helyi PowerShell-feladatokként vagy az ügyfél felhasználói bejelentkezése alatt futó munkamenetekként valósítjuk meg a szinkronizálási folyamatot és más hosszú ideig futó helyreállítási és újrafuttatási folyamatokat. A bejelentkezéskor kiadott hitelesítési jogkivonatok több óra után lejárnak, a feladatok pedig sikertelenek lesznek. Éles környezetben a hosszan futó folyamatokat megbízható Azure-szolgáltatásokként kell megvalósítani, amelyek szolgáltatásnév alatt futnak. Lásd: Azure PowerShell szolgáltatásnév létrehozásatanúsítvánnyal.

  1. A PowerShell ISE-ben nyissa meg a ...\Learning Modules\UserConfig.psm1 fájlt. Cserélje <resourcegroup> le <user> a 10. és a 11. sor és értékét az alkalmazás üzembe helyezésekor használt értékre. Mentse a fájlt!

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

    • $DemoScenario = 1, Indítson el egy háttér-feladatot, amely szinkronizálja a bérlői kiszolgálót és a készlet konfigurációs adatait a katalógusba
  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ása érdekében. Képernyőkép a bérlői erőforrások konfigurációjának szinkronizálása érdekében megnyitott új PowerShell-munkamenetről.

Hagyja futni a PowerShell-ablakot a háttérben, és folytassa az oktatóanyag további részében.

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 újraparalógus során úgy 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 együtt. Az újraparatálás során ezeket a módosításokat a rendszer az eredeti régióban található egyenértékű erőforrásokra alkalmazza.

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

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

Megjegyzés

Ez az oktatóanyag georeplikációs védelmet biztosít a Wingtip Tickets mintaalkalmazáshoz. Egy georeplikációt használó alkalmazás éles forgatókönyvében minden bérlő egy georeplikált adatbázissal lesz kiépítve a kezdeti környezetből. Lásd: Magas rendelkezésre álló szolgáltatások tervezése Azure SQL Database

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

    • $DemoScenario = 2, Tükrözött rendszerkép-helyreállítási környezet létrehozása, valamint katalógus- és bérlői adatbázisok replikálása
  2. A szkript futtatásához nyomja le az F5 billentyűt. Megnyílik egy új PowerShell-munkamenet a replikák létrehozásához. Szinkronizálási folyamat

Az alkalmazás normál állapotának áttekintése

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

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

  2. A helyreállítási erőforráscsoport erőforrásainak megismerése.

  3. Kattintson a Contoso Concert Hall adatbázisra a tenants1-dpt- < user > -recovery kiszolgálón. Kattintson a Geo-Replication a bal oldalon.

    Contoso Concert georeplikációs hivatkozás

Az Azure-régiók térképen figyelje meg az eredeti régióban található elsődleges és a helyreállítási régióban található másodlagos régió közötti georeplikációs kapcsolatot.

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

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

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

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

  2. Kényszerített feladatátvételt használ a helyreállítási régióban lévő katalógusadatbázison, hogy ez legyen az elsődleges adatbázis, és frissíti az activecatalog aliast, hogy a helyreállításikatalógus-kiszolgálóra mutasson.

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

  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, mielőtt a rendszer átveszi őket a rendszer.

  5. Frissíti a helyreállítási régióban található összes rugalmas készlet és replikált egyedi adatbázis konfigurációját, hogy tükrözzék az eredeti régió konfigurációját. (Erre a feladatra csak akkor van szükség, ha a helyreállítási környezetben található készleteket vagy replikált adatbázisokat a költségek csökkentése érdekében a normál működés során leskálák.

  6. Engedélyezi Traffic Manager webalkalmazás végpontját a helyreállítási régióban. A végpont engedélyezése lehetővé teszi, hogy az alkalmazás új bérlőket létesítsen. Ezen a ponton a meglévő bérlők még mindig offline állapotban vannak.

  7. Kérésköteteket küld az adatbázisok prioritási sorrendben való feladatátvételének kényszerítésében.

    • A kötegek úgy vannak rendszerezve, hogy az adatbázisok minden készletben párhuzamosan átveszve átesnek a feladatok.
    • A feladatátvételi kérések aszinkron műveletekkel lesznek elküldve, így gyorsan elküldhetőek, és egyszerre több kérés is feldolgozható.

    Megjegyzés

    Kimaradás esetén az eredeti régióban található elsődleges adatbázisok offline állapotban vannak. A másodlagos adatbázis kényszerített feladatátvétele megszakítja a kapcsolatot az elsődleges adatbázissal anélkül, hogy bármilyen fennmaradó várólistán lévő tranzakciót próbál alkalmazni. Az oktatóanyaghoz hasonló DR-próbaforgatókönyvben, ha a feladatátvétel során bármilyen frissítési tevékenység történik, adatvesztést okozhat. Később, az újraparatálás során, amikor a helyreállítási régió adatbázisai visszaveszi a feladatátvételt az eredeti régióba, a rendszer normál feladatátvételt használ annak biztosítására, hogy ne legyen adatvesztés.

  8. Figyeli a szolgáltatást, hogy megállapítsa, mikor lett átvetve az adatbázisok. Miután a bérlői adatbázist a rendszer átveszi, frissíti a katalógust, hogy rögzítse a bérlői adatbázis helyreállítási állapotát, és onlineként jelölje meg a bérlőt.

    • A bérlői adatbázisokat az alkalmazás akkor érheti el, ha a katalógusban meg vannak jelölve online.
    • A bérlői adatbázis sorverzió-értékeinek összegét a katalógus tárolja. Ez az érték ujjlenyomatként működik, amely lehetővé teszi, hogy az újraparanálási folyamat megállapítsa, hogy az adatbázis frissítve lett-e a helyreállítási régióban.

Futtassa a szkriptet a helyreállítási régióba való feladatátvételhez

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

  1. A PowerShell ISE-ban nyissa meg a ...\Learning 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 replikákra történő átveszési folyamatokkal
  2. A szkript futtatásához nyomja le az F5 billentyűt.

    • A szkript egy új PowerShell-ablakban nyílik meg, majd elindítja a párhuzamosan futó PowerShell-feladatok sorozatát. Ezek a feladatok átveszik a bérlői adatbázisokat a helyreállítási régióba.
    • A helyreállítási régió az az Azure-régióhoz társított párosított régió, amelyben az alkalmazást üzembe helyezett. További információ: Párosított Azure-régiók.
  3. Figyelje a helyreállítási folyamat állapotát a PowerShell-ablakban. feladatátvételi folyamat

Megjegyzés

A helyreállítási feladatok kódjának vizsgálatához tekintse át a PowerShell-szkripteket a ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\RecoveryJobs mappában.

Az alkalmazás állapotának áttekintése helyreállítás közben

Bár az alkalmazásvégpont le van tiltva a Traffic Manager, az alkalmazás nem érhető el. Miután a katalógust a rendszer átveszi a helyreállítási régióba, és az összes bérlő offline állapotúként van megjelölve, az alkalmazás újra online állapotba lesz hozva. Bár az alkalmazás elérhető, az egyes bérlők offline állapotban jelennek meg az eseményközpontban, amíg az adatbázis át nem megjelenik a teljes adatbázison. Fontos úgy tervezni az alkalmazást, hogy offline bérlői adatbázisokat kezeljen.

  1. A katalógus-adatbázis helyreállítása után azonnal frissítse a Wingtip Tickets Events Hubot a webböngészőben.
    • Figyelje meg, hogy a láblécben a katalóguskiszolgáló neve most már -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 offline állapotúként vannak megjelölve, és nem választhatók ki.

      Megjegyzés

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

      Eseményközpont offline

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

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

Még mielőtt az összes meglévő bérlői adatbázis meghibásodott volna, új bérlőket is kiépíthet a helyreállítási régióban.

  1. A PowerShell ISE-ban nyissa meg a ...\Learning 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ő üzembe építéséhez.

  3. Amikor befejeződik, megnyílik a Hawtbol Hall-események oldala a böngészőben. A láblécből figyelje meg, hogy a Hawtfül-adatbázis a helyreállítási régióban van kiépítve. Hawtfül Hall-események oldala

  4. A böngészőben frissítse a Wingtip Tickets Events Hub lapot, hogy lássa a Hawt automatikusan elérhető Hallot.

    • Ha anélkül létesíti ki a Hawthet Hallot, hogy megvárja 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

A helyreállítási folyamat befejeződése után az alkalmazás és az összes bérlő teljesen működőképes lesz a helyreállítási régióban.

  1. Ha a PowerShell-konzolablakban megjelenő állapot azt jelzi, hogy az összes bérlőt helyreállította, frissítse az eseményközpontot. A bérlők online jelennek meg, beleértve az új bérlőt, a Hawt online Hallot is.

    helyreállított és új bérlők az eseményközpontban

  2. A Azure Portalnyissa 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. 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 tenants1 kiszolgálók helyreállítási verziói a -recovery utótaggal. Az ezeken a kiszolgálókon található visszaállított katalógus- és bérlőadatbázisok mind az eredeti régióban használt neveket használják.

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

    • Az App Service events-wingtip-dpt- < recoveryregion > - < felhasználó&gt;, amely az Events alkalmazás helyreállítási példánya.

      Azure-beli helyreállítási erőforrások

  4. Nyissa meg a tenants2-dpt- < user > -recovery SQL Servert. Figyelje meg, hogy tartalmazza a hawthall adatbázist és a rugalmas készletet(Pool1). A hawthall 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 tenants1-dpt- user -recovery kiszolgáló Contoso Concert Hall < > adatbázisára. Kattintson a Geo-Replication a bal oldalon.

    Contoso-adatbázis feladatátvétel után

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

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

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

Az alkalmazás újrapatilitációja az eredeti éles régióba

Ez a feladat az alkalmazást az eredeti régióba is újraküldi. Valós helyzetben a kimaradás megoldása után kezdeményezheti az újraparanálást.

Az újraparanálási folyamat áttekintése

Újraparatatási architektúra

Az újraparanálási folyamat:

  1. Visszavonja a függőben lévő vagy az adatbázis-visszaállítási kéréseket.
  2. Frissíti az új bérlői aliast, hogy az a forrás régióban található bérlői kiszolgálóra mutasson. Ennek az aliasnak a módosítása biztosítja, hogy az új bérlők adatbázisai most a forrás régióban lesznek kiépítve.
  3. A módosított bérlői adatok eredeti régióba való berakása
  4. Prioritási sorrendben veszi át a bérlői adatbázisokat.

A feladatátvétel hatékonyan áthelyezi az adatbázist az eredeti régióba. Amikor az adatbázis meghibásodik, a nyitott kapcsolatok megszakadnak, és az adatbázis néhány másodpercig nem érhető el. Az alkalmazásokat újrapróbálkozási logikával kell megírni, hogy újra csatlakoznak. Bár ez a rövid leválasztás gyakran nem fordul elő, dönthet úgy, hogy munkaidőn túl is átveszi az adatbázisokat.

A repatriációs szkript futtatása

Most tegyük fel, hogy a kimaradás megoldódott, és futtassa az újraparanáló szkriptet.

  1. A PowerShell ISE fájlban, a ...\Learning 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ányában. Ha szükséges, indítsa újra a következő beállítással:

    • $DemoScenario = 1, Kezdje el szinkronizálni a bérlői kiszolgálót, a készletet és az adatbázis konfigurációs adatait a katalógusba
    • A szkript futtatásához nyomja le az F5 billentyűt.
  3. Ezután a következő beállítással indítsa el az újraparanálási folyamatot:

    • $DemoScenario = 6, Az alkalmazás visszapatriasztás az eredeti régióba
    • Nyomja le az F5 billentyűt a helyreállítási szkript új PowerShell-ablakban való futtatásához. Az újraparanálás több percig is eltarthat, és a PowerShell-ablakban figyelhető. Újraparanálási folyamat
  4. Amíg a szkript fut, frissítse az Eseményközpont lapot ( http://events.wingtip-dpt.&lt ;felhasználói > .trafficmanager.net)

    • Figyelje meg, hogy a folyamat során az összes bérlő online állapotban van és elérhető.
  5. Az újraparanálás befejezése után frissítse az Eseményközpontot, és nyissa meg Hawthub Hall eseményoldalát. Figyelje meg, hogy ez az adatbázis az eredeti régióba lett visszavetve. Újratért eseményközpont

Az alkalmazás megtervezése az alkalmazás és az adatbázis közös kapcsolatának biztosításához

Az alkalmazás úgy lett kialakítva, hogy mindig a bérlői adatbázissal azonos régióban található példányró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 azt feltételezi, hogy az alkalmazás és az adatbázis közötti interakció nagyobb, mint a felhasználó és az alkalmazás közötti interakció.

A bérlői adatbázisok az újraparatriálás során egy ideig elterjedhetnek a helyreállítási és az eredeti régiókban. Az alkalmazás minden adatbázishoz megkeresi azt a régiót, amelyben az adatbázis található, dns-keresés használatával a bérlői kiszolgáló neve alapján. A SQL Database a kiszolgáló neve egy alias. Az aliasnév a régió nevét tartalmazza. Ha az alkalmazás nem ugyanabban a régióban van, mint az adatbázis, a kiszolgálóval azonos régióban található példányra irányítja át. Az adatbázissal azonos régióban található 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.

Következő lépések

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

  • Adatbázis- és rugalmaskészlet-konfigurációs adatok szinkronizálása a bérlői katalógusba
  • Helyreállítási környezet beállítása egy másik régióban, amely alkalmazásokból, kiszolgálókból és készletekből áll
  • Georeplikáció használata a katalógus és a bérlői adatbázisok replikálására a helyreállítási régióba
  • Az alkalmazás- és katalógus- és bérlői adatbázisok feladatátvétele a helyreállítási régióba
  • Az alkalmazás-, katalógus- és bérlői adatbázisok feladat-visszavétele az eredeti régióba a szolgáltatáskimaradás feloldása után

Az üzletmenet folytonosságának biztosításához szükséges technológiákról Azure SQL Database az Üzletmenet-folytonosság – áttekintés dokumentációjában talál további információt.

További források