Mejores prácticas DNS personalizadas para redes virtuales de Azure Databricks workspace

Cuando despliegas un espacio de trabajo de Azure Databricks en tu propia red virtual (inyección VNet), puedes configurar el VNet para que use servidores DNS personalizados en lugar del DNS proporcionado por Azure. El DNS personalizado es habitual cuando un área de trabajo debe resolver nombres de host de las instalaciones locales, usar un reenviador DNS centralizado en una topología hub-and-spoke o aplicar un filtrado a nivel de DNS.

El DNS personalizado te da control sobre la resolución de nombres, pero también hace que la resolución de nombres sea tu responsabilidad. Si tus servidores DNS personalizados no pueden resolver los nombres que necesita el cómputo clásico, los clústeres no se inician y pierden la conectividad saliente a fuentes de datos externas y repositorios de bibliotecas. Este artículo describe la configuración DNS personalizada recomendada para espacios de trabajo inyectados por VNet, las configuraciones erróneas más comunes y cómo solucionarlas.

Cómo Azure Databricks utiliza DNS en un espacio de trabajo inyectado por VNet

Los nodos de cómputo clásicos se ejecutan en las subredes contenedor (privadas) y host (públicas) de tu VNet. Durante el arranque y el funcionamiento del clúster, esos nodos deben poder resolver y acceder a varios puntos de conexión de Azure Databricks y Azure. Si se habilita la conectividad segura del clúster (SCC), cada clúster abre una conexión saliente al relé SCC en el plano de control durante la creación del clúster, por lo que la resolución de nombres debe tener éxito antes de que pueda surgir un clúster.

Los extremos de los que depende el cómputo clásico incluyen:

La computación clásica llega al plano de control y a la aplicación web a través de rangos de IP regionales en lugar de un nombre de host orientado al cliente, por lo que Azure Databricks recomienda permitirles incluir la AzureDatabricks etiqueta de servicio en tus tablas de rutas, grupos de seguridad de red o firewall. Algunos cortafuegos, como Palo Alto, no pueden consumir etiquetas de servicio de Azure. En esos casos, añade a la lista de permitidos los rangos de IP subyacentes de la lista de referencia.

La AzureDatabricks etiqueta de servicio ya cubre el relé SCC. Si permites listar direcciones IP específicas en lugar de la etiqueta de servicio, permite listar el relé SCC por su FQDN, porque las direcciones IP detrás de él cambian. Algunas regiones realizan una conmutación por error a una región secundaria, por lo que la lista de referencia puede mostrar más de un FQDN tunnel para una región. Inclúyalos todos en la lista de permitidos. Los extremos metastore, storage y Event Hubs pertenecen a otros servicios de Azure con sus propias etiquetas de servicio, como Sql, Storage, y EventHub. Para consultar la lista completa de direcciones y FQDN por región, vea Metastore, almacenamiento Blob de artefactos, almacenamiento de tablas del sistema, almacenamiento Blob de registros y direcciones IP de puntos de conexión de Event Hubs.

Configuración DNS personalizada recomendada

Tus servidores DNS personalizados no tienen que resolver todos los nombres de Azure y públicos por sí mismos. El patrón recomendado es resolver los nombres que posees y reenviar todo lo demás a Azure.

Reenviar consultas no resueltas a Azure DNS

Configura tus servidores DNS personalizados para reenviar condicionalmente los nombres que no pueden resolver al resolvedor DNS proporcionado por Azure en la dirección 168.63.129.16IP virtual. Azure DNS resuelve el plano de control de Azure Databricks, almacenamiento, metastore y otros nombres de servicio de Azure por ti, y sigue funcionando a medida que cambian esas direcciones.

Como mínimo, reenvía condicionalmente los siguientes dominios a Azure DNS y reenvía cualquier almacenamiento y dominios de servicios Azure que utilicen tus cargas de trabajo:

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

Resolver puntos de conexión de Private Link

Si tu espacio de trabajo utiliza Azure Private Link para la conexión clásica del plano de cálculo, la resolución de nombres debe devolver las direcciones IP privadas del endpoint en lugar de las direcciones públicas. Azure crea la zona privatelink.azuredatabricks.net DNS privada y añade registros de dirección para los endpoints de tu espacio de trabajo, incluyendo el databricks_ui_api endpoint y el browser_authentication endpoint usado para el inicio de sesión único. El registro de autenticación del navegador utiliza el formato pl-auth.<region>.

Cuando un espacio de trabajo utiliza DNS personalizado, sus nodos de cómputo clásicos envían consultas DNS a tus servidores DNS personalizados en lugar de a Azure DNS. Una zona DNS privada vinculada a un VNet solo se consulta a través del resolvedor proporcionado por Azure en 168.63.129.16, por lo que enlazar solo la zona no devuelve las direcciones privadas de los endpoints para calcular que consulta un resolvedor personalizado. Se requieren ambos requisitos:

• Vincule la zona DNS privada privatelink.azuredatabricks.net a la red virtual (VNet) en la que Azure DNS resuelve la consulta: la red virtual de su espacio de trabajo o la red virtual del concentrador que hospeda su resolutor en una topología de concentrador y radios. Esto proporciona a Azure DNS los registros de direcciones del punto de conexión privado que debe devolver.
• Configura tus servidores DNS personalizados para que reenvíen *.privatelink.azuredatabricks.net condicionalmente y *.azuredatabricks.net a Azure DNS en 168.63.129.16. El reenvío es lo que envía la consulta a la zona DNS privada vinculada. En una topología de concentrador y radios, reenvíe la consulta al resolutor central que se conecta con Azure DNS.

Si la zona DNS privada no está vinculada, o está vinculada pero falta el registro de dirección de un endpoint, Azure DNS vuelve a la recursividad pública y devuelve la dirección IP pública del endpoint. La resolución de nombres parece tener éxito, pero el tráfico va al punto final público en lugar del privado. Confirma que la zona enlazada contiene los registros de direcciones esperados para cada punto final privado que utilice el espacio de trabajo.

Otros extremos privados de Azure, como el almacenamiento, utilizan sus propias zonas DNS privadas de Azure, por ejemplo privatelink.dfs.core.windows.net y privatelink.blob.core.windows.net. Aplica el mismo patrón: enlaza esas zonas y reenvía condicionalmente los dominios correspondientes privatelink a Azure DNS para que se consulten las zonas enlazadas. La integración DNS de endpoint privado tiene varios escenarios dependiendo de tu configuración. Para más detalles, consulta la integración DNS de Azure Private Endpoint.

Para la configuración completa de Private Link front-end y back-end, véase Configurar la conectividad privada clásica del plano de cálculo con Azure Databricks y Configurar Private Link entrante para espacios de trabajo.

Configuraciones erróneas comunes de DNS personalizados

La mayoría de los casos de soporte DNS personalizado provienen de una de las siguientes configuraciones erróneas:

• No hay reenvío a Azure DNS. Los servidores DNS personalizados no pueden resolver los nombres del plano de control, almacenamiento o metastore de Azure Databricks y no reenvían las consultas a 168.63.129.16. Los clústeres no se inician o, una vez iniciados, no pueden acceder al almacenamiento ni al metastore.
• Falta el vínculo, el reenvío o los registros de la zona DNS privada. El espacio de trabajo usa Private Link, pero el VNet no está vinculado a la privatelink.azuredatabricks.net zona, no se reenvía a Azure DNS, o la zona vinculada carece del registro de dirección correcto para un endpoint. Los nombres se resuelven a direcciones IP públicas, a la dirección incorrecta o a nada, por lo que la conectividad privada falla.
• Servidores DNS personalizados inaccesibles. Las direcciones de servidor DNS personalizado en el VNet son incorrectas, o las reglas de red bloquean que las subredes de cómputo lleguen a ellas, por ejemplo cuando el VNet del espacio de trabajo no está emparejado con el VNet que aloja tus servidores DNS personalizados. Falla toda la resolución de nombres.
• Resolutor local sin reenvío a Azure. Las consultas DNS se dirigen a un resolvedor local que resuelve nombres internos pero no puede resolver ni reenviar nombres de Azure. Añadir reenvío condicional para los dominios Azure e Azure Databricks.
• Bloquearon los repositorios de la biblioteca. DNS resuelve los endpoints necesarios de Azure Databricks pero no los repositorios de bibliotecas públicas, por lo que las instalaciones de bibliotecas de PyPI, Maven o CRAN fallan.

Solucionar problemas con DNS personalizado

Si los clústeres no se inician o pierden la conectividad, comprueba la resolución DNS de un clúster.

1. Crea un clúster en el espacio de trabajo. Si el clúster no se inicia y el registro de eventos muestra un error como Cluster terminated. Reason: Control Plane Request Failure, el clúster no puede alcanzar el plano de control, lo que suele ser un problema de resolución de nombres.

2. Desde un notebook en un clúster activo, resuelve el endpoint necesario para confirmar que tu DNS personalizado devuelve la dirección esperada. Para un espacio de trabajo de Private Link, compruebe que la URL del espacio de trabajo se resuelva en la dirección IP del punto de conexión privado en lugar de en una dirección pública.

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

   Si los clústeres no pueden iniciarse, por ejemplo debido a un problema de Private Link en el backend, ejecuta estas comprobaciones desde una máquina virtual de Azure en la subred pública del VNet del espacio de trabajo en lugar de desde un notebook.

3. Si la resolución falla o devuelve la dirección incorrecta, verifica lo siguiente. Cuando un clúster no se inicia debido a un problema de DNS, el registro de eventos del clúster indica la comprobación del estado de la red que falló, que aparece entre paréntesis:

   • Las direcciones personalizadas del servidor DNS del VNet son correctas, y las subredes de cómputo pueden llegar a esos servidores (X_NHC_DNS_SERVER_UNREACHABLE).
   • Tus servidores DNS personalizados reenvían condicionalmente los dominios de Azure y Azure Databricks a Azure DNS en 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, si no se resuelven los nombres del plano de control o del almacenamiento de artefactos).
   • Para Private Link, la privatelink.azuredatabricks.net zona está vinculada al VNet donde se resuelve Azure DNS, tus servidores DNS personalizados reenvían los dominios de Azure Databricks a Azure DNS, y los registros de direcciones esperados existen (X_NHC_CONTROL_PLANE_HTTP_ERROR, cuando el endpoint privado del plano de control no se resuelve).

4. Si los clústeres inician pero no pueden acceder a recursos locales u otras plataformas Azure como servicio (PaaS), confirma que existen rutas definidas por el usuario para esos destinos, porque el enrutamiento y el DNS están configurados por separado.

Si aún no puedes resolver el problema, contacta con los equipos de cuentas de Microsoft y Azure Databricks.

Recursos adicionales

• Implementar Azure Databricks en tu red virtual de Azure (inyección de VNet)
• Conexión del área de trabajo de Azure Databricks a una red local
• Configuración de rutas definidas por el usuario para Azure Databricks
• Configuración de la conectividad privada del plano de proceso clásico a Azure Databricks
• Metastore, almacenamiento de blobs de artefactos, almacenamiento de tablas del sistema, almacenamiento de blobs de registros y direcciones IP de los puntos de conexión de Event Hubs