Como utilizar a área de trabalho com um servidor DNS personalizado
Ao usar um espaço de trabalho do Azure Machine Learning (incluindo hubs de IA do Azure) com um ponto de extremidade privado, há várias maneiras de lidar com a resolução de nomes DNS. Por padrão, o Azure lida automaticamente com a resolução de nomes para seu espaço de trabalho e ponto de extremidade privado. Se, em vez disso , você usar seu próprio servidor DNS personalizado, deverá criar manualmente entradas DNS ou usar encaminhadores condicionais para o espaço de trabalho.
Importante
Este artigo aborda como encontrar os nomes de domínio totalmente qualificados (FQDN) e endereços IP para essas entradas se você quiser registrar manualmente os registros DNS em sua solução DNS. Além disso, este artigo fornece recomendações de arquitetura sobre como configurar sua solução DNS personalizada para resolver automaticamente FQDNs para os endereços IP corretos. Este artigo NÃO fornece informações sobre como configurar os registros DNS para esses itens. Consulte a documentação do seu software DNS para obter informações sobre como adicionar registos.
Pré-requisitos
- Uma Rede Virtual do Azure que usa seu próprio servidor DNS.
Um espaço de trabalho do Azure Machine Learning com um ponto de extremidade privado, incluindo espaços de trabalho de hub, como os usados pelo Azure AI Studio. Para obter mais informações, consulte Criar um espaço de trabalho do Azure Machine Learning.
Se os recursos de dependência do espaço de trabalho estiverem protegidos com uma rede Virtual do Azure, familiaridade com o artigo Isolamento de rede durante o treinamento & inferência .
- Um espaço de trabalho do Azure Machine Learning com um ponto de extremidade privado. Para obter mais informações, consulte Criar um espaço de trabalho do Azure Machine Learning.
- Familiaridade com o uso do isolamento de rede durante o treinamento e inferência.
Familiaridade com a configuração da zona DNS do Ponto de Extremidade Privado do Azure
Familiaridade com o DNS Privado do Azure
Opcionalmente, CLI do Azure ou Azure PowerShell.
Integração automatizada de servidores DNS
Introdução
Há duas arquiteturas comuns para usar a integração automatizada do servidor DNS com o Azure Machine Learning:
- Um servidor DNS personalizado hospedado em uma Rede Virtual do Azure.
- Um servidor DNS personalizado hospedado localmente, conectado ao Azure Machine Learning por meio da Rota Expressa.
Embora sua arquitetura possa diferir desses exemplos, você pode usá-los como um ponto de referência. Ambas as arquiteturas de exemplo fornecem etapas de solução de problemas que podem ajudá-lo a identificar componentes que podem estar configurados incorretamente.
Outra opção é modificar o hosts
arquivo no cliente que está se conectando à Rede Virtual do Azure (VNet) que contém seu espaço de trabalho. Para obter mais informações, consulte a seção Arquivo host .
Caminho de resolução DNS do espaço de trabalho
O acesso a um determinado espaço de trabalho do Azure Machine Learning por meio do Private Link é feito comunicando-se com os seguintes Domínios Totalmente Qualificados (chamados FQDNs do espaço de trabalho) listados abaixo:
Importante
Se você estiver usando um espaço de trabalho de hub (incluindo o hub do Azure AI Studio), terá entradas adicionais para cada espaço de trabalho de projeto criado a partir do hub.
Regiões públicas do Azure:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.azureml.ms
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.cert.api.azureml.ms
<compute instance name>.<region the workspace was created in>.instances.azureml.ms
<compute instance name>-22.<region the workspace was created in>.instances.azureml.ms
- Usado peloaz ml compute connect-ssh
comando para se conectar a cálculos em uma rede virtual gerenciada.ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
<managed online endpoint name>.<region>.inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Gorjeta
Se você estiver usando um espaço de trabalho de hub, também haverá os seguintes FQDNs para cada espaço de trabalho de projeto criado a partir do espaço de trabalho de hub:
<project workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.azureml.ms
<project workspace globally-unique identifier>.workspace.<region the workspace was created in>.cert.api.azureml.ms
ml-<project workspacename, truncated>-<region>-<project workspace globally-unique identifier>.<region>.notebooks.azure.net
Microsoft Azure operado por 21Vianet regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.cn
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.cert.api.ml.azure.cn
<compute instance name>.<region the workspace was created in>.instances.azureml.cn
<compute instance name>-22.<region the workspace was created in>.instances.azureml.cn
- Usado peloaz ml compute connect-ssh
comando para se conectar a cálculos em uma rede virtual gerenciada.ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
<managed online endpoint name>.<region>.inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Gorjeta
Se você estiver usando um espaço de trabalho de hub, também haverá os seguintes FQDNs para cada espaço de trabalho de projeto criado a partir do espaço de trabalho de hub:
<project workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.cn
<project workspace globally-unique identifier>.workspace.<region the workspace was created in>.cert.api.ml.azure.cn
ml-<project workspace name, truncated>-<region>-<project workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
Azure US Government regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.us
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.cert.api.ml.azure.us
<compute instance name>.<region the workspace was created in>.instances.azureml.us
<compute instance name>-22.<region the workspace was created in>.instances.azureml.us
- Usado peloaz ml compute connect-ssh
comando para se conectar a cálculos em uma rede virtual gerenciada.ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
<managed online endpoint name>.<region>.inference.ml.azure.us
- Usado por endpoints on-line gerenciados
Gorjeta
Se você estiver usando um espaço de trabalho de hub, também haverá os seguintes FQDNs para cada espaço de trabalho de projeto criado a partir do espaço de trabalho de hub:
<project workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.us
<project workspace globally-unique identifier>.workspace.<region the workspace was created in>.cert.api.ml.azure.us
ml-<project workspace name, truncated>-<region>-<project workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
Os Domínios Totalmente Qualificados resolvem para os seguintes Nomes Canônicos (CNAMEs) chamados FQDNs de Link Privado do espaço de trabalho:
Regiões públicas do Azure:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.privatelink.api.azureml.ms
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.privatelink.notebooks.azure.net
<managed online endpoint name>.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms
- Usado por endpoints on-line gerenciados
Azure operado por 21Vianet regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.privatelink.api.ml.azure.cn
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.privatelink.notebooks.chinacloudapi.cn
<managed online endpoint name>.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.ml.azure.cn
- Usado por endpoints on-line gerenciados
Azure US Government regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.privatelink.api.ml.azure.us
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.privatelink.notebooks.usgovcloudapi.net
<managed online endpoint name>.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.ml.azure.us
- Usado por endpoints on-line gerenciados
Os FQDNs são resolvidos para os endereços IP do espaço de trabalho do Azure Machine Learning nessa região. No entanto, a resolução dos FQDNs de Link Privado do espaço de trabalho pode ser substituída usando um servidor DNS personalizado hospedado na rede virtual. Para obter um exemplo dessa arquitetura, consulte o servidor DNS personalizado hospedado em um exemplo de vnet . Para espaços de trabalho de hub e de projeto, os FQDNs de todos os espaços de trabalho de projeto são resolvidos para o endereço IP do espaço de trabalho de hub.
Nota
Os pontos de extremidade online gerenciados compartilham o ponto de extremidade privado do espaço de trabalho. Se você estiver adicionando manualmente registros DNS à zona privatelink.api.azureml.ms
DNS privada, um registro A com curinga *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms
deverá ser adicionado para rotear todos os pontos de extremidade sob o espaço de trabalho para o ponto de extremidade privado.
Integração manual do servidor DNS
Esta seção discute para quais domínios totalmente qualificados criar registros A em um servidor DNS e para qual endereço IP definir o valor do registro A.
Recuperar FQDNs de ponto de extremidade privado
Região Pública do Azure
A lista a seguir contém os FQDNs (nomes de domínio totalmente qualificados) usados pelo seu espaço de trabalho se ele estiver na Nuvem Pública do Azure:
<workspace-GUID>.workspace.<region>.cert.api.azureml.ms
<workspace-GUID>.workspace.<region>.api.azureml.ms
ml-<workspace-name, truncated>-<region>-<workspace-guid>.<region>.notebooks.azure.net
Nota
O nome do espaço de trabalho para este FQDN pode ser truncado. O truncamento é feito para manter
ml-<workspace-name, truncated>-<region>-<workspace-guid>
em 63 caracteres ou menos.<instance-name>.<region>.instances.azureml.ms
Nota
- As instâncias de computação podem ser acessadas somente de dentro da rede virtual.
- O endereço IP deste FQDN não é o IP da instância de computação. Em vez disso, use o endereço IP privado do ponto de extremidade privado do espaço de trabalho (o IP das
*.api.azureml.ms
entradas.)
<instance-name>-22.<region>.instances.azureml.ms
- Usado apenas peloaz ml compute connect-ssh
comando para se conectar a cálculos em uma rede virtual gerenciada. Não é necessário se você não estiver usando uma rede gerenciada ou conexões SSH.<managed online endpoint name>.<region>.inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Gorjeta
Se você estiver usando espaços de trabalho de hub e de projeto, cada espaço de trabalho de projeto terá seu próprio conjunto de FQDNs adicionais. Para obter mais informações, consulte a seção Resolução de DNS do espaço de trabalho.
Microsoft Azure operado pela região 21Vianet
Os seguintes FQDNs são para o Microsoft Azure operado por regiões 21Vianet:
<workspace-GUID>.workspace.<region>.cert.api.ml.azure.cn
<workspace-GUID>.workspace.<region>.api.ml.azure.cn
ml-<workspace-name, truncated>-<region>-<workspace-guid>.<region>.notebooks.chinacloudapi.cn
Nota
O nome do espaço de trabalho para este FQDN pode ser truncado. O truncamento é feito para manter
ml-<workspace-name, truncated>-<region>-<workspace-guid>
em 63 caracteres ou menos.<instance-name>.<region>.instances.azureml.cn
- O endereço IP deste FQDN não é o IP da instância de computação. Em vez disso, use o endereço IP privado do ponto de extremidade privado do espaço de trabalho (o IP das
*.api.azureml.ms
entradas.)
- O endereço IP deste FQDN não é o IP da instância de computação. Em vez disso, use o endereço IP privado do ponto de extremidade privado do espaço de trabalho (o IP das
<instance-name>-22.<region>.instances.azureml.cn
- Usado apenas peloaz ml compute connect-ssh
comando para se conectar a cálculos em uma rede virtual gerenciada. Não é necessário se você não estiver usando uma rede gerenciada ou conexões SSH.<managed online endpoint name>.<region>.inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Gorjeta
Se você estiver usando espaços de trabalho de hub e de projeto, cada espaço de trabalho de projeto terá seu próprio conjunto de FQDNs adicionais. Para obter mais informações, consulte a seção Resolução de DNS do espaço de trabalho.
Azure US Government
Os seguintes FQDNs são para regiões do Azure US Government:
<workspace-GUID>.workspace.<region>.cert.api.ml.azure.us
<workspace-GUID>.workspace.<region>.api.ml.azure.us
ml-<workspace-name, truncated>-<region>-<workspace-guid>.<region>.notebooks.usgovcloudapi.net
Nota
O nome do espaço de trabalho para este FQDN pode ser truncado. O truncamento é feito para manter
ml-<workspace-name, truncated>-<region>-<workspace-guid>
em 63 caracteres ou menos.<instance-name>.<region>.instances.azureml.us
- O endereço IP deste FQDN não é o IP da instância de computação. Em vez disso, use o endereço IP privado do ponto de extremidade privado do espaço de trabalho (o IP das
*.api.azureml.ms
entradas.)
- O endereço IP deste FQDN não é o IP da instância de computação. Em vez disso, use o endereço IP privado do ponto de extremidade privado do espaço de trabalho (o IP das
<instance-name>-22.<region>.instances.azureml.us
- Usado apenas peloaz ml compute connect-ssh
comando para se conectar a cálculos em uma rede virtual gerenciada. Não é necessário se você não estiver usando uma rede gerenciada ou conexões SSH.<managed online endpoint name>.<region>.inference.ml.azure.us
- Usado por endpoints on-line gerenciados
Gorjeta
Se você estiver usando espaços de trabalho de hub e de projeto, cada espaço de trabalho de projeto terá seu próprio conjunto de FQDNs adicionais. Para obter mais informações, consulte a seção Resolução de DNS do espaço de trabalho.
Encontre os endereços IP
Para localizar os endereços IP internos para os FQDNs na rede virtual, use um dos seguintes métodos:
Nota
Os nomes de domínio e endereços IP totalmente qualificados serão diferentes com base na sua configuração. Por exemplo, o valor GUID no nome de domínio será específico para seu espaço de trabalho.
Para obter a ID da interface de rede de ponto de extremidade privado, use o seguinte comando:
az network private-endpoint show --name <endpoint> --resource-group <resource-group> --query 'networkInterfaces[*].id' --output table
Para obter o endereço IP e as informações de FQDN para o espaço de trabalho ou espaço de trabalho de hub, use o seguinte comando. Substitua
<resource-id>
pelo ID da etapa anterior:az network nic show --ids <resource-id> --query 'ipConfigurations[*].{IPAddress: privateIPAddress, FQDNs: privateLinkConnectionProperties.fqdns}'
O resultado será semelhante ao texto seguinte:
[ { "FQDNs": [ "fb7e20a0-8891-458b-b969-55ddb3382f51.workspace.eastus.api.azureml.ms", "fb7e20a0-8891-458b-b969-55ddb3382f51.workspace.eastus.cert.api.azureml.ms" ], "IPAddress": "10.1.0.5" }, { "FQDNs": [ "ml-myworkspace-eastus-fb7e20a0-8891-458b-b969-55ddb3382f51.eastus.notebooks.azure.net" ], "IPAddress": "10.1.0.6" }, { "FQDNs": [ "*.eastus.inference.ml.azure.com" ], "IPAddress": "10.1.0.7" } ]
Se você estiver usando um espaço de trabalho de hub, use as seguintes etapas para cada espaço de trabalho de projeto que foi criado a partir do hub:
Para obter a ID do espaço de trabalho do projeto, use o seguinte comando:
az ml workspace show --name <project-workspace-name> --resource-group <resource-group> --query 'discovery_url'
O valor devolvido seguirá o formato
https://<project-workspace-id>.workspace.<region>.api.azureml.ms/mlflow/<version>/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.MachineLearningServices/workspaces/<project-workspace-name>
.Pegue os FQDNs retornados do espaço de trabalho do hub que terminam em
workspace.<region>.api.azureml.ms
eworkspace.<region>.cert.api.azureml.ms
. Substitua o valor GUID no início desses FQDNs pelo ID do espaço de trabalho do projeto. Esses FQDNs são adicionais aos FQDNs do espaço de trabalho do hub.Pegue o FQDN retornado do espaço de trabalho do hub que segue o formato em
<workspace-name>-<region>-<GUID>.<region>.notebooks.azure.net
. Substitua o valor GUID pelo ID do espaço de trabalho do projeto. Substitua o nome do espaço de trabalho do hub pelo nome do espaço de trabalho do projeto. Talvez seja necessário truncar o nome do espaço de trabalho para manter essa entrada em 63 caracteres ou menos. Este FQDN é adicional ao FQDN do espaço de trabalho do hub.
As informações retornadas de todos os métodos são as mesmas; uma lista do FQDN e do endereço IP privado para os recursos. O exemplo a seguir é da Nuvem Pública do Azure:
FQDN | Endereço IP |
---|---|
fb7e20a0-8891-458b-b969-55ddb3382f51.workspace.eastus.api.azureml.ms |
10.1.0.5 |
fb7e20a0-8891-458b-b969-55ddb3382f51.workspace.eastus.cert.api.azureml.ms |
10.1.0.5 |
ml-myworkspace-eastus-fb7e20a0-8891-458b-b969-55ddb3382f51.eastus.notebooks.azure.net |
10.1.0.6 |
*.eastus.inference.ml.azure.com |
10.1.0.7 |
A tabela a seguir mostra exemplos de IPs do Microsoft Azure operados por regiões 21Vianet:
FQDN | Endereço IP |
---|---|
52882c08-ead2-44aa-af65-08a75cf094bd.workspace.chinaeast2.api.ml.azure.cn |
10.1.0.5 |
52882c08-ead2-44aa-af65-08a75cf094bd.workspace.chinaeast2.cert.api.ml.azure.cn |
10.1.0.5 |
ml-mype-pltest-chinaeast2-52882c08-ead2-44aa-af65-08a75cf094bd.chinaeast2.notebooks.chinacloudapi.cn |
10.1.0.6 |
*.chinaeast2.inference.ml.azure.cn |
10.1.0.7 |
A tabela a seguir mostra exemplos de IPs de regiões do Azure US Government:
FQDN | Endereço IP |
---|---|
52882c08-ead2-44aa-af65-08a75cf094bd.workspace.chinaeast2.api.ml.azure.us |
10.1.0.5 |
52882c08-ead2-44aa-af65-08a75cf094bd.workspace.chinaeast2.cert.api.ml.azure.us |
10.1.0.5 |
ml-mype-plt-usgovvirginia-52882c08-ead2-44aa-af65-08a75cf094bd.usgovvirginia.notebooks.usgovcloudapi.net |
10.1.0.6 |
*.usgovvirginia.inference.ml.azure.us |
10.1.0.7 |
Nota
Os pontos de extremidade online gerenciados compartilham o ponto de extremidade privado do espaço de trabalho. Se você estiver adicionando manualmente registros DNS à zona privatelink.api.azureml.ms
DNS privada, um registro A com curinga *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms
deverá ser adicionado para rotear todos os pontos de extremidade sob o espaço de trabalho para o ponto de extremidade privado.
Criar registos A no servidor DNS personalizado
Depois que a lista de FQDNs e endereços IP correspondentes forem coletados, prossiga para criar registros A no servidor DNS configurado. Consulte a documentação do servidor DNS para determinar como criar registos A. Observe que é recomendável criar uma zona exclusiva para todo o FQDN e criar o registro A na raiz da zona.
Exemplo: Servidor DNS personalizado hospedado em VNet
Essa arquitetura usa a topologia de rede virtual comum Hub e Spoke. Uma rede virtual contém o servidor DNS e outra contém o ponto de extremidade privado para o espaço de trabalho do Azure Machine Learning e recursos associados. Deve haver uma rota válida entre ambas as redes virtuais. Por exemplo, através de uma série de redes virtuais emparelhadas.
As etapas a seguir descrevem como essa topologia funciona:
Crie uma Zona DNS Privada e estabeleça um link para a Rede Virtual do Servidor DNS:
A primeira etapa para garantir que uma solução de DNS personalizada funcione com seu espaço de trabalho do Azure Machine Learning é criar duas zonas DNS privadas enraizadas nos seguintes domínios:
Regiões públicas do Azure:
privatelink.api.azureml.ms
privatelink.notebooks.azure.net
Microsoft Azure operado por 21Vianet regiões:
privatelink.api.ml.azure.cn
privatelink.notebooks.chinacloudapi.cn
Azure US Government regiões:
privatelink.api.ml.azure.us
privatelink.notebooks.usgovcloudapi.net
Nota
Os pontos de extremidade online gerenciados compartilham o ponto de extremidade privado do espaço de trabalho. Se você estiver adicionando manualmente registros DNS à zona
privatelink.api.azureml.ms
DNS privada, um registro A com curinga*.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms
deverá ser adicionado para rotear todos os pontos de extremidade sob o espaço de trabalho para o ponto de extremidade privado.Após a criação da Zona DNS Privada, ela precisa ser vinculada à Rede Virtual do Servidor DNS. A Rede Virtual que contém o Servidor DNS.
Uma Zona DNS Privada substitui a resolução de nomes para todos os nomes dentro do escopo da raiz da zona. Esta substituição aplica-se a todas as Redes Virtuais às quais a Zona DNS Privada está ligada. Por exemplo, se uma Zona DNS Privada enraizada em
privatelink.api.azureml.ms
estiver vinculada ao foo da Rede Virtual, todos os recursos no foo da Rede Virtual que tentarem resolverbar.workspace.westus2.privatelink.api.azureml.ms
receberão qualquer registro listadoprivatelink.api.azureml.ms
na zona.No entanto, os registros listados em Zonas DNS Privadas só são retornados para dispositivos que resolvem domínios usando o endereço IP padrão do Servidor Virtual DNS do Azure. Assim, o Servidor DNS personalizado resolverá domínios para dispositivos espalhados por toda a topologia de rede. Mas o Servidor DNS personalizado precisará resolver domínios relacionados ao Azure Machine Learning em relação ao endereço IP do Servidor Virtual DNS do Azure.
Crie um ponto de extremidade privado com integração DNS privada direcionada à Zona DNS Privada vinculada à Rede Virtual do Servidor DNS:
A próxima etapa é criar um Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning. O ponto de extremidade privado tem como alvo ambas as Zonas DNS Privadas criadas na etapa 1. Isso garante que toda a comunicação com o espaço de trabalho seja feita por meio do Ponto de Extremidade Privado na Rede Virtual do Azure Machine Learning.
Importante
O ponto de extremidade privado deve ter a integração de DNS privado habilitada para que este exemplo funcione corretamente.
Crie um encaminhador condicional no Servidor DNS para encaminhar para o DNS do Azure:
Em seguida, crie um encaminhador condicional para o Servidor Virtual DNS do Azure. O encaminhador condicional garante que o servidor DNS sempre consulte o endereço IP do Servidor Virtual DNS do Azure para FQDNs relacionados ao seu espaço de trabalho. Isso significa que o Servidor DNS retornará o registro correspondente da Zona DNS Privada.
As zonas a serem encaminhadas condicionalmente estão listadas abaixo. O endereço IP do Servidor Virtual DNS do Azure é 168.63.129.16:
Regiões públicas do Azure:
api.azureml.ms
notebooks.azure.net
instances.azureml.ms
aznbcontent.net
inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Microsoft Azure operado por 21Vianet regiões:
api.ml.azure.cn
notebooks.chinacloudapi.cn
instances.azureml.cn
aznbcontent.net
inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Azure US Government regiões:
api.ml.azure.us
notebooks.usgovcloudapi.net
instances.azureml.us
aznbcontent.net
inference.ml.azure.us
- Usado por endpoints on-line gerenciados
Importante
As etapas de configuração para o Servidor DNS não estão incluídas aqui, pois há muitas soluções DNS disponíveis que podem ser usadas como um Servidor DNS personalizado. Consulte a documentação da sua solução DNS para saber como configurar adequadamente o encaminhamento condicional.
Resolver domínio do espaço de trabalho:
Neste ponto, toda a configuração está feita. Agora, qualquer cliente que use o Servidor DNS para resolução de nomes e tenha uma rota para o Ponto de Extremidade Privado do Azure Machine Learning pode continuar para acessar o espaço de trabalho. O cliente começará consultando o servidor DNS para obter o endereço dos seguintes FQDNs:
Regiões públicas do Azure:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.azureml.ms
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
<managed online endpoint name>.<region>.inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Microsoft Azure operado por 21Vianet regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.cn
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
<managed online endpoint name>.<region>.inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Azure US Government regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.us
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
<managed online endpoint name>.<region>.inference.ml.azure.us
- Usado por endpoints on-line gerenciados
O DNS do Azure resolve recursivamente o domínio do espaço de trabalho para CNAME:
O Servidor DNS resolverá os FQDNs da etapa 4 do DNS do Azure. O DNS do Azure responderá com um dos domínios listados na etapa 1.
O Servidor DNS resolve recursivamente o registro CNAME do domínio do espaço de trabalho do DNS do Azure:
O Servidor DNS continuará a resolver recursivamente o CNAME recebido na etapa 5. Como houve uma configuração de encaminhador condicional na etapa 3, o Servidor DNS enviará a solicitação para o endereço IP do Servidor Virtual DNS do Azure para resolução.
O DNS do Azure retorna registros da zona DNS Privada:
Os registos correspondentes armazenados nas Zonas DNS Privadas serão devolvidos ao Servidor DNS, o que significa que o Servidor Virtual DNS do Azure devolve os endereços IP do Ponto de Extremidade Privado.
O Servidor DNS Personalizado resolve o nome de domínio do espaço de trabalho para o endereço de ponto final privado:
Em última análise, o servidor DNS personalizado agora retorna os endereços IP do ponto de extremidade privado para o cliente a partir da etapa 4. Isso garante que todo o tráfego para o espaço de trabalho do Azure Machine Learning seja feito por meio do Ponto de Extremidade Privado.
Resolução de Problemas
Se não for possível acessar o espaço de trabalho a partir de uma máquina virtual ou se os trabalhos falharem nos recursos de computação na rede virtual, use as seguintes etapas para identificar a causa:
Localize os FQDNs do espaço de trabalho no ponto de extremidade privado:
Navegue até o portal do Azure usando um dos seguintes links:
- Regiões públicas do Azure
- Microsoft Azure operado por 21Vianet regiões
- Azure Regiões do Governo dos EUA
Navegue até o Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning. Os FQDNs do espaço de trabalho serão listados na guia "Visão geral".
Acesse o recurso de computação na topologia da Rede Virtual:
Prossiga para acessar um recurso de computação na topologia da Rede Virtual do Azure. Isso provavelmente exigirá o acesso a uma Máquina Virtual em uma Rede Virtual emparelhada com a Rede Virtual do Hub.
Resolver FQDNs do espaço de trabalho:
Abra um prompt de comando, shell ou PowerShell. Em seguida, para cada um dos FQDN da área de trabalho, execute o seguinte comando:
nslookup <workspace FQDN>
O resultado de cada nslookup deve retornar um dos dois endereços IP privados no Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning. Se tal não acontecer, significa que existe uma configuração incorreta na solução DNS personalizada.
Causas possíveis:
- O recurso de computação em execução nos comandos de resolução de problemas não está a utilizar o Servidor DNS para a resolução DNS
- As Zonas DNS Privado selecionadas ao criar o Ponto Final Privado não estão associadas à VNet do Servidor DNS
- Encaminhadores condicionais para o IP do Servidor Virtual DNS do Azure não foram configurados corretamente
Exemplo: Servidor DNS personalizado hospedado no local
Essa arquitetura usa a topologia de rede virtual comum Hub e Spoke. A Rota Expressa é usada para se conectar da sua rede local à rede virtual do Hub. O servidor DNS personalizado está hospedado localmente. Uma rede virtual separada contém o ponto de extremidade privado para o espaço de trabalho do Azure Machine Learning e recursos associados. Com essa topologia, precisa haver outra rede virtual hospedando um servidor DNS que possa enviar solicitações para o endereço IP do Servidor Virtual DNS do Azure.
As etapas a seguir descrevem como essa topologia funciona:
Crie uma Zona DNS Privada e estabeleça um link para a Rede Virtual do Servidor DNS:
A primeira etapa para garantir que uma solução de DNS personalizada funcione com seu espaço de trabalho do Azure Machine Learning é criar duas zonas DNS privadas enraizadas nos seguintes domínios:
Regiões públicas do Azure:
privatelink.api.azureml.ms
privatelink.notebooks.azure.net
Microsoft Azure operado por 21Vianet regiões:
privatelink.api.ml.azure.cn
privatelink.notebooks.chinacloudapi.cn
Azure US Government regiões:
privatelink.api.ml.azure.us
privatelink.notebooks.usgovcloudapi.net
Nota
Os pontos de extremidade online gerenciados compartilham o ponto de extremidade privado do espaço de trabalho. Se você estiver adicionando manualmente registros DNS à zona
privatelink.api.azureml.ms
DNS privada, um registro A com curinga*.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms
deverá ser adicionado para rotear todos os pontos de extremidade sob o espaço de trabalho para o ponto de extremidade privado.Após a criação da Zona DNS Privada, ela precisa ser vinculada à VNet do Servidor DNS – a Rede Virtual que contém o Servidor DNS.
Nota
O servidor DNS na rede virtual é separado do servidor DNS local.
Uma Zona DNS Privada substitui a resolução de nomes para todos os nomes dentro do escopo da raiz da zona. Esta substituição aplica-se a todas as Redes Virtuais às quais a Zona DNS Privada está ligada. Por exemplo, se uma Zona DNS Privada enraizada em
privatelink.api.azureml.ms
estiver vinculada ao foo da Rede Virtual, todos os recursos no foo da Rede Virtual que tentarem resolverbar.workspace.westus2.privatelink.api.azureml.ms
receberão qualquer registro listado na zona privatelink.api.azureml.ms.No entanto, os registros listados em Zonas DNS Privadas só são retornados para dispositivos que resolvem domínios usando o endereço IP padrão do Servidor Virtual DNS do Azure. O endereço IP do Servidor Virtual DNS do Azure só é válido no contexto de uma Rede Virtual. Ao usar um servidor DNS local, ele não é capaz de consultar o endereço IP do Servidor Virtual DNS do Azure para recuperar registros.
Para contornar esse comportamento, crie um servidor DNS intermediário em uma rede virtual. Este servidor DNS pode consultar o endereço IP do Servidor Virtual DNS do Azure para recuperar registos de qualquer Zona DNS Privada ligada à rede virtual.
Embora o Servidor DNS local resolva domínios para dispositivos espalhados pela topologia de rede, ele resolverá domínios relacionados ao Aprendizado de Máquina do Azure em relação ao Servidor DNS. O Servidor DNS resolverá esses domínios a partir do endereço IP do Servidor Virtual DNS do Azure.
Crie um ponto de extremidade privado com integração DNS privada direcionada à Zona DNS Privada vinculada à Rede Virtual do Servidor DNS:
A próxima etapa é criar um Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning. O ponto de extremidade privado tem como alvo ambas as Zonas DNS Privadas criadas na etapa 1. Isso garante que toda a comunicação com o espaço de trabalho seja feita por meio do Ponto de Extremidade Privado na Rede Virtual do Azure Machine Learning.
Importante
O ponto de extremidade privado deve ter a integração de DNS privado habilitada para que este exemplo funcione corretamente.
Crie um encaminhador condicional no Servidor DNS para encaminhar para o DNS do Azure:
Em seguida, crie um encaminhador condicional para o Servidor Virtual DNS do Azure. O encaminhador condicional garante que o servidor DNS sempre consulte o endereço IP do Servidor Virtual DNS do Azure para FQDNs relacionados ao seu espaço de trabalho. Isso significa que o Servidor DNS retornará o registro correspondente da Zona DNS Privada.
As zonas a serem encaminhadas condicionalmente estão listadas abaixo. O endereço IP do Servidor Virtual DNS do Azure é 168.63.129.16.
Regiões públicas do Azure:
api.azureml.ms
notebooks.azure.net
instances.azureml.ms
aznbcontent.net
inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Microsoft Azure operado por 21Vianet regiões:
api.ml.azure.cn
notebooks.chinacloudapi.cn
instances.azureml.cn
aznbcontent.net
inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Azure US Government regiões:
api.ml.azure.us
notebooks.usgovcloudapi.net
instances.azureml.us
aznbcontent.net
inference.ml.azure.us
- Usado por endpoints on-line gerenciados
Importante
As etapas de configuração para o Servidor DNS não estão incluídas aqui, pois há muitas soluções DNS disponíveis que podem ser usadas como um Servidor DNS personalizado. Consulte a documentação da sua solução DNS para saber como configurar adequadamente o encaminhamento condicional.
Crie um encaminhador condicional no Servidor DNS local para encaminhar para o Servidor DNS:
Em seguida, crie um encaminhador condicional para o servidor DNS na rede virtual do servidor DNS. Este encaminhador é para as zonas listadas na etapa 1. Isso é semelhante à etapa 3, mas, em vez de encaminhar para o endereço IP do Servidor Virtual DNS do Azure, o Servidor DNS local terá como alvo o endereço IP do Servidor DNS. Como o Servidor DNS Local não está no Azure, ele não pode resolver diretamente registros em Zonas DNS Privadas. Nesse caso, o Servidor DNS faz proxies de solicitações do Servidor DNS local para o IP do Servidor Virtual DNS do Azure. Isso permite que o Servidor DNS Local recupere registros nas Zonas DNS Privadas vinculadas à Rede Virtual do Servidor DNS.
As zonas a serem encaminhadas condicionalmente estão listadas abaixo. Os endereços IP para os quais encaminhar são os endereços IP dos seus Servidores DNS:
Regiões públicas do Azure:
api.azureml.ms
notebooks.azure.net
instances.azureml.ms
inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Microsoft Azure operado por 21Vianet regiões:
api.ml.azure.cn
notebooks.chinacloudapi.cn
instances.azureml.cn
inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Azure US Government regiões:
api.ml.azure.us
notebooks.usgovcloudapi.net
instances.azureml.us
inference.ml.azure.us
- Usado por endpoints on-line gerenciados
Importante
As etapas de configuração para o Servidor DNS não estão incluídas aqui, pois há muitas soluções DNS disponíveis que podem ser usadas como um Servidor DNS personalizado. Consulte a documentação da sua solução DNS para saber como configurar adequadamente o encaminhamento condicional.
Resolver domínio do espaço de trabalho:
Neste ponto, toda a configuração está feita. Qualquer cliente que use o Servidor DNS local para resolução de nomes e tenha uma rota para o Ponto de Extremidade Privado do Azure Machine Learning pode continuar a acessar o espaço de trabalho.
O cliente começará consultando o Servidor DNS local para obter o endereço dos seguintes FQDNs:
Regiões públicas do Azure:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.azureml.ms
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
<managed online endpoint name>.<region>.inference.ml.azure.com
- Usado por endpoints on-line gerenciados
Microsoft Azure operado por 21Vianet regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.cn
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
<managed online endpoint name>.<region>.inference.ml.azure.cn
- Usado por endpoints on-line gerenciados
Azure US Government regiões:
<per-workspace globally-unique identifier>.workspace.<region the workspace was created in>.api.ml.azure.us
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
<managed online endpoint name>.<region>.inference.ml.azure.us
- Usado por endpoints on-line gerenciados
O servidor DNS local resolve recursivamente o domínio do espaço de trabalho:
O servidor DNS local resolverá os FQDNs da etapa 5 do servidor DNS. Como há um encaminhador condicional (etapa 4), o servidor DNS local enviará a solicitação ao servidor DNS para resolução.
O Servidor DNS resolve o domínio do espaço de trabalho para CNAME a partir do DNS do Azure:
O servidor DNS resolverá os FQDNs da etapa 5 do DNS do Azure. O DNS do Azure responderá com um dos domínios listados na etapa 1.
O Servidor DNS local resolve recursivamente o registro CNAME do domínio do espaço de trabalho do Servidor DNS:
O Servidor DNS local continuará a resolver recursivamente o CNAME recebido na etapa 7. Como houve uma configuração de encaminhador condicional na etapa 4, o Servidor DNS local enviará a solicitação ao Servidor DNS para resolução.
O Servidor DNS resolve recursivamente o registro CNAME do domínio do espaço de trabalho do DNS do Azure:
O Servidor DNS continuará a resolver recursivamente o CNAME recebido na etapa 7. Como houve uma configuração de encaminhador condicional na etapa 3, o Servidor DNS enviará a solicitação para o endereço IP do Servidor Virtual DNS do Azure para resolução.
O DNS do Azure retorna registros da zona DNS Privada:
Os registos correspondentes armazenados nas Zonas DNS Privadas serão devolvidos ao Servidor DNS, o que significa que o Servidor Virtual DNS do Azure devolve os endereços IP do Ponto de Extremidade Privado.
O Servidor DNS local resolve o nome de domínio do espaço de trabalho para o endereço de ponto de extremidade privado:
A consulta do Servidor DNS local para o Servidor DNS na etapa 8 retorna os endereços IP associados ao Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning. Esses endereços IP são retornados ao cliente original, que agora se comunicará com o espaço de trabalho do Azure Machine Learning pelo Ponto de Extremidade Privado configurado na etapa 1.
Importante
Se o Gateway de VPN estiver sendo usado nessa configuração junto com IP de servidor DNS personalizado na VNet, o IP DNS do Azure (168.63.129.16) também precisará ser adicionado à lista para manter a comunicação sem interrupções.
Exemplo: arquivo Hosts
O hosts
arquivo é um documento de texto que Linux, macOS e Windows usam para substituir a resolução de nomes para o computador local. O arquivo contém uma lista de endereços IP e o nome de host correspondente. Quando o computador local tenta resolver um nome de host, se o nome do host estiver listado hosts
no arquivo, o nome será resolvido para o endereço IP correspondente.
Importante
O hosts
arquivo substitui apenas a resolução de nomes para o computador local. Se você quiser usar um hosts
arquivo com vários computadores, você deve modificá-lo individualmente em cada computador.
A tabela a seguir lista o local do hosts
arquivo:
Sistema operativo | Location |
---|---|
Linux | /etc/hosts |
macOS | /etc/hosts |
Windows | %SystemRoot%\System32\drivers\etc\hosts |
Gorjeta
O nome do arquivo é hosts
sem extensão. Ao editar o arquivo, use o acesso de administrador. Por exemplo, no Linux ou macOS você pode usar sudo vi
o . No Windows, execute o bloco de notas como administrador.
Segue-se um exemplo de entradas de hosts
ficheiro para o Azure Machine Learning:
# For core Azure Machine Learning hosts
10.1.0.5 fb7e20a0-8891-458b-b969-55ddb3382f51.workspace.eastus.api.azureml.ms
10.1.0.5 fb7e20a0-8891-458b-b969-55ddb3382f51.workspace.eastus.cert.api.azureml.ms
10.1.0.6 ml-myworkspace-eastus-fb7e20a0-8891-458b-b969-55ddb3382f51.eastus.notebooks.azure.net
# For a managed online/batch endpoint named 'mymanagedendpoint'
10.1.0.7 mymanagedendpoint.eastus.inference.ml.azure.com
# For a compute instance named 'mycomputeinstance'
10.1.0.5 mycomputeinstance.eastus.instances.azureml.ms
Para obter mais informações sobre o hosts
arquivo, consulte https://wikipedia.org/wiki/Hosts_(file).
Resolução DNS dos serviços de dependência
Os serviços nos quais seu espaço de trabalho depende também podem ser protegidos usando um ponto de extremidade privado. Em caso afirmativo, talvez seja necessário criar um registro DNS personalizado se precisar se comunicar diretamente com o serviço. Por exemplo, se você quiser trabalhar diretamente com os dados em uma Conta de Armazenamento do Azure usada pelo seu espaço de trabalho.
Nota
Alguns serviços têm vários pontos de extremidade privados para subserviços ou recursos. Por exemplo, uma Conta de Armazenamento do Azure pode ter pontos de extremidade privados individuais para Blob, Arquivo e DFS. Se você precisar acessar o armazenamento de Blob e Arquivo, deverá habilitar a resolução para cada ponto de extremidade privado específico.
Para obter mais informações sobre os serviços e a resolução de DNS, consulte Configuração de DNS do Ponto de Extremidade Privado do Azure.
Resolução de Problemas
Se, depois de executar as etapas acima, você não conseguir acessar o espaço de trabalho de uma máquina virtual ou os trabalhos falharem nos recursos de computação na Rede Virtual que contém o Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning, siga as etapas abaixo para tentar identificar a causa.
Localize os FQDNs do espaço de trabalho no ponto de extremidade privado:
Navegue até o portal do Azure usando um dos seguintes links:
- Regiões públicas do Azure
- Microsoft Azure operado por 21Vianet regiões
- Azure Regiões do Governo dos EUA
Navegue até o Ponto de Extremidade Privado para o espaço de trabalho do Azure Machine Learning. Os FQDNs do espaço de trabalho serão listados na guia "Visão geral".
Acesse o recurso de computação na topologia da Rede Virtual:
Prossiga para acessar um recurso de computação na topologia da Rede Virtual do Azure. Isso provavelmente exigirá o acesso a uma Máquina Virtual em uma Rede Virtual emparelhada com a Rede Virtual do Hub.
Resolver FQDNs do espaço de trabalho:
Abra um prompt de comando, shell ou PowerShell. Em seguida, para cada um dos FQDN da área de trabalho, execute o seguinte comando:
nslookup <workspace FQDN>
O resultado de cada nslookup deve suspender um dos dois endereços IP privado no Ponto Final Privado para a área de trabalho do Azure Machine Learning. Se tal não acontecer, significa que existe uma configuração incorreta na solução DNS personalizada.
Causas possíveis:
- O recurso de computação em execução nos comandos de resolução de problemas não está a utilizar o Servidor DNS para a resolução DNS
- As Zonas DNS Privado selecionadas ao criar o Ponto Final Privado não estão associadas à VNet do Servidor DNS
- Os reencaminhadores condicionais do Servidor DNS para o IP do Servidor Virtual DNS do Azure não foram corretamente configurados
- Os reencaminhadores condicionais do Servidor DNS no Local para o Servidor DNS não foram corretamente configurados
Conteúdos relacionados
Para obter informações sobre como integrar pontos de extremidade privados em sua configuração de DNS, consulte Configuração de DNS do ponto de extremidade privado do Azure.