Implementar o Azure Databricks na rede virtual do Azure (injeção de VNet)

Este artigo descreve como implantar um espaço de trabalho do Azure Databricks em sua própria rede virtual do Azure, também conhecida como injeção de VNet.

Personalização de rede com injeção de VNet

A implementação predefinida do Azure Databricks é um serviço totalmente gerido no Azure. Uma rede virtual do Azure (VNet) é implantada em um grupo de recursos bloqueado. Todos os recursos clássicos do plano de computação estão associados a essa VNet. Se você precisar de personalização de rede, poderá implantar recursos de plano de computação clássico do Azure Databricks em sua própria rede virtual. Permite-lhe:

• Conecte o Azure Databricks a outros serviços do Azure (como o Armazenamento do Azure) de maneira mais segura usando pontos de extremidade de serviço ou pontos de extremidade privados do Azure.
• Conecte-se a fontes de dados locais usando rotas definidas pelo usuário. Consulte Configurações de rota definidas pelo usuário para o Azure Databricks.
• Conecte o Azure Databricks a um dispositivo virtual de rede para inspecionar todo o tráfego de saída e executar ações de acordo com as regras de permissão e negação. Consulte Opção: Rotear o tráfego do Azure Databricks usando um dispositivo virtual ou firewall
• Configure o Azure Databricks para usar DNS personalizado. Consulte Opção: Configurar DNS personalizado.
• Configure regras de NSG (grupo de segurança de rede) para especificar restrições de tráfego de saída.

A implantação de recursos do plano de computação clássico do Azure Databricks em sua própria VNet também permite que você aproveite os intervalos CIDR flexíveis. Para a rede virtual, você pode usar o tamanho /16-/24do intervalo CIDR. Para as sub-redes, use intervalos de IP tão pequenos quanto /26.

Importante

Não é possível substituir a VNet para um espaço de trabalho existente. Se a área de trabalho atual não conseguir acomodar o número necessário de nós de cluster ativos, recomendamos que crie outra área de trabalho numa VNet maior. Siga estes passos de migração detalhados para copiar os recursos (blocos de notas, configurações de cluster, tarefas) da área de trabalho antiga para a nova.

Requisitos de rede virtual

A VNet na qual você implanta seu espaço de trabalho do Azure Databricks deve atender aos seguintes requisitos:

• Região: A rede virtual deve residir na mesma região e assinatura que o espaço de trabalho do Azure Databricks.
• Assinatura: a VNet deve estar na mesma assinatura que o espaço de trabalho do Azure Databricks.
• Espaço de endereço: um bloco CIDR entre /16 e /24 para a VNet e um bloco CIDR até /26 para as duas sub-redes: uma sub-rede de contêiner e uma sub-rede de host. Para obter orientação sobre o máximo de nós de cluster com base no tamanho da VNet e suas sub-redes, consulte Espaço de endereçamento e nós máximos de cluster.
• Sub-redes: a rede virtual deve incluir duas sub-redes dedicadas ao seu espaço de trabalho do Azure Databricks: uma sub-rede de contêiner (às vezes chamada de sub-rede privada) e uma sub-rede de host (às vezes chamada de sub-rede pública). Quando você implanta um espaço de trabalho usando conectividade de cluster segura, tanto a sub-rede de contêiner quanto a sub-rede de host usam IPs privados. Não é possível compartilhar sub-redes entre espaços de trabalho ou implantar outros recursos do Azure nas sub-redes usadas pelo seu espaço de trabalho do Azure Databricks. Para obter orientação sobre o máximo de nós de cluster com base no tamanho da VNet e suas sub-redes, consulte Espaço de endereçamento e nós máximos de cluster.

Espaço de endereçamento e máximo de nós de cluster

Um espaço de trabalho com uma rede virtual menor pode ficar sem endereços IP (espaço de rede) mais rapidamente do que um espaço de trabalho com uma rede virtual maior. Use um bloco CIDR entre /16 e /24 para a VNet e um bloco CIDR até para /26 as duas sub-redes (a sub-rede do contêiner e a sub-rede do host). Você pode criar um bloco CIDR para /28 suas sub-redes, no entanto, o Databricks não recomenda uma sub-rede menor que /26.

O intervalo CIDR para o espaço de endereçamento da rede virtual afeta o número máximo de nós de cluster que o espaço de trabalho pode usar.

Um espaço de trabalho do Azure Databricks requer duas sub-redes na rede virtual: uma sub-rede de contêiner e uma sub-rede de host. O Azure reserva cinco IPs em cada sub-rede. O Azure Databricks requer dois IP para cada nó de cluster: um endereço IP para o host na sub-rede do host e um endereço IP para o contêiner na sub-rede do contêiner.

• Talvez você não queira usar todo o espaço de endereço da sua rede virtual. Por exemplo, talvez você queira criar vários espaços de trabalho em uma VNet. Como não é possível compartilhar sub-redes entre espaços de trabalho, convém que as sub-redes não usem o espaço total de endereços da rede virtual.
• Você deve alocar espaço de endereço para duas novas sub-redes que estão dentro do espaço de endereço da VNet e não sobrepor espaço de endereço de sub-redes atuais ou futuras nessa VNet.

A tabela a seguir mostra o tamanho máximo da sub-rede com base no tamanho da rede. Esta tabela pressupõe que não existam sub-redes adicionais que ocupem espaço de endereço. Use sub-redes menores se tiver sub-redes pré-existentes ou se quiser reservar espaço de endereço para outras sub-redes:

Espaço de endereçamento VNet (CIDR)	Tamanho máximo da sub-rede do Azure Databricks (CIDR) assumindo que não há outras sub-redes
/16	/17
/17	/18
/18	/19
/20	/21
/21	/22
/22	/23
/23	/24
/24	/25

Para localizar o máximo de nós de cluster com base no tamanho da sub-rede, use a tabela a seguir. Os endereços IP por coluna de sub-rede incluem os cinco endereços IP reservados do Azure. A coluna mais à direita indica o número de nós de cluster que podem ser executados simultaneamente em um espaço de trabalho provisionado com sub-redes desse tamanho.

Tamanho da sub-rede (CIDR)	Endereços IP por sub-rede	Máximo de nós de cluster do Azure Databricks
/17	32768	32763
/18	16384	16379
/19	8192	8187
/20	4096	4091
/21	2048	2043
/22	1024	1019
/23	512	507
/24	256	251
/25	128	123
/26	64	59

Saída de endereços IP ao usar conectividade de cluster segura

Se você habilitar a conectividade segura de cluster em seu espaço de trabalho que usa injeção de VNet, o Databricks recomenda que seu espaço de trabalho tenha um IP público de saída estável.

Endereços IP públicos de saída estáveis são úteis porque você pode adicioná-los a listas de permissões externas. Por exemplo, para se conectar do Azure Databricks ao Salesforce com um endereço IP de saída estável.

Aviso

A Microsoft anunciou que, em 30 de setembro de 2025, a conectividade de acesso de saída padrão para máquinas virtuais no Azure será desativada. Veja este anúncio. Isso significa que os espaços de trabalho do Azure Databricks que usam acesso de saída padrão em vez de um IP público de saída estável podem não continuar a funcionar após essa data. O Databricks recomenda que você adicione métodos de saída explícitos para seus espaços de trabalho antes dessa data.

Para configurar um IP público de saída estável, consulte Saída com injeção de VNet

Recursos partilhados e emparelhamento

Se recursos de rede compartilhados, como DNS, forem necessários, o Databricks recomenda que você siga as práticas recomendadas do Azure para o modelo hub e spoke. Use o emparelhamento de VNet para estender o espaço IP privado da VNet do espaço de trabalho para o hub, mantendo os raios isolados uns dos outros.

Se você tiver outros recursos na VNet ou usar emparelhamento, o Databricks recomenda que você adicione regras de Negar aos NSGs (grupos de segurança de rede) conectados a outras redes e sub-redes que estão na mesma VNet ou estão emparelhados a essa VNet. Adicione regras de Negar para conexões de entrada e saída para que limitem as conexões de e para recursos de computação do Azure Databricks. Se o cluster precisar de acesso a recursos na rede, adicione regras para permitir apenas a quantidade mínima de acesso necessária para atender aos requisitos.

Para obter informações relacionadas, consulte Regras de grupo de segurança de rede.

Criar um espaço de trabalho do Azure Databricks usando o portal do Azure

Esta seção descreve como criar um espaço de trabalho do Azure Databricks no portal do Azure e implantá-lo em sua própria VNet existente. O Azure Databricks atualiza a VNet com duas novas sub-redes se elas ainda não existirem, usando intervalos CIDR que você especificar. O serviço também atualiza as sub-redes com um novo grupo de segurança de rede, configurando regras de entrada e saída e, finalmente, implanta o espaço de trabalho na VNet atualizada. Para obter mais controle sobre a configuração da rede virtual, use modelos do Azure Resource Manager (ARM) fornecidos pelo Azure Databricks em vez do portal. Por exemplo, use grupos de segurança de rede existentes ou crie suas próprias regras de segurança. Consulte Configuração avançada usando modelos do Azure Resource Manager.

O usuário que cria o espaço de trabalho deve receber a função de colaborador Rede à Rede Virtual correspondente ou uma função personalizada à qual são atribuídas as Microsoft.Network/virtualNetworks/subnets/join/action permissões e as Microsoft.Network/virtualNetworks/subnets/write permissões.

Você deve configurar uma VNet na qual implantará o espaço de trabalho do Azure Databricks. Você pode usar uma VNet existente ou criar uma nova, mas a VNet deve estar na mesma região e na mesma assinatura que o espaço de trabalho do Azure Databricks que você planeja criar. A VNet deve ser dimensionada com um intervalo CIDR entre /16 e /24. Para obter mais requisitos, consulte Requisitos de rede virtual.

Use sub-redes existentes ou especifique nomes e intervalos de IP para novas sub-redes ao configurar seu espaço de trabalho.

1. No portal do Azure, selecione + Criar um recurso > Analytics > Azure Databricks ou procure Azure Databricks e clique em Criar ou + Adicionar para iniciar a caixa de diálogo Serviço Azure Databricks.

2. Siga as etapas de configuração descritas no espaço de trabalho Criar um Azure Databricks em seu próprio início rápido de VNet .

3. Na guia Rede, selecione a VNet que você deseja usar no campo Rede virtual.

   Importante

   Se você não vir o nome da rede no seletor, confirme se a região do Azure especificada para o espaço de trabalho corresponde à região do Azure da VNet desejada.

   

4. Nomeie suas sub-redes e forneça intervalos CIDR em um bloco até o tamanho /26. Para obter orientação sobre o máximo de nós de cluster com base no tamanho da VNet e suas sub-redes, consulte Espaço de endereçamento e nós máximos de cluster. Os intervalos CIDR da sub-rede não podem ser alterados após a implantação do espaço de trabalho.

   • Para especificar sub-redes existentes, especifique os nomes exatos das sub-redes existentes. Ao usar sub-redes existentes, defina também os intervalos de IP no formulário de criação de espaço de trabalho para corresponder exatamente aos intervalos de IP das sub-redes existentes.
   • Para criar novas sub-redes, especifique nomes de sub-redes que ainda não existem nessa rede virtual. As sub-redes são criadas com os intervalos de IP especificados. Você deve especificar intervalos de IP dentro do intervalo de IP de sua rede virtual e ainda não alocados para sub-redes existentes.

   O Azure Databricks exige que os nomes de sub-rede não tenham mais de 80 caracteres.

   As sub-redes obtêm regras de grupo de segurança de rede associadas que incluem a regra para permitir a comunicação interna do cluster. O Azure Databricks delegou permissões para atualizar ambas as sub-redes por meio do Microsoft.Databricks/workspaces provedor de recursos. Essas permissões se aplicam somente às regras de grupo de segurança de rede exigidas pelo Azure Databricks, não a outras regras de grupo de segurança de rede que você adiciona ou às regras de grupo de segurança de rede padrão incluídas em todos os grupos de segurança de rede.

5. Clique em Criar para implantar o espaço de trabalho do Azure Databricks na rede virtual.

Configuração avançada usando modelos do Azure Resource Manager

Para obter mais controle sobre a configuração da rede virtual, use os seguintes modelos do Azure Resource Manager (ARM) em vez da configuração automática de VNet baseada na interface do usuário do portal e da implantação do espaço de trabalho. Por exemplo, use sub-redes existentes, um grupo de segurança de rede existente ou adicione suas próprias regras de segurança.

Se você estiver usando um modelo personalizado do Azure Resource Manager ou o Modelo de Espaço de Trabalho para Injeção de VNet do Azure Databricks para implantar um espaço de trabalho em uma rede virtual existente, deverá criar sub-redes de host e contêiner, anexar um grupo de segurança de rede a cada sub-rede e delegar as sub-redes ao Microsoft.Databricks/workspaces provedor de recursos antes de implantar o espaço de trabalho. Deve ter um par de sub-redes separadas para cada espaço de trabalho que instalar.

Modelo tudo-em-um

Para criar um espaço de trabalho VNet e Azure Databricks usando um modelo, use o Modelo All-in-one para Espaços de Trabalho Injetados VNet do Azure Databricks.

Modelo de rede virtual

Para criar uma VNet com as sub-redes adequadas usando um modelo, use o Modelo de VNet para injeção de VNet Databricks.

Modelo de espaço de trabalho do Azure Databricks

Para implantar um espaço de trabalho do Azure Databricks em uma VNet existente com um modelo, use o Modelo de Espaço de Trabalho para Injeção de VNet do Azure Databricks.

O modelo de espaço de trabalho permite especificar uma VNet existente e usar sub-redes existentes:

• Você deve ter um par separado de sub-redes de host/contêiner para cada espaço de trabalho implantado. Não há suporte para compartilhar sub-redes entre espaços de trabalho ou implantar outros recursos do Azure nas sub-redes usadas pelo seu espaço de trabalho do Azure Databricks.
• As sub-redes de host e contêiner da rede virtual devem ter grupos de segurança de rede anexados e devem ser delegadas ao Microsoft.Databricks/workspaces serviço antes de usar esse modelo do Azure Resource Manager para implantar um espaço de trabalho.
• Para criar uma VNet com sub-redes delegadas corretamente, use o Modelo de VNet para injeção de VNet Databricks.
• Para usar uma VNet existente quando ainda não tiver delegado as sub-redes de host e contêiner, consulte Adicionar ou remover uma delegação de sub-rede.

Regras do grupo de segurança de rede

As tabelas a seguir exibem as regras atuais do grupo de segurança de rede usadas pelo Azure Databricks. Se o Azure Databricks precisar adicionar uma regra ou alterar o escopo de uma regra existente nessa lista, você receberá um aviso prévio. Este artigo e as tabelas serão atualizados sempre que tal modificação ocorrer.

Como o Azure Databricks gerencia as regras do grupo de segurança de rede

As regras do NSG listadas nas seções a seguir representam aquelas que o Azure Databricks provisiona e gerencia automaticamente em seu NSG, em virtude da delegação das sub-redes de host e contêiner da sua VNet ao Microsoft.Databricks/workspaces serviço. Você não tem permissão para atualizar ou excluir essas regras do NSG e qualquer tentativa de fazê-lo é bloqueada pela delegação da sub-rede. O Azure Databricks deve possuir essas regras para garantir que a Microsoft possa operar e dar suporte confiáveis ao serviço Azure Databricks em sua rede virtual.

Algumas dessas regras NSG têm VirtualNetwork atribuído como origem e destino. Isso foi implementado para simplificar o design na ausência de uma marca de serviço de nível de sub-rede no Azure. Todos os clusters são protegidos por uma segunda camada de diretiva de rede internamente, de modo que o cluster A não possa se conectar ao cluster B no mesmo espaço de trabalho. Isso também se aplica a vários espaços de trabalho se os espaços de trabalho forem implantados em um par diferente de sub-redes na mesma VNet gerenciada pelo cliente.

Importante

O Databricks recomenda enfaticamente que você adicione regras de Negação aos NSGs (grupos de segurança de rede) conectados a outras redes e sub-redes que estão na mesma VNet ou emparelhados a essa VNet. Adicione regras de Negar para conexões de entrada e saída para que limitem as conexões de e para recursos de computação do Azure Databricks. Se o cluster precisar de acesso a recursos na rede, adicione regras para permitir apenas a quantidade mínima de acesso necessária para atender aos requisitos.

Regras de grupo de segurança de rede para espaços de trabalho

As informações nesta seção se aplicam somente aos espaços de trabalho do Azure Databricks criados após 13 de janeiro de 2020. Se o seu espaço de trabalho foi criado antes do lançamento da conectividade segura de cluster (SCC) em 13 de janeiro de 2020, consulte a próxima seção.

Esta tabela lista as regras de grupo de segurança de rede para espaços de trabalho e inclui duas regras de grupo de segurança de entrada que são incluídas somente se a conectividade de cluster seguro (SCC) estiver desabilitada.

Direção	Protocolo	Origem	Porta de origem	Destino	Porto de Dest	Used
Interna	Qualquer	VirtualNetwork	Qualquer	VirtualNetwork	Qualquer	Predefinido
Interna	TCP	AzureDatabricks (etiqueta de serviço) Apenas se o CCS estiver desativado	Qualquer	VirtualNetwork	22	IP público
Interna	TCP	AzureDatabricks (etiqueta de serviço) Apenas se o CCS estiver desativado	Qualquer	VirtualNetwork	5557	IP público
Saída	TCP	VirtualNetwork	Qualquer	AzureDatabricks (etiqueta de serviço)	443, 3306, 8443-8451	Predefinido
Saída	TCP	VirtualNetwork	Qualquer	SQL	3306	Predefinido
Saída	TCP	VirtualNetwork	Qualquer	Armazenamento	443	Predefinido
De Saída	Qualquer	VirtualNetwork	Qualquer	VirtualNetwork	Qualquer	Predefinido
Saída	TCP	VirtualNetwork	Qualquer	EventHub	9093	Predefinido

Nota

Se você restringir as regras de saída, o Databricks recomenda que você abra as portas 111 e 2049 para habilitar determinadas instalações de biblioteca.

Importante

O Azure Databricks é um serviço primário do Microsoft Azure que é implantado na infraestrutura Global da Nuvem Pública do Azure. Todas as comunicações entre componentes do serviço, incluindo entre os IPs públicos no plano de controle e o plano de computação do cliente, permanecem no backbone de rede do Microsoft Azure. Consulte também Rede global da Microsoft.

Resolução de Problemas

Erros de criação de espaço de trabalho

A sub-rede <subnet-id> requer qualquer uma das seguintes delegações: [Microsoft.Databricks/workspaces] para fazer referência ao link de associação de serviço

Causa possível: você está criando um espaço de trabalho em uma rede virtual cujas sub-redes de host e contêiner não foram delegadas ao Microsoft.Databricks/workspaces serviço. Cada sub-rede deve ter um grupo de segurança de rede anexado e deve ser devidamente delegada. Para obter mais informações, veja Requisitos da rede virtual.

A sub-rede <subnet-id> já está em uso pelo espaço de trabalho <workspace-id>

Possível causa: você está criando um espaço de trabalho em uma VNet com sub-redes de host e contêiner que já estão sendo usadas por um espaço de trabalho existente do Azure Databricks. Não é possível partilhar várias áreas de trabalho através de uma única sub-rede. Deve ter um novo par de sub-redes de anfitrião e contentor para cada área de trabalho que implementar.

Resolução de Problemas

Instâncias inacessíveis: os recursos não eram acessíveis via SSH.

Possível causa: o tráfego do avião de controlo para os trabalhadores está bloqueado. Se estiver a implementar numa VNet existente ligada à rede no local, reveja a configuração com as informações apresentadas em Ligar a área de trabalho do Azure Databricks à rede no local.

Falha de inicialização inesperada: um erro inesperado foi encontrado durante a configuração do cluster. Tente novamente e contacte o Azure Databricks se o problema persistir. Mensagem de erro interna: Timeout while placing node.

Possível causa: o tráfego de trabalhadores para pontos de extremidade do Armazenamento do Azure está bloqueado. Se estiver a utilizar servidores DNS personalizados, verifique também o estado dos servidores DNS na VNet.

Falha ao Iniciar o Fornecedor de Cloud: foi encontrado um erro do fornecedor de cloud ao configurar o cluster. Veja o guia do Azure Databricks para obter mais informações. Código de erro do Azure: AuthorizationFailed/InvalidResourceReference.

Causa possível: a VNet ou as sub-redes não existem mais. Verifique se a VNet e as sub-redes existem.

Cluster encerrado. Motivo: Falha de Arranque do Apache Spark: o Apache Spark não conseguiu iniciar a tempo. Este problema pode ser causado por um metastore do Hive em mau funcionamento, configurações inválidas do Apache Spark ou scripts init em mau funcionamento. Veja os registos do controlador do Apache Spark para resolver este problema e contacte a equipa do Databricks se o problema persistir. Mensagem de erro interna: Spark failed to start: Driver failed to start in time.

Possível causa: o contêiner não pode falar com a instância de hospedagem ou a conta de armazenamento DBFS. Corrija ao adicionar uma rota personalizada às sub-redes da conta de armazenamento do DBFS com a Internet como próximo salto.