Aanbevolen procedures voor aangepaste DNS voor virtuele netwerken van Azure Databricks-werkruimten

Wanneer je een Azure Databricks-werkruimte in je eigen virtuele netwerk (VNet-injectie) deployt, kun je de VNet zo instellen dat deze aangepaste DNS-servers gebruikt in plaats van de door Azure geleverde DNS. Aangepaste DNS komt vaak voor wanneer een werkruimte on-premises hostnamen moet oplossen, een gecentraliseerde DNS-forwarder in een hub-and-spoke-topologie moet gebruiken, of DNS-niveau filtering moet toepassen.

Aangepaste DNS geeft je controle over naamresolutie, maar maakt naamresolutie ook jouw verantwoordelijkheid. Als je aangepaste DNS-servers de namen die klassieke compute nodig heeft niet kunnen oplossen, kunnen clusters niet starten en verliezen ze de uitgaande connectiviteit met externe databronnen en bibliotheekrepositories. Dit artikel beschrijft de aanbevolen aangepaste DNS-configuratie voor VNet-geïnjecteerde werkruimtes, de meest voorkomende verkeerde configuraties en hoe je deze kunt troubleshooten.

Hoe Azure Databricks DNS gebruikt in een VNet-geïnjecteerde werkruimte

Klassieke compute-nodes draaien in de container (privé) en host (publieke) subnetten van je VNet. Tijdens het opstarten en de werking van het cluster moeten deze knooppunten meerdere Azure Databricks- en Azure-eindpunten kunnen omzetten naar IP-adressen en bereiken. Als beveiligde clusterconnectiviteit (SCC) is ingeschakeld, opent elke cluster tijdens het aanmaken van de cluster een uitgaande verbinding met het SCC-relais in het controlevlak, dus de naamresolutie moet slagen voordat een cluster kan verschijnen.

De eindpunten waarop klassieke rekenkracht afhankelijk is, zijn onder andere:

Klassieke compute bereikt het controlevlak en de webapplicatie via regionale IP-bereiken in plaats van via een klantgerichte hostnaam, dus Azure Databricks raadt aan om ze toe te staan met de AzureDatabricks servicetag in je routetabellen, netwerkbeveiligingsgroepen of firewall. Sommige firewalls, zoals Palo Alto, kunnen geen Azure servicetags gebruiken. Op die locaties kun je in plaats daarvan de onderliggende IP-bereiken uit de referentielijst toestaan.

De AzureDatabricks servicetag dekt al het SCC-relais. Als u specifieke IP-adressen op de toegestane lijst zet in plaats van de servicetag, zet u de SCC-relay op de toegestane lijst op basis van de FQDN, omdat de IP-adressen erachter wijzigen. Sommige regio's schakelen over naar een secundaire regio, waardoor de referentielijst voor een regio meer dan één tunnel FQDN kan weergeven. Laat ze allemaal op de lijst staan. De metastore, storage en Event Hubs-eindpunten behoren tot andere Azure-diensten met hun eigen servicetags, zoals Sql, Storage, en EventHub. Zie Metastore, Blob-opslag voor artefacten, opslag voor systeemtabellen, Blob-opslag voor logboeken en IP-adressen van Event Hubs-eindpunten voor de volledige lijst per regio van adressen en FQDN's.

Aanbevolen aangepaste DNS-configuratie

Je aangepaste DNS-servers hoeven niet elke Azure- en publieke naam zelf op te lossen. Het aanbevolen patroon is om de namen die je bezit op te lossen en de rest door te sturen naar Azure.

Niet-opgeloste query’s doorsturen naar Azure DNS

Configureer je aangepaste DNS-servers zodat ze de namen die ze niet kunnen oplossen voorwaardelijk doorsturen naar de door Azure geleverde DNS-resolver op het virtuele IP-adres168.63.129.16. Azure DNS lost de Azure Databricks control plane, storage, metastore en andere Azure-servicenamen voor je op, en het blijft werken terwijl die adressen veranderen.

Stuur minimaal de volgende domeinen voorwaardelijk door naar Azure DNS, en stuur alle opslag- en Azure-servicedomeinen door die je workloads gebruiken:

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

Private Link-eindpunten omzetten

Als je werkruimte Azure Private Link gebruikt voor de klassieke computeplane-verbinding, moet naamresolutie de IP-adressen van het privé-endpoint teruggeven in plaats van publieke adressen. Azure creëert de private DNS-zone privatelink.azuredatabricks.net en voegt adresrecords toe voor je werkruimte-endpoints, inclusief het databricks_ui_api endpoint en het browser_authentication endpoint dat wordt gebruikt voor single sign-on. Het browserauthenticatierecord gebruikt het formaat pl-auth.<region>.

Wanneer een werkruimte aangepaste DNS gebruikt, sturen de klassieke compute-nodes DNS-query's naar je aangepaste DNS-servers in plaats van naar Azure DNS. Een private DNS-zone die aan een VNet is gekoppeld, wordt alleen geraadpleegd via de door Azure geleverde resolver op 168.63.129.16, dus het alleen koppelen van de zone levert niet de adressen van de private eindpunten terug om een aangepaste resolver te berekenen. Beide volgende zijn vereist:

• Koppel de privatelink.azuredatabricks.net private DNS-zone aan de VNet waar Azure DNS de query oplost: je workspace-VNet, of de hub-VNet die je resolver host in een hub-and-spoke-topologie. Hierdoor beschikt Azure DNS over de adresrecords van het private endpoint om te retourneren.
• Configureer uw aangepaste DNS-servers om *.privatelink.azuredatabricks.net en *.azuredatabricks.net voorwaardelijk door te sturen naar Azure DNS op 168.63.129.16. Doorsturen is wat de query naar de gekoppelde privé-DNS-zone doorstuurt. Stuur in een hub-and-spoke-topologie door naar de centrale resolver die verbinding maakt met Azure DNS.

Als de private DNS-zone niet gekoppeld is, of wel gekoppeld is maar het adresrecord voor een endpoint mist, valt Azure DNS terug op publieke recursie en geeft het het publieke IP-adres van het endpoint terug. De naamresolutie lijkt te slagen, maar het verkeer gaat naar het publieke eindpunt in plaats van naar het privé-eindpunt. Bevestig dat de gekoppelde zone de verwachte adresrecords bevat voor elk privé-eindpunt dat de werkruimte gebruikt.

Andere Azure private endpoints, zoals opslag, gebruiken hun eigen Azure private DNS-zones, bijvoorbeeld privatelink.dfs.core.windows.net en privatelink.blob.core.windows.net. Pas hetzelfde patroon toe: koppel die zones en stuur de bijbehorende privatelink domeinen voorwaardelijk door naar Azure DNS zodat de gekoppelde zones worden geraadpleegd. De integratie van DNS met een privé-endpoint kent verschillende scenario's, afhankelijk van je setup. Voor details, zie Azure Private Endpoint DNS-integratie.

Voor de volledige front-end en back-end Private Link-configuratie, zie Configure classic compute plane private connectivity to Azure Databricks enConfigure inbound Private Link for workspaces.

Veelvoorkomende aangepaste DNS-misconfiguraties

De meeste aangepaste DNS-ondersteuningsgevallen komen voort uit een van de volgende verkeerde configuraties:

• Geen doorstuur naar Azure DNS. Aangepaste DNS-servers kunnen de namen van Azure Databricks control plane, storage of metastore niet oplossen en sturen de queries niet door naar 168.63.129.16. Clusters kunnen niet opstarten, of bereiken de opslag en de metastore niet na het starten.
• Ontbrekende Privé-DNS zonelink, doorstuur of records. De werkruimte gebruikt Private Link, maar de VNet is niet gekoppeld aan de privatelink.azuredatabricks.net zone, stuurt niet door naar Azure DNS, of de gekoppelde zone mist het juiste adresrecord voor een endpoint. Namen worden omgezet in openbare IP-adressen, het verkeerde adres of niets, waardoor privéconnectiviteit mislukt.
• Aangepaste DNS-servers onbereikbaar. De aangepaste DNS-serveradressen op de VNet zijn fout, of netwerkregels blokkeren de compute-subnetten om ze te bereiken, bijvoorbeeld wanneer de workspace-VNet niet wordt gepeerd met de VNet die je aangepaste DNS-servers host. Alle naamomzetting mislukt.
• On-premises resolver zonder Azure forwarding. DNS-queries worden geleid naar een on-premises resolver die interne namen oplost, maar geen Azure-namen kan oplossen of doorsturen. Voeg voorwaardelijke doorsturing toe voor de domeinen van Azure en Azure Databricks.
• Geblokkeerde opslagplaatsen voor bibliotheken. DNS lost de vereiste Azure Databricks-endpoints op, maar niet de openbare bibliotheekrepositories, dus bibliotheekinstallaties van PyPI, Maven of CRAN falen.

Problemen met aangepaste DNS oplossen

Als clusters niet opstarten of de connectiviteit verliezen, controleer dan de DNS-resolutie van een cluster.

1. Maak een cluster aan in de werkruimte. Als de cluster niet opstart en het gebeurtenislogboek een fout toont zoals Cluster terminated. Reason: Control Plane Request Failure, kan de cluster het controlevlak niet bereiken, wat vaak een naamresolutieprobleem is.

2. Zoek vanuit een notebook in een actief cluster een vereist endpoint op om te controleren of uw aangepaste DNS het verwachte adres retourneert. Voor een Private Link-werkruimte controleer je of de URL van de werkruimte wordt opgelost naar het IP-adres van het privé-eindpunt in plaats van naar een openbaar adres.

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

   Als clusters helemaal niet kunnen starten, bijvoorbeeld door een back-end Private Link-probleem, voer deze controles dan uit vanuit een Azure VM in het publieke subnet van de workspace VNet in plaats van vanuit een notebook.

3. Als de oplossing mislukt of het verkeerde adres teruggeeft, controleer dan het volgende. Wanneer een cluster niet opstart door DNS, noemt het cluster-gebeurtenislogboek de netwerkgezondheidscontrole die faalde, weergegeven tussen haakjes:

   • De aangepaste DNS-serveradressen van de VNet zijn correct, en de rekensubnetten kunnen die servers bereiken (X_NHC_DNS_SERVER_UNREACHABLE).
   • Je aangepaste DNS-servers sturen de domeinen van Azure en Azure Databricks voorwaardelijk door naar Azure DNS bij 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, wanneer de namen van het controlevlak of de artefactopslag niet worden opgelost).
   • Voor Private Link is de privatelink.azuredatabricks.net zone gekoppeld aan het VNet waar Azure DNS wordt opgelost, je aangepaste DNS-servers de Azure Databricks-domeinen doorsturen naar Azure DNS, en de verwachte adresrecords bestaan (X_NHC_CONTROL_PLANE_HTTP_ERROR, wanneer het privé-endpoint van het controlevlak niet wordt opgelost).

4. Als clusters starten maar geen on-premises of andere Azure platform as a service (PaaS)-bronnen kunnen bereiken, bevestig dan dat door gebruikers gedefinieerde routes bestaan voor die bestemmingen, want routering en DNS zijn apart geconfigureerd.

Als je het probleem nog steeds niet kunt oplossen, neem dan contact op met je Microsoft- en Azure Databricks-accountteams.

Aanvullende bronnen

• Implementeer Azure Databricks in uw Azure-virtuele netwerk (VNet-injectie)
• De Azure Databricks-werkruimte verbinden met uw on-premises netwerk
• Door de gebruiker gedefinieerde route-instellingen voor Azure Databricks
• Privéconnectiviteit van het klassieke rekenvlak met Azure Databricks configureren
• Metastore-opslag, blob-opslag voor artefacten, opslag van systeemtabellen, blob-opslag voor logboeken en Event Hubs-eindpunt-IP-adressen