Compartilhar via

Implantar o Azure Databricks em sua rede virtual do Azure (injeção de VNet)

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

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

A implantação padrão do Azure Databricks é um serviço totalmente gerenciado no Azure. Uma rede virtual (VNet) do Azure é implantada em um grupo de recursos bloqueado. Todos os recursos clássicos do plano de computação são associados a essa VNet. Se você precisar de personalização de rede, poderá implantar recursos do plano de computação clássico do Azure Databricks em sua própria rede virtual. Isso permite:

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

Importante

Você não pode substituir a VNet associada a um espaço de trabalho existente do Azure Databricks. Caso a VNet do seu workspace atual tenha capacidade insuficiente para acomodar o número necessário de nós ativos do cluster, siga estas etapas:

  1. Para espaços de trabalho com injeção em VNet: amplie o intervalo CIDR da sub-rede: para aumentar o espaço de endereços IP disponível para seu espaço de trabalho, você pode solicitar uma atualização do intervalo CIDR da sub-rede do espaço de trabalho. Para fazer essas alterações, entre em contato com sua equipe de conta do Azure Databricks.
  2. Para workspaces que não foram injetados em uma VNet: crie um workspace em uma VNet maior que possa acomodar suas demandas de carga de trabalho.

Requisitos de rede virtual

A VNet na qual o workspace do Azure Databricks vai ser implantado deve atender aos seguintes requisitos:

  • Região: a VNet deve residir na mesma região e assinatura do workspace do Azure Databricks.
  • Assinatura: a VNet deve estar na mesma assinatura que o workspace 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 diretrizes sobre o máximo de nós de cluster com base no tamanho da VNet e das sub-redes, confira Espaço de endereço e máximo de nós de cluster.
  • Sub-redes: a VNet deve incluir duas sub-redes dedicadas ao workspace do Azure Databricks: uma sub-rede de contêiner (também chamada de sub-rede privada) e uma sub-rede de host (também chamada de sub-rede pública). Quando você implanta um workspace usando conectividade de cluster segura, a sub-rede de contêiner e a sub-rede de host usam IPs privados. Você não pode compartilhar sub-redes entre workspaces ou implantar outros recursos do Azure nas sub-redes usadas pelo workspace do Azure Databricks. Para obter diretrizes sobre o máximo de nós de cluster com base no tamanho da VNet e das sub-redes, confira Espaço de endereço e máximo de nós de cluster.

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

Um workspace com uma rede virtual pequena pode ficar sem endereços IP (espaço de rede) mais rapidamente do que um workspace com uma rede virtual grande. Use um bloco CIDR entre /16 e /24 para a VNet e um bloco CIDR até /26 para as duas sub-redes (a sub-rede de contêiner e a sub-rede de host). Você pode criar um bloco CIDR até /28 para 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ço da VNet afeta o número máximo de nós de cluster que o seu workspace pode usar.

Um workspace do Azure Databricks requer duas sub-redes na VNet: 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 endereços IP para cada nó de cluster: um para o host na sub-rede correspondente e outro para o contêiner na sua sub-rede.

  • Talvez você não queira usar todo o espaço de endereço da sua VNet. Por exemplo, o ideal é criar vários workspaces em uma VNet. Como você não pode compartilhar sub-redes entre workspaces, talvez queira ter sub-redes que não usem o espaço de endereço total da VNet.
  • 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 sobrepõem o 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 baseado no tamanho da rede. Essa tabela supõe que não existam sub-redes adicionais que ocupem espaço de endereço. Use sub-redes menores se você tiver sub-redes preexistentes ou se quiser reservar espaço de endereço para outras sub-redes:

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

Para saber o número máximo de nós de cluster com base no tamanho da sub-rede, use a tabela a seguir. A coluna endereços IP por sub-rede inclui os cinco endereços IP reservados para o Azure. A coluna mais à direita indica o número de nós de cluster que podem ser executados simultaneamente em um workspace 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 2.048 2043
/22 1024 1019
/23 512 507
/24 256 251
/25 128 123
/26 64 59

Endereços IP de saída ao usar a conectividade de cluster seguro

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

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. Se você configurar listas de acesso de IP, esses endereços IP públicos deverão ser adicionados a uma lista de permissões. Veja Configuração de listas de acesso IP para áreas de trabalho.

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. Confira este comunicado. Isso significa que as áreas de trabalho do Azure Databricks que usam o acesso de saída padrão em vez de um IP público de saída estável poderiam não funcionar mais após essa data. O Databricks recomenda que você adicione métodos de saída explícitos para seus workspaces antes dessa data.

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

Recursos compartilhados e emparelhamento

Se forem necessários recursos de rede compartilhados, como DNS, o Databricks recomenda enfaticamente que você siga as melhores práticas do Azure para o modelo hub and 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 o emparelhamento, o Databricks recomenda enfaticamente que você adicione regras de Negação aos grupos de segurança de rede (NSGs) que estão anexados a outras redes e sub-redes que estão na mesma VNet ou que estejam emparelhadas com essa VNet. Adicione regras de Negação de conexões para conexões de entrada e saída, de modo que elas limitem as conexões de e para os recursos de computação do Azure Databricks. Se o seu 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 do grupo de segurança de rede.

Criar um workspace do Azure Databricks usando o portal do Azure

Esta seção descreve como criar um workspace do Azure Databricks no portal do Azure e implantá-lo na sua VNet existente. O Azure Databricks atualiza a VNet com duas novas sub-redes caso elas ainda não existam, usando os intervalos CIDR que você especificar. O serviço também atualiza as sub-redes com um novo grupo de segurança de rede, configura as regras de entrada e saída e, por fim, implanta o espaço de trabalho na VNet atualizada. Para obter mais controle sobre a configuração da VNet, use modelos do Azure Resource Manager (ARM) fornecidos pelo Azure Databricks em vez do portal. Por exemplo, use os grupos de segurança de rede existentes ou crie as suas regras de segurança. Confira 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 de redes para a Rede Virtual correspondente ou uma função personalizada com as permissões Microsoft.Network/virtualNetworks/subnets/join/action e Microsoft.Network/virtualNetworks/subnets/write atribuídas.

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

Use sub-redes existentes ou especifique nomes e intervalos de IP para novas sub-redes ao configurar a área de trabalho.

  1. No portal do Azure, selecione + Criar um recurso > Análise > Azure Databricks ou pesquise por Azure Databricks e clique em Criar ou +Adicionar para inicializar a caixa de diálogo do Azure Databricks Service.

  2. Siga as etapas de configuração descritas no guia de início rápido Criar um workspace do Azure Databricks na sua 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 workspace corresponde à região do Azure da VNet desejada.

    Selecione a rede virtual

  4. Escolha o nome das suas sub-redes e forneça os intervalos CIDR em um bloco com tamanho até /26. Para obter diretrizes sobre o máximo de nós de cluster com base no tamanho da VNet e das sub-redes, confira Espaço de endereço e máximo de nós de cluster. Os intervalos do CIDR da sub-rede não podem ser alterados depois que o espaço de trabalho for implantado.

    • Para especificar sub-redes existentes, especifique os nomes exatos das respectivas sub-redes. Ao usar sub-redes existentes, defina também os intervalos de IP no formulário de criação do workspace para corresponder exatamente aos intervalos de IP das sub-redes existentes.
    • Para criar sub-redes, especifique nomes de sub-rede que ainda não existam na VNet. As sub-redes são criadas com os intervalos de IP especificados. Você deve especificar intervalos de IP que estejam dentro do intervalo de IP da VNet e não estejam alocados a 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 as regras de grupo de segurança de rede associadas que incluem a regra para permitir a comunicação interna do cluster. O Azure Databricks tem permissões delegadas para atualizar ambas as sub-redes por meio do provedor de recursos Microsoft.Databricks/workspaces. Essas permissões se aplicam somente às regras de grupo de segurança de rede que são exigidas pelo Azure Databricks e não se aplicam às outras regras adicionadas por você e nem às regras padrão incluídas em todos os grupos de segurança de rede.

  5. Clique em Criar para implantar o workspace do Azure Databricks na VNet.

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

Para obter mais controle sobre a configuração da VNet, use os modelos do Azure Resource Manager (ARM) a seguir em vez da configuração automática de VNet e implantação de workspace baseadas na UI do portal. Por exemplo, use as sub-redes existentes, um grupo de segurança de rede existente ou adicione as suas regras de segurança.

Se você estiver usando um modelo do Azure Resource Manager personalizado ou o Modelo de Workspace para injeção de VNet do Azure Databricks para implantar um workspace em uma VNet existente, você deverá criar sub-redes de host e de contêiner, anexar um grupo de segurança de rede em cada sub-rede e delegar as sub-redes ao provedor de recursos Microsoft.Databricks/workspacesantes de implantar o workspace. Você precisa ter um par de sub-redes separadas para cada workspace implantado.

Modelo tudo em um

Para criar uma VNet e um workspace do Azure Databricks usando um modelo, use o Modelo Tudo em Um para Workspaces do Azure Databricks com Injeção de VNet.

Modelo de rede virtual

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

Modelo de workspace do Azure Databricks

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

O modelo de workspace permite que você especifique uma VNet existente e use as sub-redes existentes:

  • Você precisa ter um par de sub-redes de host e de contêiner separadas para cada workspace implantado. Não há suporte para compartilhar sub-redes entre workspaces ou para implantar outros recursos do Azure nas sub-redes usadas pelo workspace do Azure Databricks.

  • As sub-redes de host e contêiner da VNet 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 workspace.

  • Para criar uma VNet com as sub-redes delegadas corretamente, use o Modelo de VNet para Injeção de VNet do Databricks.

  • Para usar uma VNet existente quando você ainda não tiver delegado as sub-redes de host e contêiner, consulte Adicionar ou remover uma delegação de sub-rede.

Regras de grupo de segurança de rede

As tabelas a seguir exibem as regras de grupo de segurança de rede atuais usadas pelo Azure Databricks. Você vai receber uma notificação antecipada caso o Azure Databricks precise adicionar uma regra ou alterar o escopo de uma regra existente nessa lista. Este artigo e as tabelas sã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 nas seções a seguir são provisionadas automaticamente e gerenciadas pelo Azure Databricks por meio da delegação das sub-redes de host e contêiner da VNet para o serviço Microsoft.Databricks/workspaces. Você não deve atualizar ou excluir essas regras, pois elas são protegidas pela delegação de sub-rede. Essas regras são essenciais para que a Microsoft opere de forma confiável e dê suporte ao Azure Databricks em sua VNet.

Algumas regras NSG usam VirtualNetwork como origem e destino para simplificar o design na ausência de marcas de serviço no nível da sub-rede. Todos os clusters são protegidos por políticas de rede internas que impedem a comunicação entre clusters, mesmo entre workspaces diferentes implantados na mesma VNet gerenciada pelo cliente.

O Azure Databricks recomenda que cada espaço de trabalho use um NSG exclusivo.

Importante

O Databricks recomenda enfaticamente que você adicione regras de Negação aos grupos de segurança de rede (NSGs) que estejam conectados a outras redes e sub-redes que estejam na mesma VNet ou que estejam emparelhadas com essa VNet. Adicione regras de Negação de conexão para conexões de entrada e saída para que elas limitem as conexões para e de recursos de computação do Azure Databricks. Se o seu 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 workspaces

Esta tabela lista as regras do grupo de segurança de rede para workspaces e inclui duas regras de grupo de segurança de entrada incluídas somente se a SCC (conectividade de cluster segura) estiver desabilitada.

Direção Protocolo Fonte Porta de origem Destino Porta de destino Usado
Entrada Qualquer Rede Virtual Qualquer Rede Virtual Qualquer Padrão
Entrada TCP AzureDatabricks (marca de serviço)
Somente se a SCC estiver desabilitada		 Qualquer Rede Virtual 22 IP público
Entrada TCP AzureDatabricks (marca de serviço)
Somente se a SCC estiver desabilitada		 Qualquer Rede Virtual 5557 IP público
Saída TCP Rede Virtual Qualquer AzureDatabricks (marca de serviço) 443, 3306, 8443-8451 Padrão
Saída TCP Rede Virtual Qualquer SQL 3306 Padrão
Saída TCP Rede Virtual Qualquer Armazenamento 443 Padrão
Saída Qualquer Rede Virtual Qualquer Rede Virtual Qualquer Padrão
Saída TCP Rede Virtual Qualquer Hub de Eventos 9093 Padrão

Observação

Se você restringir as regras de saída, a Databricks recomendará que você abra as portas 111 e 2049 para permitir determinadas instalações de biblioteca.

Importante

O Azure Databricks é um serviço interno do Microsoft Azure implantado na infraestrutura de Nuvem Pública Global do Azure. Toda a comunicação feita entre os componentes do serviço, incluindo os IPs públicos do painel de controle e do plano de computação do cliente, permanecem no backbone de rede do Microsoft Azure. Confira também Rede global da Microsoft.

Solução de problemas

A sub-rede <subnet-id> exige uma das delegações [Microsoft.Databricks/workspaces] a seguir para referenciar o link de associação de serviço

Causa possível: você está criando um workspace em uma VNet cujas sub-redes de host e de contêiner não foram delegadas para o serviço Microsoft.Databricks/workspaces. Cada sub-rede deve ter um grupo de segurança de rede anexado e ser adequadamente delegada. Confira Requisitos de rede virtual para obter mais informações.

A sub-rede <subnet-id> já está sendo usada pelo workspace <workspace-id>

Causa possível: você está criando um workspace em uma VNet com sub-redes de host e de contêiner que já estão sendo usadas por um workspace já existente do Azure Databricks. Não é possível compartilhar vários workspaces em uma sub-rede. Você deve ter um novo par de sub-redes de host e de contêiner para cada área de trabalho implantada.

Instâncias Inacessíveis: os recursos não estavam acessíveis via SSH.

Causa possível: o tráfego do plano de controle para os trabalhadores está bloqueado. Se estiver fazendo a implantação em uma VNet existente conectada à rede local, examine sua configuração usando as informações fornecidas em Conectar seu workspace do Azure Databricks à rede local.

Falha Inesperada de Lançamento: foi encontrado um erro inesperado durante a configuração do cluster. Tente novamente e entre em contato com o Azure Databricks se o problema persistir. Mensagem de erro interna: Timeout while placing node.

Causa possível: o tráfego da função de trabalho para os pontos de extremidade do Armazenamento do Azure está bloqueado. Se você estiver usando servidores DNS personalizados, verifique também o status dos servidores DNS na sua VNet.

Falha ao iniciar o Provedor de Nuvem: foi encontrado um erro do provedor de nuvem durante a configuração do cluster. Consulte o guia do Azure Databricks para obter mais informações. O código do erro do Azure: AuthorizationFailed/InvalidResourceReference.

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

Cluster encerrado. Motivo: falha de inicialização do Spark: o Spark não pôde ser iniciado a tempo. Esse problema pode ser causado por um metastore do Hive com defeito, por configurações inválidas do Spark ou por scripts init com defeito. Consulte os logs do driver do Spark para solucionar esse problema e entre em contato com o Databricks se o problema continuar. Mensagem de erro interna: Spark failed to start: Driver failed to start in time.

Causa possível: O contêiner não pode falar com a instância de hospedagem ou com a conta de armazenamento do workspace. Corrija adicionando uma rota personalizada às sub-redes para a conta de armazenamento do workspace com o próximo salto sendo a internet.

Conflito com a política de intenção de rede

Ao criar um novo workspace do Databricks, verifique se a regra de saída do NSG da sua rede virtual para a tag de serviço do Databricks permite o tráfego nas portas 443, 3306 e 8443-8451. Os workspaces existentes também devem ter essas portas habilitadas. O Databricks irá notificá-lo em julho de 2024 caso as regras do NSG não sejam atualizadas e essas portas não estejam habilitadas. Para resolver isso, habilite as portas 443, 3306 e 8443-8451 na regra de saída do NSG.

Confira Atualizações para regras de grupo de segurança de rede e Regras de grupo de segurança de rede para workspaces.