Erfahrungsspezifischer Leitfaden für die Notfallwiederherstellung

Dieses Dokument enthält erfahrungsspezifische Anleitungen zum Wiederherstellen Ihrer Fabric Daten im Falle einer regionalen Katastrophe.

Beispielszenario

Viele Anleitungsabschnitte in diesem Dokument verwenden das folgende Beispielszenario für Erläuterungen und Illustrationen. 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 Mandanten-Heimregion einen Ausfall aufweist, sind die in diesem Dokument beschriebenen Schritte von der Wiederherstellung abhängig, die zuerst von Microsoft initiiert und abgeschlossen werden muss.

Erfahrungsspezifische Wiederherstellungspläne

In den folgenden Abschnitten finden Sie schrittweise Anleitungen für jede Fabric Erfahrung, die Kunden beim Wiederherstellungsvorgang unterstützt.

Datentechnik

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Datentechnikumgebung. Hier werden Lakehouses, Notebooks und Spark-Auftragsdefinitionen behandelt.

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 Arbeitsbereichsnamen.)

   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

Materialisierte Lake Views aus der ursprünglichen Region bleiben nach dem Failover für Kunden nicht verfügbar. Aktualisierungszeitpläne und Ausführungsverlauf werden nicht in die sekundäre Region repliziert. Um sie wiederherzustellen, führen Sie die folgenden Schritte aus, nachdem Sie Ihre Lakehouse-Daten wiederhergestellt haben.

• Stellen Sie die Lakehouse-Tabellen mithilfe von Approach 1 oder Approach 2 wieder her, wie oben beschrieben. Kopieren Sie nur die Quelltabellen.
• Stellen Sie die Notizbücher wieder her, die Ihre MLV-Definitionen enthalten. Anleitung für die Wiederherstellung finden Sie im Bereich Notebook.
• 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 MLVs auch im vorherigen Schritt kopiert wurden, führen Sie CREATE OR REPLACE aus, während Sie sie neu erstellen.
• Erstellen Sie die MLV-Aktualisierungszeitpläne manuell im neuen Arbeitsbereich neu. Zeitplanverlaufs- und Ausführungsmetriken können nicht wiederhergestellt werden.
• 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

Notizbücher aus der primären Region bleiben für Kunden nicht verfügbar, und der Code in Notizbüchern wird nicht in die sekundäre Region repliziert. Für die Wiederherstellung von Notebook-Codeinhalten in der neuen Region gibt es zwei Ansätze.

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

Die beste Möglichkeit, dies einfach und schnell zu machen, besteht darin, Fabric Git-Integration zu verwenden, und dann Ihr Notizbuch mit Ihrem ADO-Repository zu synchronisieren. Nachdem für den Dienst ein Failover auf eine andere Region ausgeführt wurde, können Sie das Notebook mithilfe des Repositorys in dem von Ihnen neu erstellten Arbeitsbereich neu 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 Notebook über ein Standard-Lakehouse verfügt, können Benutzer*innen den Lakehouse-Abschnitt heranziehen, um das Lakehouse wiederherzustellen und das neu wiederhergestellte Lakehouse mit dem neu wiederhergestellten Notebook zu verbinden.

      

   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. Stellen Sie sicher, dass Sie Dateien oder Ordner auf einem lokalen Datenträger oder an einem anderen Ort speichern.

         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 Sie nicht die Git-Integration verwenden möchten, können Sie die neueste Version Ihres Codes sowie die Dateien im Ressourcen-Explorer und die Notebook-Momentaufnahme in einem Versionskontrollsystem wie Git speichern und den Notebook-Inhalt nach einem Notfall manuell wiederherstellen:

1. Verwenden Sie das Feature „Notebook importieren“, um den wiederherzustellenden Notebook-Code zu importieren.

   

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-Auftragsdefinitionen (Spark Job Definitions, SJDs) aus der primären Region können für Kunden nicht wieder verfügbar gemacht werden, und die Hauptdefinitionsdatei und die Referenzdatei im Notebook werden über OneLake in der sekundären Region repliziert. Wenn Sie die SJD in der neuen Region wiederherstellen möchten, können Sie die nachstehend beschriebenen manuellen Schritte ausführen. Historische 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. Erstellen Sie im neuen Arbeitsbereich C2.W2 ein neues SJD-Element (z. B. SJD1) mit den Einstellungen und Konfigurationen des ursprünglichen SJD-Elements (z. B. 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 Codeinhalt wird in der neu erstellten SJD angezeigt. Der neu wiederhergestellte Lakehouse-Verweis muss dem Auftrag manuell hinzugefügt werden. (Weitere Informationen finden Sie in den Schritten für die Lakehouse-Wiederherstellung.) Benutzer*innen müssen die ursprünglichen Befehlszeilenargumente 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.

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-Elemente aus der primären Region können für Kunden nicht wieder verfügbar gemacht werden, und die Inhalte und Metadaten in ML-Modellen und -Experimenten werden nicht in der sekundären Region repliziert. 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. Die Konfiguration, historische Metriken sowie Metadaten werden nicht in der gekoppelten Region repliziert. Sie müssen jede Version Ihres Data Science-Codes erneut ausführen, um ML-Modelle und -Experimente nach dem Notfall vollständig wiederherzustellen.

Data Warehouse

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Data Warehouse Erfahrung. Hier werden Warehouses behandelt.

Lagerhaus

Warehouses aus der ursprünglichen Region können für Kunden nicht wieder verfügbar gemacht werden. Führen Sie die beiden folgenden Schritte aus, um Warehouses wiederherzustellen.

1. Erstellen Sie im Arbeitsbereich C2.W2 ein neues vorübergehendes Lakehouse für die Daten, die Sie aus dem ursprünglichen Warehouse kopieren.

2. Füllen Sie die Delta-Tabellen des Lagerlagers auf, indem Sie den Lager-Explorer und die T-SQL-Funktionen nutzen (siehe Tables in Data Warehouse in Microsoft Fabric).

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 Sie Tabellendefinitionen vor dem Datenimport bereitstellen, kann der tatsächlich für Importe verwendete T-SQL-Code variieren. Sie können INSERT INTO, SELECT INTO oder CREATE TABLE AS SELECT verwenden, um auf Warehouse-Tabellen aus Lakehouses zuzugreifen. Im weiteren Verlauf des Beispiels wird INSERT INTO verwendet. (Falls Sie den folgenden Code verwenden möchten, ersetzen Sie die 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 schließlich die Verbindungszeichenfolge in Anwendungen, die Ihr Fabric Data Warehouse verwenden.

Gespiegelte Datenbanken

Gespiegelte Datenbanken aus der primären Region bleiben für Kunden nicht verfügbar, und die Einstellungen werden nicht in die sekundäre Region repliziert. Um sie im Falle eines regionalen Fehlers wiederherzustellen, müssen Sie die gespiegelte Datenbank in einem anderen Arbeitsbereich aus einer anderen Region neu erstellen.

Data Factory

Data Factory-Elemente aus der primären Region bleiben für Kunden nicht verfügbar, und die Einstellungen und Konfiguration in Pipelines oder Dataflow gen2-Elementen werden nicht in die sekundäre Region repliziert. Um diese Elemente im Falle eines regionalen Ausfalls wiederherzustellen, müssen Sie Ihre Datenintegrationselemente in einem anderen Arbeitsbereich aus einer anderen Region neu erstellen. Die folgenden Abschnitte enthalten ausführlichere Informationen.

Dataflows Gen2

Wenn Sie ein Dataflow Gen2-Element in der neuen Region wiederherstellen möchten, müssen Sie eine PQT-Datei in ein Versionskontrollsystem wie Git exportieren und dann den Dataflow Gen2-Inhalt nach dem Notfall manuell wiederherstellen.

1. Wählen Sie von Ihrem Element für Dataflow Gen2 auf der Registerkarte "Startseite" des Power Query-Editors die Exportvorlage aus.

   

2. Geben Sie im Dialogfeld „Vorlage exportieren“ einen Namen (obligatorisch) und eine Beschreibung (optional) für diese Vorlage 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. Navigieren Sie im Dialogfeld Öffnen zu Ihrem Standardordner für Downloads, und wählen Sie die PQT-Datei aus, die 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 Funktion "Datenflüsse speichern unter" 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. Es wird empfohlen, Ihre kritischen Pipelines in mehreren Arbeitsbereichen in verschiedenen Regionen zu erstellen.

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)

Die beste Möglichkeit, diesen Prozess einfach und schnell zu machen, besteht darin, Fabric Git-Integration zu verwenden, und dann Ihren CopyJob mit Ihrem ADO-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 für Ihren Arbeitsbereich, und wählen Sie Verbinden und synchronisieren mit dem ADO-Repository aus.

   

   Die folgende Abbildung zeigt den synchronisierten CopyJob.

   

2. Stellen Sie den CopyJob aus dem ADO-Repository wieder her.

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

      

   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

Apache Airflow Job in Fabric Benutzer müssen proaktive Maßnahmen ergreifen, um vor einer regionalen Katastrophe zu schützen.

Es wird empfohlen, Redundanz mit Fabric Git-Integration zu verwalten. Synchronisieren Sie zuerst Ihren Airflow-Auftrag mit Ihrem ADO-Repository. Wenn der Dienst in eine andere Region verschoben wird, können Sie das Repository nutzen, um den Airflow-Auftrag im neuen Arbeitsbereich, den Sie erstellt haben, neu aufzubauen.

Dies sind die folgenden Schritte:

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

2. Danach sehen Sie, dass Ihr Airflow-Auftrag mit Ihrem ADO-Repository synchronisiert wurde.

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 Elemente, 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. Hier werden KQL-Datenbanken/-Abfragesets und Eventstreams behandelt.

Graph-Modell/Queryset

Gegenstände des Graph-Modells und der Graph-Abfrage aus der primären Region bleiben für Kunden weiterhin nicht verfügbar, und diese Gegenstände werden nicht in die sekundäre Region repliziert. Um wiederherzustellen, erstellen oder verwenden Sie eine Kapazität in einer anderen Region; erstellen Sie dort die Elemente "Graph-Modell" und "Graph-Queryset" 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 Diagrammmodellelement im sekundären Arbeitsbereich neu (in Schritt 2 referenziert). Konfigurieren Sie die Modelldefinition neu, einschließlich Knoten, Kanten usw., um dem ursprünglichen Graph-Modell zu entsprechen.

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 Seehaus als OneLake-Datenquelle für das neu erstellte Graph-Modellelement. 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 Datenladezeitpläne oder Verbindungen für das Graph-Modell im neuen Arbeitsbereich neu.

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

KQL-Datenbank/-Abfrageset

Benutzer*innen von KQL-Datenbanken/-Abfragesets müssen proaktive Maßnahmen ergreifen, um sich vor einem regionalen Notfall zu schützen. Mit dem folgenden Ansatz wird sichergestellt, dass Daten in Ihren KQL-Datenbanken/-Abfragesets im Falle eines regionalen Notfalls 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. Einrichten unabhängiger KQL-Datenbanken: Konfigurieren Sie zwei oder mehr unabhängige KQL-Datenbanken/Querysets auf dedizierten Fabric-Kapazitäten. Diese sollten in zwei verschiedenen Azure Regionen (vorzugsweise Azure-gekoppelten Regionen) eingerichtet werden, um die Resilienz zu maximieren.

2. Replizieren von Verwaltungsaktivitäten: Alle Verwaltungsaktionen, die in einer KQL-Datenbank ausgeführt werden, müssen in der anderen Datenbank gespiegelt werden. Dadurch wird sichergestellt, dass beide Datenbanken synchron bleiben. Einige wichtige Aktivitäten, die repliziert werden müssen, sind:

   • Tabellen: Stellen Sie sicher, dass die Tabellenstrukturen und Schemadefinitionen in den Datenbanken konsistent sind.

   • Zuordnung: Duplizieren Sie alle erforderlichen Zuordnungen. Stellen Sie sicher, dass Datenquellen und -ziele richtig ausgerichtet sind.

   • Richtlinien: Stellen Sie sicher, dass beide Datenbanken über ähnliche Richtlinien für Datenaufbewahrung, Zugriff und andere relevante Bereiche verfügen.

3. Verwalten von Authentifizierung und Autorisierung: Richten Sie für jedes Replikat die erforderlichen Berechtigungen ein. Stellen Sie sicher, dass die richtigen Autorisierungsstufen eingerichtet werden, um dem Personal den nötigen Zugriff zu erteilen und Sicherheitsstandards einzuhalten.

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. Wenn die Ziele von der Notfallwiederherstellung unterstützt werden, gehen bei Eventstreams keine Daten verloren. Daher sollten Kunden die Notfallwiederherstellungsfunktionen dieser Zielsysteme verwenden, um die Datenverfügbarkeit zu gewährleisten.

Kunden können auch Georedundanz erreichen, indem identische Eventstream-Workloads in mehreren Azure Regionen als Teil einer aktiv/aktiven Strategie mit mehreren Standorten bereitgestellt werden. Bei einem Aktiv-Aktiv-Ansatz mit mehreren Standorten können Kunden auf ihre Workload in einer beliebigen der bereitgestellten Regionen 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ändige Georedundanz zu erreichen, können Kunden folgende Schritte ausführen:

1. Erstellen von Replikaten ihrer Datenquellen in verschiedenen Regionen

2. Erstellen von Eventstream-Elementen in entsprechenden Regionen

3. Verbinden dieser neuen Elemente mit den identischen Datenquellen

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

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.

Transaktionsdatenbank

In diesem Leitfaden werden die Wiederherstellungsprozeduren für das Erlebnis mit der transaktionalen Datenbank beschrieben.

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.

Dies kann mithilfe des SqlPackage CLI-Tools erreicht werden, das Datenbankübertragbarkeit bereitstellt und Datenbankbereitstellungen 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. Speichern Sie die .bacpac Datei an einem sicheren Speicherort, der sich in einer anderen Region als der Datenbank befindet. Beispiele hierfür sind das Speichern der datei .bacpac in einem Lakehouse, das sich in einer anderen Region befindet, mithilfe eines georedundanten Azure Storage Kontos oder mithilfe eines anderen sicheren Speichermediums, das sich in einer anderen Region befindet.
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, werden nicht in der ursprünglichen Datenbank widergespiegelt. Wenn Sie beabsichtigen, ein Failback zur ursprünglichen Datenbank auszuführen, wenn die Heimregion verfügbar wird, müssen Sie die manuelle Abstimmung von Daten aus der neu erstellten Datenbank mit der ursprünglichen Datenbank in Betracht ziehen.

Plattform

Plattform bezieht sich auf die zugrunde liegenden gemeinsamen Dienste und Architekturen, die für alle Workloads gelten. Dieser Abschnitt führt Sie durch die Wiederherstellungsprozeduren für gemeinsame Erfahrungen. Es behandelt Variablenbibliotheken.

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. Dies kann über Fabric Git-Integration erfolgen, wodurch sichergestellt wird, dass nach einem regionalen Notfall die Variable-Bibliothek eines Benutzers verfügbar bleibt. Zum Wiederherstellen einer Variablenbibliothek empfehlen wir Folgendes:

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

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 zusätzlich zu Microsoft verwalteten Schlüsseln für ruhende Daten eine zusätzliche Verschlüsselungsebene hinzuzufügen. Falls Fabric in einer Region nicht zugänglich oder funktionsunfähig wird, werden seine Komponenten auf eine Sicherungsinstanz umgeschaltet. Während des Failovers unterstützt das CMK-Feature schreibgeschützte Vorgänge. Solange der Azure Key Vault-Dienst fehlerfrei bleibt und die Berechtigungen für den Tresor intakt sind, wird Fabric weiterhin eine Verbindung mit Ihrem Schlüssel herstellen und es Ihnen ermöglichen, Daten normal zu 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.

Verwandte Informationen

• Microsoft Fabric Notfallwiederherstellungshandbuch