Rekommenderade metoder för anpassad DNS för virtuella nätverk för Azure Databricks-arbetsytor

När du distribuerar en Azure Databricks-arbetsyta i ditt eget virtuella nätverk (VNet-injektion) kan du konfigurera VNet att använda anpassade DNS-servrar istället för den DNS som tillhandahålls av Azure. Anpassad DNS är vanligt när en arbetsyta måste lösa värdnamn i den lokala miljön, använda en centraliserad DNS-vidarebefordrare i en nav-och-ekrar-topologi eller tillämpa filtrering på DNS-nivå.

Anpassad DNS ger dig kontroll över namnlösning, men gör också namnlösningen till ditt ansvar. Om dina anpassade DNS-servrar inte kan lösa de namn som klassisk beräkning behöver, misslyckas kluster med att starta och förlorar utgående anslutning till externa datakällor och biblioteksarkiv. Denna artikel beskriver rekommenderad anpassad DNS-konfiguration för VNet-injicerade arbetsytor, de vanligaste felkonfigurationerna och hur man felsöker dem.

Hur Azure Databricks använder DNS i en VNet-injicerad arbetsyta

Klassiska beräkningsnoder körs i din VNets container (privata) och värd (publika) subnät. Under klusterstart och drift måste dessa noder lösa och nå flera Azure Databricks och Azure-endpoints. Om säker klusteranslutning (SCC) är aktiverad öppnar varje kluster en utgående anslutning till SCC-reläet i kontrollplanet under klusterskapandet, så namnupplösningen måste lyckas innan ett kluster kan öppnas.

De ändpunkter som klassisk beräkning är beroende av inkluderar:

Klassisk beräkning når kontrollplanet och webbapplikationen via regionala IP-intervall snarare än ett kundriktat värdnamn, så Azure Databricks rekommenderar att du tillåter dem med tjänstetaggen AzureDatabricks i dina rutttabeller, nätverkssäkerhetsgrupper eller brandvägg. Vissa brandväggar, som Palo Alto, kan inte använda Azure-servicetaggar. På dessa, tillåt istället att använda de underliggande IP-intervallen från referenslistan.

Servicetaggen AzureDatabricks täcker redan SCC-reläet. Om du lägger till specifika IP-adresser i tillåtelselistan i stället för servicetaggen, lägger du till SCC-reläet med dess FQDN, eftersom IP-adresserna bakom det ändras. Vissa regioner går över till en sekundär region, så referenslistan kan visa mer än en tunnel FQDN för en region. Lägg till alla i tillåtelselistan. Metastore-, lagrings- och Event Hubs-endpointerna tillhör andra Azure-tjänster med egna servicetaggar, såsom Sql, Storage, och EventHub. För den fullständiga listan över adresser och FQDN:er per region, se Metastore, artifact Blob storage, system tables storage, log Blob storage och Event Hubs endpoint IP-adresser.

Rekommenderad anpassad DNS-konfiguration

Dina anpassade DNS-servrar behöver inte lösa alla Azure- och publika namn själva. Det rekommenderade mönstret är att lösa upp namnen du äger och vidarebefordra allt annat till Azure.

Vidarebefordran av olösta frågor till Azure DNS

Konfigurera dina anpassade DNS-servrar att villkorligt vidarebefordra de namn de inte kan lösa till den Azure-tillhandahållna DNS-resolvern på den virtuella IP-adressen168.63.129.16. Azure DNS löser Azure Databricks kontrollplan, lagring, metastore och andra Azure-tjänstenamn åt dig, och det fortsätter att fungera när dessa adresser ändras.

Minst kan du villkorligt vidarebefordra följande domäner till Azure DNS, och vidarebefordra alla lagrings- och Azure-tjänstedomäner som dina arbetsbelastningar använder:

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

Matcha Private Link-slutpunkter

Om din arbetsplats använder Azure Private Link för den klassiska compute plane-anslutningen måste namnupplösningen returnera de privata endpoint-IP-adresserna istället för publika adresser. Azure skapar den privata DNS-zonen privatelink.azuredatabricks.net och lägger till adressposter för slutpunkterna för arbetsytan, inklusive slutpunkten databricks_ui_api och slutpunkten browser_authentication som används för enkel inloggning. Webbläsarens autentiseringspost använder formatet pl-auth.<region>.

När en arbetsplats använder anpassad DNS skickar dess klassiska beräkningsnoder DNS-frågor till dina anpassade DNS-servrar istället för till Azure DNS. En privat DNS-zon som är länkad till ett VNet används endast via resolvern som tillhandahålls av Azure på 168.63.129.16, så att bara länka zonen gör inte att adresserna för den privata slutpunkten returneras till beräkningsresurser som frågar en anpassad resolver. Båda följande är obligatoriska:

• Koppla den privatelink.azuredatabricks.net privata DNS-zonen till VNet där Azure DNS löser frågan: din workspace-VNet, eller hub-VNet som hostar din resolver i en hub-och-eker-topologi. Detta ger Azure DNS de privata endpoint-adressposterna att returnera.
• Konfigurera dina anpassade DNS-servrar att villkorligt vidarebefordra *.privatelink.azuredatabricks.net och *.azuredatabricks.net till Azure DNS vid 168.63.129.16. Vidarebefordran är det som skickar frågan till den länkade privata DNS-zonen. I en hub and spoke-topologi vidarebefordrar du frågan till den centrala resolvern som ansluter till Azure DNS.

Om den privata DNS-zonen inte är länkad, eller är länkad men saknar adressposten för en endpoint, faller Azure DNS tillbaka på offentlig rekursion och returnerar endpointens publika IP-adress. Namnupplösningen verkar fungera, men trafiken går till den publika ändpunkten i stället för den privata ändpunkten. Kontrollera att den länkade zonen innehåller de adressposter som förväntas för varje privat slutpunkt som arbetsytan använder.

Andra privata Azure-endpoints, såsom lagring, använder sina egna Azure privata DNS-zoner, till exempel privatelink.dfs.core.windows.net och privatelink.blob.core.windows.net. Använd samma mönster: länka dessa zoner och vidarebefordra villkorligt motsvarande privatelink domäner till Azure DNS så att de länkade zonerna konsulteras. Privat endpoint DNS-integration har flera scenarier beroende på din setup. För detaljer, se Azure Private Endpoint DNS-integration.

Den fullständiga konfigurationen av front-end- och back-end-Private Link finns i Konfigurera klassisk privat anslutning för beräkningsplanet till Azure Databricks och Konfigurera ingående Private Link för arbetsytor.

Vanliga felkonfigurationer av anpassade DNS-lösningar

De flesta anpassade DNS-supportfall kommer från någon av följande felkonfigurationer:

• Ingen vidarebefordran till Azure DNS. Anpassade DNS-servrar kan inte lösa Azure Databricks kontrollplan, lagring eller metastore-namn och vidarebefordrar inte frågorna till 168.63.129.16. Kluster startar inte, eller når inte lagring och metastore efter att de startat.
• Saknas länk till privat DNS-zon, vidarebefordran eller poster. Arbetsområdet använder Private Link, men VNet:et är inte länkat till privatelink.azuredatabricks.net-zonen, vidarebefordrar inte till Azure DNS, eller så saknar den länkade zonen korrekt adresspost för en slutpunkt. Namn löses till offentliga IP-adresser, fel adress eller inte alls, så privat anslutning fungerar därför inte.
• Anpassade DNS-servrar är oåtkomliga. De anpassade DNS-serveradresserna i VNet är felaktiga, eller så blockerar nätverksregler beräkningssubnäten från att nå dessa, till exempel när arbetsytans VNet inte är peer-kopplat med det VNet som är värd för dina anpassade DNS-servrar. All namnmatchning misslyckas.
• Lokal resolver utan vidarebefordran till Azure. DNS-frågor dirigeras till en lokal resolver som löser interna namn men kan inte lösa eller vidarebefordra Azure-namn. Lägg till villkorlig vidarebefordran för domänerna Azure och Azure Databricks.
• Blockerade biblioteksarkiv. DNS löser de nödvändiga Azure Databricks-endpoints men inte de publika biblioteksarkiven, så biblioteksinstallationer från PyPI, Maven eller CRAN misslyckas.

Felsök anpassade DNS-problem

Om kluster inte startar eller tappar anslutningen, kontrollera DNS-upplösningen från ett kluster.

1. Skapa ett kluster i arbetsytan. Om klustret inte startar och händelseloggen visar ett fel som Cluster terminated. Reason: Control Plane Request Failure, kan klustret inte nå kontrollplanet, vilket ofta är ett problem med namnupplösning.

2. Från en notebook på ett körande kluster, lös en nödvändig endpoint för att bekräfta att din anpassade DNS returnerar den förväntade adressen. För en Private Link-arbetsyta kontrollerar du att arbetsytans URL matchar den privata slutpunktens IP-adress i stället för en offentlig adress.

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

   Om kluster inte kan starta alls, till exempel på grund av ett backend-problem med Private Link, kör dessa kontroller från en Azure-VM i workspace-VNet:s publika subnät istället för från en anteckningsbok.

3. Om lösningen misslyckas eller returnerar fel adress, kontrollera följande. När ett kluster inte startar på grund av DNS, namnger klustrets händelselogg nätverkshälsokontrollen som misslyckades, vilket visas inom parentes:

   • VNet:s anpassade DNS-serveradresser är korrekta, och beräkningssubnäten kan nå dessa servrar (X_NHC_DNS_SERVER_UNREACHABLE).
   • Dina anpassade DNS-servrar vidarebefordrar villkorligt Azure- och Azure Databricks-domänerna till Azure DNS på 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, när namnen på kontrollplanet eller artefaktlagringen inte kan lösas upp).
   • För Private Link är zonen privatelink.azuredatabricks.net kopplad till VNet där Azure DNS löses, dina anpassade DNS-servrar vidarebefordrar Azure Databricks-domänerna till Azure DNS, och de förväntade adressposterna finns (X_NHC_CONTROL_PLANE_HTTP_ERROR, när kontrollplanets privata endpoint inte löses).

4. Om kluster startar men inte kan nå lokala eller andra Azure Platform as a Service (PaaS)-resurser, bekräfta att användardefinierade rutter finns för dessa destinationer, eftersom routing och DNS konfigureras separat.

Om du fortfarande inte kan lösa problemet, kontakta dina Microsoft- och Azure Databricks-kontoteam.

Ytterligare resurser

• Distribuera Azure Databricks i ditt virtuella Azure-nätverk (VNet-inmatning)
• Ansluta din Azure Databricks-arbetsyta till ditt lokala nätverk
• Användardefinierade väginställningar för Azure Databricks
• Konfigurera klassisk privat anslutning för datorresursnivå till Azure Databricks
• Ip-adresser för metaarkiv, artefaktbloblagring, bloblagring av systemtabeller, loggbloblagring och Event Hubs-slutpunkter