Tillförlitlighet i Microsoft Fabric

  • Artikel

Den här artikeln beskriver tillförlitlighetsstöd i Microsoft Fabric och både regional återhämtning med tillgänglighetszoner och återställning mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.

Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.

Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

Infrastrukturresurser gör kommersiellt rimliga ansträngningar för att stödja zonredundanta tillgänglighetszoner, där resurser automatiskt replikeras mellan zoner, utan att du behöver konfigurera eller konfigurera.

Förutsättningar

  • Infrastrukturresurser tillhandahåller för närvarande stöd för partiell tillgänglighetszon i ett begränsat antal regioner. Det här partiella stödet för tillgänglighetszoner omfattar upplevelser (och/eller vissa funktioner i en upplevelse).
  • Funktioner som Data Factory (pipelines), Datateknik, Datavetenskap och Event Flöden stöder inte tillgänglighetszoner.
  • Zontillgänglighet kanske eller kanske inte är tillgänglig för infrastrukturresurser eller funktioner som är i förhandsversion.
  • Lokala gatewayer och stora semantiska modeller i Power BI stöder inte tillgänglighetszoner.

Regioner som stöds

Infrastrukturresurser gör kommersiellt rimliga ansträngningar för att tillhandahålla stöd för tillgänglighetszoner i olika regioner på följande sätt:

Nord- och Sydamerika Power BI Datamarter Informationslager Realtidsanalys
Brasilien, södra
Kanada, centrala
Central US
East US
USA, östra 2
USA, södra centrala
USA, västra 2
USA, västra 3
Europa Power BI Datamarter Informationslager Realtidsanalys
Frankrike, centrala
Tyskland, västra centrala
Europa, norra
Storbritannien, södra
Europa, västra
Norge, östra
Mellanöstern Power BI Datamarter Informationslager Realtidsanalys
Qatar, centrala
Afrika Power BI Datamarter Informationslager Realtidsanalys
Sydafrika, norra
Asien och stillahavsområdet Power BI Datamarter Informationslager Realtidsanalys
Australien, östra
Japan, östra
Sydostasien

Zon-ned-upplevelse

Under ett zonomfattande avbrott krävs ingen åtgärd under zonåterställning. Infrastrukturfunktioner i regioner som anges i regioner som stöds läker automatiskt och balanserar om automatiskt för att dra nytta av den felfria zonen.

Viktigt!

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 handlar om 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 fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data 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å PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

I det här avsnittet beskrivs en haveriberedskapsplan för Infrastrukturresurser som är utformad för att hjälpa din organisation att hålla sina data säkra och tillgängliga när en oplanerad regional katastrof inträffar. Planen beskriver följande ämnen:

  • Replikering mellan regioner: Infrastrukturresurser erbjuder replikering mellan regioner för data som lagras 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: Infrastrukturresurser innehåller 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: Power BI innehåller automatiskt funktioner för haveriberedskap i standarderbjudandet. 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 och svar om hög tillgänglighet, redundans och haveriberedskap i Power BI

Viktigt!

För kunder vars hemregioner inte har en Azure-parregion och som påverkas av en katastrof kan möjligheten att använda infrastrukturresurser komprometteras – även om data i dessa kapaciteter replikeras. Den här begränsningen är kopplad till hemregionens infrastruktur, som är nödvändig för kapaciteternas drift.

Funktioner 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.

Hemregionen för organisationens innehavar- och datalagring är inställd på faktureringsadressen för den första användaren som registrerar sig. Mer information om klientkonfiguration finns i Implementeringsplanering för Power BI: Klientkonfiguration. När du skapar nya kapaciteter är datalagringen inställd på hemregionen som standard. Om du vill ändra datalagringsregionen till en annan region måste du aktivera Multi-Geo, en Fabric Premium-funktion.

Viktigt!

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.

När det gäller en hemregion som inte har en länkad region kan kapaciteter i alla Multi-Geo-aktiverade regioner drabbas av driftsproblem om hemregionen drabbas av en katastrof, eftersom kärntjänstens funktioner är bundna 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 infrastrukturresurs.

Kapacitetsinställning för haveriberedskap

Fabric tillhandahåller en haveriberedskapsväxel på sidan kapacitetsinställningar. 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 haveriberedskap adresserar specifikt OneLake-data, som innehåller Lakehouse- och Warehouse-data. Växeln påverkar inte dina data som lagras utanför OneLake.

  • BCDR-kontinuitet för Power BI: Även om haveriberedskap för OneLake-data kan aktiveras och inaktiveras, stöds alltid BCDR för Power BI, oavsett om växeln är på eller av.

  • Frekvens: När du har ändrat kapacitetsinställningen för haveriberedskap måste du vänta 30 dagar innan du kan ändra den igen. Väntetiden är inställd på plats för att upprätthålla stabiliteten och förhindra konstant växling,

Screenshot of the disaster recovery tenant setting.

Kommentar

När du har aktiverat kapacitetsinställningen för haveriberedskap kan det ta upp till 72 timmar innan data börjar replikeras.

Datareplikering

När du aktiverar kapacitetsinställningen för haveriberedskap aktiveras replikering mellan regioner som en haveriberedskapsfunktion för OneLake-data. Fabric-plattformen överensstämmer med Azure-regioner för att etablera geo-redundansparen. Vissa regioner har dock ingen Azure-parregion, eller så stöder inte parregionen Infrastrukturresurser. För dessa regioner är datareplikering inte tillgängligt. Mer information finns i Regioner med tillgänglighetszoner och inget regionpar och infrastrukturområdestillgänglighet.

Kommentar

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. Mer information om haveriberedskapsmetoden för varje infrastrukturobjekt finns i resten av det här dokumentet.

Fakturering

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

Infrastrukturresurser tillhandahåller funktioner för haveriberedskap för att stödja dataåterhämtning, men du måste följa vissa manuella steg för att återställa tjänsten under 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örbered

  • 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 större katastrof gör att den primära regionen inte kan återställas initierar Microsoft Fabric en regional redundansväxling. Åtkomst till Fabric-portalen är inte tillgänglig förrän redundansväxlingen har slutförts och ett meddelande har publicerats på supportsidan för Microsoft Fabric.

Den tid det tar för redundansväxlingen 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 läsåtgärder som att bläddra bland befintliga 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 filer kan nås via OneLake-API:er eller verktyg.

  • Spark-jobbdefinition: Du kan inte öppna Spark-jobbdefinitioner, men kodfiler kan nås via OneLake-API:er eller verktyg. Metadata eller konfigurationer sparas efter redundansväxling.

  • Notebook: Du kan inte öppna notebook-filer och kodinnehåll 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 objekt, men du kan använda katastrofåterställningsmål som stöds (lakehouses eller lager) för att skydda data.

  • KQL-databas/frågeuppsättning: Du kommer inte att kunna komma åt KQL-databaser och frågeuppsättningar efter redundansväxling. 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 infrastrukturobjekt är inte tillgängliga. Du kan komma åt deras data som lagras i OneLake med hjälp av API:er eller verktyg från tredje part. 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.

OneLake-data är fortfarande tillgängliga via flera kanaler:

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 infrastrukturkapacitet i valfri region efter en katastrof. Med tanke på den höga efterfrågan under sådana händelser rekommenderar vi att du väljer en region utanför din primära geo för att öka sannolikheten för tillgänglighet för beräkningstjänsten. Information om hur du skapar en kapacitet finns i Köpa en Microsoft Fabric-prenumeration.

  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 lager.

  4. Återställ objekten. För varje objekt följer du det relevanta avsnittet i vägledningen för upplevelsespecifik haveriberedskap för att återställa objektet.

Nästa steg