Come usare l'area di lavoro con un server DNS personalizzato

Articolo
09/03/2024

Quando si usa un'area di lavoro di Azure Machine Learning (tra cui gli hub di Azure per intelligenza artificiale) con un endpoint privato, esistono diversi modi per gestire la risoluzione dei nomi DNS. Per impostazione predefinita, Azure gestisce automaticamente la risoluzione dei nomi per l'area di lavoro e l'endpoint privato. Se invece si usa il proprio server DNS personalizzato, è necessario creare manualmente voci DNS o usare server d'inoltro condizionale per l'area di lavoro.

Importante

Questo articolo illustra come trovare i nomi di dominio completi (FQDN) e gli indirizzi IP per queste voci se si desidera registrare manualmente i record DNS nella soluzione DNS. Fornisce inoltre raccomandazioni sull'architettura per configurare la soluzione DNS personalizzata in modo che risolva automaticamente gli FQDN negli indirizzi IP corretti. NON Fornisce informazioni sulla configurazione dei record DNS per questi elementi. Per informazioni su come aggiungere record, vedere la documentazione relativa al software DNS.

Prerequisiti

Una rete virtuale di Azure che usa il proprio serve DNS.

Un'area di lavoro di Azure Machine Learning con un endpoint privato, che comprenda le aree di lavoro dell’hub, ad esempio quelle usate da Studio AI della piattaforma Azure. Per ulteriori informazioni, vedere Creare un'area di lavoro di Azure Machine Learning.
Se le risorse di dipendenza dell'area di lavoro sono protette con una rete virtuale di Azure, acquisire familiarità con l'articolo Isolamento della rete durante il training e l'inferenza.

Un'area di lavoro di Azure Machine Learning con endpoint privato. Per ulteriori informazioni, vedere Creare un'area di lavoro di Azure Machine Learning.
Familiarità con l'uso dell'isolamento della rete durante il training e l'inferenza.

Familiarità con la configurazione della zona DNS dell'endpoint privato di Azure
Familiarità con il DNS privato di Azure
Facoltativamente, l'interfaccia della riga di comando di Azure o Azure PowerShell.

Integrazione automatica del server DNS

Introduzione

Esistono due architetture comuni per l'uso dell'integrazione automatica del server DNS con Azure Machine Learning:

Un server DNS personalizzato ospitato in una rete virtuale di Azure.
Un server DNS personalizzato ospitato in locale, connesso ad Azure Machine Learning tramite ExpressRoute.

Anche se l'architettura può differire da questi esempi, è possibile usare i suddetti come punto di riferimento. Entrambe le architetture di esempio forniscono passaggi per la risoluzione dei problemi che consentono di identificare i componenti che potrebbero non essere configurati correttamente.

Un'altra opzione consiste nel modificare il filehosts nel client che si connette alla rete virtuale di Azure (VNet) contenente l'area di lavoro. Per altre informazioni, vedere la sezione sul file host.

Percorso di risoluzione DNS dell'area di lavoro

L'accesso a una determinata area di lavoro di Azure Machine Learning tramite collegamento privato viene eseguito comunicando con i seguenti domini completi (denominati FQDN dell'area di lavoro):

Importante

Se si usa l’area di lavoro di un hub (incluso l'hub di Studio AI della piattaforma Azure), verranno visualizzate anche altre voci per ogni area di lavoro del progetto creata dall’hub.

Regioni pubbliche di 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 - Usato dal comando az ml compute connect-ssh per connettersi ad ambienti di calcolo in una rete virtuale gestita.
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
<managed online endpoint name>.<region>.inference.ml.azure.com- in uso da parte di endpoint online gestiti

Suggerimento

Se si usa l'area di lavoro di un hub, sono disponibili anche i nomi di dominio completi seguenti per ogni area di lavoro del progetto creata dall'area di lavoro dell’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 gestito da regioni 21Vianet:

<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 - Usato dal comando az ml compute connect-ssh per connettersi ad ambienti di calcolo in una rete virtuale gestita.
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
<managed online endpoint name>.<region>.inference.ml.azure.cn- in uso da parte di endpoint online gestiti

Suggerimento

Se si usa l'area di lavoro di un hub, sono disponibili anche i nomi di dominio completi seguenti per ogni area di lavoro del progetto creata dall'area di lavoro dell’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

Regioni di Azure US Government:

<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 - Usato dal comando az ml compute connect-ssh per connettersi ad ambienti di calcolo in una rete virtuale gestita.
ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
<managed online endpoint name>.<region>.inference.ml.azure.us- in uso da parte di endpoint online gestiti

Suggerimento

Se si usa l'area di lavoro di un hub, sono disponibili anche i nomi di dominio completi seguenti per ogni area di lavoro del progetto creata dall'area di lavoro dell’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

I domini completi vengono risolti nei seguenti Nomi Canonical (CNAME) denominati FQDN del collegamento privato dell'area di lavoro:

Regioni pubbliche di 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 - in uso da parte di endpoint online gestiti

Azure gestito da regioni 21Vianet:

<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- in uso da parte di endpoint online gestiti

Regioni di Azure US Government:

<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 - in uso da parte di endpoint online gestiti

Gli FQDN vengono risolti negli indirizzi IP dell'area di lavoro di Azure Machine Learning in tale regione. Tuttavia, è possibile eseguire l'override della risoluzione degli FQDN del collegamento privato dell'area di lavoro usando un server DNS personalizzato ospitato nella rete virtuale. Per un esempio di questa architettura, vedere l'esempio di server DNS personalizzato ospitato in una rete virtuale. Per le aree di lavoro dell’hub e del progetto, i nomi di dominio completi di tutte le aree di lavoro del progetto vengono risolti nell'indirizzo IP dell'area di lavoro dell’hub.

Nota

Gli endpoint online gestiti condividono l'endpoint privato dell'area di lavoro. Se si aggiungono manualmente record DNS alla zona DNS privata privatelink.api.azureml.ms, è necessario aggiungere un record A con carattere jolly *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms per instradare tutti gli endpoint nell'area di lavoro all'endpoint privato.

Integrazione manuale del server DNS

In questa sezione vengono illustrati i domini completi per la creazione di record A in un server DNS e l'indirizzo IP su cui impostare il valore del record A.

Recuperare nomi di dominio completi dell'endpoint privato

Regione pubblica di Azure

L'elenco seguente contiene i nomi di dominio completi (FQDN) usati dall'area di lavoro laddove la suddetta si trovi nel cloud pubblico di 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

Il nome dell'area di lavoro per questo FQDN può essere troncato. Il troncamento viene eseguito per mantenere ml-<workspace-name, truncated>-<region>-<workspace-guid> a 63 caratteri o meno.
<instance-name>.<region>.instances.azureml.ms
Nota
- È possibile accedere alle istanze di ambiente di calcolo solo dall'interno della rete virtuale.
- L'indirizzo IP per questo FQDN non è l'indirizzo IP dell'istanza di ambiente di calcolo. Usare invece l'indirizzo IP privato dell'endpoint privato dell'area di lavoro (indirizzo IP delle voci *.api.azureml.ms).
<instance-name>-22.<region>.instances.azureml.ms - Usato solo dal comando az ml compute connect-ssh per connettersi ad ambienti di calcolo in una rete virtuale gestita. Non necessario se non si usa una rete gestita o connessioni SSH.
<managed online endpoint name>.<region>.inference.ml.azure.com- in uso da parte di endpoint online gestiti

Suggerimento

Se si usano aree di lavoro per l’hub e il progetto, ogni area di lavoro del progetto ha un proprio set di altri nomi di dominio completi. Per altre informazioni, vedere la sezione Risoluzione DNS dell’area di lavoro.

Microsoft Azure gestito dalla regione 21Vianet

I seguenti nomi di dominio completi sono per Microsoft Azure gestito dalle regioni 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

Il nome dell'area di lavoro per questo FQDN può essere troncato. Il troncamento viene eseguito per mantenere ml-<workspace-name, truncated>-<region>-<workspace-guid> a 63 caratteri o meno.
<instance-name>.<region>.instances.azureml.cn
- L'indirizzo IP per questo FQDN non è l'indirizzo IP dell'istanza di ambiente di calcolo. Usare invece l'indirizzo IP privato dell'endpoint privato dell'area di lavoro (indirizzo IP delle voci *.api.azureml.ms).
<instance-name>-22.<region>.instances.azureml.cn - Usato solo dal comando az ml compute connect-ssh per connettersi ad ambienti di calcolo in una rete virtuale gestita. Non necessario se non si usa una rete gestita o connessioni SSH.
<managed online endpoint name>.<region>.inference.ml.azure.cn- in uso da parte di endpoint online gestiti

Suggerimento

Azure Governo Statunitense

I seguenti nomi di dominio completi sono per le regioni di 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

Il nome dell'area di lavoro per questo FQDN può essere troncato. Il troncamento viene eseguito per mantenere ml-<workspace-name, truncated>-<region>-<workspace-guid> a 63 caratteri o meno.
<instance-name>.<region>.instances.azureml.us
- L'indirizzo IP per questo FQDN non è l'indirizzo IP dell'istanza di ambiente di calcolo. Usare invece l'indirizzo IP privato dell'endpoint privato dell'area di lavoro (indirizzo IP delle voci *.api.azureml.ms).
<instance-name>-22.<region>.instances.azureml.us - Usato solo dal comando az ml compute connect-ssh per connettersi ad ambienti di calcolo in una rete virtuale gestita. Non necessario se non si usa una rete gestita o connessioni SSH.
<managed online endpoint name>.<region>.inference.ml.azure.us- in uso da parte di endpoint online gestiti

Suggerimento

Trovare gli indirizzi IP

Usare uno dei metodi seguenti per trovare gli indirizzi IP interni per i nomi di dominio completi nella rete virtuale:

Nota

I nomi di dominio completi e gli indirizzi IP saranno diversi in base alla configurazione. Ad esempio, il valore GUID nel nome di dominio sarà specifico per l'area di lavoro.

Usare il comando seguente per ottenere l'ID dell'interfaccia di rete dell'endpoint privato:

az network private-endpoint show --name <endpoint> --resource-group <resource-group> --query 'networkInterfaces[*].id' --output table

Per ottenere le informazioni sull'indirizzo IP e sul nome di dominio completo dell'area di lavoro o dell'area di lavoro dell'hub, usare il comando seguente. Sostituire <resource-id> con l'ID del passaggio precedente:

az network nic show --ids <resource-id> --query 'ipConfigurations[*].{IPAddress: privateIpAddress, FQDNs: privateLinkConnectionProperties.fqdns}'

L'output sarà simile al testo seguente:

[
    {
        "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 si usa un'area di lavoro dell’ hub, seguire questa procedura per ogni area di lavoro del progetto creata dall'hub:
1. Per ottenere l'ID dell'area di lavoro del progetto, usare il comando seguente:
```
az ml workspace show --name <project-workspace-name> --resource-group <resource-group> --query 'discovery_url'
```
  Il valore restituito avrà il 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>.
2. Accettare i nomi di dominio completi restituiti dall'area di lavoro dell'hub che terminano con workspace.<region>.api.azureml.ms e workspace.<region>.cert.api.azureml.ms. Sostituire il valore GUID all'inizio di questi nomi di dominio completi con l'ID dell'area di lavoro del progetto. Questi nomi di dominio completi si aggiungono a quelli dell’area di lavoro dell’hub.
3. Accettare il nome di dominio completo restituito dall'area di lavoro dell'hub con il formato indicato in <workspace-name>-<region>-<GUID>.<region>.notebooks.azure.net. Sostituire il valore GUID con l'ID dell'area di lavoro del progetto. Sostituire il nome dell'area di lavoro dell’hub con il nome dell'area di lavoro del progetto. È talvolta necessario troncare il nome dell'area di lavoro per mantenere questa voce a una lunghezza pari o inferiore a 63 caratteri. Questo nome di dominio completo si aggiunge a quello dell'area di lavoro dell'hub.

$workspaceDns=Get-AzPrivateEndpoint -Name <endpoint> -resourcegroupname <resource-group>
$workspaceDns.CustomDnsConfigs | format-table

Le informazioni restituite da tutti i metodi sono le stesse; un elenco del nomi di dominio completi e degli indirizzi IP privati per le risorse. L'esempio seguente proviene dal cloud pubblico di Azure:

FQDN	Indirizzo 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`

La tabella seguente illustra gli indirizzi IP di esempio di Microsoft Azure gestiti da regioni 21Vianet:

FQDN	Indirizzo 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`

La tabella seguente mostra gli indirizzi IP di esempio dalle regioni di Azure US Government:

FQDN	Indirizzo 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

Gli endpoint online gestiti condividono l'endpoint privato dell'area di lavoro. Se si aggiungono manualmente record DNS alla zona DNS privato privatelink.api.azureml.ms, è necessario aggiungere un record A con carattere jolly *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms per instradare tutti gli endpoint nell'area di lavoro all'endpoint privato.

Creare record A nel server DNS personalizzato

Dopo aver raccolto l'elenco di FQDN e degli indirizzi IP corrispondenti, procedere con la creazione di record A nel server DNS configurato. Per determinare come creare record A, vedere la documentazione relativa al server DNS. Si noti che è consigliabile creare una zona univoca per l'intero FQDN e creare il record A nella radice della zona.

Esempio: Server DNS personalizzato ospitato nella rete virtuale

Questa architettura usa la topologia di rete virtuale Hub e Spoke comune. Una rete virtuale contiene il server DNS e un'altra l'endpoint privato per l'area di lavoro di Azure Machine Learning e le risorse associate. Deve essere presente una route valida tra entrambe le reti virtuali. Ad esempio, tramite una serie di reti virtuali con peering.

I seguenti passaggi descrivono il funzionamento di questa topologia:

Creare una zona DNS privato e collegarsi alla rete virtuale del server DNS:

Il primo passaggio per garantire che una soluzione DNS personalizzata funzioni con l'area di lavoro di Azure Machine Learning consiste nel creare due zone DNS privato radicate nei domini seguenti:

Regioni pubbliche di Azure:
- privatelink.api.azureml.ms
- privatelink.notebooks.azure.net
Microsoft Azure gestito da regioni 21Vianet:
- privatelink.api.ml.azure.cn
- privatelink.notebooks.chinacloudapi.cn
Regioni di Azure US Government:
- privatelink.api.ml.azure.us
- privatelink.notebooks.usgovcloudapi.net
Nota

Gli endpoint online gestiti condividono l'endpoint privato dell'area di lavoro. Se si aggiungono manualmente record DNS alla zona DNS privato privatelink.api.azureml.ms, è necessario aggiungere un record A con carattere jolly *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms per instradare tutti gli endpoint nell'area di lavoro all'endpoint privato.

Una volta creata la zona DNS privato, è necessario collegarla alla rete virtuale del server DNS. Rete virtuale che contiene il server DNS.

Una zona DNS privato esegue l'override della risoluzione dei nomi per tutti i nomi all'interno dell'ambito della radice della zona. La sostituzione si applica a tutte le reti virtuali a cui è collegata la zona DNS privato. Ad esempio, se una zona DNS privato radicata in privatelink.api.azureml.ms è collegata a rete virtuale foo, tutte le risorse della rete virtuale foo che tentano di risolvere bar.workspace.westus2.privatelink.api.azureml.ms riceveranno qualsiasi record elencato nella zona privatelink.api.azureml.ms.

Tuttavia, i record elencati nelle zone DNS privato vengono restituiti solo ai dispositivi che risolvono i domini usando l'indirizzo IP predefinito del server virtuale DNS di Azure. Di conseguenza, il server DNS personalizzato risolverà i domini per i dispositivi distribuiti in tutta la topologia di rete. Tuttavia, il server DNS personalizzato dovrà risolvere i domini correlati ad Azure Machine Learning rispetto all'indirizzo IP del server virtuale DNS di Azure.
Creare un endpoint privato con integrazione DNS privato destinata alla zona DNS privato collegata alla rete virtuale del server DNS:

Il passaggio successivo consiste nel creare un endpoint privato per l'area di lavoro di Azure Machine Learning. L'endpoint privato è destinato a entrambe le zone DNS privato create nel passaggio 1. In questo modo tutte le comunicazioni con l'area di lavoro vengono eseguite tramite l'endpoint privato nella rete virtuale di Azure Machine Learning.

Importante

Perché questo esempio funzioni correttamente, l'endpoint privato deve avere l'integrazione DNS privato abilitata.
Creare un server d'inoltro condizionale nel server DNS per l'inoltro a DNS di Azure:

Creare quindi un server d'inoltro condizionale al server virtuale DNS di Azure. Il server d'inoltro condizionale garantisce che il server DNS esegua sempre query sull'indirizzo IP del server virtuale DNS di Azure circa i nomi di dominio completi correlati all'area di lavoro. Ciò significa che il server DNS restituirà il record corrispondente dalla zona DNS privato.

Di seguito sono elencate le zone da inoltrare in modo condizionale. L'indirizzo IP del server virtuale DNS di Azure è 168.63.129.16:

Regioni pubbliche di Azure:
- api.azureml.ms
- notebooks.azure.net
- instances.azureml.ms
- aznbcontent.net
- inference.ml.azure.com - in uso da parte di endpoint online gestiti
Microsoft Azure gestito da regioni 21Vianet:
- api.ml.azure.cn
- notebooks.chinacloudapi.cn
- instances.azureml.cn
- aznbcontent.net
- inference.ml.azure.cn - in uso da parte di endpoint online gestiti
Regioni di Azure US Government:
- api.ml.azure.us
- notebooks.usgovcloudapi.net
- instances.azureml.us
- aznbcontent.net
- inference.ml.azure.us - in uso da parte di endpoint online gestiti
Importante

I passaggi di configurazione per il server DNS non sono inclusi qui, poiché sono disponibili molte soluzioni DNS che è possibile usare come server DNS personalizzato. Per informazioni su come configurare in modo appropriato l'inoltro condizionale, vedere la documentazione relativa alla soluzione DNS.
Risolvere il dominio dell'area di lavoro:

A questo punto, tutte le operazioni di configurazione vengono eseguite. Ora qualsiasi client che usa il server DNS per la risoluzione dei nomi e ha una route all'endpoint privato di Azure Machine Learning può continuare ad accedere all'area di lavoro. Il client inizierà dapprima eseguendo una query sul server DNS per l'indirizzo dei seguenti nomi di dominio completi:

Regioni pubbliche di 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 - in uso da parte di endpoint online gestiti
Microsoft Azure gestito da regioni 21Vianet:
- <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 - in uso da parte di endpoint online gestiti
Regioni di Azure US Government:
- <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 - in uso da parte di endpoint online gestiti
DNS di Azure risolve in modo ricorsivo il dominio dell'area di lavoro in CNAME:

Il server DNS risolverà i nomi di dominio completi del passaggio 4 da DNS di Azure. DNS di Azure risponderà con uno dei domini elencati nel passaggio 1.
Il server DNS risolve in modo ricorsivo il record CNAME del dominio dell'area di lavoro da DNS di Azure:

Il server DNS continuerà a risolvere in modo ricorsivo il CNAME ricevuto nel passaggio 5. Poiché nel passaggio 3 è stato configurato un server d'inoltro condizionale, il server DNS invierà la richiesta all'indirizzo IP del server virtuale DNS di Azure per la risoluzione.
DNS di Azure restituisce record dalla zona DNS privato:

I record corrispondenti archiviati nelle zone DNS privato verranno restituiti al server DNS, il che significa che il server virtuale DNS di Azure restituisce gli indirizzi IP dell'endpoint privato.
Il server DNS personalizzato risolve il nome di dominio dell'area di lavoro in un indirizzo endpoint privato:

Infine, il server DNS personalizzato restituisce ora gli indirizzi IP dell'endpoint privato al client dal passaggio 4. In questo modo tutto il traffico verso l'area di lavoro di Azure Machine Learning viene eseguito tramite l'endpoint privato.

Risoluzione dei problemi

Se non è possibile accedere all'area di lavoro da una macchina virtuale, oppure i processi danno un esito negativo nelle risorse di calcolo nella rete virtuale, seguire questa procedura per identificare la causa:

Individuare gli FQDN dell'area di lavoro nell'endpoint privato:

Andare al portale di Azure usando uno dei collegamenti seguenti:
Andare all'endpoint privato per l'area di lavoro di Azure Machine Learning. Gli FQDN dell'area di lavoro verranno elencati nella scheda "Panoramica".
Accedere alla risorsa di calcolo nella topologia di rete virtuale:

Passare all'accesso a una risorsa di calcolo nella topologia della rete virtuale di Azure. È probabile che sia necessario accedere a una macchina virtuale in una rete virtuale con peering con la rete virtuale hub.
Risolvere i nomi di dominio completi dell'area di lavoro:

Aprire un prompt dei comandi, una shell o PowerShell. Quindi, eseguire il comando seguente per ogni FQDN dell'area di lavoro:

nslookup <workspace FQDN>

Il risultato di ogni nslookup deve restituire uno dei due indirizzi IP privati nell'endpoint privato per l'area di lavoro di Azure Machine Learning. Altrimenti, c'è un errore di configurazione nella soluzione DNS personalizzata.

Possibili cause:
- La risorsa di calcolo che esegue i comandi per la risoluzione dei problemi non usa il server DNS per la risoluzione DNS
- Le zone DNS privato scelte durante la creazione dell'endpoint privato non sono collegate alla rete virtuale del server DNS
- I server d'inoltro condizionali all'IP del server virtuale DNS di Azure non sono stati configurati correttamente

Esempio: Server DNS personalizzato ospitato in locale

Questa architettura usa la topologia di rete virtuale Hub e Spoke comune. ExpressRoute viene usato per connettersi dalla rete locale alla rete virtuale hub. Il server DNS personalizzato è ospitato in locale. Una rete virtuale separata contiene l'endpoint privato per l'area di lavoro di Azure Machine Learning e le risorse associate. Con questa topologia, deve essere presente un'altra rete virtuale che ospita un server DNS che può inviare richieste all'indirizzo IP del server virtuale DNS di Azure.

I seguenti passaggi descrivono il funzionamento di questa topologia:

Creare una zona DNS privato e collegarsi alla rete virtuale del server DNS:

Il primo passaggio per garantire che una soluzione DNS personalizzata funzioni con l'area di lavoro di Azure Machine Learning consiste nel creare due zone DNS privato radicate nei domini seguenti:

Regioni pubbliche di Azure:
- privatelink.api.azureml.ms
- privatelink.notebooks.azure.net
Microsoft Azure gestito da regioni 21Vianet:
- privatelink.api.ml.azure.cn
- privatelink.notebooks.chinacloudapi.cn
Regioni di Azure US Government:
- privatelink.api.ml.azure.us
- privatelink.notebooks.usgovcloudapi.net
Nota

Gli endpoint online gestiti condividono l'endpoint privato dell'area di lavoro. Se si aggiungono manualmente record DNS alla zona DNS privato privatelink.api.azureml.ms, è necessario aggiungere un record A con carattere jolly *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms per instradare tutti gli endpoint nell'area di lavoro all'endpoint privato.

Una volta creata la zona DNS privato, è necessario collegarla alla rete virtuale del server DNS, ossia la rete virtuale che contiene il server DNS.

Nota

Il server DNS nella rete virtuale è separato dal server DNS locale.

Una zona DNS privato esegue l'override della risoluzione dei nomi per tutti i nomi all'interno dell'ambito della radice della zona. La sostituzione si applica a tutte le reti virtuali a cui è collegata la zona DNS privato. Ad esempio, se una zona DNS privato radicata in privatelink.api.azureml.ms è collegata a rete virtuale foo, tutte le risorse nella rete virtuale foo che tentano di risolvere bar.workspace.westus2.privatelink.api.azureml.ms riceveranno qualsiasi record elencato nella zona privatelink.api.azureml.ms.

Tuttavia, i record elencati nelle zone DNS privato vengono restituiti solo ai dispositivi che risolvono i domini usando l'indirizzo IP predefinito del server virtuale DNS di Azure. L'indirizzo IP del server virtuale DNS di Azure è valido solo nel contesto di una rete virtuale. Quando si usa un server DNS locale, il suddetto on è in grado di eseguire query sull'indirizzo IP del server virtuale DNS di Azure per recuperare i record.

Per aggirare questo comportamento, creare un server DNS intermedio in una rete virtuale. Questo server DNS può eseguire una query sull'indirizzo IP del server virtuale DNS di Azure per recuperare i record per qualsiasi zona DNS privato collegata alla rete virtuale.

Mentre il server DNS locale risolverà i domini per i dispositivi distribuiti in tutta la topologia di rete, risolverà i domini correlati ad Azure Machine Learning rispetto al server DNS. Il server DNS risolverà tali domini dall'indirizzo IP del server virtuale DNS di Azure.
Creare un endpoint privato con integrazione DNS privato destinata alla zona DNS privato collegata alla rete virtuale del server DNS:

Il passaggio successivo consiste nel creare un endpoint privato per l'area di lavoro di Azure Machine Learning. L'endpoint privato è destinato a entrambe le zone DNS privato create nel passaggio 1. In questo modo tutte le comunicazioni con l'area di lavoro vengono eseguite tramite l'endpoint privato nella rete virtuale di Azure Machine Learning.

Importante

Perché questo esempio funzioni correttamente, l'endpoint privato deve avere l'integrazione DNS privato abilitata.
Creare un server d'inoltro condizionale nel server DNS per l'inoltro a DNS di Azure:

Creare quindi un server d'inoltro condizionale al server virtuale DNS di Azure. Il server d'inoltro condizionale garantisce che il server DNS esegua sempre query sull'indirizzo IP del server virtuale DNS di Azure circa i nomi di dominio completi correlati all'area di lavoro. Ciò significa che il server DNS restituirà il record corrispondente dalla zona DNS privato.

Di seguito sono elencate le zone da inoltrare in modo condizionale. L'indirizzo IP del server virtuale DNS di Azure è 168.63.129.16.

Regioni pubbliche di Azure:
- api.azureml.ms
- notebooks.azure.net
- instances.azureml.ms
- aznbcontent.net
- inference.ml.azure.com - in uso da parte di endpoint online gestiti
Microsoft Azure gestito da regioni 21Vianet:
- api.ml.azure.cn
- notebooks.chinacloudapi.cn
- instances.azureml.cn
- aznbcontent.net
- inference.ml.azure.cn - in uso da parte di endpoint online gestiti
Regioni di Azure US Government:
- api.ml.azure.us
- notebooks.usgovcloudapi.net
- instances.azureml.us
- aznbcontent.net
- inference.ml.azure.us - in uso da parte di endpoint online gestiti
Importante

I passaggi di configurazione per il server DNS non sono inclusi qui, poiché sono disponibili molte soluzioni DNS che è possibile usare come server DNS personalizzato. Per informazioni su come configurare in modo appropriato l'inoltro condizionale, vedere la documentazione relativa alla soluzione DNS.
Creare un server d'inoltro condizionale nel server DNS locale per l'inoltro al server DNS:

Successivamente, creare un server d'inoltro condizionale al server DNS nella rete virtuale del server DNS. Il server d'inoltro è destinato alle zone elencate nel passaggio 1. È simile al passaggio 3, con la differenza che, invece di eseguire l'inoltro all'indirizzo IP del server virtuale DNS di Azure, il server DNS locale sarà destinato all'indirizzo IP del server DNS. Poiché il server DNS locale non si trova in Azure, non è in grado di risolvere direttamente i record nelle zone DNS privato. In questo caso, i proxy del server DNS vengono richiesti dal server DNS locale all'indirizzo IP del server virtuale DNS di Azure. Ciò consente al server DNS locale di recuperare i record nelle zone DNS privato collegate alla rete virtuale del server DNS.

Di seguito sono elencate le zone da inoltrare in modo condizionale. Gli indirizzi IP a cui inoltrare sono gli indirizzi IP dei server DNS:

Regioni pubbliche di Azure:
- api.azureml.ms
- notebooks.azure.net
- instances.azureml.ms
- inference.ml.azure.com - in uso da parte di endpoint online gestiti
Microsoft Azure gestito da regioni 21Vianet:
- api.ml.azure.cn
- notebooks.chinacloudapi.cn
- instances.azureml.cn
- inference.ml.azure.cn - in uso da parte di endpoint online gestiti
Regioni di Azure US Government:
- api.ml.azure.us
- notebooks.usgovcloudapi.net
- instances.azureml.us
- inference.ml.azure.us - in uso da parte di endpoint online gestiti
Importante

I passaggi di configurazione per il server DNS non sono inclusi qui, poiché sono disponibili molte soluzioni DNS che è possibile usare come server DNS personalizzato. Per informazioni su come configurare in modo appropriato l'inoltro condizionale, vedere la documentazione relativa alla soluzione DNS.
Risolvere il dominio dell'area di lavoro:

A questo punto, tutte le operazioni di configurazione vengono eseguite. Qualsiasi client che usa il server DNS locale per la risoluzione dei nomi e ha una route all'endpoint privato di Azure Machine Learning può continuare ad accedere all'area di lavoro.

Il client inizierà prima eseguendo una query sul server DNS locale per l'indirizzo dei seguenti nomi di dominio completi:

Regioni pubbliche di 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 - in uso da parte di endpoint online gestiti
Microsoft Azure gestito da regioni 21Vianet:
- <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 - in uso da parte di endpoint online gestiti
Regioni di Azure US Government:
- <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 - in uso da parte di endpoint online gestiti
Il server DNS locale risolve in modo ricorsivo il dominio dell'area di lavoro:

Il server DNS locale risolverà i nomi di dominio completi dal passaggio 5 dal server DNS. Poiché è presente un server d'inoltro condizionale (passaggio 4), il server DNS locale invierà la richiesta al server DNS per la risoluzione.
Il server DNS risolve il dominio dell'area di lavoro in CNAME da DNS di Azure:

Il server DNS risolverà i nomi di dominio completi del passaggio 5 dal DNS di Azure. DNS di Azure risponderà con uno dei domini elencati nel passaggio 1.
Il server DNS locale risolve in modo ricorsivo il record CNAME del dominio dell'area di lavoro dal server DNS:

Il server DNS locale continuerà a risolvere in modo ricorsivo il CNAME ricevuto nel passaggio 7. Poiché nel passaggio 4 è stato configurato un server d'inoltro condizionale, il server DNS locale invierà la richiesta al server DNS per la risoluzione.
Il server DNS risolve in modo ricorsivo il record CNAME del dominio dell'area di lavoro da DNS di Azure:

Il server DNS continuerà a risolvere in modo ricorsivo il CNAME ricevuto nel passaggio 7. Poiché nel passaggio 3 è stato configurato un server d'inoltro condizionale, il server DNS invierà la richiesta all'indirizzo IP del server virtuale DNS di Azure per la risoluzione.
DNS di Azure restituisce record dalla zona DNS privato:

I record corrispondenti archiviati nelle zone DNS privato verranno restituiti al server DNS, il che significa che il server virtuale DNS di Azure restituisce gli indirizzi IP dell'endpoint privato.
Il server DNS locale risolve il nome di dominio dell'area di lavoro in un indirizzo endpoint privato:

La query dal server DNS locale al server DNS nel passaggio 8 restituisce gli indirizzi IP associati all'endpoint privato per l'area di lavoro di Azure Machine Learning. Questi indirizzi IP vengono restituiti al client originale, che ora comunicherà con l'area di lavoro di Azure Machine Learning sull'endpoint privato configurato nel passaggio 1.

Importante

Se il gateway VPN viene usato in questa configurazione insieme all'indirizzo IP del server DNS personalizzato nella rete virtuale, è necessario aggiungere l'indirizzo IP DNS di Azure (168.63.129.16) nell'elenco e mantenere le comunicazioni non interrotte.

Esempio: File host

Il file hosts è un documento di testo usato da Linux, macOS e Windows per eseguire l'override della risoluzione dei nomi per il computer locale. Il file contiene un elenco di indirizzi IP e il nome host corrispondente. Quando il computer locale tenta di risolvere un nome host, se il suddetto è elencato nel file hosts, il nome viene risolto nell'indirizzo IP corrispondente.

Importante

Il file hosts esegue l'override solo della risoluzione dei nomi per il computer locale. Se si desidera utilizzare un file hosts con diversi computer, è necessario modificarlo singolarmente in ogni computer.

La tabella seguente elenca il percorso del file hosts:

Sistema operativo	Ufficio
Linux	`/etc/hosts`
macOS	`/etc/hosts`
Finestre	`%SystemRoot%\System32\drivers\etc\hosts`

Suggerimento

Il nome del file è hosts senza estensione. Quando si modifica il file, usare l'accesso amministratore. Ad esempio, in Linux o macOS è possibile usare sudo vi. In Windows eseguire Blocco note come amministratore.

Di seguito è riportato un esempio di voci di file hosts per 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

Per altre informazioni sul file hosts, vedere https://wikipedia.org/wiki/Hosts_(file).

Risoluzione DNS dei servizi di dipendenza

È anche possibile proteggere i servizi su cui si basa l'area di lavoro usando un endpoint privato. In tal caso, potrebbe essere necessario creare un record DNS personalizzato se è necessario comunicare direttamente con il servizio. Ad esempio, se si desidera usare direttamente i dati in un account di archiviazione di Azure usato dall'area di lavoro.

Nota

Alcuni servizi dispongono di diversi endpoint privati per servizi secondari o funzionalità. Ad esempio, un account di archiviazione di Azure può avere singoli endpoint privati per Blob, file e DFS. Se è necessario accedere sia all'archiviazione Blob che file, è necessario abilitare la risoluzione per ogni endpoint privato specifico.

Per altre informazioni sui servizi e sulla risoluzione DNS, vedere Configurazione DNS dell'endpoint privato di Azure.

Risoluzione dei problemi

Se dopo aver eseguito i passaggi precedenti non è possibile accedere all'area di lavoro da una macchina virtuale, oppure i processi danno un esito negativo nelle risorse di calcolo nella rete virtuale contenente l'endpoint privato per l'area di lavoro di Azure Machine Learning, seguire questa procedura per provare a identificare la causa.

Individuare gli FQDN dell'area di lavoro nell'endpoint privato:

Andare al portale di Azure usando uno dei collegamenti seguenti:
Andare all'endpoint privato per l'area di lavoro di Azure Machine Learning. Gli FQDN dell'area di lavoro verranno elencati nella scheda "Panoramica".
Accedere alla risorsa di calcolo nella topologia di rete virtuale:

Passare all'accesso a una risorsa di calcolo nella topologia della rete virtuale di Azure. È probabile che sia necessario accedere a una macchina virtuale in una rete virtuale con peering con la rete virtuale hub.
Risolvere i nomi di dominio completi dell'area di lavoro:

Aprire un prompt dei comandi, una shell o PowerShell. Quindi, eseguire il comando seguente per ogni FQDN dell'area di lavoro:

nslookup <workspace FQDN>

Il risultato di ogni nslookup deve produrre uno dei due indirizzi IP privati nell'endpoint privato per l'area di lavoro di Azure Machine Learning. Altrimenti, c'è un errore di configurazione nella soluzione DNS personalizzata.

Possibili cause:
- La risorsa di calcolo che esegue i comandi per la risoluzione dei problemi non usa il server DNS per la risoluzione DNS
- Le zone DNS privato scelte durante la creazione dell'endpoint privato non sono collegate alla rete virtuale del server DNS
- I server d'inoltro condizionali dal server DNS all'IP del server virtuale DNS di Azure non sono stati configurati correttamente
- I server d'inoltro condizionali dal server DNS locale al server DNS non sono stati configurati correttamente

Per informazioni sull'integrazione di endpoint privati nella configurazione DNS, vedere Configurazione DNS dell'endpoint privato di Azure.

Condividi tramite

Come usare l'area di lavoro con un server DNS personalizzato

Prerequisiti

Integrazione automatica del server DNS

Introduzione

Percorso di risoluzione DNS dell'area di lavoro

Integrazione manuale del server DNS

Recuperare nomi di dominio completi dell'endpoint privato

Regione pubblica di Azure

Microsoft Azure gestito dalla regione 21Vianet

Azure Governo Statunitense

Trovare gli indirizzi IP

Creare record A nel server DNS personalizzato

Esempio: Server DNS personalizzato ospitato nella rete virtuale

Risoluzione dei problemi

Esempio: Server DNS personalizzato ospitato in locale

Esempio: File host

Risoluzione DNS dei servizi di dipendenza

Risoluzione dei problemi

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Come usare l'area di lavoro con un server DNS personalizzato

Prerequisiti

Integrazione automatica del server DNS

Introduzione

Percorso di risoluzione DNS dell'area di lavoro

Integrazione manuale del server DNS

Recuperare nomi di dominio completi dell'endpoint privato

Regione pubblica di Azure

Microsoft Azure gestito dalla regione 21Vianet

Azure Governo Statunitense

Trovare gli indirizzi IP

Creare record A nel server DNS personalizzato

Esempio: Server DNS personalizzato ospitato nella rete virtuale

Risoluzione dei problemi

Esempio: Server DNS personalizzato ospitato in locale

Esempio: File host

Risoluzione DNS dei servizi di dipendenza

Risoluzione dei problemi

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive