Meilleures pratiques relatives au DNS personnalisé pour les réseaux virtuels de l’espace de travail Azure Databricks

Lorsque vous déployez un espace de travail Azure Databricks dans votre propre réseau virtuel (injection VNet), vous pouvez configurer le VNet pour utiliser des serveurs DNS personnalisés au lieu du DNS fourni par Azure. Le DNS personnalisé est courant lorsqu’un espace de travail doit résoudre des noms d’hôte sur site, utiliser un transiteur DNS centralisé dans une topologie hub-and-spoke, ou appliquer un filtrage au niveau DNS.

Le DNS personnalisé vous donne le contrôle sur la résolution des noms, mais il fait aussi de votre responsabilité la résolution des noms. Si vos serveurs DNS personnalisés ne peuvent pas résoudre les noms dont le calcul classique a besoin, les clusters ne démarrent pas et perdent la connectivité sortante vers les sources de données externes et les dépôts de bibliothèques. Cet article décrit la configuration DNS personnalisée recommandée pour les espaces de travail injectés par VNet, les erreurs de configuration les plus courantes et la manière de les dépanner.

Note

Le DNS personnalisé s’applique au plan de calcul classique dans un espace de travail injecté par VNet. Le calcul serverless fonctionne dans le réseau Azure Databricks et n'utilise pas la configuration DNS de votre VNet.

Comment Azure Databricks utilise le DNS dans un espace de travail injecté par VNet

Les nœuds de calcul classiques s’exécutent dans les sous-réseaux conteneur (privé) et hôte (public) de votre VNet. Lors du démarrage et de l’exploitation du cluster, ces nœuds doivent se résoudre et atteindre plusieurs points de terminaison Azure Databricks et Azure. Si la connectivité sécurisée du cluster (SCC) est activée, chaque cluster ouvre une connexion sortante vers le relais SCC dans le plan de contrôle lors de la création du cluster, de sorte que la résolution du nom doit réussir avant qu’un cluster puisse apparaître.

Les points d’extrémité dont dépend le calcul classique incluent :

Point de terminaison Comment y accéder
Plan de contrôle et application web d’Azure Databricks Plages IP régionales, représentées par l’identifiant AzureDatabricks de service
Relais de connectivité sécurisée de cluster (SCC) Le nom de domaine pleinement qualifié (FQDN) tunnel.<region>.azuredatabricks.net
Ancien metastore Hive consolidated-<region>-prod-metastore.mysql.database.azure.com
Racine de stockage de l’espace de travail (DBFS) Les points de terminaison dfs et blob du compte de stockage de l’espace de travail
Stockage d’artéfacts et Blob des journaux dbartifactsprod<region>.blob.core.windows.net, dblogprod<region>.blob.core.windows.net
Centres d’événements (journalisation) prod-<region>-observabilityeventhubs.servicebus.windows.net
Sources de données externes et dépôts de bibliothèques Noms DNS publics, tels que PyPI, Maven et dépôts CRAN

Le calcul classique atteint le plan de contrôle et l’application web via des plages d’adresses IP régionales plutôt qu’au moyen d’un nom d’hôte exposé au client ; Azure Databricks recommande donc de les ajouter à la liste d’autorisation à l’aide de la balise de service AzureDatabricks dans vos tables de routage, vos groupes de sécurité réseau ou votre pare-feu. Certains pare-feus, comme Palo Alto, ne peuvent pas consommer les balises de service Azure. Dans ces cas-là, il faut plutôt inscrire les plages d’IP sous-jacentes à partir de la liste de références.

L’étiquette AzureDatabricks de service couvre déjà le relais SCC. Si vous ajoutez à la liste d’autorisation des adresses IP spécifiques au lieu de la balise de service, ajoutez le relais SCC à la liste d’autorisation en utilisant son nom de domaine complet (FQDN), car les adresses IP sous-jacentes changent. Certaines régions basculent vers une région secondaire, donc la liste de référence peut afficher plus d’un tunnel FQDN pour une région. Mettez-les tous sur la liste. Les terminaux de métastore, de stockage et de Event Hubs appartiennent à d’autres services Azure avec leurs propres balises de service, telles que Sql, Storage, et EventHub. Pour la liste complète par région des adresses et des FQDN, voir Metastore, stockage Blob d’artefacts, stockage des tables système, stockage Blob journal, et adresses IP des terminaux des hubs d’événements.

Vos serveurs DNS personnalisés n'ont pas à résoudre eux-mêmes chaque nom Azure et public. Le schéma recommandé est de résoudre les noms que vous possédez et de transmettre tout le reste à Azure.

Transférer les requêtes non résolues vers Azure DNS

Configurez vos serveurs DNS personnalisés pour transmettre conditionnellement les noms qu'ils ne peuvent pas résoudre vers le résolveur DNS fourni par Azure à l'adresse 168.63.129.16IP virtuelle. Azure DNS résout pour vous le plan de contrôle Azure Databricks, le stockage, le métastore et d’autres noms de service Azure, et il continue de fonctionner au fur et à mesure que ces adresses changent.

Important

Ne remplacez pas complètement le DNS fourni par Azure sans redirection conditionnelle. Si vos serveurs DNS personnalisés deviennent autoritaires pour les domaines Azure ou Azure Databricks et ne transmettent pas les requêtes qu'ils ne peuvent pas répondre, la résolution des terminaux requis échoue et les clusters ne peuvent pas démarrer.

Au minimum, transférez conditionnellement les domaines suivants vers Azure DNS, et transférez tous les domaines de stockage et de service Azure utilisés par vos charges de travail :

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

Si votre espace de travail utilise Azure Private Link pour la connexion classique du plan de calcul, la résolution de noms doit retourner les adresses IP des points de terminaison privés plutôt que les adresses publiques. Azure crée la zone privatelink.azuredatabricks.net DNS privée et ajoute des enregistrements d’adresse pour vos points de terminaison de l’espace de travail, y compris le databricks_ui_api point de terminaison et celui browser_authentication utilisé pour la connexion unique. L’enregistrement d’authentification du navigateur utilise le format pl-auth.<region>.

Lorsqu’un espace de travail utilise un DNS personnalisé, ses nœuds de calcul classiques envoient des requêtes DNS vers vos serveurs DNS personnalisés au lieu d’Azure DNS. Une zone DNS privée liée à un VNet n’est consultée que via le résolveur fourni par Azure à 168.63.129.16 ; le simple fait de lier la zone ne renvoie donc pas les adresses des points de terminaison privés aux ressources de calcul qui interrogent un résolveur personnalisé. Les deux éléments suivants sont requis :

  • Reliez la zone DNS privée privatelink.azuredatabricks.net au VNet dans lequel Azure DNS résout la requête : le VNet de votre espace de travail, ou le VNet hub qui héberge votre résolveur dans une topologie hub-and-spoke. Cela permet à Azure DNS de retourner les enregistrements d’adresse de terminaison privés.
  • Configurez vos serveurs DNS personnalisés pour qu’ils transmettent *.privatelink.azuredatabricks.net conditionnellement et *.azuredatabricks.net vers Azure DNS à 168.63.129.16. Le transfert permet d’acheminer la requête vers la zone DNS privée liée. Dans une topologie en étoile, transférez vers le résolveur central qui permet d’accéder à Azure DNS.

Si la zone DNS privée n'est pas liée, ou est liée mais manque de l'enregistrement d'adresse d'un point de terminaison, Azure DNS revient à la récursion publique et renvoie l'adresse IP publique du point de terminaison. La résolution de noms semble aboutir, mais le trafic est dirigé vers le point de terminaison public au lieu du point de terminaison privé. Confirmez que la zone liée contient les enregistrements d’adresses attendus pour chaque point de terminaison privé utilisé par l’espace de travail.

D’autres points privés Azure, comme le stockage, utilisent leurs propres zones DNS privées Azure, par exemple privatelink.dfs.core.windows.net et privatelink.blob.core.windows.net. Appliquez le même schéma : relier ces zones et transmettre conditionnellement les domaines correspondants privatelink vers Azure DNS afin que les zones liées soient consultées. L’intégration DNS par point d’accès privé comporte plusieurs scénarios selon votre configuration. Pour plus de détails, voir l’intégration DNS d’Azure Private Endpoint.

Pour la configuration complète du front-end et du back-end Private Link, voir Configurer la connectivité privée classique du plan de calcul vers Azure Databricks et Configurer le Private Link entrant pour les espaces de travail.

Erreurs courantes de configurations DNS personnalisées

La plupart des cas de prise en charge DNS personnalisés proviennent de l’une des erreurs de configuration suivantes :

  • Pas de transfert vers Azure DNS. Les serveurs DNS personnalisés ne peuvent pas résoudre les noms du plan de contrôle, du stockage ou du métastore d'Azure Databricks et ne transmettent pas les requêtes vers 168.63.129.16. Les clusters ne démarrent pas, ou n’atteignent pas le stockage et le métastore après le démarrage.
  • Liaison de zone DNS privée, transfert ou enregistrements manquants. L'espace de travail utilise Private Link, mais le VNet n'est pas lié à la privatelink.azuredatabricks.net zone, ne transmet pas vers Azure DNS, ou la zone liée manque de l'enregistrement d'adresse correct pour un point de terminaison. Les noms se résolvent vers des adresses IP publiques, une mauvaise adresse, ou rien, donc la connectivité privée échoue.
  • Serveurs DNS personnalisés inaccessibles. Les adresses de serveurs DNS personnalisées sur le VNet sont incorrectes, ou les règles réseau bloquent les sous-réseaux de calcul qui les atteincent, par exemple lorsque le VNet de l’espace de travail n’est pas peeré avec le VNet qui héberge vos serveurs DNS personnalisés. Toute résolution de noms échoue.
  • Résolveur local sans transfert vers Azure. Les requêtes DNS sont dirigées vers un résolveur sur site qui résout les noms internes mais ne peut pas résoudre ni rediriger les noms Azure. Ajouter un transfert conditionnel pour les domaines Azure et Azure Databricks.
  • Dépôts de bibliothèques bloqués. DNS résout les terminaux Azure Databricks requis mais pas les dépôts de bibliothèques publiques, donc les installations de bibliothèques de PyPI, Maven ou CRAN échouent.

Résoudre les problèmes DNS personnalisés

Si les clusters échouent ou perdent la connectivité, vérifiez la résolution DNS d’un cluster.

  1. Créez un cluster dans l’espace de travail. Si le cluster ne démarre pas et que le journal des événements affiche une erreur telle que Cluster terminated. Reason: Control Plane Request Failure, le cluster ne peut pas atteindre le plan de contrôle, ce qui est souvent un problème de résolution de noms.

  2. Depuis un notebook sur un cluster en cours d’exécution, résolvez un point de terminaison requis pour confirmer que votre DNS personnalisé renvoie l’adresse attendue. Pour un espace de travail Private Link, vérifiez que l’URL de l’espace de travail se résout vers l’adresse IP du point de terminaison privé plutôt qu’une adresse publique.

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

    Si les clusters ne peuvent pas démarrer du tout, par exemple à cause d'un problème back-end Private Link, exécutez ces vérifications depuis une VM Azure dans le sous-réseau public du VNet de l'espace de travail au lieu d'un notebook.

  3. Si la résolution échoue ou renvoie la mauvaise adresse, vérifiez ce qui suit. Lorsqu’un cluster ne démarre pas à cause du DNS, le journal des événements du cluster nomme la vérification de santé réseau qui a échoué, indiquée entre parenthèses :

    • Les adresses DNS personnalisées du serveur VNet sont correctes, et les sous-réseaux de calcul peuvent atteindre ces serveurs (X_NHC_DNS_SERVER_UNREACHABLE).
    • Vos serveurs DNS personnalisés transmettent conditionnellement les domaines Azure et Azure Databricks vers Azure DNS à 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, lorsque les noms du plan de contrôle ou des mémoires d'artefacts ne se résolvent pas).
    • Pour Private Link, la privatelink.azuredatabricks.net zone est liée au VNet où Azure DNS se résout, vos serveurs DNS personnalisés transmettent les domaines Azure Databricks vers Azure DNS, et les enregistrements d'adresses attendus existent (X_NHC_CONTROL_PLANE_HTTP_ERROR, lorsque le point de terminaison privé du plan de contrôle ne se résout pas).

  4. Si les clusters démarrent mais ne peuvent pas atteindre les ressources sur site ou d'autres plateformes Azure en tant que service (PaaS), confirmez que des routes définies par l'utilisateur existent pour ces destinations, car le routage et le DNS sont configurés séparément.

Si vous ne pouvez toujours pas résoudre le problème, contactez vos équipes de comptes Microsoft et Azure Databricks.

Ressources additionnelles

  • Dernière mise à jour :