Erfahrungsspezifischer Leitfaden für die Notfallwiederherstellung

Dieser Artikel bietet erfahrungsspezifische Hinweise zur Wiederherstellung Ihrer Fabric-Daten im Falle einer regionalen Katastrophe.

Beispielszenario

Viele Leitfäden in diesem Artikel verwenden das folgende Beispielszenario zur Erklärung und Illustration. Hier können Sie bei Bedarf noch einmal Informationen zu diesem Szenario nachlesen.

Nehmen wir an, Sie haben eine Kapazität C1 in Region A, die einen Arbeitsbereich W1 enthält. Wenn Sie die Notfallwiederherstellung für Kapazität C1 aktiviert haben, werden die OneLake-Daten in eine Sicherungskopie in Region B repliziert. Wenn in Region A Störungen auftreten, wechselt der Fabric-Dienst in C1 nach Region B.

Das Szenario wird in der folgenden Abbildung veranschaulicht. Das Feld auf der linken Seite zeigt den unterbrochenen Bereich. Das Feld in der Mitte stellt die weitere Verfügbarkeit der Daten nach dem Failover dar, und das Feld auf der rechten Seite zeigt die vollständig abgedeckte Situation, nachdem der Kunde aktiv geworden ist, um seine Dienste vollständig wiederherzustellen.

So sieht der allgemeine Wiederherstellungsplan aus:

1. Erstellen Sie eine neue Fabric-Kapazität C2 in einer neuen Region.

2. Erstellen Sie in C2 einen neuen Arbeitsbereich (W2), der die entsprechenden Elemente mit den gleichen Namen wie in C1.W1 enthält.

3. Arbeiten Sie kopierte Daten aus dem gestörten C1.W1 in C2.W2 ein.

4. Befolgen Sie die speziellen Anweisungen für die jeweilige Komponente, um die vollständige Funktion der Elemente wiederherzustellen.

Bei diesem Wiederherstellungsplan wird davon ausgegangen, dass die Mandanten-Heimregion weiterhin betriebsbereit bleibt. Wenn die Mieter-Home-Region einen Ausfall erlebt, sind die in diesem Artikel beschriebenen Schritte von der Wiederherstellung abhängig, die zunächst von Microsoft initiiert und abgeschlossen werden muss.

Erfahrungsspezifische Wiederherstellungspläne

Die folgenden Abschnitte bieten Schritt-für-Schritt-Anleitungen für jede Fabric-Erfahrung, um Sie durch den Erholungsprozess zu begleiten.

Datentechnik

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Datentechnikumgebung. Es behandelt Lakehouses, Notebooks, Spark-Job-Definitionen, Benutzerdatenfunktionen und GraphQL-APIs.

Lakehouse

Lakehouses aus der ursprünglichen Region können für Kunden nicht wieder verfügbar gemacht werden. Um ein Lakehouse wiederherzustellen, können Kunden es im Arbeitsbereich C2.W2 neu erstellen. Wir empfehlen zwei Ansätze für die Wiederherstellung von Lakehouses:

Ansatz 1: Verwenden eines benutzerdefinierten Skripts zum Kopieren von Delta-Tabellen und Dateien des Lakehouse

Kunden können Lakehouses mithilfe eines benutzerdefinierten Scala-Skripts neu erstellen.

1. Erstellen Sie das Lakehouse (z. B. LH1) im neu erstellten Arbeitsbereich C2.W2.

2. Erstellen Sie im Arbeitsbereich C2.W2 ein neues Notebook.

3. Informationen zum Wiederherstellen der Tabellen und Dateien aus dem ursprünglichen Lakehouse finden Sie unter Datenpfaden mit OneLake wie z. B. abfss (siehe Verbinden mit Microsoft OneLake). Sie können das folgende Codebeispiel (siehe Einführung in die Microsoft Spark Utilities) im Notizbuch verwenden, um die ABFS-Pfade von Dateien und Tabellen aus dem ursprünglichen Lakehouse zu erhalten. (Ersetzen Sie C1.W1 durch den tatsächlichen Namen des Arbeitsbereichs)

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

4. Verwenden Sie das folgende Codebeispiel, um Tabellen und Dateien in das neu erstellte Lakehouse zu kopieren.

   1. Bei Delta-Tabellen müssen die Tabellen einzeln kopiert werden, um sie im neuen Lakehouse wiederherzustellen. Bei Lakehouse-Dateien können Sie die vollständige Dateistruktur mit allen zugrunde liegenden Ordnern in einem einzelnen Schritt kopieren.

   2. Wenden Sie sich an das Supportteam, um den im Skript erforderlichen Zeitstempel des Failovers zu erhalten.

   %%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. Sobald Sie das Skript ausgeführt haben, werden die Tabellen im neuen Seehaus angezeigt.

Ansatz 2: Verwenden von Azure Storage-Explorer zum Kopieren von Dateien und Tabellen

Um nur bestimmte Lakehouse-Dateien oder Tabellen aus dem ursprünglichen Lakehouse wiederherzustellen, verwenden Sie Azure Storage-Explorer. Ausführliche Schritte finden Sie unter Integrieren von OneLake mit Azure Storage-Explorer. Verwenden Sie für große Datenmengen Ansatz 1.

Wiederherstellen von Fabric bereitgestellten Datenlake-Ansichten

Nach dem Failover kann man aus der ursprünglichen Region keine materialisierten Seeansichten mehr nutzen. Der Failover-Prozess repliziert keine Aktualisierungspläne oder die Ausführungshistorie in die sekundäre Region. Um diese Objekte wiederherzustellen, führen Sie nach der Wiederherstellung Ihrer Lakehouse-Daten die folgenden Schritte aus:

• Stellen Sie die Lakehouse-Tabellen wieder, indem Sie Ansatz 1 oder Ansatz 2 verwenden, wie zuvor in diesem Artikel beschrieben. Kopieren Sie nur die Quelltabellen.
• Stellen Sie die Notizbücher wieder her, die Ihre MLV-Definitionen enthalten. Für Genesungsschritte siehe den Abschnitt Notizbuch .
• Führen Sie die wiederhergestellten Notizbücher aus, um die MLVs im neuen Lakehouse neu zu erstellen. Informationen zum Erstellen von MLVs finden Sie unter Create a Materialized Lake View. Wenn du MLVs im früheren Schritt kopiert hast, führe CREATE OR REPLACE aus, wenn du sie neu erstellst.
• Erstelle die MLV-Aktualisierungspläne manuell im neuen Arbeitsbereich nach. Man kann keine Zeitplanhistorie oder Ausführungskennzahlen wiederherstellen.
• Wenn Ihre MLVs semantische Modelle oder Berichte versorgen, überprüfen und aktualisieren Sie die Lakehouse-ID und Dataset-ID Verweise nach Bedarf. Verbinden Sie Berichte mit dem aktualisierten Semantikmodell erneut, und überprüfen Sie die Aktualität der Daten.

Laptop

Notebooks aus der primären Region bleiben für Kunden nicht verfügbar, und der Code in den Notebooks repliziert sich nicht in die sekundäre Region. Um den Notebook-Code in der neuen Region wiederherzustellen, verwenden Sie eine der folgenden Methoden.

Ansatz 1: Benutzerseitig verwaltete Redundanz mit Git-Integration (Public Preview)

Verwenden Sie Fabric Git Integration, um Ihr Notebook mit Ihrem Azure DevOps (ADO) Repository zu synchronisieren. Nachdem der Dienst ein Failover in eine andere Region durchgeführt hat, verwenden Sie das Repository, um das Notebook im neuen Arbeitsbereich, den Sie erstellt haben, neu zu erstellen.

1. Konfigurieren Sie die Git-Integration für Ihren Arbeitsbereich, und wählen Sie Verbinden und synchronisieren mit dem ADO-Repository aus.

   

   Die folgende Abbildung zeigt das synchronisierte Notebook.

   

2. Stellen Sie das Notebook aus dem ADO-Repository wieder her.

   1. Stellen Sie im neu erstellten Arbeitsbereich erneut eine Verbindung mit Ihrem Azure ADO-Repository her.

      

   2. Wählen Sie die Schaltfläche Quellcodeverwaltung aus. Wählen Sie dann den entsprechenden Branch des Repository aus. Wählen Sie Alle aktualisieren aus. Das ursprüngliche Notizbuch wird angezeigt.

      

      

   3. Wenn das ursprüngliche Notizbuch ein Standard-Seehaus hat, konsultiere den Abschnitt Lakehouse , um das Seehaus wiederherzustellen, und verbinde dann das neu geborgene Lakehouse mit dem neu geborgenen Notizbuch.

      

   4. Die Git-Integration unterstützt keine Synchronisierung von Dateien, Ordnern oder Notebook-Momentaufnahmen im Ressourcen-Explorer für Notebooks.

      1. Wenn das ursprüngliche Notebook Dateien im Ressourcen-Explorer für Notebooks enthält, gilt Folgendes:

         1. Speichere Dateien oder Ordner auf einer lokalen Festplatte oder an einem anderen Ort.

         2. Laden Sie die Datei von Ihrem lokalen Datenträger oder Cloudlaufwerk wieder in das wiederhergestellte Notebook hoch.

      2. Wenn das ursprüngliche Notebook über eine Notebook-Momentaufnahme verfügt, speichern Sie auch die Notebook-Momentaufnahme in Ihrem eigenen Versionskontrollsystem oder auf Ihrem lokalen Datenträger.

         

         

Weitere Informationen zur Git-Integration finden Sie unter Einführung in die Git-Integration.

Ansatz 2: Manuelle Sicherung von Codeinhalten

Wenn du nicht den Git-Integrationsansatz verfolgst, speichere die neueste Version deines Codes, Dateien im Resource Explorer und Notebook-Snapshot in einem Versionskontrollsystem wie Git. Wiederherstellen Sie den Inhalt des Notizbuchs manuell nach einer Katastrophe:

1. Nutze die Funktion Notizbuch importieren , um den Notizbuch-Code zu importieren, den du wiederherstellen möchtest.

   

2. Wechseln Sie nach dem Importieren zum gewünschten Arbeitsbereich (z. B. C2.W2), um darauf zuzugreifen.

3. Wenn das ursprüngliche Notebook über ein Standard-Lakehouse verfügt, verweisen Sie auf den Lakehouse-Abschnitt. Verbinden Sie dann das neu wiederhergestellte Lakehouse (das über den gleichen Inhalt verfügt wie das ursprüngliche Standard-Lakehouse) mit dem neu wiederhergestellten Notebook.

4. Wenn das ursprüngliche Notebook Dateien oder Ordner im Ressourcen-Explorer enthält, laden Sie die Dateien oder Ordner, die im Versionskontrollsystem des Benutzers bzw. der Benutzerin gespeichert sind, wieder hoch.

Spark-Auftragsdefinition

Spark-Job-Definitionen (SJD) aus der primären Region bleiben nicht verfügbar, und OneLake repliziert die Hauptdefinitionsdatei und die Referenzdatei im Notizbuch in die sekundäre Region. Wenn Sie das SJD in der neuen Region wiederherstellen möchten, folgen Sie den in diesem Abschnitt beschriebenen manuellen Schritten. Die historischen Läufe der SJD werden nicht wiederhergestellt.

Sie können die SJD-Elemente wiederherstellen, indem Sie den Code aus der ursprünglichen Region kopieren, indem Sie Azure Storage-Explorer verwenden und lakehouse-Verweise nach der Katastrophe manuell erneut verbinden.

1. Erstelle ein neues SJD-Element (zum Beispiel SJD1) im neuen Arbeitsbereich C2. W2, mit denselben Einstellungen und Konfigurationen wie das ursprüngliche SJD-Element (zum Beispiel Sprache, Umgebung usw.).

2. Verwenden Sie Azure Storage-Explorer, um Libs, Mains und Snapshots aus dem ursprünglichen SJD-Element in das neue SJD-Element zu kopieren.

   

3. Der Code-Inhalt erscheint im neu erstellten SJD. Sie müssen die neu wiederhergestellte Lakehouse-Referenz manuell zum Projekt hinzufügen (siehe die Schritte zur Lakehouse-Wiederherstellung). Benutzer müssen die ursprünglichen Kommandozeilenargumente manuell erneut eingeben.

   

Nun können Sie Ihre neu wiederhergestellte SJD ausführen oder planen.

Ausführliche Informationen zu Azure Storage-Explorer finden Sie unter Integrate OneLake with Azure Storage-Explorer.

Benutzerdatenfunktionen

Um Ihre Nutzerdatenfunktionen in einem gesunden Bereich wiederherzustellen, verwenden Sie eine der folgenden Methoden.

Ansatz 1: Mit Git-Integration (empfohlen)

Der bevorzugte Wiederherstellungsmechanismus ist die Fabric Git-Integration. Indem Sie Benutzerdatenfunktionsprojekte mit einem Azure DevOps- oder GitHub-Repository synchronisieren, können Sie sie nach dem Failover schnell in einem neuen Arbeitsbereich rekonstruieren.

Bereite dich auf eine Katastrophe vor

1. Konfigurieren Sie die Fabric Git-Integration für den Arbeitsbereich, der die Benutzerdatenfunktion hostet.
2. Verbinden Sie den Arbeitsbereich mit einem Azure DevOps- oder GitHub-Repository.
3. Speichern Sie alle Benutzerdaten im Repository und synchronisieren Sie Änderungen regelmäßig.
4. Speichere umgebungsspezifische Einstellungen bei Bedarf separat in variablen Bibliotheken.

Wiederherstellungsschritte

Nach einer regionalen Katastrophe:

1. Schaffen Sie eine neue Fabric-Kapazität in einer gesunden Region, wie zum Beispiel C2.
2. Erstelle einen neuen Arbeitsbereich, wie zum Beispiel W2, in der neuen Funktion.
3. Verbinden Sie den Arbeitsbereich mit demselben Azure DevOps- oder GitHub-Repository.
4. Öffnen Sie Quellcodeverwaltung und synchronisieren Sie den Inhalt des Repositorys mit dem Arbeitsbereich.
5. Erstellen Sie alle abhängigen Fabric-Ressourcen neu, oder stellen Sie sie wieder her, beispielsweise Lakehouses, SQL-Datenbanken in Fabric, Warehouses und Business Events.
6. Implementiere die Benutzerdatenfunktionen neu.
7. Funktionsausführung und Abhängigkeitskonnektivität validieren.
8. Aktualisieren Sie nachgelagerte Anwendungen, Datenpipelines oder andere integrierte Funktionen, um auf die wiederhergestellten Funktionen zu verweisen.
9. Vollständige End-to-End-Validierung all deiner Szenarien.

Wichtige Überlegungen

• Die Git-Integration stellt nur Quellcode und Projekt-Assets wieder.
• Historische Hinrichtungsprotokolle werden nicht wiederhergestellt.
• Downstream-Systeme erfordern möglicherweise eine Endpunkt-Neubindung.

Weitere Informationen finden Sie unter Quellcodeverwaltung und Bereitstellung von Benutzerdatenfunktionen.

Ansatz 2: Manuelle Wiederherstellung

Wenn die Git-Integration vor der Katastrophe nicht konfiguriert war, kannst du Benutzerdatenfunktionen manuell aus Quellcode-Backups rekonstruieren.

Bereite dich auf eine Katastrophe vor

Erledigen Sie regelmäßig die folgenden Aufgaben und speichern Sie die Elemente in einem externen Quellcode-Repository oder Backup-Standort:

• Exportiere den Quellcode der Funktion in ein GitHub-Repository.
• Dokumentieren und bewahren Sie Abhängigkeitsinformationen.
• Dokumentiere die Umgebungseinstellungen.

Wiederherstellungsschritte

Nach einer regionalen Katastrophe:

1. Schaffen Sie eine neue Fabric-Kapazität in einer gesunden Region, wie zum Beispiel C2.
2. Erstelle einen neuen Arbeitsbereich, zum Beispiel W2.
3. Wiederherstellen Sie alle von der Funktion benötigten Ressourcen, einschließlich Lakehouses, SQL-Datenbanken in Fabric, Lagerhäusern, Eventhäusern und externen Diensten.
4. Erstelle ein neues Projekt zur Benutzerdatenfunktion.
5. Importiere oder erstelle den Quellcode der Funktion nach.
6. Wenden Sie die Laufzeit-Konfigurationseinstellungen erneut an.
7. Installiere alle Funktionsabhängigkeiten neu.
8. Setze die Funktion neu ein.
9. Konfigurieren Sie die Authentifizierung und Autorisierung neu.
10. Business-Event-Publisher oder -Konsumenten neu erstellen, falls verwendet.
11. Führen Sie End-to-End-Validierungstests für Ihre Szenarien und Integrationen durch.

GraphQL

GraphQL-Elemente aus der primären Region sind nach einem regionalen Notfall nicht verfügbar, und GraphQL-Definitionen und -Konfigurationen werden nicht in die sekundäre Region repliziert. Um GraphQL in einer neuen Region wiederherzustellen, verwenden Sie einen der folgenden Ansätze.

Ansatz 1: Benutzerverwaltete Redundanz mit Git-Integration

Die beste Möglichkeit, diesen Prozess einfach und schnell zu machen, besteht darin, Fabric Git-Integration zu verwenden und dann Ihre GraphQL mit Ihrem ADO-Repository zu synchronisieren. Nachdem der Dienst auf eine andere Region umgeschaltet hat, können Sie das Repository verwenden, um die GraphQL im neuen Arbeitsbereich, den Sie erstellt haben, neu zu erstellen.

1. Erstellen Sie einen neuen Arbeitsbereich in der Zielkapazität und -region.

2. Stellen Sie alle abhängigen Datenquellen wie Lakehouse-, Warehouse- oder SQL-Datenbanken wieder her, indem Sie die entsprechenden Wiederherstellungsschritte ausführen.

3. Aktualisieren Sie die GraphQL-Definition so, dass sie auf die neu wiederhergestellten Ressourcen verweist, indem sie umgebungsspezifische Referenzen wie Quell-Arbeitsbereich-IDs, Quell-Item-IDs und Verbindungsdetails ändert. Dieser Schritt stellt die korrekte Bindung bei der Bereitstellung sicher.

4. Deploye GraphQL-Elemente aus dem Git-Repository erneut in den neuen Arbeitsbereich. In diesem Schritt wird die API-Struktur und -Konfiguration mithilfe der aktualisierten Definitionen neu erstellt.

5. Wenden Sie die Element-Einstellungen erneut an, einschließlich Rollen, Zugriffskontrollen und Authentifizierungskonfiguration.

6. Erneutes Anwenden von Endpunktreferenzen durch Aktualisieren von Anwendungen oder Integrationen für die Verwendung des neu erstellten GraphQL-Endpunkts.

7. Aktualisieren Sie alle vorhandenen Bereitstellungspipelines, die auf den alten Arbeitsbereich verweisen, um auf den neu erstellten Arbeitsbereich zu verweisen.

8. Überprüfen der End-to-End-Funktionalität der API.

Ansatz 2: Manueller Ansatz

Wenn Sie den Git-Integrationsansatz nicht verwenden, können Sie den folgenden manuellen Ansatz verwenden, um GraphQL wiederherzustellen.

1. Erstellen Sie einen neuen Arbeitsbereich in der Zielkapazität und -region.

2. Wiederherstellen aller abhängigen Datenquellen, z. B. Lakehouse-, Warehouse- oder SQL-Datenbanken.

3. Erstellen Sie die GraphQL-API manuell im neuen Arbeitsbereich neu, einschließlich Schemadefinitionen, Datenquellenverbindungen und Beziehungen.

4. Wenden Sie die Element-Einstellungen erneut an, einschließlich Rollen, Zugriffskontrollen und Authentifizierungskonfiguration.

5. Erneutes Anwenden von Endpunktreferenzen durch Aktualisieren von Anwendungen oder Integrationen für die Verwendung des neu erstellten GraphQL-Endpunkts.

6. Aktualisieren Sie alle vorhandenen Bereitstellungspipelines, die auf den alten Arbeitsbereich verweisen, um auf den neu erstellten Arbeitsbereich zu verweisen.

7. Überprüfen der End-to-End-Funktionalität der API.

Wichtige Überlegungen

1. GraphQL basiert auf externen Abhängigkeiten (z. B. Lakehouse, Warehouse und SQL), die Sie vor der GraphQL-Bereitstellung wiederherstellen müssen.

2. GraphQL-API-Definitionen enthalten umgebungsspezifische Verweise (wie sourceWorkspaceId und sourceItemId). Bei der Wiederherstellung in einem neuen Bereich werden diese Verweise möglicherweise ungültig. Aktualisieren Sie sie so, dass sie auf neu bereitgestellte Ressourcen verweisen.

3. Die automatische Neubindung von Datenquellen ist in Notfallwiederherstellungsszenarien nicht garantiert, insbesondere bei Verwendung gespeicherter Anmeldeinformationen oder arbeitsbereichübergreifender Verbindungen.

4. Andere Item-Einstellungen wie Überwachung, Autorisierung, RBAC, Introspektion und mehr werden nach dem Failover nicht übernommen. Sie müssen diese Einstellungen in der neuen Region erneut einrichten.

Referenzen

• Übersicht über die Fabric Git-Integration – Microsoft Fabric | Microsoft Lernen

• Quellcodeverwaltungs- und Bereitstellungspipelinen in der API für GraphQL – Microsoft Fabric | Microsoft Lernen 

App

Das System repliziert Fabric Apps, einschließlich ihres Codes, ihrer Konfiguration und Metadaten, nicht auf sekundäre Regionen. Wenn die primäre Region fehlschlägt, bleibt die App nicht verfügbar. Für die Wiederherstellung speichern Sie den Quellcode der App außerhalb des Systems in GitHub, Azure DevOps oder einem anderen Quellcodesystem. Stellen Sie App-Daten separat wieder, indem Sie den Disaster Recovery-Richtlinien für jeden zugrundeliegenden Fabric-Datenspeicher folgen.

Manueller Ansatz

Man kann eine Fabric-App nach einer regionalen Katastrophe manuell wiederherstellen, indem man den Anwendungsquellcode und die Rayfin-CLI verwendet. 

Voraussetzungen 

Bevor eine Katastrophe eintritt:

• Speichere den Quellcode der Fabric App in GitHub, Azure DevOps oder einem anderen Quellcode-Repository. 

• Dokumentieren Sie den Wiederherstellungsprozess.  

Wiederherstellungsschritte 

1. Erstellen Sie einen neuen Arbeitsbereich in der Zielkapazität und -region. 

2. Wiederherstellen Sie abhängige Ressourcen, bevor Sie die Anwendung neu bereitstellen.  

3. Rufen Sie den neuesten Quellcode der Fabric App aus Ihrem Quellcode-Repository oder lokalem Backup ab. 

4. Vom Anwendungsquellenverzeichnis aus bereiten Sie die Fabric App über Rayfin CLI in den Wiederherstellungsarbeitsbereich ein. Führen Sie rayfin up --workspace <new workspace> aus. 

5. Stellen Sie das untergeordnete Element der App (SQL-Datenbank in Fabric) wieder her, indem Sie die entsprechenden Wiederherstellungsverfahren befolgen.  

6. Setze die Einstellungen auf Gegenstandsebene erneut an, einschließlich Rollen und Zugriffskontrollen bei Bedarf.  

7. Validiere die Anwendungsfunktionalität und stelle sicher, dass die Nutzer die richtigen Berechtigungen haben.  

Wichtig 

• Pflege des Fabric-App-Quellcodes außerhalb der Fabric-Region, um die Wiederherstellung zu ermöglichen.  

• Anwendungsdaten in der Datenbank werden im Rahmen des Fabric App-Deployment-Prozesses nicht wiederhergestellt und müssen separat wiederhergestellt werden.  Man kann eine Fabric-App nach einer regionalen Katastrophe manuell wiederherstellen, indem man den Anwendungsquellcode und die Rayfin-CLI verwendet. 

Azure Databricks Storage

Azure Databricks Storage speichert Daten in OneLake. Um Ihre Daten vor einem regionalen Ausfall zu schützen, aktivieren Sie die Disaster Recovery-Einstellung auf der Fabric-Kapazität, die das Azure Databricks Storage Item enthält. Wenn Sie diese Einstellung aktivieren, repliziert OneLake die Daten asynchron in die Azure-gepaarte Region.

Wenn OneLake ein regionales Failover initiiert, können Anwendungen weiterhin auf die replizierten Daten über den globalen OneLake-Endpunkt zugreifen, auch nachdem das Failover abgeschlossen ist. Der fortlaufende Zugriff über die öffentlichen OneLake-APIs erfordert kein weiteres Azure Databricks Storage Item oder das Kopieren der Daten in einen anderen Arbeitsbereich.

Überprüfen Sie OneLake Disaster Recovery and Data Protection auf das geltende Verhalten, die Überlegungen und Einschränkungen.

Für die Azure Databricks-spezifische Notfallwiederherstellungsplanung siehe Disaster recovery - Azure Databricks.

Data Science

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Data Science-Umgebung. Hier werden ML-Modelle und -Experimente behandelt.

ML-Modell und Experiment

Data-Science-Objekte aus der primären Region bleiben für Kunden nicht verfügbar, und die Inhalte sowie Metadaten in ML-Modellen und Experimenten replizieren sich nicht auf die sekundäre Region. Um sie vollständig in der neuen Region wiederherzustellen, müssen Sie die Codeinhalte in einem Versionskontrollsystem wie Git speichern und nach dem Notfall manuell erneut ausführen.

1. Stellen Sie das Notebook wieder her. Weitere Informationen finden Sie in den Schritten für die Notebookwiederherstellung.

2. Konfiguration, historisch ausgeführte Metriken und Metadaten replizieren sich nicht auf die gepaarte Region. Du musst jede Version deines Data-Science-Codes erneut ausführen, um ML-Modelle und Experimente nach der Katastrophe vollständig wiederherzustellen.

Data Warehouse

Dieser Leitfaden führt Sie durch die Genesungsprozeduren für die Fabric Data Warehouse Arbeitsbelastung. Es deckt Lagergegenstände ab.

Lagerhaus

Von der ursprünglichen Region aus kannst du keine Lagerhäuser erreichen. Führen Sie die beiden folgenden Schritte aus, um Warehouses wiederherzustellen.

1. Erstelle ein neues temporäres Lakehouse im Arbeitsbereich C2.W2 für die Daten, die du aus dem ursprünglichen Warehouse kopierst.

2. Befüllen Sie die Delta-Tabellen des Lagers mithilfe des Warehouse-Explorers und der T-SQL-Funktionen (siehe Tabellen in Fabric Data Warehouse).

Datenerfassung über Lakehouse und T-SQL-Code

Gehen Sie im neu erstellten Arbeitsbereich C2.W2 wie folgt vor:

1. Erstellen Sie in C2.W2 ein vorübergehendes Lakehouse (LH2).

2. Stellen Sie die Delta-Tabellen aus dem ursprünglichen Warehouse im temporären Lakehouse wieder her, indem Sie die Schritte zur Lakehouse-Wiederherstellung befolgen.

3. Erstellen Sie in C2.W2 ein neues Warehouse (WH2).

4. Stellen Sie in Ihrem Warehouse-Explorer eine Verbindung mit dem vorübergehenden Lakehouse her.

5. Je nachdem, wie du Tabellendefinitionen vor dem Datenimport bereitstellst, kann das tatsächliche T-SQL, das für Importe verwendet wird, variieren. Um Warehouse-Tabellen aus Lakehouses wiederherzustellen, kannst du den INSERT INTO-, SELECT INTO- oder CREATE TABLE AS SELECT-Ansatz verwenden. Im folgenden Beispiel verwenden wir INSERT INTO. Wenn du den folgenden Code verwendest, ersetze Beispiele durch tatsächliche Tabellen- und Spaltennamen.

   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. Ändern Sie die Verbindungszeichenfolge in Anwendungen, die Ihr Fabric-Warehouse verwenden.

Gespiegelte Datenbanken

Kunden können aus der primären Region nicht auf gespiegelte Datenbanken zugreifen, und die Einstellungen werden nicht auf die sekundäre Region repliziert. Um eine gespiegelte Datenbank nach einem regionalen Fehler wiederherzustellen, muss man sie in einem anderen Arbeitsbereich aus einer anderen Region neu erstellen.

Data Factory

Kunden können nicht auf Data Factory-Elemente aus der primären Region zugreifen, und die Einstellungen und Konfigurationen in Pipelines oder Dataflow Gen2-Items werden nicht auf die sekundäre Region repliziert. Um diese Elemente nach einem regionalen Ausfall wiederherzustellen, müssen Sie Ihre Datenintegrationselemente in einem anderen Arbeitsbereich aus einer anderen Region neu erstellen. Die folgenden Abschnitte enthalten ausführlichere Informationen.

Datenflüsse Gen2

Um ein Dataflow Gen2-Element in der neuen Region wiederherzustellen, exportiere eine .pqt Datei in ein Versionskontrollsystem wie Git und stelle dann nach dem Unglück manuell den Dataflow Gen2-Inhalt wieder her.

1. Aus Ihrem Dataflow Gen2-Element wählen Sie im Home-Tab des Power Query-Editors "Vorlage exportieren".

   

2. Im Dialogfeld "Vorlage exportieren " geben Sie für diese Vorlage einen Namen (verpflichtend) und eine Beschreibung (optional) ein. Wählen Sie dann OK.

   

3. Erstellen Sie nach dem Notfall ein neues Dataflow Gen2-Element im neuen Arbeitsbereich C2.W2.

4. Wählen Sie im aktuellen Ansichtsbereich des Power Query-Editors Import aus einer Power Query Vorlage aus.

   

5. Im Öffnen-Dialog blättern Sie zu Ihrem Standard-Download-Ordner und wählen Sie die Datei aus, die .pqt Sie in den vorherigen Schritten gespeichert haben. Wählen Sie anschließend Öffnen aus.

6. Die Vorlage wird dann in Ihr neues Dataflow Gen2-Element importiert.

Die Save As-Funktion für Dataflows wird im Falle einer Notfallwiederherstellung nicht unterstützt.

Pipelines

Kunden können im Falle einer regionalen Katastrophe nicht auf Pipelines zugreifen, und die Konfigurationen werden nicht in die gekoppelte Region repliziert. Bauen Sie Ihre kritischen Pipelines in mehreren Arbeitsbereichen in verschiedenen Regionen auf.

Kopierauftrag

CopyJob-Benutzer müssen proaktive Maßnahmen ergreifen, um vor einer regionalen Katastrophe zu schützen. Mit dem folgenden Ansatz wird sichergestellt, dass nach einer regionalen Katastrophe die CopyJobs eines Benutzers weiterhin verfügbar bleiben.

Benutzerverwaltete Redundanz mit Git-Integration (in der öffentlichen Vorschau)

Der beste Weg, diesen Prozess einfach und schnell zu gestalten, ist die Fabric Git-Integration und anschließend dein CopyJob mit deinem Azure DevOps-Repository zu synchronisieren. Nachdem der Dienst auf eine andere Region umgeschaltet wurde, können Sie das Repository verwenden, um den CopyJob im neuen, von Ihnen erstellten Arbeitsbereich neu zu erstellen.

1. Konfigurieren Sie die Git-Integration Ihres Arbeitsbereichs und wählen Sie Connect and Sync mit dem Azure DevOps-Repo.

   

   Die folgende Abbildung zeigt den synchronisierten CopyJob.

   

2. Wiederherstellen Sie den CopyJob aus dem Azure DevOps-Repo.

   1. Im neu erstellten Arbeitsbereich verbinden und synchronisieren Sie erneut Ihr Azure DevOps-Repo. Alle Fabric-Elemente in diesem Repository werden automatisch in deinen neuen Arbeitsbereich heruntergeladen.

      

   2. Wenn der ursprüngliche CopyJob ein Lakehouse verwendet, können Benutzer auf den abschnitt Lakehouse verweisen, um das Lakehouse wiederherzustellen und dann den neu wiederhergestellten CopyJob mit dem neu wiederhergestellten Lakehouse zu verbinden.

Weitere Informationen zur Git-Integration finden Sie unter Einführung in die Git-Integration.

Apache Airflow-Auftrag

Sie müssen proaktive Maßnahmen ergreifen, um Apache Airflow-Arbeitsplätze in Fabric vor regionalen Katastrophen zu schützen.

Verwalten Sie Redundanz durch Fabric Git-Integration. Zuerst synchronisiere deinen Airflow-Auftrag mit deinem ADO Repository. Wenn der Dienst ein Failover in eine andere Region durchführt, kannst du das Repository verwenden, um den Airflow-Job im neu erstellten Arbeitsbereich neu zu erstellen.

Befolgen Sie diese Schritte, um dieses Ziel zu erreichen:

1. Konfigurieren Sie die Git-Integration Ihres Arbeitsbereichs und wählen Sie Verbinden und synchronisieren mit dem ADO-Repository aus.

2. Danach sieht man, dass der Airflow-Auftrag mit dem ADO Repository synchronisiert ist.

3. Wenn Sie den Airflow-Auftrag aus dem ADO-Repository wiederherstellen müssen, erstellen Sie einen neuen Arbeitsbereich, stellen Sie eine Verbindung her, und synchronisieren Sie es erneut mit Ihrem Azure ADO-Repository. Alle Fabric-Artikel, einschließlich Airflow, in diesem Repository werden automatisch in Ihren neuen Arbeitsbereich heruntergeladen.

Echtzeitintelligenz

Dieser Leitfaden führt Sie durch die Wiederherstellungsprozesse für die Real-Time Business Intelligence-Erfahrung. Es behandelt KQL-Datenbanken, Abfragesätze und Eventstream-Elemente.

Activator

Aktiviererelemente aus der primären Region sind für Kunden nicht verfügbar, und Aktivierungsauslöserdefinitionen werden nicht in die sekundäre Region repliziert. Aktivierer müssen proaktive Schritte unternehmen, um sich auf die regionale Notfallwiederherstellung vorzubereiten.

Um sicherzustellen, dass Sie Aktivatorelemente im Falle eines regionalen Notfalls wiederherstellen können, richten Sie Fabric Git-Integration ein, um Triggerdefinitionen zu sichern und in einem Arbeitsbereich in einer anderen Region wiederherzustellen.

1. Konfigurieren Sie Fabric Git-Integration für den Arbeitsbereich, der Ihr Aktivatorelement enthält, und synchronisieren Sie Ihre Triggerdefinitionen mit Ihrem Git-Repository.
2. Halten Sie die Definitionen Ihrer Activator-Trigger regelmäßig eingecheckt und synchronisiert.
3. Erstellen Sie während der Wiederherstellung einen neuen Arbeitsbereich in der Zielregion (C2). W2), verbinden Sie es mit demselben Repository, und synchronisieren Sie sie, um die Triggerdefinitionen wiederherzustellen.
4. Konfigurieren und Überprüfen aller Aktivatordatenquellen und Abhängigkeiten im neuen Arbeitsbereich.

Weitere Informationen zur Git-Integration finden Sie unter Einführung in die Git-Integration.

Graph-Modell/Queryset

Kunden können aus der primären Region nicht auf Graph Model- und Graph-Abfragesets zugreifen, und Fabric repliziert diese Items nicht in die sekundäre Region. Um sie wiederherzustellen, erstellen oder verwenden Sie eine Kapazität in einer anderen Region und erstellen Sie dort das Graphmodell und die Graph-Abfrageset-Elemente neu.

1. Erstellen Sie oder verwenden Sie eine vorhandene Fabric-Kapazität in einer anderen Region, die von der Katastrophe nicht betroffen ist.

2. Erstellen Sie einen neuen Arbeitsbereich, oder verwenden Sie einen vorhandenen Arbeitsbereich in dieser Kapazität.

3. Erstellen Sie das Graph-Modell-Element im sekundären Arbeitsbereich (siehe Schritt 2) neu. Konfigurieren Sie die Modelldefinition, einschließlich Knoten, Kanten und andere, so um, dass sie dem ursprünglichen Graph-Modell entspricht.

4. Wenn sich das ursprüngliche Lakehouse in der fehlerhaften Region befindet, stellen Sie es zuerst wieder her, indem Sie dem Lakehouse-Abschnitt folgen.

5. Verbinden Sie ein Lakehouse als OneLake-Datenquelle für das neu erstellte Graph-Model-Objekt. Verwenden Sie das wiederhergestellte Seehaus, wenn es sich in der fehlerhaften Region befand, oder stellen Sie die Verbindung zum vorhandenen Seehaus wieder her, wenn es weiterhin verfügbar ist.

6. Konfigurieren Sie alle Datenladepläne oder Verbindungen für das Graph-Modell im neuen Arbeitsbereich neu.

7. Erstellen Sie das Graph-Abfrageset-Element im sekundären Arbeitsbereich neu. Geben Sie die Abfragen und alle gespeicherten Abfragekonfigurationen aus dem ursprünglichen Graph-Abfragesatz manuell erneut ein.

KQL-Datenbank/-Abfrageset

KQL-Datenbank- und Abfrageset-Nutzer müssen proaktive Maßnahmen ergreifen, um sich vor einer regionalen Katastrophe zu schützen. Der folgende Ansatz stellt sicher, dass im Falle einer regionalen Katastrophe die Daten in Ihren KQL-Datenbanken und Abfragesätzen sicher und zugänglich bleiben.

Verwenden Sie die folgenden Schritte, um eine effektive Notfallwiederherstellungslösung für KQL-Datenbanken und -Abfragesets zu gewährleisten:

1. Einrichtung unabhängiger KQL-Datenbanken: Konfigurieren Sie zwei oder mehr unabhängige KQL-Datenbanken und Abfragesätze auf dedizierten Fabric-Kapazitäten. Richten Sie diese Datenbanken über zwei verschiedene Azure-Regionen (vorzugsweise Azure-gepaarte Regionen) ein, um die Resilienz zu maximieren.

2. Verwaltungsaktivitäten replizieren: Spiegeln Sie jede Managementmaßnahme, die Sie in einer KQL-Datenbank ausführen, in der anderen. Dieser Ansatz hält beide Datenbanken synchron. Zu den wichtigsten Aktivitäten, die repliziert werden sollen, gehören:

   • Tabellen: Stellen Sie sicher, dass die Tabellenstrukturen und Schema-Definitionen über die Datenbanken hinweg konsistent sind.

   • Zuordnung: Duplizieren Sie alle erforderlichen Zuordnungen. Stellen Sie sicher, dass Datenquellen und -ziele korrekt übereinstimmen.

   • Richtlinien: Stellen Sie sicher, dass beide Datenbanken ähnliche Datenspeicherungs-, Zugriffs- und andere relevante Richtlinien haben.

3. Authentifizierung und Autorisierung verwalten: Richte die erforderlichen Berechtigungen für jedes Replikat ein. Stellen Sie sicher, dass Sie die richtigen Autorisierungsstufen festlegen, die den erforderlichen Personen Zugang gewähren und gleichzeitig die Sicherheitsstandards einhalten.

4. Parallele Datenerfassung: Damit die Daten konsistent und in mehreren Regionen verfügbar sind, laden Sie dasselbe Dataset zum gleichen Zeitpunkt in die einzelnen KQL-Datenbanken, zu dem Sie es erfassen.

Ereignisstrom

Ein Eventstream ist ein zentraler Ort in der Fabric-Plattform zum Erfassen, Transformieren und Weiterleiten von Echtzeitereignissen an verschiedene Ziele (z. B. Lakehouses, KQL-Datenbanken/Querysets) mit einer No-Code-Benutzererfahrung. Solange die Ziele die Katastrophenwiederherstellung unterstützen, verlieren Eventstreams keine Daten. Nutzen Sie daher die Katastrophenwiederherstellungsfähigkeiten dieser Zielsysteme, um die Datenverfügbarkeit zu gewährleisten.

Sie können auch Geo-Redundanz erreichen, indem Sie identische Eventstream-Workloads in mehreren Azure-Regionen als Teil einer Multi-Site-Active/Active-Strategie einsetzen. Mit einem Multi-Site-Aktiv/Aktiv-Ansatz können Sie in jeder der bereitgestellten Regionen auf Ihre Workload zugreifen. Dieser Ansatz ist der komplexeste und teuerste Ansatz für die Notfallwiederherstellung, kann aber die Wiederherstellungszeit in den meisten Situationen auf nahezu Null reduzieren. Um vollständig georedundant zu sein:

1. Erstellen Sie Repliken Ihrer Datenquellen in verschiedenen Regionen.

2. Erstellen Sie Eventstream-Elemente in den entsprechenden Regionen.

3. Verbinden dieser neuen Elemente mit den identischen Datenquellen

4. Hinzufügen identischer Ziele für jeden Eventstream in verschiedenen Regionen

Geschäftsereignisse, Fabric-Ereignisse und Azure-Ereignisse

Obwohl Business Events, Fabric Events und Azure Events in Microsoft Fabric dieselbe Real-Time Hub-Infrastruktur teilen, haben sie unterschiedliche Ursprünge, Verhaltensweisen und Wiederherstellungsanforderungen. Verstehen Sie diese Unterschiede, bevor Sie eine Katastrophenwiederherstellung planen:

• Fabric Events sind Event-Abonnements, die auf Aktivitäten reagieren, die von Fabric-Ressourcen selbst erzeugt werden. Diese Ereignisse umfassen Änderungen am Lebenszyklus von Workspaceelementen (etwa das Erstellen, Aktualisieren oder Löschen von Lakehouses, Notebooks oder Data Warehouses), Auftragsausführungen (etwa Pipelineausführungen oder Notebookausführungen) sowie OneLake-Datei- und Ordnervorgänge. Diese Abonnements sind pushbasiert und kurzlebig. Die Abonnements werden nicht auf die sekundäre Region übertragen.

• Azure Ereignisse sind Ereignisabonnements für Aktivitäten, die von Azure Blob Storage Konten erstellt werden. Diese Azure Ressourcen sind unabhängig von jeder Fabric Kapazität oder Region vorhanden. Obwohl die Azure Blob Storage-Ressource selbst während eines Fabric regionalen Ausfalls verfügbar bleiben kann, werden die im Real-Time Hub konfigurierten Abonnements nicht auf die sekundäre Region repliziert und müssen neu erstellt werden.

• Geschäftsereignisse sind eine unterschiedliche Funktion in Fabric Real-Time Intelligence, mit der Teams aussagekräftige Geschäftssignale definieren, veröffentlichen und darauf reagieren können. Geschäftsereignisse werden aus Fabric über Aktivierer, Spark-Notizbücher oder Benutzerdatenfunktionen generiert, die dann auf Real-Time Hub veröffentlicht werden, in dem nachgeschaltete Verbraucher wie Aktivator, Eventhouse oder Power Automate darauf reagieren können. Ereignisschemas werden zentral über die Schemaregistrierung gesteuert. Eventhouse speichert automatisch jedes veröffentlichte Geschäftsereignis, sodass sich die Wiederherstellung direkt auf die Verfügbarkeit des Geschäftsereignisverlaufs auswirkt. Keine der Herausgeber- oder Verbraucherkonfigurationen, Schemadefinitionen oder Abonnements werden in die sekundäre Region repliziert.

Führen Sie die folgenden Schritte aus, um Business Events, Fabric-Ereignisse und Azure-Ereignisse im neuen Arbeitsbereich in der Wiederherstellungsregion wiederherzustellen.

Für Geschäftsveranstaltungen:

1. Erstellen Sie das von Herausgebern und Verbrauchern verwendete Geschäftsereignis neu, indem Sie dem Artikel "Geschäftsereignisse erstellen" in Fabric Real-Time Hub folgen. Während der Erstellung des Geschäftsereignisses erstellen Sie die Ereignisschemasatz-Ressource. Die Eventhouse-Ressource ist je nach Szenario optional. Wenn du dein Event Schema Set mit Git-Integration gesichert hast, stelle es zuerst wieder her, indem du dem Abschnitt Event Schema Set folgst, und verweise dann auf das Business-Event auf das wiederhergestellte Schema-Set.

2. Erstellen Sie alle publisher Elemente neu, die Geschäftsereignisse generieren, z. B. Spark-Notizbücher oder Benutzerdatenfunktionen, im neuen Arbeitsbereich, indem Sie den publisher Artikeln folgen: Verwenden von User Data Function as a Business Events Publisher, Use Activator as a Business Events Publisher, Use Notebook as a Business Events Publisher und "Eventstream" als Publisher für Geschäftsereignisse verwenden.

3. Erstellen Sie die Consumer-Abonnements im Real-Time Hub neu (z. B. Activator-Regeln, Notebook-Trigger oder Power Automate-Flows), die ursprünglich auf Geschäftsereignisse in der betroffenen Region reagierten, indem Sie die Artikel Eventhouse and Real-Time Dashboard Integration with Business Events und Geschäftsereignisse aus Activator nutzen befolgen.

4. Überprüfen Sie, ob Ereignisse end-to-End ablaufen, indem Sie überprüfen, ob Abonnements aktiv sind und dass Daten an den erwarteten Zielen in der Wiederherstellungsregion ankommen.

Für Fabric-Events:

1. Erstellen Sie die Abonnements im Real-Time hub neu, sodass sie auf die Arbeitsbereichselemente, Aufträge oder OneLake-Pfade verweisen, die Sie in der Wiederherstellungsregion wiederhergestellt haben, wie im Artikel Explore Fabric events in Fabric Real-Time hub beschrieben.

2. Überprüfen Sie, ob Ereignisse end-to-End ablaufen, indem Sie überprüfen, ob Abonnements aktiv sind und dass Daten an den erwarteten Zielen in der Wiederherstellungsregion ankommen.

Für Azure Ereignisse:

1. Azure Blob Storage-Konten sind nicht von einem regionalen Fabric-Ausfall betroffen. Erstellen Sie die Ereignisabonnements in Real-Time Hub neu, die auf dieselben Azure Blob Storage Konten zeigen, indem Sie dem Artikel "Benachrichtigungen für Azure Blob Storage Ereignisse im Real-Time Hub festlegen" folgen.

2. Überprüfen Sie, ob Ereignisse end-to-End ablaufen, indem Sie überprüfen, ob Abonnements aktiv sind und dass Daten an den erwarteten Zielen in der Wiederherstellungsregion ankommen.

Ereignisschemasatz

Ein Ereignisschema-Set ist das Fabric Element, das Ereignistyp- und Schema-Definitionen in Real-Time Intelligence enthält. Weitere Funktionen bauen darauf auf: Publisher schreiben Ereignisse, die ihren Schemata entsprechen, und Konsumenten lesen nach denselben Definitionen.

Ereignisschema-Sets aus der primären Region bleiben für Kunden nicht verfügbar und werden nicht in die sekundäre Region repliziert. Da ein Ereignisschema-Set jedoch eine dauerhafte, autorisierte Definition und kein flüchtiges Abonnement ist, kann man es im Voraus sichern und wiederherstellen, anstatt es von Hand neu zu verfassen.

Empfohlen: Backup mit Fabric Git Integration

Um ein nach einer regionalen Katastrophe gesetzten Ereignisschemas wiederherzustellen, richten Sie die Fabric Git-Integration ein, bevor eine Katastrophe eintritt, und synchronisieren Sie den Arbeitsbereich mit Ihren Ereignisschema-Sets mit Ihrem Git-Repository.

1. Konfigurieren Sie die Fabric Git-Integration für den Arbeitsbereich, der Ihr Event Schema Set enthält, und synchronisieren Sie es mit Ihrem Git-Repository.

2. Halten Sie das Ereignisschema-Set regelmäßig festgelegt und synchronisiert, insbesondere nach dem Hinzufügen von Ereignistypen oder der Veröffentlichung neuer Schema-Versionen.

3. Während der Wiederherstellung erstellen Sie einen neuen Arbeitsbereich im Zielbereich (C2. W2), verbinden Sie es mit demselben Repository und synchronisieren, um das Ereignisschema-Set wiederherzustellen. Da der neue Arbeitsbereich leer ist, bringt Git Sync die Inhalte aus dem Repository in den Arbeitsbereich.

4. Erstelle alle Publisher und Konsumenten, die das Schema-Set verwenden, und folge den Anweisungen für diese Item-Typen.

5. Stellen Sie sicher, dass Publisher für die wiederhergestellten Ereignistypen veröffentlichen können und dass Konsumenten die Ereignisse wie erwartet erhalten.

Die synchronisierte Definition umfasst die Ereignistypen im Schema-Set, die Schemata und die Schema-Versionen. Sie enthält keine Publisher-Registrierungen, Verbraucherabonnements oder Ereignisverlauf. Stellen Sie diese separat wieder her, gemäß den Anweisungen für die Elementtypen, die den Schemasatz verwenden.

Alternative: manuell neu erstellen

Wenn du die Git-Integration vor der Katastrophe nicht konfiguriert hast, erstelle das Ereignisschema-Set in der Wiederherstellungsregion neu an, indem du die Ereignis-Schema-Sets erstelle und verwalte, und füge dann die Ereignistypen und Schemata hinzu, die das ursprüngliche Schema-Set enthielt, indem du die Ereignisse-Schemas in Schema-Sets erstellen und verwalten.

Map

Kartenelemente aus der primären Region bleiben für Kunden nicht verfügbar, und die Kartenelemente werden nicht in die sekundäre Region repliziert.

Wenn Sie ein Kartenelement wiederherstellen möchten, wenn ein Notfall auftritt, richten Sie Fabric Git-Integration und synchronisieren Ihr Kartenelement mit Ihrem Git-Repository ein.

Während der Wiederherstellung können Sie, nachdem die neue Region/Kapazität in Fabric eingerichtet wurde, das Repo verwenden, um das Map-Element im neuen Arbeitsbereich, den Sie erstellt haben, neu zu erstellen. Da der neue Arbeitsbereich leer ist, ruft Git sync den Inhalt aus dem Repository in den leeren Arbeitsbereich ab. In diesem Schritt wird das Kartenelement wieder zum Leben erweckt.

Ontologie

Ontologiebenutzer müssen proaktive Schritte ausführen, um sich auf die regionale Notfallwiederherstellung vorzubereiten. Der unten beschriebene Ansatz stellt sicher, dass Ihre Ontology nach einer regionalen Katastrophe wiederherstellbar bleibt und schnell wiederhergestellt werden kann.

Die einfachste und schnellste Möglichkeit zum Aktivieren der Wiederherstellung besteht darin, Fabric Git-Integration zu verwenden und Ihre Ontology mit einem Azure DevOps -Repository (ADO) zu synchronisieren. Wenn der Dienst in eine andere Region übergeht, können Sie dieses Repository verwenden, um die Ontologie in einem neu erstellten Arbeitsbereich wiederherzustellen.

Ontology-Elemente in der primären Region sind nach einem regionalen Notfall nicht für Kunden verfügbar, und Ontology-Elemente werden nicht in die sekundäre Region repliziert.

Um ein Ontology-Element während eines Notfalls wiederherzustellen, konfigurieren Sie Fabric Git-Integration und synchronisieren das Ontology-Element vorab mit Ihrem ADO-Repository.

Während der Wiederherstellung, sobald die neue Region und Kapazität in Fabric eingerichtet sind, können Sie das Repository verwenden, um das Ontologie-Element in einem neuen Arbeitsbereich wiederherzustellen. Da der neue Arbeitsbereich leer ist, ruft Git sync den Inhalt aus dem Repository in den Arbeitsbereich ab und stellt das Ontology-Element effektiv wieder her.

Ontologie-Agent (Ontology Agent)

Nutzer des Ontology Agents müssen proaktive Schritte unternehmen, um sich auf regionale Disaster-Recovery-Maßnahmen vorzubereiten. Der in diesem Abschnitt beschriebene Ansatz stellt sicher, dass nach einer regionalen Katastrophe Ihre Nutzung von Ontology Agent in einem neu erstellten Arbeitsbereich wiederhergestellt werden kann.

Ontology Agent hängt vom Ontologie-Element und von allen Datenquellen ab, die mit der Ontologie verbunden sind, wie z. B. Lakehouses. Kunden können nach einer regionalen Katastrophe nicht auf Ontology Agent-Sitzungen in der primären Region zugreifen, und Ontology Agent-Sitzungen werden nicht auf die sekundäre Region übertragen. Aktive Chatsitzungen, laufende Aktionen und der Gesprächsverlauf aus der betroffenen Region können nicht wieder aufgenommen werden.

Um die Ontology-Agent-Erfahrung während einer Katastrophe wiederherzustellen, konfigurieren Sie die Fabric Git-Integration und synchronisieren Sie das Ontology-Element im Voraus mit Ihrem Azure DevOps (ADO)-Repository.

Während der Wiederherstellung, sobald die neue Region und Kapazität in Fabric eingerichtet sind, führen Sie folgende Schritte durch:

1. Erstelle einen neuen Arbeitsbereich in der neuen Kapazität.
2. Verbinden Sie den neuen Arbeitsbereich mit demselben ADO-Repository, das auch das Ontologie-Element enthält.
3. Verwenden Sie Git Sync, um das Ontology-Element im neuen Arbeitsbereich wiederherzustellen.
4. Stellen Sie alle abhängigen Datenelemente wie Lakehouses wieder her, indem Sie den Anweisungen für diese Elementtypen folgen.
5. Bestätigen Sie, dass die wiedergewonnenen Daten in der gepaarten Region verfügbar sind. Für OneLake-gestützte Daten sollte man davon ausgehen, dass die Daten in die gepaarte Region repliziert werden, aber nicht von der Reihenfolge der replizierten Daten während der Wiederherstellung ausgehen.
6. Verbinden Sie das neu wiederhergestellte Ontologie-Element mit den wiederhergestellten Datenquellen.
7. Starten Sie eine neue Ontology Agent-Sitzung und überprüfen Sie, ob der Agent sich mit dem wiederhergestellten Ontology-Element und den Datenquellen verbinden kann.

Planning

Dieser Artikel beschreibt die Wiederherstellungsverfahren für die Planungsfunktion in IQ. Er beschreibt die notwendigen Schritte zur Wiederherstellung wichtiger Komponenten, darunter Planungsblätter, PowerTable-Blätter, Intelligenzblätter, InfoBridge und zugehörige Datenressourcen.

Git-Integration zum Wiederherstellen von Planelementen

Der bevorzugte Ansatz besteht darin, alle Planelemente mit einem Azure DevOps (ADO) oder GitHub Repository mithilfe Fabric Git-Integration zu synchronisieren. Verwenden Sie nach einem Failover das Repository, um die Elemente im neuen Arbeitsbereich wiederherzustellen.

Prädisaster (proaktive Schritte):

1. Wechseln Sie im Arbeitsbereich W1 zu "Arbeitsbereichseinstellungen" , und konfigurieren Sie die Git-Integration.

2. Wählen Sie "Verbinden" und "Synchronisieren" mit Ihrem ADO- oder GitHub-Repository aus.

3. Wählen Sie die Planelemente aus, die in das Repository hochgeladen werden sollen, und wählen Sie "Commit ausführen" aus.

   

4. Vergewissern Sie sich, dass der Git-Status von Planelementen synchronisiert ist.

5. Führen Sie eine Commit-Disziplin ein – erstellen Sie nach jeder wesentlichen Änderung an einer Plandefinition einen Commit, damit das Repository immer den neuesten Stand widerspiegelt.

Schritte zur Wiederherstellung:

1. Erstellen Sie einen neuen Arbeitsbereich W2 innerhalb der Kapazität C2 in der fehlerfreien Region.

2. Wechseln Sie im Arbeitsbereich W2 zu "Arbeitsbereichseinstellungen", und stellen Sie die Verbindung mit demselben ADO/GitHub Repository wieder her.

3. Wählen Sie "Quellcodeverwaltung" aus. Wählen Sie den relevanten Repositoryzweig und dann "Alle aktualisieren" aus. Alle Planelemente werden in W2 heruntergeladen.

Die folgenden Komponenten werden nach der Wiederherstellung wiederhergestellt:

• PowerTable-Blätter: Quelltabelleneinstellungen, Spaltenkonfiguration, Zeilenzugriff, visuelle Eigenschaften (Layout, Formate und mehr), Zeilenidentifikation, Kommentareinstellungen, langsam ändernde Dimensionen (SCD), Genehmigungen, Automatisierungen und Formulare.
• Planungsblätter: Blatteigenschaften (Formatierung, bedingte Formatierung und mehr), Kommentareinstellungen, Rückschreibeinstellungen, Dateneingabespalten, Dateneingabezeilen, Szenarien und Lesezeichen.
• InfoBridge: InfoBridge-Quellen, InfoBridge-Abfragen, Transformationsschritte, Rückschreibziele, Rückschreibeinstellungen, verknüpfte Abfragezuordnungen, Abfragegruppen, visuelle Eigenschaften (Blend). Diese Elemente können nicht wiederhergestellt werden: dateibasierte Quellen (CSV, Excel), Arbeitsauslastungsübergreifende Blätter, die dateibasierte Quellen verwenden.
• Intelligenz: Alle Diagramme und Matrizen.

Fabric SQL-Wiederherstellung zur Planung

In Planungsblättern eingegebene Daten, tabellen, die in PowerTable verwendet werden, und Rückschreibdaten werden in SQL-Datenbanken gespeichert und müssen als Teil Ihrer Notfallwiederherstellungsstrategie betrachtet werden. Informationen zum Wiederherstellen von SQL-Datenbanken finden Sie im Abschnitt zur SQL-Datenbank .

• Wiederherstellungsplanmetadaten: Jedes Planelement ist einer __fabric_plan_sys Datenbank zugeordnet, in der Metadaten für Planungsfeatures gespeichert werden, einschließlich Kommentare, Szenarien, Dateneingaben und Rückschreibkonfiguration. Die __fabric_plan_sys Datenbank wird nicht automatisch wiederhergestellt und muss explizit wiederhergestellt werden.

• Wiederherstellen von Rückschreibdatenbanken: Wenn Ihr Plan SQL-Zurückschreibziele verwendet, müssen Sie die zugehörigen Datenbanken auch manuell wiederherstellen. Konfigurierte SQL-Zurückschreibziele werden nicht automatisch wiederhergestellt.

• In PowerTable verwendete Tabellen wiederherstellen: Alle mit PowerTable erstellten Tabellen werden in einer SQL-Datenbank in Fabric gespeichert. Sie müssen diese Tabellen auch im Rahmen der DR-Wiederherstellung wiederherstellen.

Operationsagenten

Operations-Agent-Benutzer sollten proaktive Schritte ausführen, um sich auf die regionale Notfallwiederherstellung vorzubereiten. Wenn Sie den in diesem Abschnitt beschriebenen Ansatz befolgen, können Sie sicherstellen, dass Ihre Agents nach einem regionalen Ausfall schnell wiederhergestellt werden können.

Verwenden Sie Fabric Git-Integration, um Ihren Arbeitsbereich mit einem Repository zu synchronisieren. Mit diesem Ansatz können Sie Agentkonfigurationen in einem neuen Arbeitsbereich wiederherstellen, wenn der Dienst ein Failover in eine andere Region durchführt.

Operations Agent-Elemente in der primären Region sind während eines regionalen Notfalls nicht verfügbar. Agentkonfigurationen, Verhaltensmodelle und Aktivitätsprotokolle werden nicht in die sekundäre Region repliziert. Laufende Vorgänge, aktive Chatsitzungen und zuvor aufgenommene Ereignisse zum Zeitpunkt der Katastrophe gehen ebenfalls verloren.

Um sich auf die Wiederherstellung vorzubereiten, konfigurieren Sie Fabric Git-Integration, und synchronisieren Sie Ihre Agentelemente mit Ihrem ADO-Repository, bevor ein Notfall auftritt.

Richten Sie beim Wiederherstellen Ihre neue Region und Kapazität in Fabric ein, und verwenden Sie dann das synchronisierte Repository, um Agentkonfigurationen in einem neuen Arbeitsbereich wiederherzustellen. Git-Synchronisierung ruft die gespeicherten Inhalte aus dem Repository in den leeren Arbeitsbereich ab und erstellt Ihre Agent-Elemente neu.

Nachdem Konfigurationen wiederhergestellt wurden, vergewissern Sie sich, dass auf alle referenzierten Eventhouse-Datenbanken (KQL)-Datenbanken oder regionsspezifischen Datenquellen in der neuen Region zugegriffen werden kann. Aktualisieren Sie Endpunktverweise in Agentkonfigurationen nach Bedarf. Starten Sie schließlich Ihre Agents neu, und lassen Benutzer neue Chatsitzungen initiieren. Frühere Unterhaltungen können nicht fortgesetzt werden.

Databases

Dieser Leitfaden beschreibt die Wiederherstellungsverfahren für den Bereich Datenbanken.

SQL database

Um vor einem regionalen Fehler zu schützen, können Benutzer von SQL-Datenbanken proaktive Maßnahmen ergreifen, um ihre Daten regelmäßig zu exportieren und die exportierten Daten zu verwenden, um die Datenbank bei Bedarf in einem neuen Arbeitsbereich neu zu erstellen.

Nutzen Sie das CLI-Tool SqlPackage , das Datenbankportabilität bietet und die Datenbankbereitstellung erleichtert.

1. Verwenden Sie das SqlPackage-Tool, um die Datenbank in eine .bacpac Datei zu exportieren. Weitere Informationen finden Sie unter Exportieren einer Datenbank mit SqlPackage .
2. Speichere die .bacpac Datei an einem sicheren Ort, der sich in einer anderen Region als die Datenbank befindet. Beispiele sind, die .bacpac Datei in einem Lakehouse in einer anderen Region zu speichern, ein georedundantes Azure Storage-Konto zu verwenden oder ein anderes sicheres Speichermedium in einer anderen Region zu verwenden.
3. Wenn die SQL-Datenbank und -Region nicht verfügbar sind, können Sie die .bacpac Datei mit SqlPackage verwenden, um die Datenbank in einem Arbeitsbereich in einem neuen Bereich – Arbeitsbereich C2 – neu zu erstellen. W2 in Region B wie im obigen Szenario beschrieben. Führen Sie die in " Importieren einer Datenbank mit SqlPackage " beschriebenen Schritte aus, um die Datenbank mit Ihrer .bacpac Datei neu zu erstellen.

Die neu erstellte Datenbank ist eine unabhängige Datenbank aus der ursprünglichen Datenbank und gibt den Status der Daten zum Zeitpunkt des Exportvorgangs wieder.

Failback-Überlegungen

Die neu erstellte Datenbank ist eine unabhängige Datenbank. Daten, die der neu erstellten Datenbank hinzugefügt werden, würden in der ursprünglichen Datenbank nicht widergespiegelt. Wenn Sie planen, bei Verfügbarkeit der Heimatregion auf die Originaldatenbank zurückzufallen, sollten Sie in Erwägung ziehen, die Daten aus der neu erstellten Datenbank manuell mit der ursprünglichen Datenbank abzugleichen.

Plattform

Plattform bezieht sich auf die zugrunde liegenden gemeinsamen Dienste und Architekturen, die für alle Workloads gelten. Dieser Abschnitt beschreibt die Wiederherstellungsverfahren für gemeinsame Fabric-Fähigkeiten.

Arbeitsbereichüberwachung

Workspace Monitoring sammelt Protokolle über Aktivitäten im Workspace, in dem du es aktiviert hast. Nachdem du deinen Arbeitsbereich als C2 wiederhergestellt hast. W2, aktiviere die Arbeitsbereichsüberwachung auf W2. Es beginnt, Überwachungsdaten für den wiederhergestellten Arbeitsbereich zu sammeln.

Überwachungsdaten aus dem ursprünglichen Arbeitsbereich (C1.W1) werden nicht übernommen, da die Überwachung die Aktivität des Arbeitsbereichs widerspiegelt, in dem sie ausgeführt wird.

Variable Library

Microsoft Fabric Variablenbibliotheken ermöglichen Entwicklern das Anpassen und Freigeben von Elementkonfigurationen innerhalb eines Arbeitsbereichs und optimieren die Verwaltung des Inhaltslebenszyklus. Aus Sicht der Notfallwiederherstellung müssen Benutzer von Variablenbibliotheken proaktiv vor einer regionalen Katastrophe schützen. Dieser Schutz kann durch die Integration von Fabric Git erfolgen, die sicherstellt, dass nach einer regionalen Katastrophe die Variable-Bibliothek eines Benutzers weiterhin verfügbar bleibt. Um eine variable Bibliothek wiederherzustellen, folgen Sie diesen Schritten:

• Verwenden Sie Fabric Git-Integration, um Ihre Variable-Bibliothek mit Ihrem ADO-Repository zu synchronisieren. Im Falle eines Notfalls können Sie das Repository verwenden, um die Variable-Bibliothek im neuen Arbeitsbereich neu zu erstellen, den Sie erstellt haben. Führen Sie die folgenden Schritte aus:

  1. Verbinden Sie Ihren Arbeitsbereich mit Git-Repository, wie hier beschrieben.
  2. Stellen Sie sicher, dass die WS und das Repository mit Commit und Update synchronisiert werden.
  3. Wiederherstellung – Verwenden Sie im Notfall das Repository, um die Variable-Bibliothek in einem neuen Arbeitsbereich neu zu erstellen:

• Stellen Sie im neu erstellten Arbeitsbereich erneut eine Verbindung mit Ihrem Azure ADO-Repository her.

• Alle Fabric Elemente in diesem Repository werden automatisch in Ihren neuen Arbeitsbereich heruntergeladen.

• Nachdem Sie Ihre Elemente aus Git synchronisiert haben, öffnen Sie Ihre Variablenbibliotheken im neuen Arbeitsbereich, und wählen Sie den gewünschten aktiven Wertsatz manuell aus.

Bereitstellungsplan

Ein Einsatzplan ist ein Element in einem Fabric-Arbeitsbereich. Es gruppiert Gegenstände und legt die Reihenfolge fest, in der sie eingesetzt werden. Es kann vor oder nach der Bereitstellung jedes Elements Aktionen ausführen. Die Item-Definition speichert diese Einstellungen, Eingaben und Item-Referenzen. Der Plan hat keinen separaten Speicher für Werte, die zur Laufzeit verwendet werden.

Bereiten Sie sich auf die Wiederherstellung vor, indem Sie die Fabric Git-Integration verwenden:

1. Verbinden Sie den Arbeitsbereich, der den Plan enthält, mit einem Azure DevOps- oder GitHub-Repository.
2. Bereite den Plan und alle verwendeten Arbeitsbereichselemente ein.
3. Committe jede Änderung, damit Git über die neuesten Definitionen verfügt.

Nach einer regionalen Katastrophe:

1. Schaffen Sie einen Arbeitsplatz in der gesunden Region.
2. Verbinde den Arbeitsbereich mit demselben Repository und demselben Branch.
3. Aktualisiere den Arbeitsbereich von Git aus. Dieser Schritt stellt den Plan und seine Gegenstände wieder her.

Git stellt die vollständige Plandefinition wieder her. Es stellt keine Daten wieder her und führt keinen Laufstatus für die verknüpften Items aus. Verwenden Sie die Abschnitte in diesem Artikel, um diese Gegenstände wiederherzustellen.

Vom Kunden verwaltete Schlüssel für Fabric Arbeitsbereiche

Sie können kundenverwaltete Schlüssel (CMK) verwenden, die in Azure Key Vault gespeichert sind, um eine zusätzliche Verschlüsselungsschicht über Microsoft-verwaltete Schlüssel für ruhende Daten hinzuzufügen. Wenn Fabric in einer Region unzugänglich oder nicht mehr funktionsfähig wird, werden seine Komponenten zu einer Backup-Instanz überführt. Während des Failovers unterstützt das CMK-Feature schreibgeschützte Vorgänge. Solange der Azure Key Vault-Dienst ordnungsgemäß funktioniert und die Berechtigungen für den Schlüsseltresor intakt sind, kann Fabric weiterhin auf Ihren Schlüssel zugreifen, und Sie können Daten normal lesen. Dies bedeutet, dass die folgenden Vorgänge während des Failovers nicht unterstützt werden: Aktivieren und Deaktivieren der CMK-Einstellung des Arbeitsbereichs und Aktualisieren des Schlüssels.

Fabric Migration Assistant für SQL-Datenbanken in Fabric

Der Fabric Migration Assistant kann eine SQL Server-Datenbank in drei Phasen in eine SQL-Datenbank in Fabric übertragen: Der Migrations-Assistent erstellt die Zieldatenbank und startet die Migration, der Migrationsmonitor verfolgt den Fortschritt, während das Schema aus einem DACPAC bereitgestellt wird, und der Migrations-Assistent hilft Ihnen dabei, Skriptfehler zu überprüfen und zu beheben, die Datenbank vorzubereiten, Daten mithilfe eines Kopierauftrags zu kopieren und die Kopie abzuschließen.

Der Migrationsfortschritt wird nicht in eine andere Region repliziert, und eine unterbrochene Bereitstellung kann nicht fortgesetzt werden. Diese Fehler beeinträchtigen nicht die Quelldatenbank des SQL Server, sodass du den Migrationsassistenten erneut ausführen kannst. Wenn die ursprüngliche Region nicht verfügbar ist, folgen Sie zunächst dem allgemeinen Wiederherstellungsplan in diesem Artikel, um die Kapazität C2 und Arbeitsbereich W2 in der gepaarten Region zu erstellen, und führen Sie dann die Migration in W2 durch. Wenn die ursprüngliche Region sich wiederherstellt, kannst du die Migration im ursprünglichen Arbeitsbereich erneut versuchen.

Eine regionale Störung kann dazu führen, dass eine Migration auf drei Arten scheitert:

• Die Zieldatenbank wird nicht erstellt

  Wenn Fabric die Zieldatenbank nicht erstellen kann, zeigt der Migrationsassistent einen Fehler an und die Migration startet nicht. Wähle Start Migration , um es erneut zu versuchen, oder versuche es später erneut.

  Der Zauberer versucht, eine unvollständige Datenbank zu entfernen, aber die Bereinigung kann während einer Störung scheitern. Bevor du es erneut versuchst, überprüfe den Arbeitsbereich auf eine Datenbank mit dem Zielnamen. Bestätige, dass es die unvollständige Datenbank des fehlgeschlagenen Versuchs ist, bevor du sie löschst.

• Der Einsatz fehlschlägt

  Wenn die Bereitstellung unterbrochen wird, stellt der Migrationsmonitor die Meldung des Fortschritts ein, öffnet die Zieldatenbank und zeigt ein Dialog, das die Bereitstellung als fehlgeschlagen anzeigt. Du kannst eine fehlgeschlagene Bereitstellung nicht fortsetzen, und die durch den Versuch erstellte Datenbank bleibt im Arbeitsbereich.

  Zum Wiederherstellen:

  1. Bestätigen Sie, dass Fabric verfügbar ist und dass Sie den DACPAC für die ursprüngliche Migration verwendet haben.
  2. Identifizieren Sie die Datenbank, die durch den gescheiterten Versuch erstellt wurde. Lösche es, wenn es nichts enthält, was du behalten musst. Ansonsten behalten Sie es und verwenden Sie einen anderen Namen für die neue Datenbank.
  3. Führe eine neue Migration vom Quell-DACPC aus. Die Migration erstellt eine neue Datenbank.

  Daten werden durch einen Kopierauftrag in Data Factory kopiert. Wenn du den Kopierauftrag vor der Unterbrechung mit Git synchronisiert hast, siehe Kopierauftrag in der Data Factory-Anleitung. Ansonsten erstelle einen neuen Kopierjob im Rahmen der neuen Migration.

• Migrationshistorie lädt nicht

  Wenn der Migration Assistant die Migrationshistorie nicht abrufen kann, meldet er, dass Migrationsinformationen nicht mehr verfügbar sind. Der im aktuellen Browser gespeicherte Fortschritt bleibt erhalten und die Zieldatenbank ist nicht betroffen. Aktualisieren Sie die Seite, um den Migrationsverlauf erneut zu laden.

OneLake

Dieser Abschnitt führt Sie durch die Wiederherstellungsprozeduren für OneLake-Features. Weitere Informationen zur Notfallwiederherstellung für OneLake-Daten finden Sie unter OneLake-Notfallwiederherstellung.

Richtlinien für die Lebenszyklusverwaltung

Wenn Fabric in einer Region unzugänglich oder nicht mehr funktionsfähig wird, können Sie Ihre OneLake-Lebenszyklusrichtlinie während des Failover weiterhin lesen und aktualisieren. Alle Daten, die in die kühle oder kalte Ebene verschoben wurden, verbleiben dort. Um Ihre bestehende Richtlinie auf Ihren neuen Wiederherstellungsbereich anzuwenden, folgen Sie diesen Schritten:

1. Rufen Sie die Exportrichtlinie für Ihren ursprünglichen Arbeitsbereich auf, und speichern Sie die gesamte Lebenszyklusrichtlinie.
2. Rufen Sie Import Policy für Ihren wiederhergestellten Arbeitsbereich auf, wobei Ihre exportierte Lebenszyklusrichtlinie den Anforderungstext bildet.

Ressourceninstanzregeln

Mithilfe von Ressourceninstanzregeln können Sie den Zugriff auf Daten in OneLake mithilfe vertrauenswürdiger Azure Ressourcenidentitäten sicher steuern. Während des regionalen Failovers erzwingt das System weiterhin vorhandene Regeln für den Lesezugriff. Sie können jedoch keine Ressourceninstanzregeln erstellen, aktualisieren oder löschen, bis der Arbeitsbereich in einen schreibbaren Zustand zurückkehrt.

Verwandte Informationen

• Microsoft Fabric Notfallwiederherstellungshandbuch