Havárie můžou být selhání hardwaru, přírodní katastrofy nebo selhání softwaru. Proces přípravy na zotavení po havárii a zotavení po havárii se nazývá zotavení po havárii (DR). Tento článek popisuje doporučené postupy pro zajištění provozní kontinuity a zotavení po havárii (BCDR) pro kanály Azure Data Factory a Azure Synapse Analytics.
Strategie BCDR zahrnují redundanci zón dostupnosti, automatizované obnovení poskytované zotavením po havárii Azure a obnovení spravované uživatelem pomocí kontinuální integrace a průběžného doručování (CI/CD).
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Workflow
Kanály Data Factory a Azure Synapse dosáhnou odolnosti pomocí oblastí Azure a zón dostupnosti Azure.
- Každá oblast Azure má sadu datacenter nasazených v rámci hraniční sítě definované latencí.
- Zóny dostupnosti Azure jsou fyzicky oddělená umístění v jednotlivých oblastech Azure, které jsou odolné vůči místním selháním.
- Všechny oblasti Azure a zóny dostupnosti jsou připojené prostřednictvím vyhrazené sítě s nízkou latencí v jednotlivých oblastech a sítě s vysokým výkonem.
- Všechny oblasti s podporou zóny dostupnosti mají aspoň tři samostatné zóny dostupnosti, aby se zajistila odolnost.
Když dojde k výpadku datacentra, části datacentra nebo zóny dostupnosti v určité oblasti, dojde k nulovému výpadku u zónově odolných kanálů Data Factory a Azure Synapse.
Komponenty
Podrobnosti scénáře
Kanály Data Factory a Azure Synapse ukládají artefakty, které obsahují následující data:
Metadata
- Kanál
- Datové sady
- Propojené služby
- Prostředí Integration Runtime
- Aktivační události
Data monitorování
- Kanál
- Aktivační události
- Spuštění aktivit
Havárie můžou napadnou různými způsoby, jako jsou selhání hardwaru, přírodní katastrofy nebo selhání softwaru, které vyplývají z lidské chyby nebo kybernetického útoku. V závislosti na typech selhání může být jejich geografický dopad regionální nebo globální. Při plánování strategie zotavení po havárii zvažte jak povahu havárie, tak její geografický dopad.
BCDR v Azure funguje na modelu sdílené odpovědnosti. Řada služeb Azure vyžaduje, aby zákazníci explicitně nastavili strategii zotavení po havárii, zatímco Azure podle potřeby poskytuje základní služby infrastruktury a platformy.
Pomocí následujících doporučených postupů můžete dosáhnout BCDR pro kanály Data Factory a Azure Synapse v různých scénářích selhání. Implementace najdete v tématu Nasazení tohoto scénáře.
Automatizované obnovení s využitím zotavení po havárii Azure
Při automatizovaném obnovení poskytnutém službou Azure Backup a zotavení po havárii dojde k úplnému regionálnímu výpadku pro oblast Azure, která má spárovanou oblast, službu Data Factory nebo kanály Azure Synapse automaticky převezme služby při selhání spárované oblasti při nastavování automatizovaného obnovení. Výjimkou jsou oblasti Jihovýchodní Asie a Brazílie, kde požadavky na rezidenci dat vyžadují, aby data zůstala v těchto oblastech.
Při převzetí služeb při selhání zotavení po havárii služba Data Factory obnoví produkční kanály. Pokud potřebujete ověřit obnovené kanály, můžete zálohovat šablony Azure Resource Manageru pro produkční kanály v úložišti tajných kódů a porovnat obnovené kanály se zálohami.
Globální tým Azure provádí pravidelné postupy BCDR a azure Data Factory a Azure Synapse Analytics se účastní těchto postupů. Postup BCDR simuluje selhání oblasti a převzetí služeb při selhání služeb Azure do spárované oblasti bez jakéhokoli zásahu zákazníka. Další informace o podrobnostech BCDR naleznete v tématu Testování služeb.
Redundance spravovaná uživatelem pomocí CI/CD
K dosažení BCDR v případě selhání celé oblasti potřebujete datovou továrnu nebo pracovní prostor Azure Synapse v sekundární oblasti. V případě náhodného odstranění kanálu Data Factory nebo kanálu Azure Synapse nebo událostí interní údržby můžete kanály obnovit ručně pomocí Gitu a CI/CD.
Volitelně můžete použít aktivní/pasivní implementaci. Primární oblast zpracovává běžné operace a zůstává aktivní, zatímco sekundární oblast zotavení po havárii vyžaduje předplánované kroky v závislosti na konkrétní implementaci, aby byla povýšena na primární. V takovém případě jsou všechny potřebné konfigurace pro infrastrukturu dostupné v sekundární oblasti, ale nejsou zřízené.
Potenciální případy použití
Redundance spravovaná uživatelem je užitečná ve scénářích, jako jsou:
- Náhodné odstranění artefaktů kanálu prostřednictvím lidské chyby
- Rozšířené výpadky nebo události údržby, které neaktivují BCDR, protože se nenahlásila žádná havárie.
Produkční úlohy můžete rychle přesunout do jiných oblastí a nebude to mít vliv.
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Spolehlivost
Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.
Kanály Data Factory a Azure Synapse jsou hlavní služby Azure, které podporují zóny dostupnosti a jsou navržené tak, aby poskytovaly správnou úroveň odolnosti a flexibility spolu s ultra nízkou latencí.
Přístup pro obnovení spravovaný uživatelem umožňuje pokračovat v provozu, pokud v primární oblasti existují nějaké události údržby, výpadky nebo lidské chyby. Pomocí CI/CD se datové továrny a kanály Azure Synapse můžou integrovat do úložiště Git a nasadit je do sekundární oblasti pro okamžité obnovení.
Optimalizace nákladů
Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.
Obnovení spravované uživatelem integruje službu Data Factory s Gitem pomocí CI/CD a volitelně používá sekundární oblast zotavení po havárii, která má jako zálohu všechny potřebné konfigurace infrastruktury. V tomto scénáři můžou vzniknout další náklady. K odhadu nákladů použijte cenovou kalkulačku Azure.
Příklady cen služby Data Factory a Azure Synapse Analytics najdete tady:
Provozní dokonalost
Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity provozu.
Pomocí přístupu pro obnovení CI/CD spravovaného uživatelem můžete integrovat do Azure Repos nebo GitHubu. Další informace o osvědčených postupech CI/CD najdete v tématu Osvědčené postupy pro CI/CD.
Nasazení tohoto scénáře
Pomocí následujících akcí nastavte automatizované nebo uživatelem spravované zotavení po havárii pro službu Data Factory a kanály Azure Synapse.
Nastavení automatizovaného obnovení
Ve službě Data Factory můžete nastavit oblast prostředí Azure Integration Runtime (IR) pro spouštění aktivit nebo odesílání v nastavení prostředí Integration Runtime. Pokud chcete povolit automatické převzetí služeb při selhání v případě úplného regionálního výpadku, nastavte oblast na automatické řešení.
V kontextu prostředí Integration Runtime převezme prostředí IR služby při selhání automaticky do spárované oblasti, když jako oblast IR vyberete automatické řešení . V případě jiných konkrétních oblastí umístění můžete vytvořit sekundární datovou továrnu v jiné oblasti a pomocí CI/CD zřídit datovou továrnu z úložiště Git.
U spravovaných virtuálních sítí služba Data Factory také automaticky přepne na spravované prostředí IR.
Automatické převzetí služeb při selhání spravované Azure se nevztahuje na místní prostředí Integration Runtime (SHIR), protože infrastruktura je spravovaná zákazníkem. Pokyny k nastavení více uzlů pro vyšší dostupnost pomocí SHIR najdete v tématu Vytvoření a konfigurace místního prostředí Integration Runtime.
Pokud chcete nakonfigurovat BCDR pro Azure-SSIS IR, přečtěte si téma Konfigurace prostředí Azure-SSIS Integration Runtime pro provozní kontinuitu a zotavení po havárii (BCDR).
Propojené služby nejsou po převzetí služeb při selhání plně povolené, protože čekající privátní koncové body v novější síti oblasti. V obnovené oblasti je potřeba nakonfigurovat privátní koncové body. Vytvoření privátního koncového bodu můžete automatizovat pomocí rozhraní API pro schvalování.
Nastavení obnovení spravovaného uživatelem prostřednictvím CI/CD
Kanály gitu a CI/CD můžete použít k ručnímu obnovení kanálů v případě odstranění nebo výpadku kanálu Azure Synapse.
Pokud chcete použít CI/CD kanálu Data Factory, přečtěte si téma Kontinuální integrace a doručování ve službě Azure Data Factory a správa zdrojového kódu ve službě Azure Data Factory.
Pokud chcete použít CI/CD kanálu Azure Synapse, přečtěte si téma Kontinuální integrace a doručování pro pracovní prostor Azure Synapse Analytics. Nejprve nezapomeňte inicializovat pracovní prostor Azure Synapse. Další informace najdete v tématu Správa zdrojového kódu v nástroji Synapse Studio.
Když nasadíte redundanci spravovanou uživatelem pomocí CI/CD, proveďte následující akce:
Zakázání aktivačních událostí
Po návratu do režimu online zakažte triggery v původní primární datové továrně. Triggery můžete zakázat ručně nebo implementovat automatizaci, abyste pravidelně kontrolovali dostupnost původního primárního serveru. Zakažte všechny triggery v původní primární datové továrně hned po obnovení objektu pro vytváření.
Pokud chcete pomocí Azure PowerShellu vypnout nebo zapnout triggery služby Data Factory, prohlédni si ukázkový skript před nasazením a vylepšení CI/CD související s nasazením triggerů kanálu.
Zpracování duplicitních zápisů
Většina kanálů extrakce, transformace, načítání (ETL) je navržená tak, aby zpracovávala duplicitní zápisy, protože jejich opětovné vyplňování a obnovení vyžadují. Datové jímky, které podporují transparentní převzetí služeb při selhání, můžou zpracovávat duplicitní zápisy se záznamy sloučením nebo odstraněním a vložením všech záznamů do konkrétního časového rozsahu.
U datových jímek, které mění koncové body po převzetí služeb při selhání, může primární a sekundární úložiště obsahovat duplicitní nebo částečná data. Data musíte sloučit ručně.
Kontrola určující kopie a řízení toku kanálu (volitelné)
Obecně je potřeba navrhnout kanály tak, aby zahrnovaly aktivity, jako jsou neúspěšné a vyhledávací aktivity, pro restartování neúspěšných kanálů z hlediska zájmu.
Přidejte do datové továrny globální parametr, který označuje oblast, například
region='EastUS'v primární aregion='CentralUS'sekundární datové továrně.Vytvořte určující kopii ve třetí oblasti. Určujícím souborem může být volání REST nebo jakýkoli typ úložiště. Určující složka vrátí aktuální primární oblast, například
'EastUS've výchozím nastavení.Když dojde k havárii, aktualizujte ručně určující kopii, aby vrátila novou primární oblast, například
'CentralUS'.Přidejte do kanálu aktivitu, která vyhledá určující kopii a porovná aktuální primární hodnotu s globálním parametrem.
- Pokud se parametry shodují, tento kanál běží v primární oblasti. Pokračujte skutečnou prací.
- Pokud se parametry neshoduje, tento kanál běží v sekundární oblasti. Stačí vrátit výsledek.
Poznámka:
Tento přístup představuje závislost na vyhledávání kopií clusteru ve vašem kanálu. Při čtení určující kopie se zastaví všechna spuštění kanálu.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autoři:
Krishnakumar Rukmangathan | Vedoucí programový manažer – tým Azure Data Factory
Sunil Sabat | Hlavní programový manažer – tým Azure Data Factory
Další přispěvatelé:
Mario Zimmermann | Hlavní správce softwarového inženýrství – tým Azure Data Factory
Wee Hyong Tok | Hlavní ředitel PM – tým Azure Data Factory
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
- Správa provozní kontinuity v Azure
- Odolnost v Azure
- Terminologie odolnosti Azure
- Oblasti a zóny dostupnosti
- Replikace mezi oblastmi v Azure
- Průvodce pro výběr oblastí Azure
- Služby Azure, které podporují zóny dostupnosti
- Sdílená odpovědnost v cloudu
- Redundance dat v Azure Data Factory
- Prostředí Integration Runtime ve službě Azure Data Factory
- Kanály a aktivity ve službě Azure Data Factory a Azure Synapse Analytics
- Integrace dat ve službě Azure Synapse Analytics versus Azure Data Factory