Freigeben über

Umgebungsspezifischer Leitfaden für die Notfallwiederherstellung

  • Artikel

Dieses Dokument enthält einen umgebungsspezifischen Leitfaden für die Wiederherstellung Ihrer Fabric-Daten im Falle eines regionalen Notfalls.

Beispielszenario

In mehreren Abschnitten dieses Dokuments wird zur Erläuterung und Veranschaulichung das folgende Beispielszenario verwendet. Hier können Sie bei Bedarf noch einmal Informationen zu diesem Szenario nachlesen.

Angenommen, in der Region A mit dem Arbeitsbereich W1 gibt es die Kapazität C1. Wenn Sie für die Kapazität C1 die Notfallwiederherstellung aktiviert haben, werden OneLake-Daten in einer Sicherung in der Region B repliziert. Im Falle von Unterbrechungen in der Region A wird für den Fabric-Dienst in C1 ein Failover auf die Region B ausgeführt.

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.

Diagramm, das ein Szenario für Notfall, Failover und vollständige Wiederherstellung zeigt.

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. Kopieren Sie Daten aus der unterbrochenen Kapazität bzw. aus dem unterbrochenen Arbeitsbereich (C1.W1) in C2.W2.

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

Umgebungsspezifische Wiederherstellungspläne

In den folgenden Abschnitten finden Sie schrittweise Anleitungen für jede Fabric-Umgebung, um Kunden bei der Wiederherstellung zu unterstützen.

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. Für die Wiederherstellung von Lakehouses gibt es zwei empfohlene Ansätze:

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 in den Daten mit OneLake-Pfaden wie z. B. Abfss (siehe Herstellen einer Verbindung mit Microsoft OneLake). Sie können im Notebook das folgende Codebeispiel verwenden (siehe Einführung in Microsoft Spark-Hilfsprogramme), um die ABFS-Pfade von Dateien und Tabellen aus dem ursprünglichen Lakehouse abzurufen. (Ersetzen Sie C1.W1 durch den tatsächlichen Arbeitsbereichsnamen.)

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

mssparkutils.fs.cp(source, destination, true)

val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
    .filter{sf => sf.isFile && sf.modifyTime > timestamp}

for(fileToDelte <- filesToDelete) {
    val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
    println(s"Deleting file $destFileToDelete")
    mssparkutils.fs.rm(destFileToDelete, false)
}

mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)

  5. Nach Ausführung des Skripts sind die Tabellen im neuen Lakehouse vorhanden.

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

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

Hinweis

Mit den beiden oben beschriebenen Ansätzen werden sowohl die Metadaten als auch die Daten für Tabellen im Delta-Format wiederhergestellt, da sich die Metadaten am gleichen Ort befinden und zusammen mit den Daten in OneLake gespeichert werden. Bei Tabellen, die nicht im Delta-Format vorliegen (z. B. CSV, Parquet usw.) und mithilfe von Spark-DDL-Skripts (Data Definition Language, Datenbeschreibungssprache) erstellt wurden, ist der Benutzer bzw. die Benutzerin dafür verantwortlich, die Spark-DDL-Skripts/Befehle für die Wiederherstellung zu verwalten und erneut auszuführen.

Notebook

Notebooks aus der primären Region können für Kunden nicht wieder verfügbar gemacht werden, und der Code in Notebooks wird nicht in der sekundären 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)

Am schnellsten und einfachsten ist es, die Git-Integration von Fabric zu verwenden und Ihr Notebook anschließend 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. Richten Sie die Git-Integration ein, und wählen Sie Verbinden und synchronisieren mit dem ADO-Repository aus.

    Screenshot, der zeigt, wie Sie Ihr Notebook mit ADO-Repository verbinden und synchronisieren.

    Die folgende Abbildung zeigt das synchronisierte Notebook.

    Screenshot des Notebooks, das mit dem ADO-Repository synchronisiert wurde.

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

    1. Stellen Sie in dem neu erstellten Arbeitsbereich wieder eine Verbindung mit Ihrem Azure ADO-Repository her.

      Screenshot, der zeigt, dass das Notebook erneut mit dem ADO-Repository verbunden ist.

    2. Wählen Sie die Schaltfläche Quellcodeverwaltung aus. Wählen Sie dann den relevanten Branch des Repositorys aus. Wählen Sie Alle aktualisieren aus. Das ursprüngliche Notebook wird angezeigt.

      Screenshot, der zeigt, wie alle Notebooks in einer Branch aktualisiert werden.

      Screenshot mit neu erstellter originaler Notiz.

    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.

      Screenshot, der zeigt, wie ein wiederhergestelltes Lakehouse mit einem wiederhergestellten Notizbuch verbunden wird.

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

        Screenshot, der zeigt, wie Notebook zum Speichern von Schnappschüssen ausgeführt wird.

        Screenshot, der zeigt, wie man Schnappschüsse von Notebooks speichert.

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.

    Screenshot, der zeigt, wie man Notebook-Code importiert.

  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, lesen Sie 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. Beachten Sie, dass frühere Ausführungen der SJD nicht wiederhergestellt werden.

Sie können die SJD-Elemente wiederherstellen, indem Sie den Code mithilfe von Azure Storage-Explorer aus der ursprünglichen Region kopieren und die Verbindung von Lakehouse-Verweisen nach dem Notfall manuell wiederherstellen.

  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.

    Screenshot, der zeigt, wie die ursprüngliche Spark-Job-Definition in die neue Spark-Job-Definition kopiert wird.

  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.

    Screenshot, der Befehlszeilenargumente zum Wiederherstellen der Sparkauftragsdefinition zeigt.

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

Ausführliche Informationen zu Azure Storage-Explorer finden Sie unter Integrieren von OneLake in 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-Umgebung. Hier werden Warehouses behandelt.

Warehouse

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 Warehouse auf. Verwenden Sie dazu den Warehouse-Explorer und die T-SQL-Funktionen. (Weitere Informationen finden Sie unter Tabellen in Data Warehousing in Microsoft Fabric.)

Hinweis

Es wird empfohlen, den Warehouse-Code (Schema, Tabelle, Ansicht, gespeicherte Prozedur, Funktionsdefinitionen und Sicherheitscodes) gemäß Ihren Entwicklungspraktiken zu versionieren und an einem sicheren Ort (z. B. Git) zu speichern.

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 vorübergehenden Lakehouse wieder her, wie in den Schritten für die Lakehouse-Wiederherstellung beschrieben.

  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 Warehouse-Tabellen aus Lakehouses wiederherzustellen. 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 abschließend die Verbindungszeichenfolge in Anwendungen, die Ihr Fabric-Warehouse verwenden.

Hinweis

Kunden, die regionale Notfallwiederherstellung und vollautomatisierte Geschäftskontinuität benötigen, empfehlen wir, zwei Fabric-Warehouses in separaten Fabric-Regionen einzurichten und die Code- und Datenparität durch regelmäßige Bereitstellungen und Datenerfassungen an beiden Orten zu wahren.

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 können für Kunden nicht wieder verfügbar gemacht werden, und die Einstellungen und die Konfiguration in Datenpipelines oder in Dataflow Gen2-Elementen werden nicht in der sekundären 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 über Ihr Dataflow Gen2-Element auf der Registerkarte „Start“ des Power Query-Editors die Option Vorlage exportieren aus.

    Screenshot: Power Query-Editor mit hervorgehobener Option „Vorlage exportieren“.

  2. Geben Sie im Dialogfeld „Vorlage exportieren“ einen Namen (obligatorisch) und eine Beschreibung (optional) für diese Vorlage ein. Wählen Sie dann OK.

    Screenshot, der zeigt, wie man eine Vorlage exportiert.

  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 die Option Aus Power Query-Vorlage importieren aus.

    Screenshot: Aktuelle Ansicht mit hervorgehobener Option „Aus Power Query-Vorlage importieren“.

  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.

Datenpipelines

Kunden können im Falle eines regionalen Notfalls nicht auf Datenpipelines zugreifen, und die Konfigurationen werden nicht in der gekoppelten Region repliziert. Es wird empfohlen, Ihre kritischen Datenpipelines in mehreren Arbeitsbereichen in verschiedenen Regionen zu erstellen.

Real-Time Intelligence

Dieser Leitfaden führt Sie durch die Wiederherstellungsprozesse für die Real-Time Business Intelligence-Erfahrung. Hier werden KQL-Datenbanken/-Abfragesets und Eventstreams behandelt.

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 mindestens zwei unabhängige KQL-Datenbanken/-Abfragesets für dedizierte Fabric-Kapazitäten. Diese müssen in zwei verschiedenen Azure-Regionen (vorzugsweise in Azure-Regionspaaren) 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 korrekt 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.

Eventstream

Ein Eventstream ist ein zentraler Ort der Fabric-Plattform zum Erfassen, Transformieren und Weiterleiten von Echtzeitereignissen an verschiedene Ziele (z. B. Lakehouses, KQL-Datenbanken/-Abfragesets) ohne Programmieraufwand. 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 im Rahmen einer Aktiv-Aktiv-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