Boas práticas DNS personalizadas para redes virtuais do Azure Databricks workspace

Quando você implanta um workspace do Azure Databricks em sua própria rede virtual (injeção de VNet), pode configurar o VNet para usar servidores DNS personalizados em vez do DNS fornecido pelo Azure. O DNS personalizado é comum quando um espaço de trabalho precisa resolver nomes de host no ambiente local, usar um encaminhador de DNS centralizado em uma topologia hub-and-spoke ou aplicar filtragem em nível de DNS.

O DNS personalizado dá a você controle sobre a resolução de nomes, mas também faz da resolução de nomes sua responsabilidade. Se seus servidores DNS personalizados não conseguem resolver os nomes que a computação clássica precisa, os clusters não iniciam e perdem a conectividade de saída para fontes de dados externas e repositórios de bibliotecas. Este artigo descreve a configuração personalizada recomendada de DNS para espaços de trabalho injetados no VNet, as configurações incorretas mais comuns e como solucioná-las.

Como o Azure Databricks usa DNS em um espaço de trabalho injetado por VNet

Os nós de computação clássicos são executados nas sub-redes de contêiner (privada) e de host (pública) da sua VNet. Durante a inicialização e a operação do cluster, esses nós devem conseguir resolver e acessar vários endpoints do Azure Databricks e do Azure. Se a conectividade segura entre clusters (SCC) estiver ativada, cada cluster abrirá uma conexão de saída com o relé do SCC no plano de controle durante a criação do cluster, portanto a resolução de nomes deverá funcionar antes que um cluster possa entrar em funcionamento.

Os endpoints dos quais a computação clássica depende incluem:

Classic compute acessa o plano de controle e o aplicativo web por meio de faixas de IP regionais, em vez de um nome de host exposto ao cliente, portanto o Azure Databricks recomenda adicioná-los à lista de permissões usando a tag de serviço AzureDatabricks em suas tabelas de rotas, grupos de segurança de rede ou firewall. Alguns firewalls, como o Palo Alto, não conseguem consumir tags de serviço do Azure. Nesses casos, coloque na lista de permissões os intervalos de IP subjacentes da lista de referência.

A AzureDatabricks etiqueta de serviço já cobre o relé SCC. Se você permitir listar endereços IP específicos em vez da tag de serviço, permita listar o relé SCC pelo FQDN, porque os endereços IP atrás dele mudam. Algumas regiões fazem failover para uma região secundária, portanto a lista de referência pode mostrar mais de um tunnel FQDN para uma região. Adicione todos eles à lista de permissões. Os endpoints metastore, armazenamento e Event Hubs pertencem a outros serviços do Azure com suas próprias tags de serviço, como Sql, Storage, e EventHub. Para obter a lista completa de endereços e FQDNs por região, consulte Metastore, armazenamento de blobs de artefatos, armazenamento de tabelas do sistema, armazenamento de logs de blobs e endereços IP de pontos de extremidade dos Hubs de Eventos.

Configuração DNS personalizada recomendada

Seus servidores DNS personalizados não precisam resolver todos os nomes do Azure e públicos sozinhos. O padrão recomendado é resolver os nomes que você possui e encaminhar todo o resto para o Azure.

Encaminhe consultas não resolvidas para DNS do Azure

Configure seus servidores DNS personalizados para encaminhar condicionalmente os nomes que eles não conseguem resolver para o resolvedor DNS fornecido pelo Azure no endereço 168.63.129.16IP virtual. O DNS do Azure resolve os nomes do plano de controle do Azure Databricks, do armazenamento, do metastore e de outros serviços do Azure para você, e continua funcionando mesmo quando esses endereços mudam.

No mínimo, encaminhe condicionalmente os seguintes domínios para o DNS do Azure e encaminhe quaisquer domínios de armazenamento e serviços Azure que suas cargas de trabalho utilizem:

• *.azuredatabricks.net
• *.privatelink.azuredatabricks.net
• *.databricksapps.com

Resolver endpoints de Link Privado

Se seu espaço de trabalho usa Link Privado do Azure para a conexão clássica com o plano de computação, a resolução de nomes deve retornar os endereços IP dos endpoints privados em vez dos endereços públicos. O Azure cria a zona DNS privada privatelink.azuredatabricks.net e adiciona registros de endereço para os endpoints do workspace, incluindo o endpoint databricks_ui_api e o endpoint browser_authentication usado no logon único. O registro de autenticação do navegador usa o formato pl-auth.<region>.

Quando um workspace usa DNS personalizado, seus nós de computação clássicos enviam consultas DNS para seus servidores DNS personalizados em vez de para o DNS do Azure. Uma zona DNS privada vinculada a uma VNet é consultada apenas por meio do resolvedor fornecido pelo Azure em 168.63.129.16, pelo que a ligação da zona por si só não devolve os endereços de ponto final privado para calcular que consulta um resolvedor personalizado. Ambos os seguintes requisitos são exigidos:

• Vincule a privatelink.azuredatabricks.net zona DNS privada à rede virtual (VNet) na qual o DNS do Azure resolve a consulta: a VNet do seu espaço de trabalho ou a VNet de hub que hospeda seu resolvedor em uma topologia de hub e spoke. Isto dá ao DNS do Azure os registos de endereço de ponto final privado a devolver.
• Configure seus servidores DNS personalizados para encaminhar condicionalmente *.privatelink.azuredatabricks.net e *.azuredatabricks.net para o DNS do Azure em 168.63.129.16. O encaminhamento é o que envia a consulta para a zona privada DNS vinculada. Em uma topologia hub-and-spoke, encaminhe para o resolvedor central que tem acesso ao DNS do Azure.

Se a zona DNS privada não estiver vinculada, ou estiver vinculada mas sem o registro de endereço de um endpoint, o DNS do Azure volta à recursão pública e retorna o endereço IP público do endpoint. A resolução de nomes parece ter sucesso, mas o tráfego vai para o endpoint público em vez do endpoint privado. Confirme que a zona vinculada contém os registros de endereço esperados para cada endpoint privado que o workspace utiliza.

Outros endpoints privados do Azure, como armazenamento, usam suas próprias zonas privadas DNS no Azure, por exemplo privatelink.dfs.core.windows.net e privatelink.blob.core.windows.net. Aplique o mesmo padrão: vincule essas zonas e encaminhe condicionalmente os domínios correspondentes privatelink para o DNS do Azure para que as zonas vinculadas sejam consultadas. A integração do DNS de endpoint privado apresenta vários cenários, dependendo da sua configuração. Para detalhes, veja integração DNS do Azure Private Endpoint.

Para a configuração completa de front-end e back-end do Link Privado, veja Configurar a conectividade privada do plano de computação clássico com o Azure Databricks e Configurar o Link Privado de entrada para espaços de trabalho.

Configurações incorretas comuns de DNS personalizado

A maioria dos casos de suporte a DNS personalizado vem de uma das seguintes configurações erradas:

• Sem encaminhamento para o DNS do Azure. Servidores DNS personalizados não conseguem resolver nomes de plano de controle, armazenamento ou metastore do Azure Databricks e não encaminham as consultas para 168.63.129.16. Clusters não iniciam ou não conseguem acessar o armazenamento e o metastore após serem iniciados.
• Vínculo, encaminhamento ou registros na zona DNS privada ausentes. O workspace utiliza o Link Privado, mas o VNet não está ligado à zona privatelink.azuredatabricks.net, não encaminha para o DNS do Azure ou a zona ligada não tem o registo de endereço correto para um ponto final. Nomes resolvem para endereços IP públicos, endereço errado ou nada, então a conectividade privada falha.
• Servidores DNS personalizados inacessíveis. Os endereços dos servidores DNS personalizados na VNet estão incorretos, ou as regras de rede impedem que as sub-redes de computação os alcancem, por exemplo, quando a VNet do espaço de trabalho não está em emparelhamento com a VNet que hospeda seus servidores DNS personalizados. Toda a resolução de nomes falha.
• Resolvedor local sem encaminhamento para o Azure. Consultas DNS são direcionadas para um resolver local que resolve nomes internos, mas não pode resolver ou encaminhar nomes do Azure. Adicionar encaminhamento condicional para os domínios Azure e Azure Databricks.
• Repositórios de bibliotecas bloqueados. O DNS resolve os endpoints necessários do Azure Databricks, mas não os repositórios de bibliotecas públicas, então as instalações de bibliotecas do PyPI, Maven ou CRAN falham.

Solucionar problemas de DNS personalizado

Se clusters falharem ao iniciar ou perderem conectividade, verifique a resolução DNS de um cluster.

1. Crie um cluster no espaço de trabalho. Se o cluster falhar ao iniciar e o registro de eventos mostrar um erro como Cluster terminated. Reason: Control Plane Request Failure, o cluster não consegue alcançar o plano de controle, o que geralmente é um problema de resolução de nomes.

2. A partir de um notebook em um cluster em execução, resolva um endpoint necessário para confirmar que seu DNS personalizado retorna o endereço esperado. Para um workspace do Link Privado, verifique se a URL do workspace se resolve para o endereço IP do endpoint privado, em vez de um endereço público.

   %sh
   nslookup adb-<workspace-id>.<n>.azuredatabricks.net
   nslookup tunnel.<region>.azuredatabricks.net
   

   Se clusters não conseguirem iniciar de jeito nenhum, por exemplo por causa de um problema de Link Privado no back-end, execute essas verificações a partir de uma VM Azure na sub-rede pública do VNet do workspace, em vez de um notebook.

3. Se a resolução falhar ou retornar o endereço errado, verifique o seguinte. Quando um cluster falha em iniciar por causa do DNS, o log de eventos do cluster nomeia a verificação de saúde da rede que falhou, mostrada entre parênteses:

   • Os endereços personalizados dos servidores DNS do VNet estão corretos, e as sub-redes de computação podem alcançar esses servidores (X_NHC_DNS_SERVER_UNREACHABLE).
   • Os seus servidores DNS personalizados encaminham condicionalmente os domínios Azure e Azure Databricks para DNS do Azure em 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, quando o plano de controlo ou os nomes de armazenamento de artefatos não são resolvidos).
   • Para o Link Privado, a privatelink.azuredatabricks.net zona está vinculada ao VNet onde o DNS do Azure resolve, seus servidores DNS personalizados encaminham os domínios do Azure Databricks para o DNS do Azure, e os registros de endereço esperados existem (X_NHC_CONTROL_PLANE_HTTP_ERROR, quando o endpoint privado do plano de controle não se resolve).

4. Se clusters iniciarem, mas não conseguirem acessar recursos on-premises ou outras plataformas Azure como serviço (PaaS), confirme que existem rotas definidas pelo usuário para esses destinos, pois roteamento e DNS são configurados separadamente.

Se ainda não conseguir resolver o problema, entre em contato com as equipes de contas da Microsoft e do Azure Databricks.

Recursos adicionais

• Implante o Azure Databricks na sua rede virtual do Azure (injeção de VNet)
• Conecte seu espaço de trabalho do Azure Databricks à rede local
• Configurações de rota definidas pelo usuário para o Azure Databricks
• Configurar a conectividade privada do plano de computação clássico com o Azure Databricks
• Metastore, armazenamento de blobs de artefatos, armazenamento de tabelas de sistema, armazenamento de blobs de log e endereços IP de ponto de extremidade de Hubs de Eventos do Azure