Veiledning for opplevelsesspesifikk nødutvinning

Denne artikkelen gir erfaringsspesifikk veiledning for å gjenopprette dine Fabric-data ved en regional katastrofe.

Eksempelscenario

Mange veiledningsseksjoner i denne artikkelen bruker følgende eksempelscenario for forklaring og illustrasjon. Referer tilbake til dette scenarioet etter behov.

La oss si at du har en kapasitet C1 i område A som har et arbeidsområde W1. Hvis du har aktivert katastrofegjenoppretting for kapasitet C1, blir OneLake-data replikert til en sikkerhetskopi i region B. Hvis region A opplever forstyrrelser, går Fabric-tjenesten i C1 over til region B.

Bildet nedenfor illustrerer dette scenarioet. Boksen til venstre viser det forstyrrede området. Boksen i midten representerer fortsatt tilgjengelighet av dataene etter failover, og boksen til høyre viser den fullstendig dekkede situasjonen etter at kunden fungerer for å gjenopprette tjenestene til full funksjon.

Her er den generelle gjenopprettingsplanen:

1. Lag en ny Fabric-kapasitet C2 i en ny region.

2. Opprett et nytt W2-arbeidsområde i C2, inkludert tilsvarende elementer med samme navn som i C1. W1.

3. Kopier data fra den avbrutte C1. W1 til C2. W2.

4. Følg de dedikerte instruksjonene for hver komponent for å gjenopprette elementer til sin fulle funksjon.

Denne gjenopprettingsplanen forutsetter at leietakerboligområdet fortsatt er operativt. Hvis leietakerens hjemmeregion opplever et strømbrudd, er trinnene beskrevet i denne artikkelen betinget av gjenopprettingen, som først må initieres og fullføres av Microsoft.

Opplevelsesspesifikke gjenopprettingsplaner

Følgende seksjoner gir trinnvise guider for hver Fabric-opplevelse for å hjelpe deg gjennom restitusjonsprosessen.

Datateknikk

Denne veiledningen veileder deg gjennom gjenopprettingsprosedyrene for Dataingeniør opplevelsen. Den dekker lakehouses, notatbøker, Spark-jobbdefinisjoner, brukerdatafunksjoner og GraphQL-API-er.

Lakehouse

Lakehouses fra den opprinnelige regionen forblir utilgjengelig for kunder. Hvis du vil gjenopprette et lakehouse, kan kunder opprette det på nytt i arbeidsområde C2. W2. Vi anbefaler to fremgangsmåter for å gjenopprette lakehouses:

Fremgangsmåte 1: Bruke egendefinert skript til å kopiere Lakehouse Delta-tabeller og -filer

Kunder kan gjenskape lakehouses ved hjelp av et egendefinert Scala-skript.

1. Opprett lakehouse (for eksempel LH1) i det nyopprettede arbeidsområdet C2. W2.

2. Opprett en ny notatblokk i arbeidsområdet C2. W2.

3. For å gjenopprette tabellene og filene fra det opprinnelige lakehouse, se dataene med OneLake-stier som abfss (se Connecting to Microsoft OneLake). Du kan bruke følgende kodeeksempel (se Introduksjon til Microsoft Spark Utilities) i notatboken for å hente ABFS-stier for filer og tabeller fra det opprinnelige innsjøhuset. (Bytt C1.W1 ut med det faktiske arbeidsområdets navn)

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

4. Bruk følgende kodeeksempel til å kopiere tabeller og filer til det nyopprettede lakehouse.

   1. For Delta-tabeller må du kopiere tabell én om gangen for å gjenopprette i det nye lakehouse. Når det gjelder Lakehouse-filer, kan du kopiere den fullstendige filstrukturen med alle de underliggende mappene med én enkelt kjøring.

   2. Ta kontakt med kundestøtteteamet for tidsstempelet for failover som kreves 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
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Når du har kjørt skriptet, vises tabellene i det nye innsjøhuset.

Tilnærming 2: Bruk Azure Storage Explorer for å kopiere filer og tabeller

For å gjenopprette kun spesifikke Lakehouse-filer eller tabeller fra det opprinnelige Lakehouse, bruk Azure Storage Explorer. Se Integrer OneLake med Azure Storage Explorer for detaljerte trinn. Bruk Tilnærming 1 for store datastørrelser.

Gjenoppretting av Fabric materialiserte innsjøutsikter

Etter failover kan du ikke få tilgang til materialiserte innsjøutsikter fra det opprinnelige området. Failover-prosessen replikerer ikke oppdateringsplaner eller kjøringshistorikk til sekundærregionen. For å gjenopprette disse elementene, fullfør følgende trinn etter at du har gjenopprettet dine Lakehouse-data:

• Hent ut Lakehouse-tabellene ved å bruke Metode 1 eller Tilnærming 2 beskrevet tidligere i denne artikkelen. Kopier kun kildetabellene.
• Hent notatbøkene som inneholder dine MLV-definisjoner. For restitusjonstrinn, se avsnittet Notatbok .
• Kjør de gjenvunne notatbøkene for å gjenskape MLV-ene i det nye Lakehouse. For informasjon om hvordan du lager MLV-er, se Lag en materialisert innsjøutsikt. Hvis du kopierte MLV-er i det tidligere steget, kjør CREATE OR REPLACE når du gjenskaper dem.
• Gjenskap manuelt oppdateringsskjemaene for MLV i det nye arbeidsområdet. Du kan ikke gjenopprette tidsplanhistorikk eller utførelsesmålinger.
• Hvis MLV-ene dine mater semantiske modeller eller rapporter, verifiser og oppdater Lakehouse-ID-en og datasett-ID-referansene etter behov. Koble rapportene til den oppdaterte semantiske modellen igjen og valider dataens ferskhet.

Notatblokk

Notatbøker fra primærregionen er fortsatt utilgjengelige for kundene, og koden i notatbøker replikeres ikke til sekundærregionen. For å gjenopprette notatbokkode i det nye området, bruk en av følgende metoder.

Tilnærming 1: Brukeradministrert redundans med Git-integrasjon (i offentlig forhåndsvisning)

Bruk Fabric Git-integrasjon for å synkronisere notatboken din med ditt Azure DevOps (ADO) repo. Etter at tjenesten har gått over til en annen region, bruk repoet for å bygge opp notatboken på nytt i det nye arbeidsområdet du har opprettet.

1. Konfigurer Git-integrering for arbeidsområdet, og velg Koble til og synkroniser med ADO-repositoriet.

   

   Bildet nedenfor viser den synkroniserte notatblokken.

   

2. Gjenopprett notatblokken fra ADO-repo.

   1. I det nyopprettede arbeidsområdet, koble til Azure ADO-repoet igjen.

      

   2. Velg Kildekontroll-knappen. Velg deretter den relevante grenen av repo. Velg deretter Oppdater alle. Den originale notatblokken vises.

      

      

   3. Hvis den opprinnelige notatboken har en standard lakehouse, se til Lakehouse-delen for å gjenopprette lakehouse, og koble deretter den nylig gjenfunne lakehouse til den nylig gjenvunne notatboken.

      

   4. Git-integreringen støtter ikke synkronisering av filer, mapper eller øyeblikksbilder av notatblokker i ressursutforskeren for notatblokken.

      1. Hvis den opprinnelige notatblokken har filer i ressursutforskeren for notatblokken:

         1. Lagre filer eller mapper på en lokal disk eller et annet sted.

         2. Last opp filen på nytt fra den lokale disken eller skystasjonene til den gjenopprettede notatblokken.

      2. Hvis den opprinnelige notatblokken har et øyeblikksbilde av notatblokken, lagrer du også øyeblikksbildet av notatblokken i ditt eget versjonskontrollsystem eller en lokal disk.

         

         

Hvis du vil ha mer informasjon om Git-integrering, kan du se Innføring i Git-integrasjon.

Tilnærming 2: Manuell tilnærming til sikkerhetskopiering av kodeinnhold

Hvis du ikke velger Git-integrasjonsmetoden, lagre den nyeste versjonen av koden din, filer i ressursutforskeren og notatblokk-snapshot i et versjonskontrollsystem som Git. Manuelt gjenopprette innholdet i notatboken etter en katastrofe:

1. Bruk funksjonen Importer notatbok for å importere notatboken du ønsker å gjenopprette.

   

2. Når du har importert, går du til ønsket arbeidsområde (for eksempel C2. W2") for å få tilgang til den.

3. Hvis den opprinnelige notatblokken har et standard lakehouse, kan du se Lakehouse-delen. Deretter kobler du det nylig gjenopprettede lakehouse (som har samme innhold som det opprinnelige standard lakehouse) til den nylig gjenopprettede notatblokken.

4. Hvis den opprinnelige notatblokken har filer eller mapper i ressursutforskeren, laster du opp filene eller mappene som er lagret i brukerens versjonskontrollsystem.

Spark-jobbdefinisjon

Spark-jobbdefinisjoner (SJD) fra primærregionen er fortsatt utilgjengelige, og OneLake replikerer hoveddefinisjonsfilen og referansefilen i notatboken til sekundærregionen. Hvis du vil gjenopprette SJD i det nye området, følg de manuelle trinnene beskrevet i denne delen. Historiske spor av SJD er ikke gjenfunnet.

Du kan gjenopprette SJD-elementene ved å kopiere koden fra den opprinnelige regionen ved å bruke Azure Storage Explorer og manuelt koble til Lakehouse-referanser etter katastrofen.

1. Opprett et nytt SJD-element (for eksempel SJD1) i det nye arbeidsområdet C2. W2, med de samme innstillingene og konfigurasjonene som det opprinnelige SJD-elementet (for eksempel språk, miljø og så videre).

2. Bruk Azure Storage Explorer for å kopiere Libs, Mains og Snapshots fra det opprinnelige SJD-elementet til det nye SJD-elementet.

   

3. Kodeinnholdet vises i den nyopprettede SJD-en. Du må manuelt legge til den nylig gjenopprettede Lakehouse-referansen i jobben (se Lakehouse-gjenopprettingstrinnene). Brukere må taste inn de opprinnelige kommandolinjeargumentene manuelt.

   

Nå kan du kjøre eller planlegge den nylig gjenopprettede SJD-en.

For detaljer om Azure Storage Explorer, se Integrér OneLake med Azure Storage Explorer.

Funksjoner for brukerdata

For å gjenopprette dine datafunksjoner i et sunt område, bruk en av følgende tilnærminger.

Tilnærming 1: Med Git-integrasjon (anbefalt)

Den foretrukne gjenopprettingsmekanismen er Fabric Git-integrasjon. Ved å synkronisere brukerdatafunksjonsprosjekter med et Azure DevOps- eller GitHub-repositorium, kan du raskt rekonstruere dem i et nytt arbeidsområde etter failover.

Gjør deg klar før en katastrofe oppstår

1. Konfigurer Fabric Git-integrasjon for arbeidsområdet som hoster brukerdatafunksjonen.
2. Koble arbeidsområdet til et Azure DevOps- eller GitHub-repositorium.
3. Forplikt all brukerdata-funksjon til repositoriet og synkroniser endringer regelmessig.
4. Lagre miljøspesifikke innstillinger separat i variabelbiblioteker om nødvendig.

Gjenopprettingssteg

Etter en regional katastrofe:

1. Lag en ny Fabric-kapasitet i en sunn region, som C2.
2. Opprett et nytt arbeidsområde, som W2, i den nye kapasiteten.
3. Koble arbeidsområdet til det samme Azure DevOps- eller GitHub-arkivet.
4. Open Source-kontroll og synkroniser innholdet i arkivet til arbeidsområdet.
5. Gjenskap eller gjenopprett alle avhengige Fabric-ressurser, som lakehouses, SQL-databaser i Fabric, lagre og Business Events.
6. Distribuer brukerdatafunksjonene på nytt.
7. Valider funksjonsutførelse og avhengighetstilkobling.
8. Oppdater nedstrømsapplikasjoner, datapipelines eller andre integrerte systemer for å referere til de gjenopprettede funksjonene.
9. Fullstendig ende-til-ende-validering av alle dine scenarioer.

Viktige hensyn

• Git-integrasjon gjenoppretter kun kildekode og prosjektressurser.
• Historiske henrettelseslogger blir ikke funnet.
• Nedstrømssystemer kan kreve endepunktsrebinding.

For mer informasjon, se Brukerdatafunksjoner kildekontroll og distribusjon.

Tilnærming 2: Manuell gjenoppretting

Hvis Git-integrasjonen ikke var konfigurert før katastrofen, kan du manuelt rekonstruere brukerdatafunksjoner fra kildekodebackuper.

Gjør deg klar før en katastrofe oppstår

Utfør jevnlig følgende oppgaver, og lagre elementene i et eksternt kildekontrollarkiv eller backup-lokasjon:

• Eksporter funksjonens kildekode til et GitHub-repositorium.
• Dokumenter og bevar informasjon om avhengighet.
• Dokumentmiljøinnstillinger.

Gjenopprettingssteg

Etter en regional katastrofe:

1. Lag en ny Fabric-kapasitet i en sunn region, som C2.
2. Opprett et nytt arbeidsområde, for eksempel W2.
3. Gjenopprett alle ressurser som kreves av funksjonen, inkludert innsjøhus, SQL-databaser i Fabric, lagre, eventhouses og eksterne tjenester.
4. Opprett et nytt user data-funksjonsprosjekt.
5. Importer eller lag kildekoden til funksjonen på nytt.
6. Gjenbruk konfigurasjonsinnstillinger for kjøretid.
7. Installer alle funksjonsavhengigheter på nytt.
8. Omplasser funksjonen.
9. Konfigurer autentisering og autorisasjon på nytt.
10. Gjenskap Business Event-utgivere eller forbrukere, hvis det brukes.
11. Fullfør ende-til-ende valideringstesting for dine scenarioer og integrasjoner.

GraphQL

GraphQL-elementer fra primærregionen er ikke tilgjengelige etter en regional katastrofe, og GraphQL-definisjoner og konfigurasjoner replikeres ikke til sekundærregionen. For å gjenopprette GraphQL i et nytt område, bruk en av følgende tilnærminger.

Tilnærming 1: Brukerstyrt redundans med Git-integrasjon

Den beste måten å gjøre denne prosessen enkel og rask på, er å bruke Fabric Git-integrasjon, og deretter synkronisere GraphQL med ADO-repoet ditt. Etter at tjenesten har gått over til en annen region, kan du bruke repoet til å bygge opp GraphQL på nytt i det nye arbeidsområdet du har opprettet.

1. Opprett et nytt arbeidsområde i målkapasiteten og regionen.

2. Gjenopprett alle avhengige datakilder, som Lakehouse-, Warehouse- eller SQL-databaser, ved å følge deres respektive gjenopprettingstrinn.

3. Oppdater GraphQL-definisjonen til å peke på de nylig gjenopprettede ressursene ved å endre miljøspesifikke referanser som kildearbeidsområde-IDer, kildeobjekt-IDer og tilkoblingsdetaljer. Dette trinnet sikrer korrekt binding ved utrullingstidspunkt.

4. Redeployer GraphQL-elementer fra Git-repositoriet til det nye arbeidsområdet. Dette steget gjenskaper API-strukturen og konfigurasjonen ved å bruke de oppdaterte definisjonene.

5. Bruk gjeninndelingsinnstillinger, inkludert roller, tilgangskontroller og autentiseringskonfigurasjon.

6. Bruk endepunktsreferanser på nytt ved å oppdatere applikasjoner eller integrasjoner til å bruke det nyopprettede GraphQL-endepunktet.

7. Oppdater eventuelle eksisterende distribusjonspipelines som pekte til det gamle arbeidsområdet for å referere til det nyopprettede arbeidsområdet.

8. Valider ende-til-ende-funksjonalitet i API-et.

Tilnærming 2: Manuell tilnærming

Hvis du ikke bruker Git-integrasjonsmetoden, kan du bruke følgende manuelle tilnærming for å gjenopprette GraphQL.

1. Opprett et nytt arbeidsområde i målkapasiteten og regionen.

2. Gjenopprette alle avhengige datakilder, som Lakehouse, Warehouse eller SQL-databaser.

3. Gjenskap GraphQL-API-et manuelt i det nye arbeidsområdet, inkludert skjemadefinisjoner, datakildetilkoblinger og relasjoner.

4. Bruk gjeninndelingsinnstillinger, inkludert roller, tilgangskontroller og autentiseringskonfigurasjon.

5. Bruk endepunktsreferanser på nytt ved å oppdatere applikasjoner eller integrasjoner til å bruke det nyopprettede GraphQL-endepunktet.

6. Oppdater eventuelle eksisterende distribusjonspipelines som pekte til det gamle arbeidsområdet for å referere til det nyopprettede arbeidsområdet.

7. Valider ende-til-ende-funksjonalitet i API-et.

Viktige hensyn

1. GraphQL er avhengig av eksterne avhengigheter (som Lakehouse, Warehouse og SQL), som du må gjenopprette før GraphQL-distribusjon.

2. GraphQL API-definisjoner inkluderer miljøspesifikke referanser (som sourceWorkspaceId og sourceItemId). Ved gjenoppretting i et nytt område kan disse referansene bli ugyldige. Oppdater dem til å peke på nylig opprettede ressurser.

3. Automatisk rebinding av datakilder er ikke garantert i katastrofegjenopprettingssituasjoner, spesielt ved bruk av lagrede legitimasjoner eller kryss-arbeidsområde-tilkoblinger.

4. Andre objektinnstillinger som overvåking, autorisasjon, RBAC, introspeksjon og mer overføres ikke etter failover. Du må gjenopprette disse innstillingene i den nye regionen.

Referanser

• Oversikt over Fabric Git-integrasjon - Microsoft Fabric | Microsoft Learn

• Kildekontroll- og distribusjonspipelines i API for GraphQL - Microsoft Fabric | Microsoft Learn 

App

Systemet replikerer ikke Fabric Apps, inkludert deres kode, konfigurasjon og metadata, til sekundære regioner. Hvis primærregionen feiler, forblir appen utilgjengelig. For gjenoppretting, lagre appens kildekode utenfor systemet i GitHub, Azure DevOps eller et annet kildekontrollsystem. Hent appdata separat ved å følge katastrofegjenopprettingsveiledningen for hver underliggende Fabric-datalagring.

Manuell tilnærming

Du kan manuelt gjenopprette en Fabric App etter en regional katastrofe ved å bruke applikasjonens kildekode og Rayfin CLI. 

Forutsetninger 

Før en katastrofe inntreffer:

• Lagre Fabric App-kildekoden i GitHub, Azure DevOps eller et annet kildekontrollarkiv. 

• Dokumenter prosessen for gjenoppretting.  

Gjenopprettingssteg 

1. Opprett et nytt arbeidsområde i målkapasiteten og regionen. 

2. Gjenopprett avhengige ressurser før du distribuerer applikasjonen på nytt.  

3. Hent den nyeste Fabric App-kildekoden fra ditt kildekodearkiv eller lokal backup. 

4. Fra applikasjonskildekatalogen, distribuer Fabric App til gjenopprettingsarbeidsområdet ved å bruke Rayfin CLI. Kjør rayfin up --workspace <new workspace>. 

5. Gjenopprett appens barneobjekt (SQL-database i Fabric) ved å følge de respektive gjenopprettingsprosedyrene.  

6. Gjenbruk innstillinger på gjenstandsnivå, inkludert roller og tilgangskontroller etter behov.  

7. Valider applikasjonens funksjonalitet og sørg for at brukerne har riktige tillatelser.  

Viktig! 

• Vedlikehold Fabric App-kildekoden utenfor Fabric-regionen for å muliggjøre gjenoppretting.  

• Applikasjonsdata i databasen blir ikke gjenopprettet som en del av Fabric App-distribusjonsprosessen og må gjenopprettes separat.  Du kan manuelt gjenopprette en Fabric App etter en regional katastrofe ved å bruke applikasjonens kildekode og Rayfin CLI. 

Azure Databricks Storage

Azure Databricks Storage lagrer data i OneLake. For å beskytte dataene dine mot et regionalt driftsavbrudd, aktiver katastrofegjenopprettingsinnstillingen på Fabric-kapasiteten som inneholder Azure Databricks Storage-elementet. Når du aktiverer denne innstillingen, replikerer OneLake dataene asynkront til Azure-paret område.

Hvis OneLake initierer en regional failover, kan applikasjoner fortsette å få tilgang til de replikerte dataene gjennom OneLakes globale endepunkt etter at failoveren er fullført. Fortsatt tilgang gjennom OneLake offentlige API-er krever ikke at du oppretter et nytt Azure Databricks Storage-element eller kopierer dataene til et annet arbeidsområde.

Gå gjennom OneLake Disaster Recovery and Data Protection for gjeldende atferd, hensyn og begrensninger.

For Azure Databricks-spesifikk katastrofegjenopprettingsplanlegging, se Disaster recovery - Azure Databricks.

Datavitenskap

Denne veiledningen veileder deg gjennom gjenopprettingsprosedyrene for Data Science-opplevelsen. Den dekker ML-modeller og eksperimenter.

ML-modell og eksperiment

Data Science-elementer fra primærregionen er fortsatt utilgjengelige for kundene, og innholdet og metadataene i ML-modeller og eksperimenter replikeres ikke til sekundærregionen. Hvis du vil gjenopprette dem fullstendig i det nye området, lagrer du kodeinnholdet i et versjonskontrollsystem (for eksempel Git), og kjører kodeinnholdet manuelt etter katastrofen.

1. Gjenopprette notatblokken. Se trinnene for gjenoppretting av notatblokken.

2. Konfigurasjon, historisk kjørte metrikker og metadata replikeres ikke til den parrede regionen. Du må kjøre hver versjon av datavitenskapskoden din på nytt for å fullstendig gjenopprette ML-modeller og eksperimenter etter katastrofen.

datalager

Denne guiden går gjennom restitusjonsprosedyrene for den Fabric datalager arbeidsmengden. Den dekker lagervarer.

Warehouse

Du kan ikke få tilgang til lagerbygninger fra den opprinnelige regionen. Hvis du vil gjenopprette lagre, bruker du følgende to trinn.

1. Lag et nytt midlertidig lakehouse i arbeidsområde C2. W2 for dataene du kopierer fra det opprinnelige lageret.

2. Fyll ut lagerets Delta-tabeller ved å bruke lagerutforskeren og T-SQL-funksjonene (se Tabeller i Fabric datalager).

Datainntak via Lakehouse- og T-SQL-kode

I nylig opprettet arbeidsområde C2. W2:

1. Opprett en midlertidig lakehouse "LH2" i C2. W2.

2. Gjenopprett Delta-tabellene i det midlertidige lakehouse fra det opprinnelige lageret ved å følge Lakehouse-gjenopprettingstrinnene.

3. Opprett et nytt lager "WH2" i C2. W2.

4. Koble til midlertidig lakehouse i lagerutforskeren.

5. Avhengig av hvordan du distribuerer tabelldefinisjoner før dataimport, kan den faktiske T-SQL-en som brukes til import variere. For å hente lagerbord fra innsjøhus kan du bruke INSERT INTO, SELECT INTO, eller CREATE TABLE AS SELECT tilnærmingen. I det følgende eksempelet bruker INSERT INTOvi . Hvis du bruker følgende kode, erstatt eksemplene med faktiske tabell- og kolonnenavn.

   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. Bytt tilkoblingsstreng i applikasjoner som bruker Fabric-lageret ditt.

Speilet database

Kunder kan ikke få tilgang til speilede databaser fra primærregionen, og innstillingene replikeres ikke til sekundærregionen. For å gjenopprette en speilet database etter en regional feil, må du gjenopprette den i et annet arbeidsområde fra en annen region.

Data Factory

Kunder kan ikke få tilgang til Data Factory-elementer fra primærregionen, og innstillingene og konfigurasjonen i pipelines eller Dataflow Gen2-elementer replikeres ikke til sekundærregionen. For å gjenopprette disse elementene etter en regional feil, må du lage Data Integration-elementene dine på nytt i et annet arbeidsområde fra en annen region. Avsnittene nedenfor beskriver detaljene.

Dataflyter Gen2

For å gjenopprette et Dataflow Gen2-element i den nye regionen, eksporter en .pqt fil til et versjonskontrollsystem som Git, og hent deretter manuelt Dataflow Gen2-innholdet etter katastrofen.

1. Fra Dataflow Gen2-elementet, i Hjem-fanen i Power Query-editoren, velg Eksporter mal.

   

2. I dialogen for eksportmal , skriv inn et navn (obligatorisk) og beskrivelse (valgfritt) for denne malen. Når du er ferdig, velger du OK.

   

3. Etter katastrofen oppretter du et nytt Dataflyt Gen2-element i det nye arbeidsområdet C2. W2".

4. Fra det nåværende visningspanelet i Power Query-editoren, velg Importer fra en Power Query-mal.

   

5. I åpne-dialogen , bla til standard nedlastingsmappe og velg .pqt filen du lagret i forrige steg. Velg deretter Åpne.

6. Malen importeres deretter til det nye Dataflyt gen2-elementet.

Lagre som-funksjonen for Dataflows støttes ikke ved katastrofegjenoppretting.

Pipelines

Kunder får ikke tilgang til pipeliner i tilfelle regional katastrofe, og konfigurasjonene replikeres ikke til det sammenkoblede området. Bygg dine kritiske pipelines i flere arbeidsområder på tvers av ulike regioner.

Kopier jobb

CopyJob-brukere må foreta proaktive tiltak for å beskytte mot en regional katastrofe. Følgende fremgangsmåte sikrer at en brukers CopyJobs forblir tilgjengelig etter en regional katastrofe.

Brukeradministrert redundans med Git-integrasjon (i offentlig forhåndsvisning)

Den beste måten å gjøre denne prosessen enkel og rask på, er å bruke Fabric Git-integrasjon, og deretter synkronisere CopyJob med Azure DevOps-repoet ditt. Når tjenesten mislykkes til et annet område, kan du bruke repositoriet til å gjenoppbygge CopyJob i det nye arbeidsområdet du opprettet.

1. Konfigurer arbeidsområdets Git-integrasjon og velg koble til og synkroniser med Azure DevOps-repoet.

   

   Bildet nedenfor viser den synkroniserte CopyJob.

   

2. Gjenopprett CopyJob fra Azure DevOps-repoen.

   1. I det nyopprettede arbeidsområdet, koble til og synkroniser til Azure DevOps-repoet igjen. Alle Fabric-elementer i dette arkivet lastes automatisk ned til ditt nye arbeidsområde.

      

   2. Hvis den opprinnelige CopyJob bruker en Lakehouse, brukere kan referere til Lakehouse delen for å gjenopprette Lakehouse og deretter koble den nylig gjenopprettede CopyJob til den nylig gjenopprettede Lakehouse.

Hvis du vil ha mer informasjon om Git-integrering, kan du se Innføring i Git-integrasjon.

Apache Airflow-jobb

Du må ta proaktive tiltak for å beskytte Apache Airflow-jobber i Fabric mot en regional katastrofe.

Administrer redundans ved å bruke Fabric Git-integrasjon. Først, synkroniser Airflow-jobben din med ADO-repoet. Hvis tjenesten går over til en annen region, kan du bruke repositoriet til å bygge opp Airflow-jobben på nytt i det nye arbeidsområdet du har opprettet.

Følg disse stegene for å nå dette målet:

1. Konfigurer Git-integrasjonen i arbeidsområdet ditt og velg Connect og synkroniser med ADO-repoet.

2. Etter det ser du Airflow-jobben din synkronisert med ADO-repoet.

3. Hvis du trenger å gjenopprette Airflow-jobben fra ADO-repoet, opprett et nytt arbeidsområde, koble til, og synkroniser til Azure ADO-repoet ditt igjen. Alle Fabric-elementer, inkludert Airflow, i dette arkivet lastes automatisk ned til ditt nye arbeidsområde.

Sanntidsinnsikt

Denne veiledningen veileder deg gjennom gjenopprettingsprosedyrene for sanntidsintelligensopplevelsen. Den dekker KQL-databaser, spørringssett og hendelsesstrømselementer.

Activator

Aktivator-elementer fra primærregionen er fortsatt utilgjengelige for kundene, og Activator-triggerdefinisjoner replikeres ikke til sekundærregionen. Aktivatorbrukere må ta proaktive grep for å forberede seg på regional katastrofegjenoppretting.

For å sikre at du kan gjenopprette Activator-elementer ved en regional katastrofe, sett opp Fabric Git-integrasjon for å sikkerhetskopiere triggerdefinisjoner og gjenopprette dem i et arbeidsområde i en annen region.

1. Konfigurer Fabric Git-integrasjon for arbeidsområdet som inneholder Activator-elementet ditt, og synkroniser triggerdefinisjonene dine med Git-repositoriet ditt.
2. Hold Activator-triggerdefinisjonene dine forpliktet og synkronisert jevnlig.
3. Under gjenoppretting, opprett et nytt arbeidsområde i målregionen (C2. W2), koble den til samme repository, og synkronisere for å gjenopprette triggerdefinisjonene.
4. Rekonfigurer og valider alle Activator-datakilder og avhengigheter i det nye arbeidsområdet.

Hvis du vil ha mer informasjon om Git-integrering, kan du se Innføring i Git-integrasjon.

Grafmodell/spørringssett

Kunder kan ikke få tilgang til Graph Model- og Graph queryset-elementer fra primærregionen, og Fabric replikerer ikke disse elementene til sekundærregionen. For å gjenopprette, opprett eller bruk en kapasitet i et annet område og gjenskap grafmodellen og graf-spørringssettelementene der.

1. Opprett eller bruk en eksisterende Fabric-kapasitet i en annen region som ikke er berørt av katastrofen.

2. Opprett et nytt arbeidsområde eller bruk et eksisterende arbeidsområde i den kapasiteten.

3. Gjenskap Graph model-elementet i det sekundære arbeidsområdet (referert i steg 2). Rekonfigurer modelldefinisjonen, inkludert noder, kanter og andre, for å matche den opprinnelige Graph-modellen.

4. Hvis det opprinnelige innsjøhuset ligger i det sviktende området, bør du først ta det opp igjen ved å følge innsjøhuset-delen.

5. Koble et lakehouse som OneLake-datakilde for det nyopprettede Graph model-elementet. Bruk det gjenvunne innsjøhuset hvis det lå i det sviktende området, eller koble til det eksisterende innsjøhuset igjen hvis det fortsatt er tilgjengelig.

6. Rekonfigurer eventuelle datalasteplaner eller tilkoblinger for grafmodellen i det nye arbeidsområdet.

7. Gjenskap Graph-queryset-elementet i det sekundære arbeidsområdet. Skriv manuelt inn spørringene og eventuelle lagrede spørringskonfigurasjoner fra det opprinnelige Graph-spørringssettet.

KQL-database/spørringssett

Brukere av KQL-databaser og spørringssett må ta proaktive grep for å beskytte seg mot en regional katastrofe. Følgende tilnærming sikrer at data i dine KQL-databaser og spørringssett forblir trygge og tilgjengelige ved en regional katastrofe.

Bruk følgende fremgangsmåte for å garantere en effektiv løsning for nødgjenoppretting for KQL-databaser og spørringssett.

1. Sett opp uavhengige KQL-databaser: Konfigurer to eller flere uavhengige KQL-databaser og spørringssett på dedikerte Fabric-kapasiteter. Sett opp disse databasene på tvers av to forskjellige Azure-regioner (helst Azure-parede regioner) for å maksimere robustheten.

2. Repliker administrasjonsaktiviteter: Speil enhver administrasjonshandling du tar i én KQL-database i den andre. Denne tilnærmingen holder begge databasene synkroniserte. Nøkkelaktiviteter som kan replikeres inkluderer:

   • Tabeller: Sørg for at tabellstrukturene og skjemadefinisjonene er konsistente på tvers av databasene.

   • Tilordning: Dupliser eventuelle nødvendige tilordninger. Sørg for at datakilder og destinasjoner stemmer overens korrekt.

   • Retningslinjer: Sørg for at begge databasene har lignende datalagring, tilgang og andre relevante retningslinjer.

3. Administrer autentisering og autorisasjon: Sett opp nødvendige tillatelser for hver replika. Sørg for å etablere riktige autorisasjonsnivåer, gi tilgang til nødvendig personell samtidig som sikkerhetsstandardene opprettholdes.

4. Parallell datainntak: Hvis du vil holde dataene konsekvente og klare i flere områder, laster du inn det samme datasettet i hver KQL-database samtidig som du inntar dem.

Eventstream

En hendelsesstrøm er et sentralisert sted i Fabric-plattformen for å fange, transformere og rute sanntidshendelser til ulike destinasjoner (for eksempel innsjøhus, KQL-databaser/spørringssett) med en no-code-opplevelse. Så lenge destinasjonene støtter katastrofegjenoppretting, mister ikke hendelsesstrømmene data. Bruk derfor katastrofegjenopprettingsmulighetene til disse destinasjonssystemene for å garantere datatilgjengelighet.

Du kan også oppnå geo-redundans ved å distribuere identiske hendelsesstrøm-arbeidsbelastninger i flere Azure-regioner som en del av en multi-site aktiv/aktiv strategi. Med en multi-site aktiv/aktiv tilnærming kan du få tilgang til arbeidsbelastningen din i alle de utplasserte regionene. Denne tilnærmingen er den mest komplekse og kostbare tilnærmingen til nødgjenoppretting, men det kan redusere gjenopprettingstiden til nær null i de fleste situasjoner. For å være fullstendig geo-redundant:

1. Lag kopier av datakildene dine i ulike regioner.

2. Lag eventstream-elementer i tilsvarende regioner.

3. Koble disse nye elementene til de identiske datakildene.

4. Legg til identiske mål for hver hendelsesstrøm i forskjellige områder.

Forretningsarrangementer, Fabric-arrangementer og Azure-arrangementer

Selv om Business Events, Fabric Events og Azure Events deler samme Real-Time hub-infrastruktur i Microsoft Fabric, har de distinkte opprinnelser, atferd og krav til gjenoppretting. Forstå disse forskjellene før du planlegger katastrofegjenoppretting:

• Fabric Events er arrangementsabonnementer som reagerer på aktivitet produsert av Fabric-ressursene selv. Disse hendelsene inkluderer endringer i arbeidsområdets livssyklus (som opprettelse, oppdatering eller sletting av innsjøhus, notatbøker eller lagre), jobbutførelser (som pipeline-kjøringer eller notatblokkkjøringer), samt OneLake-fil- og mappeoperasjoner. Disse abonnementene er push-baserte og midlertidige. Abonnementene blir ikke replikert til sekundærregionen.

• Azure Events er hendelsesabonnementer på aktivitet produsert av Azure Blob Storage-kontoer. Disse Azure-ressursene eksisterer uavhengig av enhver Fabric-kapasitet eller region. Selv om den Azure Blob Storage ressursen selv kan forbli tilgjengelig under et Fabric regionalt avbrudd, blir ikke abonnementene som er konfigurert i Real-Time huben replikert til sekundærregionen og må gjenopprettes på nytt.

• Forretningshendelser er en distinkt funksjon i Fabric Real-Time Intelligence som gjør det mulig for team å definere, publisere og handle på meningsfulle forretningssignaler. Forretningshendelser genereres fra Fabric gjennom Activator, Spark-notatbøker eller User Data Functions, og publiseres deretter til Real-Time hub hvor nedstrøms forbrukere som Activator, Eventhouse eller Power Automate kan reagere på dem. Hendelsesskjemaer styres sentralt gjennom Schema Registry. Eventhouse lagrer automatisk alle publiserte forretningshendelser, så gjenopprettingen påvirker direkte tilgjengeligheten av forretningshendelseshistorikk. Ingen av utgiver- eller forbrukerkonfigurasjonene, skjemadefinisjonene eller abonnementene replikeres til sekundærregionen.

Bruk følgende steg for å gjenopprette Business Events, Fabric Events og Azure Events i det nye arbeidsområdet i gjenopprettingsregionen.

For forretningsarrangementer:

1. Gjenskap forretningsarrangementet som brukes av utgivere og forbrukere ved å følge artikkelen Create Business Events i Fabric Real-Time Hub. Under opprettelsen av forretningshendelsen oppretter du ressursen Event Schema Set. Eventhouse-ressursen er valgfri avhengig av scenarioet. Hvis du har sikkerhetskopiert hendelsesskjemasettet ditt med Git-integrasjon, gjenopprette det først ved å følge avsnittet for hendelsesskjemasettet, og pek deretter forretningshendelsen på det gjenopprettede skjemasettet.

2. Gjenskap alle publisher-elementer som genererer forretningshendelser, som Spark-notatbøker eller User Data Functions, i det nye arbeidsområdet ved å følge publisher-artiklene: Use User Data Function as Business Events Publisher, Use Activator as a Business Events Publisher, Use Notebook as a Business Events Events Publisher, og bruk Eventstream som Business Events Publisher.

3. Gjenskap forbrukerabonnementene i Real-Time hub (for eksempel Activator-regler, notatbok-triggere eller Power Automate flows) som opprinnelig reagerte på forretningshendelser i den berørte regionen ved å følge artiklene Eventhouse og Real-Time Dashboard-integrasjon med forretningshendelser og Consume Business Events fra Activator.

4. Valider at hendelser flyter fra ende til ende ved å verifisere at abonnementene er aktive og at data ankommer forventede destinasjoner i gjenopprettingsregionen.

For Fabric-arrangementer:

1. Gjenskap abonnementene i Real-Time huben som peker til arbeidsområdets elementer, jobber eller OneLake-stier du gjenopprettet i gjenopprettingsområdet ved å følge artikkelen Utforsk Fabric hendelser i Fabric Real-Time hub.

2. Valider at hendelser flyter fra ende til ende ved å verifisere at abonnementene er aktive og at data ankommer forventede destinasjoner i gjenopprettingsregionen.

For Azure-arrangementer:

1. Azure Blob Storage-kontoer påvirkes ikke av et regionalt Fabric-avbrudd. Gjenskap arrangementsabonnementene i Real-Time hub som peker til de samme Azure Blob Storage kontoene ved å følge artikkelen Sett varsler på Azure Blob Storage hendelser i Real-Time hub.

2. Valider at hendelser flyter fra ende til ende ved å verifisere at abonnementene er aktive og at data ankommer forventede destinasjoner i gjenopprettingsregionen.

Hendelsesskjema sett

Et hendelsesskjema-sett er det Fabric elementet som inneholder definisjoner av hendelsestype og skjema i Real-Time Intelligence. Andre muligheter bygger videre på dette: utgivere skriver hendelser som følger skjemaene deres, og forbrukerne leser mot de samme definisjonene.

Hendelsesskjema-sett fra primærregionen forblir utilgjengelige for kundene, og de replikeres ikke til sekundærregionen. Men fordi et hendelsesskjema-sett er en varig definert definisjon og ikke et flyktig abonnement, kan du sikkerhetskopiere det på forhånd og gjenopprette det i stedet for å skrive det på nytt for hånd.

Anbefalt: ta backup med integrasjon av Fabric Git

For å gjenopprette et hendelsesskjema satt etter en regional katastrofe, sett opp Fabric Git-integrasjon før en katastrofe oppstår, og synkroniser arbeidsområdet som inneholder hendelsesskjemasettene dine med ditt Git-repositorium.

1. Konfigurer Fabric Git-integrasjon for arbeidsområdet som inneholder hendelsesskjemasettet ditt, og synkroniser det med ditt Git-repositorium.

2. Hold hendelsesskjema-settet forpliktet og synkronisert regelmessig, spesielt etter at hendelsestyper er lagt til eller nye skjemaversjoner er publisert.

3. Under gjenoppretting, opprett et nytt arbeidsområde i målregionen (C2. W2), koble den til samme repository, og synkroniser for å gjenopprette hendelsesskjemasettet. Fordi det nye arbeidsområdet er tomt, bringer Git-synkronisering innholdet fra repositoriet inn i arbeidsområdet.

4. Gjenskap alle utgivere og brukere som bruker skjemasettet, og følg veiledningen for disse varetypene.

5. Valider at utgivere kan publisere mot de gjenopprettede hendelsestypene, og at forbrukere mottar hendelser som forventet.

Den synkroniserte definisjonen inkluderer hendelsestypene i skjemasettet, skjemaene og skjemaversjonene. Den inkluderer ikke utgiverregistreringer, forbrukerabonnementer eller hendelseshistorikk. Hent disse separat, og følg veiledningen for itemtypene som bruker skjemasettet.

Alternativ: gjenskap manuelt

Hvis du ikke konfigurerte Git-integrasjon før katastrofen, gjenskap hendelsesskjemasettet i gjenopprettingsområdet ved å følge Create and manage event schema sets, og legg deretter til hendelsestypene og skjemaene som det opprinnelige skjemasettet inneholdt ved å følge Create and manage event schemas in schema sets.

Kart

Kartobjekter fra primærregionen forblir utilgjengelige for kundene, og kartelementene blir ikke replikert til sekundærregionen.

Hvis du vil gjenopprette et kartelement når en katastrofe skjer, sett opp Fabric Git-integrasjon, og synchronize kartelementet ditt med Git-repoet.

Under gjenopprettingen, etter at den nye regionen/kapasiteten i Fabric er satt opp, kan du bruke repoet til å bygge opp kartelementet i det nye arbeidsområdet du har opprettet. Siden det nye arbeidsområdet er tomt, henter Git sync innholdet fra repoet inn i det tomme arbeidsområdet. Dette steget bringer Kart-gjenstanden tilbake til liv.

Ontologi

Ontologibrukere må ta proaktive grep for å forberede seg på regional katastrofegjenoppretting. Tilnærmingen beskrevet nedenfor sikrer at etter en regional katastrofe kan Ontologien din fortsatt gjenopprettes og kan gjenopprettes raskt.

Den enkleste og raskeste måten å muliggjøre gjenoppretting på er å bruke Fabric Git-integrasjon og synkronisere ontologien din med et Azure DevOps (ADO)-repositorium. Hvis tjenesten går over til en annen region, kan du bruke dette repositoriet til å bygge opp ontologien på nytt i et nyopprettet arbeidsområde.

Ontologielementer i primærregionen er ikke tilgjengelige for kunder etter en regional katastrofe, og ontologielementer replikeres ikke til sekundærregionen.

For å gjenopprette et Ontology-element under en katastrofe, konfigurere Fabric Git-integrasjon, og synchronize Ontology-elementet med ADO-repositoriet ditt på forhånd.

Under gjenoppretting, når den nye regionen og kapasiteten i Fabric er satt opp, kan du bruke repositoryet til å bygge opp Ontology-elementet i et nytt arbeidsområde. Fordi det nye arbeidsområdet er tomt, henter Git sync innholdet fra repositoriet inn i arbeidsområdet, og gjenoppretter dermed effektivt Ontology-elementet.

Ontologiagent

Brukere av Ontology Agent må ta proaktive grep for å forberede seg på regional katastrofegjenoppretting. Tilnærmingen beskrevet i dette avsnittet sikrer at etter en regional katastrofe kan din Ontology Agent-opplevelse gjenopprettes i et nyopprettet arbeidsområde.

Ontology Agent avhenger av ontologielementet og av datakilder som er koblet til ontologien, som for eksempel innsjøhus. Kunder kan ikke få tilgang til Ontology Agent-økter i primærregionen etter en regional katastrofe, og Ontology Agent-økter blir ikke replikert til sekundærregionen. Aktive chat-økter, pågående handlinger og samtalehistorikk fra den berørte regionen kan ikke gjenopptas.

For å gjenopprette Ontology Agent-opplevelsen under en katastrofe, konfigurere Fabric Git-integrasjon, og synkroniser Ontology-elementet med ditt Azure DevOps (ADO)-repositorium på forhånd.

Under gjenopprettingen, når den nye regionen og kapasiteten i Fabric er satt opp, fullfør følgende trinn:

1. Opprett et nytt arbeidsområde i den nye kapasiteten.
2. Koble det nye arbeidsområdet til det samme ADO-repositoriet som inneholder Ontology-elementet.
3. Bruk Git-synkronisering for å gjenopprette Ontology-elementet i det nye arbeidsområdet.
4. Gjenopprett eventuelle avhengige dataelementer, som innsjøhus, ved å følge retningslinjene for disse elementene.
5. Bekreft at de gjenopprettede dataene er tilgjengelige i det parrede området. For OneLake-støttede data, anta at dataene er replikert til det parrede området, men ikke anta rekkefølgen av replikerte data under gjenoppretting.
6. Koble det nylig gjenopprettede Ontology-elementet til de gjenopprettede datakildene.
7. Start en ny Ontology Agent-økt og verifiser at agenten kan koble til det gjenopprettede Ontology-elementet og datakildene.

Planlegging

Denne artikkelen beskriver gjenopprettingsprosedyrene for planleggingsopplevelsen i IQ. Den beskriver trinnene som kreves for å gjenopprette nøkkelkomponenter, inkludert planleggingsark, PowerTable-ark, intelligensark, InfoBridge og tilhørende dataressurser.

Git-integrasjon for å gjenopprette planelementer

Den foretrukne tilnærmingen er å synkronisere alle planelementer med et Azure DevOps (ADO) eller GitHub-repositorium ved å bruke Fabric Git-integrasjon. Etter en failover, bruk repositoryet for å gjenopprette elementene i det nye arbeidsområdet.

Forkatastrofe (proaktive tiltak):

1. I arbeidsområde W1, gå til Arbeidsområdeinnstillinger og konfigurer Git-integrasjon.

2. Velg Connect og synkroniser med ADO eller GitHub-repositoriet ditt.

3. Velg planelementene som skal lastes opp til depotet og velg Forplikt.

   

4. Bekreft at Git-statusen til planobjektene er Synkronisert.

5. Etabler en commit-disiplin – commit etter hver betydelig endring i en plandefinisjon slik at repositoryet alltid gjenspeiler den nyeste tilstanden.

Gjenopprettingstrinn:

1. Lag et nytt arbeidsområde W2 innenfor kapasitet C2 i det sunne området.

2. I arbeidsområde W2, gå til Arbeidsområdeinnstillinger og koble til samme ADO/GitHub-repositorium igjen.

3. Velg kildekontroll. Velg den relevante repository-grenen og velg Oppdater Alt. Alle planposter lastes ned til W2.

Følgende komponenter gjenopprettes etter gjenoppretting:

• PowerTable-ark: Innstillinger for kildetabeller, kolonnekonfigurasjon, rad-tilgang, visuelle egenskaper (layout, formater og mer), radidentifikasjon, kommentarinnstillinger, gradvis endrende dimensjoner (SCD), godkjenninger, automatiseringer og skjemaer.
• Planleggingsark: Arkegenskaper (formatering, betinget formatering og mer), kommentarinnstillinger, tilbakeskrivingsinnstillinger, datainndatakolonner, datainndatarader, scenarier og bokmerker.
• InfoBridge: InfoBridge-kilder, InfoBridge-spørringer, transformasjonssteg, writeback-destinasjoner, writeback-innstillinger, koblede spørringsmappinger, spørringsgrupper, visuelle egenskaper (blend). Disse elementene kan ikke gjenopprettes: filbaserte kilder (CSV, Excel), tverrarbeidsmengdeark som bruker filbaserte kilder.
• Etterretning: Alle horoskoper og matriser.

Fabric SQL-gjenoppretting for planlegging

Data som legges inn i planleggingsark, tabeller brukt i PowerTable, og tilbakeskrivingsdata lagres i SQL-databaser og må vurderes som en del av din katastrofegjenopprettingsstrategi. For å gjenopprette SQL-databaser, se SQL-databasedelen .

• Gjenopprette planmetadata: Hvert planelement er knyttet til en __fabric_plan_sys database som lagrer metadata for planleggingsfunksjoner, inkludert kommentarer, scenarioer, datainndata og tilbakeskrivingskonfigurasjon. Den __fabric_plan_sys databasen gjenopprettes ikke automatisk og må eksplisitt gjenopprettes.

• Gjenopprette writeback-databaser: Hvis planen din bruker SQL-writeback-destinasjoner, må du også gjenopprette de tilknyttede databasene manuelt. Konfigurerte SQL-writeback-destinasjoner gjenopprettes ikke automatisk.

• Gjenopprettingstabeller brukt i PowerTable: Alle tabeller laget ved bruk av PowerTable lagres i en SQL-database i Fabric. Du må også gjenopprette disse tabellene under DR.

Operasjonsagenter

Brukere av operasjonsagenter bør ta proaktive grep for å forberede seg på regional katastrofegjenoppretting. Å følge tilnærmingen beskrevet i dette avsnittet bidrar til å sikre at agentene dine raskt kan gjenopprettes etter et regionalt driftsavbrudd.

Bruk Fabric Git-integrasjon for å synkronisere arbeidsområdet ditt med et repository. Denne tilnærmingen gjør det mulig å rekonstruere agentkonfigurasjoner i et nytt arbeidsområde hvis tjenesten går over til en annen region.

Operasjonsagenter i primærregionen er ikke tilgjengelige under en regional katastrofe. Agentkonfigurasjoner, atferdsmodeller og aktivitetslogger blir ikke replikert til sekundærområdet. Pågående operasjoner, aktive chat-økter og tidligere inntatte hendelser på tidspunktet for katastrofen går også tapt.

For å forberede gjenoppretting, konfigurere Fabric Git-integrasjon og synkroniser agentelementene dine med ADO-repositoriet før en katastrofe inntreffer.

Når du gjenoppretter, sett opp din nye region og kapasitet i Fabric, og bruk deretter det synkroniserte repositoriet for å gjenopprette agentkonfigurasjoner i et nytt arbeidsområde. Git Sync henter det lagrede innholdet fra repositoriet inn i det tomme arbeidsområdet, og gjenskaper agent-elementene dine.

Når konfigurasjonene er gjenopprettet, bekreft at eventuelle refererte Eventhouse (KQL)-databaser eller regionsspesifikke datakilder er tilgjengelige i den nye regionen. Oppdater endepunktreferanser i agentkonfigurasjoner etter behov. Til slutt, start agentene dine på nytt og la brukerne starte nye chat-økter. Tidligere samtaler kan ikke gjenopptas.

Databases

Denne guiden beskriver gjenopprettingsprosedyrene for databasens erfaring.

SQL-database

For å beskytte mot en regional feil kan brukere av SQL-databaser iverksette proaktive tiltak for å eksportere dataene sine med jevne mellomrom og bruke de eksporterte dataene til å opprette databasen på nytt i et nytt arbeidsområde når det er nødvendig.

Bruk SqlPackage CLI-verktøyet som gir databaseportabilitet og legger til rette for databasedistribusjon.

1. Bruk SqlPackage-verktøyet til å eksportere databasen til en .bacpac fil. Se Eksportere en database med SqlPackage hvis du vil ha mer informasjon.
2. Lagre .bacpac filen på et sikkert sted som er i en annen region enn databasen. Eksempler inkluderer lagring av .bacpac filen i en Lakehouse i en annen region, bruk av en geo-redundant Azure Storage-konto, eller bruk av et annet sikkert lagringsmedium i en annen region.
3. Hvis SQL-databasen og området ikke er tilgjengelig, kan du bruke .bacpac filen med SqlPackage til å opprette databasen på nytt i et arbeidsområde i et nytt område – arbeidsområde C2. W2 i region B som beskrevet i scenariet ovenfor. Følg fremgangsmåten som er beskrevet i Importere en database med SqlPackage for å opprette databasen på nytt med .bacpac filen.

Den gjenskapte databasen er en uavhengig database fra den opprinnelige databasen og gjenspeiler tilstanden til dataene på tidspunktet for eksportoperasjonen.

Hensyn til failback

Den gjenskapte databasen er en uavhengig database. Data lagt til i den gjenskapte databasen ville ikke bli reflektert i den opprinnelige databasen. Hvis du planlegger å gå tilbake til den opprinnelige databasen når hjemmeregionen blir tilgjengelig, må du vurdere å manuelt avstemme data fra den gjenskapte databasen til den opprinnelige databasen.

Plattform

Plattform refererer til de underliggende delte tjenestene og arkitekturen som gjelder for alle arbeidsbelastninger. Denne delen beskriver gjenopprettingsprosedyrer for delte Fabric-kapabiliteter.

Overvåking av arbeidsområde

Overvåking av arbeidsområdet samler logger om aktivitet i arbeidsområdet der du aktiverer det. Etter at du har gjenopprettet arbeidsområdet ditt som C2. W2, aktiver arbeidsområdeovervåking på W2. Den begynner å samle inn overvåkingsdata for det gjenopprettede arbeidsområdet.

Overvåkingsdata fra det opprinnelige arbeidsområdet (C1. W1) overføres ikke, fordi overvåking reflekterer aktiviteten i arbeidsområdet den kjører på.

Variabelt bibliotek

Microsoft Fabric Variable-biblioteker gjør det mulig for utviklere å tilpasse og dele elementkonfigurasjoner i et arbeidsområde, noe som effektiviserer innholdslivssyklusen. Fra et nødgjenopprettingssynspunkt må brukere av variable biblioteker proaktivt beskytte mot en regional katastrofe. Denne beskyttelsen kan gjøres gjennom Fabric Git-integrasjon, som sikrer at etter en regional katastrofe forblir brukerens Variable-bibliotek tilgjengelig. For å gjenopprette et variabelbibliotek, følg disse stegene:

• Bruk Fabric Git-integrasjon for å synkronisere Variable-biblioteket ditt med ADO-repoet. I tilfelle katastrofe kan du bruke repositoriet til å gjenoppbygge variabelbiblioteket i det nye arbeidsområdet du opprettet. Bruk følgende fremgangsmåte:

  1. Koble arbeidsområdet til Git-repositoriet som beskrevet her.
  2. Sørg for å holde WS og repositoriet synkronisert med Commit and Update.
  3. Gjenoppretting – I tilfelle katastrofe kan du bruke repositoriet til å gjenoppbygge variabelbiblioteket i et nytt arbeidsområde:

• I det nyopprettede arbeidsområdet, koble til og synkroniser til Azure ADO-repoet ditt igjen.

• Alle Fabric-elementer i dette arkivet lastes automatisk ned til ditt nye arbeidsområde.

• Når du har synkronisert elementene fra Git, åpner du variabelbibliotekene i det nye arbeidsområdet og velger ønsket aktivt verdisett manuelt.

Utplasseringsplan

En deployeringsplan er et element i et Fabric-arbeidsområde. Den grupperer gjenstander og setter rekkefølgen for å deployere dem. Den kan utføre handlinger før eller etter at hver gjenstand deployeres. Varedefinisjonen lagrer disse innstillingene, inputene og gjenstandsreferansene. Planen har ikke en egen lagring for verdier brukt under kjøring.

Forbered deg på gjenoppretting ved å bruke Fabric Git-integrasjon:

1. Koble arbeidsområdet som inneholder planen til et Azure DevOps- eller GitHub-arkiv.
2. Committer planen og alle arbeidsplass-elementer den bruker.
3. Commit hver endring slik at Git har de nyeste definisjonene.

Etter en regional katastrofe:

1. Lag et arbeidsområde i det sunne området.
2. Koble arbeidsområdet til samme repository og gren.
3. Oppdater arbeidsområdet fra Git. Dette steget gjenoppretter planen og dens gjenstander.

Git gjenoppretter den fullstendige plandefinisjonen. Den gjenoppretter ikke data eller kjører tilstanden for de tilknyttede elementene. Bruk seksjonene i denne artikkelen for å gjenopprette disse elementene.

Kundestyrte nøkler for Fabric-arbeidsområder

Du kan bruke kundestyrte nøkler (CMK) lagret i Azure Key Vault for å legge til et ekstra lag med kryptering oppå Microsoft-administrerte nøkler for data i hvile. Hvis Fabric blir utilgjengelig eller ubrukelig i et område, går komponentene over til en backup-instans. Under failover støtter CMK-funksjonen skrivebeskyttede operasjoner. Så lenge Azure Key Vault-tjenesten forblir frisk og tillatelsene til hvelvet er intakte, fortsetter Fabric å koble til nøkkelen din og lar deg lese data normalt. Dette betyr at følgende operasjoner ikke støttes under failover: aktivering og deaktivering av CMK-innstillingen for arbeidsområdet og oppdatering av nøkkelen.

Fabric Migration Assistant for SQL-databaser i Fabric

Fabric Migration Assistant kan flytte en SQL Server-database til en SQL-database i Fabric i tre trinn: migreringsveiviseren oppretter måldatabasen og starter migreringen, migreringsmonitoren sporer fremdriften mens skjemaet distribueres fra en DACPAC, Migration Assistant hjelper deg med å gjennomgå og rette skriptfeil, forberede databasen, kopiere data med en kopijobb og fullføre kopieringen.

Migrasjonsfremdriften kopieres ikke til en annen region, og en avbrutt distribusjon kan ikke gjenopptas. Disse feilene påvirker ikke kilde-SQL Server-databasen, så du kan kjøre migreringsassistenten på nytt. Hvis den opprinnelige regionen ikke er tilgjengelig, følg først den generelle gjenopprettingsplanen i denne artikkelen for å opprette kapasitet C2 og arbeidsområde W2 i den parrede regionen, og kjør deretter migreringen i W2. Hvis den opprinnelige regionen gjenopprettes, kan du prøve migreringen på nytt i det opprinnelige arbeidsområdet.

En regional forstyrrelse kan føre til at en migrasjon mislykkes på tre måter:

• Måldatabasen blir ikke opprettet

  Hvis Fabric ikke kan opprette måldatabasen, viser migreringsveiviseren en feil og migreringen starter ikke. Velg Start migrering for å prøve på nytt, eller prøv igjen senere.

  Trollmannen forsøker å fjerne en ufullstendig database, men opprydding kan mislykkes under en forstyrrelse. Før du prøver på nytt, sjekk arbeidsområdet for en database med målnavn. Bekreft at det er den ufullstendige databasen fra det mislykkede forsøket før du sletter den.

• Utplasseringen mislykkes

  Hvis utrullingen avbrytes, slutter migreringsmonitoren å rapportere fremdrift, åpner måldatabasen og viser en dialog som indikerer at utrullingen mislyktes. Du kan ikke gjenoppta en mislykket distribusjon, og databasen som ble opprettet av forsøket forblir i arbeidsområdet.

  For å komme seg:

  1. Bekreft at Fabric er tilgjengelig og at du har DACPAC-en brukt for den opprinnelige migreringen.
  2. Identifiser databasen som ble opprettet av det mislykkede forsøket. Slett den hvis den ikke inneholder noe du trenger å beholde. Ellers, behold den og bruk et annet navn på den nye databasen.
  3. Kjør en ny migrering fra kilde-DACPAC. Migreringen oppretter en ny database.

  Data kopieres av en kopijobb i Data Factory. Hvis du synkroniserte kopijobben med Git før avbruddet, se Copy Job i Data Factory-veiledningen. Ellers, opprett en ny kopijobb som en del av den nye migreringen.

• Migrasjonshistorikken laster ikke inn

  Hvis Migration Assistant ikke klarer å hente migreringshistorikken, rapporterer den at migreringsinformasjon ikke lenger er tilgjengelig. Fremdriften lagret i den nåværende nettleseren bevares, og måldatabasen påvirkes ikke. Oppdater siden for å laste inn migreringshistorikken på nytt.

OneLake

Denne delen tar deg gjennom gjenopprettingsprosedyrene for OneLake-funksjoner. For mer informasjon om katastrofegjenoppretting for OneLake-data, se OneLake katastrofegjenoppretting.

Policyer for livssyklusbehandling

Hvis Fabric blir utilgjengelig eller ubrukelig i en region, kan du fortsatt lese og oppdatere din LifeLake-livssykluspolicy under failover. All data som flyttes til kjøle- eller kald-tier forblir i det nivået. For å anvende din eksisterende policy på ditt nye gjenopprettingsarbeidsområde, følg disse stegene:

1. Kall Eksportpolicy på ditt opprinnelige arbeidsområde og lagre hele livssykluspolicyen.
2. Kall Import Policy på ditt gjenopprettede arbeidsområde, med din eksportør-livssykluspolicy som forespørselsorgan.

Ressursinstansregler

Ressursinstansregler hjelper deg med å sikre tilgang til data i OneLake ved å bruke pålitelige Azure-ressursidentiteter. Under regional failover fortsetter systemet å håndheve eksisterende regler for lesetilgang. Du kan imidlertid ikke opprette, oppdatere eller slette ressursinstansregler før arbeidsområdet går tilbake til en skrivbar tilstand.

Beslektet informasjon

• Microsoft Fabric katastrofegjenopprettingsguide