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

  • Artigo

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

Não é possível substituir a VNet em um workspace existente. Se o seu workspace atual não puder acomodar o número necessário de nós de cluster ativos, recomendamos que você crie outro workspace em uma VNet maior. Siga estas etapas de migração detalhada para copiar recursos (notebooks, configurações de cluster, trabalhos) do workspace antigo para o novo.

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 IPs 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 VNet. Por exemplo, você pode querer 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 dentro do espaço de endereço da VNet e que não sobreponham o espaço de endereço das 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 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 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. Confira este comunicado. Isso significa que os workspaces do Azure Databricks que usam o acesso de saída padrão em vez de um IP público de saída estável podem não continuar funcionando 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 implanta o workspace 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 workspace deve ter atribuída a função de Colaborador de rede para a Rede Virtual correspondente ou uma função personalizada atribuída à ação Microsoft.Network/virtualNetworks/subnets/join/action e as permissões Microsoft.Network/virtualNetworks/subnets/write.

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 especificar nomes e intervalos de IP para novas sub-redes ao configurar o workspace.

  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 ARM (Azure Resource Manager) a seguir em vez da configuração automática de VNet e implantação de workspace baseadas na interface do usuário 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. Deve haver 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 VNet injetada.

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 workspace do Azure Databricks em uma VNet existente com um modelo, use o Modelo de workspace 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:

  • Deve haver 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 de contêiner da VNet devem ter grupos de segurança de rede anexados e devem ser delegadas ao serviço Microsoft.Databricks/workspaces antes do modelo do Azure Resource Manager ser usado 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 de NSG listadas nas seções a seguir representam aquelas que o Azure Databricks provisiona e gerencia automaticamente no seu NSG em virtude da delegação das sub-redes de host e de contêiner da VNet para o serviço Microsoft.Databricks/workspaces. Você não tem permissão para atualizar ou excluir essas regras do NSG, e qualquer tentativa de fazer isso é bloqueada pela delegação da sub-rede. O Azure Databricks deve ser o proprietário dessas regras para garantir que a Microsoft possa operar e dar suporte confiável ao serviço do Azure Databricks na sua VNet.

Algumas dessas regras de 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 no nível da sub-rede no Azure. Todos os clusters são protegidos internamente por uma segunda camada de política de rede de modo que o cluster A não possa se conectar ao cluster B no mesmo workspace. Isso também se aplica a vários workspaces se esses estiverem 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 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

As informações nesta seção se aplicam apenas aos workspaces do Azure Databricks criados após 13 de janeiro de 2020. Se seu workspace tiver sido criado antes do lançamento da SCC (conectividade de cluster segura) em 13 de janeiro de 2020, veja a próxima seção.

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 conectividade de cluster segura (SCC) estiver desabilitada.

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

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

Erros de criação do workspace

A sub-rede <subnet-id> requer uma das seguintes delegações [Microsoft.Databricks/workspaces] 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 do Azure Databricks existente. 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 workspace implantado.

Solução de problemas

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

Causa possível: o tráfego do painel de controle para a função de trabalho 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 nem com a conta de armazenamento do DBFS. Corrija adicionando uma rota personalizada às sub-redes para a conta de armazenamento do DBFS com o próximo salto sendo a Internet.