Erfaringsspecifik vejledning til it-katastrofeberedskab

Dette dokument giver erfaringsspecifik vejledning til at gendanne dine Fabric-data i tilfælde af en regional katastrofe.

Eksempelscenarie

Mange vejledningsafsnit i dette dokument bruger følgende eksempelscenarie til forklaring og illustration. Vend tilbage til dette scenarie efter behov.

Lad os antage, at du har en kapacitet C1 i område A, der har et arbejdsområde W1. Hvis du har aktiveret katastrofeberedskab for kapacitet C1, bliver OneLake-data replikeret til en backup i region B. Hvis region A oplever forstyrrelser, skifter Fabric-tjenesten i C1 til region B.

Bemærk

Denne genopretningsvejledning gælder kun, når den primære region har en Azure-parret sekundær region, og Fabric understøttes i den parrede region.

Følgende billede illustrerer dette scenarie. Feltet til venstre viser det afbrudte område. Feltet i midten repræsenterer den fortsatte tilgængelighed af dataene efter failover, og feltet til højre viser den fuldt dækkede situation, efter at kunden har handlet for at gendanne deres tjenester til fuld funktion.

Diagram, der viser et scenarie for katastrofe, failover og fuld genoprettelse.

Her er den generelle genopretningsplan:

  1. Opret en ny Fabric-kapacitet C2 i et nyt område.

  2. Opret et nyt W2-arbejdsområde i C2, herunder de tilsvarende elementer med samme navne som i C1. W1.

  3. Kopiér data fra det afbrudte C1. W1 til C2. W2.

  4. Følg de dedikerede instruktioner for hver komponent for at gendanne elementer til deres fulde funktion.

Denne genopretningsplan antager, at lejeboligområdet forbliver operationelt. Hvis lejerens hjemregion oplever et nedbrud, er de trin, der er beskrevet i dette dokument, afhængige af gendannelsen, som først skal igangsættes og gennemføres af Microsoft.

Erfaringsspecifikke genopretningsplaner

De følgende afsnit giver trin-for-trin vejledninger for hver Fabric-oplevelse for at hjælpe kunderne gennem genvindingsprocessen.

Data Engineering

Denne vejledning fører dig gennem inddrivelsesprocedurerne for Dataudvikler oplevelsen. Den dækker lakehouses, notebooks, Spark-jobdefinitioner, brugerdatafunktioner og GraphQL API'er.

Lakehouse

Lakehouses fra det oprindelige område er ikke tilgængelige for kunder. Kunderne kan genoprette et lakehouse i arbejdsområde C2. W2. Vi anbefaler to metoder til at genoprette lakehouses:

Tilgang 1: Brug af brugerdefineret script til at kopiere Lakehouse Delta-tabeller og -filer

Kunder kan genoprette lakehouses ved hjælp af et brugerdefineret Scala-script.

  1. Opret lakehouse (f.eks. LH1) i det netop oprettede arbejdsområde C2. W2.

  2. Opret en ny notesbog i arbejdsområdet C2. W2.

  3. For at gendanne tabellerne og filerne fra det oprindelige lakehouse, henvis til dataene med OneLake-stier såsom abfss (se Connecting to Microsoft OneLake). Du kan bruge følgende kodeeksempel (se Introduktion til Microsoft Spark Utilities) i notesbogen til at få ABFS-stierne for filer og tabeller fra det oprindelige lakehouse. (Erstat C1. W1 med det faktiske navn på arbejdsområdet)

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

  4. Brug følgende kodeeksempel til at kopiere tabeller og filer til det nyoprettede lakehouse.

    1. For Delta-tabeller skal du kopiere tabel et ad gangen for at gendanne i det nye lakehouse. I tilfælde af Lakehouse-filer kan du kopiere den komplette filstruktur med alle de underliggende mapper med en enkelt udførelse.

    2. Kontakt supportteamet for at få det tidsstempel for failover, der kræves i scriptet.

    %%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 kørt scriptet, vises tabellerne i det nye søhus.

Tilgang 2: Brug Azure Storage Explorer til at kopiere filer og tabeller

For kun at gendanne specifikke Lakehouse-filer eller tabeller fra det oprindelige Lakehouse, brug Azure Storage Explorer. Se Integrér OneLake med Azure Storage Explorer for detaljerede trin. I forbindelse med store datastørrelser skal du bruge Tilgang 1.

Bemærk

De to metoder, der er beskrevet ovenfor, gendanner både metadataene og dataene for Delta-formaterede tabeller, fordi metadataene er placeret samtidig og gemt sammen med dataene i OneLake. For tabeller uden Delta-formater (f.eks. CSV, Parquet osv.), der oprettes ved hjælp af DDL-scripts/-kommandoer (Spark Data Definition Language), er brugeren ansvarlig for at vedligeholde og køre Spark DDL-scripts/-kommandoer igen for at gendanne dem.

At genvinde Fabric materialiserede søudsigter

Materialiserede Lake Views fra den oprindelige region forbliver utilgængelige for kunder efter failover. Opdateringsplaner og eksekveringshistorik bliver ikke replikeret til den sekundære region. For at gendanne dem skal du udføre følgende trin, efter du har gendannet dine Lakehouse-data.

  • Genfind Lakehouse-tabellerne ved at bruge Approach 1 eller Approach 2 beskrevet ovenfor. Kopier kun kildetabellerne.
  • Genopfrisk de notesbøger, der indeholder dine MLV-definitioner. Se afsnittet Notesbog for restitutionstrin.
  • Kør de genvundne notesbøger for at genskabe MLV'erne i det nye Lakehouse. For information om at skabe MLV'er, se Create a Materialized Lake View. Hvis MLV'er også blev kopieret i det tidligere trin, kør CREATE OR REPLACE mens du genskaber dem.
  • Genskab MLV-opdateringsskemaerne manuelt i det nye arbejdsområde. Tidsplanhistorik og udførelsesmålinger kan ikke gendannes.
  • Hvis dine MLV'er leverer semantiske modeller eller rapporter, så verificér og opdater Lakehouse ID og datasæt-ID-referencer efter behov. Genforbind rapporter til den opdaterede semantiske model og valider dataens friskhed.

Tips

For at minimere kodeændringer ved kørsel af notebooks efter failover, brug de samme workspace- og Lakehouse-navne i den nye region (især når du bruger Workspace- eller Lakehouse-navnet i navngivningskonventionerne). Opdateringsplanerne, udførelseshistorikken og de operationelle målinger starter forfra i det genvundne område. Planlæg for en baseline-periode, når du fastsætter nye overvågningstærskler.

Notesbog

Notesbøger fra det primære område forbliver utilgængelige for kunderne, og koden i notesbøger replikeres ikke til det sekundære område. Hvis du vil gendanne notesbogkoden i det nye område, er der to metoder til at gendanne kodeindholdet i notesbogen.

Tilgang 1: Brugeradministrerede redundanser med Git-integration (i offentlig prøveversion)

Den bedste måde at gøre det nemt og hurtigt på er at bruge Fabric Git-integrationen og derefter synkronisere din notesbog med dit ADO-repo. Når tjenesten mislykkes til et andet område, kan du bruge lageret til at genopbygge notesbogen i det nye arbejdsområde, du har oprettet.

  1. Konfigurer Git Integration for dit arbejdsområde, og vælg Opret forbindelse, og synkroniser med ADO-lager.

    Skærmbillede, der viser, hvordan du opretter forbindelse til og synkroniserer notesbog med ADO-lager.

    På følgende billede vises den synkroniserede notesbog.

    Skærmbillede, der viser notesbogen, der er synkroniseret med ADO-lager.

  2. Gendan notesbogen fra ADO-lageret.

    1. I det nyoprettede arbejdsområde skal du igen oprette forbindelse til dit Azure ADO-repo.

      Skærmbillede, der viser, at notesbogen er genoprettet til ADO-lageret.

    2. Vælg knappen Kildekontrolelement. Vælg derefter den relevante forgrening af lageret. Vælg derefter Opdater alle. Den originale notesbog vises.

      Skærmbillede, der viser, hvordan du opdaterer alle notesbøger i en forgrening.

      Skærmbillede, der viser den oprindelige note, der er genoprettet.

    3. Hvis den oprindelige notesbog har et standard lakehouse, kan brugerne se afsnittet Lakehouse for at gendanne lakehouse og derefter forbinde det nyligt genoprettede lakehouse med den nyligt genoprettede notesbog.

      Skærmbillede, der viser, hvordan du forbinder et gendannet lakehouse til en gendannet notesbog.

    4. Git-integrationen understøtter ikke synkronisering af filer, mapper eller snapshots af notesbøger i notesbogressourceoversigten.

      1. Hvis den oprindelige notesbog indeholder filer i notesbogressourceoversigten:

        1. Sørg for at gemme filer eller mapper på en lokal disk eller et andet sted.

        2. Upload filen igen fra dine lokale disk- eller clouddrev til den gendannede notesbog.

      2. Hvis den oprindelige notesbog har et snapshot af notesbogen, skal du også gemme snapshottet af notesbogen i dit eget versionskontrolsystem eller på din lokale disk.

        Skærmbillede, der viser, hvordan du kører notesbogen for at gemme snapshots.

        Skærmbillede, der viser, hvordan du gemmer snapshots af notesbogen.

Du kan få flere oplysninger om Git-integration under Introduktion til Git-integration.

Fremgangsmåde 2: Manuel metode til sikkerhedskopiering af kodeindhold

Hvis du ikke bruger Git-integrationstilgangen, kan du gemme den nyeste version af din kode, filer i Ressourceoversigt og snapshot af notesbogen i et versionskontrolsystem, f.eks. Git, og manuelt gendanne notesbogindholdet efter en katastrofe:

  1. Brug funktionen "Importér notesbog" til at importere den notesbogkode, du vil gendanne.

    Skærmbillede, der viser, hvordan du importerer notesbogkode.

  2. Når du har importeret, skal du gå til det ønskede arbejdsområde (f.eks. "C2. W2") for at få adgang til den.

  3. Hvis den oprindelige notesbog har et standard lakehouse, skal du se afsnittet Lakehouse. Forbind derefter det nyoprettede lakehouse (der har det samme indhold som det oprindelige standard lakehouse) til den nyligt gendannede notesbog.

  4. Hvis den oprindelige notesbog indeholder filer eller mapper i ressourceoversigten, skal du overføre de filer eller mapper, der er gemt i brugerens versionskontrolsystem, igen.

Definition af Spark-job

Spark-jobdefinitioner (SJD) fra det primære område forbliver utilgængelige for kunder, og hoveddefinitionsfilen og referencefilen i notesbogen replikeres til det sekundære område via OneLake. Hvis du vil gendanne SJD i det nye område, kan du følge de manuelle trin, der er beskrevet nedenfor, for at gendanne SJD. Historiske serier af SJD vil ikke blive genfundet.

Du kan gendanne SJD-elementerne ved at kopiere koden fra den oprindelige region ved hjælp af Azure Storage Explorer og manuelt genoprette Lakehouse-referencerne efter katastrofen.

  1. Opret et nyt SJD-element (f.eks. SJD1) i det nye arbejdsområde C2. W2 med de samme indstillinger og konfigurationer som det oprindelige SJD-element (f.eks. sprog, miljø osv.).

  2. Brug Azure Storage Explorer til at kopiere biblioteker, mains og snapshots fra det oprindelige SJD-element til det nye SJD-element.

    Skærmbillede, der viser, hvordan du kopierer fra definitionen af det oprindelige sparkjob til definitionen af det nye sparkjob.

  3. Kodeindholdet vises i den nyoprettede SJD. Du skal manuelt tilføje den nyligt genoprettede Lakehouse-reference til jobbet (Se trinnene til gendannelse i Lakehouse). Brugerne skal angive de oprindelige kommandolinjeargumenter manuelt.

    Skærmbillede, der viser kommandolinjeargumenter til gendannelse af definitionen af sparkjob.

Nu kan du køre eller planlægge din nyligt gendannede SJD.

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

Brugerdata funktioner

For at gendanne dine brugerdatafunktioner i et sundt område, brug en af følgende metoder.

Den foretrukne genopretningsmekanisme er Fabric Git-integration. Ved at synkronisere brugerdatafunktionsprojekter med et Azure DevOps- eller GitHub-repository kan du hurtigt rekonstruere dem i et nyt arbejdsområde efter failover.

Forbered dig på en katastrofe
  1. Konfigurer Fabric Git-integration for det arbejdsområde, der huser brugerdatafunktionen.
  2. Forbind arbejdsområdet til et Azure DevOps- eller GitHub-repository.
  3. Commit alle brugerdatafunktioner i repositoryet og synkroniser ændringer regelmæssigt.
  4. Gem miljøspecifikke indstillinger separat i variable biblioteker, hvis det er nødvendigt.
Genopretningstrin

Efter en regional katastrofe:

  1. Skab en ny Fabric-kapacitet i et sundt område, såsom C2.
  2. Opret et nyt arbejdsområde, såsom W2, i den nye kapacitet.
  3. Forbind arbejdsområdet til det samme Azure DevOps- eller GitHub-repository.
  4. Open Source-kontrol og synkroniser indholdet af repositoryet til arbejdsområdet.
  5. Genskab eller genskab alle afhængige Fabric-ressourcer, såsom lakehouses, SQL-databaser i Fabric, lagre og Business Events.
  6. Omdeploy brugerdatafunktionerne.
  7. Valider funktionsudførelse og afhængighedsforbindelser.
  8. Opdater downstream-applikationer, datapipelines eller andre integrerede systemer for at referere til de genvundne funktioner.
  9. Fuldstændig end-to-end validering af alle dine scenarier.
Vigtige overvejelser
  • Git-integration gendanner kun kildekode og projektassets.
  • Historiske henrettelseslogbøger bliver ikke genoprettet.
  • Downstream-systemer kan kræve endepunkts-rebinding.

For mere information, se User data functions kildekontrol og implementering.

Tilgang 2: Manuel genopretning

Hvis Git-integration ikke var konfigureret før katastrofen, kan du manuelt rekonstruere brugerdatafunktioner ud fra kildekodebackups.

Forbered dig på en katastrofe

Udfør regelmæssigt følgende opgaver og gem artefakterne i et eksternt versionsstyringsrepository eller backup-lokation:

  • Eksporter funktionskildekoden til et GitHub-repository.
  • Dokumentér og bevar afhængighedsoplysninger.
  • Dokumentmiljøindstillinger.
Genopretningstrin

Efter en regional katastrofe:

  1. Skab en ny Fabric-kapacitet i et sundt område, såsom C2.
  2. Opret et nyt arbejdsområde, såsom W2.
  3. Genopret alle ressourcer, der kræves af funktionen, herunder lakehouses, SQL-databaser i Fabric, lagre, eventhouses og eksterne tjenester.
  4. Opret et nyt projekt med brugerdata-funktionen.
  5. Importer eller genskab funktionens kildekode.
  6. Genanvend runtime-konfigurationsindstillinger.
  7. Geninstaller alle funktionsafhængigheder.
  8. Omplacer funktionen.
  9. Genkonfigurer autentificering og autorisation.
  10. Genskab Business Event-udgivere eller forbrugere, hvis det bruges.
  11. Gennemfør end-to-end valideringstest for dine scenarier og integrationer.

GraphQL

GraphQL-elementer fra den primære region er ikke tilgængelige efter en regional katastrofe, og GraphQL-definitioner og konfigurationer bliver ikke replikeret til den sekundære region. For at gendanne GraphQL i et nyt område, brug en af følgende tilgange.

Tilgang 1: Brugerstyret redundans med Git-integration

Den bedste måde at gøre denne proces nem og hurtig på er at bruge Fabric Git-integration og derefter synkronisere din GraphQL med dit ADO-repo. Efter tjenesten er skiftet til en anden region, kan du bruge repoet til at genopbygge GraphQL i det nye arbejdsområde, du har oprettet.

  1. Opret et nyt arbejdsområde i målkapaciteten og -regionen.

  2. Genopret alle afhængige datakilder, såsom Lakehouse-, Warehouse- eller SQL-databaser, ved at følge deres respektive gendannelsestrin.

  3. Opdater GraphQL-definitionen til at pege på de nyligt genvundne ressourcer ved at ændre miljøspecifikke referencer såsom kildearbejdsområde-ID'er, kildeartefakt-ID'er og forbindelsesdetaljer. Dette trin sikrer korrekt binding ved udrulning.

  4. Udrul GraphQL-artefakter fra Git-repositoriet til det nye arbejdsområde. Dette trin genskaber API-strukturen og konfigurationen ved at bruge de opdaterede definitioner.

  5. Genanvend artefaktindstillinger, herunder roller, adgangskontroller og autentificeringskonfiguration.

  6. Genanvend endpoint-referencer ved at opdatere applikationer eller integrationer til at bruge det nyoprettede GraphQL-endpoint.

  7. Opdater eventuelle eksisterende deployment-pipelines, der pegede på det gamle arbejdsområde, for at referere til det nyoprettede arbejdsområde.

  8. Valider API'ens end-to-end funktionalitet.

Tilgang 2: Manuel tilgang

Hvis du ikke vælger Git-integrationsmetoden, kan du bruge følgende manuelle tilgang til at gendanne GraphQL.

  1. Opret et nyt arbejdsområde i målkapaciteten og -regionen.

  2. Genopret alle afhængige datakilder, såsom Lakehouse, Warehouse eller SQL-databaser.

  3. Genskab GraphQL API'et manuelt i det nye arbejdsområde, inklusive skema-definitioner, datakildeforbindelser og relationer.

  4. Genanvend artefaktindstillinger, herunder roller, adgangskontroller og autentificeringskonfiguration.

  5. Genanvend endpoint-referencer ved at opdatere applikationer eller integrationer til at bruge det nyoprettede GraphQL-endpoint.

  6. Opdater eventuelle eksisterende deployment-pipelines, der pegede på det gamle arbejdsområde, for at referere til det nyoprettede arbejdsområde.

  7. Valider API'ens end-to-end funktionalitet.

Vigtige overvejelser

  1. GraphQL er afhængig af eksterne afhængigheder (såsom Lakehouse, Warehouse og SQL), som du skal gendanne, før du implementerer GraphQL.

  2. GraphQL API-definitioner inkluderer miljøspecifikke referencer (såsom sourceWorkspaceId og sourceItemId). Når man kommer sig i en ny region, kan disse referencer blive ugyldige. Opdater dem til at pege på nyligt provisionerede ressourcer.

  3. Automatisk genbinding af datakilder er ikke garanteret i katastrofeberedskabsscenarier, især når man bruger gemte legitimationsoplysninger eller tværgående arbejdsområder.

  4. Andre artefaktindstillinger som overvågning, autorisation, RBAC, introspektion og mere overføres ikke efter failover. Du skal genoprette disse indstillinger i den nye region.

Referencer

App

Systemet replikerer ikke Fabric Apps, inklusive deres kode, konfiguration og metadata, til sekundære regioner. Hvis primærregionen fejler, forbliver appen utilgængelig. For gendannelse gemmer du appens kildekode uden for systemet i GitHub, Azure DevOps eller et andet versionsstyringssystem. Genopret appdata separat ved at følge katastrofegendannelsesvejledningen for hver underliggende Fabric-datalager.

Manuel tilgang

Du kan manuelt gendanne en Fabric App efter en regional katastrofe ved at bruge applikationens kildekode og Rayfin CLI. 

Forudsætninger 

Før en katastrofe indtræffer:

  • Gem Fabric App-kildekoden i GitHub, Azure DevOps eller et andet versionsstyringsarkiv. 

  • Dokumentér processen for genopretning.  

Genopretningstrin 

  1. Opret et nyt arbejdsområde i målkapaciteten og -regionen. 

  2. Genopret afhængige ressourcer, før du genudruler applikationen.  

  3. Hent den nyeste Fabric App-kildekode fra dit versionsstyringsarkiv eller lokale backup. 

  4. Fra applikationskildemappen deployerer du Fabric App til recovery-arbejdsområdet ved at bruge Rayfin CLI. Kør rayfin up --workspace <new workspace>. 

  5. Genopret appens underliggende element (Fabric SQL Database) ved at følge de respektive gendannelsesprocedurer.  

  6. Genanvend artefaktniveau-indstillinger, inklusive roller og adgangskontroller efter behov.  

  7. Valider applikationens funktionalitet og sørg for, at brugerne har de rette tilladelser.  

Vigtigt 

  • Oprethold Fabric App-kildekoden uden for Fabric-regionen for at muliggøre gendannelse.  

  • Applikationsdata i databasen gendannes ikke som en del af Fabric App-udrulningsprocessen og skal gendannes separat.  Du kan manuelt gendanne en Fabric App efter en regional katastrofe ved at bruge applikationens kildekode og Rayfin CLI. 

Datavidenskab

Denne vejledning fører dig gennem genoprettelsesprocedurerne for datavidenskabsoplevelsen. Den dækker modeller og eksperimenter i forbindelse med maskinel indlæring.

ML-model og eksperiment

Data Science-elementer fra det primære område forbliver utilgængelige for kunder, og indholdet og metadataene i ML-modeller og -eksperimenter replikeres ikke til det sekundære område. Hvis du vil gendanne dem fuldt ud i det nye område, skal du gemme kodeindholdet i et versionskontrolsystem (f.eks. Git) og køre kodeindholdet manuelt efter katastrofen.

  1. Gendan notesbogen. Se gendannelsestrinnene for notesbogen.

  2. Konfiguration, kørsel af historiske målepunkter og metadata replikeres ikke til det parrede område. Du skal køre hver version af din datavidenskabskode igen for at genoprette ML-modeller og eksperimenter fuldt ud efter katastrofen.

data warehouse

Denne guide guider dig gennem gendannelsesprocedurerne for data warehouse-oplevelsen. Det dækker varehuse.

Lagersted

Lagre fra det oprindelige område forbliver ikke tilgængelige for kunder. Hvis du vil gendanne lagre, skal du bruge følgende to trin.

  1. Opret et nyt midlertidigt lakehouse i arbejdsområde C2. W2 for de data, du kopierer fra det oprindelige lager.

  2. Fyld lagerets Delta-tabeller ved at udnytte warehouse Explorer og T-SQL-funktionerne (se Tables i data warehousing i Microsoft Fabric).

Bemærk

Det anbefales, at du bevarer versionen og lagringen af din Warehouse-kode (skema, tabel, visning, lagret procedure, funktionsdefinitioner og sikkerhedskoder) på et sikkert sted (f.eks. Git) i henhold til dine udviklingspraksisser.

Dataindtagelse via Lakehouse- og T-SQL-kode

I arbejdsområde C2, der netop er oprettet. W2:

  1. Opret et midlertidigt lakehouse "LH2" i C2. W2.

  2. Gendan Delta-tabellerne i det midlertidige lakehouse fra det oprindelige lager ved at følge trinnene til gendannelse af Lakehouse.

  3. Opret et nyt lager "WH2" i C2. W2.

  4. Forbind det midlertidige lakehouse i din lageroversigt.

  5. Afhængigt af hvordan du installerer tabeldefinitioner før dataimport, kan den faktiske T-SQL, der bruges til import, variere. Du kan bruge METODEN INSERT INTO, SELECT INTO eller CREATE TABLE AS SELECT til at gendanne lagertabeller fra lakehouses. Længere i eksemplet bruger vi INSERT INTO flavor. (Hvis du bruger nedenstående kode, skal du erstatte eksempler med faktiske tabel- og kolonnenavne)

    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. Til sidst skal du ændre forbindelsesstreng i applikationer, der bruger dit Fabric-lager.

Bemærk

For kunder, der har brug for tværregional katastrofeberedskab og fuldt automatiseret forretningskontinuitet, anbefaler vi at holde to Fabric Warehouse-opsætninger i separate Fabric-regioner og opretholde kode- og dataparitet ved regelmæssige udrulninger og dataindlæsning til begge steder.

Spejlet database

Spejlede databaser fra det primære område forbliver ikke tilgængelige for kunder, og indstillingerne replikeres ikke til det sekundære område. Hvis du vil gendanne den i tilfælde af en regional fejl, skal du genoprette den spejlede database i et andet arbejdsområde fra et andet område.

Data Factory

Data Factory-elementer fra det primære område forbliver utilgængelige for kunderne, og indstillingerne og konfigurationen i pipelines eller dataflow gen2-elementer replikeres ikke til det sekundære område. Hvis du vil gendanne disse elementer i tilfælde af en regional fejl, skal du genoprette dine dataintegrationselementer i et andet arbejdsområde fra et andet område. I følgende afsnit beskrives detaljerne.

Dataflow Gen2

Hvis du vil gendanne et Dataflow Gen2-element i det nye område, skal du eksportere en PQT-fil til et versionskontrolsystem, f.eks. Git, og derefter manuelt gendanne indholdet af Dataflow Gen2 efter katastrofen.

  1. Fra dit Dataflow Gen2-element, vælg Export template i fanen Hjem i Power Query editoren.

    Skærmbillede viser Power Query-editoren, med eksportskabelonen fremhævet.

  2. I dialogboksen Eksportér skabelon skal du angive et navn (obligatorisk) og en beskrivelse (valgfrit) for denne skabelon. Når du er færdig, skal du vælge OK.

    Skærmbillede, der viser, hvordan du eksporterer en skabelon.

  3. Efter katastrofen skal du oprette et nyt Dataflow Gen2-element i det nye arbejdsområde "C2. W2".

  4. Fra det aktuelle visningspanel i Power Query-editoren vælger du Import fra en Power Query skabelon.

    Skærmbillede, der viser den aktuelle visning med Import fra en Power Query skabelon fremhævet.

  5. I dialogboksen Åbn skal du gå til standardmappen for downloads og vælge den .pqt-fil , du gemte i de forrige trin. Vælg derefter Åbn.

  6. Skabelonen importeres derefter til det nye Dataflow Gen2-element.

Funktionen Gem som dataflow understøttes ikke i tilfælde af it-katastrofeberedskab.

Pipelines

Kunder kan ikke få adgang til pipelines i tilfælde af regional katastrofe, og konfigurationerne replikeres ikke til det parrede område. Vi anbefaler, at du bygger dine kritiske pipelines i flere arbejdsområder på tværs af forskellige områder.

Kopiér job

CopyJob-brugere skal foretage proaktive foranstaltninger for at beskytte mod en regional katastrofe. Følgende fremgangsmåde sikrer, at en brugers CopyJobs forbliver tilgængelige efter en regional katastrofe.

Brugeradministrerede redundanser med Git-integration (i offentlig prøveversion)

Den bedste måde at gøre denne proces nem og hurtig på er at bruge Fabric Git-integration og derefter synkronisere din CopyJob med dit ADO-repo. Når tjenesten mislykkes til et andet område, kan du bruge lageret til at genopbygge CopyJob i det nye arbejdsområde, du har oprettet.

  1. Konfigurer Git-integration for dit arbejdsområde, og vælg oprette forbindelse til og synkronisere med ADO-lager.

    Skærmbillede, der viser, hvordan du opretter forbindelse til og synkroniserer Arbejdsområde med ADO-lager.

    På følgende billede vises det synkroniserede CopyJob.

    Skærmbillede, der viser CopyJob synkroniseret med ADO-lager.

  2. Gendan CopyJob fra ADO-lageret.

    1. I det nyoprettede arbejdsområde skal du oprette og synkronisere til dit Azure ADO-repo igen. Alle Fabric-elementer i dette repository downloades automatisk til dit nye Workspace.

      Skærmbillede, der viser Arbejdsområde, der igen har forbindelse til ADO-lager.

    2. Hvis den oprindelige CopyJob bruger en Lakehouse, kan brugerne henvise til sektionen Lakehouse for at gendanne Lakehouse og derefter forbinde det nyligt gendannede CopyJob med det nyligt gendannede Lakehouse.

Du kan få flere oplysninger om Git-integration under Introduktion til Git-integration.

Apache Airflow-job

Apache Airflow Job in Fabric-brugere skal tage proaktive skridt for at beskytte sig mod en regional katastrofe.

Vi anbefaler at håndtere redundans med Fabric Git-integration. Først skal du synkronisere dit Airflow Job med dit ADO-repo. Hvis tjenesten failover til et andet område, kan du bruge lageret til at genopbygge Airflow-jobbet i det nye arbejdsområde, du har oprettet.

Her er trinene til at opnå dette:

  1. Konfigurer dit arbejdsområdes Git-integration, og vælg "opret forbindelse og synkroniser" med ADO-lageret.

  2. Derefter vil du se, at dit Airflow-job er blevet synkroniseret med dit ADO-repo.

  3. Hvis du skal gendanne Airflow-jobbet fra ADO-repoet, skal du oprette et nyt arbejdsområde, forbinde og synkronisere med dit Azure ADO-repo igen. Alle Fabric-elementer, inklusive Airflow, i dette repository vil automatisk blive downloadet til dit nye arbejdsområde.

Intelligence i realtid

Denne vejledning fører dig gennem genoprettelsesprocedurerne for realtidsintelligensoplevelsen. Det dækker KQL-databaser/-forespørgselssæt og eventstreams.

Activator

Aktivator-elementer fra den primære region forbliver utilgængelige for kunderne, og Activator-triggerdefinitioner replikeres ikke til den sekundære region. Aktivatorbrugere skal tage proaktive skridt for at forberede sig på regional katastrofeberedskab.

For at sikre, at du kan gendanne Activator-elementer i tilfælde af en regional katastrofe, opsæt Fabric Git-integration til at tage backup af trigger-definitioner og gendanne dem i et arbejdsområde i en anden region.

  1. Konfigurer Fabric Git-integration for det arbejdsområde, der indeholder dit Activator-item, og synkroniser dine trigger-definitioner med dit Git-repository.
  2. Hold dine trigger-definitioner af Activator faste og synkroniserede regelmæssigt.
  3. Under gendannelsen oprettes et nyt arbejdsområde i målregionen (C2. W2), forbind det til det samme repository, og synkroniser for at gendanne trigger-definitionerne.
  4. Rekonfigurer og valider alle Activator-datakilder og afhængigheder i det nye arbejdsområde.

Bemærk

Den standard Fabric failover-proces gælder ikke for Activator-genstande. Gendannelse er begrænset til Git-baseret backup og gendannelse af triggerdefinitioner.

Du kan få flere oplysninger om Git-integration under Introduktion til Git-integration.

Grafmodel/forespørgselssæt

Graph Model- og Graph Queryset-elementer fra den primære region forbliver utilgængelige for kunderne, og disse elementer replikeres ikke til den sekundære region. For at gendanne, opret eller brug en kapacitet i et andet område og genskab Graph Model- og Graph Queryset-elementerne der.

  1. Opret eller brug en eksisterende Fabric-kapacitet i en anden region, som ikke er påvirket af katastrofen.

  2. Opret et nyt arbejdsområde eller brug et eksisterende arbejdsområde i den kapacitet.

  3. Genskab Graph Model-elementet i det sekundære arbejdsområde (refereret i trin 2). Rekonfigurér modeldefinitionen, inklusive noder, kanter osv., for at matche den oprindelige grafmodel.

  4. Hvis det oprindelige søhus ligger i det svigtende område, skal det først genopstå ved at følge søhusets sektion.

  5. Forbind et lakehouse som OneLake-datakilde for det nyoprettede Graph Model-element. Brug det genoprettede søhus, hvis det var i det svigtende område, eller genforbind det eksisterende søhus, hvis det stadig er tilgængeligt.

  6. Genkonfigurer eventuelle dataindlæsningsplaner eller forbindelser for grafmodellen i det nye arbejdsområde.

  7. Genskab Graph Queryset-elementet i det sekundære arbejdsområde. Indtast manuelt forespørgslerne og eventuelle gemte forespørgselskonfigurationer fra det oprindelige Graph Queryset.

KQL-database/forespørgselssæt

Brugere af KQL-database/forespørgselssæt skal foretage proaktive foranstaltninger for at beskytte mod en regional katastrofe. Følgende fremgangsmåde sikrer, at data i dine KQL-databasers forespørgselssæt forbliver sikre og tilgængelige i tilfælde af en regional katastrofe.

Brug følgende trin til at garantere en effektiv løsning til it-katastrofeberedskab for KQL-databaser og -forespørgselssæt.

  1. Etabler uafhængige KQL-databaser: Konfigurer to eller flere uafhængige KQL-databaser/forespørgselssæt på dedikerede Fabric kapaciteter. Disse bør sættes op på tværs af to forskellige Azure-regioner (helst Azure-parrede regioner) for at maksimere robustheden.

  2. Repliker administrationsaktiviteter: Alle administrationshandlinger, der udføres i én KQL-database, skal afspejles i den anden. Dette sikrer, at begge databaser forbliver synkroniserede. Nøgleaktiviteter, der skal replikeres, omfatter:

    • Tabeller: Sørg for, at tabelstrukturerne og skemadefinitionerne er ensartede på tværs af databaserne.

    • Tilknytning: Dupliker alle påkrævede tilknytninger. Sørg for, at datakilder og destinationer er justeret korrekt.

    • Politikker: Sørg for, at begge databaser har lignende dataopbevaring, adgang og andre relevante politikker.

  3. Administrer godkendelse og godkendelse: Konfigurer de påkrævede tilladelser for hver replika. Sørg for, at der er etableret korrekte godkendelsesniveauer, der giver adgang til det nødvendige personale, samtidig med at sikkerhedsstandarderne opretholdes.

  4. Parallel dataindtagelse: Hvis du vil sikre, at dataene er ensartede og klar i flere områder, skal du indlæse det samme datasæt i hver KQL-database på samme tid, som du indtager dem.

Eventstream

En eventstream er et centralt sted på Fabric-platformen til at indfange, transformere og dirigere realtidsbegivenheder til forskellige destinationer (for eksempel lakehouses, KQL-databaser/forespørgselssæt) med en no-code-oplevelse. Så længe destinationerne understøttes af it-katastrofeberedskab, mister eventstreams ikke data. Derfor bør kunderne bruge funktionerne til it-katastrofeberedskab i disse destinationssystemer til at garantere datatilgængelighed.

Kunder kan også opnå geo-redundans ved at implementere identiske Eventstream-arbejdsbelastninger i flere Azure-regioner som en del af en multi-site aktiv/aktiv strategi. Med en aktiv/aktiv tilgang til flere websteder kan kunderne få adgang til deres arbejdsbelastning i et hvilket som helst af de udrullede områder. Denne fremgangsmåde er den mest komplekse og dyre tilgang til it-katastrofeberedskab, men den kan reducere genoprettelsestiden til næsten nul i de fleste situationer. For at være fuldt geo-redundant kan kunderne

  1. Opret replikaer af deres datakilder i forskellige områder.

  2. Opret Eventstream-elementer i tilsvarende områder.

  3. Opret forbindelse mellem disse nye elementer og de identiske datakilder.

  4. Tilføj identiske destinationer for hver eventstream i forskellige områder.

Forretningsbegivenheder, Fabric Events og Azure Events

Selvom Business Events, Fabric Events og Azure Events deler den samme Real-Time hub-infrastruktur i Microsoft Fabric, har de forskellige oprindelser, adfærd og genopretningskrav, som skal forstås, før man planlægger katastrofegenopretning:

  • Fabric Events er begivenhedsabonnementer, der reagerer på aktivitet produceret af Fabric-ressourcer selv, herunder ændringer i arbejdsområdesobjekters livscyklus (såsom oprettelse, opdatering eller sletning af søhuse, notesbøger eller lagre), jobudførelser (såsom pipeline-kørsler eller notebook-udførelser) samt OneLake-fil- og mappeoperationer. Disse abonnementer er push-baserede og flygtige. Abonnementerne replikeres ikke til den sekundære region.

  • Azure Events er begivenhedsabonnementer på aktivitet produceret af Azure Blob Storage-konti. Disse Azure-ressourcer eksisterer uafhængigt af enhver Fabric-kapacitet eller -region. Selvom Azure Blob Storage-ressourcen selv kan forblive tilgængelig under et Fabric regionalt nedbrud, replikeres de abonnementer, der er konfigureret i Real-Time hub, ikke til den sekundære region og skal genskabes.

  • Business Events er en særskilt kapacitet i Fabric Real-Time Intelligence, der gør det muligt for teams at definere, offentliggøre og handle på meningsfulde forretningssignaler. Forretningsbegivenheder genereres internt Fabric via Activator, Spark-notebooks eller User Data Functions, og publiceres derefter til Real-Time hub, hvor nedstrøms forbrugere som Activator, Eventhouse eller Power Automate kan reagere på dem. Hændelsesskemaer styres centralt gennem Schema Registry. Eventhouse gemmer automatisk alle offentliggjorte forretningsbegivenheder, så dens gendannelse påvirker direkte tilgængeligheden af forretningsbegivenhedshistorik. Ingen af udgiverens eller forbrugerens konfigurationer, skema-definitioner eller abonnementer replikeres til den sekundære region.

Brug følgende trin til at gendanne Business Events, Fabric Events og Azure Events i det nye arbejdsområde i recovery-regionen.

For forretningsarrangementer:

  1. Genskab forretningsbegivenheden, som udgivere og forbrugere bruger, ved at følge artiklen Create Business Events i Fabric Real-Time Hub. Under oprettelsen af forretningsbegivenheden opretter du Event Schema Set-ressourcen. Eventhouse-ressourcen er valgfri afhængigt af scenariet. Hvis du har taget backup af dit event schema set med Git-integration, så gendanne det først ved at følge Event schema set-sektionen, og peg derefter forretningsbegivenheden på det gendannede skema-sæt.

  2. Genskab alle publisher elementer, der genererer forretningsbegivenheder, såsom Spark-notebooks eller User Data Functions, i det nye arbejdsområde ved at følge de publisher artikler: Brug User Data Function som Business Events Publisher, Brug Activator som Business Events Publisher, Brug Notebook som Business Events Publisher, og brug Eventstream som Business Events Publisher.

  3. Genskab forbrugerabonnementerne i Real-Time hub (for eksempel Activator-regler, notebook-triggere eller Power Automate flows), der oprindeligt reagerede på forretningsbegivenheder i den berørte region, ved at følge artiklerne Eventhouse og Real-Time Dashboard-integration med forretningsbegivenheder og forbrug forretningsbegivenheder fra Activator.

  4. Valider at begivenhederne flyder fra ende til ende ved at verificere, at abonnementerne er aktive, og at data ankommer til de forventede destinationer i genopretningsområdet.

Til Fabric-arrangementer:

  1. Genskab abonnementerne i Real-Time hub, der peger på arbejdsområde-elementer, jobs eller OneLake-stier, der blev gendannet i recovery-regionen, ved at følge artiklen Udforsk Fabric events i Fabric Real-Time hub.

  2. Valider at begivenhederne flyder fra ende til ende ved at verificere, at abonnementerne er aktive, og at data ankommer til de forventede destinationer i genopretningsområdet.

For Azure-begivenheder:

  1. Azure Blob Storage-konti påvirkes ikke af en regional Fabric-nedetid. Genskab event-abonnementerne i Real-Time hub, der peger på de samme Azure Blob Storage konti, ved at følge artiklen Set advarsler på Azure Blob Storage events i Real-Time hub.

  2. Valider at begivenhederne flyder fra ende til ende ved at verificere, at abonnementerne er aktive, og at data ankommer til de forventede destinationer i genopretningsområdet.

Bemærk

Hændelseshistorik for Business Events afhænger af Eventhouse-genopretning. Business Events, Fabric Events og Azure Events er push-baserede og flygtige, så der kan ikke gendannes historiske hændelsesdata for disse typer. Kun begivenheder, der produceres efter genopretningen er fuldført, er tilgængelige i den nye region.

Hændelsesskema

Et hændelsesskema-sæt er det Fabric element, der indeholder hændelsestype- og skemadefinitioner i Real-Time Intelligence. Andre funktioner bygger videre på det: udgivere skriver events, der følger dets skemaer, og forbrugerne læser op mod de samme definitioner.

Hændelsesskemasæt fra den primære region forbliver utilgængelige for kunderne, og de replikeres ikke til den sekundære region. Men fordi et event schema-sæt er en holdbar defineret definition og ikke et midlertidig abonnement, kan du tage backup på forhånd og gendanne det i stedet for at genforfatte det manuelt.

For at gendanne et hændelsesskema, der er sat efter en regional katastrofe, skal du opsætte Fabric Git-integration, før en katastrofe opstår, og synkronisere arbejdsområdet, der indeholder dine hændelsesskema-sæt, med dit Git-repository.

  1. Konfigurér Fabric Git-integration for arbejdsområdet, der indeholder dit event schema-sæt, og synkroniser det med dit Git-repository.

  2. Hold hændelsesskemasættet dedikeret og synkroniseret regelmæssigt, især efter tilføjelse af hændelsestyper eller publicering af nye skemaversioner.

  3. Under gendannelsen oprettes et nyt arbejdsområde i målregionen (C2. W2), forbind det til det samme repository og synkroniser for at gendanne hændelsesskemasættet. Fordi det nye arbejdsområde er tomt, bringer Git Sync indholdet fra repositoryet ind i arbejdsområdet.

  4. Genskab alle udgivere og forbrugere, der bruger skemasættet, og følg vejledningen for disse item-typer.

  5. Valider, at udgivere kan publicere mod de genoprettede hændelsestyper, og at forbrugerne modtager begivenheder som forventet.

Den synkroniserede definition inkluderer hændelsestyperne i skemasættet, skemaerne og skemaversionerne. Den inkluderer ikke udgiverregistreringer, forbrugerabonnementer eller begivenhedshistorik. Genopret dem separat, efter vejledningen for de objekttyper, der bruger skemasættet.

Alternativ: genskab manuelt

Hvis du ikke konfigurerede Git-integration før katastrofen, så genskab hændelsesskemasættet i recovery-regionen ved at følge Create and manage event schema sets, og tilføj derefter de hændelsestyper og skemaer, som det oprindelige skemasæt indeholdt, ved at følge Create and manage event schemas in schema sets.

Bemærk

Hændelsesskema-sæt deles ofte mellem flere udgivere og forbrugere. Genopfør skemasættet, før du genskaber de elementer, der afhænger af det, så disse elementer har hændelsestyper at binde til.

Kort

Kortgenstande fra den primære region forbliver utilgængelige for kunderne, og kortgenstandene bliver ikke replikeret til den sekundære region.

Hvis du vil gendanne et kortelement, når en katastrofe sker, så opsæt Fabric Git-integration, og synchronize dit kortelement med dit Git-repo.

Under genopretningen, efter den nye region/kapacitet i Fabric er sat op, kan du bruge repoet til at genopbygge Map-elementet i det nye arbejdsområde, du har oprettet. Da det nye arbejdsområde er tomt, henter Git sync indholdet fra repoet ind i det tomme arbejdsområde. Dette trin bringer kort-genstanden tilbage til live.

Bemærk

Hvis det oprindelige kortelement har konfigureret et lakehouse- eller KQL-forespørgselssæt, henvises først til afsnittet om søhuset og KQL-forespørgselsmængden for at gendanne dem. Når disse afhængigheder er løst, forbind det nyligt genvundne søhus og queryset til det nyligt genvundne kortelement.

Ontologi

Ontologibrugere skal tage proaktive skridt for at forberede sig på regional katastrofeberedskab. Den nedenfor beskrevne tilgang sikrer, at din Ontologi efter en regional katastrofe forbliver genoprettelig og kan genoprettes hurtigt.

Den simpleste og hurtigste måde at muliggøre gendannelse på er at bruge Fabric Git-integration og synkronisere din Ontology med et Azure DevOps (ADO) repository. Hvis tjenesten overgår til et andet område, kan du bruge dette repository til at genopbygge ontologien i et nyoprettet arbejdsområde.

Ontologielementer i den primære region er ikke tilgængelige for kunder efter en regional katastrofe, og ontologielementer replikeres ikke til den sekundære region.

For at gendanne et Ontology-element under en katastrofe, konfigurerer du Fabric Git-integration og synchronize Ontology-elementet med dit ADO-repository på forhånd.

Under gendannelse, når den nye region og kapacitet i Fabric er sat op, kan du bruge repositoryet til at genopbygge Ontology-elementet i et nyt arbejdsområde. Fordi det nye arbejdsområde er tomt, henter Git sync indholdet fra repositoryet ind i arbejdsområdet, hvilket effektivt gendanner Ontology-elementet.

Bemærk

Hvis det oprindelige Ontologi-element har et lakehouse konfigureret, henvises til Lakehouse-afsnittet for først at gendanne lakehouse. Når disse afhængigheder er håndteret, forbind det nyligt genvundne søhus til det nyligt genvundne Ontologi-element.

Plan

Denne artikel beskriver genopretningsprocedurerne for planens erfaring i IQ. Den beskriver de nødvendige trin for at genoprette nøglekomponenter, herunder Planning, PowerTable, Intelligence, InfoBridge og relaterede dataaktiver.

Git-integration til at gendanne Plan-elementer

Den foretrukne tilgang er at synkronisere alle Plan-elementer med et Azure DevOps (ADO) eller GitHub-repository ved at bruge Fabric Git-integration. Efter en failover skal du bruge repositoryet til at gendanne elementerne i det nye arbejdsområde.

Før katastrofen (proaktive skridt):

  1. I arbejdsområde W1 skal du gå til Arbejdsområdeindstillinger og konfigurere Git-integration.

  2. Vælg Connect og synkroniser med dit ADO eller GitHub-repository.

  3. Vælg Plan-elementerne, der skal uploades til repositoryet, og vælg Commit.

    Skærmbillede af upload af Plan-elementer fra Fabric-arbejdsområdet til et Git-repository.

  4. Bekræft, at Git-status for Plan-items er Synkroniseret.

  5. Etabler en commit-disciplin – commit efter hver væsentlig ændring i en plandefinition, så repositoryet altid afspejler den seneste tilstand.

Genopretningsskridt:

  1. Opret et nyt arbejdsområde W2 inden for kapacitet C2 i det sunde område.

  2. I arbejdsområde W2 skal du gå til Arbejdsområdeindstillinger og genoprette forbindelsen til det samme ADO/GitHub-repository.

  3. Vælg Kildekontrolelement. Vælg den relevante repository-gren og vælg Opdater Alle. Alle planpunkter downloades til W2.

Vigtig

Kun planlægningsarkets struktur og indstillinger gendannes ved brug af Git-integration. Data indtastet i planlægningsarket såsom inputværdier, noter og kommentarer gendannes ikke automatisk. Det kræver Fabric SQL-gendannelse. Semantiske modeldata skal også gendannes separat.

Følgende komponenter genoprettes efter genopretning:

  • PowerTable-ark: Indstillinger for kildetabel, kolonnekonfiguration, rækkeadgang, visuelle egenskaber (layout, formater og mere), rækkeidentifikation, kommentarindstillinger, langsomt skiftende dimensioner (SCD), godkendelser, automatiseringer og formularer.
  • Planlægningsark: Arkegenskaber (formatering, betinget formatering og mere), kommentarindstillinger, writeback-indstillinger, datainputkolonner, datainput-rækker, scenarier og bogmærker.
  • InfoBridge: InfoBridge-kilder, InfoBridge-forespørgsler, transformationstrin, writeback-destinationer, writeback-indstillinger, linked query-mapping, forespørgselsgrupper, visuelle egenskaber (blend). Disse elementer kan ikke gendannes: filbaserede kilder (CSV, Excel), tværarbejdsbelastningsark, der bruger filbaserede kilder.
  • Intelligens: Alle horoskoper og matricer.

Fabric SQL-gendannelse for Plan

Data indtastet i planlægningsark, tabeller brugt i PowerTable og writeback-data gemmes i SQL-databaser og skal tages i betragtning som en del af din katastrofeberedskabsstrategi. For at gendanne SQL-databaser, se afsnittet om SQL-databaser .

  • Genopret planmetadata: Hvert planelement er tilknyttet en __fabric_plan_sys database, der gemmer metadata for planlægningsfunktioner, herunder kommentarer, scenarier, datainput og konfiguration af writeback. Den __fabric_plan_sys database gendannes ikke automatisk og skal eksplicit gendannes.

  • Genopret writeback-databaser: Hvis din plan bruger SQL writeback-destinationer, skal du også manuelt gendanne de tilknyttede databaser. Konfigurerede SQL-writeback-destinationer gendannes ikke automatisk.

  • Genopret tabeller brugt i PowerTable: Alle tabeller oprettet ved brug af PowerTable gemmes i en Fabric SQL-database. Du skal også gendanne disse tabeller under DR.

Operationsagenter

Brugere af operationsagenter bør tage proaktive skridt for at forberede sig på regional katastrofeberedskab. At følge den metode, der er beskrevet i dette afsnit, hjælper med at sikre, at dine agenter hurtigt kan genoprettes efter et regionalt udfald.

Brug Fabric Git-integration til at synkronisere dit arbejdsområde med et repository. Denne tilgang gør det muligt at rekonstruere agentkonfigurationer i et nyt arbejdsområde, hvis tjenesten skifter til en anden region.

Operationsagent-items i primærregionen er ikke tilgængelige under en regional katastrofe. Agentkonfigurationer, adfærdsmodeller og aktivitetslogfiler replikeres ikke til den sekundære region. Igangværende operationer, aktive chatsessioner og tidligere indsamlede begivenheder på katastrofetidspunktet går også tabt.

For at forberede gendannelse skal du konfigurere Fabric Git-integration og synkronisere dine agent-elementer med dit ADO-repository, før en katastrofe opstår.

Når du gendanner, opsætter du din nye region og kapacitet i Fabric, og brug derefter det synkroniserede repository til at gendanne agentkonfigurationer i et frisk arbejdsområde. Git sync henter det lagrede indhold fra repositoryet ind i det tomme arbejdsområde og genskaber dine agent-elementer.

Når konfigurationerne er genoprettet, bekræftes det, at eventuelle refererede Eventhouse (KQL) databaser eller regionsspecifikke datakilder er tilgængelige i den nye region. Opdater endpoint-referencer i agentkonfigurationer efter behov. Endelig genstart dine agenter og lad brugerne starte nye chatsessioner. Tidligere samtaler kan ikke genoptages.

Transaktionsdatabase

I denne vejledning beskrives genoprettelsesprocedurerne for transaktionsdatabasen.

SQL-database

For at beskytte mod en regional fejl kan brugere af SQL-databaser træffe proaktive foranstaltninger for regelmæssigt at eksportere deres data og bruge de eksporterede data til at genskabe databasen i et nyt arbejdsområde, når det er nødvendigt.

Dette kan opnås ved at bruge SqlPackage CLI-værktøjet, der giver databaseportabilitet og letter databaseimplementeringer.

  1. Brug værktøjet SqlPackage til at eksportere databasen til en .bacpac fil. Se Eksportere en database med SqlPackage for at få flere oplysninger.
  2. Gem .bacpac filen på en sikker placering, der er i et andet område end databasen. Eksempler inkluderer lagring af .bacpac-filen i en Lakehouse, der ligger i en anden region, ved brug af en geo-redundant Azure Storage-konto eller ved brug af et andet sikkert lagringsmedie, der er i en anden region.
  3. Hvis SQL-databasen og -området ikke er tilgængelige, kan du bruge .bacpac filen med SqlPackage til at genskabe databasen i et arbejdsområde i et nyt område – Workspace C2. W2 i region B som beskrevet i scenariet ovenfor. Følg de trin, der er beskrevet i Importere en database med SqlPackage for at genoprette databasen med din .bacpac fil.

Den genskabte database er en uafhængig database i forhold til den oprindelige database og afspejler dataenes tilstand på tidspunktet for eksporten.

Overvejelser i forbindelse med failback

Den genskabte database er en uafhængig database. Data, der føjes til den genskabte database, afspejles ikke i den oprindelige database. Hvis du planlægger at gå tilbage til den oprindelige database, når hjemmeområdet bliver tilgængeligt, skal du overveje manuelt at afstemme data fra den genskabte database til den oprindelige database.

Platform

Platform refererer til de underliggende delte tjenester og arkitektur, der gælder for alle arbejdsbelastninger. Dette afsnit beskriver genopretningsprocedurer for delte Fabric-kapabiliteter.

Overvågning af arbejdsområde

Arbejdsområdeovervågning indsamler logfiler om aktivitet i det arbejdsområde, hvor du aktiverer det. Efter du har gendannet dit arbejdsområde som C2. W2, aktiver arbejdsområdeovervågning på W2. Den begynder at indsamle overvågningsdata for det genvundne arbejdsområde.

Overvågningsdata fra det oprindelige arbejdsområde (C1. W1) overføres ikke, fordi overvågning afspejler aktiviteten i det arbejdsområde, den kører på.

Variabelt bibliotek

Microsoft Fabric Variable-biblioteker gør det muligt for udviklere at tilpasse og dele produktkonfigurationer inden for et arbejdsområde, hvilket effektiviserer styringen af indholdslivscyklussen. Fra et it-katastrofeberedskabssynspunkt skal brugere af variable biblioteker proaktivt beskytte mod en regional katastrofe. Dette kan gøres gennem Fabric Git-integration, som sikrer, at efter en regional katastrofe forbliver brugerens Variable-bibliotek tilgængeligt. Hvis du vil gendanne et variabelbibliotek, anbefaler vi følgende:

  • Brug Fabric Git-integration til at synkronisere dit Variable-bibliotek med dit ADO-repo. I tilfælde af en katastrofe kan du bruge lageret til at genopbygge variabelbiblioteket i det nye arbejdsområde, du har oprettet. Benyt følgende fremgangsmåde:

    1. Opret forbindelse mellem dit arbejdsområde og Git-lageret som beskrevet her.
    2. Sørg for at holde WS og lageret synkroniseret med Commit and Update.
    3. Genoprettelse – I tilfælde af en katastrofe skal du bruge lageret til at genopbygge variabelbiblioteket i et nyt arbejdsområde:

  • I det nyoprettede arbejdsområde skal du oprette og synkronisere til dit Azure ADO-repo igen.

  • Alle Fabric-elementer i dette repository downloades automatisk til dit nye Workspace.

  • Når du har synkroniseret dine elementer fra Git, skal du åbne dine variable biblioteker i det nye arbejdsområde og manuelt vælge det ønskede aktive værdisæt.

Kundeadministrerede nøgler til Fabric-arbejdsområder

Du kan bruge kundeadministrerede nøgler (CMK), der er gemt i Azure Key Vault, til at tilføje et ekstra lag kryptering oven på Microsoft-administrerede nøgler til data i hvile. Hvis Fabric bliver utilgængelig eller ubrugelig i en region, vil dens komponenter blive overført til en backup-instans. Under failover understøtter CMK-funktionen skrivebeskyttede handlinger. Så længe Azure Key Vault-tjenesten forbliver sund, og tilladelserne til vaulten er intakte, vil Fabric fortsætte med at forbinde til din nøgle og lade dig læse data normalt. Det betyder, at følgende handlinger ikke understøttes under failover: aktivering og deaktivering af CMK-indstillingen for arbejdsområdet og opdatering af nøglen.

OneLake

Dette afsnit guider dig gennem genopretningsprocedurerne for OneLake-funktioner. For mere information om katastrofeberedskab for OneLake-data, se OneLake katastrofeberedskab.

Politikker for administration af livscyklus

Hvis Fabric bliver utilgængelig eller ubrugelig i et område, kan din OneLake-livscykluspolitik stadig læses og opdateres under failover. Alle data, der flyttes til cool eller cold tier, forbliver i det tier. Du kan følge disse trin for at anvende din eksisterende politik på dit nye recovery-arbejdsområde:

  1. Kald Eksportpolitik på dit oprindelige arbejdsområde og gem hele livscykluspolitikken.
  2. Kald Import Policy på dit gendannede arbejdsområde, med din eksporterede livscykluspolitik som anmodningsorgan.

Ressourceinstansregler

Resource instance rules hjælper dig med sikkert at kontrollere adgangen til data i OneLake ved at bruge betroede Azure resource identitys. Under regional failover fortsætter systemet med at håndhæve eksisterende regler for læseadgang. Du kan dog ikke oprette, opdatere eller slette ressourceinstansregler, før arbejdsområdet vender tilbage til en skrivbar tilstand.

  • Last updated on