Pålitelighet i Microsoft Fabric

Denne artikkelen beskriver pålitelighetsstøtte i Microsoft Fabric, inkludert både regional robusthet med tilgjengelighetssoner og tverrregion-gjenoppretting og forretningskontinuitet. For en mer detaljert oversikt over pålitelighet i Azure, se Azure reliability.

Støtte for tilgjengelighetssone

Tilgjengelighetssoner er fysisk separate grupper av datasentre innenfor en Azure-region. Når én sone feiler, kan tjenestene gå over til en av de gjenværende sonene.

Fabric bruker Azure-tilgjengelighetssoner for å beskytte Fabric- og Power BI-elementer og data mot datasenterfeil. Tjenesten distribuerer automatisk Fabric-ressurser over flere soner uten behov for kundekonfigurasjon.

  • Data engineering støtter tilgjengelighetssoner hvis du bruker OneLake. Hvis du bruker andre datakilder som ADLS Gen2, må du sørge for at Zone-redundant Storage (ZRS) er aktivert.

Sone-down-opplevelse

Under et soneomfattende strømbrudd kreves ingen kundehandling. Fabric-evner helbreder seg selv og rebalanserer automatisk for å utnytte den sunne sonen. I noen tilfeller kan pågående operasjoner måtte starte på nytt. For eksempel kan kjøring av Spark Jobs feile hvis primærnoden er i den mislykkede sonen. I slike tilfeller må du sende inn jobbene på nytt. Datavarehus og SQL-analyse endepunktsspørring kan feile hvis front-end-noden er i den feilede sonen. I et slikt tilfelle må du trygt starte forespørselen på nytt.

Important

Selv om Microsoft streber etter å tilby ensartet og konsistent støtte for tilgjengelighetssoner, kan Fabric-kapasiteter plassert i Azure-regioner med høyere variasjoner i kundesone oppleve høyere enn normal forsinkelse ved feil i tilgjengelighetssonen.

Tverrregional katastrofegjenoppretting og forretningskontinuitet

Katastrofegjenoppretting (DR) refererer til praksiser som organisasjoner bruker for å komme seg etter hendelser med stor påvirkning, som naturkatastrofer eller mislykkede utrullinger som resulterer i nedetid og datatap. Uavhengig av årsaken, er det beste middelet for en katastrofe en veldefinert og testet DR-plan og en programdesign som aktivt støtter DR. Før du begynner å lage din katastrofegjenopprettingsplan, se Anbefalinger for utforming av en katastrofegjenopprettingsstrategi.

For DR bruker Microsoft modellen for delt ansvar. I denne modellen sørger Microsoft for at grunnleggende infrastruktur og plattformtjenester er tilgjengelige. Mange Azure-tjenester replikerer imidlertid ikke automatisk data eller faller tilbake fra en mislykket region for å kryssreplikere til en annen aktivert region. For disse tjenestene er du ansvarlig for å sette opp en katastrofegjenopprettingsplan som fungerer for din arbeidsmengde. De fleste tjenester som kjører på Azure plattform som en tjeneste (PaaS) tilbud gir funksjoner og veiledning for å støtte DR. Du kan bruke tjenestespesifikke funksjoner for å støtte rask gjenoppretting og hjelpe deg med å utvikle DR-planen din.

Denne delen beskriver en katastrofegjenopprettingsplan for Fabric som er designet for å hjelpe organisasjonen din med å holde dataene sine trygge og tilgjengelige når en uplanlagt regional katastrofe inntreffer. Planen dekker følgende temaer:

  • Tverrregion-replikasjon: Fabric tilbyr tverrregion-replikasjon for data lagret i OneLake. Du kan melde deg inn eller ut av denne funksjonen basert på dine behov.

  • Datatilgang etter katastrofe: I et regionalt katastrofescenario garanterer Fabric datatilgang, med visse begrensninger. Selv om opprettelse eller modifisering av nye elementer er begrenset etter failover, er hovedfokuset fortsatt å sikre at eksisterende data forblir tilgjengelige og intakte.

  • Veiledning for restitusjon: Fabric gir et strukturert sett med instruksjoner som veileder deg gjennom restitusjonsprosessen. Den strukturerte veiledningen gjør det enklere for deg å gå tilbake til vanlig drift.

Power BI, som nå er en del av Fabric, har et solid katastrofegjenopprettingssystem på plass og tilbyr følgende funksjoner:

  • BCDR som standard: Hvis en region kombineres med en region som støtter Power BI, er katastrofegjenopprettingsmuligheter inkludert som standard. Du trenger ikke å melde deg inn eller aktivere denne funksjonen separat.

  • Tverrregion-replikasjon: Power BI bruker Azure-lagring geo-redundant replikering og Azure SQL geo-redundant replikering for å garantere at backup-instanser finnes i andre regioner og kan brukes. Dette betyr at data dupliseres på tvers av ulike regioner, noe som øker tilgjengeligheten og reduserer risikoen forbundet med regionale strømbrudd.

  • Fortsettelse av tjenester og tilgang etter katastrofe: Selv under forstyrrende hendelser forblir Power BI-elementer tilgjengelige i skrivebeskyttet modus. Elementene inkluderer semantiske modeller, rapporter og dashbord, som sikrer at bedrifter kan fortsette sine analyse- og beslutningsprosesser uten betydelige hindringer.

For mer informasjon, se FAQ for Power BI høy tilgjengelighet, failover og katastrofegjenoppretting.

Important

For kunder som er rammet av en katastrofe og hvis hjemregioner ikke har en Azure-paret region som støtter Fabric, kan muligheten til å bruke Fabric-kapasiteter bli kompromittert, selv om dataene i disse kapasitetene blir replikert. Denne begrensningen er knyttet til hjemregionens infrastruktur, som er essensiell for driften av kapasitetene. For å se listen over regioner som støtter Fabric, gå til Fabric Region Availability.

Hjemmeregion og kapasitetsfunksjonalitet

For effektiv katastrofegjenopprettingsplanlegging er det avgjørende at du forstår sammenhengen mellom hjemregionen og kapasitetsstedene. Å forstå hjemregion og kapasitetslokasjoner hjelper deg å ta strategiske valg av kapasitetsområder, samt tilsvarende replikerings- og gjenopprettingsprosesser.

Hjemregionen for organisasjonens leieforhold og datalagring er satt til faktureringsadressen til den første brukeren som registrerer seg. For flere detaljer om leieoppsett, gå til Power BI implementation planning: Tenant setup. Når du oppretter nye kapasiteter, settes datalagringen din som standard til hjemmeregionen. Hvis du ønsker å endre datalagringsregionen til en annen region, må du aktivere Multi-Geo, en Fabric Premium-funksjon.

Important

Å velge en annen region for kapasiteten din flytter ikke all dataen din helt til den regionen. Noen dataelementer er fortsatt lagret i hjemregionen. For å se hvilke data som fortsatt er i hjemregionen og hvilke data som lagres i Multi-Geo-aktivert region, se Configure Multi-Geo support for Fabric Premium.

I tilfelle av en hjemmeregion som ikke har en paret region, kan kapasiteter i enhver Multi-Geo-aktivert region få driftsproblemer dersom hjemregionen opplever en katastrofe, siden kjernefunksjonaliteten er knyttet til hjemmeregionen.

Hvis du velger en Multi-Geo-aktivert region innenfor EU, er det garantert at dataene dine lagres innenfor EU-grensen.

For å lære hvordan du identifiserer hjemregionen din, se Find your Fabric hjemregion.

Kapasitetsinnstilling for katastrofegjenoppretting

Fabric tilbyr en katastrofegjenopprettingsbryter på kapasitetsinnstillingssiden. Den er tilgjengelig der Azure regionale paringer samsvarer med Fabric sin tjenestetilstedeværelse. Her er detaljene rundt dette byttet:

  • Rolletilgang: Kun brukere med kapasitet som administrator eller høyere kan bruke denne bryteren.

  • Granularitet: Granulariteten til bryteren er kapasitetsnivået. Den er tilgjengelig for både Premium- og Fabric-kapasiteter.

  • Dataomfang: Katastrofegjenopprettingsbryteren adresserer spesifikt OneLake-data, som inkluderer Lakehouse- og Warehouse-data. Switchen påvirker ikke dataene dine lagret utenfor OneLake.

  • BCDR-kontinuitet for Power BI: Selv om du kan slå av og på katastrofegjenoppretting for OneLake-data, støttes BCDR for Power BI alltid, uansett om bryteren er på eller av.

  • Frekvens: Når du endrer innstillingen for katastrofegjenopprettingskapasitet, må du vente 30 dager før du kan endre den igjen. Ventetiden opprettholder stabiliteten og forhindrer konstant veksling.

Skjermbilde av katastrofegjenopprettings-leietakerinnstillingen.

Note

Etter å ha aktivert katastrofegjenopprettingskapasiteten eller opprettet nye arbeidsområder innenfor kapasiteten, kan datareplikering ta tid å starte. Du kan sjekke statusen til hvert arbeidsområde på siden for kapasitetsinnstillinger under Arbeidsområder tildelt denne kapasiteten. OneLake Geo-replikeringskolonnen viser status for å aktivere geo-replikering.

Datareplikering

Når du slår på innstillingen for katastrofegjenopprettingskapasitet, aktiveres tverrregion-replikering som en katastrofegjenopprettingsfunksjon for OneLake-data. Fabric-plattformen tilpasser seg Azure-regionene for å tilby geo-redundansparene. Noen regioner har imidlertid ikke en Azure pair-region, eller pair-regionen støtter ikke Fabric. For disse områdene er ikke datareplikasjon tilgjengelig. For mer informasjon, se Regioner med tilgjengelighetssoner uten regionspar og Fabric regiontilgjengelighet.

Note

Selv om Fabric tilbyr en datareplikasjonsløsning i OneLake for å støtte katastrofegjenoppretting, finnes det merkbare begrensninger. For eksempel lagres dataene fra KQL-databaser og spørringssett eksternt til OneLake, noe som betyr at en egen katastrofegjenopprettingsmetode er nødvendig. Se resten av dette dokumentet for detaljer om katastrofegjenopprettingsmetoden for hvert Fabric-element.

Fakturering

Katastrofegjenopprettingsfunksjonen i Fabric muliggjør geo-replikering av dataene dine for økt sikkerhet og pålitelighet. Denne funksjonen bruker mer lagring og transaksjoner, som faktureres som henholdsvis BCDR Storage og BCDR Operations. Du kan overvåke og administrere disse kostnadene i Microsoft Fabric Capacity Metrics-appen, hvor de vises som separate linjeposter.

For en grundig oversikt over alle tilknyttede katastrofegjenopprettingskostnader, slik at du kan planlegge og budsjettere deretter, se OneLake databehandlings- og lagringsforbruk.

Sett opp katastrofegjenoppretting

Selv om Fabric tilbyr katastrofegjenopprettingsfunksjoner for å støtte datarobusthet, må du følge visse manuelle trinn for å gjenopprette tjenesten under forstyrrelser. Denne delen beskriver tiltakene du bør iverksette for å forberede deg på potensielle forstyrrelser.

Fase 1: Forbered

  • Aktiver innstillingene for katastrofegjenopprettingskapasitet: Gå jevnlig gjennom og sett innstillingene for katastrofegjenopprettingskapasitet for å sikre at de oppfyller dine beskyttelses- og ytelsesbehov.

  • Lag sikkerhetskopier av data: Kopier kritiske data lagret utenfor OneLake til en annen region på en måte som samsvarer med din katastrofegjenopprettingsplan.

Fase 2: Katastrofe-failover

Når en stor katastrofe gjør primærregionen uopprettelig, initierer Microsoft Fabric en regional failover. Du får ikke tilgang til Fabric-portalen før failoveren er fullført. En varsling legges ut på Microsoft Fabric-støttesiden.

Tiden det tar å fullføre failover kan variere, selv om det vanligvis tar mindre enn én time. Når failoveren er fullført, kan du forvente følgende:

  • Fabric-portal: Du kan få tilgang til portalen, og lese operasjoner, som å bla gjennom eksisterende arbeidsområder, oppgaveflyter i arbeidsområder og elementer, fortsette å fungere. Alle skriveoperasjoner, som å opprette eller endre et arbeidsområde, settes på pause.

  • Power BI: Du kan utføre leseoperasjoner, som å vise dashbord og rapporter. Oppdateringer, rapportpubliseringsoperasjoner, endringer i dashbord og rapporter, samt andre operasjoner som krever endringer i metadata, støttes ikke.

  • Lakehouse/Warehouse: Du kan ikke åpne disse elementene, men du kan få tilgang til filer via OneLake-API-er eller verktøy.

  • Spark-jobbdefinisjon: Du kan ikke åpne Spark-jobbdefinisjoner, men du kan få tilgang til kodefiler via OneLake-API-er eller verktøy. All metadata eller konfigurasjon lagres etter failover.

  • Notatbok: Du kan ikke åpne notatbøker, og kodeinnhold lagres ikke etter katastrofen.

  • ML-modell/eksperiment: Du kan ikke åpne ML-modeller eller eksperimenter. Kodeinnhold og metadata som kjøremålinger og konfigurasjoner lagres ikke etter katastrofen.

  • Dataflow Gen2/Pipeline/Eventstream: Du kan ikke åpne disse elementene, men du kan bruke støttede katastrofegjenopprettingsdestinasjoner (lakehouses eller lagre) for å beskytte data.

  • KQL-database/spørringssett: Du kan ikke få tilgang til KQL-databaser og spørringssett etter failover. Flere forutsetningstrinn er nødvendige for å beskytte dataene i KQL-databaser og spørringssett.

I et katastrofescenario er Fabric-portalen og Power BI i skrivebeskyttet modus, og andre Fabric-elementer er ikke tilgjengelige. Du kan få tilgang til dataene deres lagret i OneLake ved å bruke API-er eller tredjepartsverktøy. Både portal og Power BI beholder evnen til å utføre lese- og skriveoperasjoner på disse dataene. Denne evnen sikrer at kritiske data forblir tilgjengelige og kan endres, og reduserer potensiell forstyrrelse av forretningsdriften din.

Du kan få tilgang til OneLake-data gjennom flere kanaler:

Fase 3: Gjenopprettingsplan

Selv om Fabric sørger for at data forblir tilgjengelig etter en katastrofe, kan du også handle for å gjenopprette deres tjenester fullt ut til staten før hendelsen. Denne delen gir en trinnvis guide som hjelper deg gjennom rehabiliteringsprosessen.

Gjenopprettingssteg

  1. Opprett en ny Fabric-kapasitet i enhver region etter en katastrofe. Gitt den høye etterspørselen under slike hendelser, velg et område utenfor din primære geo for å øke sannsynligheten for tilgjengelighet av databehandlingstjenester. For informasjon om å opprette en kapasitet, se Buy Fabric capacity i Azure.

  2. Opprett arbeidsområder i den nyopprettede kapasiteten. Om nødvendig, bruk de samme navnene som de gamle arbeidsområdene.

  3. Lag gjenstander med samme navn som de du ønsker å gjenvinne. Dette steget er viktig hvis du bruker det tilpassede skriptet for å gjenopprette innsjøhus og lagerbygninger.

  4. Restaurer gjenstandene. For hvert element, følg den relevante seksjonen i Experience-spesifikke katastrofegjenopprettingsveiledningen for å gjenopprette gjenstanden.

Neste trinn

  • Last updated on