Notfallwiederherstellung

Notfallwiederherstellung (DR) für Azure Databricks repliziert Arbeitsbereiche, Daten und Konfigurationen in cloudübergreifenden Regionen, damit Ihre Teams weiterhin arbeiten, wenn ein regionaler Ausfall Ihre primäre Bereitstellung offline nimmt. Ein vollständiger DR-Plan umfasst nicht nur Azure Databricks, sondern auch die Datenquellen, Datenaufnahme-Tools, BI-Tools und Scheduler, mit denen es verbunden ist.

Auf dieser Seite werden die Konzepte, Strategien, Tools und Testverfahren behandelt, die Sie zum Entwerfen und Ausführen einer regionsübergreifenden DR-Lösung benötigen.

Neu bei der DR-Planung? Beginnen Sie mit der Terminologie der Notfallwiederherstellung für Definitionen von RPO und RTO.

Wichtig

Verwenden Sie die verwaltete Notfallwiederherstellung. Azure Databricks empfiehlt die verwaltete Notfallwiederherstellung für regionsübergreifende DR auf AWS und Azure. Es repliziert Unity-Katalogmetadaten, verwaltete Tabellendaten und Arbeitsbereichsressourcen in einem kontinuierlichen Zeitplan, bietet eine stabile URL, die das Failover überlebt, und ermöglicht es Ihnen, das Failover über die Kontokonsole auszulösen. Keine Replikationsskripte müssen erstellt oder gepflegt werden. Verwenden Sie die DIY-Anleitungen auf dieser Seite nur für Ressourcen, die von Managed DR nicht repliziert werden, oder wenn Sie Active-Active-Topologien, cloudübergreifende Replikation oder eine feingranulare Kontrolle über die Replikationspipeline benötigen.

Hochverfügbarkeitsgarantien innerhalb der Region

Der Rest dieser Seite umfasst regionsübergreifende DR, aber Azure Databricks bietet auch hohe Verfügbarkeit (HA) innerhalb einer einzelnen Region. Verstehen Sie diese Garantien zuerst. Sie bestimmen, ob Sie eine separate DR-Strategie benötigen.

HA und DR lösen verschiedene Probleme:

HA verwendet Az-Redundanz (Availability Zone) innerhalb einer Region. Wenn eine Zone fehlschlägt, werden die Dienste weiterhin in den anderen Ausgeführt.
DR verwendet die regionsübergreifende Replikation. Sie betreiben sekundäre Azure-Databricks-Arbeitsbereiche in einer anderen Region und replizieren Daten und Konfigurationen dorthin; bei einem regionalen Ausfall schwenken Sie dann auf sie um.

Wenn Sie keine regionsübergreifende DR benötigen, ist Azure Databricks HA möglicherweise ausreichend. HA vermeidet regionsübergreifende Komplexität, schützt aber nicht vor einem vollständigen Ausfall einer Region. Wenn Sie sich allein auf HA für DR verlassen, überprüfen Sie die Trennung und Redundanz Ihrer Cloudregion.

Die Intra-Region-HA-Garantien gelten für die Kontrollebene und die Rechenebene.

Verfügbarkeit der Azure Databricks Steuerebene

Die Azure Databricks Steuerebene ist widerstandsfähig für Zonenfehler und wird innerhalb von ca. 15 Minuten nach einem Zonenausfall automatisch wiederhergestellt. Bei regulären Zonenfehlertests wird dies überprüft.

Alle zustandslosen Dienste der Steuerungsebene können einzelne VMs oder alle VMs in einer ganzen Zone verlieren, ohne dass der Dienst ausfällt. Arbeitsbereichsdaten werden in Datenbanken gespeichert, die über Zonen in der Region repliziert werden. Speicherkonten, die Databricks-Runtime-Images hosten, sind ebenfalls innerhalb der Region redundant, und alle Regionen verfügen über sekundäre Speicherkonten, die den Betrieb übernehmen, wenn das primäre Speicherkonto ausfällt.

Hinweis

Die oben genannten Kontrollebenengarantien gelten für Azure Databricks verwaltete Infrastruktur. Sie sind für die Zonenredundanz der Compute-Ebene verantwortlich, z. B. indem Sie für den Stamm-Bucket des Arbeitsbereichs zonenredundanten Speicher auswählen und Instanzpools verwenden, die sich über Verfügbarkeitszonen erstrecken.

Einige Azure Regionen verwenden eine Steuerebene, die in einem gekoppelten Bereich bereitgestellt wird. Weitere Informationen finden Sie unter Azure Databricks-Regionen.

Die Resilienz bei Zonenausfällen toleriert höchstens den Ausfall einer Zone und ist nur in Azure-Regionen verfügbar, die mehrere Zonen unterstützen.

Verfügbarkeit der Computeebene

Die Verfügbarkeit des Arbeitsbereichs hängt von der Verfügbarkeit der Steuerungsebene ab.

DBFS-Stammdaten sind nicht betroffen, wenn das Speicherkonto mit zonenredundanten Speicher (Zone Redundant Storage, ZRS) oder geozonenredundanten Speicher (GZRS) konfiguriert ist. Der Standardwert ist georedundanter Speicher (GRS).

Clusterknoten werden aus unterschiedlichen Verfügbarkeitszonen bezogen, indem Knoten beim Azure-Computeanbieter angefordert werden, vorausgesetzt, dass in den verbleibenden Zonen ausreichend Kapazität vorhanden ist. Wenn ein Knoten verloren geht, fordert der Cluster-Manager Ersatzknoten vom Azure-Computeanbieter an, der sie aus den verfügbaren AZs abruft. Die Ausnahme ist, wenn der Treiberknoten verloren geht. In diesem Fall startet der Cluster-Manager den Job und den Cluster neu.

Informationen zur Bestätigung der Multi-AZ-Unterstützung finden Sie in der Liste der Azure Regionen. Verwenden Sie für die Multi-AZ-Resilienz der Computeebene einen zonenredundanten Speicher.

Begriff

Verwenden Sie diese Definitionen konsistent, wenn Sie DR mit Ihrem Team besprechen.

Regionsterminologie

Terminologie der Region

Diese Seite verwendet die folgenden Regionsdefinitionen:

Primäre Region: Die Region, in der Benutzer täglich interaktive und automatisierte Datenanalyseworkloads ausführen.
Sekundäre Region: Die Region, in der IT-Teams Workloads vorübergehend während eines Ausfalls einer primären Region verschieben.
Georedundanter Speicher: Asynchrone regionsübergreifende Replikation des dauerhaften Speichers. Sehen Sie sich die Dokumentation Ihrer Cloud an:

Georedundanter Speicher über Regionen (Azure) hinweg.

Wichtig

Verlassen Sie sich nicht auf georedundanten Speicher, um den Azure Databricks-Rootspeicher (z. B. den ADLS, den Azure Databricks für jeden Arbeitsbereich erstellt; bei Arbeitsbereichen, die vor dem 6. März 2023 erstellt wurden, Azure Blob Storage) regionsübergreifend zu duplizieren. Um verwaltete Tabellendaten zu replizieren, verwenden Sie Delta Deep Clone, und konvertieren Sie bei Nicht-Delta-Daten zuerst nach Möglichkeit in Delta.

Terminologie des Bereitstellungsstatus

Terminologie zum Bereitstellungsstatus

Diese Seite verwendet die folgenden Bereitstellungsstatusdefinitionen:

Aktive Bereitstellung (manchmal als hot deployment bezeichnet): Benutzer stellen eine Verbindung mit ihr her und führen Workloads aus. Aufträge und Datenströme werden hier im Zeitplan ausgeführt.
Passive Bereitstellung (manchmal als kalter Bereitstellung bezeichnet): Hier werden keine Prozesse ausgeführt. IT-Teams halten sie bereit, indem sie die Bereitstellung von Code, Konfiguration und anderen Azure Databricks Objekten automatisieren. Eine passive Bereitstellung wird nur aktiv, wenn die aktive Bereitstellung ausfällt.

Wichtig

Ein Projekt kann mehrere passive Bereitstellungen in verschiedenen Regionen umfassen, um zusätzliche Resilienz zu erhalten.

Die meisten Teams führen jeweils eine aktive Bereitstellung aus, die aktiv-passive Strategie. Die weniger verbreitete Active-Active-Strategie verwendet zwei gleichzeitig aktive Bereitstellungen.

Terminologie der Notfallwiederherstellung

Terminologie der Notfallwiederherstellungsbranche

Definieren Sie diese beiden Branchenbegriffe mit Ihrem Team:

Ziel des Wiederherstellungspunkts (RPO): Der maximale Zeitraum des Datenverlusts, den Ihr Dienst während eines schwerwiegenden Vorfalls tolerieren kann. Siehe RPO.

Azure Databricks speichert ihre primären Kundendaten nicht. Das lebt in ADLS (für Arbeitsbereiche, die vor dem 6. März 2023 erstellt wurden, Azure Blob Storage) oder anderen Systemen, die Sie steuern. Die Azure Databricks Steuerebene speichert einige Objekte (z. B. Aufträge und Notizbücher), sodass das Azure Databricks RPO der maximale Zeitraum ist, in dem Änderungen an diesen Objekten verloren gehen können. Sie sind für die Definition des RPO für Ihre Kundendaten in ADLS (für Arbeitsbereiche, die vor dem 6. März 2023, Azure Blob Storage) erstellt wurden, und für andere Datenquellen verantwortlich, die Sie steuern.
Wiederherstellungszeitziel (RTO): Die maximale Zeit, innerhalb der ein Geschäftsprozess nach einem Notfall wiederhergestellt werden muss. Siehe RTO.

Notfallwiederherstellung und Datenbeschädigung

Eine DR-Lösung mindert nicht die Datenkorruption. Beschädigte Daten in der primären Region werden in die sekundäre Region repliziert und sind dadurch in beiden Regionen beschädigt. Um diese Art von Fehlern zu vermeiden, verwenden Sie Delta-Zeitreisen, ähnliche Tools oder Datensicherungstools.

Typischer Wiederherstellungsworkflow

Ein Azure Databricks DR-Szenario spielt in der Regel wie folgt aus:

Ein Ausfall betrifft einen kritischen Dienst in Ihrer primären Region: eine Datenquelle, ein Netzwerk oder eine andere Abhängigkeit, von der die Azure-Databricks-Bereitstellung abhängt.
Sie untersuchen den Vorfall bei Ihrem Cloud-Anbieter.
Wenn das Warten inakzeptabel ist, entscheiden Sie sich für ein Failover in Ihre sekundäre Region.
Bestätigen Sie, dass sich dasselbe Problem nicht auf Ihre sekundäre Region auswirkt.
Umschalten (ausführliche Anweisungen finden Sie unter Failover testen):
1. Beenden Sie alle Arbeitsbereichsaktivitäten. Benutzer beenden Arbeitsauslastungen und sichern aktuelle Änderungen, sofern möglich. Jobs werden beendet (falls der Ausfall sie nicht bereits zum Fehlschlagen gebracht hat).
2. Führen Sie das Wiederherstellungsverfahren für sekundäre Regionen aus, um Routing- und Umleitungsverbindungen und Netzwerkdatenverkehr zu aktualisieren.
3. Stellen Sie nachgeschaltete Systeme (BI-Tools, Planer, Integrationen von Drittanbietern) auf den sekundären Arbeitsbereich um und stellen Sie ihre Verbindungen wieder her.
4. Deklarieren Sie nach dem Testen die sekundäre Region als betriebsbereit. Benutzer melden sich bei der nun aktiven Bereitstellung an, und Sie lösen geplante oder verzögerte Jobs erneut aus.
Nachdem das Problem in der primären Region eingedämmt wurde, bestätigen Sie die Fehlerbehebung.
Failback (Details finden Sie unter "Testen der Wiederherstellung (Failback)"):
1. Beenden Sie alle Arbeiten in der sekundären Region.
2. Führen Sie die Wiederherstellungsprozedur der primären Region aus, um das Routing zurückzuleiten.
3. Replizieren Sie alle neuen Daten zurück in den primären Bereich. Minimieren Sie, was repliziert werden muss. Schreibgeschützte Aufträge, die in der sekundären Bereitstellung ausgeführt wurden, erfordern möglicherweise keinen Rückschreibvorgang.
4. Testen Sie die Bereitstellung in der primären Region.
5. Markieren Sie die primäre Region als aktiv und nehmen Sie die Produktions-Workloads wieder auf.

Wichtig

Einige Datenverluste können während dieser Schritte auftreten. Definieren Sie, wie viel Verlust für Ihre Organisation akzeptabel ist und wie Sie ihn mindern.

Schritt 1: Verstehen Ihrer Geschäftsanforderungen

Identifizieren Sie, welche Datendienste kritisch sind, und definieren Sie deren Ziel-RPO und RTO. Recherchieren Sie die reale Toleranz jedes Systems.

DR, Failover und Failback tragen echte Kosten und Risiken, einschließlich Datenbeschädigung, Datenduplizierung (Schreiben an den falschen Speicherort) und Benutzer, die Änderungen an der falschen Region vornehmen.

Ordnen Sie jeden Azure Databricks Integrationspunkt zu, der sich auf Ihr Unternehmen auswirkt, und wählen Sie die Tools und Kommunikationskanäle aus, die Ihr Plan verwendet.

Integrationspunkte zur Zuordnung

Muss Ihre DR-Lösung interaktive Prozesse, automatisierte Prozesse oder beides berücksichtigen?
Welche Datendienste nutzen Sie? Einige könnten On-Premises sein.
Wie kommen Eingabedaten in die Cloud?
Wer nutzt diese Daten? Welche Prozesse nutzen es im weiteren Verlauf?
Gibt es Integrationen von Drittanbietern, die sich über DR-Änderungen informieren müssen?

Tools und Kommunikation zum Planen

Können Sie Ihre Konfiguration vordefinieren und modular gestalten, um DR-Lösungen auf natürliche und wartungsfähige Weise zu unterstützen?
Welche Kommunikationstools und -kanäle benachrichtigen interne Teams und Drittanbieter (Integrationen, Downstream-Consumer) über DR-Failover- und Failbackänderungen? Wie bestätigen Sie ihre Bestätigung?
Welche Dienste schalten Sie gegebenenfalls ab, bis die vollständige Wiederherstellung erfolgt ist?

Schritt 2: Auswählen eines Prozesses, der Ihre Geschäftsanforderungen erfüllt

Standardeinstellung für die verwaltete Notfallwiederherstellung. Es übernimmt die Arbeitsbereichsreplikation, Metadaten des Unity Catalog, Daten verwalteter Tabellen und die Failover-Orchestrierung ohne benutzerdefinierte Skripte. Verwenden Sie die nachstehenden Anleitungen zur Selbstkonfiguration nur, wenn Ihr Szenario nicht darunter fällt, wie z. B. Ressourcen, die von Managed DR nicht repliziert werden, Active-Active-Topologien, cloudübergreifende Replikation oder feingranulare Kontrolle über die Replikationspipeline.

Eine DIY-Lösung muss die richtigen Daten über die Steuerebene, die Computeebene und Datenquellen replizieren. Redundante Arbeitsbereiche sind unterschiedlichen Steuerebenen in verschiedenen Regionen zugeordnet, sodass Sie sie mit einer skriptbasierten Lösung, entweder einem Synchronisierungstool oder einem CI/CD-Workflow, synchronisieren. Für die Daten selbst verwenden die meisten Teams Azure Databricks Aufträge (häufig geplant) oder Delta Deep Clone, um Tabellen zwischen Regionen zu kopieren. Sie müssen keine Daten aus der Computeebene synchronisieren (z. B. aus Databricks-Runtime-Mitarbeitern).

Wenn Sie das VNet-Einfügungsfeature verwenden (nicht mit allen Abonnement- und Bereitstellungstypen verfügbar), stellen Sie Netzwerke konsistent in beiden Regionen mithilfe von vorlagenbasierten Tools wie Terraform bereit.

Replizieren Sie Ihre Datenquellen nach Bedarf über Regionen hinweg.

DR-Lösungen umfassen in der Regel zwei (oder mehr) Arbeitsbereiche. Wählen Sie je nach der Dauer der Unterbrechung, die Sie tolerieren müssen, dem betrieblichen Aufwand und den Kosten für ein Failback zur primären Region zwischen den folgenden Strategien.

Allgemeine bewährte Methoden

Zu den allgemeinen bewährten Methoden für einen erfolgreichen DR-Plan gehören:

Verstehen, welche Prozesse für das Unternehmen kritisch sind und in DR ausgeführt werden müssen.
Identifizieren Sie eindeutig, welche Dienste beteiligt sind, welche Daten verarbeitet werden, was der Datenfluss ist und wo sie gespeichert wird.
Isolieren Sie die Dienste und Daten so weit wie möglich. Erstellen Sie beispielsweise einen speziellen Cloudspeichercontainer für die DR-Daten, oder verschieben Sie Azure Databricks Objekte, die während eines Notfalls in einen separaten Arbeitsbereich erforderlich sind.
Sie sind für die Aufrechterhaltung der Integrität zwischen primären und sekundären Bereitstellungen für Objekte verantwortlich, die nicht in der Azure Databricks Kontrollebene gespeichert sind.
Verwenden Sie für Datenquellen systemeigene Azure Tools, um Daten nach Möglichkeit in Ihre DR-Regionen zu replizieren.

Warnung

Speichern Sie keine Daten im ADLS-Stamm (für Arbeitsbereiche, die vor dem 6. März 2023 erstellt wurden, Azure Blob Storage), der für den Stammzugriff von DBFS verwendet wird. DBFS-Stammspeicher wird für Kundendaten der Produktionsumgebung nicht unterstützt. Azure Databricks empfiehlt auch davon ab, Bibliotheken, Konfigurationsdateien oder Initialisierungsskripts dort zu speichern.

Aktiv-passive Lösungsstrategie

Aktiv/Passiv-Lösungsstrategie

Dieser Abschnitt konzentriert sich auf die aktiv-passive Strategie, da sie am häufigsten, am einfachsten und kostengünstigsten ist. Eine aktiv passive Lösung synchronisiert Daten- und Objektänderungen von Ihrer aktiven Bereitstellung mit einer passiven Bereitstellung in einer sekundären Region. Während eines DR-Ereignisses wird die passive Bereitstellung zur aktiven.

Zwei gängige Varianten:

Einheitlich (unternehmensweit): Ein Satz aktiver und passiver Bereitstellungen für die gesamte Organisation.
Nach Abteilung oder Projekt: Jede Domäne verwaltet eine eigene DR-Lösung mit primären und sekundären Regionen, die auf ihre Anforderungen zugeschnitten sind.

Sie können auch eine passive Bereitstellung für schreibgeschützte Workloads verwenden, z. B. für Benutzerabfragen, die weder Daten noch Azure-Databricks-Objekte ändern.

Aktive Lösungsstrategie

Aktiv/Aktiv-Lösungsstrategie

In einer aktiven Lösung werden alle Datenprozesse in beiden Regionen jederzeit parallel ausgeführt. Ihr Operations-Team darf jeden Auftrag erst dann als abgeschlossen markieren, nachdem er in beiden Regionen erfolgreich abgeschlossen wurde. Objekte können in der Produktion nicht geändert werden und müssen einem strikten CI/CD-Promotionsprozess von der Entwicklungs-/Staging-Umgebung in die Produktion folgen.

Aktiv-Aktiv ist die komplexeste Strategie und verursacht höhere Kosten, da Workloads in beiden Regionen ausgeführt werden, bietet jedoch die niedrigsten RTO- und RPO-Werte.

Sie können eine Aktiv-Aktiv-Konfiguration unternehmensweit oder abteilungsweise implementieren. Sie benötigen keinen doppelten Arbeitsbereich für jede Workload. Beispielsweise sind Entwicklungs- oder Staging-Arbeitsbereiche oft einfacher aus einer Entwicklungspipeline zu rekonstruieren als zu synchronisieren.

Auswählen der Tools

Wählen Sie Ihre Tools

Es gibt zwei Hauptansätze für die Synchronisierung von Daten zwischen Arbeitsbereichen in Ihren primären und sekundären Regionen:

Synchronisierungsclient, der vom primären in das sekundäre Region kopiert: Ein Synchronisierungsclient überträgt Produktionsdaten und Ressourcen aus der primären in die sekundäre Region. In der Regel wird dies auf geplanter Basis ausgeführt, und die Zeitplanhäufigkeit hängt von Ihrem Ziel-RTO und RPO ab.
CI/CD-Tools für die parallele Bereitstellung: Verwenden Sie für Produktionscode und Ressourcen CI/CD-Tools, die Änderungen gleichzeitig an Produktionssysteme in beide Regionen pushen. Wenn Sie z. B. Code und Ressourcen aus Staging/Entwicklung in die Produktion pushen, stellt ein CI/CD-System ihn gleichzeitig in beiden Regionen zur Verfügung. Der Kerngedanke besteht darin, alle Artefakte in einem Azure Databricks Arbeitsbereich als Infrastructure-as-Code zu behandeln. Die meisten Artefakte können sowohl für primäre als auch für sekundäre Arbeitsbereiche gemeinsam bereitgestellt werden, während einige Artefakte möglicherweise erst nach einem DR-Ereignis bereitgestellt werden müssen. Tools finden Sie unter Automatisierungsskripts, Beispiele und Prototypen.

Je nach Ihren Anforderungen können Sie die Ansätze kombinieren. Verwenden Sie beispielsweise CI/CD für Notebook Quellcode, aber verwenden Sie die Synchronisierung für die Konfiguration wie Pools und Zugriffssteuerungen.

In der folgenden Tabelle wird beschrieben, wie sie jeden Datentyp mit jeder Tooloption behandeln.

Beschreibung	Umgang mit CI/CD-Werkzeugen	Umgang mit dem Synchronisierungstool
Quellcode: Notebook-Quellcodeexporte und Quellcode für gepackte Bibliotheken	Gleichzeitige Bereitstellung sowohl auf primären als auch sekundären Systemen.	Synchronisieren Sie den Quellcode vom primären zum sekundären System.
Benutzer und Gruppen	Verwalten Sie Metadaten als Konfiguration in Git. Alternativ können Sie für beide Arbeitsbereiche denselben Identitätsanbieter (IdP) verwenden. Gleichzeitige Bereitstellung von Benutzer- und Gruppendaten zu primären und sekundären Implementierungen.	Verwenden Sie SCIM oder eine andere Automatisierung für beide Regionen. Die manuelle Erstellung wird nicht empfohlen, aber wenn sie verwendet wird, muss für beide gleichzeitig durchgeführt werden. Wenn Sie ein manuelles Setup verwenden, erstellen Sie einen geplanten automatisierten Prozess, um die Liste der Benutzer und Gruppen zwischen den beiden Bereitstellungen zu vergleichen.
Poolkonfigurationen	Können Vorlagen in Git sein. Co-Bereitstellung auf primäre und sekundäre Ziele. `min_idle_instances` in secondary muss jedoch bis zum DR-Ereignis null sein.	Pools, die mit einem beliebigen `min_idle_instances` erstellt werden, wenn sie über die API oder CLI mit einem sekundären Arbeitsbereich synchronisiert werden.
Auftragskonfigurationen	Verwenden Sie Databricks Asset Bundles mit Zielen pro Umgebung (z. B. `prod` und `dr`), um dieselbe Jobdefinition in beiden Regionen bereitzustellen. Legen Sie für die sekundäre Bereitstellung die Nebenläufigkeit auf null fest, sodass der Auftrag vorbereitet, aber nicht ausgeführt wird. Ändern Sie den Gleichzeitigkeitswert, nachdem die sekundäre Bereitstellung aktiv geworden ist.	Wenn die Aufträge aus irgendeinem Grund auf vorhandenen `<interactive>` Clustern ausgeführt werden, sollte der Synchronisierungsclient dem entsprechenden `cluster_id` im sekundären Arbeitsbereich zugeordnet werden.
Zugriffssteuerungslisten (ACLs)	Können Vorlagen in Git sein. Gleichzeitige Bereitstellung auf primären und sekundären Deployments für Notebooks, Ordner und Cluster. Halten Sie die Auftragsdaten jedoch bis zum Eintritt des DR-Ereignisses zurück.	Die Berechtigungs-API kann Zugriffssteuerungen für Cluster, Aufträge, Pools, Notebooks und Ordner festlegen. Ein Synchronisierungsclient muss die entsprechenden Objekt-IDs für jedes Objekt im sekundären Arbeitsbereich zuordnen. Databricks empfiehlt, eine Zuordnung der Objekt-IDs zwischen primärem und sekundärem Arbeitsbereich zu erstellen und diese Objekte vor dem Replizieren der Zugriffssteuerung zu synchronisieren.
Bibliotheken	Fügen Sie in den Quellcode und die Cluster-/Auftragsvorlagen ein.	Synchronisieren Sie benutzerdefinierte Bibliotheken aus zentralisierten Repositorys, DBFS oder dem Cloudspeicher (kann eingebunden werden).
Cluster-Init-Skripte	Fügen Sie bei Bedarf den Quellcode hinzu.	Um die Synchronisierung zu vereinfachen, speichern Sie Init-Skripts im primären Arbeitsbereich in einem gemeinsamen Ordner oder nach Möglichkeit in einem kleinen Satz von Ordnern.
Einhängepunkte	Schließen Sie den Quellcode ein, wenn er nur über notebookbasierte Aufträge oder die Befehls-API erstellt wird.	Verwenden Sie Aufträge, die als ADF-Aktivitäten (Azure Data Factory-Aktivitäten) ausgeführt werden können. Beachten Sie, dass sich die Speicherendpunkte ändern können, da sich Arbeitsbereiche in unterschiedlichen Regionen befinden. Dies hängt auch von Ihrer Daten-DR-Strategie ab.
Tabellenmetadaten	Für Unity Catalog-Objekte (Kataloge, Schemata, Tabellen, Volumes und Berechtigungen) gemeinsam mit dem Databricks Terraform-Provider oder Databricks Asset Bundles bereitstellen. Fügen Sie bei älteren Hive-Metastore-Tabellen Create-Table-Anweisungen mit Quellcode hinzu, wenn sie über Notizbuch-basierte Aufträge oder die Befehls-API erstellt wurden.	Lesen Sie für Unity Catalog-Objekte Quellmetadaten aus Systemtabellen oder `information_schema` und replizieren Sie sie mithilfe des Databricks SDK in den sekundären Arbeitsbereich. Für Legacy-Hive-Metastore-Tabellen vergleichen Sie Metadatendefinitionen zwischen Metastores mithilfe der Spark Catalog-API oder `SHOW CREATE TABLE` in einem Notebook oder mithilfe von Skripten. Zugrunde liegende Speicherpfade können regionsbasiert sein und können sich zwischen Metastoreinstanzen unterscheiden.
Geheimnisse	Fügen Sie in den Quellcode ein, wenn er nur durch die Befehls-API erstellt wird. Beachten Sie, dass einige Geheimnisinhalte möglicherweise zwischen dem Primären und dem Sekundären geändert werden müssen.	Geheimnisse werden in beiden Arbeitsbereichen über die API erstellt. Beachten Sie, dass einige Geheimnisinhalte möglicherweise zwischen dem Primären und dem Sekundären geändert werden müssen.
Clusterkonfigurationen	Können Vorlagen in Git sein. Stellen Sie gleichzeitig in primären und sekundären Bereitstellungen bereit, obwohl die in der sekundären Bereitstellung bis zum DR-Fall beendet bleiben sollten.	Cluster werden erstellt, nachdem sie mithilfe der API oder CLI mit dem sekundären Arbeitsbereich synchronisiert wurden. Diese können abhängig von den Einstellungen für die automatische Beendigung explizit beendet werden.
Notebook-, Auftrags- und Ordnerberechtigungen	Können Vorlagen in Git sein. Co-Bereitstellung für primäre und sekundäre Bereitstellungen.	Verwenden Sie für die Replikation die Berechtigungs-API.

Auswählen von Regionen und mehreren sekundären Arbeitsbereichen

Sie steuern, wann DR ausgelöst wird und zu welcher sekundären Region Sie ein Failover durchführen. Sie sind auch für die Stabilisierung der DR-Umgebung verantwortlich, bevor Sie den normalen Betrieb fortsetzen. Dies bedeutet in der Regel, mehrere Azure Databricks Arbeitsbereiche für Die Produktion und DR zu erstellen und dann einen sekundären Failoverbereich auszuwählen.

Bevor Sie Ihre sekundäre Region auswählen, vergewissern Sie sich, dass alle Ressourcen und Dienste, von denen Sie abhängig sind (Computetypen, Produkte, Integrationen) verfügbar sind. Einige Azure Databricks Dienste sind nur in bestimmten Regionen verfügbar.

Überprüfen Sie auch die Verfügbarkeit der Datenreplikation und des VM-Typs.

Schritt 3: Arbeitsbereiche vorbereiten und eine einmalige Kopie erstellen

Stellen Sie zunächst einen sekundären Azure Databricks Arbeitsbereich (oder Arbeitsbereiche) und den unterstützenden Metaspeicher in Ihrer ausgewählten sekundären Region auf. Der sekundäre Arbeitsbereich muss das Konto, die Region und die Identitätskonfiguration des primären Arbeitsbereichs spiegeln, bevor Sie Daten oder Ressourcen replizieren können.

Wenn Sie die verwaltete Notfallwiederherstellung verwenden, behandelt Azure Databricks den anfänglichen Bootstrap von In-Scope-Katalogen und Arbeitsbereichsressourcen, wenn Sie eine Failovergruppe erstellen. Sie müssen keine einmalige Kopie für diese Ressourcen ausführen. Fahren Sie mit dem restlichen Teil dieses Abschnitts fort, und zwar für alle Datenquellen oder Ressourcen, die von Managed DR nicht repliziert werden.

Führen Sie für einen Produktionsarbeitsbereich, der außerhalb des Bereichs verwalteter DR ausgeführt wird, eine einmalige Kopie aus, um die passive Bereitstellung mit der aktiven Bereitstellung zu synchronisieren. Diese Kopierhandles:

Datenreplikation: Verwenden Sie eine Cloudreplikationslösung oder Delta Deep Clone.
Tokengenerierung: Automatisieren Sie replikations- und zukünftige Workloads mit generierten Token.
Arbeitsbereichreplikation: Replizieren Sie mithilfe der Methoden in Schritt 4: Bereiten Sie Ihre Datenquellen vor. Umfassende Anleitungen zum Exportieren von Arbeitsbereichskonfigurationen, Daten und AI/ML-Ressourcen finden Sie unter Exportieren von Arbeitsbereichsdaten.
Arbeitsbereichüberprüfung: Testen Sie den Arbeitsbereich und den Prozess, um zu bestätigen, dass sie erfolgreich ausgeführt werden, und erzeugen Sie die erwarteten Ergebnisse.

Nachfolgende Synchronisierungen werden schneller als die ursprüngliche Kopie ausgeführt, und Ihre Tools protokollieren, was sich geändert hat und wann.

Schritt 4: Vorbereiten Ihrer Datenquellen

Azure Databricks kann eine Vielzahl von Datenquellen mithilfe von Batchverarbeitung oder Datenströmen verarbeiten.

Batchverarbeitung aus Datenquellen

Batchdaten befinden sich in der Regel in einer Quelle, die Sie replizieren oder an eine andere Region übermitteln können.

Daten werden z. B. häufig nach einem Zeitplan in den Cloudspeicher hochgeladen. Leiten Sie im DR-Modus diese Uploads an den Speicher in Ihrer sekundären Region weiter und passen Sie die Workloads so an, dass sie aus diesem Speicher lesen und in ihn schreiben.

Datenströme

Die Verarbeitung eines Datenstroms ist eine größere Herausforderung. Streamingdaten können aus verschiedenen Quellen aufgenommen, verarbeitet und an eine Streaming-Lösung gesendet werden.

Nachrichtenwarteschlange wie Kafka
Datenbankänderungsdaten-Erfassungsstrom
Dateibasierte fortlaufende Verarbeitung
Dateibasierte geplante Verarbeitung, auch als Einmal-Auslöser bekannt

In all diesen Fällen müssen Sie Ihre Datenquellen so konfigurieren, dass sie den DR-Modus unterstützen und Ihre sekundäre Bereitstellung in Ihrer sekundären Region verwenden.

Ein Datenstrom-Schreiber speichert einen Prüfpunkt mit Informationen über die verarbeiteten Daten. Dieser Prüfpunkt kann einen Datenspeicherort (normalerweise Cloudspeicher) enthalten, der zu einem neuen Speicherort geändert werden muss, um einen erfolgreichen Neustart des Datenstroms sicherzustellen. Beispielsweise kann der Unterordner source unter dem Prüfpunkt den dateibasierten Cloudordner speichern.

Dieser Prüfpunkt muss rechtzeitig repliziert werden. Erwägen Sie die Synchronisierung des Prüfpunktintervalls mit einer neuen Cloudreplikationslösung.

Das Aktualisieren von Prüfpunkten ist eine Funktion des Schreibers und betrifft daher den Datenstrom bei der Aufnahme, Verarbeitung und Speicherung auf einer anderen Streaming-Quelle.

Stellen Sie für Streamingworkloads sicher, dass Prüfpunkte im vom Kunden verwalteten Speicher konfiguriert sind, damit sie für die Wiederaufnahme der Workload ab dem Zeitpunkt des letzten Fehlers in die sekundäre Region repliziert werden können. Sie können auch den sekundären Streamingprozess parallel zum primären Prozess ausführen.

Schritt 5: Implementieren und Testen Ihrer Lösung

Wenn Sie die verwaltete Notfallwiederherstellung verwenden, können Sie ein geplantes Failover über die Kontokonsole auslösen, um zu überprüfen, ob Das Setup am Ende funktioniert. Dasselbe Verfahren umfasst sowohl DR-Tests als auch reale Ausfälle. Siehe Failover und Failback.

Testen Sie Ihre DR-Einrichtung regelmäßig. Ein nicht getesteter DR-Plan schlägt häufig fehl, wenn Sie ihn benötigen. Einige Teams wechseln alle paar Monate nach einem festen Zeitplan die aktive Region, um Annahmen zu überprüfen, Prozesse zu erproben und sicherzustellen, dass das Team mit dem Runbook vertraut bleibt.

Wichtig

Testen Sie Ihre DR-Lösung in realen Bedingungen regelmäßig.

Wenn bei einem Test ein fehlendes Objekt oder eine fehlende Vorlage angezeigt wird, aktualisieren Sie Ihren Plan: Entfernen Sie die Abhängigkeit, replizieren Sie es in den sekundären Arbeitsbereich, oder stellen Sie es auf eine andere Weise zur Verfügung.

Testen Sie auch die Organisations- und Konfigurationsänderungen. Ihr DR-Plan wirkt sich auf Ihre Bereitstellungspipeline aus, sodass das Team wissen muss, was synchronisiert werden soll. Vergewissern Sie sich nach dem Einrichten von DR-Arbeitsbereichen, dass Ihre Infrastruktur, Aufträge, Notizbücher, Bibliotheken und andere Arbeitsbereichsobjekte in der sekundären Region verfügbar sind.

Erweitern Sie Ihre Standardarbeitsprozesse und Konfigurationspipelines, um Änderungen in allen Arbeitsbereichen auszurollen. Verwalten Sie Benutzeridentitäten über Arbeitsbereiche hinweg, und konfigurieren Sie die Auftragsautomatisierung und -überwachung für die neuen Arbeitsbereiche.

Planen und testen Sie Änderungen an Ihren Konfigurationstools.

Konfigurationsänderungen für Plan und Test

Bereiten Sie für jeden der folgenden Punkte einen Plan für Failover vor, und testen Sie alle Annahmen:

Erfassung: Verstehen Sie, wo Sich Ihre Datenquellen befinden und wo diese Quellen ihre Daten erhalten. Wenn möglich, parametrisieren Sie die Quelle, und verwenden Sie eine separate Konfigurationsvorlage für die sekundäre Bereitstellung und Region.
Ausführungsänderungen: Wenn Sie einen Planer zum Auslösen von Aufträgen oder anderen Aktionen haben, benötigen Sie möglicherweise einen separaten Zeitplan, der mit der sekundären Bereitstellung oder den zugehörigen Datenquellen funktioniert.
Interaktive Konnektivität: Erwägen Sie, wie Konfiguration, Authentifizierung und Netzwerkverbindungen von regionalen Unterbrechungen für jede Verwendung von REST-APIs, CLI-Tools oder anderen Diensten wie ODBC betroffen sind.
Automatisierungsänderungen: Für alle Automatisierungstools.
Ausgaben: Für alle Tools, die Ausgabedaten oder Protokolle generieren.
Nachgeschaltete Änderungen: Planen Sie für BI-Tools, Dashboards, Zeitplanungen und Drittanbieterintegrationen, die aus Azure Databricks lesen oder schreiben, wie Sie sie im sekundären Arbeitsbereich erneut anzeigen und deren Besitzer benachrichtigen.

Testen des Failovers

Testfailover

Viele Szenarien können DR auslösen: ein unerwarteter Ausfall im Cloud-Netzwerk, Cloud-Speicher oder in einem anderen Kerndienst, bei dem kein ordnungsgemäßes Herunterfahren möglich ist; eine geplante Abschaltung oder ein geplanter Ausfall; oder sogar der regelmäßige Wechsel zwischen Regionen im Rahmen Ihres Testzyklus.

Zum Testen des Failovers stellen Sie eine Verbindung mit dem System her, und führen Sie ein Herunterfahren aus. Vergewissern Sie sich, dass alle Aufträge abgeschlossen sind und Cluster beendet werden.

Ein Synchronisierungsclient (oder CI/CD-Tooling) repliziert relevante Azure Databricks Objekte und Ressourcen in den sekundären Arbeitsbereich. Um den sekundären Arbeitsbereich zu aktivieren, kann ihr Prozess einige oder alle der folgenden Elemente umfassen:

Führen Sie Tests aus, um sicherzustellen, dass die Plattform auf dem neuesten Stand ist.
Deaktivieren Sie Pools und Cluster für die primäre Region, sodass diese nicht mit der Verarbeitung neuer Daten beginnt, wenn der ausgefallene Dienst wieder online geht.
Führen Sie den Wiederherstellungsvorgang für Ihre Datenquellen aus (siehe unten).
Starten Sie relevante Pools (oder erhöhen Sie die min_idle_instances Zahl auf eine relevante Zahl).
Starten Sie relevante Cluster, falls sie nicht bereits beendet sind.
Ändern Sie die parallele Ausführung für Jobs und führen Sie die entsprechenden Jobs aus. Das können einmalige Durchläufe oder regelmäßige Durchläufe sein.
Aktualisieren Sie für alle externen Tools, die eine URL oder einen Domänennamen für Ihren Azure Databricks-Arbeitsbereich verwenden, die Konfigurationen, um die neue Steuerungsebene zu berücksichtigen. Aktualisieren Sie beispielsweise URLs für REST-APIs und JDBC-/ODBC-Verbindungen. Die kundenorientierte URL der Azure Databricks-Webanwendung ändert sich, wenn sich die Steuerungsebene ändert. Benachrichtigen Sie daher die Benutzer Ihrer Organisation über die neue URL.

Details des Wiederherstellungsvorgangs

Überprüfen Sie das Datum der letzten synchronisierten Daten. Siehe Terminologie der Notfallwiederherstellung. Die Details dieses Schritts variieren je nachdem, wie Sie Daten und Ihre individuellen Geschäftsanforderungen synchronisieren.
Stabilisieren Sie Ihre Datenquellen, und stellen Sie sicher, dass sie alle verfügbar sind. Schließen Sie alle externen Datenquellen wie Azure Cloud SQL sowie Ihren Delta Lake, Parquet oder andere Dateien ein.
Finden Sie Ihren Wiederherstellungspunkt für Streaming. Richten Sie den Prozess ein, um von dort aus neu zu starten, und haben Sie einen Prozess bereit, potenzielle Duplikate zu identifizieren und zu beseitigen (Delta Lake erleichtert dies).
Schließen Sie den Datenflussprozess ab, und informieren Sie die Benutzer.

Testwiederherstellung (Failback)

Das Failback ist einfacher zu steuern und kann in einem Wartungsfenster ausgeführt werden. Planen Sie einige oder alle der folgenden Schritte:

Erhalten Sie eine Bestätigung, dass die primäre Region wiederhergestellt wurde.
Deaktivieren Sie Pools und Cluster in der sekundären Region, damit keine neuen Daten verarbeitet werden.
Synchronisieren Sie alle neuen oder geänderten Ressourcen im sekundären Arbeitsbereich mit der primären Bereitstellung. Je nach Entwurf Ihrer Failoverskripts können Sie möglicherweise dieselben Skripts ausführen, um Objekte aus der sekundären Region (DR) mit der primären Region (Produktionsregion) zu synchronisieren.
Synchronisieren Sie alle neuen Datenaktualisierungen zurück zur primären Bereitstellung. Sie können die Überwachungspfade von Protokollen und Delta-Tabellen verwenden, um keinen Datenverlust zu gewährleisten.
Beenden Sie alle Workloads in der DR-Region.
Ändern Sie die URL für Jobs und Benutzer auf die primäre Region, und verweisen Sie nachgelagerte Verbindungen (BI-Tools, Scheduler, Integrationen von Drittanbietern) wieder auf diese zurück.
Führen Sie Tests aus, um sicherzustellen, dass die Plattform auf dem neuesten Stand ist.
Starten Sie relevante Pools (oder erhöhen Sie die min_idle_instances Zahl auf eine relevante Zahl).
Starten Sie relevante Cluster, falls sie nicht bereits beendet sind.
Ändern Sie die gleichzeitige Ausführung von Jobs und führen Sie relevante Jobs aus. Das können einmalige Durchläufe oder regelmäßige Durchläufe sein.
Richten Sie bei Bedarf ihre sekundäre Region für zukünftige DR-Dateien erneut ein.

Automatisierungsskripts, Beispiele und Prototypen

Für AWS und Azure behandelt die verwaltete Notfallwiederherstellung Arbeitsbereiche und die Replikation von verwalteten Tabellen ohne benutzerdefinierte Automatisierung. Die folgenden Verweise gelten nur, wenn Sie eine DIY-Lösung außerhalb des Bereichs verwalteter DR erstellen.

Verwenden Sie für DIY-DR-Pipelines den Databricks Terraform-Anbieter , um Arbeitsbereichsressourcen als Code zu verwalten und für primäre und sekundäre Regionen gemeinsam bereitzustellen.

Wenn Sie Azure Databricks von Azure Data Factory koordinieren, replizieren Sie die relevanten ADF-Pipelines, sodass sie auf einen verknüpften Dienst verweisen, der dem sekundären Arbeitsbereich zugeordnet ist.

Zusätzliche Ressourcen

Feedback

War diese Seite hilfreich?

Last updated on 2026-06-24