Implementación de Azure Databricks en su red virtual de Azure (inserción en red virtual)
En este artículo se describe cómo implementar un área de trabajo de Azure Databricks en su propia red virtual de Azure, también conocida como inyección de red virtual.
Personalización de red con inyección de red virtual
La implementación predeterminada de Azure Databricks es un servicio totalmente administrado en Azure. Una red virtual (VNet) de Azure se implementa en un grupo de recursos bloqueado. Todos los recursos del plano de proceso clásico están asociados a esa red virtual. Si necesita personalización de red, puede implementar recursos del plano de proceso clásico de Azure Databricks en su propia red virtual. Esto le permite:
- Conecte Azure Databricks a otros servicios de Azure (como Azure Storage) de forma más segura mediante puntos de conexión de servicio o puntos de conexión privados de Azure.
- Conéctese a orígenes de datos locales mediante rutas definidas por el usuario. Vea Configuración de rutas definidas por el usuario para Azure Databricks.
- Conectar Azure Databricks a una aplicación virtual de red para inspeccionar todo el tráfico saliente y tomar medidas en función de reglas que permitan o denieguen el acceso. Vea Opción: Enrutamiento del tráfico de Azure Databricks mediante una aplicación virtual o un firewall
- Configurar Azure Databricks para que use DNS personalizado. Vea Opción: Configuración de DNS personalizado.
- Configurar reglas de grupo de seguridad de red para especificar las restricciones del tráfico de salida.
La implementación de recursos del plano de proceso clásico de Azure Databricks en su propia red virtual también le permite aprovechar los intervalos CIDR flexibles. Para la red virtual, puede usar el tamaño del intervalo CIDR /16-/24. Para las subredes, use intervalos IP tan pequeños como /26.
Importante
No se puede reemplazar la red virtual para un área de trabajo existente. Si el área de trabajo actual no puede aceptar al número necesario de nodos de clúster activos, recomendamos crear otra área de trabajo en una red virtual de mayor tamaño. Siga estos pasos de migración detallados para copiar los recursos (cuadernos, configuraciones de clúster, trabajos) del área de trabajo antigua a la nueva.
Requisitos de red virtual
La red virtual que se implementa en el área de trabajo de Azure Databricks debe cumplir los siguientes requisitos:
- Región: La red virtual debe residir en la misma región y suscripción que el área de trabajo de Azure Databricks.
- Suscripción: la red virtual debe residir en la misma suscripción que el área de trabajo de Azure Databricks.
- Espacio de direcciones: un bloque CIDR entre
/16y/24para la red virtual y un bloque CIDR hasta/26para las dos subredes: una subred de contenedor y una subred de host. Para obtener una orientación sobre el número máximo de nodos de clúster en función del tamaño de la red virtual y sus subredes, consulte Espacio de direcciones y número máximo de nodos de clúster. - Subredes: la red virtual debe incluir dos subredes dedicadas al área de trabajo de Azure Databricks: una subred de contenedor (a veces denominada subred privada) y una subred de host (a veces denominada subred pública). Al implementar un área de trabajo mediante conectividad segura de clústeres, tanto la subred de contenedor como la subred del host usan direcciones IP privadas. No puede compartir subredes entre áreas de trabajo ni implementar otros recursos de Azure en las subredes que usa el área de trabajo de Azure Databricks. Para obtener una orientación sobre el número máximo de nodos de clúster en función del tamaño de la red virtual y sus subredes, consulte Espacio de direcciones y número máximo de nodos de clúster.
Espacio de direcciones y número máximo de nodos de clúster
Un área de trabajo con una red virtual más pequeña puede quedarse sin direcciones IP (espacio de red) más rápidamente que un área de trabajo con una red virtual de mayor tamaño. Use un bloque CIDR entre /16 y /24 para la red virtual y un bloque CIDR hasta /26 para las dos subredes (la subred de contenedor y la subred de host). Puede crear un bloque CIDR hasta /28 para las subredes, pero Databricks no recomienda una subred menor que /26.
El intervalo CIDR del espacio de direcciones de la red virtual afecta al número máximo de nodos de clúster que puede usar el área de trabajo.
Un área de trabajo de Azure Databricks requiere dos subredes en la red virtual: una subred de contenedor y una subred de host. Azure reserva cinco direcciones IP en cada subred. Azure Databricks requiere dos direcciones IP para cada nodo de clúster: una dirección IP para el host en la subred del host y una dirección IP para el contenedor en la subred del contenedor.
- Es posible que no quiera usar todo el espacio de direcciones de la red virtual. Por ejemplo, puede que desee crear varias áreas de trabajo en una red virtual. Dado que no puede compartir subredes entre áreas de trabajo, es posible que desee subredes que no usen el espacio total de direcciones de la red virtual.
- Debe asignar un espacio de direcciones para las dos subredes nuevas que se encuentran dentro del espacio de direcciones de la red virtual y que no se superponga al espacio de direcciones de las subredes actuales o futuras de esa red virtual.
En la tabla siguiente se muestra el tamaño máximo de subred en función del tamaño de la red. En esta tabla se supone que no existen subredes adicionales que asuman el espacio de direcciones. Use subredes más pequeñas si tiene subredes preexistentes o si desea reservar espacio de direcciones para otras subredes:
| Espacio de direcciones de la red virtual (CIDR) | Tamaño máximo de subred de Azure Databricks (CIDR) suponiendo que no haya otras subredes |
|---|---|
/16 |
/17 |
/17 |
/18 |
/18 |
/19 |
/20 |
/21 |
/21 |
/22 |
/22 |
/23 |
/23 |
/24 |
/24 |
/25 |
Para buscar el número máximo de nodos de clúster en función del tamaño de subred, use la tabla siguiente. Las columna de direcciones IP por subred incluye las cinco direcciones IP reservadas para Azure. La columna situada más a la derecha indica el número de nodos de clúster que se pueden ejecutar simultáneamente en un área de trabajo que esté aprovisionada con subredes de ese tamaño.
| Tamaño de subred (CIDR) | Direcciones IP por subred | Número máximo de nodos de clúster de Azure Databricks |
|---|---|---|
/17 |
32768 | 32 763 |
/18 |
16384 | 16 379 |
/19 |
8192 | 8187 |
/20 |
4096 | 4091 |
/21 |
2048 | 2043 |
/22 |
1024 | 1019 |
/23 |
512 | 507 |
/24 |
256 | 251 |
/25 |
128 | 123 |
/26 |
64 | 59 |
Direcciones IP de salida al usar la conectividad segura del clúster
Si habilita la conectividad segura del clúster en el área de trabajo en la que se usa la inserción de red virtual, Databricks recomienda que el área de trabajo tenga una dirección IP pública de salida estable.
Las direcciones IP públicas de salida estables son útiles porque puede agregarlas a listas de permitidos externas. Por ejemplo, para conectarse desde Azure Databricks a Salesforce con una dirección IP de salida estable. Si configura listas de acceso IP, esas direcciones IP públicas deben agregarse a una lista de permitidos. Consulte Configurar listas de acceso IP para áreas de trabajo.
Advertencia
Microsoft ha anunciado que el 30 de septiembre de 2025 será retirada la conectividad de acceso de salida predeterminada para máquinas virtuales en Azure. Consulteeste anuncio. Esto significa que las áreas de trabajo de Azure Databricks que usan el acceso saliente predeterminado en lugar de una dirección IP pública de salida estable podrían no seguir funcionando después de esa fecha. Databricks recomienda agregar métodos de salida explícitos para las áreas de trabajo antes de esa fecha.
Para configurar una dirección IP pública de salida estable, vea salida con inyección de red virtual
Recursos compartidos y emparejamiento
Si se requieren recursos de red compartidos como DNS, Databricks recomienda encarecidamente seguir los procedimientos recomendados de Azure para el modelo en estrella tipo hub-and-spoke. Use el emparejamiento de red virtual para ampliar el espacio IP privado de la red virtual del área de trabajo al centro mientras mantiene las conexiones aisladas entre sí.
Si tiene otros recursos en la red virtual o usa el emparejamiento, Databricks recomienda encarecidamente agregar reglas de denegación a los grupos de seguridad de red (NSG) que están conectados a otras redes y subredes que están en la misma red virtual o que están emparejadas con esa red virtual. Añade reglas de denegación de conexiones tanto entrantes como salientes para que limiten las conexiones tanto hacia como desde los recursos informáticos de Azure Databricks. Si su clúster necesita acceder a recursos de la red, añada reglas para permitir solo la cantidad mínima de acceso necesaria para cumplir los requisitos.
Para obtener información relacionada, consulte Reglas de grupo de seguridad de red.
Creación de un área de trabajo de Azure Databricks mediante Azure Portal
En esta sección se describe cómo crear un área de trabajo de Azure Databricks en Azure Portal e implementarla en su propia red virtual existente. Azure Databricks actualizará la red virtual con dos subredes nuevas, en caso de que aún no existan, mediante los intervalos CIDR que especifique. El servicio también actualiza las subredes con un nuevo grupo de seguridad de red, configurando reglas de entrada y salida y, por último, implementa el área de trabajo en la red virtual actualizada. Para obtener más control sobre la configuración de la red virtual, use plantillas de Azure-Databricks proporcionadas por Azure Resource Manager (ARM) en lugar del portal. Por ejemplo, use grupos de seguridad de red existentes o cree sus propias reglas de seguridad. Consulte Configuración avanzada mediante plantillas de Azure Resource Manager.
Al usuario que crea el área de trabajo se le debe asignar el rol Colaborador de red para la Virtual Network correspondiente o un rol personalizado que tenga asignada la Microsoft.Network/virtualNetworks/subnets/join/action y los permisos Microsoft.Network/virtualNetworks/subnets/write.
Debe configurar una red virtual en la que se implementará el área de trabajo de Azure Databricks. Puede usar una red virtual existente o crear una nueva, pero la red virtual debe estar en la misma región y en la misma suscripción que el área de trabajo de Azure Databricks que va a crear. El tamaño de la red virtual debe tener un intervalo de CIDR comprendido entre /16 y /24. Para obtener más requisitos, consulte Requisitos de red virtual.
Use subredes existentes o especifique nombres e intervalos IP para las nuevas subredes al configurar el área de trabajo.
En Azure Portal, seleccione + Crear un recurso > Análisis > Azure Databricks, o busque Azure Databricks y haga clic en Crear o + Agregar para iniciar el cuadro de diálogo de Azure Databricks Service.
Siga los pasos de configuración que se describen en el inicio rápido Creación de un área de trabajo de Azure Databricks en su propia red virtual.
En la pestaña Redes, seleccione la red virtual que desea usar en el campo Red virtual.
Importante
Si no ve el nombre de red en el selector, confirme que la región de Azure que especificó para el área de trabajo coincide con la región de Azure de la red virtual deseada.
Asigne un nombre a las subredes y proporcione intervalos de CIDR en un bloque con un tamaño máximo de
/26. Para obtener una orientación sobre el número máximo de nodos de clúster en función del tamaño de la red virtual y sus subredes, consulte Espacio de direcciones y número máximo de nodos de clúster. Los rangos CIDR de subred no pueden modificarse una vez implementado el área de trabajo.- Para especificar subredes existentes, especifique los nombres exactos de dichas subredes. Cuando use subredes existentes, establezca también los intervalos IP en el formulario de creación del área de trabajo para que coincidan exactamente con los intervalos IP de las subredes existentes.
- Para crear nuevas subredes, especifique nombres de subred que aún no existan en esa red virtual. Las subredes se crean con los intervalos IP especificados. Debe especificar intervalos IP que estén dentro del intervalo IP de la red virtual y que no estén ya asignados a las subredes existentes.
Azure Databricks requiere que los nombres de subred no tengan más de 80 caracteres.
Las subredes obtienen reglas de grupo de seguridad de red asociadas que incluyen la regla que permite la comunicación interna del clúster. Azure Databricks tiene permisos delegados para actualizar ambas subredes a través del proveedor de recursos
Microsoft.Databricks/workspaces. Estos permisos solo se aplican a las reglas del grupo de seguridad de red que requiere Azure Databricks, no a las demás reglas que agregue ni a las reglas predeterminadas incluidas en todos los grupos de seguridad de red.Haga clic en Crear para implementar el área de trabajo de Azure Databricks en la VNet.
Configuración avanzada mediante plantillas de Azure Resource Manager
Para tener más control sobre la configuración de la red virtual, use las siguientes plantillas de Azure Resource Manager (ARM) en lugar de la configuración automática de red virtual basada en la interfaz de usuario del portal y la implementación del área de trabajo. Por ejemplo, use subredes existentes, un grupo de seguridad de red existente o agregue sus propias reglas de seguridad.
Si usa una plantilla de Azure Resource Manager personalizada o la plantilla del área de trabajo de la inserción en red virtual de Azure Databricks para implementar un área de trabajo en una red virtual existente, debe crear subredes de host y de contenedor, asociar un grupo de seguridad de red a cada subred y delegar las subredes en el proveedor de recursos Microsoft.Databricks/workspacesantes de implementar el área de trabajo. Debe tener un par independiente de subredes para cada área de trabajo que implemente.
Plantilla todo en uno
Para crear una red virtual y un área de trabajo de Azure Databricks mediante una plantilla, use la plantilla todo en uno para áreas de trabajo insertadas en la red virtual de Azure Databricks.
Plantilla de red virtual
Para crear una red virtual con las subredes adecuadas mediante una plantilla, use la plantilla de red virtual para la inserción en red virtual de Databricks.
Plantilla de área de trabajo de Azure Databricks
Para implementar un área de trabajo de Azure Databricks en una red virtual existente con una plantilla, use la plantilla de área de trabajo para la inserción en red virtual de Azure Databricks.
La plantilla de área de trabajo le permite especificar una red virtual existente y usar las subredes existentes:
- Debe tener un par independiente de subredes de host y de contenedor para cada área de trabajo que implemente. No se admite el uso compartido de subredes entre áreas de trabajo ni la implementación de otros recursos de Azure en las subredes que usa el área de trabajo de Azure Databricks.
- Las subredes de host y de contenedor de la red virtual deben tener asociados grupos de seguridad de red y deben delegarse al servicio
Microsoft.Databricks/workspacesantes de usar esta plantilla de Azure Resource Manager para implementar un área de trabajo. - Para crear una red virtual con subredes delegadas correctamente, use la plantilla de red virtual para la inserción en red virtual de Databricks.
- Para usar una red virtual existente cuando aún no ha delegado las subredes de host y contenedor, consulte Adición o eliminación de una delegación de subred.
Reglas del grupo de seguridad de red
En las tablas siguientes se muestran las reglas de grupo de seguridad de red actuales que usa Azure Databricks. Si Azure Databricks necesita agregar una regla o cambiar el ámbito de una regla existente de esta lista, recibirá un aviso previo. Este artículo y las tablas se actualizarán cada vez que se produzca esta modificación.
Administración de las reglas de grupo de seguridad de red por parte de Azure Databricks
Las reglas de grupos de seguridad de red enumeradas en las secciones siguientes representan aquellas que Azure Databricks aprovisiona y administra automáticamente en el grupo de seguridad de red, en virtud de la delegación de las subredes de host y de contenedor de la red virtual en el servicio Microsoft.Databricks/workspaces. No tiene permiso para actualizar o eliminar estas reglas de NSG y cualquier intento de hacerlo está bloqueada por la delegación de subred. Azure Databricks debe disponer de estas reglas para asegurarse de que Microsoft pueda operar y proporcionar soporte técnico de forma confiable al servicio Azure Databricks en su red virtual.
Algunas de estas reglas de grupos de seguridad de red tienen VirtualNetwork asignado como origen y destino. Esto se ha implementado así para simplificar el diseño en ausencia de una etiqueta de servicio de nivel de subred en Azure. Todos los clústeres están protegidos internamente por una segunda capa de directiva de red, de modo que el clúster A no se puede conectar al clúster B en la misma área de trabajo. Esto también se aplica en varias áreas de trabajo si estas están implementadas en un par diferente de subredes de la misma red virtual administrada por el cliente.
Importante
Databricks recomienda encarecidamente agregar reglas de denegación a los grupos de seguridad de red (NSG) que están conectados a otras redes y subredes que están en la misma red virtual o que están emparejadas con esa red virtual. Añade reglas de denegación de conexiones tanto entrantes como salientes para que limiten las conexiones tanto hacia como desde los recursos informáticos de Azure Databricks. Si su clúster necesita acceder a recursos de la red, añada reglas para permitir solo la cantidad mínima de acceso necesaria para cumplir los requisitos.
Reglas de grupo de seguridad de red para áreas de trabajo
La información de esta sección solo se aplica a las áreas de trabajo de Azure Databricks creadas después del 13 de enero de 2020. Si el área de trabajo se creó antes del lanzamiento de la conectividad de clústeres segura (SCC) del 13 de enero de 2020, consulte la sección siguiente.
En esta tabla se enumeran las reglas de grupo de seguridad de red para las áreas de trabajo e incluye dos reglas de grupo de seguridad de entrada que solo se incluyen si la conectividad segura de clústeres (SCC) está deshabilitada.
| Dirección | Protocolo | Origen | Puerto de origen | Destination | Puerto de destino | Usado |
|---|---|---|---|---|---|---|
| Entrada | Any | VirtualNetwork | Any | VirtualNetwork | Any | Valor predeterminado |
| Entrada | TCP | AzureDatabricks (etiqueta de servicio) Solo si SCC está deshabilitada |
Any | VirtualNetwork | 22 | Dirección IP pública |
| Entrada | TCP | AzureDatabricks (etiqueta de servicio) Solo si SCC está deshabilitada |
Any | VirtualNetwork | 5557 | Dirección IP pública |
| Salida | TCP | VirtualNetwork | Any | AzureDatabricks (etiqueta de servicio) | 443, 3306, 8443-8451 | Valor predeterminado |
| Salida | TCP | VirtualNetwork | Any | SQL | 3306 | Valor predeterminado |
| Salida | TCP | VirtualNetwork | Any | Storage | 443 | Valor predeterminado |
| Salida | Any | VirtualNetwork | Any | VirtualNetwork | Any | Valor predeterminado |
| Salida | TCP | VirtualNetwork | Any | EventHub | 9093 | Valor predeterminado |
Nota:
Si restringe las reglas de salida, Databricks recomienda abrir los puertos 111 y 2049 para habilitar determinadas instalaciones de biblioteca.
Importante
Azure Databricks es un servicio propio de Microsoft Azure que se implementa en la infraestructura global de la nube pública de Azure. Todas las comunicaciones entre los componentes del servicio, incluidas aquellas entre las direcciones IP públicas del plano de control y el plano de proceso del cliente, permanecen dentro de la red troncal de Microsoft Azure. Consulte también Red global de Microsoft.
Solución de problemas
Errores de creación del área de trabajo
La subred <subnet-id> requiere cualquiera de las siguientes delegaciones [Microsoft.Databricks/workspaces] para hacer referencia al vínculo de una asociación de servicio.
Posible causa: está creando un área de trabajo en una red virtual cuyas subredes de host y de contenedor no se han delegado al servicio Microsoft.Databricks/workspaces. Cada subred debe tener un grupo de seguridad de red asociado y debe delegarse correctamente. Consulte Requisitos de red virtual para más información.
La subred <subnet-id> ya la está utilizando el área de trabajo <workspace-id>.
Posible causa: está creando un área de trabajo en una red virtual con subredes de host y de contenedor que un área de trabajo de Azure Databricks existente ya está utilizando. No se pueden compartir varias áreas de trabajo en una sola subred. Debe tener un nuevo par de subredes de host y de contenedor para cada área de trabajo que implemente.
Solución de problemas
Instancias inaccesibles: los recursos no son accesibles a través de SSH.
Causa posible: el tráfico del plano de control a los trabajos está bloqueado. Si va a implementar en una red virtual existente conectada a la red local, revise la configuración con la información que se proporciona en Conexión del área de trabajo de Azure Databricks a una red local.
Error de inicio inesperado: se ha producido un error inesperado al configurar el clúster. Pruebe otra vez y póngase en contacto con Azure Databricks si el problema persiste. Mensaje de error interno: Timeout while placing node.
Causa posible: el tráfico de los trabajados a los puntos de conexión de Azure Storage está bloqueado. Si usa servidores DNS personalizados, compruebe también el estado de los servidores DNS de la red virtual.
Cloud Provider Launch Failure: A cloud provider error was encountered while setting up the cluster (Error de inicio de proveedor en la nube: Se detectó un error de proveedor en la nube al configurar el clúster). Consulte la guía de Azure Databricks para obtener más información. Código de error de Azure: AuthorizationFailed/InvalidResourceReference.
Posible causa: la red virtual o las subredes ya no existen. Asegúrese de que existen la red virtual y las subredes.
Clúster terminado. Motivo: Error de inicio de Spark: Spark no pudo iniciarse a tiempo. Este problema puede deberse a Hive Metastore que no funciona correctamente, configuraciones de Spark no válidas o scripts de init que no funcionan correctamente. Consulte los registros de controlador de Spark para solucionar este problema, y póngase en contacto con Databricks si el problema persiste. Mensaje de error interno: Spark failed to start: Driver failed to start in time.
Posible causa: el contenedor no puede comunicarse con la instancia que hospeda ni con la cuenta de almacenamiento del área de trabajo. Para corregirlo, agregue una ruta personalizada a las subredes de la cuenta de almacenamiento del área de trabajo con el próximo salto siendo Internet.