Zotavení z přerušení služeb na úrovni celé oblasti

Azure je fyzicky a logicky rozdělený na jednotky označované jako oblasti. Oblast se skládá z jednoho nebo více datových center v těsné blízkosti. Řada oblastí a služeb také podporuje zóny dostupnosti, které je možné použít k zajištění větší odolnosti proti výpadkům v jednom datovém centru. Zvažte použití oblastí se zónami dostupnosti ke zlepšení dostupnosti vašeho řešení.

Za výjimečných okolností je možné, že zařízení v celé zóně dostupnosti nebo oblasti mohou být například nepřístupná kvůli selhání sítě. Nebo zařízení může být zcela ztracena, například kvůli přírodní katastrofě. Azure nabízí možnosti pro vytváření aplikací distribuovaných napříč zónami a oblastmi. Toto rozdělení pomáhá minimalizovat možnost, že selhání v jedné zóně nebo oblasti může ovlivnit jiné zóny nebo oblasti.

Cloudové služby

Řízení zdrojů

Výpočetní instance můžete distribuovat napříč oblastmi vytvořením samostatné cloudové služby v každé cílové oblasti a následným publikováním balíčku pro nasazení do každé cloudové služby. Distribuci provozu mezi cloudové služby v různých oblastech ale musí implementovat vývojář aplikace nebo se službou správy provozu.

Určení počtu instancí náhradních rolí, které se mají nasadit předem pro zotavení po havárii, je důležitým aspektem plánování kapacity. Pokud máte plně škálované sekundární nasazení, zajistíte, že kapacita je již dostupná v případě potřeby; to však účinně zdvojnásobí náklady. Běžným vzorem je mít malé sekundární nasazení, které je dostatečně velké pro spouštění důležitých služeb. Toto malé sekundární nasazení je vhodné– jak rezervovat kapacitu, tak pro testování konfigurace sekundárního prostředí.

Vyrovnávání zatížení

K vyrovnávání zatížení provozu napříč oblastmi se vyžaduje řešení správy provozu. Azure poskytuje Azure Traffic Manager. Můžete také využít služby třetích stran, které poskytují podobné možnosti správy provozu.

Strategie

K dispozici je mnoho alternativních strategií pro implementaci distribuovaných výpočetních prostředků napříč oblastmi. Musí se přizpůsobit konkrétním obchodním požadavkům a okolnostem aplikace. Na vysoké úrovni lze přístupy rozdělit do následujících kategorií:

• Opětovné nasazení při havárii: V tomto přístupu se aplikace v době havárie znovu nasadí od začátku. To je vhodné pro nekritické aplikace, které nevyžadují zaručenou dobu obnovení.

• Warm Spare (Aktivní/pasivní):: Sekundární hostovaná služba se vytvoří v alternativní oblasti a role se nasadí za účelem zajištění minimální kapacity. Role ale nedostávají produkční provoz. Tento přístup je užitečný pro aplikace, které nebyly navrženy tak, aby distribuovaly provoz napříč oblastmi.

• Hot Spare (Active/Active): Aplikace je navržená tak, aby přijímala produkční zatížení ve více oblastech. Cloudové služby v každé oblasti můžou být nakonfigurované pro vyšší kapacitu, než je vyžadováno pro účely zotavení po havárii. Cloudové služby můžou případně škálovat podle potřeby v době havárie a převzetí služeb při selhání. Tento přístup vyžaduje značné investice do návrhu aplikace, ale má významné výhody. Patří sem nízká a garantovaná doba obnovení, průběžné testování všech umístění obnovení a efektivní využití kapacity.

Úplná diskuze o distribuovaném návrhu je mimo rozsah tohoto dokumentu. Další informace najdete v tématu Zotavení po havárii a vysoká dostupnost pro Aplikace Azure.

Virtuální počítače

Obnovení virtuálních počítačů infrastruktury jako služby (IaaS) se v mnoha ohledech podobá obnovení výpočetních prostředků paaS (platforma jako služba). Existují ale důležité rozdíly, protože virtuální počítač IaaS se skládá z virtuálního počítače i disku virtuálního počítače.

• Pomocí služby Azure Backup můžete vytvářet zálohy napříč oblastmi, které jsou konzistentní vzhledem k aplikacím. Azure Backup umožňuje zákazníkům vytvářet zálohy konzistentní vzhledem k aplikacím napříč několika disky virtuálních počítačů a podporovat replikaci záloh napříč oblastmi. Můžete to provést tak, že zvolíte geografickou replikaci trezoru záloh v době vytvoření. Replikace trezoru záloh musí být nakonfigurovaná při vytváření. Později ho nejde nastavit. Pokud dojde ke ztrátě oblasti, Microsoft zpřístupní zálohy zákazníkům. Zákazníci můžou provést obnovení do libovolného z nakonfigurovaných bodů obnovení.

• Oddělte datový disk od disku operačního systému. Důležitým aspektem virtuálních počítačů IaaS je, že bez opětovného vytvoření virtuálního počítače nemůžete změnit disk s operačním systémem. To není problém, pokud vaše strategie obnovení je opětovné nasazení po havárii. Může se ale jednat o problém, pokud k rezervaci kapacity používáte přístup Warm Spare. Pokud chcete tento postup implementovat správně, musíte mít nasazený správný disk operačního systému do primárního i sekundárního umístění a data aplikace musí být uložená na samostatné jednotce. Pokud je to možné, použijte standardní konfiguraci operačního systému, kterou lze poskytnout v obou umístěních. Po převzetí služeb při selhání musíte datovou jednotku připojit k existujícím virtuálním počítačům IaaS v sekundárním řadiči domény. Pomocí AzCopy zkopírujte snímky datových disků do vzdálené lokality.

• Mějte na paměti potenciální problémy s konzistencí po geografickém převzetí služeb při selhání několika disků virtuálních počítačů. Disky virtuálních počítačů se implementují jako objekty blob služby Azure Storage a mají stejnou geografickou replikaci. Pokud azure Backup nepoužíváte, neexistují žádné záruky konzistence napříč disky, protože geografická replikace je asynchronní a replikuje se nezávisle. U jednotlivých disků virtuálních počítačů je zaručeno, že po geografickém převzetí služeb při selhání budou v konzistentním stavu, ale nebudou konzistentní napříč disky. To může v některých případech způsobit problémy (například v případě prokládání disků).

• Pomocí Azure Site Recovery můžete replikovat aplikace napříč oblastmi. U Azure Site Recovery si zákazníci nemusí dělat starosti s oddělením datových disků od disků operačního systému nebo potenciálními problémy s konzistencí. Azure Site Recovery replikuje úlohy spuštěné na fyzických a virtuálních počítačích z primární lokality (buď místně, nebo v Azure) do sekundárního umístění (v Azure). Když dojde k výpadku v primární lokalitě zákazníka, může se aktivovat převzetí služeb při selhání, aby se zákazník rychle vrátil do provozního stavu. Po obnovení primárního umístění můžou zákazníci po obnovení služby po obnovení provést navrácení služeb po obnovení. Můžou se snadno replikovat pomocí bodů obnovení se snímky konzistentními vzhledem k aplikacím. Tyto snímky zachycují data disku, všechna data v paměti a všechny transakce v procesu. Azure Site Recovery umožňuje zákazníkům zachovat cíle doby obnovení (RTO) a cíle bodu obnovení (RPO) v rámci limitů organizace. Zákazníci také můžou snadno spouštět postupy zotavení po havárii, aniž by to mělo vliv na aplikace v produkčním prostředí. Pomocí plánů obnovení můžou zákazníci sekvencovat převzetí služeb při selhání a obnovení vícevrstvé aplikace spuštěné na několika virtuálních počítačích. Můžou seskupit počítače do plánu obnovení a volitelně přidat skripty a ruční akce. Plány obnovení je možné integrovat s runbooky Azure Automation.

Úložiště

Obnovení s využitím geograficky redundantního úložiště objektů blob, tabulky, fronty a diskového úložiště virtuálních počítačů

V Azure se ve výchozím nastavení geograficky replikují všechny objekty blob, tabulky, fronty a disky virtuálních počítačů. Označuje se jako geograficky redundantní úložiště (GRS). GRS replikuje data úložiště do spárovaného datacentra umístěného stovky kilometrů od sebe v rámci konkrétní geografické oblasti. GRS je navržený tak, aby poskytoval další odolnost v případě, že dojde k významné havárii datacentra. Microsoft řídí, kdy dojde k převzetí služeb při selhání a převzetí služeb při selhání je omezené na závažné havárie, ve kterých je původní primární umístění považováno za nedostupné v přiměřené době. V některých scénářích to může být několik dní. Data se obvykle replikují během několika minut, i když interval synchronizace ještě není pokryt smlouvou o úrovni služeb.

Pokud dojde k geografickému převzetí služeb při selhání, nedojde ke změně způsobu přístupu k účtu (adresa URL a klíč účtu se nezmění). Účet úložiště ale po převzetí služeb při selhání bude v jiné oblasti. To může mít vliv na aplikace, které vyžadují regionální spřažení s účtem úložiště. I u služeb a aplikací, které nevyžadují účet úložiště ve stejném datacentru, může být latence mezi datovými centry přesvědčivá z důvodů dočasného přesunu provozu do oblasti převzetí služeb při selhání. To by mohlo znamenat celkovou strategii zotavení po havárii.

Kromě automatického převzetí služeb při selhání poskytovaného GRS azure zavedla službu, která poskytuje přístup pro čtení ke kopii vašich dat v sekundárním umístění úložiště. Říká se tomu geograficky redundantní úložiště jen pro čtení (RA-GRS).

Další informace o úložišti GRS i RA-GRS najdete v tématu Replikace služby Azure Storage.

Mapování oblastí geografické replikace

Je důležité vědět, kde se data geograficky replikují, abyste věděli, kam nasadit další instance vašich dat, které vyžadují regionální spřažení s úložištěm. Další informace najdete v tématu Spárované oblasti Azure.

Ceny geografické replikace

Geografická replikace je součástí aktuálních cen služby Azure Storage. Tomu se říká geograficky redundantní úložiště (GRS). Pokud nechcete, aby se vaše data geograficky replikovala, můžete pro svůj účet zakázat geografickou replikaci. Říká se tomu místně redundantní úložiště (LRS) a ve srovnání s GRS se účtuje za zvýhodněnou cenu.

Určení, jestli došlo k geografickému převzetí služeb při selhání

Pokud dojde k geografickému převzetí služeb při selhání, zveřejní se na řídicím panelu služby Azure Service Health. Aplikace můžou implementovat automatizované prostředky k detekci, ale monitorováním geografické oblasti pro svůj účet úložiště. Můžete ho použít k aktivaci dalších operací obnovení, jako je aktivace výpočetních prostředků v geografické oblasti, do které se jejich úložiště přesunulo.

Databáze

SQL Database

Azure SQL Database poskytuje dva typy obnovení: geografické obnovení a aktivní geografickou replikaci.

Geografické obnovení

Geografické obnovení je k dispozici také v databázích Basic, Standard a Premium. Poskytuje výchozí možnost obnovení, pokud databáze není k dispozici kvůli incidentu v oblasti, kde je vaše databáze hostovaná. Podobně jako při obnovení k určitému bodu v čase se geografické obnovení spoléhá na zálohy databáze v geograficky redundantním úložišti Azure. Obnoví se z geograficky replikované záložní kopie, a proto je odolný vůči výpadkům úložiště v primární oblasti. Další informace najdete v tématu Obnovení služby Azure SQL Database nebo převzetí služeb při selhání do sekundární služby.

Aktivní geografická replikace

Aktivní geografická replikace je dostupná pro všechny databázové úrovně. Je navržená pro aplikace, které mají agresivnější požadavky na obnovení, než může nabídnout geografické obnovení. Pomocí aktivní geografické replikace můžete vytvořit až čtyři čitelné sekundy na serverech v různých oblastech. Převzetí služeb při selhání můžete zahájit na libovolný z sekundárních souborů. Kromě toho lze aktivní geografickou replikaci použít k podpoře scénářů upgradu nebo přemístění aplikací a také vyrovnávání zatížení pro úlohy jen pro čtení. Podrobnosti najdete v tématu Konfigurace aktivní geografické replikace pro Azure SQL Database a zahájení převzetí služeb při selhání. Podrobné informace o návrhu a implementaci aplikací a upgradu aplikací bez výpadků najdete v tématu Návrh globálně dostupných služeb pomocí služby Azure SQL Database a správa postupných upgradů cloudových aplikací pomocí aktivní geografické replikace služby SQL Database.

SQL Server na Azure Virtual Machines

Pro obnovení a vysokou dostupnost pro SQL Server 2012 (a novější) běžící ve službě Azure Virtual Machines jsou k dispozici různé možnosti. Další informace najdete v tématu Vysoká dostupnost a zotavení po havárii pro SQL Server ve službě Azure Virtual Machines.

Další služby platformy Azure

Při pokusu o spuštění cloudové služby ve více oblastech Azure musíte zvážit důsledky pro každou z vašich závislostí. V následujících částech pokyny specifické pro službu předpokládají, že musíte použít stejnou službu Azure v alternativním datacentru Azure. To zahrnuje úlohy konfigurace i replikace dat.

Service Bus

Azure Service Bus používá jedinečný obor názvů, který nezahrnuje oblasti Azure. Prvním požadavkem je tedy nastavení potřebných oborů názvů služby Service Bus v alternativní oblasti. Existuje však také důležité informace o stálosti zpráv zařazených do fronty. Existuje několik strategií replikace zpráv napříč oblastmi Azure. Podrobnosti o těchto strategiích replikace a dalších strategiích zotavení po havárii najdete v tématu Osvědčené postupy pro izolaci aplikací před výpadky a haváriemi služby Service Bus.

App Service

Pokud chcete migrovat aplikaci služby Aplikace Azure, například Web Apps nebo Mobile Apps, do sekundární oblasti Azure, musíte mít k dispozici zálohu webu pro publikování. Pokud výpadek nezahrnuje celé datové centrum Azure, může být možné použít FTP ke stažení nedávné zálohy obsahu webu. Pak vytvořte novou aplikaci v alternativní oblasti, pokud jste to ještě neudělali, abyste si rezervovali kapacitu. Publikujte lokalitu do nové oblasti a proveďte potřebné změny konfigurace. Tyto změny můžou zahrnovat připojovací řetězec databáze nebo jiná nastavení specifická pro danou oblast. V případě potřeby přidejte certifikát SSL webu a změňte záznam CNAME DNS tak, aby název vlastní domény odkazovaly na znovu nasazenou adresu URL webové aplikace Azure.

HDInsight

Data přidružená ke službě HDInsight se ve výchozím nastavení ukládají ve službě Azure Blob Storage. HDInsight vyžaduje, aby byly úlohy MapReduce pro zpracování clusteru Hadoop společně přiděleny ve stejné oblasti jako účet úložiště, který obsahuje analyzovaná data. Pokud používáte funkci geografické replikace dostupnou pro Azure Storage, máte přístup k datům v sekundární oblasti, ve které se data replikovala, pokud z nějakého důvodu primární oblast už není dostupná. V oblasti, ve které se data replikovala, můžete vytvořit nový cluster Hadoop a pokračovat ve zpracování.

SQL Reporting

V tuto chvíli vyžaduje zotavení po ztrátě oblasti Azure několik instancí generování sestav SQL v různých oblastech Azure. Tyto instance generování sestav SQL by měly přistupovat ke stejným datům a tato data by měla mít v případě havárie svůj vlastní plán obnovení. Pro každou sestavu můžete také udržovat externí záložní kopie souboru RDL.

Media Services

Azure Media Services má jiný přístup k obnovení pro kódování a streamování. Streamování je obvykle důležitější během regionálního výpadku. Abyste se na to mohli připravit, měli byste mít účet Media Services ve dvou různých oblastech Azure. Kódovaný obsah by měl být umístěn v obou oblastech. Během selhání můžete streamované přenosy přesměrovat do alternativní oblasti. Kódování je možné provést v libovolné oblasti Azure. Pokud je kódování citlivé na čas, například během zpracování živých událostí, musíte být připraveni odesílat úlohy do alternativního datacentra během selhání.

Virtuální síť

Konfigurační soubory poskytují nejrychlejší způsob, jak nastavit virtuální síť v alternativní oblasti Azure. Po konfiguraci virtuální sítě v primární oblasti Azure exportujte nastavení virtuální sítě pro aktuální síť do konfiguračního souboru sítě. Pokud dojde k výpadku v primární oblasti, obnovte virtuální síť z uloženého konfiguračního souboru. Pak nakonfigurujte další cloudové služby, virtuální počítače nebo nastavení mezi místními sítěmi, aby fungovaly s novou virtuální sítí.
Existují prostředky související s virtuální sítí, které musíme vzít v úvahu (např. NSG, DNS, směrovací tabulky). Metoda popsaná v infrastruktuře jako kód je způsob, jak pokaždé vygenerovat stejné prostředí a můžete ho nasadit v nové oblasti.

Kontrolní seznamy pro zotavení po havárii

Kontrolní seznam cloudových služeb

1. Projděte si část Cloud Services tohoto dokumentu.
2. Vytvořte strategii zotavení po havárii mezi oblastmi.
3. Seznamte se s kompromisy při rezervaci kapacity v alternativních oblastech.
4. Použijte nástroje pro směrování provozu, jako je Azure Traffic Manager.

Kontrolní seznam pro virtuální počítače

1. Projděte si část Virtuální počítače v tomto dokumentu.
2. Azure Backup umožňuje vytvářet zálohy konzistentní vzhledem k aplikacím napříč oblastmi.

Kontrolní seznam k úložišti

1. Projděte si část Úložiště tohoto dokumentu.
2. Nezakažujte geografickou replikaci prostředků úložiště.
3. Seznamte se s alternativní oblastí geografické replikace, pokud dojde k převzetí služeb při selhání.
4. Vytvořte vlastní strategie zálohování pro strategie převzetí služeb při selhání řízené uživatelem.

Kontrolní seznam ke službě SQL Database

1. Projděte si část databáze SQL v tomto dokumentu.
2. Podle potřeby použijte geografické obnovení nebo geografickou replikaci .

Kontrolní seznam k SQL Serveru na virtuálních počítačích

1. Projděte si část SQL Server na virtuálních počítačích tohoto dokumentu.
2. Používejte skupiny dostupnosti AlwaysOn napříč oblastmi nebo zrcadlení databáze.
3. Alternativně použijte zálohování a obnovení do úložiště objektů blob.

Kontrolní seznam služby Service Bus

1. Projděte si část služby Service Bus tohoto dokumentu.
2. Nakonfigurujte obor názvů služby Service Bus v alternativní oblasti.
3. Zvažte vlastní strategie replikace pro zprávy napříč oblastmi.

Kontrolní seznam služby App Service

1. Projděte si část služby App Service tohoto dokumentu.
2. Udržujte zálohy lokality mimo primární oblast.
3. Pokud je výpadek částečný, pokuste se načíst aktuální web pomocí ftp.
4. Naplánujte nasazení webu do nové nebo existující lokality v alternativní oblasti.
5. Naplánujte změny konfigurace pro záznamy CNAME aplikace i DNS.

Kontrolní seznam služby HDInsight

1. Projděte si část HDInsight tohoto dokumentu.
2. Vytvořte nový cluster Hadoop v oblasti s replikovanými daty.

Kontrolní seznam pro vytváření sestav SQL

1. Projděte si část Vytváření sestav SQL tohoto dokumentu.
2. Udržujte alternativní instanci generování sestav SQL v jiné oblasti.
3. Udržujte samostatný plán pro replikaci cíle do této oblasti.

Kontrolní seznam media Services

1. Projděte si část Media Services tohoto dokumentu.
2. Vytvořte účet Media Services v alternativní oblasti.
3. Zakódujte stejný obsah v obou oblastech, aby podporovalo převzetí služeb při selhání streamování.
4. Pokud dojde k přerušení služby, odešlete úlohy kódování do alternativní oblasti.

Kontrolní seznam pro virtuální síť

1. Projděte si část Virtuální síť tohoto dokumentu.
2. K opětovnému vytvoření v jiné oblasti použijte exportovaná nastavení virtuální sítě.