Ervaringsspecifieke richtlijnen voor herstel na noodgevallen

Dit document bevat ervaringsspecifieke richtlijnen voor het herstellen van uw Fabric gegevens in het geval van een regionale ramp.

Voorbeeldscenario

Veel richtlijnen in dit document gebruiken het volgende voorbeeldscenario voor uitleg en illustratie. Raadpleeg dit scenario indien nodig.

Stel dat u een capaciteit C1 in regio A hebt met een werkruimte W1. Wanneer u herstel na noodgevallen heeft ingeschakeld voor capaciteit C1, worden de OneLake-gegevens gerepliceerd naar een back-up in regio B. Als regio A onderbrekingen ondervindt, schakelt de Fabric-service in C1 over naar regio B.

In de volgende afbeelding ziet u dit scenario. In het vak aan de linkerkant ziet u de verstoorde regio. Het vak in het midden vertegenwoordigt de voortdurende beschikbaarheid van de gegevens na een failover en het vak aan de rechterkant toont de volledig gedekte situatie nadat de klant heeft deelgenomen aan het herstellen van hun services naar volledige functie.

Dit is het algemene herstelplan:

1. Maak een nieuwe Fabric-netwerkcapaciteit C2 in een nieuwe regio.

2. Maak een nieuwe W2-werkruimte in C2, inclusief de bijbehorende items met dezelfde namen als in C1. W1.

3. Kopieer gegevens van de verstoorde C1.W1 naar C2.W2.

4. Volg de speciale instructies voor elk onderdeel om items te herstellen naar hun volledige functie.

In dit herstelplan wordt ervan uitgegaan dat de basisregio van de tenant operationeel blijft. Als de basisregio van de tenant een storing ondervindt, zijn de stappen die in dit document worden beschreven, afhankelijk van het herstel, dat eerst moet worden gestart en voltooid door Microsoft.

Ervaringsspecifieke herstelplannen

De volgende secties bevatten stapsgewijze handleidingen voor elke Fabric ervaring om klanten te helpen bij het herstelproces.

Data-engineering

In deze handleiding wordt u begeleid bij de herstelprocedures voor de Data-engineer-ervaring. Het behandelt lakehouses, notebooks, Spark-jobdefinities, gebruikersdatafuncties en GraphQL-API's.

Lakehouse

Lakehouses uit de oorspronkelijke regio blijven niet beschikbaar voor klanten. Om een lakehouse te herstellen, kunnen klanten deze opnieuw maken in werkruimte C2. W2. We raden twee benaderingen aan voor het herstellen van lakehouses:

Benadering 1: Aangepast script gebruiken om Lakehouse Delta-tabellen en -bestanden te kopiëren

Klanten kunnen lakehouses opnieuw maken met behulp van een aangepast Scala-script.

1. Maak het lakehouse (bijvoorbeeld LH1) in de zojuist gemaakte werkruimte C2. W2.

2. Maak een nieuw notitieblok in de werkruimte C2. W2.

3. Als u de tabellen en bestanden uit het oorspronkelijke lakehouse wilt ophalen, raadpleegt u de gegevens met OneLake-paden zoals abfss (zie Connecting to Microsoft OneLake). U kunt het volgende codevoorbeeld (zie Introduction to Microsoft Spark Utilities) in het notebook gebruiken om de ABFS-paden van bestanden en tabellen op te halen uit het oorspronkelijke Lakehouse. (Vervang C1. W1 met de werkelijke naam van de werkruimte)

   notebookutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Gebruik het volgende codevoorbeeld om tabellen en bestanden te kopiëren naar het zojuist gemaakte Lakehouse.

   1. Voor Delta-tabellen moet u de tabellen één voor één kopiëren om te herstellen in het nieuwe lakehouse. In het geval van Lakehouse-bestanden kunt u de volledige bestandsstructuur met alle onderliggende mappen kopiëren met één uitvoering.

   2. Neem contact op met het ondersteuningsteam voor de tijdstempel van failover die is vereist in het script.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Nadat u het script hebt uitgevoerd, worden de tabellen weergegeven in het nieuwe lakehouse.

Benadering 2: gebruik Azure Storage Explorer om bestanden en tabellen te kopiëren

Gebruik Azure Storage Explorer om alleen specifieke Lakehouse-bestanden of -tabellen te herstellen uit het oorspronkelijke lakehouse. Raadpleeg Integrate OneLake met Azure Storage Explorer voor gedetailleerde stappen. Gebruik Benadering 1 voor grote gegevensgrootten.

Herstellen van Fabric gematerialiseerde lakeweergaven

Gerealiseerde lakeweergaven van de oorspronkelijke regio blijven na een failover niet beschikbaar voor klanten. Vernieuwingsschema's en uitvoeringsgeschiedenis worden niet gerepliceerd naar de secundaire regio. Herstel ze door de volgende stappen uit te voeren nadat u uw Lakehouse-gegevens hebt hersteld.

• Herstel de Lakehouse-tabellen met behulp van Benadering 1 of Benadering 2 die hierboven worden beschreven. Kopieer alleen de brontabellen.
• Herstel de notebooks met uw MLV-definities. Raadpleeg de sectie Notebook voor herstelstappen.
• Voer de herstelde notebooks uit om de MLV's te reproduceren in het nieuwe Lakehouse. Zie Een gematerialiseerde Lake View maken voor meer informatie over het maken van MLV's. Als MLV's ook in de vorige stap zijn gekopieerd, voert u CREATE OR REPLACE uit terwijl u ze opnieuw maakt.
• Maak de MLV-vernieuwingsschema's handmatig opnieuw in de nieuwe werkruimte. Planningsgeschiedenis en metrische uitvoeringsgegevens kunnen niet worden hersteld.
• Als uw MLV's semantische modellen of rapporten voorzien, controleert en werkt u de verwijzingen naar de Lakehouse-ID en gegevensset-ID bij indien nodig. Maak opnieuw verbinding met het bijgewerkte semantische model en valideer de nieuwheid van gegevens.

Laptop

Notebooks uit de primaire regio blijven niet beschikbaar voor klanten en de code in notebooks wordt niet gerepliceerd naar de secundaire regio. Als u notebookcode in de nieuwe regio wilt herstellen, zijn er twee benaderingen voor het herstellen van notebookcode-inhoud.

Benadering 1: door de gebruiker beheerde redundantie met Git-integratie (in openbare preview)

De beste manier om dit eenvoudig en snel te maken, is door Fabric Git-integratie te gebruiken en uw notebook vervolgens te synchroniseren met uw ADO-opslagplaats. Nadat de service een failover naar een andere regio heeft uitgevoerd, kunt u de opslagplaats gebruiken om het notebook opnieuw op te bouwen in de nieuwe werkruimte die u hebt gemaakt.

1. Configureer Git-integratie voor uw werkruimte en selecteer Verbinding maken en synchroniseren met ADO-opslagplaats.

   

   In de volgende afbeelding ziet u het gesynchroniseerde notitieblok.

   

2. Herstel het notitieblok uit de ADO-opslagplaats.

   1. Maak in de zojuist gemaakte werkruimte opnieuw verbinding met uw Azure ADO-opslagplaats.

      

   2. Selecteer de knop Bronbeheer. Selecteer vervolgens de relevante branch van de repository. Selecteer daarna Alles bijwerken. Het oorspronkelijke notitieblok wordt weergegeven.

      

      

   3. Als het oorspronkelijke notitieblok een standaard lakehouse heeft, kunnen gebruikers verwijzen naar de sectie Lakehouse om het lakehouse te herstellen en vervolgens het zojuist herstelde lakehouse te verbinden met het zojuist herstelde notitieblok.

      

   4. De Git-integratie biedt geen ondersteuning voor het synchroniseren van bestanden, mappen of momentopnamen van notebooks in de notebooks-resourceverkenner.

      1. Als het oorspronkelijke notitieblok bestanden bevat in de notitieblok-resourceverkenner:

         1. Zorg ervoor dat u bestanden of mappen opslaat op een lokale schijf of op een andere locatie.

         2. Upload het bestand opnieuw vanaf uw lokale schijf of cloudstations naar het herstelde notebook.

      2. Als het oorspronkelijke notitieblok een momentopname van het notitieblok heeft, slaat u de momentopname van het notitieblok ook op in uw eigen versiebeheersysteem of lokale schijf.

         

         

Zie Inleiding tot Git-integratie voor meer informatie over Git-integratie.

Benadering 2: Handmatige benadering voor het maken van back-ups van code-inhoud

Als u niet de Git-integratiebenadering gebruikt, kunt u de nieuwste versie van uw code, bestanden in resourceverkenner en momentopname van notebooks opslaan in een versiebeheersysteem zoals Git, en de inhoud van het notitieblok handmatig herstellen na een noodgeval:

1. Gebruik de functie Notebook importeren om de notebookcode te importeren die u wilt herstellen.

   

2. Ga na het importeren naar de gewenste werkruimte (bijvoorbeeld 'C2. W2") om er toegang toe te krijgen.

3. Als het oorspronkelijke notitieblok een standaard lakehouse heeft, raadpleegt u de Lakehouse-sectie. Verbind vervolgens het zojuist herstelde lakehouse (dat dezelfde inhoud heeft als de oorspronkelijke standaard lakehouse) met het zojuist herstelde notebook.

4. Als het oorspronkelijke notitieblok bestanden of mappen bevat in de resourceverkenner, uploadt u de bestanden of mappen die zijn opgeslagen in het versiebeheersysteem van de gebruiker.

Spark-taakdefinitie

Spark-taakdefinities (SJD) uit de primaire regio blijven niet beschikbaar voor klanten en het hoofddefinitiebestand en het referentiebestand in het notebook worden gerepliceerd naar de secundaire regio via OneLake. Als u de SJD in de nieuwe regio wilt herstellen, kunt u de handmatige stappen volgen die hieronder worden beschreven om de SJD te herstellen. Historische uitvoeringen van de SJD kunnen niet worden hersteld.

U kunt de SJD-items herstellen door de code uit de oorspronkelijke regio te kopiëren met behulp van Azure Storage Explorer en na het noodgeval handmatig opnieuw verbinding te maken met Lakehouse-verwijzingen.

1. Maak een nieuw SJD-item (bijvoorbeeld SJD1) in de nieuwe werkruimte C2. W2, met dezelfde instellingen en configuraties als het oorspronkelijke SJD-item (bijvoorbeeld taal, omgeving, enzovoort).

2. Gebruik Azure Storage Explorer om bibliotheken, mains en momentopnamen van het oorspronkelijke SJD-item naar het nieuwe SJD-item te kopiëren.

   

3. De code-inhoud wordt weergegeven in de zojuist gemaakte SJD. U moet de zojuist herstelde Lakehouse-verwijzing handmatig toevoegen aan de taak (raadpleeg de herstelstappen van Lakehouse). Gebruikers moeten de oorspronkelijke opdrachtregelargumenten handmatig opnieuw opgeven.

   

U kunt nu uw zojuist herstelde SJD uitvoeren of plannen.

Zie Integrate OneLake with Azure Storage Explorer voor meer informatie over Azure Storage Explorer.

Functies voor gebruikersgegevens

Om je gebruikersgegevensfuncties in een gezonde regio te herstellen, gebruik je een van de volgende methoden.

Benadering 1: Met Git-integratie (aanbevolen)

Het voorkeursherstelmechanisme is Fabric Git-integratie. Door gebruikersdatafunctieprojecten te synchroniseren met een Azure DevOps- of GitHub-repository, kun je ze snel reconstrueren in een nieuwe werkruimte na een failover.

Bereid je voor op een ramp

1. Configureer Fabric Git-integratie voor de werkruimte die de gebruikersdatafunctie host.
2. Verbind de werkruimte met een Azure DevOps- of GitHub-repository.
3. Zet alle gebruikersgegevensfuncties in de repository en synchroniseer wijzigingen regelmatig.
4. Sla omgevingsspecifieke instellingen apart op in variabele bibliotheken indien nodig.

Herstelstappen

Na een regionale ramp:

1. Creëer een nieuwe Fabric-capaciteit in een gezonde regio, zoals C2.
2. Maak een nieuwe werkruimte, zoals W2, in de nieuwe hoedanigheid.
3. Verbind de werkruimte met dezelfde Azure DevOps- of GitHub-repository.
4. Open Broncodebeheer en synchroniseer de inhoud van de opslagplaats met de werkruimte.
5. Maak alle afhankelijke Fabric-bronnen opnieuw aan of herstel ze, zoals lakehouses, SQL-databases in Fabric, warehouses en Business Events.
6. Implementeer de functies voor gebruikersgegevens opnieuw.
7. Valideer de functie-uitvoering en afhankelijkheidsconnectiviteit.
8. Werk downstreamapplicaties, datapijplijnen of andere geïntegreerde onderdelen bij zodat deze verwijzen naar de herstelde functies.
9. Volledige end-to-end validatie van al je scenario's.

Belangrijke overwegingen

• Git-integratie herstelt alleen broncode en projectassets.
• Historische executielogboeken worden niet teruggevonden.
• Downstream-systemen kunnen een herbinding van het eindpunt vereisen.

Raadpleeg voor meer informatie Broncodebeheer en implementatie van gebruikersgegevensfuncties.

Aanpak 2: Handmatig herstel

Als Git-integratie niet vóór de ramp was geconfigureerd, kun je handmatig gebruikersdatafuncties reconstrueren vanuit broncode-back-ups.

Bereid je voor op een ramp

Voer regelmatig de volgende taken uit en sla de artefacten op in een externe source control-repository of back-uplocatie:

• Exporteer de broncode van de functie naar een GitHub-repository.
• Documenteer en bewaar afhankelijkheidsinformatie.
• Instellingen voor documentomgeving.

Herstelstappen

Na een regionale ramp:

1. Creëer een nieuwe Fabric-capaciteit in een gezonde regio, zoals C2.
2. Maak een nieuwe werkruimte aan, zoals W2.
3. Herstel alle resources die de functie nodig heeft, waaronder lakehouses, SQL-databases in Fabric, warehouses, eventhouses en externe diensten.
4. Maak een nieuw user data function project aan.
5. Importeer of maak de broncode van de functie opnieuw.
6. Pas de runtime-configuratie-instellingen opnieuw toe.
7. Installeer alle functieafhankelijkheden opnieuw.
8. Hergebruik de functie.
9. Herconfigureer authenticatie en autorisatie.
10. Maak Business Event-uitgevers of consumenten opnieuw aan, indien gebruikt.
11. Voltooi end-to-end validatietests voor je scenario's en integraties.

GraphQL

GraphQL-items uit de primaire regio zijn niet beschikbaar na een regionaal noodgeval en GraphQL-definities en -configuraties worden niet gerepliceerd naar de secundaire regio. Als u GraphQL in een nieuwe regio wilt herstellen, gebruikt u een van de volgende methoden.

Benadering 1: Gebruikersbeheerde redundantie met Git-integratie

De beste manier om dit proces eenvoudig en snel te maken, is door Fabric Git-integratie te gebruiken en uw GraphQL vervolgens te synchroniseren met uw ADO-opslagplaats. Nadat de service een failover naar een andere regio heeft uitgevoerd, kunt u de opslagplaats gebruiken om de GraphQL opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt.

1. Maak een nieuwe werkruimte in de doelcapaciteit en regio.

2. Herstel alle afhankelijke gegevensbronnen, zoals Lakehouse, Warehouse of SQL-databases, door de bijbehorende herstelstappen te volgen.

3. Werk de GraphQL-definitie bij zodat deze verwijst naar de zojuist herstelde resources door omgevingsspecifieke verwijzingen zoals bronwerkruimte-id's, bronartefact-id's en verbindingsgegevens te wijzigen. Deze stap zorgt ervoor dat de juiste binding tijdens de implementatie wordt uitgevoerd.

4. GraphQL-artefacten uit de Git-opslagplaats opnieuw implementeren in de nieuwe werkruimte. Met deze stap maakt u de API-structuur en -configuratie opnieuw met behulp van de bijgewerkte definities.

5. Artifactinstellingen opnieuw toepassen, waaronder rollen, toegangsbeheer en authenticatieconfiguratie.

6. Pas eindpuntverwijzingen opnieuw toe door toepassingen of integraties bij te werken om het zojuist gemaakte GraphQL-eindpunt te gebruiken.

7. Werk bestaande implementatiepijplijnen bij die naar de oude werkruimte verwijzen om te verwijzen naar de zojuist gemaakte werkruimte.

8. Valideer end-to-end-functionaliteit van de API.

Benadering 2: Handmatige benadering

Als u niet de Git-integratiebenadering gebruikt, kunt u de volgende handmatige methode gebruiken om GraphQL te herstellen.

1. Maak een nieuwe werkruimte in de doelcapaciteit en regio.

2. Herstel alle afhankelijke gegevensbronnen, zoals Lakehouse, Warehouse of SQL-databases.

3. Maak de GraphQL-API handmatig opnieuw in de nieuwe werkruimte, inclusief schemadefinities, gegevensbronverbindingen en relaties.

4. Artifactinstellingen opnieuw toepassen, waaronder rollen, toegangsbeheer en authenticatieconfiguratie.

5. Pas eindpuntverwijzingen opnieuw toe door toepassingen of integraties bij te werken om het zojuist gemaakte GraphQL-eindpunt te gebruiken.

6. Werk bestaande implementatiepijplijnen bij die naar de oude werkruimte verwijzen om te verwijzen naar de zojuist gemaakte werkruimte.

7. Valideer end-to-end-functionaliteit van de API.

Belangrijke overwegingen

1. GraphQL is afhankelijk van externe afhankelijkheden (zoals Lakehouse, Warehouse en SQL), die u moet herstellen vóór de GraphQL-implementatie.

2. GraphQL API-definities bevatten omgevingsspecifieke verwijzingen (zoals sourceWorkspaceId en sourceItemId). Wanneer u herstelt in een nieuwe regio, kunnen deze verwijzingen ongeldig worden. Werk ze bij zodat ze verwijzen naar nieuw ingerichte resources.

3. Het automatisch koppelen van gegevensbronnen wordt niet gegarandeerd in scenario's voor herstel na noodgevallen, met name bij het gebruik van opgeslagen referenties of verbindingen tussen werkruimten.

4. Andere artefactinstellingen, zoals bewaking, autorisatie, RBAC, introspectie en meer, worden niet overgedragen na een failover. U moet deze instellingen opnieuw instellen in de nieuwe regio.

References

• Overzicht van Fabric Git-integratie - Microsoft Fabric | Microsoft Learn

• Broncodebeheer- en implementatiepijplijnen in API voor GraphQL - Microsoft Fabric | Microsoft Learn 

App

Het systeem repliceert Fabric Apps, inclusief hun code, configuratie en metadata, niet naar secundaire regio's. Als de primaire regio faalt, blijft de app niet beschikbaar. Voor herstel sla je de broncode van de app buiten het systeem op in GitHub, Azure DevOps of een ander bronbeheersysteem. Herstel app-gegevens afzonderlijk door de disaster recovery-richtlijnen voor elke onderliggende Fabric-datawinkel te volgen.

Handmatige benadering

Je kunt een Fabric App handmatig herstellen na een regionale ramp door gebruik te maken van de broncode van de applicatie en de Rayfin CLI. 

Prerequisites 

Voordat er een ramp plaatsvindt:

• Sla de broncode van de Fabric App op in GitHub, Azure DevOps of een andere source control repository. 

• Documenteer het herstelproces.  

Herstelstappen 

1. Maak een nieuwe werkruimte in de doelcapaciteit en regio. 

2. Herstel afhankelijke resources voordat je de applicatie opnieuw uitrolt.  

3. Haal de nieuwste broncode van de Fabric App op uit je source control-repository of lokale back-up. 

4. Vanuit de applicatiebronmap deploy je de Fabric App in de herstelwerkruimte met behulp van Rayfin CLI. Voer rayfin up --workspace <new workspace>uit. 

5. Herstel het kinditem van de app (Fabric SQL Database) door de bijbehorende herstelprocedures te volgen.  

6. Pas artefactniveau-instellingen opnieuw toe, inclusief rollen en toegangscontroles indien nodig.  

7. Valideer de functionaliteit van de applicatie en zorg dat gebruikers de juiste rechten hebben.  

Belangrijk 

• Onderhoud de broncode van de Fabric App buiten de Fabric-regio om herstel mogelijk te maken.  

• Applicatiegegevens in de database worden niet teruggehaald als onderdeel van het Fabric App-implementatieproces en moeten apart worden hersteld.  Je kunt een Fabric App handmatig herstellen na een regionale ramp door gebruik te maken van de broncode van de applicatie en de Rayfin CLI. 

Gegevenswetenschap

Deze handleiding leidt u door de herstelprocedés voor de Data Science-ervaring. Hierin worden ML-modellen en -experimenten behandeld.

ML-model en -experiment

Items voor datawetenschap uit de primaire regio blijven voor klanten niet beschikbaar. Bovendien worden inhoud en metagegevens binnen ML-modellen en experimenten niet overgedragen naar de secundaire regio. Als u ze volledig wilt herstellen in de nieuwe regio, slaat u de code-inhoud op in een versiebeheersysteem (zoals Git) en voert u de code-inhoud handmatig opnieuw uit na het noodgeval.

1. Herstel het notitieblok. Raadpleeg de stappen voor notebookherstel.

2. Configuratie, historisch uitgevoerde metrische gegevens en metagegevens worden niet gerepliceerd naar de gekoppelde regio. U moet elke versie van uw data science-code opnieuw uitvoeren om ML-modellen en experimenten volledig te herstellen na het noodgeval.

Gegevensmagazijn

In deze handleiding wordt u begeleid bij de herstelprocedures voor de Data Warehouse ervaring. Het behandelt magazijnen.

Magazijn

Magazijnen uit de oorspronkelijke regio blijven niet beschikbaar voor klanten. Gebruik de volgende twee stappen om magazijnen te herstellen.

1. Maak een nieuw interim lakehouse in werkruimte C2.W2 voor de gegevens die u uit het oorspronkelijke datawarehouse kopieert.

2. Vul de Delta-tabellen van het magazijn in door gebruik te maken van warehouse Explorer en de T-SQL-mogelijkheden (zie Tables in datawarehousing in Microsoft Fabric).

Gegevensopname via Lakehouse en T-SQL-code

In nieuw gemaakte werkruimte C2. W2:

1. Maak een interim lakehouse "LH2" in C2. W2.

2. Herstel de Delta-tabellen in het interim lakehouse vanuit het oorspronkelijke magazijn door de Lakehouse-herstelstappen te volgen.

3. Maak een nieuw magazijn 'WH2' in C2. W2.

4. Verbind de interim lakehouse in uw warehouse explorer.

5. Afhankelijk van hoe u tabeldefinities gaat implementeren voordat u gegevens importeert, kan de werkelijke T-SQL die voor import wordt gebruikt, variëren. U kunt INSERT INTO, SELECT INTO of CREATE TABLE AS SELECT gebruiken om magazijntabellen te herstellen uit lakehouses. Verder in het voorbeeld zullen we INSERT INTO flavor gebruiken. (Als u de onderstaande code gebruikt, vervangt u voorbeelden door werkelijke tabel- en kolomnamen)

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Wijzig ten slotte de verbindingsreeks in toepassingen met behulp van uw Fabric warehouse.

Gespiegelde database

Gespiegelde databases uit de primaire regio blijven niet beschikbaar voor klanten en de instellingen worden niet gerepliceerd naar de secundaire regio. Als u deze wilt herstellen in het geval van een regionale fout, moet u de gespiegelde database opnieuw maken in een andere werkruimte vanuit een andere regio.

Data Factory

Data Factory-items uit de primaire regio blijven niet beschikbaar voor klanten en de instellingen en configuratie in pijplijnen of gegevensstroom gen2-items worden niet gerepliceerd naar de secundaire regio. Als u deze items wilt herstellen in het geval van een regionale storing, moet u de data-integratie-items opnieuw creëren in een andere werkruimte in een andere regio. In de volgende secties worden de details beschreven.

Gegevensstromen Gen2

Als u een Dataflow Gen2-item in de nieuwe regio wilt herstellen, moet u een PQT-bestand exporteren naar een versiebeheersysteem zoals Git en de Inhoud van Dataflow Gen2 na het noodgeval handmatig herstellen.

1. Selecteer in het item Dataflow Gen2 op het tabblad Start van de Power Query-editor Sjabloon exporteren.

   

2. Voer in het dialoogvenster Sjabloon exporteren een naam (verplicht) en een beschrijving (optioneel) in voor deze sjabloon. Selecteer OK als u klaar bent.

   

3. Maak na het noodgeval een nieuw Dataflow Gen2-item in de nieuwe werkruimte C2. W2".

4. Selecteer in het huidige weergavevenster van de Power Query-editor Import uit een Power Query-sjabloon.

   

5. Blader in het dialoogvenster Openen naar de standaard downloadsmap en selecteer het .pqt-bestand dat u in de vorige stappen hebt opgeslagen. Selecteer vervolgens Openen.

6. De sjabloon wordt vervolgens geïmporteerd in uw nieuwe Dataflow Gen2-item.

De functie Opslaan als voor gegevensstromen wordt niet ondersteund in het geval van herstel na noodgevallen.

Pipelines

Klanten hebben geen toegang tot pijplijnen in het geval van regionale noodgevallen en de configuraties worden niet gerepliceerd naar de gekoppelde regio. We raden u aan uw kritieke pijplijnen in meerdere werkruimten in verschillende regio's te bouwen.

Kopieer Taak

CopyJob-gebruikers moeten proactieve maatregelen nemen om te beschermen tegen een regionale ramp. De volgende aanpak zorgt ervoor dat na een regionale ramp de CopyJobs van een gebruiker beschikbaar blijven.

Door de gebruiker beheerde redundantie met Git-integratie (in openbare preview)

De beste manier om dit proces eenvoudig en snel te maken, is door Fabric Git-integratie te gebruiken en vervolgens uw CopyJob te synchroniseren met uw ADO-opslagplaats. Nadat de service een failover naar een andere regio heeft uitgevoerd, kunt u de opslagplaats gebruiken om de CopyJob opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt.

1. Configureer de Git-integratie van uw werkruimte en selecteer verbinden en synchroniseren met ADO-repository.

   

   In de volgende afbeelding ziet u de gesynchroniseerde CopyJob.

   

2. Herstel de CopyJob uit de ADO-opslagplaats.

   1. Maak in de zojuist gemaakte werkruimte opnieuw verbinding met uw Azure ADO-opslagplaats en synchroniseer deze. Alle Fabric items in deze opslagplaats worden automatisch gedownload naar uw nieuwe werkruimte.

      

   2. Als de oorspronkelijke CopyJob gebruikmaakt van een Lakehouse, kunnen gebruikers verwijzen naar de sectie Lakehouse om het Lakehouse te herstellen en vervolgens de zojuist herstelde CopyJob te verbinden met het zojuist herstelde Lakehouse.

Zie Inleiding tot Git-integratie voor meer informatie over Git-integratie.

Apache Airflow-taak

Gebruikers van Apache Airflow Jobs in Fabric moeten proactieve maatregelen nemen om zich te beschermen tegen een regionale ramp.

We raden u aan redundantie te beheren met Fabric Git-integratie. Synchroniseer eerst uw Airflow-taak met uw ADO-opslagplaats. Als de service een failover naar een andere regio uitvoert, kunt u de repository gebruiken om de Airflow-taak opnieuw op te bouwen in de nieuwe werkruimte die u hebt aangemaakt.

Hier volgen de stappen om dit te bereiken:

1. Configureer de Git-integratie van uw werkruimte en selecteer verbinding maken en synchroniseren met de ADO-opslagplaats.

2. Daarna ziet u dat uw Airflow-taak is gesynchroniseerd met uw ADO-opslagplaats.

3. Als u de Airflow-taak wilt herstellen vanuit de ADO-opslagplaats, maakt u een nieuwe werkruimte, maakt u verbinding en synchroniseert u deze opnieuw met uw Azure ADO-opslagplaats. Alle Fabric items, inclusief Airflow, worden in deze opslagplaats automatisch gedownload naar uw nieuwe werkruimte.

Realtime intelligentie

In deze handleiding wordt u begeleid bij de herstelprocedures voor de realtime intelligence-ervaring. Hierin worden KQL-databases/querysets en eventstreams behandeld.

Activator

Activator-items uit de primaire regio blijven niet beschikbaar voor klanten en Activator-triggerdefinities worden niet gerepliceerd naar de secundaire regio. Activator-gebruikers moeten proactieve stappen ondernemen om zich voor te bereiden op regionaal herstel na noodgevallen.

Om ervoor te zorgen dat u Activator-items kunt herstellen in het geval van een regionaal noodgeval, stelt u Fabric Git-integratie in om een back-up te maken van triggerdefinities en deze te herstellen in een werkruimte in een andere regio.

1. Configureer Fabric Git-integratie voor de werkruimte die uw Activator-item bevat en synchroniseer uw triggerdefinities met uw Git-opslagplaats.
2. Zorg dat uw Activator-triggerdefinities regelmatig gecommit en gesynchroniseerd worden.
3. Maak tijdens het herstel een nieuwe werkruimte in de doelregio (C2). W2), verbind deze met dezelfde opslagplaats en synchroniseer om de triggerdefinities te herstellen.
4. Configureer en valideer alle Activator-gegevensbronnen en -afhankelijkheden in de nieuwe werkruimte.

Zie Inleiding tot Git-integratie voor meer informatie over Git-integratie.

Grafenmodel/queryset

Graph Model- en Graph Queryset-items uit de primaire regio blijven niet beschikbaar voor klanten en deze items worden niet gerepliceerd naar de secundaire regio. Als u een capaciteit wilt herstellen, maak of gebruik dan een capaciteit in een andere regio en hercreëer daar de Graph Model- en Graph Queryset-items.

1. Maak of gebruik een bestaande Fabric capaciteit in een andere regio die niet wordt beïnvloed door het noodgeval.

2. Maak een nieuwe werkruimte of gebruik een bestaande werkruimte in die capaciteit.

3. Maak het Graph Model-item opnieuw in de secundaire werkruimte (waarnaar wordt verwezen in stap 2). Configureer de modeldefinitie opnieuw, inclusief knooppunten, randen, enzovoort, zodat deze overeenkomt met het oorspronkelijke Grafiekmodel.

4. Als het originele lakehouse zich in de falende regio bevindt, herstelt u het eerst door de instructies in de sectie Lakehouse op te volgen.

5. Verbind een lakehouse als de OneLake-gegevensbron voor het zojuist gemaakte Graph Model-item. Gebruik het herstelde lakehouse als deze zich in de mislukte regio bevond of maak opnieuw verbinding met het bestaande lakehouse als deze beschikbaar blijft.

6. Configureer alle schema's of verbindingen voor het laden van gegevens voor het Graph-model in de nieuwe werkruimte opnieuw.

7. Maak het Graph Queryset-item opnieuw in de secundaire werkruimte. Voer de query's en eventuele opgeslagen queryconfiguraties handmatig opnieuw uit de oorspronkelijke Graph Queryset.

KQL-database/queryset

KQL-database-/querysetgebruikers moeten proactieve maatregelen treffen om te beschermen tegen een regionaal noodgeval. De volgende aanpak zorgt ervoor dat in het geval van een regionale ramp gegevens in uw KQL-databasesquerysets veilig en toegankelijk blijven.

Gebruik de volgende stappen om een effectieve oplossing voor herstel na noodgevallen te garanderen voor KQL-databases en querysets.

1. Etablish onafhankelijke KQL-databases: configureer twee of meer onafhankelijke KQL-databases/querysets voor toegewezen Fabric capaciteiten. Deze moeten worden ingesteld in twee verschillende Azure regio's (bij voorkeur Azure gekoppelde regio's) om de tolerantie te maximaliseren.

2. Beheeractiviteiten repliceren: alle beheeracties die in de ene KQL-database worden uitgevoerd, moeten in de andere worden gespiegeld. Dit zorgt ervoor dat beide databases gesynchroniseerd blijven. Belangrijke activiteiten die moeten worden gerepliceerd, zijn onder andere:

   • Tabellen: zorg ervoor dat de tabelstructuren en schemadefinities consistent zijn in de databases.

   • Toewijzing: eventuele vereiste toewijzingen dupliceren. Zorg ervoor dat gegevensbronnen en bestemmingen correct zijn uitgelijnd.

   • Beleid: zorg ervoor dat beide databases vergelijkbare gegevensretentie, toegang en ander relevant beleid hebben.

3. Verificatie en autorisatie beheren: Stel voor elke replica de vereiste machtigingen in. Zorg ervoor dat de juiste autorisatieniveaus tot stand zijn gebracht, waarbij toegang wordt verleend tot het vereiste personeel, terwijl de beveiligingsstandaarden behouden blijven.

4. Parallelle gegevensopname: als u de gegevens consistent en gereed wilt houden in meerdere regio's, laadt u dezelfde gegevensset in elke KQL-database op hetzelfde moment als u deze opneemt.

Gebeurtenisstroom

Een eventstream is een gecentraliseerde plaats in het Fabric-platform voor het vastleggen, transformeren en routeren van realtime gebeurtenissen naar verschillende bestemmingen (bijvoorbeeld lakehouses, KQL-databases/querysets) met een ervaring zonder code. Zolang de bestemmingen worden ondersteund door herstel na noodgevallen, gaan eventstreams geen gegevens kwijt. Daarom moeten klanten de mogelijkheden voor herstel na noodgevallen van deze doelsystemen gebruiken om de beschikbaarheid van gegevens te garanderen.

Klanten kunnen ook georedundantie bereiken door identieke Eventstream-workloads in meerdere Azure regio's te implementeren als onderdeel van een actieve/actieve strategie voor meerdere sites. Met een actieve/actieve benadering voor meerdere sites hebben klanten toegang tot hun workload in een van de geïmplementeerde regio's. Deze benadering is de meest complexe en kostbare benadering van herstel na noodgevallen, maar kan de hersteltijd in de meeste situaties verminderen tot bijna nul. Om volledig geografisch redundant te zijn, kunnen klanten

1. Maak replica's van hun gegevensbronnen in verschillende regio's.

2. Eventstream-items maken in de bijbehorende regio's.

3. Verbind deze nieuwe items met de identieke gegevensbronnen.

4. Voeg identieke bestemmingen toe voor elke eventstream in verschillende regio's.

Zakelijke gebeurtenissen, Fabric-gebeurtenissen en Azure-gebeurtenissen

Hoewel zakelijke gebeurtenissen, Fabric gebeurtenissen en Azure gebeurtenissen dezelfde Real-Time hubinfrastructuur in Microsoft Fabric delen, hebben ze verschillende oorsprongs-, gedrags- en herstelvereisten die moeten worden begrepen voordat u herstel na noodgevallen plant:

• Fabric-gebeurtenissen zijn gebeurtenisabonnementen die reageren op activiteiten die afkomstig zijn van Fabric-resources zelf, waaronder wijzigingen in de levenscyclus van werkruimte-items (zoals het maken, bijwerken of verwijderen van lakehouses, notebooks of warehouses), taakuitvoeringen (zoals pipeline-uitvoeringen of notebookuitvoeringen) en OneLake-bestands- en mapbewerkingen. Deze abonnementen zijn push-based en kortstondig. De abonnementen worden niet gerepliceerd naar de secundaire regio.

• Azure gebeurtenissen zijn gebeurtenisabonnementen op activiteiten die worden geproduceerd door Azure Blob Storage accounts. Deze Azure resources bestaan onafhankelijk van elke Fabric capaciteit of regio. Hoewel de Azure Blob Storage resource zelf beschikbaar kan blijven tijdens een regionale storing van Fabric, worden de abonnementen die zijn geconfigureerd in Real-Time hub niet gerepliceerd naar de secundaire regio en moeten ze opnieuw worden gemaakt.

• Zakelijke gebeurtenissen zijn een unieke mogelijkheid in Fabric Real-Time Intelligence waarmee teams zinvolle signalen kunnen definiëren, publiceren en erop kunnen reageren. Zakelijke gebeurtenissen worden gegenereerd vanuit Fabric via Activator, Spark-notebooks of User Data Functions, en vervolgens gepubliceerd naar Real-Time hub waar downstreamgebruikers, zoals Activator, Eventhouse of Power Automate hierop kunnen reageren. Gebeurtenisschema's worden centraal beheerd via het schemaregister. Eventhouse slaat elke gepubliceerde zakelijke gebeurtenis automatisch op, zodat het herstel rechtstreeks van invloed is op de beschikbaarheid van de geschiedenis van zakelijke gebeurtenissen. Geen van de uitgevers- of consumentenconfiguraties, schemadefinities of abonnementen worden gerepliceerd naar de secundaire regio.

Gebruik de volgende stappen om Business Events, Fabric Events en Azure Events in de nieuwe werkruimte in de herstelregio te herstellen.

Voor zakelijke gebeurtenissen:

1. Maak de zakelijke gebeurtenis die wordt gebruikt door uitgevers en consumenten opnieuw door het artikel Zakelijke gebeurtenissen maken in Fabric Real-Time Hub te volgen. Tijdens het aanmaken van de businessgebeurtenis maakt u de resource Event Schema Set. De Eventhouse-resource is optioneel, afhankelijk van het scenario. Als je je event schema set hebt geback-upt met Git-integratie, herstel het dan eerst door het Event schema set-gedeelte te volgen en wijs daarna het business event naar het herstelde schema set.

2. Maak alle publisher-items die business events genereren, zoals Spark-notebooks of gebruikersgegevensfuncties, opnieuw aan in de nieuwe werkruimte door de volgende publisher-artikelen te volgen: Gebruikersgegevensfunctie als Business Events-publisher gebruiken, Activator als Business Events-publisher gebruiken, Notebook als Business Events-publisher gebruiken en Eventstream als Business Events-publisher gebruiken.

3. Maak de consumentenabonnementen opnieuw in Real-Time hub (bijvoorbeeld Activator-regels, notebooktriggers of Power Automate stromen) die oorspronkelijk reageerden op zakelijke gebeurtenissen in de betrokken regio door de artikelen Eventhouse en Real-Time Dashboard Integration with Business Events andConsume Business Events from Activator te volgen.

4. Controleer of gebeurtenissen van begin tot eind worden doorgegeven door na te gaan of subscriptions actief zijn en of gegevens aankomen op de verwachte bestemmingen in de herstelregio.

Voor Fabric gebeurtenissen:

1. Maak de abonnementen opnieuw in de Real-Time hub die verwijzen naar de werkruimte-items, jobs of OneLake-paden die in de herstelregio zijn hersteld, door het artikel Fabric-gebeurtenissen verkennen in Fabric Real-Time hub te volgen.

2. Controleer of gebeurtenissen van begin tot eind worden doorgegeven door na te gaan of subscriptions actief zijn en of gegevens aankomen op de verwachte bestemmingen in de herstelregio.

Voor Azure gebeurtenissen:

1. Azure Blob Storage-accounts worden niet getroffen door een regionale storing in Fabric. Maak de gebeurtenisabonnementen in Real-Time hub die naar dezelfde Azure Blob Storage-accounts verwijzen opnieuw door het artikel Waarschuwingen instellen voor Azure Blob Storage-gebeurtenissen in Real-Time hub te volgen.

2. Controleer of gebeurtenissen van begin tot eind worden doorgegeven door na te gaan of subscriptions actief zijn en of gegevens aankomen op de verwachte bestemmingen in de herstelregio.

Gebeurtenisschemaset

Een event schema set is het Fabric item dat event type en schema definities bevat in Real-Time Intelligence. Andere mogelijkheden bouwen hierop: uitgevers schrijven gebeurtenissen die voldoen aan hun schema's, en consumenten lezen volgens dezelfde definities.

Gebeurtenisschemasets uit de primaire regio blijven niet beschikbaar voor klanten en worden niet gerepliceerd naar de secundaire regio. Omdat een set met gebeurtenisschema’s echter een duurzame, opgestelde definitie is en geen tijdelijk abonnement, kun je er vooraf een back-up van maken en deze terugzetten in plaats van deze handmatig opnieuw op te stellen.

Aanbevolen: back-up maken met Fabric Git-integratie

Om een event schema dat na een regionale ramp is ingesteld te herstellen, zet je Fabric Git-integratie op voordat er een ramp plaatsvindt, en synchroniseer je de werkruimte met je event schema-sets met je Git-repository.

1. Configureer Fabric Git-integratie voor de werkruimte die je event schema set bevat, en synchroniseer deze met je Git-repository.

2. Houd de event schema-set regelmatig gecommitteerd en gesynchroniseerd, vooral na het toevoegen van eventtypes of het publiceren van nieuwe schemaversies.

3. Tijdens het herstel maak je een nieuwe werkruimte aan in het doelgebied (C2. W2), verbind het met dezelfde repository en synchroniseer om de event schema set te herstellen. Omdat de nieuwe werkruimte leeg is, brengt Git sync de inhoud van de repository naar de werkruimte.

4. Maak alle uitgevers en consumenten die de schemaset gebruiken opnieuw aan, volgens de richtlijnen voor die itemtypes.

5. Valideer dat uitgevers kunnen publiceren tegen de herstelde gebeurtenistypes en dat consumenten gebeurtenissen ontvangen zoals verwacht.

De gesynchroniseerde definitie omvat de gebeurtenistypes in de schemaset, de schema's en de schemaversies. Het bevat geen uitgeversregistraties, consumentenabonnementen of evenementengeschiedenis. Herstel deze apart, volgens de richtlijnen voor de itemtypes die de schemaset gebruiken.

Alternatief: handmatig opnieuw aanmaken

Als je de Git-integratie vóór de ramp niet hebt geconfigureerd, maak dan de event schema set in de recovery region opnieuw aan door te volgen Create and manage event schema sets, en voeg dan de event types en schema's toe die de originele schemaset bevatte door te volgen Create and manage event schemas in schema sets.

Map

Kaartitems uit de primaire regio blijven onbeschikbaar voor klanten en de kaartitems worden niet naar de secundaire regio gerepliceerd.

Als u een kaartitem wilt herstellen wanneer er een noodgeval optreedt, stelt u Fabric Git-integratie in en synchroniseren uw kaartitem met uw Git-opslagplaats.

Tijdens het herstel, nadat de nieuwe regio/capaciteit in Fabric is ingesteld, kunt u de repository gebruiken om het Map-item opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt. Omdat de nieuwe werkruimte leeg is, haalt Git sync de inhoud van de opslagplaats op in de lege werkruimte. Met deze stap wordt het kaartitem weer tot leven geschoven.

Ontologie

Ontology-gebruikers moeten proactieve stappen ondernemen om zich voor te bereiden op regionaal herstel na noodgevallen. De hieronder beschreven aanpak zorgt ervoor dat, na een regionale ramp, uw Ontology herstelbaar blijft en snel kan worden hersteld.

De eenvoudigste en snelste manier om herstel mogelijk te maken, is door Fabric Git-integratie te gebruiken en uw Ontology te synchroniseren met een Azure DevOps (ADO)-opslagplaats. Als de service een failover naar een andere regio uitvoert, kunt u deze opslagplaats gebruiken om de Ontology opnieuw te bouwen in een zojuist gemaakte werkruimte.

Ontologie-items in de primaire regio zijn niet beschikbaar voor klanten na een regionale ramp en Ontology-items worden niet gerepliceerd naar de secundaire regio.

Als u een Ontology-item tijdens een noodgeval wilt herstellen, configureert u Fabric Git-integratie en synchronize het Ontology-item met uw ADO-opslagplaats vooraf.

Wanneer de nieuwe regio en capaciteit in Fabric zijn ingesteld, kunt u tijdens het herstel de opslagplaats gebruiken om het Ontology-item opnieuw te bouwen in een nieuwe werkruimte. Omdat de nieuwe werkruimte leeg is, haalt Git sync de inhoud van de opslagplaats naar de werkruimte op, zodat het Ontology-item effectief wordt hersteld.

Planning

Dit artikel beschrijft de herstelprocedures voor de planningsfunctionaliteit in IQ. Het beschrijft de stappen die nodig zijn om belangrijke componenten te herstellen, waaronder planningsbladen, PowerTable-bladen, intelligentiebladen, InfoBridge en gerelateerde data-assets.

Git-integratie voor het herstellen van planitems

De voorkeursmethode is om alle planitems te synchroniseren met een Azure DevOps (ADO) of GitHub opslagplaats met behulp van Fabric Git-integratie. Na een failover gebruikt u de opslagplaats om de items in de nieuwe werkruimte te herstellen.

Vóór een ramp (proactieve stappen):

1. Ga in werkruimte W1 naar Werkruimte-instellingen en configureer Git-integratie.

2. Selecteer Verbinding maken en synchroniseren met uw ADO of GitHub opslagplaats.

3. Selecteer de planitems die u wilt uploaden naar de opslagplaats en selecteer Doorvoeren.

   

4. Controleer of de Git-status van planitems is gesynchroniseerd.

5. Hanteer een commitdiscipline: commit na elke belangrijke wijziging aan de plandefinitie, zodat de repository altijd de meest recente status weerspiegelt.

Herstelstappen:

1. Maak een nieuwe werkruimte W2 binnen capaciteit C2 in de gezonde regio.

2. Ga in werkruimte W2 naar Werkruimte-instellingen en maak opnieuw verbinding met dezelfde ADO/GitHub opslagplaats.

3. Selecteer Broncodebeheer. Selecteer de relevante opslagplaatsbranch en selecteer Alles bijwerken. Alle items van het plan worden naar W2 gedownload.

De volgende onderdelen worden hersteld na herstel:

• PowerTable-bladen: Brontabelinstellingen, kolomconfiguratie, rijtoegang, visuele eigenschappen (indeling, opmaak en meer), rijidentificatie, opmerkingeninstellingen, langzaam veranderende dimensies (SCD), goedkeuringen, automatiseringen en formulieren.
• Planningsbladen: Bladeigenschappen (opmaak, voorwaardelijke opmaak en meer), opmerkingeninstellingen, instellingen voor terugschrijven, kolommen voor gegevensinvoer, gegevensinvoerrijen, scenario's en bladwijzers.
• InfoBridge: InfoBridge-bronnen, InfoBridge-query's, transformatiestappen, writeback-bestemmingen, writeback-instellingen, gekoppelde querytoewijzingen, querygroepen, visuele eigenschappen (blend). Deze items kunnen niet worden hersteld: op bestanden gebaseerde bronnen (CSV, Excel), werkbladen voor meerdere werkbelastingen die gebruikmaken van bronnen op basis van bestanden.
• Intelligentie: Alle grafieken en matrices.

Fabric SQL-herstel voor planningsdoeleinden

Gegevens die worden ingevoerd in planningsbladen, tabellen die worden gebruikt in PowerTable en write-backgegevens, worden opgeslagen in SQL-databases en moeten worden beschouwd als onderdeel van uw strategie voor herstel na noodgevallen. Om SQL-databases te herstellen, zie de sectie SQL-database.

• Metagegevens van herstelplan: elk planitem is gekoppeld aan een __fabric_plan_sys-database waarin metagegevens worden opgeslagen voor planningsfuncties, waaronder opmerkingen, scenario's, gegevensinvoer en configuratie voor terugschrijven. De __fabric_plan_sys-database wordt niet automatisch hersteld en moet expliciet worden hersteld.

• Write-backdatabases herstellen: als uw plan GEBRUIKMAAKT van SQL-terugschrijfbestemmingen, moet u ook de bijbehorende databases handmatig herstellen. Geconfigureerde SQL-terugschrijfbestemmingen worden niet automatisch hersteld.

• Tabellen herstellen die worden gebruikt in PowerTable: tabellen die zijn gemaakt met behulp van PowerTable, worden opgeslagen in een Fabric SQL-database. U moet ook deze tabellen herstellen tijdens disaster recovery.

Operationsagenten

Gebruikers van operations-agents moeten proactieve stappen nemen om zich voor te bereiden op regionaal herstel na noodgevallen. Door de in deze sectie beschreven aanpak te volgen, kunt u ervoor zorgen dat uw agents snel kunnen worden hersteld na een regionale storing.

Gebruik Fabric Git-integratie om uw werkruimte te synchroniseren met een opslagplaats. Met deze methode kunt u agentconfiguraties in een nieuwe werkruimte reconstrueren als de service een failover naar een andere regio uitvoert.

Items van de Operations-agent in de primaire regio zijn niet beschikbaar tijdens een regionale ramp. Agentconfiguraties, gedragsmodellen en activiteitenlogboeken worden niet gerepliceerd naar de secundaire regio. Lopende bewerkingen, actieve chatsessies en eerder geïngeste gebeurtenissen op het moment van de ramp gaan ook verloren.

Als u zich wilt voorbereiden op herstel, configureert u Fabric Git-integratie en synchroniseert u uw agentitems met uw ADO-opslagplaats voordat er zich een noodgeval voordoet.

Wanneer u herstelt, stelt u uw nieuwe regio en capaciteit in Fabric in en gebruikt u vervolgens de gesynchroniseerde opslagplaats om agentconfiguraties te herstellen in een nieuwe werkruimte. Git-synchronisatie haalt de opgeslagen inhoud uit de repository op en zet die in de lege werkruimte, waarmee uw agentitems opnieuw worden aangemaakt.

Zodra de configuraties zijn hersteld, controleert u of eventuele KQL-databases (Eventhouse) of regiospecifieke gegevensbronnen toegankelijk zijn in de nieuwe regio. Werk indien nodig eindpuntverwijzingen bij in agentconfiguraties. Start ten slotte uw agents opnieuw op en laat gebruikers nieuwe chatsessies initiëren. Eerdere gesprekken kunnen niet worden hervat.

Transactionele database

In deze handleiding worden de herstelprocedures voor de transactionele database-ervaring beschreven.

SQL database

Ter bescherming tegen regionale fouten kunnen gebruikers van SQL-databases proactieve maatregelen nemen om hun gegevens periodiek te exporteren en de geëxporteerde gegevens te gebruiken om de database in een nieuwe werkruimte opnieuw te maken wanneer dat nodig is.

Dit kan worden bereikt met behulp van het sqlPackage CLI-hulpprogramma dat databaseportabiliteit biedt en database-implementaties faciliteert.

1. Gebruik het hulpprogramma SqlPackage om de database te exporteren naar een .bacpac bestand. Zie Een database exporteren met SqlPackage voor meer informatie.
2. Sla het .bacpac bestand op een veilige locatie op die zich in een andere regio bevindt dan de database. Voorbeelden hiervan zijn het opslaan van het bestand .bacpac in een Lakehouse dat zich in een andere regio bevindt, met behulp van een geografisch redundant Azure Storage-account of een ander beveiligd opslagmedium dat zich in een andere regio bevindt.
3. Als de SQL-database en -regio niet beschikbaar zijn, kunt u het .bacpac bestand met SqlPackage gebruiken om de database opnieuw te maken in een werkruimte in een nieuwe regio: Werkruimte C2. W2 in regio B, zoals beschreven in het bovenstaande scenario. Volg de stappen in Een database importeren met SqlPackage om de database opnieuw te maken met uw .bacpac bestand.

De opnieuw gemaakte database is een onafhankelijke database van de oorspronkelijke database en weerspiegelt de status van de gegevens op het moment van de exportbewerking.

Overwegingen voor failback

De opnieuw gemaakte database is een onafhankelijke database. Gegevens die aan de opnieuw gemaakte database worden toegevoegd, worden niet weergegeven in de oorspronkelijke database. Als u een failback naar de oorspronkelijke database wilt uitvoeren wanneer de basisregio beschikbaar is, moet u overwegen om handmatig gegevens van de opnieuw gemaakte database te afstemmen op de oorspronkelijke database.

Platform

Platform verwijst naar de onderliggende gedeelde services en architectuur die van toepassing zijn op alle workloads. Deze sectie beschrijft herstelprocedures voor gedeelde Fabric-mogelijkheden.

Werkruimtebewaking

Workspace monitoring verzamelt logs over activiteit in de workspace waar je het inschakelt. Nadat je je werkruimte hebt hersteld als C2.W2, schakel je werkruimtemonitoring in op W2. Het begint monitoringgegevens te verzamelen voor de herstelde werkruimte.

Monitoringgegevens van de oorspronkelijke werkruimte (C1.W1) worden niet meegenomen, omdat monitoring de activiteit weerspiegelt van de werkruimte waarop deze wordt uitgevoerd.

Variabele bibliotheek

Microsoft Fabric Variabelenbibliotheken stellen ontwikkelaars in staat om itemconfiguraties binnen een werkruimte aan te passen en te delen, waardoor het levenscyclusbeheer van inhoud wordt stroomlijnd. Vanuit het oogpunt van rampherstel moeten gebruikers van een bibliotheek met variabelen proactief maatregelen nemen tegen een regionaal noodgeval. Dit kan worden gedaan via Fabric Git-integratie, wat ervoor zorgt dat na een regionaal noodgeval de variabele bibliotheek van een gebruiker beschikbaar blijft. Als u een variabelebibliotheek wilt herstellen, raden we het volgende aan:

• Gebruik Fabric Git-integratie om uw variabelebibliotheek te synchroniseren met uw ADO-opslagplaats. In geval van nood kunt u de opslagplaats gebruiken om de variabelebibliotheek opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt. Gebruik de volgende stappen:

  1. Verbind uw werkruimte met een Git-opslagplaats, zoals hier wordt beschreven.
  2. Zorg ervoor dat de WS en de opslagplaats zijn gesynchroniseerd met Doorvoeren en bijwerken.
  3. Herstel : in geval van nood gebruikt u de opslagplaats om de variabelebibliotheek opnieuw te bouwen in een nieuwe werkruimte:

• Maak in de zojuist gemaakte werkruimte opnieuw verbinding met uw Azure ADO-opslagplaats en synchroniseer deze.

• Alle Fabric items in deze opslagplaats worden automatisch gedownload naar uw nieuwe werkruimte.

• Nadat u uw items vanuit Git hebt gesynchroniseerd, opent u uw variabelenbibliotheken in de nieuwe werkruimte en selecteert u handmatig de gewenste actieve waardeset.

Door de klant beheerde sleutels voor Fabric werkruimten

U kunt door de klant beheerde sleutels (CMK) die zijn opgeslagen in Azure Key Vault gebruiken om een extra versleutelingslaag toe te voegen boven op Microsoft beheerde sleutels voor data-at-rest. Als Fabric ontoegankelijk of onbruikbaar wordt in een regio, zal worden overgestapt naar een back-upexemplaar. Tijdens een failover ondersteunt de CMK-functie alleen-lezenbewerkingen. Zolang de Azure Key Vault-service in orde blijft en de machtigingen voor de kluis intact blijven, blijft Fabric verbinding maken met uw sleutel en kunt u gegevens normaal lezen. Dit betekent dat de volgende bewerkingen niet worden ondersteund tijdens failover: de CMK-instelling van de werkruimte in- en uitschakelen en de sleutel bijwerken.

OneLake

In deze sectie wordt u begeleid bij de herstelprocedures voor OneLake-functies. Zie OneLake-herstel na noodgevallen voor OneLake-gegevens voor meer informatie over herstel na noodgevallen.

Beleid voor levenscyclusbeheer

In het geval dat Fabric ontoegankelijk of onbruikbaar wordt in een regio, kan het levenscyclusbeleid van OneLake nog steeds worden gelezen en bijgewerkt tijdens een failover. Alle gegevens die naar de statische of koude laag worden verplaatst, blijven in die laag staan. U kunt deze stappen volgen om uw bestaande beleid toe te passen op uw nieuwe herstelwerkruimte:

1. Roep Exportbeleid aan in uw oorspronkelijke werkruimte en sla het volledige levenscyclusbeleid op.
2. Roep Import Policy aan op uw herstelde werkruimte, waarbij u het geëxporteerde levenscyclusbeleid als aanvraagtekst gebruikt.

Regels voor resource-exemplaren

Met resource-exemplaarregels kunt u de toegang tot gegevens in OneLake veilig beheren met behulp van vertrouwde Azure resource-identiteiten. Tijdens regionale failover blijft het systeem bestaande regels voor leestoegang afdwingen. U kunt echter geen regels voor het resource-exemplaar maken, bijwerken of verwijderen totdat de werkruimte terugkeert naar een beschrijfbare status.

Gerelateerde informatie

• Microsoft Fabric handleiding voor herstel na noodgevallen