Zotavení po havárii

Zotavení po havárii (DR) pro Azure Databricks replikuje pracovní prostory, data a konfigurace napříč cloudovými oblastmi, aby vaše týmy dál fungovaly, když oblastní výpadek přenese primární nasazení do offline režimu. Kompletní plán obnovy po havárii zahrnuje nejen Azure Databricks, ale také zdroje dat, nástroje pro ingesti dat, nástroje BI a plánovače, ke kterým se připojuje.

Tato stránka popisuje koncepty, strategie, nástroje a testovací postupy, které potřebujete k návrhu a spuštění řešení zotavení po havárii napříč oblastmi.

S plánováním zotavení po havárii teprve začínáte? Začněte u terminologie v oblasti zotavení po havárii, kde najdete definice cíle bodu obnovení (RPO) a cíle doby obnovení (RTO).

Důležité

Použijte spravované obnovení po havárii. Azure Databricks doporučuje spravované zotavení po havárii pro zotavení po havárii napříč oblastmi v AWS a Azure. Průběžně replikuje metadata katalogu Unity, data spravovaných tabulek a prostředky pracovních prostorů, poskytuje stabilní adresu URL, která zůstane zachována i po převzetí služeb při selhání, a umožňuje spustit převzetí služeb při selhání z konzoly účtu. Žádné skripty replikace k zápisu nebo údržbě. Pokyny DIY na této stránce používejte pouze pro prostředky, které spravované řešení DR nereplikuje, nebo pokud vyžadujete topologie aktivní-aktivní, replikaci mezi cloudy nebo podrobnou kontrolu nad procesem replikace.

Záruky vysoké dostupnosti v rámci regionu

Zbytek této stránky popisuje zotavení po havárii napříč oblastmi, ale Azure Databricks také poskytuje vysokou dostupnost (HA) v jedné oblasti. Nejprve porozumíte těmto zárukám. Určí, jestli potřebujete samostatnou DR strategii.

HA a DR řeší různé problémy:

HA využívá redundanci zóny dostupnosti (AZ) v rámci oblasti. Pokud jedna zóna selže, služby dál běží v ostatních.
DR používá mezioblastní replikaci. Provozujete sekundární pracovní prostory Azure Databricks v jiném regionu, replikujete do nich data a konfiguraci a během výpadku regionu na ně převedete provoz.

Pokud nepotřebujete disaster recovery ve více oblastech, může stačit vysoká dostupnost Azure Databricks. HA eliminuje složitost mezi regiony, ale nechrání před výpadkem celého regionu. Pokud pro DR spoléháte pouze na HA, ověřte izolaci a redundanci svého cloudového regionu.

Garance vysoké dostupnosti v rámci regionu pokrývají řídicí rovinu a výpočetní rovinu.

Dostupnost řídicí roviny Azure Databricks

Řídicí rovina Azure Databricks je odolná vůči selhání zóny a automaticky se obnoví přibližně do 15 minut od výpadku zóny. Pravidelné testování selhání zóny to ověří.

Všechny bezstavové služby řídicí roviny můžou ztratit jednotlivé virtuální počítače nebo všechny virtuální počítače v celé zóně, aniž by došlo k výpadku služby. Data pracovního prostoru se ukládají v databázích replikovaných napříč zónami v dané oblasti. Účty úložiště, které hostují obrazy Databricks Runtime, jsou také redundantní v rámci oblasti a všechny oblasti mají sekundární účty úložiště, které převezmou jejich roli, když je primární účet úložiště mimo provoz.

Note

Výše uvedené záruky řídicí roviny platí pro Azure Databricks spravovanou infrastrukturu. Odpovídáte za zónovou redundanci výpočetní vrstvy, například volbou úložiště s redundancí napříč zónami pro kořenový bucket pracovního prostoru a používáním fondů instancí, které jsou rozprostřené napříč zónami dostupnosti.

Některé oblasti Azure používají řídicí rovinu nasazenou ve spárované oblasti. Podívejte se na oblasti Azure Databricks.

Odolnost vůči výpadku zóny podporuje nejvýše výpadek jedné zóny a je k dispozici pouze v oblastech Azure, které podporují více zón.

Dostupnost výpočetní roviny

Dostupnost pracovního prostoru závisí na dostupnosti řídicí roviny.

Kořenová data DBFS nejsou ovlivněna, pokud je účet úložiště nakonfigurovaný s zónově redundantním úložištěm (ZRS) nebo geograficky zónově redundantním úložištěm (GZRS). Výchozí možností je geograficky redundantní úložiště (GRS).

Uzly clusteru se načítají z různých zón dostupnosti vyžádáním uzlů od poskytovatele výpočetních prostředků Azure za předpokladu dostatečné kapacity ve zbývajících zónách. Pokud dojde ke ztrátě uzlu, správce clusteru požádá o náhradní uzly od poskytovatele výpočetních prostředků Azure, který je načítá z dostupných zón AZ. Výjimkou je ztráta uzlu ovladače. V takovém případě správce clusteru restartuje úlohu a cluster.

Chcete-li ověřit podporu více zón dostupnosti, podívejte se na seznam oblastí Azure. Pro odolnost výpočetní roviny s podporou více AZ použijte zónově redundantní úložiště.

Terminologie

Tyto definice používejte konzistentně při diskuzi o zotavení po havárii s týmem.

Terminologie oblastí

Tato stránka používá následující definice oblasti:

Primární oblast: Oblast, ve které uživatelé spouštějí úlohy každodenní interaktivní a automatizované analýzy dat.
Sekundární oblast: Oblast, ve které it týmy dočasně přesunují úlohy během výpadku primární oblasti.
Geograficky redundantní úložiště: Asynchronní replikace trvalého úložiště mezi oblastmi Projděte si dokumentaci ke cloudu:

Geograficky redundantní úložiště napříč oblastmi (Azure)

Důležité

Nespoléhejte na geograficky redundantní úložiště při duplikaci kořenového úložiště Azure Databricks (například ADLS, nebo u pracovních prostorů vytvořených před 6. březnem 2023 na Azure Blob Storage, které Azure Databricks vytváří pro každý pracovní prostor) mezi oblastmi. Chcete-li replikovat data spravovaných tabulek, použijte Delta Deep Clone a data, která nejsou ve formátu Delta, pokud je to možné, nejprve převeďte na Delta.

Terminologie stavu nasazení

Na této stránce se používají následující definice stavu nasazení:

Aktivní nasazení (někdy označované jako horké nasazení): Uživatelé se k němu připojují a spouštějí úlohy. Úlohy a datové streamy se tady spouštějí podle plánu.
Pasivní nasazení (někdy označované jako studené nasazení): Tady neběží žádné procesy. IT týmy ji udržují připravenou automatizací nasazení kódu, konfigurace a dalších objektů Azure Databricks do něj. Pasivní nasazení se aktivuje jenom v případech, kdy aktivní nasazení přestane fungovat.

Důležité

Projekt může zahrnovat několik pasivních nasazení v různých oblastech, aby se zajistila další odolnost.

Většina týmů spouští současně jedno aktivní nasazení, strategii aktivní-pasivní . Méně běžná strategie aktivní-aktivní využívá dvě současně aktivní nasazení.

Terminologie odvětví zotavení po havárii

Definujte tyto dva oborové termíny s týmem:

Cíl bodu obnovení (RPO): Maximální doba ztráty dat, která vaše služba může tolerovat během závažného incidentu. Viz RPO.

Azure Databricks neukládá vaše primární zákaznická data. To se nachází v ADLS (pro pracovní prostory vytvořené před 6. březnem 2023, Azure Blob Storage) nebo v jiných systémech, které řídíte. Řídicí rovina Azure Databricks ukládá některé objekty (například úlohy a poznámkové bloky), takže RPO Azure Databricks představuje maximální dobu, za kterou může dojít ke ztrátě změn těchto objektů. Zodpovídáte za definování hodnoty RPO pro vaše zákaznická data v ADLS (pro pracovní prostory vytvořené před 6. březnem 2023 v Azure Blob Storage) a v dalších zdrojích dat, které spravujete.
Cíl doby obnovení (RTO):: Maximální doba, po které se musí obchodní proces obnovit po havárii. Viz RTO.

Zotavení po havárii a poškození dat

Řešení zotavení po havárii nezmírní poškození dat. Poškozená data v primární oblasti se replikují do sekundární oblasti a jsou poškozena v obou oblastech. Chcete-li omezit dopady tohoto typu selhání, použijte nástroj Delta time travel, podobné nástroje nebo nástroje pro zálohování dat.

Typický pracovní postup obnovení

Scénář obnovení po havárii v Azure Databricks obvykle probíhá následovně:

V primárním regionu dojde k selhání kritické služby: zdroje dat, sítě nebo jiné závislosti, na které nasazení Azure Databricks spoléhá.
Prověříte to u svého poskytovatele cloudu.
Pokud je čekání nepřijatelné, rozhodnete se přepnout na sekundární region.
Ověřte, že stejný problém nemá vliv na vaši sekundární oblast.
Převzetí služeb při selhání (podrobný postup najdete v tématu Testovací převzetí služeb při selhání):
1. Zastavte veškerou aktivitu v pracovním prostoru. Pokud je to možné, uživatelé zastavují úlohy a zálohují nedávné změny. Úlohy se ukončí (pokud už dříve neselhaly kvůli výpadku).
2. Spusťte postup obnovení sekundární oblasti, aby se aktualizovalo směrování a přesměrovala připojení a síťový provoz.
3. Nasměrujte podřízené systémy (nástroje BI, plánovače, integrace třetích stran) do sekundárního pracovního prostoru a obnovte jejich připojení.
4. Po testování prohlaste sekundární oblast za provozní. Uživatelé se přihlašují k aktuálně aktivnímu nasazení a vy znovu nasazujete naplánované nebo zpožděné úlohy.
Jakmile je problém v primárním regionu zmírněn, potvrďte, že oprava funguje.
Navrácení služeb po obnovení (podrobnosti najdete v části Testovací obnovení (navrácení služeb po obnovení)):
1. Zastavte veškerou práci v sekundární oblasti.
2. Spusťte postup obnovení primárního regionu a přesměrujte směrování zpět.
3. Replikujte všechna nová data zpět do primární oblasti. Minimalizujte, co je potřeba replikovat. Například úlohy jen pro čtení, které běžely v sekundárním nasazení, nemusí vyžadovat zpětný zápis.
4. Otestujte nasazení v primární oblasti.
5. Deklarujte aktivní primární oblast a obnovte produkční úlohy.

Důležité

Během těchto kroků může dojít ke ztrátě dat. Definujte, kolik ztrát je pro vaši organizaci přijatelné a jak ji zmírníte.

Krok 1: Vysvětlení obchodních potřeb

Určete, které datové služby jsou kritické, a definujte jejich cílové hodnoty RPO a RTO. Prozkoumání reálné tolerance každého systému.

DR, převzetí služeb při selhání a navrácení služeb po obnovení nesou skutečné náklady a rizika, včetně poškození dat, duplikace dat (zápisu do nesprávného umístění úložiště) a situací, kdy uživatelé provádějí změny v nesprávném regionu.

Namapujte každý Azure Databricks integrační bod, který ovlivňuje vaši firmu, a zvolte nástroje a komunikační kanály, které váš plán používá.

Body integrace k mapování

Potřebuje vaše řešení zotavení po havárii pojmout interaktivní procesy, automatizované procesy nebo obojí?
Které datové služby používáte? Některé mohou být lokálně.
Jak se vstupní data dostanou do cloudu?
Kdo tato data využívá? Jaké procesy ho využívají v podřízené fázi?
Existují integrace třetích stran, které musí zohlednit změny v DR?

Nástroje a komunikace pro plánování

Můžete si konfiguraci předem definovat a navrhnout ji modulárně tak, aby přirozeným a snadno udržovatelným způsobem podporovala řešení DR?
Které komunikační nástroje a kanály informují interní týmy a třetí strany (integrace, podřízení příjemci) o převzetí služeb při selhání zotavení po havárii a o změnách navrácení služeb po obnovení? Jak potvrdíte jejich potvrzení?
Jaké služby, pokud nějaké nějaké, vypnete, dokud se nedokončí obnovení?

Krok 2: Volba procesu, který vyhovuje vašim obchodním potřebám

Ve výchozím nastavení používejte spravované zotavení po havárii. Zpracovává replikaci pracovního prostoru, metadata katalogu Unity, data spravovaných tabulek a orchestraci převzetí služeb při selhání bez vlastních skriptů. Níže uvedené pokyny DIY použijte pouze v případě, že nespadáte do jejich rozsahu, například pokud jde o prostředky, které spravované DR nereplikuje, aktivně-aktivní topologie, replikaci mezi cloudy nebo podrobnou kontrolu nad procesem replikace.

Řešení DIY musí replikovat správná data napříč řídicí rovinou, výpočetní rovinou a zdroji dat. Redundantní pracovní prostory se mapují na různé řídicí roviny v různých oblastech, takže je udržujete v synchronizaci se skriptovým řešením, a to buď synchronizačním nástrojem, nebo pracovním postupem CI/CD. U samotných dat používá většina týmů Azure Databricks úlohy (často naplánované) nebo Delta Deep Clone ke kopírování tabulek mezi oblastmi. Nemusíte synchronizovat data z výpočetní roviny (například z pracovních procesů Databricks Runtime).

Pokud používáte funkci injektáže virtuální sítě (není k dispozici se všemi typy předplatného a nasazení), nasaďte sítě konzistentně v obou oblastech pomocí nástrojů založených na šablonách, jako je Terraform.

Podle potřeby replikujte zdroje dat mezi oblastmi.

Řešení DR obvykle zahrnují dva (nebo více) pracovní prostory. Zvolte jednu z následujících strategií podle délky výpadku, kterou můžete tolerovat, potřebného provozního úsilí a nákladů na návrat do primárního regionu po obnovení provozu.

Obecné osvědčené postupy

Mezi obecné osvědčené postupy pro úspěšný plán zotavení po havárii patří:

Určete, které procesy jsou pro podnik kritické a které musí běžet v režimu zotavení po havárii.
Jasně určete, které služby jsou zapojeny, které data se zpracovávají, jaké jsou toky dat a kde jsou uloženy.
Co nejvíce izolujte služby a data. Můžete například vytvořit speciální kontejner cloudového úložiště pro data zotavení po havárii nebo přesunout objekty Azure Databricks potřebné během havárie do samostatného pracovního prostoru.
Zodpovídáte za zachování integrity mezi primárním a sekundárním nasazením objektů, které nejsou uloženy v řídicí rovině Azure Databricks.
Pro zdroje dat použijte nativní nástroje Azure k replikaci dat do oblastí zotavení po havárii, pokud je to možné.

Upozornění

Neukládejte data v kořenové službě ADLS (pro pracovní prostory vytvořené před 6. březnem 2023, Azure Blob Storage) používaný pro kořenový přístup DBFS. Kořenové úložiště DBFS není podporováno pro produkční zákaznická data. Azure Databricks také nedoporučuje ukládat tam knihovny, konfigurační soubory ani inicializační skripty.

Strategie řešení aktivní-pasivní

Tato část se zaměřuje na strategii aktivní-pasivní, protože je nejběžnější, nejjednodušší a nákladově nejefektivnější. Aktivní-pasivní řešení synchronizuje změny dat a objektů z aktivního nasazení do pasivního nasazení v sekundární oblasti. Během události obnovy po havárii se pasivní nasazení stane aktivním.

Dvě běžné varianty:

Jednotná (celopodniková): Jedna sada aktivních a pasivních nasazení podporuje celou organizaci.
Podle oddělení nebo projektu: Každá doména udržuje vlastní řešení zotavení po havárii s primárními a sekundárními oblastmi přizpůsobenými svým potřebám.

Můžete také použít pasivní nasazení pro úlohy jen pro čtení, jako jsou dotazy uživatelů, které neupravují data nebo Azure Databricks objekty.

Strategie řešení aktivní-aktivní

V aktivně-aktivním řešení běží všechny datové procesy paralelně v obou oblastech po celou dobu. Váš provozní tým musí označit každou úlohu dokončenou až po úspěšném dokončení v obou oblastech. Objekty nelze v produkčním prostředí měnit a musí se řídit striktním CI/CD postupem nasazování z vývojového/testovacího prostředí do produkce.

Strategie aktivní-aktivní je nejsložitější strategií a je nákladnější, protože úlohy běží v obou regionech, ale nabízí nejnižší hodnoty RTO a RPO.

Řešení active-active můžete implementovat v rámci celé organizace nebo podle oddělení. Pro každou úlohu nepotřebujete duplicitní pracovní prostor. Například vývojová nebo testovací pracovní prostředí je často snazší znovu vytvořit z vývojového pipeline, než je udržovat synchronizovaná.

Volba nástrojů

Existují dva hlavní přístupy pro synchronizaci dat mezi pracovními prostory v primární a sekundární oblasti:

Synchronizační klient, který kopíruje z primární do sekundární: Synchronizační klient odesílá produkční data a prostředky z primární oblasti do sekundární oblasti. Obvykle se to spouští podle plánu a frekvence spouštění závisí na cílové době obnovení (RTO) a cílovém bodu obnovení (RPO).
Nástroje CI/CD pro paralelní nasazení: Pro produkční kód a prostředky použijte nástroje CI/CD, které současně do obou oblastí odesílají změny do produkčních systémů. Když například nasdílíte kód a prostředky z přípravného/vývojového prostředí do produkčního prostředí, systém CI/CD ho zpřístupní současně v obou oblastech. Základní myšlenkou je zacházet se všemi artefakty v pracovním prostoru Azure Databricks jako s infrastrukturou jako kódem. Většina artefaktů může být společně nasazena do primárních i sekundárních pracovních prostorů, zatímco některé artefakty je možná potřeba nasadit až po události zotavení po havárii. Nástroje najdete v tématu Automatizační skripty, ukázky a prototypy.

V závislosti na vašich potřebách můžete tyto přístupy kombinovat. Použijte například CI/CD pro zdrojový kód poznámkového bloku, ale použijte synchronizaci pro konfiguraci, jako jsou fondy a řízení přístupu.

Následující tabulka popisuje, jak zpracovávat jednotlivé typy dat s jednotlivými možnostmi nástrojů.

Popis	Jak pracovat s nástroji CI/CD	Zpracování pomocí synchronizačního nástroje
Zdrojový kód: export zdrojového kódu poznámkového bloku a zdrojový kód pro balíčkované knihovny	Společně nasadit na primární i sekundární.	Synchronizujte zdrojový kód z primárního do sekundárního.
Uživatelé a skupiny	Správa metadat jako konfigurace v Gitu Případně pro oba pracovní prostory použijte stejného zprostředkovatele identity (IdP). Spolusaďte data uživatelů a skupin do primárního a sekundárního nasazení.	Pro obě oblasti použijte SCIM nebo jinou automatizaci. Ruční vytvoření se nedoporučuje, ale pokud se používá, musí být prováděno současně pro oba. Pokud použijete ruční nastavení, vytvořte naplánovaný automatizovaný proces pro porovnání seznamu uživatelů a skupin mezi dvěma nasazeními.
Konfigurace fondů	Může to být šablony v Gitu. Společně nasaďte do primárního a sekundárního prostředí. `min_idle_instances` však musí být v sekundárním prostředí nulové až do události DR.	Fondy vytvořené s libovolnou `min_idle_instances`, když jsou synchronizovány do sekundárního pracovního prostoru pomocí rozhraní API nebo příkazového řádku.
Konfigurace úloh	K nasazení stejné definice úlohy do obou oblastí použijte sady prostředků Databricks s cíli pro jednotlivá prostředí (například `prod` a `dr`). U sekundárního nasazení nastavte souběžnost na nulu, aby úloha byla fázovaná, ale nespustí se. Po aktivním sekundárním nasazení změňte hodnotu souběžnosti.	Pokud se úlohy spouštějí z nějakého důvodu na existujících `<interactive>` clusterech, musí se synchronizační klient namapovat na odpovídající `cluster_id` v sekundárním pracovním prostoru.
Seznamy pro řízení přístupu (ACL)	Může to být šablony v Gitu. Nasazujte současně do primárního a sekundárního nasazení pro poznámkové bloky, složky a clustery. Data úloh však ponechte do události DR.	Rozhraní API pro oprávnění může nastavit řízení přístupu pro clustery, úlohy, fondy, poznámkové bloky a složky. Synchronizační klient musí přiřadit odpovídající ID objektů ke každému objektu v sekundárním pracovním prostoru. Databricks doporučuje vytvořit mapu ID objektů z primárního do sekundárního pracovního prostoru při synchronizaci těchto objektů před replikací řízení přístupu.
Knihovny	Zahrňte zdrojový kód a šablony úloh nebo clusteru.	Synchronizovat vlastní knihovny z centralizovaných úložišť, DBFS nebo cloudového úložiště (je možné je připojit).
Inicializační skripty clusteru	Pokud chcete, zahrňte do zdrojového kódu.	Pro jednodušší synchronizaci uložte inicializační skripty v primárním pracovním prostoru do společné složky nebo do malé sady složek, pokud je to možné.
Přípojné body	Zahrnout do zdrojového kódu, pokud se vytváří pouze prostřednictvím úloh založených na poznámkových blocích nebo příkazového rozhraní API.	Použijte úlohy, které je možné spustit jako aktivity služby Azure Data Factory (ADF). Mějte na paměti, že koncové body úložiště se můžou změnit vzhledem k tomu, že pracovní prostory budou v různých oblastech. To také hodně závisí na vaší strategii obnovy dat po havárii.
Metadata tabulky	Pro objekty služby Unity Catalog (katalogy, schémata, tabulky, volumes a oprávnění) nasazujte společně s providerem Databricks Terraform nebo Databricks Asset Bundles. U starších tabulek metastoru Hive zahrňte příkazy create-table se zdrojovým kódem, pokud se vytvářejí prostřednictvím úloh založených na poznámkových blocích nebo rozhraní API příkazů.	U objektů katalogu Unity načtěte zdrojová metadata ze systémových tabulek nebo `information_schema` a replikujte je do sekundárního pracovního prostoru pomocí Databricks SDK. U starších tabulek v úložišti metadat Hive porovnejte definice metadat mezi úložišti metadat pomocí rozhraní Spark Catalog API nebo `SHOW CREATE TABLE` v notebooku či skriptech. Podkladové cesty úložiště mohou být závislé na regionu a mohou se mezi instancemi metastore lišit.
Tajné kódy	Zahrnout do zdrojového kódu, pokud byl vytvořen pouze prostřednictvím příkazového rozhraní API. Všimněte si, že mezi primárním a sekundárním obsahem může být potřeba změnit obsah tajných kódů.	Tajné kódy se vytvářejí v obou pracovních prostorech prostřednictvím rozhraní API. Všimněte si, že mezi primárním a sekundárním obsahem může být potřeba změnit obsah tajných kódů.
Konfigurace clusterů	Může to být šablony v Gitu. Nasaďte současně do primárního i sekundárního prostředí, ačkoli instance v sekundárním prostředí by měly zůstat ukončené až do události zotavení po havárii (DR).	Clustery se vytvoří po jejich synchronizaci do sekundárního pracovního prostoru pomocí rozhraní API nebo rozhraní příkazového řádku. Pokud chcete, můžete je explicitně ukončit v závislosti na nastavení automatického ukončení.
Oprávnění k poznámkovému bloku, úloze a složce	Může to být šablony v Gitu. Společně nasadit na primární a sekundární nasazení.	Replikovat pomocí rozhraní API Oprávnění.

Volba oblastí a více sekundárních pracovních prostorů

Řídíte, kdy se DR spustí a do které sekundární oblasti při selhání přepnete. Jste také odpovědní za stabilizaci prostředí DR před obnovením běžného provozu. To obvykle znamená vytvoření několika pracovních prostorů Azure Databricks pro produkční prostředí a zotavení po havárii a výběr sekundární oblasti pro převzetí služeb při selhání.

Než vyberete sekundární oblast, ověřte, že jsou v ní dostupné všechny prostředky a služby, na které závisíte (typy výpočetních prostředků, produkty, integrace). Některé Azure Databricks služby jsou dostupné jenom v konkrétních oblastech.

Zkontrolujte také dostupnost replikace dat a typu virtuálního počítače.

Krok 3: Příprava pracovních prostorů a jednorázové kopírování

Nejprve vytvořte sekundární pracovní prostor Azure Databricks (nebo pracovní prostory) a k němu přidružený metastore ve zvoleném sekundárním regionu. Sekundární pracovní prostor musí před replikací dat nebo prostředků zrcadlit konfiguraci primárního účtu, oblasti a identity.

Pokud používáte spravovanou obnovu po havárii, Azure Databricks při vytvoření skupiny pro převzetí služeb při selhání provede počáteční inicializaci relevantních katalogů a prostředků pracovního prostoru. Pro tyto zdroje nemusíte provádět jednorázové kopírování. Pokračujte zbývající částí tohoto oddílu u všech zdrojů dat nebo prostředků, které spravované DR nereplikuje.

U produkčního pracovního prostoru, který je mimo rozsah spravovaného zotavení po havárii, proveďte jednorázové kopírování k synchronizaci pasivního nasazení s aktivním nasazením. Tato kopie zpracovává:

Replikace dat: Použijte cloudové řešení replikace nebo Delta Deep Clone.
Generování tokenů: Automatizujte replikaci a budoucí úlohy s vygenerovanými tokeny.
Replikace pracovního prostoru: Replikace pomocí metod v kroku 4: Příprava zdrojů dat Podrobné pokyny k exportu konfigurace, dat a prostředků AI/ML pracovního prostoru najdete v tématu Export dat pracovního prostoru.
Ověření pracovního prostoru: Otestujte pracovní prostor a proces, abyste ověřili, že se úspěšně spustil, a vytvořte očekávané výsledky.

Následné synchronizace běží rychleji než počáteční kopie a protokoly nástrojů zaznamenávají, co se změnilo a kdy.

Krok 4: Příprava zdrojů dat

Azure Databricks může zpracovávat velké množství zdrojů dat pomocí dávkového zpracování nebo datových proudů.

Dávkové zpracování ze zdrojů dat

Dávková data se obvykle nacházejí ve zdroji, který můžete replikovat nebo dodávat do jiné oblasti.

Například data se často nahrávají do cloudového úložiště podle plánu. V režimu obnovy po havárii nasměrujte tato odesílání do úložiště v sekundární oblasti a aktualizujte pracovní zátěže tak, aby z tohoto úložiště četly a zapisovaly do něj.

Datové proudy

Datové streamy

Zpracování datového proudu je větší výzvou. Streamovaná data se můžou ingestovat z různých zdrojů, zpracovávat a odesílat do řešení streamování:

Fronta zpráv, jako je Kafka
Stream zachytávání dat změn databáze
Průběžné zpracování založené na souborech
Naplánované zpracování založené na souborech, označované také jako aktivace jednou

Ve všech těchto případech musíte zdroje dat nakonfigurovat tak, aby zpracovávaly režim zotavení po havárii a používaly sekundární nasazení v sekundární oblasti.

Zapisovač streamu ukládá kontrolní bod s informacemi o zpracovaných datech. Tento kontrolní bod může obsahovat umístění dat (obvykle cloudové úložiště), které je potřeba upravit na nové místo, aby se zajistilo úspěšné restartování datového proudu. Podsložka pod kontrolním bodem může například source ukládat cloudovou složku založenou na souborech.

Tento kontrolní bod se musí včas replikovat. Zvažte synchronizaci intervalu kontrolního bodu s jakýmkoli novým řešením cloudové replikace.

Aktualizace kontrolního bodu je funkcí zapisovače, a proto se vztahuje na přijímání, zpracování datových proudů a ukládání do jiného zdroje streamování.

U úloh streamování se ujistěte, že jsou kontrolní body nakonfigurované v úložišti spravovaném zákazníkem, aby se mohly replikovat do sekundární oblasti pro obnovení úloh z bodu posledního selhání. Můžete se také rozhodnout spustit sekundární proces streamování paralelně s primárním procesem.

Krok 5: Implementace a testování řešení

Pokud používáte spravované zotavení po havárii, můžete v konzoli účtu spustit plánované převzetí služeb při selhání a ověřit, že vaše nastavení funguje od začátku do konce. Stejný postup zahrnuje testy zotavení po havárii i skutečné výpadky. Viz Převzetí služeb při selhání a navrácení služeb po obnovení.

Pravidelně testujte své nastavení disaster recovery. Neotestovaný plán zotavení po havárii často selže, když ho potřebujete. Některé týmy podle stanoveného harmonogramu každých několik měsíců střídají aktivní regiony, aby ověřily předpoklady, procvičily procesy a udržovaly tým obeznámený s provozní příručkou.

Důležité

Pravidelně testujte své řešení obnovy po havárii v reálných podmínkách.

Pokud test odhalí chybějící objekt nebo šablonu, aktualizujte plán: odeberte závislost, replikujte ho do sekundárního pracovního prostoru nebo ho zpřístupněte jiným způsobem.

Otestujte také změny organizace a konfigurace. Váš plán zotavení po havárii má vliv na váš kanál nasazení, takže tým musí vědět, co se má synchronizovat. Po nastavení pracovních prostorů zotavení po havárii ověřte, že vaše infrastruktura, úlohy, poznámkové bloky, knihovny a další objekty pracovního prostoru jsou dostupné v sekundární oblasti.

Rozšiřte standardní pracovní procesy a kanály konfigurace a nasaďte změny do všech pracovních prostorů. Správa identit uživatelů napříč pracovními prostory a konfigurace automatizace a monitorování úloh pro nové pracovní prostory

Naplánujte a otestujte změny konfiguračních nástrojů.

Změny konfigurace pro plánování a testování

Pro každou z následujících možností připravte plán pro převzetí služeb při selhání a otestujte všechny předpoklady:

Příjem dat: Zjistěte, kde jsou zdroje dat a kde tyto zdroje získávají data. Pokud je to možné, parametrizujte zdroj a použijte samostatnou šablonu konfigurace pro sekundární nasazení a oblast.
Změny provádění: Pokud máte plánovač pro aktivaci úloh nebo jiných akcí, možná budete potřebovat samostatný plánovač, který funguje se sekundárním nasazením nebo jeho zdroji dat.
Interaktivní připojení: Zvažte, jak může mít konfigurace, ověřování a síťová připojení vliv na regionální přerušení pro jakékoli použití rozhraní REST API, nástrojů rozhraní příkazového řádku nebo jiných služeb, jako je JDBC/ODBC.
Změny automatizace: Pro všechny automatizační nástroje.
Výstupy: Pro všechny nástroje, které generují výstupní data nebo protokoly.
Podřízené změny: U nástrojů BI, řídicích panelů, plánovačů a integrací třetích stran, které čtou nebo zapisují do Azure Databricks, naplánujte, jak je znovu nasměrovat v sekundárním pracovním prostoru a oznámit jejich vlastníkům.

Otestovat převzetí služeb při selhání

Testovací převzetí služeb při selhání

Mnoho scénářů může spustit DR: neočekávaný výpadek cloudové sítě, cloudového úložiště nebo jiné klíčové služby, kdy nelze systém korektně odstavit; plánované odstavení nebo výpadek; nebo dokonce pravidelné přepínání mezi regiony v rámci testovacího cyklu.

Chcete-li otestovat přepnutí při selhání, připojte se k systému a proveďte vypnutí. Potvrďte, že jsou všechny úlohy dokončené a clustery ukončeny.

Synchronizační klient (nebo nástroje CI/CD) replikuje relevantní Azure Databricks objekty a prostředky do sekundárního pracovního prostoru. Pokud chcete aktivovat sekundární pracovní prostor, může váš proces obsahovat některé nebo všechny následující položky:

Spuštěním testů ověřte, že je platforma aktuální.
Zakažte fondy a clustery v primární oblasti tak, aby pokud se selhalá služba znovu objeví online, primární oblast nezahajuje zpracování nových dat.
Spusťte proces obnovení pro vaše zdroje dat (viz níže).
Zahajte příslušné pooly (nebo upravte hodnotu min_idle_instances na příslušné číslo).
Spusťte relevantní clustery (pokud nejsou ukončeny).
Upravte režim souběžného spuštění úloh a proveďte konkrétní úlohy. Může se jednat o jednorázové procesy nebo periodické procesy.
Pro jakýkoli vnější nástroj, který používá adresu URL nebo název domény pro váš pracovní prostor Azure Databricks, aktualizujte konfigurace tak, aby zohlednily novou řídicí rovinu. Například aktualizujte adresy URL pro rozhraní REST API a připojení JDBC/ODBC. Adresa URL webové aplikace Azure Databricks zobrazená zákazníkem se změní, když se řídicí rovina změní, takže uživatelům vaší organizace upozorněte na novou adresu URL.

Podrobnosti o procesu obnovení

Zkontrolujte datum nejnovějších synchronizovaných dat. Viz terminologie odvětví zotavení po havárii. Podrobnosti tohoto kroku se liší v závislosti na způsobu synchronizace dat a vašich jedinečných obchodních potřeb.
Stabilizujte zdroje dat a ujistěte se, že jsou všechny dostupné. Zahrňte všechny externí zdroje dat, například Azure Cloud SQL, Delta Lake, Parquet nebo jiné soubory.
Vyhledejte bod obnovení streamování. Nastavte proces, který se má odsud restartovat, a připravte se na identifikaci a odstranění potenciálních duplicit (Delta Lake to usnadňuje).
Dokončete proces toku dat a informujte uživatele.

Test obnovení (zpětné přepnutí)

Testovací obnovení (návrat zpět po selhání)

Návrat je snazší kontrolovat a lze ho provést v údržbovém okně. Naplánujte některé nebo všechny následující kroky:

Obdržte potvrzení, že byla obnovena primární oblast.
Vypněte fondy a clustery v sekundární oblasti, aby nezačaly zpracovávat nová data.
Synchronizujte všechny nové nebo upravené prostředky v sekundárním pracovním prostoru zpět s primárním nasazením. V závislosti na návrhu vašich skriptů pro převzetí služeb při selhání můžete být schopni spustit stejné skripty pro synchronizaci objektů ze sekundární oblasti (DR) do primární produkční oblasti.
Synchronizujte všechny nové aktualizace dat zpět do primárního nasazení. Záznamy auditu protokolů a tabulek Delta můžete použít k zajištění žádné ztráty dat.
Vypněte všechny pracovní zátěže v regionu pro zotavení po havárii.
Změňte adresy URL úloh a uživatelů na primární oblast a znovu na něj nasměrujte podřízená připojení (nástroje BI, plánovače, integrace třetích stran).
Spuštěním testů ověřte, že je platforma aktuální.
Zahajte příslušné pooly (nebo upravte hodnotu min_idle_instances na příslušné číslo).
Spusťte relevantní clustery (pokud nejsou ukončeny).
Změňte souběžné spuštění úloh a spusťte relevantní úlohy. Může se jednat o jednorázové procesy nebo periodické procesy.
Podle potřeby znovu nastavte sekundární oblast pro budoucí zotavení po havárii.

Automatizační skripty, ukázky a prototypy

U AWS a Azure spravované zotavení po havárii zpracovává replikaci pracovních prostorů a spravovaných tabulek bez vlastní automatizace. Níže uvedené odkazy platí pouze tehdy, pokud vytváříte vlastní řešení mimo rámec spravovaného zotavení po havárii.

Pro vlastní kanály DR použijte provider Databricks Terraform ke správě prostředků pracovního prostoru formou kódu a k současnému nasazení do primárních i sekundárních regionů.

Pokud orchestrujete Azure Databricks z Azure Data Factory, replikujte relevantní kanály ADF tak, aby odkazovaly na propojenou službu mapovanou na sekundární pracovní prostor.

Další materiály

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-06-24