Erfaringsspecifik vejledning til it-katastrofeberedskab

Dette dokument indeholder erfaringsspecifik vejledning til gendannelse af 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 it-katastrofeberedskab for kapacitet C1, replikeres OneLake-data til en sikkerhedskopi i område B. Hvis område A står over for afbrydelser, mislykkes Fabric-tjenesten i C1 til område B.

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.

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.

Erfaringsspecifikke genopretningsplaner

Følgende afsnit indeholder trinvise vejledninger til hver Fabric-oplevelse for at hjælpe kunderne gennem genoprettelsesprocessen.

Data Engineering

Denne vejledning fører dig gennem inddrivelsesprocedurerne for Dataudvikler oplevelsen. Det dækker lakehouses, notesbøger og Spark jobdefinitioner.

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. Hvis du vil gendanne tabellerne og filerne fra det oprindelige lakehouse, skal du se dataene med OneLake-stier, f.eks. abfss (se Opret forbindelse til Microsoft OneLake). Du kan bruge følgende kodeeksempel (se Introduktion til Microsoft Spark Utilities) i notesbogen til at hente ABFS-stierne til filer og tabeller fra det oprindelige søhus. (Erstat C1. W1 med det faktiske navn på arbejdsområdet)

   mssparkutils.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
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Når du har kørt scriptet, vises tabellerne i det nye søhus.

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

Hvis du kun vil gendanne bestemte Lakehouse-filer eller -tabeller fra det oprindelige lakehouse, skal du bruge Azure Storage Explorer. Se Integrer OneLake med Azure Storage Explorer for at få 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.

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 dette nemt og hurtigt på er at bruge Fabric Git-integration og derefter synkronisere din notesbog med dit ADO-lager. 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.

   

   På følgende billede vises den synkroniserede notesbog.

   

2. Gendan notesbogen fra ADO-lageret.

   1. Opret forbindelse til dit Azure ADO-lager igen i det netop oprettede arbejdsområde.

      

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

      

      

   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.

      

   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.

         

         

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.

   

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 det oprindelige område ved hjælp af Azure Storage Explorer og manuelt genoprette Lakehouse-referencer 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 Libs, Mains og Snapshots fra det oprindelige SJD-element til det nye SJD-element.

   

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.

   

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

Du kan finde flere oplysninger om Azure Storage Explorer under Integrer OneLake med Azure Storage Explorer.

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 vejledning fører dig gennem genoprettelsesprocedurerne 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. Udfyld lagerets Delta-tabeller ved at udnytte lageroversigten og T-SQL-funktionerne (se Tabeller i datawarehousing 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. Endelig skal du ændre forbindelsesstreng i programmer ved hjælp af dit Fabric Warehouse.

Bemærk

For kunder, der har brug for tværgående it-katastrofeberedskab og fuld automatiseret forretningskontinuitet, anbefaler vi, at du bevarer to Fabric Warehouse-opsætninger i separate Fabric-områder og bevarer kode- og dataparitet ved at foretage regelmæssige udrulninger og dataindtagelse på begge websteder.

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. Vælg Eksportér skabelon under fanen Hjem i Power Query-editoren fra elementet Dataflow Gen2.

   

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.

   

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

4. I den aktuelle visningsrude i Power Query-editor skal du vælge Importér fra en Power Query-skabelon.

   

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 ved at bruge Fabric Git-integration og derefter synkronisere dit CopyJob med dit ADO-lager. 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.

   

   På følgende billede vises det synkroniserede CopyJob.

   

2. Gendan CopyJob fra ADO-lageret.

   1. Opret forbindelse til og synkroniser med dit Azure ADO-lager igen i det netop oprettede arbejdsområde. Alle Fabric-elementer i dette lager downloades automatisk til dit nye arbejdsområde.

      

   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 træffe proaktive foranstaltninger for at beskytte mod en regional katastrofe.

Vi anbefaler, at du administrerer 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 har brug for at gendanne Airflow-jobbet fra ADO-lageret, skal du oprette et nyt arbejdsområde, oprette forbindelse og synkronisere med dit Azure ADO-lager igen. Alle Fabric-elementer, herunder Airflow, i dette lager downloades automatisk 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.

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. Opret uafhængige KQL-databaser: Konfigurer to eller flere uafhængige KQL-databaser/-forespørgselssæt på dedikerede Fabric-kapaciteter. Disse skal konfigureres på tværs af to forskellige Azure-områder (helst Azure-parrede områder) 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 i Fabric-platformen til hentning, transformering og distribution af hændelser i realtid til forskellige destinationer (f.eks. lakehouses, KQL-databaser/forespørgselssæt) med en oplevelse uden kode. 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å georedundans ved at udrulle identiske Eventstream-arbejdsbelastninger i flere Azure-områder som en del af en aktiv/aktiv strategi for flere websteder. 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.

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 omfatter lagring af .bacpac filen i et Lakehouse, der er i et andet område, ved hjælp af en geo-redundant Azure Storage-konto eller ved hjælp af et andet sikkert lagermedie, der er i et andet område.
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. I dette afsnit gennemgår du gendannelsesprocedurerne for delte oplevelser. Det dækker variable biblioteker.

Variabelt bibliotek

Microsoft Fabric Variable-biblioteker gør det muligt for udviklere at tilpasse og dele elementkonfigurationer i et arbejdsområde, hvilket strømliner administration af indholdslivscyklus. Fra et it-katastrofeberedskabssynspunkt skal brugere af variable biblioteker proaktivt beskytte mod en regional katastrofe. Dette kan gøres via Fabric Git-integration, som sikrer, at en brugers variabelbibliotek forbliver tilgængeligt efter en regional katastrofe. Hvis du vil gendanne et variabelbibliotek, anbefaler vi følgende:

• Brug Fabric Git-integration til at synkronisere dit variabelbibliotek med dit ADO-lager. 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:

• Opret forbindelse til og synkroniser med dit Azure ADO-lager igen i det netop oprettede arbejdsområde.

• Alle Fabric-elementer i dette lager downloades automatisk til dit nye arbejdsområde.

• 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, der er gemt i Azure Key Vault, til at tilføje et ekstra krypteringslag oven på Microsoft-administrerede nøgler til inaktive data. I tilfælde af at Fabric bliver utilgængelig eller ubrugelig i et område, vil komponenterne redde til en sikkerhedskopiinstans. Under failover understøtter CMK-funktionen skrivebeskyttede handlinger. Så længe Azure Key Vault-tjenesten forbliver sund, og tilladelserne til boksen er intakte, fortsætter Fabric med at oprette forbindelse til din nøgle og giver dig mulighed for at 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.

Relaterede oplysninger

• Microsoft Fabric-vejledning til it-katastrofeberedskab