Bewährte Methoden für benutzerdefiniertes DNS für virtuelle Netzwerke von Azure-Databricks-Arbeitsbereichen

Wenn Sie einen Azure Databricks-Arbeitsbereich in Ihrem eigenen virtuellen Netzwerk (VNet-Injection) bereitstellen, können Sie das VNet so konfigurieren, dass es benutzerdefinierte DNS-Server anstelle des von Azure bereitgestellten DNS verwendet. Benutzerdefiniertes DNS ist üblich, wenn ein Arbeitsbereich On-Premises-Hostnamen auflösen, einen zentralen DNS-Forwarder in einer Hub-and-Spoke-Topologie verwenden oder DNS-Filterung auf DNS-Ebene anwenden muss.

Custom DNS gibt dir die Kontrolle über die Namensauflösung, macht aber auch die Namensauflösung zu deiner eigenen Verantwortung. Wenn Ihre benutzerdefinierten DNS-Server die von Classic-Compute benötigten Namen nicht auflösen können, können Cluster nicht gestartet werden und verlieren die ausgehende Konnektivität zu externen Datenquellen und Repositorys für Bibliotheken. Dieser Artikel beschreibt die empfohlene benutzerdefinierte DNS-Konfiguration für VNet-injizierte Arbeitsbereiche, die häufigsten Fehlkonfigurationen und deren Fehlerbehebung.

Wie Azure Databricks DNS in einem VNet-injizierten Arbeitsbereich verwendet

Klassische Compute-Knoten laufen in den (privaten) Container- und Host-(öffentlichen) Subnetzen Ihres VNet. Während des Clusterstarts und -betriebs müssen diese Knoten mehrere Azure Databricks- und Azure-Endpunkte auflösen und erreichen. Wenn die sichere Clusterverbindung (SCC) aktiviert ist, öffnet jeder Cluster während der Clustererstellung eine ausgehende Verbindung zum SCC-Relais in der Kontrollebene, sodass die Namensauflösung erfolgreich sein muss, bevor ein Cluster gestartet werden kann.

Die Endpunkte, von denen die klassische Berechnung abhängt, umfassen:

Die klassische Compute-Umgebung erreicht die Steuerungsebene und die Webanwendung über regionale IP-Adressbereiche anstelle eines kundenorientierten Hostnamens; daher empfiehlt Azure Databricks, diese Bereiche mithilfe des AzureDatabricks-Diensttags in Ihren Routentabellen, Netzwerksicherheitsgruppen oder Ihrer Firewall auf die Zulassungsliste (Allowlist) zu setzen. Einige Firewalls, wie Palo Alto, können keine Azure-Service-Tags verwenden. Auf diesen listen Sie stattdessen die zugrunde liegenden IP-Bereiche aus der Referenzliste auf.

Das Service-Tag AzureDatabricks deckt bereits das SCC-Relais ab. Wenn Sie bestimmte IP-Adressen anstelle des Servicetags zulassen, lassen Sie das SCC-Relais nach seinem FQDN zuweisen, da sich die dahinterliegenden IP-Adressen ändern. Einige Regionen übergehen zu einer sekundären Region, sodass die Referenzliste mehr als einen tunnel FQDN für eine Region anzeigen kann. Alle auf die Positivliste setzen. Die Metastore-, Speicher- und Event Hubs-Endpunkte gehören zu anderen Azure-Diensten mit eigenen Service-Tags, wie Sql, Storage, und EventHub. Für die vollständige, regionsspezifische Liste von Adressen und FQDNs siehe Metastore, Artefakt-Blob-Speicher, Systemtabellen-Speicher, Log-Blob-Speicher und Event-Hubs-Endpunkt-IP-Adressen.

Empfohlene benutzerdefinierte DNS-Konfiguration

Deine benutzerdefinierten DNS-Server müssen nicht jeden Azure- und öffentlichen Namen selbst auflösen. Das empfohlene Muster ist, die Namen aufzulösen, die Sie besitzen, und alles andere an Azure weiterzuleiten.

Nicht aufgelöste Abfragen an Azure DNS weiterleiten

Konfigurieren Sie Ihre benutzerdefinierten DNS-Server so, dass sie die Namen, die sie nicht auflösen können, bedingt an den von Azure bereitgestellten DNS-Resolver an der virtuellen IP-Adresse 168.63.129.16weiterleiten. Azure DNS löst die Azure Databricks Control Plane, Storage, Metastore und andere Azure-Servicenamen für Sie auf und funktioniert weiterhin, wenn sich diese Adressen ändern.

Mindestens leite die folgenden Domänen bedingt an Azure DNS weiter und leite alle Speicher- und Azure-Servicedomänen weiter, die deine Arbeitslasten nutzen:

• *.azuredatabricks.net
• *.privatelink.azuredatabricks.net
• *.databricksapps.com

Private Link-Endpunkte auflösen

Wenn Ihr Arbeitsbereich Azure Private Link für die klassische Compute-Plane-Verbindung verwendet, muss die Namensauflösung die IP-Adressen des privaten Endpunkts anstelle der öffentlichen Adressen zurückgeben. Azure erstellt die private DNS-Zone privatelink.azuredatabricks.net und fügt Adresseinträge für Ihre Arbeitsbereichs-Endpunkte hinzu, einschließlich des databricks_ui_api Endpunkts und des Endpunkts, der browser_authentication für Single Sign-on verwendet wird. Der Browser-Authentifizierungseintrag verwendet das Format pl-auth.<region>.

Wenn ein Arbeitsbereich benutzerdefiniertes DNS verwendet, senden seine klassischen Rechenknoten DNS-Abfragen an Ihre eigenen DNS-Server statt an Azure DNS. Eine private DNS-Zone, die mit einem VNet verknüpft ist, wird nur über den von Azure bereitgestellten Resolver bei 168.63.129.16 abgefragt; daher liefert die bloße Verknüpfung der Zone keine privaten Endpunktadressen an Compute-Ressourcen zurück, die einen benutzerdefinierten Resolver abfragen. Beide folgenden Voraussetzungen sind erforderlich:

• Verknüpfe die privatelink.azuredatabricks.net private DNS-Zone mit dem VNet, in dem Azure DNS die Anfrage löst: deinem Arbeitsbereich-VNet oder dem Hub-VNet, das deinen Resolver in einer Hub-and-Spoke-Topologie hostet. Dadurch erhalten Azure DNS die privaten Endpunktadressdatensätze, die zurückgegeben werden sollen.
• Konfigurieren Sie Ihre benutzerdefinierten DNS-Server so, dass sie *.privatelink.azuredatabricks.net und *.azuredatabricks.net bedingt an Azure DNS unter 168.63.129.16 weiterleiten. Weiterleitung sendet die Anfrage in die verknüpfte private DNS-Zone. In einer Hub-and-Spoke-Topologie an den zentralen Resolver weiterleiten, der Azure DNS erreicht.

Wenn die private DNS-Zone nicht verknüpft ist oder verknüpft ist, aber der Adresseintrag eines Endpunkts fehlt, greift Azure DNS auf öffentliche Rekursion zurück und gibt die öffentliche IP-Adresse des Endpunkts zurück. Die Namensauflösung scheint erfolgreich zu sein, aber der Datenverkehr wird an den öffentlichen Endpunkt statt an den privaten Endpunkt geleitet. Bestätigen Sie, dass die verknüpfte Zone die erwarteten Adresseinträge für jeden privaten Endpunkt enthält, den der Arbeitsbereich verwendet.

Andere private Azure-Endpunkte, wie Speicher, verwenden eigene Azure-private DNS-Zonen, zum Beispiel privatelink.dfs.core.windows.net und privatelink.blob.core.windows.net. Wenden Sie dasselbe Muster an: Verknüpfen Sie diese Zonen und leiten Sie die entsprechenden privatelink Domänen bedingt an Azure DNS weiter, damit die verknüpften Zonen konsultiert werden. Die DNS-Integration eines privaten Endpunkts bietet je nach deiner Einrichtung mehrere Szenarien. Details finden Sie unter Azure Private Endpoint DNS Integration.

Die vollständige Front-End- und Back-End-Konfiguration für Private Link finden Sie unter Konfigurieren der klassischen Private Link-Konnektivität der Compute-Ebene zu Azure Databricks und Konfigurieren von eingehendem Private Link für Arbeitsbereiche.

Häufige benutzerdefinierte DNS-Fehlkonfigurationen

Die meisten benutzerdefinierten DNS-Supportfälle resultieren aus einer der folgenden Fehlkonfigurationen:

• Keine Weiterleitung zu Azure DNS. Benutzerdefinierte DNS-Server können die Azure Databricks Control Plane, Storage oder Metastore-Namen nicht lösen und leiten die Abfragen nicht an 168.63.129.16weiter. Cluster starten nicht oder erreichen nach dem Start den Speicher und den Metastore nicht.
• Fehlende Privates DNS-Zonenverbindung, Weiterleitung oder Datensätze. Der Arbeitsbereich verwendet Private Link, aber das VNet ist nicht mit der Zone privatelink.azuredatabricks.net verknüpft, leitet Abfragen nicht an Azure DNS weiter, oder in der verknüpften Zone fehlt der korrekte Adresseintrag für einen Endpunkt. Namen werden auf öffentliche IP-Adressen, die falsche Adresse oder gar nichts aufgelöst, sodass die private Verbindung ausfällt.
• Benutzerdefinierte DNS-Server nicht erreichbar. Die benutzerdefinierten DNS-Serveradressen auf dem VNet sind falsch, oder Netzwerkregeln verhindern, dass die Rechensubnetze sie erreichen, zum Beispiel wenn das Workspace-VNet nicht mit dem VNet gepeert ist, das deine eigenen eigenen DNS-Server hostet. Jede Namensauflösung schlägt fehl.
• On-premises-Resolver ohne Azure-Weiterleitung. DNS-Abfragen werden zu einem lokalen Resolver geleitet, der interne Namen auflöst, aber keine Azure-Namen auflösen oder weiterleiten kann. Fügen Sie bedingtes Weiterleitungsverfahren für die Azure- und Azure Databricks-Domänen hinzu.
• Blockierte Bibliotheks-Repositories. DNS löst die erforderlichen Azure Databricks-Endpunkte auf, aber nicht die öffentlichen Bibliotheks-Repositories, sodass Bibliotheksinstallationen von PyPI, Maven oder CRAN fehlschlagen.

Problembehebung von benutzerdefinierten DNS-Problemen

Wenn Cluster nicht starten oder die Verbindung verlieren, prüfen Sie die DNS-Auflösung eines Clusters.

1. Erstelle einen Cluster im Arbeitsbereich. Wenn der Cluster nicht startet und das Ereignisprotokoll einen Fehler wie Cluster terminated. Reason: Control Plane Request Failurezeigt, kann der Cluster die Steuerebene nicht erreichen, was oft ein Namensauflösungsproblem darstellt.

2. Aus einem Notebook auf einem laufenden Cluster lösen Sie einen erforderlichen Endpunkt auf, um zu bestätigen, dass Ihr benutzerdefinierter DNS die erwartete Adresse zurückgibt. Vergewissern Sie sich bei einem Private-Link-Arbeitsbereich, dass die URL des Arbeitsbereichs in die IP-Adresse des privaten Endpunkts und nicht in eine öffentliche Adresse aufgelöst wird.

   %sh
   nslookup adb-<workspace-id>.<n>.azuredatabricks.net
   nslookup tunnel.<region>.azuredatabricks.net
   

   Wenn Cluster überhaupt nicht starten können, zum Beispiel wegen eines Backend-Private Link-Problems, führen Sie diese Prüfungen aus einer Azure-VM im öffentlichen Subnetz des Arbeitsbereichs VNet aus, statt aus einem Notebook.

3. Wenn die Auflösung fehlschlägt oder die falsche Adresse zurückgegeben wird, überprüfen Sie Folgendes. Wenn ein Cluster aufgrund von DNS nicht starten kann, nennt das Cluster-Ereignisprotokoll die Netzwerk-Gesundheitsprüfung, die fehlgeschlagen ist, in Klammern dargestellt:

   • Die benutzerdefinierten DNS-Serveradressen des VNet sind korrekt, und die Rechensubnetze können diese Server erreichen (X_NHC_DNS_SERVER_UNREACHABLE).
   • Deine benutzerdefinierten DNS-Server leiten die Azure- und Azure-Databricks-Domänen per bedingter Weiterleitung an Azure DNS unter 168.63.129.16 weiter (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, wenn die Namen der Steuerungsebene oder des Artefaktspeichers nicht aufgelöst werden).
   • Für Private Link ist die privatelink.azuredatabricks.net Zone mit dem VNet verknüpft, in dem Azure DNS aufgelöst wird, deine benutzerdefinierten DNS-Server leiten die Azure Databricks-Domains an Azure DNS weiter, und die erwarteten Adresseinträge existieren (X_NHC_CONTROL_PLANE_HTTP_ERROR, wenn der private Endpunkt der Kontrollebene nicht aufgelöst wird).

4. Wenn Cluster starten, aber keine lokalen oder andere Azure Platform as a Service (PaaS)-Ressourcen erreichen, bestätigen Sie, dass benutzerdefinierte Routen für diese Ziele existieren, da Routing und DNS separat konfiguriert sind.

Wenn du das Problem immer noch nicht lösen kannst, kontaktiere deine Microsoft- und Azure Databricks-Kontoteams.

Weitere Ressourcen

• Stellen Sie Azure Databricks in Ihrem Azure-Virtuellen Netzwerk bereit (VNet-Injektion)
• Verbinden des Azure Databricks-Arbeitsbereichs mit Ihrem lokalen Netzwerk
• Benutzerdefinierte Routeneinstellungen für Azure Databricks
• Konfigurieren Sie die private Konnektivität der klassischen Berechnungsebene zu Azure Databricks.
• Die IP-Adressen von Metastore, Artefaktblobspeicher, Systemtabellenspeicher, Protokollblobspeicher und Event Hubs-Endpunkt