Provozní kontinuita a zotavení po havárii pro analýzy škálování cloudu

Při návrhu architektury pro cloudovou službu zvažte požadavky na dostupnost a způsob reakce na potenciální přerušení služby. Problém může být lokalizován do konkrétní instance nebo oblasti v celé oblasti. Plánování obojího je důležité. V závislosti na vašem cíli doby obnovení a cíli bodu obnovení můžete zvolit agresivní strategii pro vysokou dostupnost a zotavení po havárii.

Vysoká dostupnost a zotavení po havárii je někdy možné kombinovat. Tyto dvě oblasti mají mírně odlišné strategie, zejména pokud jde o data. Další informace najdete v tématu Microsoft Azure Well-Architected Framework a jeho principy spolehlivosti.

Místo toho, abyste se snažili zabránit selháním, přijměte předem, že k chybám může a dochází. Minimalizujte účinky jakékoli jedné součásti, která selhává v životním cyklu. Typ řešení, které se má implementovat, určuje vaše tolerance k nákladům, cíli bodu obnovení a časovému cíli obnovení.

Strategie zálohování

Pro implementaci distribuovaných výpočetních prostředků napříč oblastmi je k dispozici mnoho alternativních strategií. Strategie musí být přizpůsobeny obchodním požadavkům a okolnostem vaší aplikace. Na vysoké úrovni spadají přístupy do následujících kategorií:

• Zálohování a obnovení: Obnovte aplikaci databáze z poslední záložní kopie před havárií. Tento přístup se běžně používá po poškození dat nebo náhodném odstranění.

• Opětovné nasazení při havárii: Znovu nasaďte aplikaci od nuly v době havárie. Tento přístup je vhodný pro nekritičtější aplikace, které nevyžadují zaručenou dobu obnovení.

• Teplá náhradní (aktivní/pasivní): Vytvořte sekundární hostované služby v alternativní oblasti. Nasaďte role, abyste zajistili minimální kapacitu. Role nedostávají produkční provoz. Tento přístup je užitečný pro aplikace, které nebyly navrženy tak, aby distribuovaly provoz napříč oblastmi.

• Horká rezerva (aktivní/aktivní): Navrhnou aplikaci tak, aby přijímala produkční zatížení ve více oblastech. Cloudové služby v každé oblasti můžete nakonfigurovat pro vyšší kapacitu, než je potřeba pro účely zotavení po havárii. Místo toho byste mohli škálovat cloudové služby podle potřeby v době havárie a převzetí služeb při selhání.

  Tento přístup vyžaduje investice do návrhu aplikací, ale má výhody. Nabízí nízkou a zaručenou dobu obnovení. Nepřetržitě se testuje všechna umístění pro obnovení a efektivní využití kapacity. U databázových aplikací tento přístup zahrnuje nástroj pro vyrovnávání zatížení pro dvě databáze, které se synchronizují s jedním spojovacím bodem.

Zotavení po havárii a vysoká dostupnost služeb Azure

Následující části popisují různé služby Azure.

Azure Cosmos DB

Přehled vysoké dostupnosti se službou Azure Cosmos DB najdete v tématu Jak azure Cosmos DB poskytuje vysokou dostupnost.

Azure Data Factory

Integrace dat a datový produkt mají pravděpodobně propojená úložiště Azure DevOps s Azure Data Factory. Kanály můžete nasadit do jiné služby Data Factory s minimálními výpadky. Pokud chcete kromě Úložiště GitHubu a Azure DevOps používat software pro správu verzí kódu, použijte sadu Azure Data Factory SDK k vytváření kanálů a dalších objektů Azure Data Factory.

Azure Data Lake

Azure Data Lake Storage Gen2 již podporuje 3x replikaci, která chrání před lokalizovanými selháními hardwaru. Další možnosti replikace, například zónově redundantní úložiště (ZRS) nebo geograficky zónově redundantní úložiště (GZRS), zlepšují vysokou dostupnost. Geograficky redundantní úložiště (GRS) a geograficky redundantní úložiště s přístupem pro čtení (RA-GRS) zlepšují zotavení po havárii. V případě vysoké dostupnosti potřebuje úloha co nejrychleji přístup k nejnovějším datům, pokud dojde k přerušení služby. Úloha se může přepnout na replikovanou instanci místně nebo do nové oblasti.

Účet úložiště nakonfigurovaný jako RA-GRS nebo GRS může být součástí plánu zotavení po havárii, ale vyžaduje náležitou péči při analýze cíle bodu obnovení (RPO) a cíle doby obnovení (RTO) a kontrolu dalších možností, jako je scénář duálního načtení, který kopíruje data do dvou různých oblastí Azure.

Každá cílová zóna dat musí mít cíl bodu obnovení pro své datové produkty. Každá cílová zóna dat musí mít definovanou strategii replikace pro své případy použití.

Další informace najdete v tématu Zotavení po havárii a převzetí služeb při selhání účtu úložiště.

Azure Databricks

Přehled architektury zotavení po havárii pro clustery Azure Databricks najdete v tématu Regionální zotavení po havárii pro clustery Azure Databricks.

Azure Machine Learning

Přehled vysoké dostupnosti služby Azure Machine Learning najdete v tématu Převzetí služeb při selhání pro zajištění provozní kontinuity a zotavení po havárii.

Azure Key Vault

Azure Key Vault poskytuje funkce, které vám pomůžou udržet dostupnost a zabránit ztrátě dat. Zálohovat tajné kódy jenom v případě, že máte důležité obchodní odůvodnění. Zálohování tajných kódů v trezoru klíčů může představovat provozní problémy, jako je údržba několika sad protokolů, oprávnění a záloh po vypršení platnosti nebo obměně tajných kódů. Další informace najdete v tématu Zálohování azure Key Vault.

Key Vault udržuje dostupnost ve scénářích havárie. Převezme služby při selhání požadavků do spárované oblasti bez jakéhokoli zásahu uživatele. Další informace najdete v tématu Dostupnost a redundance azure Key Vault. Alternativně můžete zvážit ukládání tajných kódů a dalších artefaktů Key Vault do sekundárního trezoru s příslušnými oprávněními. Tento model může být vhodný pro aplikace, které vyžadují, aby byl trezor ve stejné oblasti jako aplikace.

Azure SQL Database

Přehled provozní kontinuity s Azure SQL Database najdete v tématu Přehled provozní kontinuity s Azure SQL Database.

Azure Synapse Analytics

Přehled provozní kontinuity s Azure Synapse Analytics najdete v tématu Vysoká dostupnost pro Azure Synapse Analytics.

Další kroky

• Přehled zásad správného řízení dat