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. Hierin worden lakehouses, notebooks en Spark-taakdefinities behandeld.

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.

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 connection string 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.

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.

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.

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. In deze sectie wordt u begeleid bij de herstelprocedures voor gedeelde ervaringen. Hierin worden variabelen bibliotheken behandeld.

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.

Gerelateerde informatie

• Microsoft Fabric handleiding voor herstel na noodgevallen