Blog >

Asignación de una única IP pública a Azure Databricks


 

INTRODUCCIÓN

Azure Databricks es una plataforma de análisis de datos, y es muy habitual que esos datos los obtenga desde servicios externos (SQL, event hubs, data lakes…).

En algunos casos, por cuestión de seguridad, los servicios externos sólo permiten que se acceda a ellos a través de IPs públicas específicas. En estos casos, es necesario poder dotar a los clústeres de Azure Databricks de una única IP pública para que le permitan acceder a esos servicios externos restringidos.

Para poder dotar a un clúster de Azure Databricks existente, de una única IP pública hay dos alternativas:

 

ARQUITECTURA DE AZURE DATABRICKS

Para poder entender el uso de las IPs públicas por parte de Azure Databricks es conveniente tener algunas nociones acerca de su arquitectura.

Desde el punto de vista conceptual, la arquitectura de Azure Databricks está compuesta por dos capas o planos:

Plano de control: incluye los servicios de backend de Azure Databricks, donde se encuentra la aplicación web del Workspace de Databricks, los servicios de gestión de los clústeres de Azure Databricks, los notebooks y los jobs. Todos estos recursos se despliegan en una suscripción gestionada por Microsoft.

Plano de datos: donde se encuentran tanto los datos como los clústeres de Azure Databricks que los procesan. Todos estos recursos se despliegan en la suscripción del cliente.

Para más información acerca de la arquitectura de Azure Databricks y los conceptos principales ver Azure Databricks architecture overview – Azure Databricks – Workspace | Microsoft Docs y Databricks Data Science & Engineering concepts – Azure Databricks – Workspace | Microsoft Docs.

Desde el punto de vista de la arquitectura de red, Azure Databricks utiliza redes virtuales para desplegar sus recursos. Para más información acerca de las redes virtuales, ver Azure Virtual Network Documentation – Tutorials, quickstarts, API references | Microsoft Docs.

Los recursos del plano de control se crean en una red virtual (en el diagrama MSFT-managed Databricks Control Plane VNET y de color azure) en una suscripción gestionada por Microsoft.

Los clústeres de Azure Databricks se crean en una red virtual (en el diagrama MSFT-managed Databricks Workspace VNET, y de color naranja) en la suscripción del cliente.

 

ASIGNACIÓN DE UNA ÚNICA IP PÚBLICA A AZURE DATABRICKS

Los clústeres de Azure Databricks están formados por máquinas virtuales (ver  Virtual machines in Azure – Azure Virtual Machines | Microsoft Docs) que están conectadas a una red virtual en la suscripción del cliente.

En concreto, al desplegar Azure Databricks en una red virtual, se crea automáticamente un resource group denominado Managed Resource Group donde se crearán de forma dinámica los recursos de Azure asociados a los nodos de los clústeres de Azure Databricks.

Y en la red virtual a la que se conectarán los nodos de los clústeres de Azure Databricks se crean dos subredes, una pública y otra privada.

Si, por ejemplo, se crea un clúster de tres nodos, se puede observar que en el Managed Resource Group se crea una serie de recursos de Azure. Para cada nodo del clúster se crea una máquina virtual, dos tarjetas de red, una IP pública y varios discos.

Cada máquina virtual tendrá 2 tarjetas de red (ver Create, change, or delete an Azure network interface | Microsoft Docs), una conectada a la subred privada con una IP privada, y otra conectada a la subred pública con una IP privada y una IP pública.

El diagrama de red para un clúster de Azure Databricks de tres nodos sería la siguiente:

Las tarjetas de la subred privada son las que utilizan los nodos para comunicarse entre ellos.

Las tarjetas de la subred pública con las que utilizan los nodos para comunicarse con el Plano de control y otros servicios externos a la red virtual.

Si se crea un notebook, se conecta al clúster creado recientemente y se ejecuta el siguiente comando:

Se puede observar que la IP pública con la que Azure Databricks se comunica con los servicios externos (en este caso, ifconfig.me) corresponde a la IP pública de uno de los nodos del clúster de Azure Databricks.

Sin embargo, cada nodo tiene su IP pública. Además, cuando se termina un clúster de Azure Databricks, desaparecen todos los recursos anteriormente creados en el Managed Resource Group, y cuando se arranca se vuelven a recrear los recursos, incluidas las IPs públicas, pudiendo éstas ser diferentes. Por lo tanto, no tenemos una única IP pública para conectar desde un clúster de Azure Databricks a un servicio externo.

Para conseguir que un clúster de Azure Databricks acceda a través de una única IP pública a un servicio externo hay que intentar que el tráfico hacia Internet (hacia ese servicio externo) desde los nodos del clúster no vaya de forma directa hacia Internet sino a través de algún elemento que le proporcione una única IP pública. Este elemento podría ser:

  • Azure Firewall: es un servicio autogestionado que ofrece enrutamiento, control y filtrado del tráfico de red. El mayor inconveniente de esta solución es su complejidad y coste.
  • Network Virtual Appliance: podría ser una máquina virtual con software de enrutamiento. En este caso la solución es más económica, pero más laboriosa de montar y mantener, al tener que desplegar una máquina virtual que actúe como Network Virtual Appliance.

ASIGNACIÓN DE UNA ÚNICA IP PÚBLICA A AZURE DATABRICKS MEDIANTE UN AZURE FIREWALL

Un Azure Firewall es un servicio autogestionado al que se le puede enrutar tráfico de red y aporta una capa de seguridad a dicho tráfico. Además, utiliza una IP pública estática que permite a otros firewalls externos identificar el tráfico procedente de tu red virtual.

Los nodos del clúster utilizan las tarjetas conectadas a la subred pública para acceder a cualquier servicio existente fuera de la red virtual del clúster de Azure Databricks.

Hay que desplegar un Azure Firewall en una nueva subred (Firewall subnet) dentro de la red virtual del clúster de Azure Databricks.

Mediante una Route Table (ver Azure virtual network traffic routing | Microsoft Docs) asociada a la subred pública, hay que crear dos rutas, una para que el tráfico de salida desde la subred pública al servicio externo restringido (al que nos queremos conectar con una IP pública estática) lo enrute a través del Azure Firewall, y otra para que el resto de tráfico lo enrute directamente a Internet.

De esta forma, cuando los nodos del clúster tengan que comunicarse con el servicio externo restringido, el tráfico pasará a través del Azure Firewall que le dotará de una IP pública estática. El resto de tráfico desde los nodos a Internet irá directamente a Internet sin pasar por el Azure Firewall, como ocurre por defecto.

Los pasos a seguir para poder acceder a un servicio externo con una única IP pública mediante Azure Firewall serían los siguientes:

  1. Añadir a la red virtual del clúster de AzureDatabricks una subred donde desplegar un Azure Firewall que enrutará el tráfico hacia Internet.
  2. Desplegar el Azure Firewall en la nueva subred.
  3. Crear una regla en el Azure Firewall para permitir todo el tráfico desde la subred pública de Azure Databricks a Internet.
  4. Crear una Route Table.
  5. Crear dos reglas de enrutamiento en la Route Table:
  6. El tráfico con destino al servicio externo restringido que lo enrute hacia el Azure Firewall.
  7. El tráfico a cualquier otro lugar que lo enrute hacia Internet.
  8. Asociar la Route Table a la subred pública de la red virtual del clúster de Azure Databricks.

ASIGNACIÓN DE UNA ÚNICA IP PÚBLICA A AZURE DATABRICKS MEDIANTE UN NETWORK VIRTUAL APPLIANCE

Un Network Virtual Appliance es una máquina virtual que ayuda en la realización de funciones de red como el enrutamiento.  A esta máquina virtual se le puede asignar una IP pública estática que permita a otros firewalls externos identificar el tráfico procedente de tu red virtual.

Los nodos del clúster utilizan las tarjetas conectadas a la subred pública para acceder a cualquier servicio existente fuera de la red virtual del clúster de Azure Databricks.

Hay que desplegar una máquina virtual que actúe de Virtual Network Appliance con una tarjeta de red en una nueva subred (NVA subnet) y otra tarjeta de red en la subred pública, ambas dentro de la red virtual del clúster de Azure Databricks.

Mediante una Route Table (ver Azure virtual network traffic routing | Microsoft Docs) asociada a la subred pública, hay que crear dos rutas, una para que el tráfico de salida desde la subred pública al servicio externo restringido (al que nos queremos conectar con una IP pública estática) lo enrute a través del Virtual Network Appliance, y otra para que el resto de tráfico lo enrute directamente a Internet.

De esta forma, cuando los nodos del clúster tengan que comunicarse con el servicio externo restringido, el tráfico pasará a través del Virtual Network Appliance que le dotará de una IP pública estática. El resto de tráfico desde los nodos a Internet irá directamente a Internet sin pasar por el Virtual Network Appliance, como ocurre por defecto.

Los pasos a seguir para poder acceder a un servicio externo con una única IP pública mediante Virtual Network Appliance serían los siguientes:

  1. Añadir a la red virtual del clúster de Azure Databricks una subred donde desplegar la máquina virtual que actuará de Virtual Network Appliance.
  2. Desplegar la máquina virtual que actuará de Virtual Network Appliance y enrutará el tráfico hacia Internet con dos tarjetas de red, una en la nueva subred con una IP pública estática, y otra en la subred pública de Azure Databricks
  3. Instalar el role Remote Access y configurar el Network Address Translation utilizando la tarjeta de red de la nueva subred como interfaz para conectar a Internet.
  4. Crear una Route Table.
  5. Crear dos reglas de enrutamiento en la Route Table:
  6. El tráfico con destino al servicio externo restringido que lo enrute hacia el Azure Firewall.
  7. El tráfico a cualquier otro lugar que lo enrute hacia Internet.
  8. Asociar la Route Table a la subred pública de la red virtual del clúster de Azure Databricks.

También te puede interesar

Suscríbete a nuestra newsletter para enterarte de las novedades más Geek

Newsletter Banner
RGPD

Contenido Relacionado