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

Článek
03/21/2023

Azure je fyzicky a logicky rozdělený do jednotek označovaných jako oblasti. Oblast se skládá z jednoho nebo více datových center v těsné blízkosti. Mnoho 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 datacentru. Zvažte použití oblastí se zónami dostupnosti ke zlepšení dostupnosti vašeho řešení.

Ve výjimečných případech je možné, že zařízení v celé zóně dostupnosti nebo oblasti můžou být nedostupná, například kvůli selháním sítě. Nebo mohou být zařízení zcela ztracena, například kvůli přírodní katastrofě. Azure má funkce pro vytváření aplikací, které jsou distribuované napříč zónami a oblastmi. Taková distribuce pomáhá minimalizovat možnost, že selhání v jedné zóně nebo oblasti může ovlivnit jiné zóny nebo oblasti.

Cloud Services

Správa prostředků

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 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 služba pro správu provozu.

Důležitým aspektem plánování kapacity je určení počtu instancí náhradních rolí, které se mají předem nasadit pro zotavení po havárii. Plně škálovatelné sekundární nasazení zajišťuje, že kapacita bude v případě potřeby již dostupná. tím se však náklady v podstatě zdvojnásobí. 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 pro rezervaci kapacity, tak pro testování konfigurace sekundárního prostředí.

Poznámka

Kvóta předplatného není zárukou kapacity. Kvóta je jednoduše úvěrový limit. Aby bylo možné zaručit kapacitu, musí být v modelu služby definován požadovaný počet rolí a role musí být nasazeny.

Vyrovnávání zatížení

Vyrovnávání zatížení provozu mezi oblastmi vyžaduje řešení pro správu provozu. Azure poskytuje Azure Traffic Manager. Můžete také využít služby třetích stran, které poskytují podobné funkce správy provozu.

Strategie

Pro implementaci distribuovaných výpočetních prostředků napříč oblastmi je k dispozici mnoho alternativních strategií. Ty musí být přizpůsobeny 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 znovu nasadí od začátku v době havárie. To je vhodné pro nekritičtější 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í, aby byla zaručena minimální kapacita. role ale nepřijímá produkční provoz. Tento přístup je užitečný pro aplikace, které nebyly navrženy tak, aby distribuovaly provoz napříč oblastmi.
Hot Spare (aktivní/aktivní): 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 potřeba pro účely zotavení po havárii. Případně se cloudové služby můžou v době havárie podle potřeby škálovat na více instancí a převzít služby při selhání. Tento přístup vyžaduje značné investice do návrhu aplikací, ale má značné výhody. Patří mezi ně nízká a zaručená doba obnovení, průběžné testování všech umístění obnovení a efektivní využití kapacity.

Kompletní 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čů typu infrastruktura jako služba (IaaS) je v mnoha ohledech podobné výpočetnímu obnovení typu platforma jako služba (PaaS). Existují však důležité rozdíly způsobené skutečností, ž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í Azure Backup můžete vytvářet zálohy mezi 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 na více discích virtuálních počítačů a podporovat replikaci záloh napříč oblastmi. Můžete to udělat tak, že zvolíte geografickou replikaci trezoru záloh v době vytvoření. Replikace trezoru záloh musí být nakonfigurovaná v okamžiku vytvoření. Později ho nejde nastavit. Pokud dojde ke ztrátě oblasti, Microsoft zpřístupní zálohy zákazníkům. Zákazníci budou moct provést obnovení do libovolného ze svých nakonfigurovaných bodů obnovení.
Oddělte datový disk od disku operačního systému. Důležitým aspektem pro virtuální počítače 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 je vaší strategií obnovení opětovné nasazení po havárii. Pokud ale k rezervované kapacitě používáte přístup Warm Spare, může to být problém. Aby bylo možné tento postup správně implementovat, musíte mít nasazený správný disk operačního systému v primárním i sekundárním umístění a data aplikace musí být uložena na samostatné jednotce. Pokud je to možné, použijte standardní konfiguraci operačního systému, která se dá poskytnout v obou umístěních. Po převzetí služeb při selhání pak musíte datovou jednotku připojit ke stávajícím virtuálním počítačům IaaS v sekundárním řadiči domény. Pomocí Nástroje AzCopy zkopírujte snímky datových disků do vzdálené lokality.
Mějte na paměti možné 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 charakteristiku geografické replikace. Pokud nepoužíváte Azure Backup, neexistují žádné záruky konzistence mezi disky, protože geografická replikace je asynchronní a replikuje se nezávisle. Jednotlivé disky virtuálních počítačů jsou po geografickém převzetí služeb při selhání v konzistentním stavu, ale ne konzistentní mezi disky. To může v některých případech způsobit problémy (například v případě prokládání disků).
Azure Site Recovery můžete použít k replikaci aplikací napříč oblastmi. S Azure Site Recovery se zákazníci nemusí starat o oddělení datových disků od disků operačního systému ani potenciální problémy s konzistencí. Azure Site Recovery replikuje úlohy běžící na fyzických a virtuálních počítačích z primární lokality (místní nebo v Azure) do sekundárního umístění (v Azure). Pokud dojde k výpadku v primární lokalitě zákazníka, je možné aktivovat převzetí služeb při selhání, které zákazníka rychle vrátí do provozního stavu. Po obnovení primárního umístění můžou zákazníci navrátit služby po obnovení. Můžou se snadno replikovat pomocí bodů obnovení se snímky konzistentními vzhledem k aplikacím. Tyto snímky zaznamenávají data na disku, všechna data v paměti a všechny transakce v procesu. Azure Site Recovery umožňuje zákazníkům udržovat cíle doby obnovení (RTO) a cíle bodu obnovení (RPO) v rámci organizačních limitů. 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řidávat skripty a ruční akce. Plány obnovení je možné integrovat s runbooky Azure Automation.

Storage

Obnovení pomocí geograficky redundantního úložiště objektů blob, tabulek, front a diskových úložišť virtuálních počítačů

V Azure se objekty blob, tabulky, fronty a disky virtuálních počítačů ve výchozím nastavení geograficky replikují. 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 konkrétní geografické oblasti. GRS je navržený tak, aby poskytoval další odolnost v případě velké havárie datacentra. Společnost Microsoft řídí, kdy dojde k převzetí služeb při selhání, a převzetí služeb při selhání je omezeno na závažné havárie, kdy je původní primární umístění považováno za neobnovitelné 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ž se na interval synchronizace ještě nevztahuje smlouva o úrovni služeb.

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

Kromě automatického převzetí služeb při selhání, které poskytuje GRS, azure zavedl službu, která poskytuje přístup pro čtení ke kopii vašich dat v sekundárním úložišti. To se nazývá geograficky redundantní úložiště s přístupem pro čtení (RA-GRS).

Další informace o úložišti GRS a 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 vaše data geograficky replikují, abyste věděli, kam nasadit další instance vašich dat, které vyžadují regionální spřažení s vaším úložištěm. Další informace najdete v tématu Spárované oblasti Azure.

Ceny geografické replikace

Geografická replikace je zahrnutá v aktuálních cenách služby Azure Storage. Tomu se říká geograficky redundantní úložiště (GRS). Pokud nechcete, aby se data geograficky replikovala, můžete geografickou replikaci pro svůj účet zakázat. Označuje se jako 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ý způsob, jak to zjistit, 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. Můžete na to provést dotaz z rozhraní API pro správu služeb pomocí příkazu Získat vlastnosti účtu úložiště. Relevantní vlastnosti jsou:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

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 je databáze nedostupná kvůli incidentu v oblasti, kde je vaše databáze hostovaná. Podobně jako obnovení k určitému bodu v čase závisí geografické obnovení na zálohování databází 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í Azure SQL databáze nebo převzetí služeb při selhání do sekundární databáze.

Aktivní geografická replikace

Aktivní geografická replikace je k dispozici pro všechny databázové vrstvy. Je navržený pro aplikace, které mají agresivnější požadavky na obnovení, než nabízí geografické obnovení. Pomocí aktivní geografické replikace můžete na serverech v různých oblastech vytvořit až čtyři sekundární soubory pro čtení. Převzetí služeb při selhání můžete zahájit u libovolného sekundárního serveru. Aktivní geografickou replikaci je navíc možné použít k podpoře scénářů upgradu nebo přemístění aplikace a 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í. Podrobnosti o tom, jak navrhovat a implementovat upgrady aplikací a aplikací bez výpadků, najdete v tématu Navrhování globálně dostupných služeb pomocí Azure SQL Databáze a Správa upgradů cloudových aplikací s využitím SQL Database aktivní geografické replikace.

SQL Server na Azure Virtual Machines

Pro obnovení a vysokou dostupnost pro SQL Server 2012 (a novější) běžící v 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 v Azure Virtual Machines.

Další služby platformy Azure

Při pokusu o spuštění cloudové služby v několika oblastech Azure musíte zvážit důsledky pro každou z vašich závislostí. V následujících částech pokyny pro konkrétní 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.

Poznámka

V některých případech můžou tyto kroky pomoct zmírnit výpadek konkrétní služby místo celé události datacentra. Z hlediska aplikace může být výpadek specifický pro službu stejně omezující a vyžadoval by dočasnou migraci služby do alternativní oblasti Azure.

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. Existují však také aspekty stálosti zpráv ve frontě. 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 Azure App Service aplikaci, 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 se výpadek netýká celého datacentra 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 předtím neudělali kvůli rezervaci kapacity. Publikujte lokalitu do nové oblasti a proveďte potřebné změny konfigurace. Tyto změny můžou zahrnovat databázové připojovací řetězce nebo jiná nastavení specifická pro danou oblast. V případě potřeby přidejte certifikát SSL webu a změňte záznam DNS CNAME tak, aby název vlastní domény odkazovaly na adresu URL znovu nasazené webové aplikace Azure.

HDInsight

Data přidružená ke službě HDInsight jsou ve výchozím nastavení uložena v Azure Blob Storage. HDInsight vyžaduje, aby cluster Hadoop zpracovávající úlohy MapReduce byl společně umístěné ve stejné oblasti jako účet úložiště, který obsahuje analyzovaná data. Pokud použijete funkci geografické replikace dostupnou pro Azure Storage, budete mít přístup ke svým datům v sekundární oblasti, kde se data replikovala, pokud z nějakého důvodu už primární oblast není dostupná. Můžete vytvořit nový cluster Hadoop v oblasti, ve které byla data replikována, a pokračovat v jejich zpracování.

SQL Reporting

Zotavení po ztrátě oblasti Azure v tuto chvíli vyžaduje několik SQL Reporting instancí v různých oblastech Azure. Tyto SQL Reporting instance by měly přistupovat ke stejným datům a tato data by měla mít v případě havárie 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 se měl nacházet 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 odeslat úlohy do alternativního datacentra v případě 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 různými místy tak, aby fungovaly s novou virtuální sítí.
Musíme vzít v úvahu prostředky související s virtuální sítí (např. NSG, DNS, směrovací tabulky). Metoda popsaná v tématu Infrastruktura jako kód je způsob, jak pokaždé vygenerovat stejné prostředí a můžete je nasadit v nové oblasti.

Kontrolní seznamy pro zotavení po havárii

Cloud Services kontrolní seznam

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

Virtual Machines kontrolní seznam

Projděte si část Virtual Machines tohoto dokumentu.
Pomocí Azure Backup můžete vytvářet zálohy konzistentní vzhledem k aplikacím napříč oblastmi.

Kontrolní seznam úložiště

Projděte si část Úložiště tohoto dokumentu.
Nezakazujte geografickou replikaci prostředků úložiště.
Vysvětlení alternativní oblasti pro geografickou replikaci, pokud dojde k převzetí služeb při selhání
Vytvořte vlastní strategie zálohování pro strategie převzetí služeb při selhání řízené uživatelem.

kontrolní seznam SQL Database

Projděte si část SQL Database tohoto dokumentu.
Podle potřeby použijte geografické obnovení nebo geografickou replikaci .

SQL Server na kontrolním seznamu Virtual Machines

Projděte si část SQL Server Virtual Machines tohoto dokumentu.
Použijte skupiny dostupnosti AlwaysOn mezi oblastmi nebo zrcadlení databáze.
Alternativně použijte zálohování a obnovení do úložiště objektů blob.

Kontrolní seznam služby Service Bus

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

App Service kontrolní seznam

Projděte si část App Service tohoto dokumentu.
Udržujte zálohy lokality mimo primární oblast.
Pokud je výpadek částečný, zkuste načíst aktuální web pomocí protokolu FTP.
Naplánujte nasazení webu na nový nebo existující web v alternativní oblasti.
Naplánujte změny konfigurace pro záznamy CNAME aplikace i DNS.

Kontrolní seznam služby HDInsight

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

SQL Reporting kontrolní seznam

Projděte si část SQL Reporting tohoto dokumentu.
Udržujte alternativní instanci SQL Reporting v jiné oblasti.
Udržujte samostatný plán pro replikaci cíle do této oblasti.

Kontrolní seznam ke službě Media Services

Projděte si část Media Services tohoto dokumentu.
Vytvořte účet Media Services v alternativní oblasti.
Kódování stejného obsahu v obou oblastech pro podporu převzetí služeb při selhání streamování
Pokud dojde k přerušení služby, odešlete úlohy kódování do alternativní oblasti.

kontrolní seznam Virtual Network

Projděte si část Virtual Network tohoto dokumentu.
Pomocí exportovaného nastavení virtuální sítě ji znovu vytvořte v jiné oblasti.