Použití geografického obnovení k obnovení víceklientské aplikace SaaS ze záloh databáze

Platí pro: Azure SQL Database

V tomto kurzu se seznámíte se scénářem úplného zotavení po havárii pro víceklientské aplikace SaaS implementované s databází na model tenanta. Geografické obnovení slouží k obnovení katalogu a databází tenantů z automaticky udržovaných geograficky redundantních záloh do alternativní oblasti obnovení. Po vyřešení výpadku použijete geografickou replikaci k repatriaci změněných databází do původní oblasti.

Geografické obnovení je řešení pro zotavení po havárii s nejnižšími náklady pro Azure SQL Database. Obnovení z geograficky redundantních záloh ale může způsobit ztrátu dat až jednu hodinu. V závislosti na velikosti každé databáze to může trvat poměrně dlouho.

Poznámka:

Obnovte aplikace s nejnižší možnou hodnotou RPO a RTO pomocí geografické replikace místo geografického obnovení.

V tomto kurzu se seznámíte s pracovními postupy obnovení i opakování. Získáte informace pro:

• Synchronizujte informace o konfiguraci databáze a elastického fondu do katalogu tenantů.
• Nastavte prostředí zrcadlové image v oblasti obnovení, která zahrnuje aplikace, servery a fondy.
• Obnovte katalog a databáze tenantů pomocí geografického obnovení.
• Geografická replikace slouží k obnovení katalogu tenantů a změně databází tenantů po vyřešení výpadku.
• Aktualizujte katalog při obnovení (nebo opakování) katalogu, abyste mohli sledovat aktuální umístění aktivní kopie databáze každého tenanta.
• Zajistěte, aby se aplikace a databáze tenanta vždy nacházely ve stejné oblasti Azure, aby se snížila latence.

Než začnete s tímto kurzem, proveďte následující požadavky:

• Nasaďte databázi SaaS Wingtip Tickets na aplikaci tenanta. Pokud chcete nasadit méně než pět minut, přečtěte si téma Nasazení a prozkoumání databáze SaaS Wingtip Tickets na aplikaci tenanta.
• Nainstalujte Azure PowerShell. Podrobnosti najdete v tématu Začínáme s Azure PowerShellem.

Úvod do modelu obnovení geografického obnovení

Zotavení po havárii (DR) je důležitým aspektem pro mnoho aplikací, ať už z důvodů dodržování předpisů nebo provozní kontinuity. Pokud dojde k dlouhodobému výpadku služby, dobře připravený plán zotavení po havárii může minimalizovat přerušení provozu. Plán zotavení po havárii založený na geografickém obnovení musí dosáhnout několika cílů:

• Zarezervujte si veškerou potřebnou kapacitu ve zvolené oblasti obnovení co nejrychleji, abyste měli jistotu, že je k dispozici pro obnovení databází tenantů.
• Vytvořte prostředí pro obnovení zrcadlové image, které odráží původní konfiguraci fondu a databáze.
• Pokud se původní oblast vrátí do online režimu, povolte zrušení procesu obnovení v polovině testovací verze.
• Rychle povolte zřizování tenantů, aby se nové nasazení tenanta co nejdříve restartoval.
• Optimalizace pro obnovení tenantů v pořadí priority.
• Pokud je to praktické, optimalizujte je tak, aby bylo možné co nejdříve získat tenanty online.
• Buďte odolní vůči selhání, restartování a idempotentnímu.
• Po vyřešení výpadku znovu obnovte databáze do původní oblasti s minimálním dopadem na tenanty.

Poznámka:

Aplikace se obnoví do spárované oblasti oblasti, ve které je aplikace nasazená. Další informace najdete v tématu Spárované oblasti Azure.

Tento kurz používá funkce Azure SQL Database a platformy Azure k řešení těchto problémů:

• Šablony Azure Resource Manageru pro co nejrychlejší rezervaci všech potřebných kapacit Šablony Azure Resource Manageru slouží ke zřízení zrcadlové image původních serverů a elastických fondů v oblasti obnovení. Pro zřizování nových tenantů se vytvoří také samostatný server a fond.
• Klientská knihovna elastické databáze (EDCL) pro vytvoření a údržbu katalogu databáze tenanta. Rozšířený katalog obsahuje pravidelně aktualizované informace o konfiguraci fondu a databáze.
• Funkce obnovení správy horizontálních oddílů seznamu EDCL za účelem údržby položek umístění databáze v katalogu během obnovení a opakování
• Geografické obnovení pro obnovení katalogu a databází tenantů z automaticky udržovaných geograficky redundantních záloh.
• Asynchronní operace obnovení odeslané v pořadí priority tenanta se zařadí do fronty pro každý fond systémem a zpracovávají se v dávkách, takže fond není přetížený. Tyto operace lze v případě potřeby zrušit před spuštěním nebo během nich.
• Geografická replikace, která po výpadku repatriauje databáze do původní oblasti. Při použití geografické replikace nedojde ke ztrátě dat a minimálnímu dopadu na tenanta.
• Aliasy DNS sql serveru, které umožňují procesu synchronizace katalogu připojit se k aktivnímu katalogu bez ohledu na jeho umístění.

Získání skriptů pro zotavení po havárii

Skripty zotavení po havárii použité v tomto kurzu jsou k dispozici v databázi Wingtip Tickets SaaS na úložiště GitHub tenanta. Projděte si obecné pokyny ke stažení a odblokování skriptů pro správu Wingtip Tickets.

Důležité

Stejně jako všechny skripty pro správu Wingtip Tickets jsou skripty zotavení po havárii ukázkovou kvalitou a nedají se použít v produkčním prostředí.

Kontrola stavu aplikace v pořádku

Před zahájením procesu obnovení zkontrolujte normální stav v pořádku aplikace.

1. Ve webovém prohlížeči otevřete centrum událostí Wingtip Tickets (http://events.wingtip-dpt.<user.trafficmanager.net>, nahraďte <uživatele> hodnotou uživatele vašeho nasazení).

   Posuňte se do dolní části stránky a všimněte si názvu serveru katalogu a umístění v zápatí. Umístění je oblast, ve které jste nasadili aplikaci.

   Tip

   Když najedete myší na místo, zvětšíte zobrazení.

   

2. Vyberte tenanta koncertu Contoso a otevřete stránku události.

   V zápatí si všimněte názvu serveru tenanta. Umístění je stejné jako umístění serveru katalogu.

   

3. Na webu Azure Portal zkontrolujte a otevřete skupinu prostředků, ve které jste aplikaci nasadili.

   Všimněte si prostředků a oblasti, ve které jsou nasazené komponenty služby App Service a SQL Database.

Synchronizace konfigurace tenanta do katalogu

V této úloze spustíte proces synchronizace konfigurace serverů, elastických fondů a databází do katalogu tenantů. Tyto informace se později použijí ke konfiguraci prostředí zrcadlové image v oblasti obnovení.

Důležité

Pro zjednodušení se proces synchronizace a další dlouhotrvající procesy obnovení a opakování implementují v těchto ukázkách jako místní úlohy nebo relace PowerShellu, které běží pod přihlášením uživatele klienta. Ověřovací tokeny vydané při přihlášení vyprší po několika hodinách a úlohy se pak nezdaří. V produkčním scénáři by se dlouhotrvající procesy měly implementovat jako spolehlivé služby Azure nějakého druhu spuštěné v rámci instančního objektu. Viz Použití Azure PowerShellu k vytvoření instančního objektu s certifikátem.

1. V prostředí PowerShell ISE otevřete soubor ...\Learning Modules\UserConfig.psm1. Nahraďte <resourcegroup> a <user> na řádcích 10 a 11 hodnotou použitou při nasazení aplikace. Uložte soubor.

2. V prostředí PowerShell ISE otevřete skript ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1.

   V tomto kurzu spustíte všechny scénáře v tomto skriptu PowerShellu, takže nechte tento soubor otevřený.

3. Nastavte následující:

   $DemoScenario = 1: Spusťte úlohu na pozadí, která synchronizuje informace o konfiguraci serveru tenanta a fondu do katalogu.

4. Pokud chcete spustit synchronizační skript, vyberte F5.

   Tyto informace se později použijí k zajištění toho, aby obnovení vytvořilo zrcadlovou image serverů, fondů a databází v oblasti obnovení.

   

Nechte okno PowerShellu spuštěné na pozadí a pokračujte ve zbývající části tohoto kurzu.

Poznámka:

Proces synchronizace se připojí k katalogu prostřednictvím aliasu DNS. Alias se změní během obnovení a opakování tak, aby odkazovaly na aktivní katalog. Proces synchronizace udržuje katalog aktuální s libovolnými změnami konfigurace databáze nebo fondu provedenými v oblasti obnovení. Během opakování se tyto změny použijí na ekvivalentní prostředky v původní oblasti.

Přehled procesu obnovení geografického obnovení

Proces obnovení geografického obnovení nasadí aplikaci a obnoví databáze ze záloh do oblasti obnovení.

Proces obnovení provede následující:

1. Zakáže koncový bod Azure Traffic Manageru pro webovou aplikaci v původní oblasti. Zakázáním koncového bodu zabráníte uživatelům v připojení k aplikaci v neplatném stavu, pokud se původní oblast během obnovení vrátí do režimu online.

2. Zřídí server katalogu obnovení v oblasti obnovení, geograficky obnoví databázi katalogu a aktualizuje alias activecatalog tak, aby odkazovat na obnovený server katalogu. Změna aliasu katalogu zajišťuje, aby se proces synchronizace katalogu vždy synchronizoval s aktivním katalogem.

3. Označí všechny existující tenanty v katalogu obnovení jako offline, aby se zabránilo přístupu k databázím tenantů před jejich obnovením.

4. Zřídí instanci aplikace v oblasti obnovení a nakonfiguruje ji tak, aby používal obnovený katalog v této oblasti. Aby se zachovala latence na minimum, je ukázková aplikace navržená tak, aby se vždy připojila k databázi tenanta ve stejné oblasti.

5. Zřídí server a elastický fond, ve kterém se zřídí noví tenanti. Vytvořením těchto prostředků zajistíte, že zřizování nových tenantů nezasahuje do obnovení stávajících tenantů.

6. Aktualizuje nový alias tenanta tak, aby odkazovat na server pro nové databáze tenantů v oblasti obnovení. Změnou tohoto aliasu zajistíte, že se databáze pro všechny nové tenanty zřídí v oblasti obnovení.

7. Zřizuje servery a elastické fondy v oblasti obnovení pro obnovení databází tenantů. Tyto servery a fondy jsou zrcadlovou imagí konfigurace v původní oblasti. Zřizovací fondy předem vyhrazují kapacitu potřebnou k obnovení všech databází.

   Výpadek v oblasti může výrazně zatěžovat prostředky dostupné ve spárované oblasti. Pokud pro zotavení po havárii spoléháte na geografické obnovení, doporučuje se rychle rezervace prostředků. Pokud je důležité, aby se aplikace obnovila v konkrétní oblasti, zvažte geografickou replikaci.

8. Povolí koncový bod Traffic Manageru pro webovou aplikaci v oblasti obnovení. Povolení tohoto koncového bodu umožňuje aplikaci zřídit nové tenanty. V této fázi jsou stávající tenanti stále offline.

9. Odešle dávky požadavků k obnovení databází v pořadí priority.

   • Dávky jsou uspořádané tak, aby se databáze obnovily paralelně napříč všemi fondy.

   • Žádosti o obnovení se odesílají asynchronně, takže se rychle odesílají a zařadí do fronty pro provádění v každém fondu.

   • Vzhledem k tomu, že žádosti o obnovení se zpracovávají paralelně napříč všemi fondy, je lepší distribuovat důležité tenanty napříč mnoha fondy.

10. Monitoruje službu a zjišťuje, kdy se databáze obnoví. Po obnovení databáze tenanta se v katalogu označí jako online a zaznamená se součet rowversion pro databázi tenanta.

    • K databázím tenantů může aplikace přistupovat hned, jak jsou v katalogu označené online.

    • Součet hodnot rowversion v databázi tenanta je uložen v katalogu. Tento součet funguje jako otisk prstu, který umožňuje procesu opakování určit, jestli se databáze aktualizovala v oblasti obnovení.

Spuštění skriptu pro obnovení

Důležité

Tento kurz obnoví databáze z geograficky redundantních záloh. I když jsou tyto zálohy obvykle dostupné do 10 minut, může to trvat až hodinu. Skript se pozastaví, dokud nebude dostupný.

Představte si, že v oblasti, ve které je aplikace nasazená, došlo k výpadku, a spusťte skript pro obnovení:

1. V prostředí PowerShell ISE ve skriptu ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 nastavte následující hodnotu:

   $DemoScenario = 2: Obnovení aplikace do oblasti obnovení obnovením z geograficky redundantních záloh.

2. Pokud chcete skript spustit, vyberte F5.

   • Skript se otevře v novém okně PowerShellu a pak spustí sadu úloh PowerShellu, které běží paralelně. Tyto úlohy obnovují servery, fondy a databáze do oblasti obnovení.

   • Oblast obnovení je spárovaná oblast přidružená k oblasti Azure, ve které jste nasadili aplikaci. Další informace najdete v tématu Spárované oblasti Azure.

3. Monitorujte stav procesu obnovení v okně PowerShellu.

   

Poznámka:

Pokud chcete prozkoumat kód pro úlohy obnovení, projděte si skripty PowerShellu ve složce ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs.

Kontrola stavu aplikace během obnovení

Koncový bod aplikace je v Traffic Manageru zakázaný, ale aplikace není k dispozici. Katalog se obnoví a všichni tenanti jsou označeni jako offline. Koncový bod aplikace v oblasti obnovení je pak povolený a aplikace je zase online. I když je aplikace dostupná, tenanti se v centru událostí zobrazí offline, dokud se jejich databáze neobnoví. Je důležité navrhnout aplikaci tak, aby zpracovávala offline databáze tenantů.

• Po obnovení databáze katalogu, ale před návratem tenantů do online režimu aktualizujte centrum událostí Wingtip Tickets ve webovém prohlížeči.

  • V zápatí si všimněte, že název serveru katalogu má teď příponu -recovery a nachází se v oblasti obnovení.

  • Všimněte si, že tenanti, kteří ještě nejsou obnoveni, jsou označeni jako offline a nedají se vybrat.

    

  • Pokud otevřete stránku událostí tenanta přímo, když je tenant offline, zobrazí se na stránce offline oznámení tenanta. Pokud je například koncertní sál Contoso offline, zkuste otevřít http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>.

    

Zřízení nového tenanta v oblasti obnovení

Ještě před obnovením databází tenantů můžete zřídit nové tenanty v oblasti obnovení. Nové databáze tenantů zřízené v oblasti obnovení se později znovu vrátí s obnovenými databázemi.

1. V prostředí PowerShell ISE ve skriptu ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 nastavte následující vlastnost:

   $DemoScenario = 3: Zřízení nového tenanta v oblasti obnovení

2. Pokud chcete skript spustit, vyberte F5.

3. Po dokončení zřizování se v prohlížeči otevře stránka událostí Hawthorn Hall.

   Všimněte si, že databáze Hawthorn Hall se nachází v oblasti obnovení.

   

4. V prohlížeči aktualizujte stránku centra událostí Wingtip Tickets, aby se zobrazila zahrnutá hala Hawthorn.

   Pokud jste zřídili Halu Hawthorn bez čekání na obnovení ostatních tenantů, můžou být ostatní tenanti stále offline.

Kontrola obnoveného stavu aplikace

Po dokončení procesu obnovení jsou aplikace a všichni tenanti plně funkční v oblasti obnovení.

1. Po zobrazení v okně konzoly PowerShellu se obnoví všechny tenanty, aktualizujte centrum událostí.

   Všichni tenanti se zobrazí online, včetně nového tenanta Hawthorn Hall.

   

2. Klikněte na Koncertní sál Společnosti Contoso a otevřete stránku s událostmi.

   V zápatí si všimněte, že databáze se nachází na serveru pro obnovení umístěném v oblasti obnovení.

   

3. Na webu Azure Portal otevřete seznam skupin prostředků.

   Všimněte si nasazené skupiny prostředků a skupiny prostředků obnovení s příponou -recovery. Skupina prostředků obnovení obsahuje všechny prostředky vytvořené během procesu obnovení a nové prostředky vytvořené během výpadku.

4. Otevřete skupinu prostředků obnovení a všimněte si následujících položek:

   • Verze obnovení serverů katalogu a tenantů1 s příponou -recovery. Obnovené databáze katalogu a tenantů na těchto serverech mají všechny názvy použité v původní oblasti.

   • Tenants2-dpt-user-recovery<> SQL Server. Tento server se používá ke zřizování nových tenantů během výpadku.

   • App Service s názvem events-wingtip-dpt-recoveryregion-user<><>, což je instance obnovení aplikace událostí.

     

5. Otevřete SQL server sql tenants2-dpt-user-recovery<>. Všimněte si, že obsahuje databázi hawthornhall a fond elastických fondů1. Databáze hawthornhall je nakonfigurovaná jako elastická databáze v elastickém fondu Pool1.

Změna dat tenanta

V této úloze aktualizujete jednu z obnovených databází tenanta. Proces opakování kopíruje obnovené databáze, které byly změněny do původní oblasti.

1. V prohlížeči vyhledejte seznam událostí pro Sál koncertů Contoso, projděte si události a všimněte si poslední události, Vážně Strauss.

2. V prostředí PowerShell ISE ve skriptu ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 nastavte následující hodnotu:

   $DemoScenario = 4: Odstraňte událost z tenanta v oblasti obnovení.

3. Pokud chcete skript spustit, vyberte F5.

4. Aktualizujte stránku událostí koncertu Contoso (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>) a všimněte si, že událost Vážně Strauss chybí.

V tomto okamžiku v kurzu jste obnovili aplikaci, která je nyní spuštěná v oblasti obnovení. V oblasti obnovení jste zřídili nového tenanta a upravili jste data jednoho z obnovených tenantů.

Poznámka:

Jiné kurzy v ukázce nejsou navržené tak, aby běžely s aplikací ve stavu obnovení. Pokud chcete prozkoumat další kurzy, nezapomeňte nejprve aplikaci znovu zkontrolovat.

Přehled procesu opakování

Proces opakování vrátí aplikaci a její databáze do původní oblasti po vyřešení výpadku.

Proces:

1. Zastaví probíhající aktivitu obnovení a zruší všechny nevyřízených nebo probíhajících žádostí o obnovení databáze.

2. Znovu se aktivuje v původních databázích tenantů oblasti, které se od výpadku nezměnily. Tyto databáze zahrnují ty, které se ještě neobnovily, a ty se obnovily, ale následně se nezměnily. Opětovně aktivované databáze jsou přesně tak, jak k nim přistupují jejich tenanti.

3. Zřídí zrcadlovou kopii serveru nového tenanta a elastického fondu v původní oblasti. Po dokončení této akce se nový alias tenanta aktualizuje tak, aby odkazovat na tento server. Aktualizace aliasu způsobí, že místo oblasti obnovení dojde k onboardingu nového tenanta v původní oblasti.

4. Pomocí geografické replikace přesune katalog do původní oblasti z oblasti obnovení.

5. Aktualizuje konfiguraci fondu v původní oblasti, aby byla konzistentní se změnami provedenými v oblasti obnovení během výpadku.

6. Vytvoří požadované servery a fondy pro hostování všech nových databází vytvořených během výpadku.

7. Používá geografickou replikaci k obnovení obnovených databází tenantů, které byly aktualizovány po obnovení, a všech nových databází tenantů zřízených během výpadku.

8. Vyčistí prostředky vytvořené v oblasti obnovení během procesu obnovení.

Pokud chcete omezit počet databází tenantů, které je potřeba opakovat, kroky 1 až 3 se provádějí okamžitě.

Krok 4 se provádí pouze v případě, že se během výpadku změnil katalog v oblasti obnovení. Katalog se aktualizuje, pokud se vytvoří nové tenanty nebo pokud se v oblasti obnovení změní nějaká konfigurace databáze nebo fondu.

Je důležité, aby krok 7 způsobil minimální přerušení tenantů a neztratil žádná data. K dosažení tohoto cíle proces používá geografickou replikaci.

Před geografickou replikací každé databáze se odstraní odpovídající databáze v původní oblasti. Databáze v oblasti obnovení se pak geograficky replikuje a vytvoří sekundární repliku v původní oblasti. Po dokončení replikace se tenant v katalogu označí jako offline, což přeruší všechna připojení k databázi v oblasti obnovení. Databáze se pak převezme při selhání, což způsobí, že všechny čekající transakce budou zpracovávat na sekundární straně, takže se neztratí žádná data.

Při převzetí služeb při selhání jsou databázové role obrácené. Sekundární v původní oblasti se stane primární databází pro čtení i zápis a databáze v oblasti obnovení se stane sekundární jen pro čtení. Položka tenanta v katalogu se aktualizuje tak, aby odkazovat na databázi v původní oblasti a tenant je označen online. V tuto chvíli je opakování databáze dokončeno.

Aplikace by měly být napsané s logikou opakování, aby se zajistilo, že se automaticky připojí při přerušení připojení. Když katalog použije ke zprostředkování opětovného připojení, připojí se k repatriované databázi v původní oblasti. I když si stručné odpojení často nevšimnete, můžete se rozhodnout znovu znova zpracovat databáze mimo pracovní dobu.

Po repatriování databáze je možné sekundární databázi v oblasti obnovení odstranit. Databáze v původní oblasti pak znovu spoléhá na geografické obnovení ochrany zotavení po havárii.

V kroku 8 se odstraní prostředky v oblasti obnovení, včetně serverů pro obnovení a fondů.

Spuštění skriptu repatriation

Představme si, že výpadek je vyřešený a spusťte skript opakování.

Pokud jste postupovali podle kurzu, skript okamžitě znovu aktivuje Fabrikam Jazz Club a Dogwood Dojo v původní oblasti, protože se nezměnil. Potom se znovu opakuje nový tenant, Hawthorn Hall a Contoso Concert Hall, protože byl upraven. Skript také znovu opakuje katalog, který byl aktualizován při zřízení Hawthorn Hall.

1. V prostředí PowerShell ISE ve skriptu ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 ověřte, že proces synchronizace katalogu je stále spuštěný v instanci PowerShellu. V případě potřeby ho restartujte nastavením:

   $DemoScenario = 1: Spusťte synchronizaci konfiguračních informací o serveru tenanta, fondu a databázi do katalogu.

   Pokud chcete skript spustit, vyberte F5.

2. Potom spusťte proces opakování, nastavte:

   $DemoScenario = 5: Repatriate aplikaci do původní oblasti.

   Pokud chcete spustit skript pro obnovení v novém okně PowerShellu, vyberte F5. Opakování trvá několik minut a dá se monitorovat v okně PowerShellu.

3. Během spouštění skriptu aktualizujte stránku centra událostí (http://events.wingtip-dpt.<user.trafficmanager.net>).

   Všimněte si, že v průběhu tohoto procesu jsou všichni tenanti online a přístupní.

4. Vyberte Fabrikam Jazz Club a otevřete ho. Pokud jste tohoto tenanta neupravovali, všimněte si zápatí, že se server už vrátil k původnímu serveru.

5. Otevřete nebo aktualizujte stránku událostí koncertu Contoso. Všimněte si zápatí, že databáze je zpočátku stále na serveru -recovery.

6. Aktualizujte stránku událostí koncertu Společnosti Contoso, když se proces opakování dokončí, a všimněte si, že databáze je teď ve vaší původní oblasti.

7. Aktualizujte centrum událostí znovu a otevřete Hawthorn Hall. Všimněte si, že jeho databáze se nachází také v původní oblasti.

Vyčištění prostředků oblasti obnovení po repatriaci

Po dokončení opakování je bezpečné odstranit prostředky v oblasti obnovení.

Důležité

Odstraňte tyto prostředky okamžitě, abyste zastavili veškeré účtování za ně.

Proces obnovení vytvoří všechny prostředky obnovení ve skupině prostředků obnovení. Proces čištění odstraní tuto skupinu prostředků a odebere všechny odkazy na prostředky z katalogu.

1. V prostředí PowerShell ISE ve skriptu ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 nastavte:

   $DemoScenario = 6: Odstraňte zastaralé prostředky z oblasti obnovení.

2. Pokud chcete skript spustit, vyberte F5.

Po vyčištění skriptů se aplikace vrátí tam, kde se spustila. V tomto okamžiku můžete skript spustit znovu nebo vyzkoušet další kurzy.

Návrh aplikace tak, aby se zajistilo, že se aplikace a databáze společně nacházejí

Aplikace je navržená tak, aby se vždy připojila z instance ve stejné oblasti jako databáze tenanta. Tento návrh snižuje latenci mezi aplikací a databází. Tato optimalizace předpokládá, že interakce mezi aplikacemi je chatovací než interakce mezi uživateli a aplikací.

Databáze tenantů můžou být během opakování rozložené do oblastí obnovení a původních oblastí. Pro každou databázi aplikace vyhledá oblast, ve které se databáze nachází, vyhledáním DNS v názvu serveru tenanta. Název serveru je alias. Název aliasovaného serveru obsahuje název oblasti. Pokud aplikace není ve stejné oblasti jako databáze, přesměruje se na instanci ve stejné oblasti jako server. Přesměrování na instanci ve stejné oblasti jako databáze minimalizuje latenci mezi aplikací a databází.

Další kroky

V tomto kurzu jste se naučili, jak:

• Katalog tenantů slouží k pravidelnému uchovávání informací o konfiguraci, které umožňují vytvoření prostředí pro obnovení zrcadlové image v jiné oblasti.
• Obnovte databáze do oblasti obnovení pomocí geografického obnovení.
• Aktualizujte katalog tenantů tak, aby odrážel obnovená umístění databáze tenanta.
• Pomocí aliasu DNS můžete aplikaci povolit připojení ke katalogu tenantů v celém prostředí bez rekonfigurace.
• Po vyřešení výpadku použijte geografickou replikaci k obnovení obnovených databází do původní oblasti.

Vyzkoušejte zotavení po havárii pro víceklientské aplikace SaaS pomocí kurzu geografické replikace databáze a zjistěte, jak používat geografickou replikaci, aby se výrazně zkrátila doba potřebná k obnovení rozsáhlé víceklientské aplikace.

Další materiály

Další kurzy, které vycházejí z aplikace Wingtip SaaS