Pålidelighed i Microsoft Fabric

Denne artikel beskriver pålidelighedssupport i Microsoft Fabric, herunder både regional robusthed med tilgængelighedszoner samt genopretning på tværs af regioner og forretningskontinuitet. For en mere detaljeret oversigt over pålidelighed i Azure, se Azure reliability.

Understøttelse af tilgængelighedszoner

Tilgængelighedszoner er fysisk adskilte grupper af datacentre inden for en Azure-region. Når en zone fejler, kan tjenester skifte til en af de resterende zoner.

Fabric bruger Azure-tilgængelighedszoner til at beskytte Fabric- og Power BI-elementer og data mod datacenterfejl. Tjenesten distribuerer automatisk Fabric-ressourcer over flere zoner uden behov for kundekonfiguration.

  • Data engineering understøtter tilgængelighedszoner, hvis du bruger OneLake. Hvis du bruger andre datakilder som ADLS Gen2, skal du sikre, at zone-redundant lagring (ZRS) er aktiveret.

Zone-ned-oplevelse

Under et zoneomfattende nedbrud kræves ingen kundehandling. Fabric-evner heler og balancerer automatisk for at udnytte den sunde zone. I nogle tilfælde kan igangværende operationer være nødt til at genstarte. For eksempel kan det at køre Spark Jobs fejle, hvis den primære node er i den fejlede zone. I så fald skal du indsende jobene igen. Data warehouse og SQL analytics endpoint-forespørgsler kan fejle, hvis frontend-noden er i den fejlede zone. I sådanne tilfælde skal du sikkert genstarte forespørgslen.

Vigtigt!

Selvom Microsoft bestræber sig på at levere ensartet og ensartet understøttelse af tilgængelighedszoner, kan Fabric-kapaciteter placeret i Azure-regioner med højere kundeefterspørgselsudsving opleve højere end normal latenstid i nogle tilfælde af fejl i tilgængelighedszonerne.

Tværregional katastrofeberedskab og forretningskontinuitet

Katastrofeberedskab (DR) refererer til praksisser, som organisationer bruger til at komme sig efter hændelser med stor påvirkning, såsom naturkatastrofer eller fejlslagne implementeringer, der resulterer i nedetid og datatab. Uanset årsagen er det bedste middel til en katastrofe en veldefineret og testet DR-plan og et programdesign, der aktivt understøtter DR. Før du begynder at lave din katastrofeberedskabsplan, se Anbefalinger til at designe en katastrofeberedskabsstrategi.

For DR bruger Microsoft modellen med delt ansvar. I denne model sikrer Microsoft, at den grundlæggende infrastruktur og platformtjenester er tilgængelige. Dog replikerer mange Azure-tjenester ikke automatisk data eller falder tilbage fra en fejlslagen region for at kryds-replikere til en anden aktiveret region. For disse tjenester er du ansvarlig for at oprette en katastrofeberedskabsplan, der passer til din arbejdsbyrde. De fleste tjenester, der kører på Azure PaaS-tilbud (Platform as a Service), indeholder funktioner og vejledning til understøttelse af DR. Du kan bruge servicespecifikke funktioner til at understøtte hurtig genopretning og hjælpe med at udvikle din DR-plan.

Dette afsnit beskriver en katastrofeberedskabsplan for Fabric, der er designet til at hjælpe din organisation med at holde sine data sikre og tilgængelige, når en uplanlagt regional katastrofe indtræffer. Planen dækker følgende emner:

  • Tværregional replikation: Fabric tilbyder tværregional replikering for data lagret i OneLake. Du kan vælge at tilmelde dig eller fravælge denne funktion baseret på dine behov.

  • Dataadgang efter katastrofe: I et regionalt katastrofescenarie garanterer Fabric dataadgang, med visse begrænsninger. Selvom oprettelse eller ændring af nye elementer er begrænset efter failover, forbliver det primære fokus på at sikre, at eksisterende data forbliver tilgængelige og intakte.

  • Vejledning til genopretning: Fabric giver et struktureret sæt instruktioner, der guider dig gennem helingsprocessen. Den strukturerede vejledning gør det lettere for dig at vende tilbage til almindelig drift.

Power BI, som nu er en del af Fabric, har et solidt katastrofeberedskabssystem på plads og tilbyder følgende funktioner:

  • BCDR som standard: Hvis en region parres med en region, der understøtter Power BI, er katastrofeberedskabsfunktioner inkluderet som standard. Du behøver ikke vælge eller aktivere denne funktion separat.

  • Tværregional replikering: Power BI bruger Azure storage geo-redundant replikering og Azure SQL geo-redundant replikering for at sikre, at backup-instanser findes i andre regioner og kan bruges. Det betyder, at data duplikeres på tværs af forskellige regioner, hvilket øger tilgængeligheden og reducerer risiciene forbundet med regionale nedbrud.

  • Fortsatte tjenester og adgang efter katastrofe: Selv under forstyrrende begivenheder forbliver Power BI-elementer tilgængelige i skrivebeskyttet tilstand. Punkterne omfatter semantiske modeller, rapporter og dashboards, som sikrer, at virksomheder kan fortsætte deres analyse- og beslutningsprocesser uden væsentlige hindringer.

For mere information, se Power BI high availability, failover og disaster recovery FAQ.

Vigtigt!

For kunder, der er ramt af en katastrofe, og hvis hjemmeregioner ikke har en Azure-parret region, der understøtter Fabric, kan muligheden for at udnytte Fabric-kapaciteter blive kompromitteret, selv hvis dataene inden for disse kapaciteter replikeres. Denne begrænsning er knyttet til hjemregionens infrastruktur, som er essentiel for driften af kapaciteterne. For at se listen over regioner, der understøtter Fabric, gå til Fabric Region Availability.

Hjemmeregion og kapacitetsfunktionalitet

For effektiv katastrofeberedskabsplanlægning er det afgørende, at du forstår forholdet mellem din hjemregion og kapacitetsplaceringerne. At forstå hjemregioner og kapacitetsplaceringer hjælper dig med at træffe strategiske valg af kapacitetsregioner samt de tilsvarende replikations- og genopretningsprocesser.

Hjemmeområdet for din organisations leje- og datalagring er sat til faktureringsadressen for den første bruger, der tilmelder sig. For yderligere detaljer om lejeopsætning, gå til Power BI implementeringsplanlægning: Lejeropsætning. Når du opretter nye kapaciteter, er din datalagring som standard sat til hjemmeområdet. Hvis du ønsker at ændre din datalagringsregion til en anden region, skal du aktivere Multi-Geo, en Fabric Premium-funktion.

Vigtigt!

At vælge et andet område til din kapacitet flytter ikke alle dine data helt til det område. Nogle dataelementer forbliver stadig lagret i hjemregionen. For at se, hvilke data der forbliver i hjemmeregionen, og hvilke data der er lagret i Multi-Geo-aktiveret region, se Konfigurér Multi-Geo-understøttelse for Fabric Premium.

I tilfælde af en hjemmeregion, der ikke har en parret region, kan kapaciteter i enhver Multi-Geo-aktiveret region få driftsproblemer, hvis hjemregionen oplever en katastrofe, da kernefunktionaliteten er bundet til hjemregionen.

Hvis du vælger en Multi-Geo-aktiveret region inden for EU, er det garanteret, at dine data er lagret inden for EU's datagrænse.

For at lære, hvordan du identificerer din hjemregion, se Find din Fabric hjemregion.

Indstilling af katastrofeberedskabskapacitet

Fabric tilbyder en katastrofeberedskabskontakt på kapacitetsindstillingssiden. Det er tilgængeligt, hvor Azure's regionale parringer matcher Fabric's servicetilstedeværelse. Her er detaljerne i dette skift:

  • Rolleadgang: Kun brugere med kapacitetsadministratorrollen eller højere kan bruge denne switch.

  • Granularitet: Granulariteten af switchen er kapacitetsniveauet. Den fås både i Premium- og Fabric-versioner.

  • Dataomfang: Katastrofeberedskabs-togglen adresserer specifikt OneLake-data, som inkluderer Lakehouse- og Warehouse-data. Switchen påvirker ikke dine data, der er gemt uden for OneLake.

  • BCDR-kontinuitet for Power BI: Selvom du kan slå katastrofegendannelse for OneLake-data til og fra, understøttes BCDR for Power BI altid, uanset om switchen er tændt eller slukket.

  • Frekvens: Når du har ændret indstillingen for katastrofeberedskabskapacitet, skal du vente 30 dage, før du kan ændre den igen. Ventetiden opretholder stabiliteten og forhindrer konstant skift.

Skærmbillede af disaster recovery-lejerindstillingen.

Note

Efter at have aktiveret katastrofeberedskabskapaciteten eller oprettet nye arbejdsområder inden for kapaciteten, kan datareplikering tage noget tid at starte. Du kan tjekke status for hvert arbejdsområde på siden med kapacitetsindstillinger under Arbejdsområder tildelt denne kapacitet. OneLake Geo-replikationskolonnen viser status for aktivering af geo-replikation.

Datareplikering

Når du aktiverer indstillingen for katastrofegendannelseskapacitet, aktiveres tværregional replikering som en katastrofegendannelsesfunktion for OneLake-data. Fabric-platformen tilpasser sig Azure-regionerne for at levere geo-redundanspar. Dog har nogle regioner ikke en Azure pair-region, eller også understøtter pair-regionen ikke Fabric. For disse regioner er datareplikation ikke tilgængelig. For mere information, se Regioner med tilgængelighedszoner uden regionspar og Fabric regionstilgængelighed.

Note

Selvom Fabric tilbyder en datareplikeringsløsning i OneLake til understøtte katastrofegendannelse, er der bemærkelsesværdige begrænsninger. For eksempel gemmes data fra KQL-databaser og forespørgselssæt eksternt i OneLake, hvilket betyder, at en separat katastrofeberedskabsmetode er nødvendig. Se resten af dette dokument for detaljer om katastrofeberedskabsmetoden for hvert Fabric-element.

Fakturering

Disaster recovery-funktionen i Fabric muliggør geo-replikering af dine data for øget sikkerhed og pålidelighed. Denne funktion bruger mere lagerplads og transaktioner, som krediteres som henholdsvis BCDR Storage og BCDR Operations. Du kan overvåge og styre disse omkostninger i Microsoft Fabric Capacity Metrics-appen, hvor de vises som separate linjeposter.

For en udtømmende gennemgang af alle tilknyttede katastrofeberedskabsomkostninger, der kan hjælpe dig med at planlægge og budgettere derefter, se OneLake compute- og lagerforbrug.

Opsæt katastrofeberedskab

Selvom Fabric tilbyder katastrofeberedskabsfunktioner for at understøtte datarobusthed, skal du følge visse manuelle trin for at genoprette tjenesten under forstyrrelser. Dette afsnit beskriver de handlinger, du bør tage for at forberede dig på potentielle forstyrrelser.

Fase 1: Forbered

  • Aktivér katastrofeberedskabskapacitetsindstillingerne: Gennemgå og indsæt regelmæssigt katastrofeberedskabskapacitetsindstillingerne for at sikre, at de opfylder dine beskyttelses- og ydelsesbehov.

  • Opret databackups: Kopier kritiske data, der er lagret uden for OneLake, til en anden region på en måde, der passer til din katastrofeberedskabsplan.

Fase 2: Katastrofe-failover

Når en større katastrofe gør den primære region uoprettelig, igangsætter Microsoft Fabric en regional failover. Du kan ikke få adgang til Fabric-portalen, før failoveren er fuldført. En notifikation er lagt op på Microsoft Fabric-supportsiden.

Den tid, det tager for failover at fuldføre, kan variere, selvom det typisk tager mindre end en time. Når failoveren er fuldført, kan du forvente følgende:

  • Fabric-portal: Du kan få adgang til portalen, og læse operationer, såsom at gennemse eksisterende arbejdsområder, opgaveflows i arbejdsområder og elementer, fortsætter med at fungere. Alle skriveoperationer, såsom oprettelse eller ændring af et arbejdsområde, er sat på pause.

  • Power BI: Du kan udføre læseoperationer, såsom at vise dashboards og rapporter. Opdateringer, rapporteringsudgivelser, ændringer i dashboards og rapporter samt andre operationer, der kræver ændringer i metadata, understøttes ikke.

  • Lakehouse/Warehouse: Du kan ikke åbne disse genstande, men du kan få adgang til filer via OneLake API'er eller værktøjer.

  • Spark-jobdefinition: Du kan ikke åbne Spark-jobdefinitioner, men du kan få adgang til kodefiler via OneLake API'er eller værktøjer. Enhver metadata eller konfiguration gemmes efter failover.

  • Notesbog: Du kan ikke åbne notesbøger, og kodeindhold gemmes ikke efter katastrofen.

  • ML-model/eksperiment: Du kan ikke åbne ML-modeller eller eksperimenter. Kodeindhold og metadata som kørselsmetrikker og konfigurationer gemmes ikke efter katastrofen.

  • Dataflow Gen2/Pipeline/Eventstream: Du kan ikke åbne disse elementer, men du kan bruge understøttede katastrofeberedskabsdestinationer (lakehouses eller lagre) til at beskytte data.

  • KQL-database/forespørgselssæt: Du kan ikke få adgang til KQL-databaser og forespørgselssæt efter failover. Der kræves flere forudsætningstrin for at beskytte dataene i KQL-databaser og forespørgselssæt.

I et katastrofescenarie er Fabric-portalen og Power BI i skrivebeskyttet tilstand, og andre Fabric-elementer er ikke tilgængelige. Du kan få adgang til deres data, der er gemt i OneLake, ved at bruge API'er eller tredjepartsværktøjer. Både portal og Power BI bevarer evnen til at udføre læse-skriveoperationer på disse data. Denne evne sikrer, at kritiske data forbliver tilgængelige og kan ændres, og afbøder potentielle forstyrrelser i dine forretningsaktiviteter.

Du kan få adgang til OneLake-data gennem flere kanaler:

Fase 3: Genopretningsplan

Mens Fabric sikrer, at data forbliver tilgængelige efter en katastrofe, kan du også handle for fuldt ud at genoprette deres tjenester til staten før hændelsen. Dette afsnit giver en trin-for-trin guide, der hjælper dig gennem helingsprocessen.

Genopretningstrin

  1. Opret en ny Fabric-kapacitet i enhver region efter en katastrofe. Givet den høje efterspørgsel under sådanne begivenheder, vælg et område uden for din primære geo for at øge sandsynligheden for tilgængelighed af compute-tjenester. For information om oprettelse af en kapacitet, se Køb et Microsoft Fabric-abonnement.

  2. Opret arbejdsområder i den nyoprettede kapacitet. Hvis nødvendigt, brug de samme navne som de gamle arbejdsområder.

  3. Opret genstande med samme navne som dem, du ønsker at genvinde. Dette trin er vigtigt, hvis du bruger det brugerdefinerede script til at gendanne søhuse og lagre.

  4. Genopret genstandene. For hvert element følger du det relevante afsnit i vejledningen for Experience-specifik katastrofeberedskab for at genoprette genstanden.

Næste trin

  • Last updated on