Verwaltete Notfallwiederherstellung

Die verwaltete Notfallwiederherstellung (DR) repliziert Ihre Azure Databricks Bereitstellung in eine sekundäre Region, sodass Sie einen regionalen Ausfall in Minuten wiederherstellen können. Azure Databricks verwaltet die Replikationspipeline, den Status der replizierten Kataloge im sekundären und den Failoverprozess. Sie schreiben oder pflegen keine Replikationsskripte.

Informationen zum manuellen Ansatz für die Notfallwiederherstellung, einschließlich allgemeiner DR-Konzepte und bewährter Methoden, finden Sie unter Notfallwiederherstellung.

Was ist die verwaltete Notfallwiederherstellung?

Verwaltetes DR setzt auf den Workspaces und Metastores auf, die Sie bereits betreiben. Sie richten zwei Azure Databricks-Workspaces ein, einen in Ihrer primären Region und einen in Ihrer sekundären Region, sowie einen Metastore in jeder Region. Verwaltete DR damals:

• Repliziert die Kategorien, die Sie von der primären zur sekundären nach einem kontinuierlichen Zeitplan auswählen. Beide Kategorien sind unabhängig voneinander optional: Unity-Katalogmetadaten und verwaltete Tabellendaten sowie Arbeitsbereichsressourcen wie Notizbücher, Aufträge, SQL-Lagerhäuser, Cluster und ACLs.
• Stellt eine optionale stabile URL, eine einzelne Verbindungszeichenfolge bereit, die immer auf die aktuelle primäre Url verweist, sodass Clients nach dem Failover ohne Neukonfiguration weiterarbeiten.
• Ermöglicht es Ihnen, bei Bedarf ein Failover für einen DR-Test oder einen tatsächlichen Ausfall auszulösen.

Arbeitsbereichsressourcen-IDs bleiben regionsübergreifend erhalten, sodass URLs, die per ID auf eine Arbeitsbereichsressource verweisen, nach einem Failover weiterhin korrekt aufgelöst werden.

Was repliziert wird

Verwaltetes DR kann Folgendes in jedem Replikationszyklus replizieren. Beide Kategorien sind optional, sodass Sie entweder oder beides aktivieren können:

• Unity Catalog-Metadaten und -Daten: von Unity Catalog verwaltete Tabellen in Delta Lake mit Daten, externe Tabellen und Volumes (nur Metadaten), Ansichten, Funktionen und alle Berechtigungsvergaben. Der Isolationsmodus des Katalogs wird repliziert. Wenn der Quellkatalog geöffnet ist, ist das Replikat geöffnet. Wenn die Quelle isoliert und an den primären Arbeitsbereich gebunden ist, ist das Replikat isoliert und an den sekundären Arbeitsbereich gebunden.
• Arbeitsbereichsressourcen: Notizbücher, Aufträge, SQL-Lagerhäuser, Cluster, AI/BI-Dashboards, Dateien und Ordner sowie ihre ACLs. SQL-Warehouses werden im Status STOPPED repliziert, Cluster im Status TERMINATED. Die Zeitpläne für Aufträge auf dem sekundären System sind angehalten.

Nichts, das im vorherigen Abschnitt nicht aufgeführt ist, wird nicht repliziert. Ausführliche Informationen finden Sie unter Einschränkungen.

Requirements

• Das Mission Critical Workspace-Add-On ist in beiden Arbeitsbereichen aktiviert. Siehe "Mission Critical aktivieren" in beiden Arbeitsbereichen.
• Serverlose Rechenleistung ist in beiden Arbeitsbereichen aktiviert. Serverless Compute ist standardmäßig in den meisten Unity-Katalog-aktivierten Arbeitsbereichen verfügbar. Siehe Verbindung mit serverlosem Computing herstellen.
• Rolle als Kontoadministrator mit ALLE BERECHTIGUNGEN für jeden externen Speicherort, der von den Katalogen verwendet wird, die Sie replizieren möchten.
• SSO auf Kontoebene mit allen aktivierten Arbeitsbereichen und Identitäten, die über SCIM mit dem Konto synchronisiert wurden, sodass Benutzer, Gruppen und Dienstprinzipale in beiden Regionen vorhanden sind.
• Für stabile URLs: eine benutzerdefinierte URL, die für Ihre Azure Databricks Domäne bereitgestellt wird (wenden Sie sich an Ihr Kontoteam) und OAuth auf Kontoebene.
• Ein sekundärer Arbeitsbereich und ein Unity Catalog-Metastore in der sekundären Region, im selben Azure Databricks-Konto und in derselben Cloud wie Ihre primäre Umgebung. Der sekundäre Arbeitsbereich muss mit der Konfiguration des primären Netzwerks, Private Link und der vom Kunden verwalteten Schlüssel übereinstimmen. Der sekundäre Metastore darf keine Kataloge enthalten, die dieselben Namen wie replizierte Kataloge haben. Bei der Arbeitsbereichsressourcenreplikation löscht Azure Databricks alle vorhandenen Ressourcen im sekundären Arbeitsbereich, wenn die erste Replikation abgeschlossen ist. Ressourcen außerhalb des Gültigkeitsbereichs sind nicht betroffen, sodass der sekundäre Arbeitsbereich nicht leer sein muss.
• Ein entsprechender externer Speicherort und entsprechende Speicheranmeldedaten in der sekundären Region für jeden von Ihren Primärkatalogen jeweils referenzierten Eintrag. Verwaltetes DR repliziert externe Speicherorte oder Speicheranmeldeinformationen nicht automatisch; Sie müssen sie in der sekundären Umgebung erstellen.

• Ein Azure Databricks Access Connector in der sekundären Region mit der Rolle "Storage Blob Data Contributor" für die sekundären Speicherkonten, die als Speicheranmeldeinformationen im sekundären Arbeitsbereich hinzugefügt wurden.
• Eine Netzwerkkonnektivitätskonfiguration (Network Connectivity Configuration, NCC) in der sekundären Region, die dem sekundären Arbeitsbereich zugewiesen ist.
• Genehmigte private Endpunkte für alle Quell- und sekundären Speicherkonten, auf die in Ihren replizierten Katalogen verwiesen wird.

Aktivieren Sie Mission Critical in beiden Arbeitsbereichen

Aktivieren Sie das Mission-Critical-Add-On sowohl in Ihren primären als auch in Ihren sekundären Arbeitsbereichen, bevor Sie eine Failover-Gruppe erstellen. Die Compute-Nutzung in jedem Arbeitsbereich, in dem Sie das Add-on aktivieren, wird zum Mission-Critical-Tarif abgerechnet. Wenden Sie sich an Ihr Azure Databricks Kontoteam für den aktuellen Preis.

1. Klicken Sie in der Kontokonsole auf Arbeitsbereiche, und klicken Sie dann auf den Arbeitsbereich.
2. Klicken Sie auf die Registerkarte "Add-Ons ".
3. Aktivieren Sie auf der Mission Critical-Karte den Umschalter und bestätigen Sie.

Wiederholen Sie den Vorgang für den sekundären Arbeitsbereich.

Einrichten der Replikation

Eine neue Failovergruppe wechselt durch CREATING → INITIAL_REPLICATION → ACTIVE. Der erste Replikationszyklus kopiert alle relevanten Daten auf das Sekundärsystem. Bei großen Arbeitsbereichen kann die anfängliche Bereitstellung der Workspace-Ressourcen bis zu zwei Wochen dauern. Diese Wartezeit ist einmalig. Nach Abschluss des anfänglichen Bootstrap wird die Replikation kontinuierlich ausgeführt.

Während der Replikation sind sekundäre In-Scope-Kataloge schreibgeschützt und die Berechnung ist im sekundären Arbeitsbereich nicht verfügbar. Zum Ausführen von Überprüfungsabfragen ohne Schreiben in die sekundäre Region empfiehlt Azure Databricks einen separaten schreibgeschützten Monitorarbeitsbereich in der sekundären Region.

So erstellen Sie eine Failovergruppe:

1. Klicken Sie in der Kontokonsole auf "Resilienz".
2. Wenn Sie beabsichtigen, eine stabile URL zu verwenden, klicken Sie auf die Registerkarte "Stabile URLs " und dann auf "Stabile URL erstellen". Geben Sie einen Namen ein, wählen Sie den aktuellen primären Arbeitsbereich aus, und erstellen Sie die stabile URL. Verweisen Sie nachgelagerte Clients (JDBC, ODBC, die Azure Databricks-Webbenutzeroberfläche, direkte API-Anfragen) auf die stabile URL statt auf die ursprüngliche Workspace-URL.
3. Klicken Sie auf die Registerkarte "Failovergruppen " und dann auf " Failovergruppe erstellen".
4. Füllen Sie das Formular aus:
   • Failovergruppenname: Ein Name, den Sie für die Failovergruppe auswählen.
   • Primärer Arbeitsbereich: Der Arbeitsbereich, der als Ihr primärer Arbeitsbereich festgelegt ist.
   • Sekundärer Arbeitsbereich: Der Arbeitsbereich in der sekundären Region.
   • Replizieren von Arbeitsbereichsressourcen (optional): Standardmäßig deaktiviert. Aktivieren Sie das Replizieren von Notizbüchern, Aufträgen, SQL-Lagerhäusern, Clustern, Dashboards, Dateien und Ordnern (und deren ACLs) vom primären zum sekundären. Erfordert, dass beide Arbeitsbereiche das mission Critical-Add-On aktiviert haben. Wenn Sie die Replikation von Arbeitsbereichsobjekten aktivieren, löscht Azure Databricks nach Abschluss der initialen Replikation alle vorhandenen, vom Replikationsumfang erfassten Objekte im sekundären Arbeitsbereich. Assets außerhalb des Geltungsbereichs sind nicht betroffen.
   • Stabile URL (optional): Die stabile URL, die Sie in Schritt 2 erstellt haben.
   • Replikationsbereich: Die zu replizierenden Kataloge. Sie müssen einen primären Arbeitsbereich auswählen, bevor dieses Feld verfügbar ist.
   • Speicherzuordnungen: Fügen Sie für jeden externen Speicherort, den Ihre replizierten Kataloge in der primären Region verwenden, einen Eintrag hinzu, der seinen Speicherpfad dem entsprechenden externen Speicherort zuordnet, den Sie in der sekundären Region erstellt haben (siehe Anforderungen). Sie können als Wildcard zum Präfixabgleich verwenden * .
5. Klicken Sie auf "Failovergruppe erstellen".

Beispielsweise kann eine Azure-Speicherzuordnung abfss://data@primary.dfs.core.windows.net/*abfss://data@secondary.dfs.core.windows.net/* zuordnen.

Erstellung von DRs für verwaltete Ressourcen

Wenn Sie eine Failovergruppe erstellen, stellt Managed DR zusätzliche Unity-Catalog-Ressourcen bereit, die die Replikationspipeline verwendet, um Daten zwischen Regionen zu kopieren. In den primären und sekundären Metaspeichern erstellt verwaltetes DR:

• Eine Verbindung , die auf den Arbeitsbereich in der anderen Region verweist.
• Ein fremder Katalog für jeden replizierten Katalog. Der Fremdkatalog verweist auf den entsprechenden Katalog in der anderen Region.

Diese Ressourcen werden zusammen mit Ihren eigenen Katalogen im Katalog-Explorer angezeigt. Sie können sie an ihrem Kommentar erkennen, aus dem hervorgeht, dass die Disaster Recovery von Azure Databricks sie erstellt und verwaltet.

Besitz von replizierten Ressourcen

Wenn verwaltetes DR einen replizierten sicherungsfähigen (Katalog, Schema, Tabelle, Ansicht, Funktion oder Volume) im sekundären Erstellt, ist der ursprüngliche Besitzer der Azure Databricks Dienstprinzipal, der die Replikation ausführt, da Unity Catalog der Identität, die das Objekt erstellt, Besitz zuweist. Managed DR überträgt dann den Besitz des Replikats so, dass er dem Besitzer des entsprechenden sicherbaren Objekts im Primärsystem entspricht.

Wenn der Besitzer eines Sicherungsobjekts in der primären Datenbank ein Benutzer ist, der aus dem Konto gelöscht wurde, kann Managed DR den Besitz nicht auf einen Prinzipal übertragen, der nicht mehr vorhanden ist. In diesem Fall behält das replizierbare Sicherheitsobjekt den Azure Databricks-Dienstprinzipal als Besitzer. Um dieses Problem zu beheben, weisen Sie dem Sicherungsobjekt in der primären Instanz einen gültigen Besitzer zu. Managed DR repliziert den aktualisierten Eigentümer innerhalb des RPO-Fensters in die Replik.

Verwenden der stabilen URL

Die stabile URL verweist immer auf den aktuellen primären Arbeitsbereich, sodass Clients, die sich über diese URL verbinden, nach einem Failover nicht neu konfiguriert werden müssen. Konfigurieren Sie die folgenden nachgelagerten Clients so, dass sie die stabile URL anstelle der ursprünglichen Workspace-URL verwenden:

• Die Azure Databricks Web-UI.
• JDBC- und ODBC-Verbindungen zu SQL-Data-Warehouses.
• Direkte REST-API-Anforderungen.

Stabile URLs werden mit Front-End-Private Link unterstützt, das URL-Format unterscheidet sich jedoch vom Standardformular.

Die ursprüngliche Arbeitsbereichs-URL funktioniert weiterhin, übersteht jedoch kein Failover. Azure Databricks empfiehlt, Clients zur stabilen URL zu migrieren.

Replikation überwachen

Auf der Registerkarte "Failovergruppen " werden der aktuelle Status, der Replikationspunkt und alle aktiven Fehler jeder Failovergruppe angezeigt. Mögliche Zustände:

Wählen Sie den Namen einer Failovergruppe aus, um die Detailseite zu öffnen. Der Replikationspunkt zeigt an, wann alle Ressourcen im Bereich zuletzt kopiert wurden. Daten, die nach dem Replikationspunkt geschrieben wurden, sind möglicherweise nicht im sekundären Vorhanden und können während des Failovers verloren gehen.

Fragen Sie bei historischen RPO-Trends und Replikationsfehlern pro Ressource die system.replication.states Systemtabelle ab. Siehe Referenz zur Replikationssystemtabelle.

Failover und Failback

Dasselbe Verfahren umfasst geplante Failovers (DR-Tests, geplante Wartung) und ungeplante Failover (ein regionaler Ausfall). Um zurückzuschalten, wiederholen Sie den Vorgang mit vertauschten Regionen.

Wenn Sie ein Failover auslösen, führt Azure Databricks Folgendes aus:

• Verweist die stabile URL, falls vorhanden, auf die neue primäre Region.
• Umkehrt die Richtung der Replikation.
• Hält Die Auftragspläne im ehemaligen Primären an.
• Überführt die Failovergruppe von FAILING_OVER in INITIAL_REPLICATION.

Auf das Ausfallsystem umschalten:

1. Benachrichtigen Sie Ihr Team, dass ein Failover gestartet wird.

2. Nur für ein geplantes Failover:

   1. Beenden Sie im primären Arbeitsbereich alle ausgeführten Cluster, und beenden Sie alle SQL-Lagerhäuser.
   2. Vergewissern Sie sich, dass Schreibvorgänge auf dem Primärserver gestoppt wurden, und warten Sie dann, bis die Replikation aufgeholt hat. Um dies zu überprüfen, öffnen Sie die Detailseite der Failovergruppe und bestätigen Sie, dass der Replikationspunkt innerhalb weniger Sekunden des Zeitpunkts liegt, zu dem Sie die Schreibvorgänge beendet haben.

3. Klicken Sie in der Kontokonsole auf Resilienz → Failovergruppen, und klicken Sie dann auf den Namen der Failovergruppe.

4. Klicken Sie auf "Fail over".

5. Wählen Sie den neuen primären Bereich aus, und bestätigen Sie es. Das Failover ist in wenigen Minuten abgeschlossen.

6. Starten Sie in der neuen primären Datei den Compute, der vor dem Failover ausgeführt wurde. Replizierte Cluster und SQL-Warehouses kommen im neuen Primärsystem jeweils im Zustand TERMINATED bzw. STOPPED an.

7. Setzen Sie die benötigten Auftragspläne manuell in der neuen primären Stelle fort. Die Zeitpläne des ehemaligen primären Systems sind bereits pausiert.

Clients, die über die stabile URL verbunden sind, funktionieren nach dem Failover weiterhin. Konfigurieren Sie Clients, die weiterhin die ursprüngliche Arbeitsbereichs-URL verwenden, so um, dass sie entweder die stabile URL oder die Arbeitsbereichs-URL des neuen primären Systems verwenden.

Häufige Replikationsfehler

Sie können den Status Ihrer Failovergruppen in der system.replication.states Systemtabelle überwachen. Die Tabelle enthält eine Zusammenfassung der aktuellen Fehler pro Failovergruppe. In der folgenden Tabelle sind die häufigsten Fehler aufgeführt, die am häufigsten zuerst auftreten:

Zerreißen verwalteter DR

1. Klicken Sie in der Kontokonsole auf Resilienz → Failovergruppen, und klicken Sie dann auf den Namen der Failovergruppe, und löschen Sie sie. Sie können „Mission Critical“ nicht deaktivieren, während eine Failovergruppe im Arbeitsbereich aktiv ist.
2. Um die Abrechnung zum Mission-Critical-Tarif zu beenden, deaktivieren Sie Mission Critical in jedem Workspace auf der Registerkarte Add-ons.

Limitations

Verwaltetes DR hat die folgenden Einschränkungen:

• Nicht repliziert: materialisierte Ansichten, Streamingtabellen, Lakeflow Spark Declarative Pipelines, verwaltete Volumedaten (Metadaten repliziert), Unity-Katalog- und Arbeitsbereichsgeheimnisse, ML-Modelle, Modell zur Bereitstellung von Endpunkten, Vektorsuchindizes, Delta-Freigaben, veröffentlichte AI/BI-Dashboards (Entwürfe repliziert) und Spark Structured Streaming außerhalb von Lakeflow Spark Declarative Pipelines. Tabellen mit Zeilenfiltern oder Spaltenmasken sowie mit ABAC-Tags versehene Ressourcen werden in der Systemtabelle als Replikation fehlgeschlagen gekennzeichnet, und diese Fehler verzögern das Erreichen des RPO, bis Sie die Ressource aus dem Umfang der Failovergruppe entfernen.
• Sekundäre Kataloge im Geltungsbereich sind schreibgeschützt. Schreibschutz gilt nur für replizierte Entitäten. Sie können weiterhin Ihre eigene Replikation für schutzfähige Objekte außerhalb des vom verwalteten DR abgedeckten Bereichs einrichten. Sie können jedoch im sekundären Arbeitsbereich keine Compute-Workloads ausführen, solange verwaltetes DR aktiviert ist, was den Betrieb einer selbst erstellten Replikationspipeline dort einschränkt.
• Das Umbenennen eines sicherbaren Objekts im Unity Catalog löst im Sekundärsystem ein Löschen und anschließendes Neuerstellen aus. Bei verwalteten Tabellen repliziert die Umbenennung die Tabellendaten im nächsten Zyklus erneut. Vermeiden Sie Umbenennungen während einer stabilen Replikation.
• UNDROP wird nicht an die Sekundäre weitergegeben.
• Maximal 300 Kataloge pro Konto.
• Maximal 100 Failovergruppen pro Konto.
• Die Ersteinrichtung von Workspace-Assets kann bei großen Workspaces bis zu 2 Wochen dauern.

• Verwaltetes DR ist nicht mit der Arbeitsbereichsspeicherfirewall kompatibel. Aktivieren Sie keine Firewallunterstützung für die Arbeitsbereichsspeicherkonten, die mit verwaltetem DR verwendet werden.

Informationen zu DR-Konzepten und bewährten Methoden finden Sie unter Notfallwiederherstellung.