Bereitstellen von Azure Databricks in Ihrem virtuellen Azure-Netzwerk (VNET-Einschleusung)

  • Artikel

In diesem Artikel wird beschrieben, wie Sie einen Azure Databricks-Arbeitsbereich in Ihrem eigenen virtuellen Azure-Netzwerk bereitstellen, auch bekannt als VNet-Einschleusung.

Netzwerkanpassung mit VNet-Einschleusung

Bei der Standardbereitstellung von Azure Databricks handelt es sich um einen vollständig verwalteten Dienst in Azure. Ein virtuelles Azure-Netzwerk (VNet) wird in einer gesperrten Ressourcengruppe bereitgestellt. Alle klassischen Computeebenenressourcen sind diesem VNet zugeordnet. Falls eine Netzwerkanpassung erforderlich ist, können Sie die klassischen Computeebenenressourcen für Azure Databricks in Ihrem eigenen virtuellen Netzwerk bereitstellen. Hierdurch wird Folgendes ermöglicht:

Wenn Sie Azure Databricks-Compute-Ebenenressourcen in Ihrem eigenen VNet bereitstellen, können Sie auch flexible CIDR-Bereiche nutzen. Für das VNet können Sie die CIDR-Bereichsgröße /16-/24 verwenden. Verwenden Sie für die Subnetze kleine IP-Bereiche wie /26.

Wichtig

Das VNet für einen vorhandenen Arbeitsbereich kann nicht ersetzt werden. Sollte Ihr aktueller Arbeitsbereich für die erforderliche Anzahl aktiver Clusterknoten zu klein sein, empfiehlt es sich, einen weiteren Arbeitsbereich in einem größeren VNET zu erstellen. Führen Sie diese detaillierten Migrationsschritte aus, um Ressourcen (Notebooks, Clusterkonfigurationen, Aufträge) aus dem alten Arbeitsbereich in den neuen zu kopieren.

Anforderungen für virtuelle Netzwerke

Das VNet, in dem Sie Ihren Azure Databricks-Arbeitsbereich bereitstellen, muss die folgenden Anforderungen erfüllen:

  • Region: Das VNet muss sich in derselben Region und demselben Abonnement wie der Azure Databricks-Arbeitsbereich befinden.
  • Abonnement: Das VNet muss sich im selben Abonnement wie der Azure Databricks-Arbeitsbereich befinden.
  • Adressraum: Es muss ein CIDR-Block zwischen /16 und /24 für das VNet verwendet werden und ein CIDR-Block bis /26 für die zwei Subnetze: ein Containersubnetz und ein Hostsubnetz. Einen Leitfaden zur maximalen Anzahl von Clusterknoten basierend auf der Größe Ihres VNet und der Subnetze finden Sie unter Adressraum und maximale Anzahl von Clusterknoten.
  • Subnetze: Das VNet muss zwei dedizierte Subnetze für Ihren Azure Databricks-Arbeitsbereich enthalten: ein Containersubnetz (auch als privates Subnetz bezeichnet) und ein Hostsubnetz (auch als öffentliches Subnetz bezeichnet). Wenn Sie einen Arbeitsbereich bereitstellen, der die Konnektivität für sichere Cluster (Secure Cluster Connectivity, SCC) nutzt, verwenden sowohl das Containersubnetz als auch das Hostsubnetz private IP-Adressen. Die arbeitsbereichsübergreifende gemeinsame Nutzung von Subnetzen oder die Bereitstellung anderer Azure-Ressourcen in den von Ihrem Azure Databricks-Arbeitsbereich verwendeten Subnetzen ist nicht möglich. Einen Leitfaden zur maximalen Anzahl von Clusterknoten basierend auf der Größe Ihres VNet und der Subnetze finden Sie unter Adressraum und maximale Anzahl von Clusterknoten.

Adressraum und maximale Anzahl von Clusterknoten

Bei einem Arbeitsbereich mit einem kleineren virtuellen Netzwerk können schneller keine IP-Adressen (Netzwerkadressraum) mehr verfügbar sein als bei einem Arbeitsbereich mit einem größeren virtuellen Netzwerk. Verwenden Sie einen CIDR-Block zwischen /16 und /24 für das VNet und einen CIDR-Block bis /26 für die zwei Subnetze (Containersubnetz und Hostsubnetz). Sie können einen CIDR-Block bis /28 für Ihre Subnetze erstellen, Databricks empfiehlt jedoch kein kleineres Subnetz als /26.

Der CIDR-Bereich für Ihren VNet-Adressraum wirkt sich auf die maximale Anzahl von Clusterknoten aus, die Ihr Arbeitsbereich verwenden kann.

Ein Azure Databricks-Arbeitsbereich erfordert zwei Subnetze im VNet: ein Containersubnetz und ein Hostsubnetz. Azure reserviert fünf IP-Adressen in jedem Subnetz. Azure Databricks erfordert zwei IP-Adressen für jeden Clusterknoten: eine IP-Adresse für den Host im Hostsubnetz und eine IP-Adresse für den Container im Containersubnetz.

  • Möglicherweise möchten Sie nicht den gesamten Adressraum Ihres VNet verwenden. Sie können beispielsweise mehrere Arbeitsbereiche in einem VNet erstellen. Da Sie Subnetze nicht arbeitsbereichsübergreifend freigeben können, möchten Sie vielleicht Subnetze einrichten, die nicht den gesamten VNet-Adressraum verwenden.
  • Sie müssen einen Adressraum für zwei neue Subnetze zuordnen, die sich innerhalb des Adressraums des VNet befinden und sich nicht mit dem Adressraum aktueller oder zukünftiger Subnetze in diesem VNet überlappen.

In der folgenden Tabelle ist die maximale Subnetzgröße basierend auf der Netzwerkgröße aufgeführt. Die Angaben in dieser Tabelle setzen voraus, dass keine zusätzlichen Subnetze vorhanden sind, die Adressraum in Anspruch nehmen. Verwenden Sie kleinere Subnetze, wenn Sie bereits über Subnetze verfügen oder Adressraum für andere Subnetze reservieren möchten:

VNet-Adressraum (CIDR) Maximale Azure Databricks-Subnetzgröße (CIDR), wenn keine anderen Subnetze vorhanden sind
/16 /17
/17 /18
/18 /19
/20 /21
/21 /22
/22 /23
/23 /24
/24 /25

Verwenden Sie die folgende Tabelle, um die maximale Anzahl von Clusterknoten basierend auf der Subnetzgröße zu ermitteln. Der Wert in der Spalte „IP-Adressen pro Subnetz“ beinhaltet die fünf von Azure reservierten IP-Adressen. Die Spalte ganz rechts gibt die Anzahl von Clusterknoten an, die in einem mit Subnetzen dieser Größe bereitgestellten Arbeitsbereich gleichzeitig ausgeführt werden können.

Subnetzgröße (CIDR) IP-Adressen pro Subnetz Maximale Anzahl von Azure Databricks-Clusterknoten
/17 32768 32.763
/18 16384 16.379
/19 8192 8187
/20 4096 4091
/21 2048 2.043
/22 1024 1019
/23 512 507
/24 256 251
/25 128 123
/26 64 59

Ausgehende IP-Adressen bei Verwendung der sicheren Clusterkonnektivität

Wenn Sie sichere Clusterkonnektivität in Ihrem Arbeitsbereich aktivieren, in dem VNet-Einfügung verwendet wird, empfiehlt Databricks, dass Ihr Arbeitsbereich über eine stabile öffentliche IP-Adresse verfügt.

Stabile öffentliche IP-Adressen sind nützlich, da Sie sie externen Zulassungslisten hinzufügen können. Um beispielsweise eine Verbindung von Azure Databricks mit Salesforce mit einer stabilen ausgehenden IP-Adresse herzustellen.

Warnung

Microsoft hat angekündigt, dass am 30. September 2025 die standardmäßige ausgehende Zugriffskonnektivität für virtuelle Computer in Azure eingestellt wird. Sehen Sie sich diese Ankündigung an. Dies bedeutet, dass Azure Databricks-Arbeitsbereiche, die standardmäßigen ausgehenden Zugriff, statt einer stabilen öffentlichen IP-Adresse verwenden, nach diesem Datum möglicherweise nicht mehr funktionieren. Databricks empfiehlt, vor diesem Datum explizite ausgehende Methoden für Ihre Arbeitsbereiche hinzuzufügen.

Informationen zum Konfigurieren einer stabilen öffentlichen IP-Adresse für den Ausgang finden Sie unter Ausgehend mit VNET-Einschleusung.

Freigegebene Ressourcen und Peering

Wenn freigegebene Netzwerkressourcen wie DNS erforderlich sind, empfiehlt Databricks dringend, die bewährten Azure-Methoden für das Hub and Spoke-Modell zu befolgen. Verwenden Sie VNet-Peering, um den privaten IP-Bereich des Arbeitsbereichs-VNet auf den Hub zu erweitern, während Spokes voneinander isoliert bleiben.

Wenn Sie über andere Ressourcen im VNet verfügen oder Peering verwenden, empfiehlt Databricks dringend, den Netzwerksicherheitsgruppen (NSGs) Verweigerungsregeln hinzuzufügen, die an andere Netzwerke und Subnetze angefügt sind, die sich im selben VNet befinden oder über ein Peering mit diesem VNet verfügen. Fügen Sie Verweigerungsregeln für Verbindungen sowohl für eingehende als auch für ausgehende Verbindungen hinzu, sodass sie Verbindungen sowohl zu als auch von Azure Databricks-Computeressourcen beschränken. Wenn Ihr Cluster Zugriff auf Ressourcen im Netzwerk benötigt, fügen Sie Regeln hinzu, um nur den minimalen Zugriff zu ermöglichen, der für die Erfüllung der Anforderungen erforderlich ist.

Verwandte Informationen finden Sie unter Regeln für Netzwerksicherheitsgruppen.

Erstellen eines Azure Databricks-Arbeitsbereichs im Azure-Portal

In diesem Abschnitt wird beschrieben, wie Sie einen Azure Databricks-Arbeitsbereich im Azure-Portal erstellen und in Ihrem eigenen vorhandenen VNet bereitstellen. Azure Databricks aktualisiert das VNet mit zwei neuen Subnetzen, sofern diese noch nicht vorhanden sind, und verwendet dabei die von Ihnen angegebenen CIDR-Bereiche. Der Dienst aktualisiert die Subnetze zudem mit einer neuen Netzwerksicherheitsgruppe, konfiguriert dabei Ein- und Ausgangsregeln und stellt zum Schluss den Arbeitsbereich im aktualisierten VNet bereit. Wenn Sie die Konfiguration des VNet umfassender steuern möchten, verwenden Sie von Azure Databricks bereitgestellte Azure Resource Manager (ARM)-Vorlagen anstelle des Portals. Sie können beispielsweise vorhandene Netzwerksicherheitsgruppen verwenden oder eigene Sicherheitsregeln erstellen. Weitere Informationen finden Sie unter Erweiterte Konfiguration mithilfe von Azure Resource Manager-Vorlagen.

Dem Benutzer, der den Arbeitsbereich erstellt, muss die Rolle „Netzwerkmitwirkender“ für das entsprechende virtuelle Netzwerk oder eine benutzerdefinierte Rolle mit den zugeordneten Berechtigungen Microsoft.Network/virtualNetworks/subnets/join/action und Microsoft.Network/virtualNetworks/subnets/write zugewiesen sein.

Sie müssen ein VNet konfigurieren, in dem Sie den Azure Databricks-Arbeitsbereich bereitstellen. Sie können ein vorhandenes VNet verwenden oder ein neues erstellen, das VNet muss sich jedoch in der gleichen Region und im gleichen Abonnement befinden wie der Azure Databricks-Arbeitsbereich, den Sie erstellen möchten. Der CIDR-Bereich des VNet muss zwischen /16 und /24 liegen. Weitere Anforderungen finden Sie unter Anforderungen für virtuelle Netzwerke.

Beim Konfigurieren Ihres Arbeitsbereichs können Sie entweder vorhandene Subnetze verwenden oder Namen und IP-Adressbereiche für neue Subnetze angeben.

  1. Wählen Sie im Azure-Portal + Ressource erstellen > Analytics > Azure Databricks aus, oder suchen Sie nach Azure Databricks, und klicken Sie auf Erstellen oder + Hinzufügen, um das Dialogfeld „Azure Databricks-Dienst“ zu öffnen.

  2. Führen Sie die Konfigurationsschritte unter Schnellstart: Erstellen eines Azure Databricks-Arbeitsbereichs in Ihrem eigenen virtuellen Netzwerk aus.

  3. Wählen Sie auf der Registerkarte Netzwerk im Feld Virtuelles Netzwerk das gewünschte VNet aus.

    Wichtig

    Falls der Netzwerkname nicht in der Auswahl angezeigt wird, vergewissern Sie sich, dass die Azure-Region, die Sie für den Arbeitsbereich angegeben haben, der Azure-Region des gewünschten VNet entspricht.

    Virtuelles Netzwerk auswählen

  4. Geben Namen für Ihre Subnetze und CIDR-Bereiche in einem Block mit einer Größe bis /26 an. Einen Leitfaden zur maximalen Anzahl von Clusterknoten basierend auf der Größe Ihres VNet und der Subnetze finden Sie unter Adressraum und maximale Anzahl von Clusterknoten. Die CIDR-Bereiche des Subnetzes können nach der Bereitstellung des Arbeitsbereichs nicht mehr geändert werden.

    • Wenn Sie vorhandene Subnetze verwenden, geben Sie die genauen Namen dieser Subnetze an. Geben Sie in diesem Fall im Formular für die Arbeitsbereichserstellung auch die genauen IP-Adressbereiche der vorhandenen Subnetze an.
    • Wenn Sie neue Subnetze erstellen, geben Sie Subnetznamen an, die noch nicht in diesem VNet vorhanden sind. Die Subnetze werden mit den angegebenen IP-Adressbereichen erstellt. Sie müssen IP-Adressbereiche innerhalb des IP-Adressbereichs Ihres VNet angeben, die noch keinen vorhandenen Subnetzen zugeordnet sind.

    In Azure Databricks dürfen Subnetznamen nicht länger als 80 Zeichen sein.

    Den Subnetzen werden Netzwerksicherheitsgruppen-Regeln zugeordnet, die die Regel zum Zulassen der clusterinternen Kommunikation beinhalten. Azure Databricks verfügt über delegierte Berechtigungen zum Aktualisieren beider Subnetze über den Ressourcenanbieter Microsoft.Databricks/workspaces. Diese Berechtigungen gelten nur für Netzwerksicherheitsgruppen-Regeln, die für Azure Databricks erforderlich sind. Sie gelten nicht für andere Netzwerksicherheitsgruppen-Regeln, die Sie hinzufügen, oder für die Standardregeln, die in allen Netzwerksicherheitsgruppen enthalten sind.

  5. Klicken Sie auf Erstellen, um den Azure Databricks-Arbeitsbereich im VNet bereitzustellen.

Erweiterte Konfiguration mithilfe von Azure Resource Manager-Vorlagen

Wenn Sie die Konfiguration des VNet umfassender steuern möchten, können Sie anstelle der automatischen VNet-Konfiguration und Arbeitsbereichsbereitstellung über die Portalbenutzeroberfläche die folgenden Azure Resource Manager (ARM)-Vorlagen verwenden. Sie können beispielsweise vorhandene Subnetze und eine vorhandene Netzwerksicherheitsgruppe verwenden oder eigene Sicherheitsregeln hinzufügen.

Wenn Sie eine benutzerdefinierte Azure Resource Manager-Vorlage oder die Arbeitsbereichsvorlage für die Azure Databricks-VNet-Injektion verwenden, um einen Arbeitsbereich in einem vorhandenen VNet bereitzustellen, müssen Sie Host- und Containersubnetze erstellen, eine Netzwerksicherheitsgruppe an jedes Subnetz anfügen und die Subnetze an den Ressourcenanbieter Microsoft.Databricks/workspaces delegieren, bevor Sie den Arbeitsbereich bereitstellen. Für jeden Arbeitsbereich, den Sie bereitstellen, benötigen Sie ein separates Paar von Subnetzen.

All-in-One-Vorlage

Um ein VNet und einen Azure Databricks-Arbeitsbereich mit einer einzigen Vorlage zu erstellen, verwenden Sie die All-in-One-Vorlage für Azure Databricks-Arbeitsbereiche mit VNet-Injektion.

Vorlage für virtuelle Netzwerke

Um ein VNet mit den richtigen Subnetzen mithilfe einer Vorlage zu erstellen, verwenden Sie die VNet-Vorlage für die Databricks-VNet-Injektion.

Azure Databricks-Arbeitsbereichsvorlage

Um einen Azure Databricks-Arbeitsbereich in einem vorhandenen VNet mithilfe einer Vorlage bereitzustellen, verwenden Sie die Arbeitsbereichsvorlage für die Azure Databricks-VNet-Injektion.

In der Arbeitsbereichsvorlage können Sie ein vorhandenes VNet angeben und vorhandene Subnetze verwenden:

  • Für jeden Arbeitsbereich, den Sie bereitstellen, benötigen Sie ein separates Paar von Host-/Containersubnetzen. Die arbeitsbereichsübergreifende Freigabe von Subnetzen oder Bereitstellung anderer Azure-Ressourcen in den von Ihrem Azure Databricks-Arbeitsbereich verwendeten Subnetzen wird nicht unterstützt.
  • Die Host- und Containersubnetze Ihres VNet müssen über angefügte Netzwerksicherheitsgruppen verfügen und an den Dienst Microsoft.Databricks/workspaces delegiert worden sein, bevor Sie diese Azure Resource Manager-Vorlage zum Bereitstellen eines Arbeitsbereichs verwenden.
  • Verwenden Sie zum Erstellen eines VNet mit korrekt delegierten Subnetzen die VNet-Vorlage für die Databricks-VNet-Injektion.
  • Informationen zur Verwendung eines vorhandenen VNet ohne vorherige Delegierung der Host- und Containersubnetze finden Sie unter Hinzufügen oder Entfernen einer Subnetzdelegierung.

Netzwerksicherheitsgruppen-Regeln

In den folgenden Tabellen sind die aktuellen Netzwerksicherheitsgruppen-Regeln aufgeführt, die von Azure Databricks verwendet werden. Wenn Azure Databricks eine Regel hinzufügen oder den Bereich einer vorhandenen Regel in dieser Liste ändern muss, werden Sie vorab benachrichtigt. Dieser Artikel und die Tabellen werden bei jeder Änderung dieser Art aktualisiert.

Verwaltung von Netzwerksicherheitsgruppen-Regeln durch Azure Databricks

Die in den folgenden Abschnitten genannten Netzwerksicherheitsgruppen (NSG)-Regeln stellen die Regeln dar, die Azure Databricks aufgrund der Delegierung der Host- und Containersubnetze Ihres VNet an den Dienst Microsoft.Databricks/workspaces automatisch in Ihrer NSG bereitstellt und verwaltet. Sie sind nicht berechtigt, diese NSG-Regeln zu aktualisieren oder zu löschen. Diese Vorgänge werden durch die Subnetzdelegierung blockiert. Azure Databricks muss der Besitzer dieser Regeln sein, damit Microsoft den Azure Databricks-Dienst in Ihrem VNet zuverlässig ausführen und unterstützen kann.

Einigen dieser NSG-Regeln ist VirtualNetwork als Quelle und Ziel zugewiesen. Diese Zuweisung wurde implementiert, um den Entwurf zu vereinfachen, wenn kein Diensttag auf Subnetzebene in Azure vorhanden ist. Alle Cluster sind intern durch eine zweite Ebene von Netzwerkrichtlinien geschützt, sodass Cluster A keine Verbindung mit Cluster B im selben Arbeitsbereich herstellen kann. Dies gilt auch für mehrere Arbeitsbereiche, wenn diese in einem anderen Subnetzpaar im gleichen vom Kunden verwalteten VNet bereitgestellt werden.

Wichtig

Databricks empfiehlt dringend, den Netzwerksicherheitsgruppen (NSGs) Verweigerungsregeln hinzuzufügen, die an andere Netzwerke und Subnetze angefügt sind, die sich im selben VNet befinden oder über ein Peering mit diesem VNet verfügen. Fügen Sie Verweigerungsregeln für Verbindungen sowohl für eingehende als auch für ausgehende Verbindungen hinzu, sodass sie Verbindungen sowohl zu als auch vonAzure Databricks-Computeressourcen beschränken. Wenn Ihr Cluster Zugriff auf Ressourcen im Netzwerk benötigt, fügen Sie Regeln hinzu, um nur den minimalen Zugriff zu ermöglichen, der für die Erfüllung der Anforderungen erforderlich ist.

Regeln der Netzwerksicherheitsgruppe für Arbeitsbereiche

Die Informationen in diesem Abschnitt gelten nur für Azure Databricks-Arbeitsbereiche, die nach dem 13. Januar 2020 erstellt wurden. Wenn Ihr Arbeitsbereich vor der Veröffentlichung der Konnektivität für sichere Cluster (Secure Cluster Connectivity, SCC) am 13. Januar 2020 erstellt wurde, beziehen Sie sich auf den nächsten Abschnitt.

Diese Tabelle führt die Regeln der Netzwerksicherheitsgruppe für Arbeitsbereiche auf und umfasst zwei Sicherheitsgruppenregeln für eingehenden Datenverkehr auf, die nur enthalten sind, wenn die Konnektivität für sichere Cluster (SCC) deaktiviert ist.

Direction Protocol `Source` Quellport Ziel Dest Port Verwendet
Eingehend Beliebig VirtualNetwork Beliebig VirtualNetwork Beliebig Standard
Eingehend TCP AzureDatabricks (Diensttag)
Nur wenn SCC deaktiviert ist		 Beliebig VirtualNetwork 22 Öffentliche IP-Adresse
Eingehend TCP AzureDatabricks (Diensttag)
Nur wenn SCC deaktiviert ist		 Beliebig VirtualNetwork 5557 Öffentliche IP-Adresse
Ausgehend TCP VirtualNetwork Beliebig AzureDatabricks (Diensttag) 443, 3306, 8443-8451 Standard
Ausgehend TCP VirtualNetwork Beliebig SQL 3306 Standard
Ausgehend TCP VirtualNetwork Beliebig Storage 443 Standard
Ausgehend Beliebig VirtualNetwork Beliebig VirtualNetwork Beliebig Standard
Ausgehend TCP VirtualNetwork Beliebig EventHub 9093 Standard

Hinweis

Wenn Sie Ausgangsregeln einschränken, empfiehlt Databricks, die Ports 111 und 2049 zu öffnen, um bestimmte Bibliotheksinstallationen zu ermöglichen.

Wichtig

Azure Databricks ist ein Erstanbieterdienst von Microsoft Azure, der in der öffentlichen Global Azure-Cloudinfrastruktur bereitgestellt wird. Die gesamte Kommunikation zwischen den Dienstkomponenten einschließlich der zwischen den öffentlichen IP-Adressen in der Steuerungsebene und der Kundencomputeebene verbleibt im Netzwerkbackbone von Microsoft Azure. Siehe auch Globales Microsoft-Netzwerk.

Problembehandlung

Fehler beim Erstellen des Arbeitsbereichs

Das Subnetz „<subnet-id>“ erfordert eine der folgenden Delegierungen [Microsoft.Databricks/workspaces], um auf den Dienstzuordnungslink zu verweisen.

Mögliche Ursache: Sie erstellen einen Arbeitsbereich in einem VNet, dessen Host- und Containersubnetze nicht an den Dienst Microsoft.Databricks/workspaces delegiert wurden. Jedes Subnetz muss über eine angefügte Netzwerksicherheitsgruppe verfügen und korrekt delegiert werden. Weitere Informationen finden Sie unter Anforderungen für virtuelle Netzwerke.

Das Subnetz „<subnet-id>“ wird bereits vom Arbeitsbereich „<workspace-id>“ verwendet.

Mögliche Ursache: Sie erstellen einen Arbeitsbereich in einem VNet mit Host- und Containersubnetzen, die bereits von einem vorhandenen Azure Databricks-Arbeitsbereich verwendet werden. Es ist nicht möglich, mehrere Arbeitsbereiche in einem einzelnen Subnetz freizugeben. Für jeden Arbeitsbereich, den Sie bereitstellen, ist ein neues Paar von Host- und Containersubnetzen erforderlich.

Problembehandlung

Die Instanzen ist nicht erreichbar: Ressourcen sind über SSH nicht erreichbar.

Mögliche Ursache: Datenverkehr von der Steuerungsebene zum Worker wird blockiert. Wenn Sie die Bereitstellung in einem vorhandenen VNet vornehmen, das mit Ihrem lokalen Netzwerk verbunden ist, überprüfen Sie die Konfiguration anhand der Informationen unter Verbinden des Azure Databricks-Arbeitsbereichs mit Ihrem lokalen Netzwerk.

Unerwarteter Startfehler: Beim Einrichten des Clusters ist ein unerwarteter Fehler aufgetreten. Versuchen Sie es erneut, und kontaktieren Sie Azure Databricks, wenn das Problem weiterhin besteht. Meldung zu internem Fehler: Timeout while placing node.

Mögliche Ursache: Datenverkehr vom Worker zu Azure Storage-Endpunkten wird blockiert. Wenn Sie benutzerdefinierte DNS-Server verwenden, überprüfen Sie auch den Status der DNS-Server in Ihrem VNet.

Startfehler des Cloudanbieters: Beim Einrichten des Clusters ist ein Fehler des Cloudanbieters aufgetreten. Weitere Informationen finden Sie im Azure Databricks-Handbuch. Azure-Fehlercode: AuthorizationFailed/InvalidResourceReference.

Mögliche Ursache: Das VNet oder die Subnetze sind nicht mehr vorhanden. Stellen Sie sicher, dass das VNet und die Subnetze vorhanden sind.

Cluster wurde beendet. Ursache: Spark-Startfehler: Spark konnte nicht rechtzeitig gestartet werden. Dieses Problem kann durch einen fehlerhaften Hive-Metastore, ungültige Spark-Konfigurationen oder fehlerhafte Init-Skripte verursacht werden. Siehe die Spark-Treiberprotokolle, um dieses Problem zu beheben, und wenden Sie sich an Databricks, wenn das Problem weiterhin besteht. Meldung zu internem Fehler: Spark failed to start: Driver failed to start in time.

Mögliche Ursache: Der Container kann nicht mit der Hosting-Instanz oder dem DBFS-Speicherkonto kommunizieren. Beheben Sie das Problem, indem Sie eine benutzerdefinierte Route zu den Subnetzen für das DBFS-Speicherkonto hinzufügen, wobei der nächste Hop das Internet ist.