Pokyny pro zotavení po havárii specifické pro konkrétní prostředí

Tento dokument obsahuje pokyny specifické pro konkrétní prostředí pro obnovení dat prostředků infrastruktury v případě regionální havárie.

Ukázkový scénář

Řada částí s pokyny v tomto dokumentu používá následující ukázkový scénář pro účely vysvětlení a ilustrace. Podle potřeby se vraťte k tomuto scénáři.

Řekněme, že máte kapacitu C1 v oblasti A, která má pracovní prostor W1. Pokud jste pro kapacitu C1 zapnuli zotavení po havárii, data OneLake se budou replikovat do zálohy v oblasti B. Pokud oblast A čelí přerušení, služba Fabric v C1 převezme služby při selhání do oblasti B.

Tento scénář znázorňuje následující obrázek. V poli vlevo se zobrazí přerušená oblast. Pole uprostřed představuje nepřetržitou dostupnost dat po převzetí služeb při selhání a pole na pravé straně ukazuje plně pokrytou situaci poté, co zákazník jedná o obnovení služeb do plné funkce.

Tady je obecný plán obnovení:

1. Vytvořte novou kapacitu Infrastruktury C2 v nové oblasti.

2. Vytvořte nový pracovní prostor W2 v jazyce C2, včetně odpovídajících položek se stejnými názvy jako v C1. W1.

3. Zkopírujte data z přerušeného C1. W1 až C2. W2.

4. Postupujte podle vyhrazených pokynů pro každou komponentu a obnovte položky do své úplné funkce.

Plány obnovení specifické pro konkrétní prostředí

Následující části obsahují podrobné pokyny pro každé prostředí infrastruktury, které zákazníkům pomůžou procesem obnovení.

Příprava dat

Tato příručka vás provede postupy obnovení pro Datoví technici prostředí. Zahrnuje definice úloh Lakehouse, poznámkových bloků a úloh Sparku.

Jezero

Lakehouses z původní oblasti zůstávají zákazníkům nedostupné. Pokud chcete obnovit lakehouse, zákazníci ho můžou znovu vytvořit v pracovním prostoru C2. W2. Pro obnovení jezera doporučujeme dva přístupy:

Přístup 1: Kopírování tabulek a souborů Lakehouse Delta pomocí vlastního skriptu

Zákazníci můžou znovu vytvořit jezera pomocí vlastního skriptu Scala.

1. V nově vytvořeném pracovním prostoru C2 vytvořte lakehouse (například LH1). W2.

2. Vytvořte nový poznámkový blok v pracovním prostoru C2. W2.

3. Pokud chcete obnovit tabulky a soubory z původního jezera, musíte pro přístup k datům použít cestu ABFS (viz Připojení pro Microsoft OneLake). Následující příklad kódu (viz Úvod do nástrojů Microsoft Sparku) v poznámkovém bloku můžete použít k získání cest souborů a tabulek ABFS z původního jezerahouse. (Nahraďte C1. W1 se skutečným názvem pracovního prostoru)

   mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Pomocí následujícího příkladu kódu zkopírujte tabulky a soubory do nově vytvořeného jezerahouse.

   1. U tabulek Delta je potřeba tabulku zkopírovat po jednom, aby se obnovila v novém jezeře. V případě souborů Lakehouse můžete zkopírovat kompletní strukturu souborů se všemi podkladovými složkami s jediným spuštěním.

   2. Spojte se s týmem podpory pro časové razítko převzetí služeb při selhání vyžadované ve skriptu.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Po spuštění skriptu se tabulky zobrazí v novém jezeře.

Přístup 2: Kopírování souborů a tabulek pomocí Průzkumník služby Azure Storage

Pokud chcete obnovit pouze konkrétní soubory nebo tabulky Lakehouse z původního jezera, použijte Průzkumník služby Azure Storage. Podrobné kroky najdete v tématu Integrace OneLake s Průzkumník služby Azure Storage. V případě velkých objemů dat použijte přístup 1.

Poznámka:

Dva přístupy popsané výše obnoví metadata i data tabulek ve formátu Delta, protože metadata jsou společně umístěna a uložena s daty v OneLake. U neformátovaných tabulek (e.g. CSV, Parquet atd.), které se vytvářejí pomocí skriptů/příkazů jazyka DDL (Spark Data Definition Language), je uživatel zodpovědný za údržbu a opětovné spuštění skriptů a příkazů Spark DDL, aby je obnovil.

Poznámkový blok

Poznámkové bloky z primární oblasti zůstanou pro zákazníky nedostupné a kód v poznámkových blocích se nereplikuje do sekundární oblasti. Pokud chcete obnovit kód poznámkového bloku v nové oblasti, existují dva přístupy k obnovení obsahu kódu poznámkového bloku.

Přístup 1: Redundance spravovaná uživatelem s integrací Gitu (ve verzi Public Preview)

Nejlepším způsobem, jak to snadno a rychle udělat, je použít integraci Infrastruktury Git a pak synchronizovat poznámkový blok s úložištěm ADO. Po převzetí služeb při selhání do jiné oblasti můžete úložiště použít k opětovnému sestavení poznámkového bloku v novém pracovním prostoru, který jste vytvořili.

1. Nastavte integraci Gitu a vyberte Připojení a synchronizujte s úložištěm ADO.

   

   Následující obrázek znázorňuje synchronizovaný poznámkový blok.

   

2. Obnovte poznámkový blok z úložiště ADO.

   1. V nově vytvořeném pracovním prostoru se znovu připojte k úložišti Azure ADO.

      

   2. Vyberte tlačítko Správy zdrojového kódu. Pak vyberte příslušnou větev úložiště. Pak vyberte Aktualizovat vše. Zobrazí se původní poznámkový blok.

      

      

   3. Pokud má původní poznámkový blok výchozí jezerní dům, můžou uživatelé odkazovat na oddíl Lakehouse a obnovit jezero a pak nově obnovený lakehouse připojit k nově obnoveném poznámkovému bloku.

      

   4. Integrace Gitu nepodporuje synchronizaci souborů, složek nebo snímků poznámkových bloků v Průzkumníku prostředků poznámkového bloku.

      1. Pokud má původní poznámkový blok soubory v Průzkumníku prostředků poznámkového bloku:

         1. Nezapomeňte uložit soubory nebo složky na místní disk nebo na jiné místo.

         2. Znovu nahrajte soubor z místního disku nebo z cloudových jednotek do obnoveného poznámkového bloku.

      2. Pokud má původní poznámkový blok snímek poznámkového bloku, uložte ho také do vlastního systému správy verzí nebo místního disku.

         

         

Další informace o integraci Gitu najdete v tématu Úvod do integrace Gitu.

Přístup 2: Ruční přístup k zálohování obsahu kódu

Pokud nepoužíváte přístup k integraci Gitu, můžete uložit nejnovější verzi kódu, soubory v Průzkumníku prostředků a snímek poznámkového bloku do systému správy verzí, jako je Git, a po havárii ručně obnovit obsah poznámkového bloku:

1. Pomocí funkce Importovat poznámkový blok naimportujte kód poznámkového bloku, který chcete obnovit.

   

2. Po importu přejděte do požadovaného pracovního prostoru (například C2. W2") pro přístup k němu.

3. Pokud má původní poznámkový blok výchozí jezero, přečtěte si část Lakehouse. Pak připojte nově obnovený lakehouse (který má stejný obsah jako původní výchozí jezero) k nově obnoveném poznámkovému bloku.

4. Pokud má původní poznámkový blok soubory nebo složky v Průzkumníku prostředků, znovu nahrajte soubory nebo složky uložené v systému správy verzí uživatele.

Definice úlohy Sparku

Definice úloh Sparku (SJD) z primární oblasti zůstávají pro zákazníky nedostupné a hlavní definiční soubor a referenční soubor v poznámkovém bloku se replikují do sekundární oblasti prostřednictvím OneLake. Pokud chcete obnovit SJD v nové oblasti, můžete provést ruční kroky popsané níže a obnovit SJD. Mějte na paměti, že historická spuštění SJD se neobnoví.

Položky SJD můžete obnovit zkopírováním kódu z původní oblasti pomocí Průzkumník služby Azure Storage a ručním opětovným připojením odkazů Lakehouse po havárii.

1. V novém pracovním prostoru C2 vytvořte novou položku SJD (například SJD1). W2 se stejnými nastaveními a konfiguracemi jako původní položka SJD (například jazyk, prostředí atd.).

2. Pomocí Průzkumník služby Azure Storage zkopírujte knihovny, hlavní položky a snímky z původní položky SJD do nové položky SJD.

   

3. Obsah kódu se zobrazí v nově vytvořené SJD. K úloze budete muset ručně přidat nově obnovený odkaz na Lakehouse (viz kroky obnovení Lakehouse). Uživatelé budou muset znovu zadat původní argumenty příkazového řádku ručně.

   

Teď můžete spustit nebo naplánovat nově obnovenou SJD.

Podrobnosti o Průzkumník služby Azure Storage najdete v tématu Integrace OneLake s Průzkumník služby Azure Storage.

Datové vědy

Tato příručka vás provede postupy obnovení pro Datová Věda prostředí. Zahrnuje modely ML a experimenty.

Model a experiment ML

Datová Věda položky z primární oblasti zůstanou pro zákazníky nedostupné a obsah a metadata v modelech ML a experimenty se nebudou replikovat do sekundární oblasti. Pokud je chcete plně obnovit v nové oblasti, uložte obsah kódu do systému správy verzí (například Git) a po havárii ručně znovu spusťte obsah kódu.

1. Obnovte poznámkový blok. Projděte si kroky obnovení poznámkového bloku.

2. Konfigurace, historicky spuštěné metriky a metadata se nebudou replikovat do spárované oblasti. Abyste mohli plně obnovit modely ML a experimenty po havárii, budete muset znovu spustit každou verzi kódu datové vědy.

Datový sklad

Tato příručka vás provede postupy obnovení pro prostředí datového skladu. Pokrývá sklady.

Sklad

Sklady z původní oblasti zůstanou zákazníkům nedostupné. K obnovení skladů použijte následující dva kroky.

1. Vytvořte nový dočasný jezero v pracovním prostoru C2. W2 pro data, která zkopírujete z původního skladu.

2. Naplňte tabulky Delta skladu využitím Průzkumníka skladu a možností T-SQL (viz Tabulky v datových skladech v Microsoft Fabric).

Poznámka:

Doporučujeme, abyste kód skladu (schéma, tabulku, zobrazení, uloženou proceduru, definice funkcí a kódy zabezpečení) ponechal ve verzi a uložili ho do bezpečného umístění (jako je Git) v souladu s vašimi postupy vývoje.

Příjem dat přes Lakehouse a kód T-SQL

V nově vytvořeném pracovním prostoru C2. W2:

1. Vytvořte dočasné jezero "LH2" v C2. W2.

2. Pomocí kroků obnovení Lakehouse obnovte tabulky Delta v dočasném jezeře z původního skladu.

3. V jazyce C2 vytvořte nový sklad WH2. W2.

4. Připojení dočasného jezera v průzkumníku skladu.

   

5. V závislosti na tom, jak nasadíte definice tabulek před importem dat, se skutečný T-SQL použitý pro import může lišit. K obnovení tabulek Warehouse z lakehouse můžete použít přístup INSERT INTO, SELECT INTO nebo CREATE TABLE AS SELECT. Dále bychom v tomto příkladu používali příchuť INSERT INTO. (Pokud použijete následující kód, nahraďte ukázky skutečnými názvy tabulek a sloupců.

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Nakonec změňte připojovací řetězec v aplikacích pomocí vašeho skladu Fabric.

Poznámka:

Zákazníkům, kteří potřebují zotavení po havárii mezi oblastmi a plně automatizovanou kontinuitu podnikových procesů, doporučujeme udržovat dvě nastavení služby Fabric Warehouse v samostatných oblastech Infrastruktury a udržovat paritu kódu a dat tím, že provádí pravidelné nasazení a příjem dat do obou lokalit.

Data Factory

Položky služby Data Factory z primární oblasti zůstanou pro zákazníky nedostupné a nastavení a konfigurace v datových kanálech nebo položkách toku dat Gen2 se nebudou replikovat do sekundární oblasti. Pokud chcete tyto položky obnovit v případě selhání oblasti, budete muset znovu vytvořit Integrace Dat položky v jiném pracovním prostoru z jiné oblasti. Podrobnosti najdete v následujících částech.

Toky dat Gen2

Pokud chcete obnovit položku Dataflow Gen2 v nové oblasti, musíte exportovat soubor PQT do systému správy verzí, jako je Git, a po havárii ručně obnovit obsah Toku dat Gen2.

1. V položce Toku dat Gen2 na kartě Domů v editoru Power Query vyberte Exportovat šablonu.

   

2. V dialogovém okně Exportovat šablonu zadejte název (povinné) a popis (volitelné) pro tuto šablonu. Jakmile budete hotovi, vyberte OK.

   

3. Po havárii vytvořte novou položku Toku dat Gen2 v novém pracovním prostoru C2. W2".

4. V aktuálním podokně zobrazení editoru Power Query vyberte Importovat ze šablony Power Query.

   

5. V dialogovém okně Otevřít přejděte do výchozí složky pro stahování a vyberte soubor .pqt , který jste uložili v předchozích krocích. Pak vyberte Otevřít.

6. Šablona se pak naimportuje do nové položky Toku dat Gen2.

Datové kanály

Zákazníci nemají přístup k datovým kanálům v případě regionální havárie a konfigurace se nereplikují do spárované oblasti. Doporučujeme vytvářet důležité datové kanály v několika pracovních prostorech v různých oblastech.

Inteligentní funkce v reálném čase

Tato příručka vás provede postupy obnovení pro prostředí inteligentních funkcí v reálném čase. Zabývá se databázemi a sadami dotazů a eventstreamy KQL.

Databáze nebo sada dotazů KQL

Uživatelé databáze nebo sady dotazů KQL musí provádět proaktivní opatření k ochraně před regionální katastrofou. Následující přístup zajistí, že v případě regionální havárie zůstanou data v databázích KQL bezpečná a přístupná.

Následující postup vám umožní zaručit efektivní řešení zotavení po havárii pro databáze a sady dotazů KQL.

1. Vytvoření nezávislých databází KQL: Nakonfigurujte dvě nebo více nezávislých databází KQL a sad dotazů ve vyhrazených kapacitách Fabric. Ty by se měly nastavit napříč dvěma různými oblastmi Azure (nejlépe spárovanými oblastmi Azure), aby se maximalizovala odolnost.

2. Replikace aktivit správy: Všechny akce správy provedené v jedné databázi KQL by se měly zrcadlit v druhé. Tím zajistíte, že obě databáze zůstanou synchronizované. Mezi klíčové aktivity, které se mají replikovat, patří:

   • Tabulky: Ujistěte se, že struktury tabulek a definice schématu jsou v databázích konzistentní.

   • Mapování: Duplikuje všechna požadovaná mapování. Ujistěte se, že zdroje a cíle dat odpovídají správně.

   • Zásady: Ujistěte se, že obě databáze mají podobné uchovávání dat, přístup a další relevantní zásady.

3. Správa ověřování a autorizace: Pro každou repliku nastavte požadovaná oprávnění. Ujistěte se, že jsou zavedeny správné úrovně autorizace, které poskytují přístup požadovaným pracovníkům při zachování standardů zabezpečení.

4. Paralelní příjem dat: Aby byla data konzistentní a připravená ve více oblastech, načtěte stejnou datovou sadu do každé databáze KQL současně s příjmem dat.

Eventstream

Eventstream je centralizované místo na platformě Fabric pro zachytávání, transformaci a směrování událostí v reálném čase do různých cílů (například databází nebo sad dotazů KQL) s prostředím bez kódu. Pokud jsou cíle podporovány zotavením po havárii, streamy událostí nepřijdou o data. Zákazníci by proto měli využít možnosti zotavení po havárii těchto cílových systémů k zajištění dostupnosti dat.

Zákazníci můžou také dosáhnout geografické redundance nasazením identických úloh Eventstream ve více oblastech Azure jako součást strategie aktivní/aktivní pro více lokalit. Díky přístupu s více lokalitami, který je aktivní/aktivní, můžou zákazníci přistupovat ke svým úlohám v libovolné z nasazených oblastí. Tento přístup je nejsložitější a nákladnější přístup k zotavení po havárii, ale ve většině situací může zkrátit dobu obnovení na téměř nulu. Aby zákazníci byli plně geograficky redundantní, můžou zákazníci

1. Vytvořte repliky svých zdrojů dat v různých oblastech.

2. Vytvořte položky eventstreamu v odpovídajících oblastech.

3. Připojení tyto nové položky do stejných zdrojů dat.

4. Přidejte identické cíle pro každý eventstream v různých oblastech.

Související informace

• Průvodce zotavením po havárii Microsoft Fabric