Tillförlitlighet i Microsoft Fabric

Denna artikel beskriver tillförlitlighetsstöd i Microsoft Fabric, inklusive både regional motståndskraft med tillgänglighetszoner samt återställning och affärskontinuitet över regioner. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Tillgänglighetszonsstöd

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Fabric använder Azure-tillgänglighetszoner för att skydda Fabric- och Power BI-objekt och data från datacenterfel. Tjänsten distribuerar automatiskt Fabric-resurser över flera zoner utan att behöva någon kundkonfiguration.

  • Datateknik stöder tillgänglighetszoner om du använder OneLake. Om du använder andra datakällor, till exempel ADLS Gen2, måste du se till att zonredundant lagring (ZRS) är aktiverat.

Avslappnande upplevelse

Under ett zonomfattande avbrott krävs ingen kundåtgärd. Infrastrukturkapaciteterna självläker och återbalanseras automatiskt för att dra nytta av den felfria zonen. I vissa fall kan pågående verksamheter behöva starta om. Till exempel kan körning av Spark Jobs misslyckas om den primära noden befinner sig i den felade zonen. I ett sådant fall måste du skicka in jobben på nytt. Data warehouse- och SQL-analysändpunktsfrågor kan misslyckas om frontend-noden är i den felade zonen. I ett sådant fall behöver du säkert starta om sökningen.

Important

Medan Microsoft strävar efter att tillhandahålla enhetlig och konsekvent stöd för tillgänglighetszoner kan fabric-kapaciteter som finns i Azure-regioner med högre variationer i kundefterfrågan i vissa fall av fel i tillgänglighetszonen uppleva högre svarstid än normalt.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap (DR) refererar till metoder som organisationer använder för att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar skapa din haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

För DR använder Microsoft shared responsibility-modellen. I den här modellen ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Många Azure-tjänster replikerar dock inte data automatiskt eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på Azure PaaS-erbjudanden (Plattform som en tjänst) ger funktioner och vägledning för att stödja DR. Du kan använda de tjänstspecifika funktionerna i till att underlätta snabb återställning för att hjälpa till att utveckla din DR-plan.

I det här avsnittet beskrivs en haveriberedskapsplan för Fabric som är utformad för att hjälpa din organisation att hålla sina data säkra och tillgängliga vid en oväntad regional katastrof. Planen beskriver följande ämnen:

  • Cross-region-replikering: Fabric erbjuder replikering mellan regioner för data som finns lagrad i OneLake. Du kan välja att delta i eller bort från den här funktionen baserat på dina krav.

  • Dataåtkomst efter haveri: I ett regionalt katastrofscenario garanterar Fabric dataåtkomst med vissa begränsningar. Även om skapandet eller ändringen av nya objekt är begränsad efter redundansväxlingen ligger det primära fokuset på att se till att befintliga data förblir tillgängliga och intakta.

  • Vägledning för återställning: Fabric ger en strukturerad uppsättning instruktioner som vägleder dig genom återställningsprocessen. Den strukturerade vägledningen gör det enklare för dig att gå tillbaka till vanliga åtgärder.

Power BI, som nu är en del av infrastrukturresurserna, har ett stabilt haveriberedskapssystem på plats och erbjuder följande funktioner:

  • BCDR som standard: Om en region är parerad med en region som stöder Power BI ingår haveriberedskapsfunktioner som standard. Du behöver inte anmäla dig eller aktivera den här funktionen separat.

  • Replikering mellan regioner: Power BI använder geo-redundant replikering i Azure Storage och geo-redundant Replikering i Azure SQL för att garantera att säkerhetskopieringsinstanser finns i andra regioner och kan användas. Det innebär att data dupliceras i olika regioner, vilket ökar tillgängligheten och minskar riskerna med regionala avbrott.

  • Fortsatta tjänster och åtkomst efter haveri: Även under störande händelser förblir Power BI-objekt tillgängliga i skrivskyddat läge. Objekt inkluderar semantiska modeller, rapporter och instrumentpaneler, vilket säkerställer att företag kan fortsätta sina analys- och beslutsprocesser utan betydande hinder.

Mer information finns i vanliga frågor om Power BI, hög tillgänglighet, redundansväxling och katastrofåterställning.

Important

För kunder som drabbats av en katastrof och vars hemregioner inte har en Azure-parad region som stödjer Fabric, kan möjligheten att använda Fabric-kapaciteter bli komprometterad, även om datan inom dessa kapaciteter replikeras. Denna begränsning är kopplad till hemregionens infrastruktur, som är avgörande för kapacitetens drift. Om du vill se listan över regioner som stöder Fabric går du till Fabric Region Availability.

Funktionalitet för hemregion och kapacitet

För effektiv planering av haveriberedskap är det viktigt att du förstår relationen mellan din hemregion och kapacitetsplatser. Genom att förstå platser för hemregion och kapacitet kan du göra strategiska val av kapacitetsregioner, samt motsvarande replikerings- och återställningsprocesser.

Huvudregionen för din organisations hyresavtal och datalagring är inställd till faktureringsadressen för den första användaren som registrerar sig. Mer information om hyresgästkonfiguration finns i Implementeringsplanering för Power BI: Hyresgästkonfiguration. När du skapar nya kapaciteter är datalagringen inställd på hemregionen som standard. Om du vill byta din datalagringsregion till en annan region behöver du aktivera Multi-Geo, en Fabric Premium-funktion.

Important

Om du väljer en annan region för din kapacitet flyttas inte alla dina data helt till den regionen. Vissa dataelement lagras fortfarande i hemregionen. Information om vilka data som finns kvar i hemregionen och vilka data som lagras i den Multi-Geo-aktiverade regionen finns i Konfigurera Multi-Geo-stöd för Fabric Premium.

I fallet med en hemregion som inte har en parad region kan kapaciteter i vilken Multi-Geo-aktiverad region som helst få operativa problem om hemregionen råkar ut för en katastrof, eftersom kärnfunktionaliteten är kopplad till hemregionen.

Om du väljer en Multi-Geo-aktiverad region inom EU är det garanterat att dina data lagras inom EU:s datagräns.

Information om hur du identifierar din hemregion finns i Hitta din Fabric-hemregion.

Kapacitetsinställning för katastrofåterställning

Fabric tillhandahåller en återställningsknapp på kapacitetsinställningssidan. Det är tillgängligt där regionala Azure-parkopplingar överensstämmer med Fabrics tjänstnärvaro. Här är detaljerna i den här växeln:

  • Rollåtkomst: Endast användare med kapacitetsadministratörsrollen eller högre kan använda den här växeln.

  • Kornighet: Kornigheten för växeln är kapacitetsnivån. Den är tillgänglig för både Premium- och Fabric-kapaciteter.

  • Dataomfång: Växlingsknappen för katastrofåterställning berör specifikt OneLake-data, som inkluderar Lakehouse- och Warehouse-datavolymer. Switchen påverkar inte din data som lagras utanför OneLake.

  • BCDR-kontinuitet för Power BI: Även om du kan slå på och av katastrofåterställning för OneLake-data, stöds BCDR för Power BI alltid, oavsett om strömbrytaren är på eller av.

  • Frekvens: När du ändrar inställningen för katastrofåterställningskapacitet måste du vänta 30 dagar innan du kan ändra den igen. Väntetiden bibehåller stabiliteten och förhindrar ständiga växlingar.

Skärmbild av klientinställningen för katastrofåterställning.

Note

Efter att ha aktiverat katastrofåterställningskapaciteten eller skapat nya arbetsytor inom kapaciteten kan datareplikering ta tid att starta. Du kan kontrollera statusen för varje arbetsyta på sidan kapacitetsinställningar under Arbetsytor som tilldelats den här kapaciteten. Kolumnen OneLake Geo-replikering visar status för aktivering av geo-replikering.

Datakopiering

När du aktiverar kapacitetsinställningen för haveriberedskap aktiveras replikering mellan regioner som en haveriberedskapsfunktion för OneLake-data. Fabric-plattformen anpassar sig efter Azure-regionerna för att skapa par för geo-redundans. Vissa regioner har dock ingen Azure-parregion, eller parregionen stöder inte Fabric. För dessa regioner är datareplikering inte tillgänglig. Mer information finns i Regioner med tillgänglighetszoner och inget regionpar och infrastrukturområdestillgänglighet.

Note

Fabric erbjuder en datareplikeringslösning i OneLake för att stödja haveriberedskap, men det finns betydande begränsningar. Till exempel lagras data för KQL-databaser och frågeuppsättningar externt till OneLake, vilket innebär att en separat haveriberedskapsmetod behövs. Se resten av detta dokument för detaljer om katastrofåterställningsstrategin för varje Fabric-komponent.

Billing

Haveriberedskapsfunktionen i Fabric möjliggör geo-replikering av dina data för ökad säkerhet och tillförlitlighet. Den här funktionen förbrukar mer lagring och transaktioner, som faktureras som BCDR Storage respektive BCDR-åtgärder. Du kan övervaka och hantera dessa kostnader i appen Kapacitetsmått för Microsoft Fabric, där de visas som separata radobjekt.

En fullständig uppdelning av alla associerade haveriberedskapskostnader som hjälper dig att planera och budgeta i enlighet med detta finns i OneLake-beräkning och lagringsförbrukning.

Konfigurera haveriberedskap

Medan Fabric tillhandahåller haveriberedskapsfunktioner för att stödja datasäkerhet, måste du följa vissa manuella steg för att återuppta tjänsten vid avbrott. Det här avsnittet beskriver de åtgärder som du bör vidta för att förbereda dig för potentiella störningar.

Fas 1: Förbereda

  • Aktivera kapacitetsinställningarna för haveriberedskap: Granska och ange regelbundet kapacitetsinställningarna för haveriberedskap för att se till att de uppfyller dina skydds- och prestandabehov.

  • Skapa datasäkerhetskopior: Kopiera kritiska data som lagras utanför OneLake till en annan region på ett sätt som överensstämmer med din haveriberedskapsplan.

Fas 2: Haveriberedskap

När en stor katastrof gör primärregionen oåterkallelig initierar Microsoft Fabric en regional failover. Du kan inte komma åt Fabric-portalen förrän failovern är klar. En notis publiceras på Microsoft Fabric-supportsidan.

Den tid det tar för omkopplingen att slutföras kan variera, även om det vanligtvis tar mindre än en timme. När redundansväxlingen är klar kan du förvänta dig följande:

  • Infrastrukturportal: Du kan komma åt portalen, och operationer som att bläddra i befintliga arbetsytor, uppgiftsflöden i arbetsytor, och objekt fortsätter att fungera. Alla skrivåtgärder, till exempel att skapa eller ändra en arbetsyta, pausas.

  • Power BI: Du kan utföra läsåtgärder, till exempel att visa instrumentpaneler och rapporter. Uppdateringar, rapportpubliceringar, ändringar av instrumentpaneler och rapporter samt andra åtgärder som kräver ändringar i metadata stöds inte.

  • Lakehouse/Warehouse: Du kan inte öppna dessa objekt, men du kan komma åt filer via OneLake-API:er eller verktyg.

  • Spark-jobbdefinition: Du kan inte öppna Spark-jobbdefinitioner, men du kan komma åt kodfiler via OneLake-API:er eller verktyg. All metadata eller konfiguration sparas efter failover.

  • Anteckningsbok: Du kan inte öppna anteckningsböcker, och kodinnehållet sparas inte efter katastrofen.

  • ML-modell/experiment: Du kan inte öppna ML-modeller eller experiment. Kodinnehåll och metadata som körningsmått och konfigurationer sparas inte efter katastrofen.

  • Dataflöde Gen2/Pipeline/Eventstream: Du kan inte öppna dessa enheter, men du kan använda konfigurerade katastrofåterställningsdestinationer (lakehouses eller datalager) för att skydda data.

  • KQL-databas/frågeset: Du kan inte komma åt KQL-databaser och frågeuppsättningar efter failover. Fler nödvändiga steg krävs för att skydda data i KQL-databaser och frågeuppsättningar.

I ett katastrofscenario är Fabric-portalen och Power BI i skrivskyddat läge, och andra Fabric-objekt är otillgängliga. Du kan komma åt deras data som lagras i OneLake genom att använda API:er eller tredjepartsverktyg. Både portalen och Power BI behåller möjligheten att utföra skrivåtgärder på dessa data. Den här möjligheten säkerställer att kritiska data förblir tillgängliga och ändringsbara och minimerar potentiella avbrott i din verksamhet.

Du kan komma åt OneLake-data via flera kanaler:

  • OneLake ADLS Gen2 API: Se Ansluta till Microsoft OneLake

  • Exempel på verktyg som kan ansluta till OneLake-data:

  • I ett katastrofscenario är OneLake-katalogen i skrivskyddat läge:

    • Fliken Utforska: Du kan öppna fliken Utforska för att visa alla objekt och arbetsytor, inklusive deras metadata och relaterad information.

    • Fliken Styrning: Du kan komma åt fliken Styrning för att visa insikter, rekommenderade åtgärder och styrningsverktyg – baserat på den senaste lyckade modelluppdateringen före redundansväxlingen.

Fas 3: Återställningsplan

Även om Fabric ser till att data förblir tillgängliga efter en katastrof, kan du också agera för att helt återställa deras tjänster till tillståndet före incidenten. Det här avsnittet innehåller en stegvis guide som hjälper dig genom återställningsprocessen.

Återställningssteg

  1. Skapa en ny Fabric-kapacitet i valfri region efter en katastrof. Med tanke på den höga efterfrågan under sådana händelser, välj en region utanför din primära geo för att öka sannolikheten för tillgång till beräkningstjänster. För information om hur du skapar en kapacitet, se Buy Fabric capacity i Azure.

  2. Skapa arbetsytor i den nya kapaciteten. Använd vid behov samma namn som de gamla arbetsytorna.

  3. Skapa objekt med samma namn som de som du vill återställa. Det här steget är viktigt om du använder det anpassade skriptet för att återställa lakehouses och lagerhus.

  4. Återställ objekten. För varje post, följ det relevanta avsnittet i Upplevelsespecifik vägledning för katastrofåterställning för att återställa posten.

Nästa steg

  • Last updated on