Felhőalkalmazások működés közbeni frissítéseinek kezelése az SQL Database aktív georeplikációjának használatával

A következőre vonatkozik: Azure SQL Database

Megtudhatja, hogyan használhat aktív georeplikációt az Azure SQL Database-ben a felhőalkalmazás működés közbeni frissítéseinek engedélyezéséhez. Mivel a frissítések zavaró műveletek, az üzletmenet-folytonosság tervezésének és tervezésének részét kell képezniük. Ebben a cikkben a frissítési folyamat vezénylésének két különböző módszerét tekintjük át, és az egyes lehetőségek előnyeit és kompromisszumait tárgyaljuk. A cikk alkalmazásában egy olyan alkalmazásra hivatkozunk, amely egy olyan webhelyből áll, amely egyetlen adatbázishoz csatlakozik adatszintként. Célunk, hogy az alkalmazás 1. (V1) verzióját a 2. verzióra (V2) frissítsük anélkül, hogy jelentős hatással lenne a felhasználói élményre.

A frissítési lehetőségek kiértékelésekor vegye figyelembe az alábbi tényezőket:

• Az alkalmazás rendelkezésre állására gyakorolt hatás a frissítések során, például hogy az alkalmazásfüggvények mennyi ideig lehetnek korlátozottak vagy csökkentek.
• Visszaválás lehetősége, ha a frissítés sikertelen.
• Az alkalmazás biztonsági rése, ha a frissítés során nem kapcsolódó, katasztrofális hiba történik.
• Teljes dollárköltség. Ez a tényező további adatbázis-redundanciát és a frissítési folyamat által használt ideiglenes összetevők növekményes költségeit is magában foglalja.

Adatbázis biztonsági mentésére támaszkodó alkalmazások frissítése vészhelyreállításhoz

Ha az alkalmazás automatikus adatbázis-biztonsági mentésekre támaszkodik, és georedundáns visszaállítást használ a vészhelyreállításhoz, az egyetlen Azure-régióban lesz üzembe helyezve. A felhasználói fennakadások minimalizálása érdekében hozzon létre egy átmeneti környezetet az adott régióban a frissítésben érintett összes alkalmazásösszetevővel együtt. Az első ábra a frissítési folyamat előtti működési környezetet mutatja be. A végpont contoso.azurewebsites.net a webalkalmazás éles környezetét jelöli. A frissítés visszaállításához létre kell hoznia egy átmeneti környezetet az adatbázis teljes mértékben szinkronizált példányával. Az alábbi lépéseket követve hozzon létre átmeneti környezetet a frissítéshez:

1. Hozzon létre egy másodlagos adatbázist ugyanabban az Azure-régióban. Figyelje meg a másodlagost, és ellenőrizze, hogy a vetés folyamata befejeződött-e (1).
2. Hozzon létre egy új környezetet a webalkalmazáshoz, és nevezd "előkészítésnek". A rendszer regisztrálja az Azure DNS-ben a (2) URL-címmel contoso-staging.azurewebsites.net .

Megjegyzés:

Ezek az előkészítési lépések nem befolyásolják az éles környezetet, amely teljes hozzáférésű módban működhet.

Ha az előkészítési lépések befejeződnek, az alkalmazás készen áll a tényleges frissítésre. A következő ábra a frissítési folyamat lépéseit mutatja be:

1. Állítsa be az elsődleges adatbázist írásvédett üzemmódra (3). Ez a mód garantálja, hogy a webalkalmazás (V1) éles környezete írásvédett marad a frissítés során, így megakadályozza az adateltérést a V1 és a V2 adatbázispéldányok között.
2. Bontsa le a másodlagos adatbázist a tervezett leállítási mód (4) használatával. Ez a művelet létrehoz egy teljes mértékben szinkronizált, független másolatot az elsődleges adatbázisról. Ez az adatbázis frissítve lesz.
3. Kapcsolja be a másodlagos adatbázist olvasási-írási módba, és futtassa a frissítési szkriptet (5).

Ha a frissítés sikeresen befejeződött, készen áll arra, hogy a felhasználókat az alkalmazás frissített példányára váltsa, amely éles környezet lesz. A váltás néhány további lépést is magában foglal, ahogyan azt a következő diagram is szemlélteti:

1. Csereművelet aktiválása a webalkalmazás éles és átmeneti környezetei között (6). Ez a művelet a két környezet URL-címeit váltja át. Most contoso.azurewebsites.net a webhely és az adatbázis (éles környezet) V2-es verziójára mutat.
2. Ha már nincs szüksége a V1-es verzióra, amely a csere után átmeneti példánysá vált, az előkészítési környezetet (7) leszerelheti.

Ha a frissítési folyamat sikertelen (például a frissítési szkript hibája miatt), fontolja meg az előkészítési környezet sérülését. Az alkalmazás frissítés előtti állapotba való visszaállításához állítsa vissza az éles környezetben lévő alkalmazást teljes hozzáférésre. A következő diagram a reverzió lépéseit mutatja be:

1. Állítsa be az adatbázis másolását írási módra (8). Ez a művelet visszaállítja az éles példány teljes V1-funkcióját.
2. Végezze el a kiváltó okok elemzését, és szerelje le az átmeneti környezetet (9).

Ezen a ponton az alkalmazás teljesen működőképes, és megismételheti a frissítési lépéseket.

Megjegyzés:

A visszaállítás nem igényel DNS-módosításokat, mert még nem hajtott végre felcserélési műveletet.

Ennek a lehetőségnek a fő előnye, hogy egyetlen régióban frissíthet alkalmazásokat egyszerű lépések végrehajtásával. A frissítés dollárköltsége viszonylag alacsony.

A fő kompromisszum az, hogy ha a frissítés során katasztrofális hiba történik, a frissítés előtti állapotra való helyreállítás magában foglalja az alkalmazás egy másik régióban való ismételt üzembe helyezését és az adatbázis biztonsági mentésből való visszaállítását georedundáns visszaállítással. Ez a folyamat jelentős állásidőt eredményez.

Adatbázis georeplikációjára támaszkodó alkalmazások frissítése vészhelyreállításhoz

Ha az alkalmazás aktív georeplikációs vagy feladatátvételi csoportokat használ az üzletmenet folytonossága érdekében, legalább két különböző régióban üzembe helyezi. Van egy aktív elsődleges adatbázis egy elsődleges régióban, és egy írásvédett másodlagos adatbázis egy biztonsági mentési régióban. A cikk elején említett tényezők mellett a frissítési folyamatnak a következőket is garantálnia kell:

• Az alkalmazás a frissítési folyamat során mindig védett marad a katasztrofális hibáktól.
• Az alkalmazás georedundáns összetevői az aktív összetevőkkel párhuzamosan frissülnek.

E célok elérése érdekében a Web Apps-környezetek használata mellett az Azure Traffic Manager előnyeit is kihasználhatja egy feladatátvételi profillal egy aktív végponttal és egy biztonsági mentési végponttal. A következő ábra a frissítési folyamat előtti működési környezetet mutatja be. A webhelyek contoso-1.azurewebsites.net és contoso-dr.azurewebsites.net az alkalmazás éles környezetét képviselik teljes földrajzi redundanciával. Az éles környezet a következő összetevőket tartalmazza:

• A webalkalmazás contoso-1.azurewebsites.net éles környezete az elsődleges régióban (1)
• Az elsődleges adatbázis az elsődleges régióban (2)
• A webalkalmazás készenléti példánya a biztonsági mentési régióban (3)
• A biztonsági mentési régió georeplikált másodlagos adatbázisa (4)
• Traffic Manager-teljesítményprofil egy online végponttal contoso-1.azurewebsites.net és egy offline végponttal contoso-dr.azurewebsites.net

A frissítés visszaállításához létre kell hoznia egy átmeneti környezetet az alkalmazás teljes mértékben szinkronizált példányával. Mivel gondoskodnia kell arról, hogy az alkalmazás gyorsan helyreálljon, ha a frissítési folyamat során katasztrofális hiba történik, az átmeneti környezetnek georedundánsnak is kell lennie. A frissítés átmeneti környezetének létrehozásához a következő lépések szükségesek:

1. A webalkalmazás átmeneti környezetének üzembe helyezése az elsődleges régióban (6).
2. Másodlagos adatbázis létrehozása az elsődleges Azure-régióban (7). Konfigurálja a webalkalmazás átmeneti környezetét a csatlakozáshoz.
3. Hozzon létre egy másik georedundáns másodlagos adatbázist a biztonsági mentési régióban a másodlagos adatbázis replikálásával az elsődleges régióban. (Ezt a módszert láncolt georeplikációs módszernek nevezzük.) (8).
4. Telepítse a webalkalmazás-példány átmeneti környezetét a biztonsági mentési régióban (9), és konfigurálja a (8) helyen létrehozott georedundáns másodlagos adatbázis csatlakoztatásához.

Megjegyzés:

Ezek az előkészítési lépések nem lesznek hatással az éles környezetben lévő alkalmazásra. Írási módban továbbra is teljesen működőképes marad.

Az előkészítési lépések elvégzése után az előkészítési környezet készen áll a frissítésre. A következő diagram az alábbi frissítési lépéseket mutatja be:

1. Állítsa be az elsődleges adatbázist az éles környezetben írásvédett üzemmódra (10). Ez a mód garantálja, hogy az éles adatbázis (V1) nem változik a frissítés során, így megakadályozza az adateltérést a V1 és a V2 adatbázispéldányok között.

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. Állítsa le a georeplikálást a másodlagos (11) leválasztásával. Ez a művelet létrehozza az éles adatbázis független, de teljes mértékben szinkronizált példányát. Ez az adatbázis frissítve lesz. Az alábbi példa a Transact-SQL-t használja, de a PowerShell is elérhető.

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. Futtassa a frissítési szkriptet contoso-1-staging.azurewebsites.netaz , contoso-dr-staging.azurewebsites.netés az átmeneti elsődleges adatbázison (12). Az adatbázis módosításait a rendszer automatikusan replikálja az átmeneti másodlagosra.

Ha a frissítés sikeresen befejeződött, készen áll arra, hogy a felhasználókat az alkalmazás V2-es verziójára váltsa. A következő diagram az alábbi lépéseket mutatja be:

1. Csereművelet aktiválása a webalkalmazás éles és átmeneti környezetei között az elsődleges régióban (13) és a biztonsági mentési régióban (14). Az alkalmazás V2-jének most már éles környezete lesz, és redundáns másolat található a biztonsági mentési régióban.
2. Ha már nincs szüksége a V1-alkalmazásra (15 és 16), az előkészítési környezetet leszerelheti.

Ha a frissítési folyamat sikertelen (például a frissítési szkript hibája miatt), vegye figyelembe, hogy az átmeneti környezet inkonzisztens állapotban van. Ha vissza szeretné állítani az alkalmazást a frissítés előtti állapotba, térjen vissza az alkalmazás V1-re az éles környezetben. A szükséges lépések a következő diagramon láthatók:

1. Állítsa be az elsődleges adatbázis-példányt az éles környezetben olvasási-írási módra (17). Ez a művelet visszaállítja a teljes V1-funkciót az éles környezetben.
2. Végezze el a kiváltó okok elemzését, és javítsa ki vagy távolítsa el az átmeneti környezetet (18 és 19).

Ezen a ponton az alkalmazás teljesen működőképes, és megismételheti a frissítési lépéseket.

Megjegyzés:

A visszaállítás nem igényel DNS-módosításokat, mert nem hajtott végre felcserélési műveletet.

Ennek a lehetőségnek a fő előnye, hogy párhuzamosan frissítheti az alkalmazást és annak georedundáns példányát anélkül, hogy veszélyeztetné az üzletmenet folytonosságát a frissítés során.

A fő kompromisszum az, hogy az egyes alkalmazásösszetevők dupla redundanciára van szükség, ezért magasabb dollárköltséggel jár. Ez egy bonyolultabb munkafolyamatot is magában foglal.

Összesítés

A cikkben ismertetett két frissítési módszer összetettségében és dollárköltségében különbözik, de mindkettő a felhasználó írásvédett műveleteinek minimálisra korlátozására összpontosít. Ezt az időt közvetlenül a frissítési szkript időtartama határozza meg. Ez nem függ az adatbázis méretétől, a választott szolgáltatási szinttől, a webhely konfigurációjától vagy más olyan tényezőktől, amelyeket nem lehet könnyen szabályozni. Az összes előkészítési lépés leválasztva van a frissítési lépésekről, és nincs hatással az éles alkalmazásra. A frissítési szkript hatékonysága kulcsfontosságú tényező, amely meghatározza a felhasználói élményt a frissítések során. Így a legjobb módja annak, hogy javítsa ezt a élményt, ha arra összpontosítja erőfeszítéseit, hogy a frissítési szkript a lehető leghatékonyabb legyen.

Kapcsolódó tartalom

• Üzletmenet-folytonosság áttekintése.
• Olvasható másodlagos adatbázisok létrehozása aktív georeplikációs módszerrel.
• Több adatbázis transzparens és koordinált feladatátvételének engedélyezése feladatátvételi csoportok használatával.
• Átmeneti környezetek beállítása Azure-alkalmazás Szolgáltatásban.
• Azure Traffic Manager-profil kezelése.