Správa postupných upgradů cloudových aplikací pomocí aktivní geografické replikace služby SQL Database

Platí pro:Azure SQL Database

Naučte se používat aktivní geografickou replikaci ve službě Azure SQL Database k povolení postupných upgradů cloudové aplikace. Vzhledem k tomu, že upgrady jsou rušivé operace, měly by být součástí plánování a návrhu provozní kontinuity. V tomto článku se podíváme na dvě různé metody orchestrace procesu upgradu a probereme výhody a kompromisy jednotlivých možností. Pro účely tohoto článku odkazujeme na aplikaci, která se skládá z webu připojeného k jedné databázi jako její datové vrstvy. Naším cílem je upgradovat verzi 1 (V1) aplikace na verzi 2 (V2), aniž by to mělo významný dopad na uživatelské prostředí.

Při vyhodnocování možností upgradu zvažte tyto faktory:

• Dopad na dostupnost aplikace během upgradů, například jak dlouho můžou být funkce aplikací omezené nebo degradované.
• Možnost vrátit se zpět, pokud se upgrade nezdaří.
• Ohrožení zabezpečení aplikace v případě, že nesouvisí, dojde během upgradu k závažné chybě.
• Celkové náklady na dolar. Tento faktor zahrnuje další redundanci databáze a přírůstkové náklady na dočasné komponenty používané procesem upgradu.

Upgradujte aplikace, které spoléhají na zálohy databáze pro zotavení po havárii.

Pokud vaše aplikace využívá automatické zálohy databáze a používá geografické obnovení pro zotavení po havárii, nasadí se do jedné oblasti Azure. Pokud chcete minimalizovat přerušení uživatelů, vytvořte v této oblasti přípravné prostředí se všemi komponentami aplikace, které jsou součástí upgradu. První diagram znázorňuje provozní prostředí před procesem upgradu. Koncový bod contoso.azurewebsites.net představuje produkční prostředí webové aplikace. Abyste mohli vrátit upgrade zpět, musíte vytvořit přípravné prostředí s plně synchronizovanou kopií databáze. Při vytváření přípravného prostředí pro upgrade postupujte takto:

1. Vytvořte sekundární databázi ve stejné oblasti Azure. Monitorujte sekundární proces a zjistěte, jestli je proces počátečního zpracování dokončen (1).
2. Vytvořte nové prostředí pro webovou aplikaci a pojmenujte ho "Příprava". Bude zaregistrovaný v Azure DNS s adresou URL contoso-staging.azurewebsites.net (2).

Poznámka:

Tyto přípravné kroky nebudou mít vliv na produkční prostředí, které může fungovat v režimu úplného přístupu.

Po dokončení přípravného postupu je aplikace připravená na skutečný upgrade. Následující diagram znázorňuje kroky, které jsou součástí procesu upgradu:

1. Nastavte primární databázi na režim jen pro čtení (3). Tento režim zaručuje, že produkční prostředí webové aplikace (V1) zůstane během upgradu jen pro čtení, což brání rozdílu dat mezi instancemi databáze V1 a V2.
2. Odpojte sekundární databázi pomocí plánovaného režimu ukončení (4). Tato akce vytvoří plně synchronizovanou nezávislou kopii primární databáze. Tato databáze bude upgradována.
3. Přepněte sekundární databázi do režimu čtení a zápisu a spusťte skript upgradu (5).

Pokud se upgrade úspěšně dokončí, jste připraveni přepnout uživatele na upgradovanou kopii aplikace, která se stane produkčním prostředím. Přepnutí zahrnuje několik dalších kroků, jak je znázorněno v dalším diagramu:

1. Aktivace operace prohození mezi produkčním a přípravovým prostředím webové aplikace (6). Tato operace přepne adresy URL obou prostředí. Nyní contoso.azurewebsites.net odkazuje na verzi webu V2 a databázi (produkční prostředí).
2. Pokud už verzi V1 nepotřebujete, která se po prohození stala přípravnou kopií, můžete pracovní prostředí vyřadit z provozu (7).

Pokud proces upgradu není úspěšný (například kvůli chybě ve skriptu upgradu), zvažte ohrožení přípravného prostředí. Pokud chcete vrátit aplikaci zpět do stavu před upgradem, vraťte aplikaci v produkčním prostředí k úplnému přístupu. Další diagram znázorňuje kroky pro reverzi:

1. Nastavte kopii databáze do režimu čtení a zápisu (8). Tato akce obnoví úplnou funkci V1 produkční kopie.
2. Proveďte analýzu původní příčiny a vyřate přípravné prostředí z provozu (9).

V tomto okamžiku je aplikace plně funkční a můžete opakovat kroky upgradu.

Poznámka:

Vrácení zpět nevyžaduje změny DNS, protože jste ještě neprokončili operaci prohození.

Klíčovou výhodou této možnosti je, že můžete upgradovat aplikaci v jedné oblasti pomocí sady jednoduchých kroků. Dolarové náklady na upgrade jsou relativně nízké.

Hlavním kompromisem je, že pokud během upgradu dojde k závažnému selhání, obnovení do stavu před upgradem zahrnuje opětovné nasazení aplikace v jiné oblasti a obnovení databáze ze zálohy pomocí geografického obnovení. Výsledkem tohoto procesu je výrazný výpadek.

Upgrade aplikací, které se spoléhají na geografickou replikaci databáze pro zotavení po havárii

Pokud vaše aplikace používá aktivní geografickou replikaci nebo skupiny převzetí služeb při selhání pro provozní kontinuitu, nasadí se alespoň do dvou různých oblastí. V primární oblasti je aktivní primární databáze a sekundární databáze jen pro čtení v zálohované oblasti. Spolu s faktory uvedenými na začátku tohoto článku musí proces upgradu také zaručit, že:

• Aplikace zůstává během procesu upgradu chráněná před katastrofickými selháními.
• Geograficky redundantní komponenty aplikace se upgradují paralelně s aktivními komponentami.

K dosažení těchto cílů využijete kromě použití prostředí Web Apps také azure Traffic Manager pomocí profilu převzetí služeb při selhání s jedním aktivním koncovým bodem a jedním koncovým bodem zálohování. Následující diagram znázorňuje provozní prostředí před procesem upgradu. Weby contoso-1.azurewebsites.net a contoso-dr.azurewebsites.net představují produkční prostředí aplikace s plnou geografickou redundancí. Produkční prostředí zahrnuje následující komponenty:

• Produkční prostředí webové aplikace contoso-1.azurewebsites.net v primární oblasti (1)
• Primární databáze v primární oblasti (2)
• Pohotovostní instance webové aplikace v oblasti zálohování (3)
• Geograficky replikovaná sekundární databáze v oblasti zálohování (4)
• Profil výkonu Traffic Manageru s volaným contoso-1.azurewebsites.net online koncovým bodem a s názvem offline koncového bodu contoso-dr.azurewebsites.net

Aby bylo možné vrátit upgrade zpět, musíte vytvořit přípravné prostředí s plně synchronizovanou kopií aplikace. Protože potřebujete zajistit, aby se aplikace v případě závažného selhání během procesu upgradu rychle obnovila, musí být přípravné prostředí také geograficky redundantní. K vytvoření přípravného prostředí pro upgrade jsou potřeba následující kroky:

1. Nasazení přípravného prostředí webové aplikace v primární oblasti (6)
2. Vytvořte sekundární databázi v primární oblasti Azure (7). Nakonfigurujte přípravné prostředí webové aplikace, aby se k ní připojilo.
3. Vytvořte další geograficky redundantní sekundární databázi v oblasti zálohování tím, že replikuje sekundární databázi v primární oblasti. (Tato metoda se nazývá zřetězený geografická replikace.) (8).
4. Nasaďte přípravné prostředí instance webové aplikace v oblasti zálohování (9) a nakonfigurujte ji tak, aby připojila geograficky redundantní sekundární databázi vytvořenou v (8).

Poznámka:

Tyto přípravné kroky nebudou mít vliv na aplikaci v produkčním prostředí. Zůstane plně funkční v režimu čtení i zápisu.

Po dokončení přípravných kroků je přípravné prostředí připravené na upgrade. Následující diagram znázorňuje tyto kroky upgradu:

1. Nastavte primární databázi v produkčním prostředí na režim jen pro čtení (10). Tento režim zaručuje, že se produkční databáze (V1) během upgradu nezmění, čímž zabrání rozdílu dat mezi instancemi databáze V1 a V2.

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

2. Ukončete geografickou replikaci odpojením sekundární replikace (11). Tato akce vytvoří nezávislou, ale plně synchronizovanou kopii produkční databáze. Tato databáze bude upgradována. Následující příklad používá Jazyk Transact-SQL, ale PowerShell je k dispozici také.

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

3. Spusťte skript upgradu na contoso-1-staging.azurewebsites.net, contoso-dr-staging.azurewebsites.neta přípravnou primární databázi (12). Změny databáze se automaticky replikují do přípravné sekundární.

Pokud se upgrade úspěšně dokončí, jste připraveni přepnout uživatele na verzi V2 aplikace. Následující diagram znázorňuje příslušné kroky:

1. Aktivace operace prohození mezi produkčním a přípravovým prostředím webové aplikace v primární oblasti (13) a v oblasti zálohování (14). V2 aplikace se teď stane produkčním prostředím s redundantní kopií v oblasti zálohování.
2. Pokud už aplikaci V1 (15 a 16) nepotřebujete, můžete přípravné prostředí vyřadit z provozu.

Pokud proces upgradu není úspěšný (například kvůli chybě ve skriptu upgradu), zvažte, jestli je přípravné prostředí v nekonzistentním stavu. Pokud chcete vrátit aplikaci do stavu před upgradem, vraťte se k použití verze 1 aplikace v produkčním prostředí. Požadované kroky se zobrazí v dalším diagramu:

1. Nastavte primární kopii databáze v produkčním prostředí na režim čtení a zápisu (17). Tato akce obnoví úplné funkce V1 v produkčním prostředí.
2. Proveďte analýzu a opravu původní příčiny nebo odeberte přípravné prostředí (18 a 19).

V tomto okamžiku je aplikace plně funkční a můžete opakovat kroky upgradu.

Poznámka:

Vrácení zpět nevyžaduje změny DNS, protože jste neprohodili operaci prohození.

Klíčovou výhodou této možnosti je, že můžete upgradovat aplikaci i její geograficky redundantní kopii paralelně, aniž byste během upgradu ovlivnili provozní kontinuitu.

Hlavním kompromisem je, že vyžaduje dvojitou redundanci každé komponenty aplikace, a proto se účtují vyšší dolarové náklady. Zahrnuje také složitější pracovní postup.

Shrnutí

Dvě metody upgradu popsané v článku se liší v složitosti a dolarových nákladech, ale oba se zaměřují na minimalizaci doby, po kterou je uživatel omezen na operace jen pro čtení. Tento čas je přímo definován dobou trvání skriptu upgradu. Nezávisí na velikosti databáze, zvolené úrovni služby, konfiguraci webu nebo jiných faktorech, které nemůžete snadno ovládat. Všechny přípravné kroky jsou oddělené od kroků upgradu a nemají vliv na produkční aplikaci. Efektivita skriptu upgradu je klíčovým faktorem, který určuje uživatelské prostředí během upgradů. Nejlepší způsob, jak toto prostředí vylepšit, je zaměřit se na co nejefektivnější upgrade skriptu.

Související obsah

• Přehled kontinuity podnikových procesů
• Umožňuje vytvářet čitelné sekundární databáze pomocí aktivní geografické replikace.
• Pomocí skupin převzetí služeb při selhání můžete povolit transparentní a koordinované převzetí služeb při selhání více databází.
• Nastavte přípravná prostředí ve službě Aplikace Azure Service.
• Správa profilu Azure Traffic Manageru