Delen via

Betrouwbaarheid in Microsoft Fabric

  • Artikel

In dit artikel wordt ondersteuning voor betrouwbaarheid in Microsoft Fabric beschreven, en zowel regionale tolerantie met beschikbaarheidszones als herstel in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's voor meer informatie over zone-redundante architectuur en zone-redundante architectuur.

Fabric doet commercieel redelijke inspanningen om zone-redundante beschikbaarheidszones te ondersteunen, waarbij resources automatisch tussen zones worden gerepliceerd, zonder dat u hoeft in te stellen of te configureren.

Vereisten

  • Fabric biedt momenteel ondersteuning voor gedeeltelijke beschikbaarheidszones in een beperkt aantal regio's. Deze ondersteuning voor gedeeltelijke beschikbaarheidszone omvat ervaringen (en/of bepaalde functionaliteiten binnen een ervaring).
  • Ervaringen zoals Gebeurtenisstromen bieden geen ondersteuning voor beschikbaarheidszones.
  • Data engineering ondersteunt beschikbaarheidszones als u OneLake gebruikt. Als u andere gegevensbronnen zoals ADLS Gen2 gebruikt, moet u ervoor zorgen dat Zone-redundante opslag (ZRS) is ingeschakeld.
  • Beschikbaarheid van zones is mogelijk of niet beschikbaar voor Fabric-ervaringen en/of functies/functies die in preview zijn.
  • On-premises gateways en grote semantische modellen in Power BI bieden geen ondersteuning voor beschikbaarheidszones.
  • Data Factory (pijplijnen) ondersteunen beschikbaarheidszones in Europa - west, maar nieuwe of inprogresse pijplijnen kunnen mislukken in het geval van een storing in de zone.

Ondersteunde regio’s

Fabric doet commercieel redelijke inspanningen om ondersteuning voor beschikbaarheidszones in verschillende regio's te bieden:

Noord- en Zuid-Amerika Power BI Datamarts Datawarehouses Realtime analyse Data Factory (pijplijnen) Data-engineer ing
Brazilië - zuid
Canada - midden
VS - centraal
VS - oost
VS - oost 2
VS - zuid-centraal
VS - west 2
US - west 3
Europa
Frankrijk - centraal
Duitsland - west-centraal
Italië - noord
Europa - noord
Noorwegen - oost
Polen - centraal
Verenigd Koninkrijk Zuid
Europa -west
Midden-Oosten
Qatar - centraal
Israël - centraal
Afrika
Zuid-Afrika - noord
Azië en Stille Oceaan
Australië - oost
Japan East
Azië - zuidoost

Zone-down-ervaring

Tijdens een zonebrede storing is er geen actie vereist tijdens zoneherstel. Infrastructuurmogelijkheden in regio's die in ondersteunde regio's worden vermeld, herstellen en automatisch opnieuw verdelen om te profiteren van de gezonde zone. Het uitvoeren van Spark-taken kan mislukken als het hoofdknooppunt zich in de mislukte zone bevindt. In dat geval moeten de taken opnieuw worden ingediend.

Belangrijk

Hoewel Microsoft ernaar streeft om uniforme en consistente ondersteuning voor beschikbaarheidszones te bieden, kunnen infrastructuurcapaciteiten in Azure-regio's met hogere vraagschommelingen van klanten een hogere latentie ervaren dan normale latentie.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

In deze sectie wordt een plan voor herstel na noodgevallen beschreven voor Fabric dat is ontworpen om uw organisatie te helpen de gegevens veilig en toegankelijk te houden wanneer er zich een ongeplande regionale ramp voordoet. In het plan worden de volgende onderwerpen behandeld:

  • Replicatie tussen regio's: Fabric biedt replicatie tussen regio's voor gegevens die zijn opgeslagen in OneLake. U kunt deze functie in- of uitschakelen op basis van uw vereisten.

  • Gegevenstoegang na noodgeval: In een regionaal noodscenario garandeert Fabric gegevenstoegang, met bepaalde beperkingen. Hoewel het maken of wijzigen van nieuwe items na een failover wordt beperkt, blijft de primaire focus behouden om ervoor te zorgen dat bestaande gegevens toegankelijk en intact blijven.

  • Richtlijnen voor herstel: Fabric biedt een gestructureerde set instructies om u door het herstelproces te leiden. Met de gestructureerde richtlijnen kunt u gemakkelijker terugkeren naar normale bewerkingen.

Power BI, nu onderdeel van de Infrastructuur, heeft een solide systeem voor herstel na noodgevallen en biedt de volgende functies:

  • BCDR als standaardinstelling: Power BI bevat automatisch mogelijkheden voor herstel na noodgevallen in de standaardaanbiedingen. U hoeft deze functie niet afzonderlijk aan te geven of te activeren.

  • Replicatie tussen regio's: Power BI maakt gebruik van geografisch redundante replicatie van Azure Storage en geo-redundante replicatie van Azure SQL om te garanderen dat back-upexemplaren in andere regio's aanwezig zijn en kunnen worden gebruikt. Dit betekent dat gegevens worden gedupliceerd in verschillende regio's, de beschikbaarheid ervan verbeteren en de risico's verminderen die verband houden met regionale storingen.

  • Continue services en toegang na noodgeval: Zelfs tijdens verstorende gebeurtenissen blijven Power BI-items toegankelijk in de modus Alleen-lezen. Items omvatten semantische modellen, rapporten en dashboards, zodat bedrijven hun analyse- en besluitvormingsprocessen kunnen voortzetten zonder aanzienlijke hinder.

Zie de veelgestelde vragen over hoge beschikbaarheid, failover en herstel na noodgevallen in Power BI voor meer informatie

Belangrijk

Voor klanten waarvan de thuisregio's geen Azure-paarregio hebben en worden beïnvloed door een noodgeval, kan de mogelijkheid om fabric-capaciteiten te gebruiken worden aangetast, zelfs als de gegevens binnen deze capaciteiten worden gerepliceerd. Deze beperking is gekoppeld aan de infrastructuur van de thuisregio, die essentieel is voor de werking van de capaciteiten.

Functionaliteit voor thuisregio's en capaciteit

Voor een effectieve planning voor herstel na noodgevallen is het essentieel dat u de relatie tussen uw thuisregio en capaciteitslocaties begrijpt. Inzicht in thuisregio's en capaciteitslocaties helpt u bij het maken van strategische selecties van capaciteitsregio's, evenals de bijbehorende replicatie- en herstelprocessen.

De thuisregio voor de tenant en gegevensopslag van uw organisatie is ingesteld op de locatie van het factuuradres van de eerste gebruiker die zich registreert. Voor meer informatie over het instellen van tenancy gaat u naar de planning van de Power BI-implementatie: Tenantinstallatie. Wanneer u nieuwe capaciteiten maakt, wordt uw gegevensopslag standaard ingesteld op de thuisregio. Als u uw gegevensopslagregio wilt wijzigen in een andere regio, moet u Multi-Geo, een Fabric Premium-functie inschakelen.

Belangrijk

Als u een andere regio voor uw capaciteit kiest, worden niet al uw gegevens volledig verplaatst naar die regio. Sommige gegevenselementen blijven nog steeds opgeslagen in de thuisregio. Zie Multi-Geo-ondersteuning configureren voor Fabric Premium om te zien welke gegevens zich in de regio met meerdere geografische gebieden bevinden en welke gegevens worden opgeslagen in de regio met meerdere geografische gebieden.

In het geval van een thuisregio die geen gekoppelde regio heeft, kunnen capaciteiten in een regio met meerdere geografische gebieden operationele problemen ondervinden als de thuisregio een noodgeval ondervindt, omdat de kernservicefunctionaliteit wordt gekoppeld aan de thuisregio.

Als u een regio met meerdere geografische gebieden binnen de EU selecteert, is het gegarandeerd dat uw gegevens worden opgeslagen binnen de eu-gegevensgrens.

Zie Uw fabric-thuisregio zoeken voor meer informatie over het identificeren van uw thuisregio.

Instelling voor noodherstelcapaciteit

Fabric biedt een schakeloptie voor herstel na noodgevallen op de pagina capaciteitsinstellingen. Deze is beschikbaar wanneer regionale azure-koppeling overeenkomt met de aanwezigheid van de service van Fabric. Hier volgen de specifieke kenmerken van deze switch:

  • Roltoegang: Alleen gebruikers met de rol capaciteitsbeheerder of hoger kunnen deze switch gebruiken.

  • Granulariteit: de granulariteit van de switch is het capaciteitsniveau. Het is beschikbaar voor zowel Premium- als Fabric-capaciteiten.

  • Gegevensbereik: De wisselknop voor herstel na noodgevallen heeft specifiek betrekking op OneLake-gegevens, waaronder Lakehouse- en Warehouse-gegevens. De switch heeft geen invloed op uw gegevens die buiten OneLake zijn opgeslagen.

  • BCDR-continuïteit voor Power BI: hoewel herstel na noodgevallen voor OneLake-gegevens kan worden in- en uitgeschakeld, wordt BCDR voor Power BI altijd ondersteund, ongeacht of de schakelaar is ingeschakeld of uitgeschakeld.

  • Frequentie: Nadat u de instelling voor noodherstelcapaciteit hebt gewijzigd, moet u 30 dagen wachten voordat u deze opnieuw kunt wijzigen. De wachttijd is ingesteld om stabiliteit te behouden en constante wisselknop te voorkomen;

Schermopname van de tenantinstelling voor herstel na noodgevallen.

Notitie

Nadat u de instelling voor noodherstelcapaciteit hebt ingeschakeld, kan het tot één week duren voordat de gegevens worden gerepliceerd.

Gegevensreplicatie

Wanneer u de instelling voor noodherstelcapaciteit inschakelt, wordt replicatie tussen regio's ingeschakeld als noodherstelmogelijkheid voor OneLake-gegevens. Het Fabric-platform is afgestemd op Azure-regio's om de georedundantieparen in te richten. Sommige regio's hebben echter geen Azure-paarregio of de paarregio biedt geen ondersteuning voor Fabric. Voor deze regio's is gegevensreplicatie niet beschikbaar. Zie Regio's met beschikbaarheidszones en geen regiopaar en beschikbaarheid van infrastructuurregio's voor meer informatie.

Notitie

Hoewel Fabric een oplossing voor gegevensreplicatie in OneLake biedt ter ondersteuning van herstel na noodgevallen, zijn er aanzienlijke beperkingen. De gegevens van KQL-databases en -querysets worden bijvoorbeeld extern opgeslagen in OneLake, wat betekent dat er een afzonderlijke benadering voor herstel na noodgevallen nodig is. Raadpleeg de rest van dit document voor meer informatie over de aanpak voor herstel na noodgevallen voor elk Fabric-item.

Billing

De functie voor herstel na noodgevallen in Fabric maakt geo-replicatie van uw gegevens mogelijk voor verbeterde beveiliging en betrouwbaarheid. Deze functie verbruikt meer opslag en transacties, die respectievelijk worden gefactureerd als BCDR-opslag en BCDR-bewerkingen. U kunt deze kosten bewaken en beheren in de microsoft Fabric Capacity Metrics-app, waar ze worden weergegeven als afzonderlijke regelitems.

Zie OneLake-reken- en opslagverbruik voor een uitgebreide uitsplitsing van alle bijbehorende kosten voor herstel na noodgevallen, zodat u dienovereenkomstig kunt plannen en budgetteren.

Herstel na noodgeval instellen

Hoewel Fabric functies voor herstel na noodgevallen biedt ter ondersteuning van gegevenstolerantie, moet u bepaalde handmatige stappen volgen om de service te herstellen tijdens onderbrekingen. In deze sectie worden de acties beschreven die u moet uitvoeren om u voor te bereiden op mogelijke onderbrekingen.

Fase 1: Voorbereiden

  • Activeer de instellingen voor noodherstelcapaciteit: controleer en stel de instellingen voor noodherstelcapaciteit regelmatig in om ervoor te zorgen dat ze voldoen aan uw beveiligings- en prestatiebehoeften.

  • Gegevensback-ups maken: kopieer kritieke gegevens die buiten OneLake zijn opgeslagen naar een andere regio op een manier die overeenkomt met uw plan voor herstel na noodgevallen.

Fase 2: Failover na noodgevallen

Wanneer een grote noodgeval de primaire regio onherstelbaar maakt, start Microsoft Fabric een regionale failover. Toegang tot de Fabric-portal is niet beschikbaar totdat de failover is voltooid en er een melding wordt geplaatst op de ondersteuningspagina van Microsoft Fabric.

De tijd die nodig is om de failover te voltooien, kan variëren, hoewel het doorgaans minder dan één uur duurt. Zodra de failover is voltooid, kunt u het volgende verwachten:

  • Infrastructuurportal: U hebt toegang tot de portal en leesbewerkingen, zoals het bladeren door bestaande werkruimten en items, blijven werken. Alle schrijfbewerkingen, zoals het maken of wijzigen van een werkruimte, worden onderbroken.

  • Power BI: U kunt leesbewerkingen uitvoeren, zoals het weergeven van dashboards en rapporten. Vernieuwingen, publicatiebewerkingen voor rapporten, wijzigingen in dashboards en rapporten en andere bewerkingen waarvoor wijzigingen in metagegevens zijn vereist, worden niet ondersteund.

  • Lakehouse/Warehouse: u kunt deze items niet openen, maar bestanden zijn toegankelijk via OneLake-API's of hulpprogramma's.

  • Spark-taakdefinitie: U kunt Spark-taakdefinities niet openen, maar codebestanden zijn toegankelijk via OneLake-API's of hulpprogramma's. Metagegevens of configuraties worden na een failover opgeslagen.

  • Notitieblok: u kunt geen notitieblokken openen en code-inhoud wordt niet opgeslagen na het noodgeval.

  • ML-model/experiment: u kunt ML-modellen of -experimenten niet openen. Code-inhoud en metagegevens, zoals metrische gegevens en configuraties uitvoeren, worden niet opgeslagen na het noodgeval.

  • Gegevensstroom Gen2/Pipeline/Eventstream: u kunt deze items niet openen, maar u kunt ondersteunde bestemmingen voor herstel na noodgevallen (lakehouses of magazijnen) gebruiken om gegevens te beveiligen.

  • KQL Database/Queryset: U hebt geen toegang tot KQL-databases en querysets na een failover. Er zijn meer vereiste stappen vereist voor het beveiligen van de gegevens in KQL-databases en -querysets.

In een noodscenario bevinden de Fabric-portal en Power BI zich in de modus Alleen-lezen en andere Fabric-items zijn niet beschikbaar. U hebt toegang tot hun gegevens die zijn opgeslagen in OneLake met behulp van API's of hulpprogramma's van derden. Zowel portal als Power BI behouden de mogelijkheid om lees-schrijfbewerkingen uit te voeren op die gegevens. Deze mogelijkheid zorgt ervoor dat kritieke gegevens toegankelijk en wijzigbaar blijven en mogelijke onderbrekingen van uw bedrijfsactiviteiten beperken.

OneLake-gegevens blijven toegankelijk via meerdere kanalen:

Fase 3: Herstelplan

Hoewel Fabric ervoor zorgt dat gegevens toegankelijk blijven na een noodgeval, kunt u ook actie ondernemen om hun services volledig te herstellen naar de status vóór het incident. Deze sectie bevat een stapsgewijze handleiding om u te helpen bij het herstelproces.

Herstelstappen

  1. Maak een nieuwe Infrastructuurcapaciteit in elke regio na een noodgeval. Gezien de hoge vraag tijdens dergelijke gebeurtenissen, raden we u aan een regio buiten uw primaire geografische regio te selecteren om de kans op beschikbaarheid van de rekenservice te vergroten. Zie Een Microsoft Fabric-abonnement kopen voor meer informatie over het maken van een capaciteit.

  2. Werkruimten maken in de zojuist gemaakte capaciteit. Gebruik indien nodig dezelfde namen als de oude werkruimten.

  3. Maak items met dezelfde namen als de items die u wilt herstellen. Deze stap is belangrijk als u het aangepaste script gebruikt om lakehouses en magazijnen te herstellen.

  4. Herstel de items. Volg voor elk item de relevante sectie in de richtlijnen voor herstel na noodgevallen die specifiek zijn voor het herstellen van het item.

Volgende stappen