Erfarenhetsspecifik vägledning för haveriberedskap

Det här dokumentet innehåller erfarenhetsspecifik vägledning för att återställa dina Infrastrukturdata i händelse av en regional katastrof.

Exempelscenario

Ett antal vägledningsavsnitt i det här dokumentet använder följande exempelscenario för förklaringar och illustrationer. Gå tillbaka till det här scenariot efter behov.

Anta att du har en kapacitet C1 i region A som har en arbetsyta W1. Om du har aktiverat haveriberedskap för kapacitet C1 replikeras OneLake-data till en säkerhetskopia i region B. Om region A drabbas av störningar redundansväxlar infrastrukturtjänsten i C1 till region B.

Följande bild illustrerar det här scenariot. Rutan till vänster visar den störda regionen. Rutan i mitten representerar fortsatt tillgänglighet för data efter redundansväxling, och rutan till höger visar den fullständigt täckta situationen när kunden agerar för att återställa sina tjänster till full funktion.

Här är den allmänna återställningsplanen:

1. Skapa en ny infrastrukturkapacitet C2 i en ny region.

2. Skapa en ny W2-arbetsyta i C2, inklusive motsvarande objekt med samma namn som i C1. W1.

3. Kopiera data från den störda C1. W1 till C2. W2.

4. Följ de dedikerade anvisningarna för varje komponent för att återställa objekt till deras fullständiga funktion.

Erfarenhetsspecifika återställningsplaner

Följande avsnitt innehåller stegvisa guider för varje Fabric-upplevelse för att hjälpa kunder genom återställningsprocessen.

Datateknik

Den här guiden vägleder dig genom återställningsprocedurerna för Datateknik upplevelse. Den omfattar lakehouses, notebook-filer och Spark-jobbdefinitioner.

Sjöhus

Lakehouses från den ursprungliga regionen är fortfarande otillgängliga för kunder. För att återställa ett sjöhus kan kunderna återskapa det i arbetsytan C2. W2. Vi rekommenderar två metoder för att återställa sjöhus:

Metod 1: Använda anpassat skript för att kopiera Lakehouse Delta-tabeller och -filer

Kunder kan återskapa lakehouses med hjälp av ett anpassat Scala-skript.

1. Skapa lakehouse (till exempel LH1) i den nyligen skapade arbetsytan C2. W2.

2. Skapa en ny notebook-fil i arbetsytan C2. W2.

3. Om du vill återställa tabellerna och filerna från det ursprungliga lakehouse-huset måste du använda ABFS-sökvägen för att komma åt data (se Anslut till Microsoft OneLake). Du kan använda kodexemplet nedan (se Introduktion till Microsoft Spark-verktyg) i notebook-filen för att hämta ABFS-sökvägarna för filer och tabeller från det ursprungliga lakehouse-huset. (Ersätt C1. W1 med det faktiska arbetsytans namn)

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

4. Använd följande kodexempel för att kopiera tabeller och filer till det nyligen skapade lakehouse.

   1. För Delta-tabeller måste du kopiera tabell ett i taget för att återställa i det nya sjöhuset. När det gäller Lakehouse-filer kan du kopiera hela filstrukturen med alla underliggande mappar med en enda körning.

   2. Kontakta supportteamet för tidsstämpeln för redundans som krävs i skriptet.

   %%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. När du har kört skriptet visas tabellerna i det nya sjöhuset.

Metod 2: Använd Azure Storage Explorer för att kopiera filer och tabeller

Om du bara vill återställa specifika Lakehouse-filer eller tabeller från det ursprungliga lakehouse-huset använder du Azure Storage Explorer. Mer information finns i Integrera OneLake med Azure Storage Explorer. För stora datastorlekar använder du Metod 1.

Kommentar

De två metoderna som beskrivs ovan återställer både metadata och data för Delta-formaterade tabeller, eftersom metadata är samlokalisering och lagras med data i OneLake. För icke-Delta-formaterade tabeller (t.ex. CSV, Parquet osv.) som skapas med hjälp av DDL-skript/-kommandon (Spark Data Definition Language) ansvarar användaren för att underhålla och köra Spark DDL-skript/-kommandon igen för att återställa dem.

Notebook-fil

Notebook-filer från den primära regionen är fortfarande inte tillgängliga för kunder och koden i notebook-filer replikeras inte till den sekundära regionen. För att återställa notebook-kod i den nya regionen finns det två metoder för att återställa notebook-kodinnehåll.

Metod 1: Användarhanterad redundans med Git-integrering (i offentlig förhandsversion)

Det bästa sättet att göra detta enkelt och snabbt är att använda Fabric Git-integrering och sedan synkronisera notebook-filen med din ADO-lagringsplats. När tjänsten redundansväxlar till en annan region kan du använda lagringsplatsen för att återskapa anteckningsboken på den nya arbetsytan som du skapade.

1. Konfigurera Git-integrering och välj Anslut och synkronisera med ADO-lagringsplatsen.

   

   Följande bild visar den synkroniserade notebook-filen.

   

2. Återställa notebook-filen från ADO-lagringsplatsen.

   1. I den nyligen skapade arbetsytan ansluter du till din Azure ADO-lagringsplats igen.

      

   2. Välj knappen Källkontroll. Välj sedan relevant gren av lagringsplatsen. Välj sedan Uppdatera alla. Den ursprungliga anteckningsboken visas.

      

      

   3. Om den ursprungliga notebook-filen har ett standard lakehouse kan användarna referera till Lakehouse-avsnittet för att återställa lakehouse och sedan ansluta det nyligen återställda lakehouse till den nyligen återställda notebook-filen.

      

   4. Git-integreringen stöder inte synkronisering av filer, mappar eller notebook-ögonblicksbilder i notebook-resursutforskaren.

      1. Om den ursprungliga notebook-filen har filer i notebook-resursutforskaren:

         1. Se till att spara filer eller mappar på en lokal disk eller på någon annan plats.

         2. Ladda upp filen igen från din lokala disk eller molnenheter till den återställda notebook-filen.

      2. Om den ursprungliga notebook-filen har en ögonblicksbild av notebook-filen sparar du även ögonblicksbilden av notebook-filen till ditt eget versionskontrollsystem eller din lokala disk.

         

         

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Metod 2: Manuell metod för att säkerhetskopiera kodinnehåll

Om du inte använder Git-integreringsmetoden kan du spara den senaste versionen av din kod, filer i resursutforskaren och ögonblicksbilden av notebook-filer i ett versionskontrollsystem som Git och manuellt återställa notebook-innehållet efter ett haveri:

1. Använd funktionen "Importera anteckningsbok" för att importera den notebook-kod som du vill återställa.

   

2. Efter importen går du till önskad arbetsyta (till exempel "C2. W2") för att komma åt den.

3. Om den ursprungliga notebook-filen har ett standard lakehouse läser du avsnittet Lakehouse. Anslut sedan det nyligen återställda lakehouse (som har samma innehåll som det ursprungliga standard lakehouse) till den nyligen återställda notebook-filen.

4. Om den ursprungliga notebook-filen har filer eller mappar i resursutforskaren laddar du upp filerna eller mapparna som sparats i användarens versionskontrollsystem igen.

Definition av Spark-jobb

Spark-jobbdefinitioner (SJD) från den primära regionen är fortfarande inte tillgängliga för kunder, och huvuddefinitionsfilen och referensfilen i notebook-filen replikeras till den sekundära regionen via OneLake. Om du vill återställa SJD i den nya regionen kan du följa de manuella stegen nedan för att återställa SJD. Observera att historiska körningar av SJD inte återställs.

Du kan återställa SJD-objekten genom att kopiera koden från den ursprungliga regionen med hjälp av Azure Storage Explorer och manuellt återansluta Lakehouse-referenser efter katastrofen.

1. Skapa ett nytt SJD-objekt (till exempel SJD1) i den nya arbetsytan C2. W2, med samma inställningar och konfigurationer som det ursprungliga SJD-objektet (till exempel språk, miljö osv.).

2. Använd Azure Storage Explorer för att kopiera Libs, Mains och Snapshots från det ursprungliga SJD-objektet till det nya SJD-objektet.

   

3. Kodinnehållet visas i den nyligen skapade SJD:en. Du måste lägga till den nyligen återställda Lakehouse-referensen manuellt till jobbet (se Återställningsstegen för Lakehouse). Användarna måste ange de ursprungliga kommandoradsargumenten manuellt.

   

Nu kan du köra eller schemalägga din nyligen återställda SJD.

Mer information om Azure Storage Explorer finns i Integrera OneLake med Azure Storage Explorer.

Datavetenskap

Den här guiden vägleder dig genom återställningsprocedurerna för Datavetenskap upplevelse. Den omfattar ML-modeller och experiment.

ML-modell och experiment

Datavetenskap objekt från den primära regionen är fortfarande inte tillgängliga för kunder, och innehållet och metadata i ML-modeller och experiment replikeras inte till den sekundära regionen. Om du vill återställa dem helt i den nya regionen sparar du kodinnehållet i ett versionskontrollsystem (till exempel Git) och kör kodinnehållet igen manuellt efter katastrofen.

1. Återställ anteckningsboken. Se återställningsstegen för notebook-filer.

2. Konfiguration, historiskt kör mått och metadata replikeras inte till den kopplade regionen. Du måste köra om varje version av din datavetenskapskod för att helt återställa ML-modeller och experiment efter katastrofen.

Informationslager

Den här guiden vägleder dig genom återställningsprocedurerna för informationslagerupplevelsen. Den täcker lager.

Distributionslager

Lager från den ursprungliga regionen är fortfarande otillgängliga för kunder. Använd följande två steg för att återställa lager.

1. Skapa ett nytt interim lakehouse i arbetsytan C2. W2 för de data som du kopierar över från det ursprungliga lagret.

2. Fyll i informationslagrets Delta-tabeller genom att använda lagerutforskaren och T-SQL-funktionerna (se Tabeller i datalager i Microsoft Fabric).

Kommentar

Vi rekommenderar att du behåller din lagerkod (schema, tabell, vy, lagrad procedur, funktionsdefinitioner och säkerhetskoder) version och sparad på en säker plats (till exempel Git) enligt dina utvecklingsmetoder.

Datainmatning via Lakehouse- och T-SQL-kod

I nyskapade arbetsytan C2. W2:

1. Skapa ett interim lakehouse "LH2" i C2. W2.

2. Återställ Delta-tabellerna i interim lakehouse från det ursprungliga lagret genom att följa Återställningsstegen för Lakehouse.

3. Skapa ett nytt lager "WH2" i C2. W2.

4. Anslut interim lakehouse i din lagerutforskare.

   

5. Beroende på hur du ska distribuera tabelldefinitioner före dataimporten kan den faktiska T-SQL som används för import variera. Du kan använda metoden INSERT INTO, SELECT INTO eller CREATE TABLE AS SELECT för att återställa Lagertabeller från lakehouses. Vidare i exemplet skulle vi använda INSERT INTO-smak. (Om du använder koden nedan ersätter du exempel med faktiska tabell- och kolumnnamn)

   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. Slutligen ändrar du anslutningssträng i program med hjälp av ditt Infrastrukturlager.

Kommentar

För kunder som behöver regional haveriberedskap och helt automatiserad affärskontinuitet rekommenderar vi att du behåller två infrastrukturlagerinställningar i separata infrastrukturresurser och underhåller kod- och dataparitet genom att utföra regelbundna distributioner och datainmatning till båda platserna.

Data Factory

Data Factory-objekt från den primära regionen är fortfarande inte tillgängliga för kunder och inställningarna och konfigurationen i datapipelines eller dataflödesgen2-objekt replikeras inte till den sekundära regionen. Om du vill återställa dessa objekt i händelse av ett regionalt fel måste du återskapa dina Dataintegration objekt på en annan arbetsyta från en annan region. I följande avsnitt beskrivs informationen.

Dataflöden Gen2

Om du vill återställa ett Dataflow Gen2-objekt i den nya regionen måste du exportera en PQT-fil till ett versionskontrollsystem som Git och sedan återställa Dataflow Gen2-innehållet manuellt efter katastrofen.

1. I dataflödets Gen2-objekt går du till fliken Start i Power Query-redigeraren och väljer Exportera mall.

   

2. I dialogrutan Exportera mall anger du ett namn (obligatoriskt) och en beskrivning (valfritt) för den här mallen. När du är klar klickar du på OK.

   

3. Efter katastrofen skapar du ett nytt Dataflow Gen2-objekt i den nya arbetsytan "C2. W2".

4. I den aktuella vyrutan i Power Query-redigeraren väljer du Importera från en Power Query-mall.

   

5. I dialogrutan Öppna bläddrar du till din standardmapp för nedladdningar och väljer den .pqt-fil som du sparade i föregående steg. Välj sedan Öppna.

6. Mallen importeras sedan till ditt nya Dataflow Gen2-objekt.

Datapipelines

Kunder kan inte komma åt datapipelines i händelse av regional katastrof och konfigurationerna replikeras inte till den kopplade regionen. Vi rekommenderar att du skapar kritiska datapipelines på flera arbetsytor i olika regioner.

Realtidsanalys

Den här guiden vägleder dig genom återställningsprocedurerna för realtidsanalysupplevelsen. Den omfattar KQL-databaser/frågeuppsättningar och eventstreams.

KQL-databas/frågeuppsättning

KQL-databas-/frågeuppsättningsanvändare måste vidta proaktiva åtgärder för att skydda mot en regional katastrof. Följande metod säkerställer att data i KQL-databasernas frågeuppsättningar förblir säkra och tillgängliga i händelse av en regional katastrof.

Använd följande steg för att garantera en effektiv haveriberedskapslösning för KQL-databaser och frågeuppsättningar.

1. Upprätta oberoende KQL-databaser: Konfigurera två eller flera oberoende KQL-databaser/frågeuppsättningar på dedikerade Infrastrukturresurser-kapaciteter. Dessa bör konfigureras i två olika Azure-regioner (helst Azure-kopplade regioner) för att maximera motståndskraften.

2. Replikera hanteringsaktiviteter: Alla hanteringsåtgärder som vidtas i en KQL-databas bör speglas i den andra. Detta säkerställer att båda databaserna förblir synkroniserade. Viktiga aktiviteter som ska replikeras är:

   • Tabeller: Kontrollera att tabellstrukturerna och schemadefinitionerna är konsekventa mellan databaserna.

   • Mappning: Duplicera alla nödvändiga mappningar. Kontrollera att datakällor och mål är korrekt anpassade.

   • Principer: Kontrollera att båda databaserna har liknande datakvarhållning, åtkomst och andra relevanta principer.

3. Hantera autentisering och auktorisering: Konfigurera nödvändiga behörigheter för varje replik. Se till att rätt auktoriseringsnivåer har fastställts, vilket ger åtkomst till den personal som krävs samtidigt som säkerhetsstandarderna upprätthålls.

4. Parallell datainmatning: Om du vill hålla data konsekventa och redo i flera regioner läser du in samma datauppsättning i varje KQL-databas samtidigt som du matar in den.

Händelseström

En händelseström är en central plats i Infrastrukturplattformen för att samla in, transformera och dirigera realtidshändelser till olika destinationer (till exempel lakehouses, KQL-databaser/frågeuppsättningar) utan kod. Så länge målen stöds av haveriberedskap förlorar inte eventstreams data. Därför bör kunderna använda haveriberedskapsfunktionerna i dessa målsystem för att garantera datatillgänglighet.

Kunder kan också uppnå geo-redundans genom att distribuera identiska Eventstream-arbetsbelastningar i flera Azure-regioner som en del av en aktiv/aktiv strategi för flera platser. Med en aktiv/aktiv metod för flera platser kan kunderna komma åt sin arbetsbelastning i någon av de distribuerade regionerna. Den här metoden är den mest komplexa och kostsamma metoden för haveriberedskap, men det kan minska återställningstiden till nära noll i de flesta situationer. För att vara helt geo-redundanta kan kunderna

1. Skapa repliker av deras datakällor i olika regioner.

2. Skapa Eventstream-objekt i motsvarande regioner.

3. Anslut dessa nya objekt till identiska datakällor.

4. Lägg till identiska mål för varje händelseström i olika regioner.

Relaterad information

• Guide för haveriberedskap för Microsoft Fabric