Migliori pratiche DNS personalizzate per le reti virtuali di workspace di Azure Databricks

Quando distribuisci uno spazio di lavoro Azure Databricks nella tua rete virtuale (injection VNet), puoi configurare il VNet per usare server DNS personalizzati invece del DNS fornito da Azure. Il DNS personalizzato è comune quando uno spazio di lavoro deve risolvere nomi host on-premises, utilizzare un server d'inoltro DNS centralizzato in una topologia hub-and-spoke o applicare un filtraggio a livello DNS.

Il DNS personalizzato consente di controllare la risoluzione dei nomi, ma ti rende anche responsabile della risoluzione dei nomi. Se i tuoi server DNS personalizzati non riescono a risolvere i nomi di cui il calcolo classico ha bisogno, i cluster non si avviano e perdono la connettività in uscita verso sorgenti dati esterne e repository di librerie. Questo articolo descrive la configurazione DNS personalizzata raccomandata per gli spazi di lavoro iniettati con VNet, le configurazioni errate più comuni e come risolvere i problemi.

Come Azure Databricks utilizza il DNS in uno spazio di lavoro VNet injectato

I classici nodi di calcolo girano nelle sottoreti container (private) e host (pubbliche) del tuo VNet. Durante l'avvio e il funzionamento del cluster, quei nodi devono risolvere e raggiungere diversi endpoint di Azure Databricks e Azure. Se è abilitata la connettività sicura del cluster (SCC ), ogni cluster apre una connessione in uscita al relè SCC nel piano di controllo durante la creazione del cluster, quindi la risoluzione del nome deve avere successo prima che un cluster possa emergere.

Gli endpoint da cui dipende il calcolo classico includono:

Le risorse di calcolo classiche raggiungono il piano di controllo e l'applicazione Web tramite intervalli IP regionali anziché tramite un hostname esposto al cliente, quindi Azure Databricks consiglia di aggiungerli a un elenco elementi consentiti tramite il tag di servizio AzureDatabricks nelle tabelle di route, nei gruppi di sicurezza di rete o nel firewall. Alcuni firewall, come Palo Alto, non possono consumare i service tag Azure. In quelli, inserisci invece gli intervalli di IP sottostanti dalla lista di riferimenti.

Il AzureDatabricks tag di servizio copre già il relè SCC. Se permetti di indicare indirizzi IP specifici invece del service tag, consente di indicare il relay SCC tramite il suo FQDN, perché gli indirizzi IP dietro di esso cambiano. Alcune regioni passano a una regione secondaria, quindi la lista di riferimento può mostrare più di un tunnel FQDN per una regione. Mettili tutti nella lista. Gli endpoint metastore, storage e Event Hub appartengono ad altri servizi Azure con propri tag di servizio, come Sql, Storage, e EventHub. Per l'elenco completo degli indirizzi e degli FQDN per area geografica, consulta gli indirizzi IP di Metastore, dell'archiviazione Blob degli artefatti, dell'archiviazione delle tabelle di sistema, dell'archiviazione Blob dei log e degli endpoint di Event Hubs.

Configurazione DNS personalizzata consigliata

I tuoi server DNS personalizzati non devono risolvere da soli ogni nome Azure e pubblico. Il modello consigliato è risolvere i nomi che possiedi e inoltrare tutto il resto ad Azure.

Inoltrai query non risolte a DNS di Azure

Configura i tuoi server DNS personalizzati in modo che inoltrino in modo condizionale i nomi che non riescono a risolvere al resolver DNS fornito da Azure all'indirizzo IP virtuale 168.63.129.16. DNS di Azure risolve per te il piano di controllo Azure Databricks, lo storage, il metastore e altri nomi dei servizi Azure, e continua a funzionare man mano che quegli indirizzi cambiano.

Al minimo, inoltra condizionatamente i seguenti domini ad DNS di Azure e inoltra tutti i domini di storage e servizi Azure utilizzati dai tuoi carichi di lavoro:

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

Risolvere gli endpoint di collegamento privato

Se il tuo workspace utilizza collegamento privato di Azure per la connessione classica del piano di calcolo, la risoluzione dei nomi deve restituire gli indirizzi IP degli endpoint privati invece che quelli pubblici. Azure crea la zona privatelink.azuredatabricks.net DNS privata e aggiunge i record degli indirizzi per gli endpoint del tuo workspace, inclusi l'endpoint databricks_ui_api e quello browser_authentication usato per il single sign-on. Il record di autenticazione del browser utilizza il formato pl-auth.<region>.

Quando uno spazio di lavoro utilizza DNS personalizzato, i suoi classici nodi di calcolo inviano query DNS ai tuoi server DNS personalizzati invece che ad DNS di Azure. Una zona DNS privata collegata a una VNet viene consultata solo tramite il resolver fornito da Azure all'indirizzo 168.63.129.16, quindi il solo collegamento della zona non restituisce gli indirizzi degli endpoint privati alle risorse di calcolo che eseguono query tramite un resolver personalizzato. Sono richiesti entrambi i seguenti aspetti:

• Collega la privatelink.azuredatabricks.net zona DNS privata al VNet dove DNS di Azure risolve la query: il tuo VNet workspace, o il VNet hub che ospita il tuo resolver in una topologia hub-and-spoke. Questo dà a DNS di Azure i record degli indirizzi privati degli endpoint da restituire.
• Configura i tuoi server DNS personalizzati per inoltrare *.privatelink.azuredatabricks.net e *.azuredatabricks.net con inoltro condizionale ad DNS di Azure all'indirizzo 168.63.129.16. Il forwarding è ciò che invia la query nella zona DNS privata collegata. In una topologia hub-and-spoke, inoltrare al resolver centrale che raggiunge DNS di Azure.

Se la zona DNS privata non è collegata, o è collegata ma manca l'indirizzo di un endpoint, DNS di Azure torna alla ricorsione pubblica e restituisce l'indirizzo IP pubblico dell'endpoint. La risoluzione del nome sembra avere successo, ma il traffico va all'endpoint pubblico invece che a quello privato. Conferma che la zona collegata contenga i record di indirizzo attesi per ogni endpoint privato utilizzato dallo spazio di lavoro.

Altri endpoint privati Azure, come lo storage, utilizzano le proprie zone DNS private Azure, ad esempio privatelink.dfs.core.windows.net e privatelink.blob.core.windows.net. Applica lo stesso schema: collega quelle zone e inoltra condizionatamente i domini corrispondenti privatelink ad DNS di Azure così che le zone collegate vengano consultate. L'integrazione DNS con endpoint privati prevede diversi scenari a seconda della tua configurazione. Per dettagli, vedi Azure Private Endpoint DNS integration.

Per la configurazione completa di collegamento privato front-end e back-end, vedi Configura la connettività privata classica del piano di calcolo con Azure Databricks e Configura collegamento privato in entrata per gli spazi di lavoro.

Errori comuni di configurazione DNS personalizzata

La maggior parte dei casi di supporto DNS personalizzati deriva da una delle seguenti configurazioni errate:

• Nessun inoltro a DNS di Azure. I server DNS personalizzati non possono risolvere i nomi del piano di controllo, dello storage o del metastore di Azure Databricks e non inoltrono le query a 168.63.129.16. I cluster non si avviano, o non raggiungono lo storage e il metastore dopo l'avvio.
• Collegamento di zona DNS privato, inoltro o record mancanti. Lo spazio di lavoro usa collegamento privato, ma il VNet non è collegato alla privatelink.azuredatabricks.net zona, non viene inoltrato ad DNS di Azure, oppure la zona collegata manca del corretto record di indirizzo per un endpoint. I nomi si risolvono in indirizzi IP pubblici, all'indirizzo sbagliato o a nulla, quindi la connettività privata fallisce.
• Server DNS personalizzati non raggiungibili. Gli indirizzi dei server DNS personalizzati sul VNet sono sbagliati, oppure le regole di rete bloccano le subnet di calcolo dal raggiungerli, ad esempio quando il VNet dello spazio di lavoro non è peeregato con il VNet che ospita i tuoi server DNS personalizzati. Ogni risoluzione dei nomi fallisce.
• Resolver on-premises senza inoltro verso Azure. Le query DNS vengono indirizzate a un risolver on-premises che risolve i nomi interni ma non può risolvere o inoltrare i nomi Azure. Aggiungi l'inoltro condizionale per i domini Azure e Azure Databricks.
• Repository di biblioteche bloccati. DNS risolve gli endpoint Azure Databricks necessari ma non i repository delle biblioteche pubbliche, quindi le installazioni di librerie da PyPI, Maven o CRAN falliscono.

Risoluzione problemi DNS personalizzati

Se i cluster non si avviano o perdono la connettività, verifica la risoluzione DNS di un cluster.

1. Crea un cluster nello spazio di lavoro. Se il cluster non si avvia e il registro eventi mostra un errore come Cluster terminated. Reason: Control Plane Request Failure, il cluster non può raggiungere il piano di controllo, il che spesso è un problema di risoluzione del nome.

2. Da un notebook su un cluster in esecuzione, risolvi un endpoint richiesto per confermare che il tuo DNS personalizzato restituisca l'indirizzo atteso. Per uno spazio di lavoro collegamento privato, verifica che l'URL dello spazio di lavoro risolva sull'indirizzo IP dell'endpoint privato piuttosto che su un indirizzo pubblico.

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

   Se i cluster non possono avviarsi affatto, ad esempio a causa di un problema back-end con collegamento privato, esegui questi controlli da una VM Azure nella subnet pubblica del VNet dello spazio di lavoro invece che da un notebook.

3. Se la risoluzione fallisce o restituisce l'indirizzo errato, verifica quanto segue. Quando un cluster non si avvia a causa del DNS, il registro eventi del cluster indica il controllo di salute della rete che non è stato effettuato, mostrato tra parentesi:

   • Gli indirizzi dei server DNS personalizzati del VNet sono corretti, e le sottoreti di calcolo possono raggiungere quei server (X_NHC_DNS_SERVER_UNREACHABLE).
   • I tuoi server DNS personalizzati inoltrano in modo condizionale i domini Azure e Azure Databricks ad DNS di Azure all'indirizzo 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, quando i nomi del piano di controllo o dell'archiviazione degli artefatti non vengono risolti).
   • Per collegamento privato, la privatelink.azuredatabricks.net zona è collegata al VNet dove DNS di Azure si risolve, i tuoi server DNS personalizzati inoltrono i domini Azure Databricks su DNS di Azure, e i record di indirizzo attesi esistono (X_NHC_CONTROL_PLANE_HTTP_ERROR, quando l'endpoint privato del piano di controllo non si risolve).

4. Se i cluster iniziano ma non riescono a raggiungere risorse on-premises o altre piattaforme Azure as a Service (PaaS), conferma che esistano rotte definite dall'utente per quelle destinazioni, perché routing e DNS sono configurati separatamente.

Se ancora non riesci a risolvere il problema, contatta i team account Microsoft e Azure Databricks.

Risorse aggiuntive

• Distribuisci Azure Databricks nella rete virtuale di Azure (iniezione VNet)
• Connettere l'area di lavoro di Azure Databricks alla rete locale
• Impostazioni di route definite dall'utente per Azure Databricks
• Configurare la connettività privata del piano di calcolo classico ad Azure Databricks
• Metastore, archiviazione BLOB degli artefatti, archiviazione delle tabelle di sistema, archiviazione BLOB dei log e indirizzi IP degli endpoint di Event Hubs