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

Quando implementa um espaço de trabalho Azure Databricks na sua própria rede virtual (injeção VNet), pode configurar o VNet para usar servidores DNS personalizados em vez do DNS fornecido pelo Azure. DNS personalizado é comum quando um espaço de trabalho tem de resolver nomes de host locais, usar um encaminhador DNS centralizado numa topologia hub-and-spoke, ou aplicar filtragem ao nível de DNS.

O DNS personalizado dá-lhe controlo sobre a resolução de nomes, mas também torna a resolução de nomes da sua responsabilidade. Se os seus servidores DNS personalizados não conseguirem resolver os nomes que a computação clássica precisa, os clusters falham em iniciar e perdem a conectividade de saída para fontes de dados externas e repositórios de bibliotecas. Este artigo descreve a configuração DNS personalizada recomendada para espaços de trabalho injetados por VNet, as configurações erradas mais comuns e como as diagnosticar.

Note

DNS personalizado aplica-se ao plano de computação clássico num espaço de trabalho injetado por VNet. A computação serverless corre na rede Azure Databricks e não utiliza a configuração DNS do seu VNet.

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

Os nós de computação clássicos correm nas subredes container (privada) e host (pública) do seu VNet. Durante o arranque e a operação do cluster, esses nós têm de conseguir resolver e aceder a vários pontos de extremidade do Azure Databricks e do Azure. Se a conectividade segura entre clusters (SCC) estiver ativada, cada cluster estabelece uma ligação de saída ao relay SCC no plano de controlo durante a criação do cluster, pelo que a resolução de nomes tem de ser bem-sucedida antes de um cluster poder ficar operacional.

Os endpoints de que o cálculo clássico depende incluem:

Ponto final Como chegou
Plano de controlo e aplicação Web do Azure Databricks Intervalos regionais de IP, representados pela AzureDatabricks etiqueta de serviço
Relé de conectividade segura do cluster (SCC) O nome de domínio totalmente qualificado (FQDN) tunnel.<region>.azuredatabricks.net
Metastore Legacy Hive consolidated-<region>-prod-metastore.mysql.database.azure.com
Armazenamento raiz de espaço de trabalho (DBFS) Os pontos finais dfs e blob da conta de armazenamento da área de trabalho
Armazenamento de blobs de artefactos e registos dbartifactsprod<region>.blob.core.windows.net, dblogprod<region>.blob.core.windows.net
Event Hubs (registo) prod-<region>-observabilityeventhubs.servicebus.windows.net
Fontes de dados externas e repositórios de bibliotecas Nomes DNS públicos, como repositórios PyPI, Maven e CRAN

A computação clássica chega ao plano de controlo e à aplicação web através de intervalos de IP regionais em vez de um nome de host orientado para o cliente, por isso o Azure Databricks recomenda que os inclua com a AzureDatabricks tag de serviço nas suas tabelas de rota, grupos de segurança de rede ou firewall. Alguns firewalls, como o Palo Alto, não conseguem consumir as etiquetas de serviço do Azure. Nesses casos, permite-listar os intervalos de IPs subjacentes da lista de referências.

A AzureDatabricks etiqueta de serviço já cobre o relé SCC. Se permitires listar endereços IP específicos em vez da etiqueta de serviço, permite listar o relay SCC pelo seu FQDN, porque os endereços IP por trás dele mudam. Algumas regiões fazem failover para uma região secundária, pelo que a lista de referências pode mostrar mais do que um tunnel FQDN para uma região. Adicione todos à lista de permissões. Os endpoints metastore, storage e Event Hubs pertencem a outros serviços Azure com as suas próprias etiquetas de serviço, como Sql, Storage, e EventHub. Para a lista completa, por região, de endereços e FQDNs, consulte Metastore, armazenamento Blob de artefactos, armazenamento de tabelas do sistema, armazenamento Blob de registos e endereços IP do ponto final do Event Hubs.

Os seus servidores DNS personalizados não têm de resolver todos os nomes Azure e públicos por si próprios. O padrão recomendado é resolver os nomes que possui e encaminhar todo o resto para o Azure.

Encaminhe consultas não resolvidas para DNS do Azure

Configure os seus servidores DNS personalizados para encaminharem condicionalmente os nomes que não conseguem resolver para o resolvedor DNS fornecido pelo Azure no endereço 168.63.129.16IP virtual. O DNS do Azure resolve o plano de controlo do Azure Databricks, o armazenamento, o metastore e outros nomes de serviço do Azure para si, e continua a funcionar à medida que esses endereços mudam.

Importante

Não substitua totalmente o DNS fornecido pelo Azure sem encaminhamento condicional. Se os seus servidores DNS personalizados se tornarem autoritativos para domínios Azure ou Azure Databricks e não encaminharem as consultas que não conseguem responder, a resolução dos endpoints necessários falha e os clusters não conseguem iniciar.

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 os seus workloads utilizem:

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

Se a sua área de trabalho utilizar Azure Private Link para a ligação clássica do plano de computação, a resolução de nomes tem de devolver os endereços IP privados dos pontos finais em vez de endereços públicos. O Azure cria a zona DNS privada privatelink.azuredatabricks.net e adiciona registos de endereços para os pontos finais do seu espaço de trabalho, incluindo o ponto final databricks_ui_api e o ponto final browser_authentication utilizado para início de sessão único. O registo de autenticação do navegador utiliza o formato pl-auth.<region>.

Quando um espaço de trabalho usa DNS personalizado, os seus nós de computação clássicos enviam consultas DNS para os seus servidores DNS personalizados em vez de para o DNS do Azure. Uma zona DNS privada associada a uma VNet é consultada apenas através do resolvedor disponibilizado pelo Azure em 168.63.129.16, pelo que associar apenas a zona não devolve os endereços do ponto final privado a recursos de computação que consultam um resolvedor personalizado. Ambos os seguintes requisitos são obrigatórios:

  • Liga a privatelink.azuredatabricks.net zona DNS privada ao VNet onde o DNS do Azure resolve a consulta: o VNet do teu workspace, ou o VNet hub que aloja o teu resolver numa topologia hub-and-spoke. Isto dá ao DNS do Azure os registos privados de endereços finais para devolver.
  • Configure os seus servidores DNS personalizados para encaminharem de forma condicional *.privatelink.azuredatabricks.net e *.azuredatabricks.net para o DNS do Azure em 168.63.129.16. O encaminhamento é responsável por enviar a consulta para a zona DNS privada associada. Numa topologia hub-and-spoke, encaminhe para o resolvedor central que acede ao DNS do Azure.

Se a zona DNS privada não estiver ligada, ou estiver ligada mas não tiver o registo de endereço de um endpoint, o DNS do Azure recorre à recursão pública e devolve 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 ligada contém os registos de endereços esperados para cada endpoint privado que o workspace utiliza.

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

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

Configurações incorretas comuns de DNS personalizado

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

  • Sem encaminhamento para DNS do Azure. Servidores DNS personalizados não conseguem resolver nomes do plano de controlo, armazenamento ou metastore do Azure Databricks e não encaminham as consultas para 168.63.129.16. Os clusters não começam, ou não chegam ao armazenamento e à metastore após o arranque.
  • Faltam ligação à zona de DNS privado, reencaminhamento ou registos. O espaço de trabalho utiliza o Private Link, mas a VNet não está associada à zona privatelink.azuredatabricks.net, não reencaminha para o DNS do Azure ou a zona associada não contém o registo de endereço IP correto para um ponto final. Os nomes resolvem para endereços IP públicos, o endereço errado ou nada, pelo que 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 aloja os seus servidores DNS personalizados. Toda a resolução de nomes falha.
  • Resolvedor local sem reencaminhamento para o Azure. As consultas DNS encaminham para um resolvedor local que resolve nomes internos mas não consegue resolver ou encaminhar nomes Azure. Adicione o reencaminhamento 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, pelo que as instalações de bibliotecas do PyPI, Maven ou CRAN falham.

Resolver problemas de DNS personalizado

Se os clusters não iniciarem ou perderem a conectividade, verifique a resolução de DNS a partir de um cluster.

  1. Cria um cluster no espaço de trabalho. Se o cluster não iniciar e o registo de eventos mostrar um erro como Cluster terminated. Reason: Control Plane Request Failure, o cluster não consegue aceder ao plano de controlo, o que é frequentemente um problema de resolução de nomes.

  2. A partir de um notebook num cluster em execução, resolva um endpoint necessário para confirmar que o seu DNS personalizado devolve o endereço esperado. Para um espaço de trabalho Private Link, verifique se a URL do espaço de trabalho 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 os clusters não conseguirem iniciar de todo, por exemplo devido a um problema de Private Link no back-end, execute estas verificações a partir de uma VM do Azure na sub-rede pública da VNet da área de trabalho, em vez de num notebook.

  3. Se a resolução falhar ou devolver o endereço errado, verifique o seguinte. Quando um cluster falha em arrancar devido ao DNS, o registo 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 subredes de computação podem aceder a esses servidores (X_NHC_DNS_SERVER_UNREACHABLE).
    • Os seus servidores DNS personalizados reencaminham condicionalmente os domínios do Azure e do Azure Databricks para o DNS do Azure em 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, quando os nomes do plano de controlo ou do armazenamento de artefactos não forem resolvidos).
    • Para o Private Link, a privatelink.azuredatabricks.net zona está ligada ao VNet onde o DNS do Azure resolve, os seus servidores DNS personalizados encaminham os domínios Azure Databricks para o DNS do Azure, e os registos de endereço esperados existem (X_NHC_CONTROL_PLANE_HTTP_ERROR, quando o endpoint privado do plano de controlo não se resolve).

  4. Se os clusters iniciarem mas não conseguirem aceder a recursos on-premises ou a outras plataformas Azure como serviço (PaaS), confirme que existem rotas definidas pelo utilizador para esses destinos, porque o encaminhamento e o DNS estão configurados separadamente.

Se ainda não conseguires resolver o problema, contacta as equipas de contas da tua Microsoft e Azure Databricks.

Recursos adicionais

  • Última atualização a