Zotavení po havárii pro víceklientské aplikace SaaS pomocí geografické replikace databáze

Platí pro: Azure SQL Database

V tomto kurzu prozkoumáte scénář úplné zotavení po havárii pro víceklientské aplikace SaaS implementované pomocí modelu databáze na tenanta. K ochraně aplikace před výpadkem použijete geografickou replikaci k vytvoření replik pro katalog a databáze tenantů v alternativní oblasti obnovení. Pokud dojde k výpadku, dojde k rychlému převzetí služeb při selhání těchto replik za účelem obnovení normálních obchodních operací. Při převzetí služeb při selhání se databáze v původní oblasti stanou sekundárními replikami databází v oblasti obnovení. Jakmile se tyto repliky vrátí do online režimu, automaticky dohoní stav databází v oblasti obnovení. Po vyřešení výpadku provedete navrácení služeb po obnovení do databází v původní produkční oblasti.

Tento kurz zkoumá pracovní postupy převzetí služeb při selhání i navrácení služeb po obnovení. Získáte následující informace:

• Synchronizace informací o konfiguraci databáze a elastického fondu do katalogu tenantů
• Nastavení prostředí pro obnovení v alternativní oblasti, která se skládá z aplikací, serverů a fondů
• Použití geografické replikace k replikaci katalogu a databází tenantů do oblasti obnovení
• Převzetí služeb při selhání aplikací a databází katalogu a tenantů do oblasti obnovení
• Později po vyřešení výpadku převezme služby při selhání aplikace, katalogu a databází tenantů zpět do původní oblasti.
• Aktualizace katalogu, protože každá databáze tenanta převezme služby při selhání, aby se sledovalo primární umístění databáze každého tenanta
• Ujistěte se, že aplikace a primární databáze tenantů jsou vždy společně přiděleny ve stejné oblasti Azure, aby se snížila latence.

Před zahájením tohoto kurzu se ujistěte, že jsou splněné následující požadavky:

• Nasadí se databáze Wingtip Tickets SaaS na aplikaci tenanta. Pokud chcete nasazení provést za 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.
• Prostředí Azure PowerShell je nainstalované. Podrobnosti najdete v článku Začínáme s prostředím Azure PowerShell.

Úvod do modelu obnovení geografické replikace

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. Použití geografické replikace poskytuje nejnižší cíl bodu obnovení (RPO) a RTO tím, že udržuje repliky databáze v oblasti obnovení, u které je možné provést převzetí služeb při selhání na krátkou dobu.

Plán zotavení po havárii založený na geografické replikaci se skládá ze tří různých částí:

• Nastavení – vytvoření a údržba prostředí pro obnovení
• Obnovení – převzetí služeb při selhání aplikace a databází do prostředí pro obnovení, pokud dojde k výpadku,
• Opakování – převzetí služeb při selhání aplikace a databází zpět do původní oblasti po vyřešení aplikace

Všechny části je třeba pečlivě zvážit, zejména pokud pracujete ve velkém měřítku. Plán musí celkově dosáhnout několika cílů:

• Sestava
  • Vytvořte a udržujte prostředí zrcadlové image v oblasti obnovení. Vytvoření elastických fondů a replikace všech databází v tomto prostředí obnovení si vyhrazuje kapacitu v oblasti obnovení. Údržba tohoto prostředí zahrnuje replikaci nových databází tenantů při jejich zřizování.
• Zotavení
  • Pokud se prostředí zotavení se škálováním na více instancí se používá k minimalizaci každodenních nákladů, fondy a databáze se musí vertikálně navýšit, aby získaly plnou provozní kapacitu v oblasti obnovení.
  • Co nejdříve povolte zřizování nového tenanta v oblasti obnovení.
  • Optimalizace pro obnovení tenantů v pořadí priority
  • Buďte optimalizovaní pro co nejrychlejší přechod tenantů do online režimu, a to paralelně, pokud je to praktické.
  • Odolnost vůči selhání, restartování a idempotentnímu
  • Proces je možné zrušit v polovině letu, pokud se původní oblast vrátí zpět na linku.
• Repatriace
  • Převzetí služeb při selhání databází z oblasti obnovení na repliky v původní oblasti s minimálním dopadem na tenanty: bez ztráty dat a minimálního období off-line na tenanta.

V tomto kurzu jsou tyto výzvy vyřešeny pomocí funkcí služby Azure SQL Database a platformy Azure:

• Šablony Azure Resource Manageru pro co nejrychlejší rezervaci všech potřebných kapacit Šablony Azure Resource Manageru slouží ke zřízení zrcadlové image produkčních serverů a elastických fondů v oblasti obnovení.
• Geografická replikace pro vytváření asynchronně replikovaných sekundárních souborů jen pro čtení pro všechny databáze. Během výpadku převezmete služby při selhání replikám v oblasti obnovení. Po vyřešení výpadku provedete navrácení služeb po obnovení do databází v původní oblasti bez ztráty dat.
• Asynchronní operace převzetí služeb při selhání odeslané v pořadí priority tenanta, aby se minimalizovala doba převzetí služeb při selhání u velkého počtu databází.
• Funkce obnovení správy horizontálních oddílů pro změnu položek databáze v katalogu během obnovení a opakování Tyto funkce umožňují aplikaci připojit se k databázím tenantů bez ohledu na umístění bez nutnosti překonfigurovat aplikaci.
• Aliasy DNS SQL Serveru, které umožňují bezproblémové zřizování nových tenantů bez ohledu na to, ve které oblasti aplikace pracuje. Aliasy DNS se také používají k tomu, aby se proces synchronizace katalogu mohl připojit k aktivnímu katalogu bez ohledu na jeho umístění.

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

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

Skripty pro obnovení použité v tomto kurzu a zdrojový kód aplikace Wingtip 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.

Přehled kurzů

V tomto kurzu nejprve použijete geografickou replikaci k vytvoření replik aplikace Wingtip Tickets a jejích databází v jiné oblasti. Potom převezmete služby při selhání do této oblasti a simulujete zotavení z výpadku. Po dokončení je aplikace plně funkční v oblasti obnovení.

Později v samostatném kroku opakování převezmete služby při selhání katalogu a databází tenantů v oblasti obnovení do původní oblasti. Aplikace a databáze zůstanou dostupné během opakování. Po dokončení je aplikace plně funkční v původní oblasti.

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.

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: Pokud chcete zvětšit zobrazení, najeďte myší na místo.

2. Klikněte na tenanta koncertu Contoso a otevřete jeho stránku události.

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

3. Na webu Azure Portal otevřete skupinu prostředků, ve které je aplikace nasazená.

   • Všimněte si oblasti, ve které jsou servery nasazené.

Synchronizace konfigurace tenanta do katalogu

V této úloze spustíte proces, který synchronizuje konfiguraci serverů, elastických fondů a databází do katalogu tenantů. Tento proces uchovává tyto informace v katalogu aktuální. Proces funguje s aktivním katalogem, ať už v původní oblasti nebo v oblasti obnovení. Informace o konfiguraci se používají jako součást procesu obnovení, aby se zajistilo, že prostředí obnovení je konzistentní s původním prostředím, a později během opakování, aby se zajistilo, že původní oblast bude konzistentní se všemi změnami provedenými v prostředí obnovení. Katalog se také používá ke sledování stavu obnovení prostředků tenanta.

Důležité

Pro zjednodušení se proces synchronizace a další dlouhotrvající procesy obnovení a opakování implementují v těchto kurzech 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 pak selžou. 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\Provozní kontinuita a zotavení po havárii\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 a nastavte:

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

3. Stisknutím klávesy F5 spusťte synchronizační skript. Otevře se nová relace PowerShellu pro synchronizaci konfigurace prostředků tenanta.

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

Poznámka:

Proces synchronizace se připojí k katalogu prostřednictvím aliasu DNS. Tento 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.

Vytvoření sekundárních replik databáze v oblasti obnovení

V této úloze spustíte proces, který nasadí duplicitní instanci aplikace a replikuje katalog a všechny databáze tenantů do oblasti obnovení.

Poznámka:

Tento kurz přidá ochranu geografické replikace do ukázkové aplikace Wingtip Tickets. V produkčním scénáři aplikace, která používá geografickou replikaci, by se každý tenant zřídil s geograficky replikovanou databází od počátku. Viz Návrh vysoce dostupných služeb pomocí Azure SQL Database

1. V prostředí PowerShell ISE otevřete skript ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 a nastavte následující hodnoty:

   • $DemoScenario = 2, vytvoření prostředí pro obnovení zrcadlové image a replikace katalogu a databází tenantů

2. Stisknutím klávesy F5 spusťte skript. Otevře se nová relace PowerShellu pro vytvoření replik.

Kontrola normálního stavu aplikace

V tuto chvíli aplikace běží normálně v původní oblasti a teď je chráněná geografickou replikací. Sekundární repliky jen pro čtení existují v oblasti obnovení pro všechny databáze.

1. Na webu Azure Portal se podívejte na skupiny prostředků a všimněte si, že skupina prostředků byla vytvořena s příponou -recovery v oblasti obnovení.

2. Prozkoumejte prostředky ve skupině prostředků obnovení.

3. Klikněte na databázi Concert Hall společnosti Contoso na serveru pro obnovení uživatele tenants1-dpt-user-recovery><. Klikněte na geografickou replikaci na levé straně.

   

V mapě oblastí Azure si všimněte propojení geografické replikace mezi primární oblastí v původní oblasti a sekundární oblastí obnovení.

Převzetí služeb při selhání aplikace do oblasti obnovení

Přehled procesu obnovení geografické replikace

Skript pro obnovení provádí následující úlohy:

1. Zakáže koncový bod 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. Použije vynucené převzetí služeb při selhání databáze katalogu v oblasti obnovení, aby byla primární databází, a aktualizuje alias activecatalog tak, aby odkazovat na server katalogu obnovení.

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

4. Označí všechny existující tenanty v katalogu obnovení jako offline, aby před převzetím služeb při selhání zabránily přístupu k databázím tenantů.

5. Aktualizuje konfiguraci všech elastických fondů a replikovaných jednoúčelových databází v oblasti obnovení tak, aby zrcadlila jejich konfiguraci v původní oblasti. (Tato úloha je nutná pouze v případě, že se fondy nebo replikované databáze v prostředí obnovení škálují během normálních operací, aby se snížily náklady).

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

7. Odešle dávky požadavků, které vynutí převzetí služeb při selhání databází v pořadí priority.

   • Dávky jsou uspořádané tak, aby se databáze převzaly paralelně napříč všemi fondy.
   • Žádosti o převzetí služeb při selhání se odesílají pomocí asynchronních operací, takže se odesílají rychle a současně je možné zpracovat více požadavků.

   Poznámka:

   Ve scénáři výpadku jsou primární databáze v původní oblasti offline. Vynucení převzetí služeb při selhání na sekundární straně přeruší připojení k primárnímu serveru, aniž byste se pokusili použít všechny zbývající transakce zařazené do fronty. V případě scénáře zotavení po havárii, jako je tento kurz, může dojít ke ztrátě dat, pokud v době převzetí služeb při selhání dojde k nějaké aktivitě aktualizace. Později při opakování při převzetí služeb při selhání databází v oblasti obnovení zpět do původní oblasti se použije normální převzetí služeb při selhání, aby nedošlo ke ztrátě dat.

8. Monitoruje službu, aby určila, kdy došlo k převzetí služeb při selhání databází. Po převzetí služeb při selhání databáze tenanta aktualizuje katalog, aby zaznamenal stav obnovení databáze tenanta a označil tenanta jako online.

   • 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. Tato hodnota funguje jako otisk prstu, který umožňuje procesu opakování zjistit, jestli byla databáze v oblasti obnovení aktualizována.

Spuštěním skriptu převeďte služby při selhání do oblasti obnovení.

Teď si představte, že v oblasti, ve které je aplikace nasazená, dojde k výpadku a spuštění skriptu pro obnovení:

1. V prostředí PowerShell ISE otevřete skript ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 a nastavte následující hodnoty:

   • $DemoScenario = 3, obnovení aplikace do oblasti obnovení převzetím služeb při selhání replik

2. Stisknutím klávesy F5 spusťte skript.

   • Skript se otevře v novém okně PowerShellu a pak spustí řadu úloh PowerShellu, které běží paralelně. Tyto úlohy převezme služby při selhání databází tenantů 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 úloh obnovení, projděte si skripty PowerShellu ve složce ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\RecoveryJobs.

Kontrola stavu aplikace během obnovení

Koncový bod aplikace je v Traffic Manageru zakázaný, ale aplikace není k dispozici. Po převzetí služeb při selhání katalogu do oblasti obnovení a všech tenantů označených jako offline se aplikace vrátí do režimu online. I když je aplikace dostupná, každý tenant se v centru událostí zobrazí offline, dokud nedojde k převzetí služeb při selhání její databáze. Je důležité navrhnout aplikaci tak, aby zpracovávala offline databáze tenantů.

1. Po obnovení databáze katalogu 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.

     Poznámka:

     Pokud chcete obnovit jenom několik databází, možná nebudete moct před dokončením obnovení aktualizovat prohlížeč, takže se nemusí zobrazovat tenanti, když jsou offline.

     

   • Pokud otevřete stránku Události offline tenanta přímo, zobrazí se oznámení tenanta offline. 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í

I před převzetím služeb při selhání všech existujících databází tenantů můžete zřídit nové tenanty v oblasti obnovení.

1. V prostředí PowerShell ISE otevřete skript ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 a nastavte následující vlastnost:

   • $DemoScenario = 4, zřízení nového tenanta v oblasti obnovení

2. Stisknutím klávesy F5 spusťte skript a zřiďte nového tenanta.

3. Po dokončení se v prohlížeči otevře stránka událostí Hawthorn Hall. Všimněte si zápatí, že databáze Hawthorn Hall je zřízena v oblasti obnovení.

4. V prohlížeči aktualizujte stránku Centra událostí wingtipu, 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. 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.

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

   • Verze obnovení katalogu a serverů tenants1 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 Events.

     

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

5. Přejděte zpět do skupiny prostředků a klikněte na databázi Koncert hall společnosti Contoso na serveru pro obnovení tenants1-dpt-user-recovery><. Klikněte na geografickou replikaci na levé straně.

   

Změna dat tenanta

V této úloze aktualizujete jednu z databází tenantů.

1. V prohlížeči vyhledejte seznam událostí pro Sál koncertů Contoso a poznamenejte si příjmení události.
2. V prostředí PowerShell ISE nastavte ve skriptu ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 následující hodnotu:
   • $DemoScenario = 5 Odstranění události z tenanta v oblasti obnovení
3. Stisknutím klávesy F5 spusťte skript.
4. Aktualizujte stránku událostí koncertu Contoso (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall> – nahraďte <uživatele> hodnotou uživatele vašeho nasazení) a všimněte si, že poslední událost byla odstraněna.

Repatriace aplikace do původní produkční oblasti

Tato úloha přepíná aplikaci do původní oblasti. V reálném scénáři byste iniciovali opakování, když dojde k vyřešení výpadku.

Přehled procesu opakování

Proces opakování:

1. Zruší všechny nevyřízených nebo vyřízených žádostí o obnovení databáze.
2. Aktualizuje alias nového tenanta tak, aby odkazovat na server tenantů v oblasti původu. Změna tohoto aliasu zajistí, že databáze pro všechny nové tenanty se teď zřídí v oblasti původu.
3. Zasadí všechna změněná data tenanta do původní oblasti.
4. Převzetí služeb při selhání databází tenantů v pořadí podle priority

Převzetí služeb při selhání efektivně přesune databázi do původní oblasti. Když databáze převezme služby při selhání, všechna otevřená připojení se zahodí a databáze bude několik sekund nedostupná. Aplikace by měly být napsané s logikou opakování, aby se zajistilo, že se znovu připojí. I když si toto krátké odpojení často nevšimnete, můžete se rozhodnout znovu znova zpracovat databáze mimo pracovní dobu.

Spuštění skriptu repatriation

Teď si představme, že dojde k vyřešení výpadku, a spusťte skript pro opakování.

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

2. 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 informací o konfiguraci tenanta, fondu a databáze do katalogu.
   • Stisknutím klávesy F5 spusťte skript.

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

   • $DemoScenario = 6, přepatriatujte aplikaci do původní oblasti.
   • Stisknutím klávesy F5 spusťte skript pro obnovení v novém okně PowerShellu. Opakování bude trvat několik minut a dá se monitorovat v okně PowerShellu.

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

5. Po dokončení opakování aktualizujte centrum událostí a otevřete stránku událostí pro Halu Hawthorn. Všimněte si, že tato databáze byla repatriována do původní oblasti.

Návrh aplikace pro zajištění společného přidělení aplikace a databáze

Aplikace je navržená tak, aby se vždy připojovat 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ů se můžou po určitou dobu během opakování rozprostřit mezi oblasti obnovení a původní oblasti. Pro každou databázi aplikace vyhledá oblast, ve které se databáze nachází, vyhledáním DNS v názvu serveru tenanta. V SQL Database je název serveru 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:

• Synchronizace informací o konfiguraci databáze a elastického fondu do katalogu tenantů
• Nastavení prostředí pro obnovení v alternativní oblasti, která se skládá z aplikací, serverů a fondů
• Použití geografické replikace k replikaci katalogu a databází tenantů do oblasti obnovení
• Převzetí služeb při selhání aplikací a databází katalogu a tenantů do oblasti obnovení
• Navrácení služeb po obnovení aplikace, katalogu a databází tenantů do původní oblasti po vyřešení výpadku

Další informace o technologiích, které azure SQL Database poskytuje, vám umožní kontinuitu podnikových procesů v dokumentaci přehledu provozní kontinuity.

Další materiály

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