Partager via

Utilisation de votre espace de travail avec un serveur DNS personnalisé

  • Article

Lorsque vous utilisez un espace de travail Azure Machine Learning (y compris les hubs Azure AI) avec un point de terminaison privé, il existe plusieurs manières de gérer la résolution de noms DNS. Par défaut, Azure gère automatiquement la résolution de noms pour votre espace de travail et votre point de terminaison privé. Si vous utilisez votre propre serveur DNS personnalisé, vous devez créer manuellement des entrées DNS ou utiliser des redirecteurs conditionnels pour l’espace de travail.

Important

Cet article explique comment obtenir les noms de domaine complets (FQDN) et les adresses IP de ces entrées si vous souhaitez inscrire manuellement des enregistrements DNS dans votre solution DNS. Il fournit également des recommandations sur l’architecture, indiquant comment configurer votre solution DNS personnalisée pour résoudre automatiquement les FQDN en adresses IP correctes. Cet article ne fournit pas d’informations sur la configuration des enregistrements DNS pour ces éléments. Pour savoir comment ajouter des enregistrements, consultez la documentation de votre logiciel DNS.

Prérequis

Intégration de serveur DNS automatisée

Introduction

Il existe deux architectures courantes pour l’utilisation de l’intégration de serveur DNS automatisée avec Azure Machine Learning :

Vous pouvez utiliser ces exemples comme points de référence même s’ils ne correspondent pas précisément à votre architecture. Les deux exemples d’architectures incluent des procédures de résolution des problèmes vous permettant d’identifier des composants qui pourraient être mal configurés.

Une autre option consiste à modifier le fichier hosts sur le client qui se connecte au réseau virtuel Azure (VNet) contenant votre espace de travail. Pour plus d’informations, consultez la section Fichier hosts.

Chemin de résolution DNS de l’espace de travail

L’accès à un espace de travail Azure Machine Learning donné par le biais d’une liaison privée implique une communication avec les noms de domaine complets listés ci-dessous (FQDN de l’espace de travail) :

Important

Si vous utilisez un espace de travail hub (y compris Azure AI Studio hub), vous aurez des entrées supplémentaires pour chaque espace de travail de projet créé à partir du hub.

Régions publiques 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 : utilisé par la commande az ml compute connect-ssh pour se connecter aux calculs dans un réseau virtuel managé.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
  • <managed online endpoint name>.<region>.inference.ml.azure.com - Utilisé par les points de terminaison en ligne managés

Conseil

Si vous utilisez un espace de travail hub, il existe également les noms de domaine complets suivants pour chaque espace de travail de projet créé à partir de l’espace de travail 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 géré par 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 : utilisé par la commande az ml compute connect-ssh pour se connecter aux calculs dans un réseau virtuel managé.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
  • <managed online endpoint name>.<region>.inference.ml.azure.cn - Utilisé par les points de terminaison en ligne managés

Conseil

Si vous utilisez un espace de travail hub, il existe également les noms de domaine complets suivants pour chaque espace de travail de projet créé à partir de l’espace de travail 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

Régions 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 : utilisé par la commande az ml compute connect-ssh pour se connecter aux calculs dans un réseau virtuel managé.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
  • <managed online endpoint name>.<region>.inference.ml.azure.us - Utilisé par les points de terminaison en ligne managés

Conseil

Si vous utilisez un espace de travail hub, il existe également les noms de domaine complets suivants pour chaque espace de travail de projet créé à partir de l’espace de travail 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

Les noms de domaine complets sont résolus en noms canoniques (CNAME), appelés FQDN de liaison privée de l’espace de travail, comme suit :

Régions publiques 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 - Utilisé par les points de terminaison en ligne managés

Régions Azure géré par le cloud 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 - Utilisé par les points de terminaison en ligne managés

Régions 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 - Utilisé par les points de terminaison en ligne managés

Les FQDN sont résolus en adresses IP de l’espace de travail Azure Machine Learning dans cette région. Toutefois, la résolution des noms de domaine complets de liaison privée de l’espace de travail peut être remplacée en utilisant un serveur DNS personnalisé hébergé dans le réseau virtuel. Pour obtenir un exemple de cette architecture, consultez l’exemple Serveur DNS personnalisé hébergé dans un réseau virtuel. Pour les espaces de travail hub et projet, les FQDN de tous les espaces de travail projet sont résolus par l'adresse IP de l'espace de travail hub.

Remarque

Les points de terminaison en ligne gérés partagent le point de terminaison privé de l’espace de travail. Si vous ajoutez manuellement des enregistrements DNS à la zone DNS privée privatelink.api.azureml.ms, un enregistrement A avec un caractère générique *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms doit être ajouté pour router tous les points de terminaison situés sous l’espace de travail vers le point de terminaison privé.

Intégration de serveur DNS manuelle

Cette section traite des domaines complets pour lesquels des enregistrements A doivent être créés dans un serveur DNS et de l’adresses IP sur laquelle la valeur de l’enregistrement A doit être définie.

Récupérer les FQDN de point de terminaison privé

Région publique Azure

La liste suivante contient les noms de domaine complets (FQDN) utilisés par votre espace de travail s’il se trouve dans le cloud public 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

    Notes

    Le nom de l’espace de travail pour ce nom de domaine complet peut être tronqué. Cette troncation a pour but de limiter la longueur de ml-<workspace-name, truncated>-<region>-<workspace-guid> à 63 caractères.

  • <instance-name>.<region>.instances.azureml.ms

    Notes

    • Les instances de calcul sont accessibles uniquement à partir du réseau virtuel.
    • L’adresse IP de ce nom de domaine complet n’est pas l’adresse IP de l’instance de calcul. Utilisez plutôt l’adresse IP privée du point de terminaison privé de l’espace de travail (l’adresse IP des entrées *.api.azureml.ms).

  • <instance-name>-22.<region>.instances.azureml.ms : utilisé uniquement par la commande az ml compute connect-ssh pour se connecter aux calculs dans un réseau virtuel managé. Non nécessaire si vous n’utilisez pas de réseau managé ou de connexions SSH.

  • <managed online endpoint name>.<region>.inference.ml.azure.com - Utilisé par les points de terminaison en ligne managés

Conseil

Si vous utilisez un hub et des espaces de travail de projet, chaque espace de travail de projet possède son propre ensemble de FQDNs supplémentaires. Pour plus d’informations, consultez la section Résolution d’espace de travail DNS.

Région Microsoft Azure géré par 21Vianet

Les FQDN (noms de domaines complets) suivants sont pour les régions Microsoft Azure géré par 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

    Notes

    Le nom de l’espace de travail pour ce nom de domaine complet peut être tronqué. Cette troncation a pour but de limiter la longueur de ml-<workspace-name, truncated>-<region>-<workspace-guid> à 63 caractères.

  • <instance-name>.<region>.instances.azureml.cn

    • L’adresse IP de ce nom de domaine complet n’est pas l’adresse IP de l’instance de calcul. Utilisez plutôt l’adresse IP privée du point de terminaison privé de l’espace de travail (l’adresse IP des entrées *.api.azureml.ms).

  • <instance-name>-22.<region>.instances.azureml.cn : utilisé uniquement par la commande az ml compute connect-ssh pour se connecter aux calculs dans un réseau virtuel managé. Non nécessaire si vous n’utilisez pas de réseau managé ou de connexions SSH.

  • <managed online endpoint name>.<region>.inference.ml.azure.cn - Utilisé par les points de terminaison en ligne managés

Conseil

Si vous utilisez un hub et des espaces de travail de projet, chaque espace de travail de projet possède son propre ensemble de FQDNs supplémentaires. Pour plus d’informations, consultez la section Résolution d’espace de travail DNS.

Azure US Government

Les noms de domaine complets suivants sont destinés aux régions 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

    Notes

    Le nom de l’espace de travail pour ce nom de domaine complet peut être tronqué. Cette troncation a pour but de limiter la longueur de ml-<workspace-name, truncated>-<region>-<workspace-guid> à 63 caractères.

  • <instance-name>.<region>.instances.azureml.us

    • L’adresse IP de ce nom de domaine complet n’est pas l’adresse IP de l’instance de calcul. Utilisez plutôt l’adresse IP privée du point de terminaison privé de l’espace de travail (l’adresse IP des entrées *.api.azureml.ms).

  • <instance-name>-22.<region>.instances.azureml.us : utilisé uniquement par la commande az ml compute connect-ssh pour se connecter aux calculs dans un réseau virtuel managé. Non nécessaire si vous n’utilisez pas de réseau managé ou de connexions SSH.

  • <managed online endpoint name>.<region>.inference.ml.azure.us - Utilisé par les points de terminaison en ligne managés

Conseil

Si vous utilisez un hub et des espaces de travail de projet, chaque espace de travail de projet possède son propre ensemble de FQDNs supplémentaires. Pour plus d’informations, consultez la section Résolution d’espace de travail DNS.

Rechercher les adresses IP

Pour rechercher les adresses IP internes des noms de domaine complets dans le réseau virtuel, utilisez l’une des méthodes suivantes :

Notes

Les noms de domaine complets et les adresses IP seront différents en fonction de votre configuration. Par exemple, la valeur GUID dans le nom de domaine sera spécifique à votre espace de travail.

  1. Pour connaître l’ID de l’interface réseau du point de terminaison privé, utilisez la commande suivante :

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

  2. Pour récupérer les informations sur l’adresse IP et le nom de domaine complet pour l’espace de travail ou l’espace de travail hub, utilisez la commande suivante. Remplacez <resource-id> par l’ID obtenu à l’étape précédente :

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

    Le résultat ressemble au texte suivant :

    [
    {
        "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"
    }
]

  3. Si vous utilisez un espace de travail hub, utilisez les étapes suivantes pour chaque espace de travail de projet qui a été créé à partir du hub :

    1. Pour obtenir l'identifiant de l'espace de travail du projet, utilisez la commande suivante :

      az ml workspace show --name <project-workspace-name> --resource-group <resource-group> --query 'discovery_url'

      La valeur retournée suit le format 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. Prenez les noms de domaine complets retournés à partir de l’espace de travail hub qui se terminent par workspace.<region>.api.azureml.ms et workspace.<region>.cert.api.azureml.ms. Remplacez la valeur GUID au début de ces FQDN par l'identifiant de l'espace de travail du projet. Ces FQDN s'ajoutent aux FQDN de l'espace de travail du hub.

    3. Prenez les noms de domaine complets retournés à partir de l’espace de travail hub qui suit le format dans <workspace-name>-<region>-<GUID>.<region>.notebooks.azure.net. Remplacez la valeur GUID par l'identifiant de l'espace de travail du projet. Remplacer le nom de l'espace de travail du hub par le nom de l'espace de travail du projet. Il peut être nécessaire de tronquer le nom de l'espace de travail pour que cette entrée ne dépasse pas 63 caractères. Ce FQDN s'ajoute au FQDN de l'espace de travail du concentrateur.

Les informations retournées par toutes les méthodes sont les mêmes : une liste du nom de domaine complet et de l’adresse IP privée pour les ressources. Le tableau suivant montre des exemples d’IP à partir du cloud public Azure :

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

Le tableau suivant montre des exemples d’adresses IP à partir de régions Microsoft Azure géré par 21Vianet :

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

Le tableau suivant montre des exemples d’IP à partir de régions Azure US Government :

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

Notes

Les points de terminaison en ligne managés partagent le point de terminaison privé de l’espace de travail. Si vous ajoutez manuellement des enregistrements DNS à la zone DNS privée privatelink.api.azureml.ms, un enregistrement A contenant un caractère générique *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms doit être ajouté pour acheminer tous les points de terminaison de l’espace de travail vers le point de terminaison privé.

Créer des enregistrements A dans un serveur DNS personnalisé

Après avoir récupéré la liste des FQDN et adresses IP correspondantes, commencez à créer des enregistrements A dans le serveur DNS configuré. Reportez-vous à la documentation de votre serveur DNS pour savoir comment créer des enregistrements A. Notez qu’il est recommandé de créer une seule zone pour l’intégralité du FQDN et de créer l’enregistrement A à la racine de la zone.

Exemple : Serveur DNS personnalisé hébergé dans un réseau virtuel

Cette architecture utilise la topologie de réseau virtuel courante hub-and-spoke. Un réseau virtuel contient le serveur DNS et un autre contient le point de terminaison privé vers l’espace de travail Azure Machine Learning et les ressources associées. Une route valide doit exister entre les deux réseaux virtuels, par exemple, par le biais d’une série de réseaux virtuels appairés.

Diagramme d’un DNS personnalisé hébergé dans une topologie Azure

Les étapes suivantes décrivent le fonctionnement de cette topologie :

  1. Créer une zone DNS privée et la lier au réseau virtuel du serveur DNS :

    Pour garantir le bon fonctionnement d’une solution DNS personnalisée avec votre espace de travail Azure Machine Learning, la première étape consiste à créer deux zones DNS privées avec, pour racine, les domaines suivants :

    Régions publiques Azure :

    • privatelink.api.azureml.ms
    • privatelink.notebooks.azure.net

    Microsoft Azure géré par 21Vianet :

    • privatelink.api.ml.azure.cn
    • privatelink.notebooks.chinacloudapi.cn

    Régions Azure US Government :

    • privatelink.api.ml.azure.us
    • privatelink.notebooks.usgovcloudapi.net

    Notes

    Les points de terminaison en ligne managés partagent le point de terminaison privé de l’espace de travail. Si vous ajoutez manuellement des enregistrements DNS à la zone DNS privée privatelink.api.azureml.ms, un enregistrement A contenant un caractère générique *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms doit être ajouté pour acheminer tous les points de terminaison de l’espace de travail vers le point de terminaison privé.

    Après sa création, la zone DNS privée doit être liée au réseau virtuel du serveur DNS (le réseau virtuel qui contient le serveur DNS).

    Une zone DNS privée remplace la résolution de noms pour tous les noms dans l’étendue de la racine de la zone. Ce remplacement s’applique à tous les réseaux virtuels auxquels la zone DNS privée est liée. Par exemple, si une zone DNS privée avec privatelink.api.azureml.ms pour racine est liée au réseau virtuel foo, toutes les ressources du réseau virtuel foo qui tentent de résoudre bar.workspace.westus2.privatelink.api.azureml.ms recevront un enregistrement listé dans la zone privatelink.api.azureml.ms.

    Toutefois, les enregistrements listés dans les zones DNS privées sont retournés uniquement aux appareils qui résolvent les domaines en utilisant l’adresse IP par défaut du serveur virtuel Azure DNS. Le serveur DNS personnalisé va donc résoudre les domaines pour tous les appareils présents dans votre topologie réseau. Cependant, le serveur DNS personnalisé devra résoudre les domaines liés à Azure Machine Learning par rapport à l’adresse IP du serveur virtuel Azure DNS.

  2. Créer un point de terminaison privé avec intégration au DNS privé, ciblant la zone DNS privée liée au réseau virtuel du serveur DNS :

    L’étape suivante consiste à créer un point de terminaison privé vers l’espace de travail Azure Machine Learning. Le point de terminaison privé cible les deux zones DNS privées créées à l’étape 1. Ceci garantit que toutes les communications avec l’espace de travail sont effectuées par le biais du point de terminaison privé dans le réseau virtuel Azure Machine Learning.

    Important

    Le point de terminaison privé doit avoir l’intégration à un DNS privé activée pour que cet exemple fonctionne correctement.

  3. Créer un redirecteur conditionnel dans le serveur DNS pour la redirection vers Azure DNS :

    Vous allez à présent créer un redirecteur conditionnel vers le serveur virtuel Azure DNS. Le redirecteur conditionnel garantit que le serveur DNS interroge toujours l’adresse IP du serveur virtuel Azure DNS pour obtenir les FQDN associés à votre espace de travail. Cela signifie que le serveur DNS retourne l’enregistrement correspondant à partir de la zone DNS privée.

    Les zones concernées par la redirection conditionnelle sont listées ci-dessous. L’adresse IP du serveur virtuel Azure DNS est 168.63.129.16 :

    Régions publiques Azure :

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • aznbcontent.net
    • inference.ml.azure.com - Utilisé par les points de terminaison en ligne managés

    Microsoft Azure géré par 21Vianet :

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • aznbcontent.net
    • inference.ml.azure.cn - Utilisé par les points de terminaison en ligne managés

    Régions Azure US Government :

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • aznbcontent.net
    • inference.ml.azure.us - Utilisé par les points de terminaison en ligne managés

    Important

    Les étapes de configuration du serveur DNS ne sont pas abordées ici, car de nombreuses solutions DNS peuvent être utilisées comme serveur DNS personnalisé. Reportez-vous à la documentation de votre solution DNS pour savoir comment configurer correctement la redirection conditionnelle.

  4. Résoudre le domaine de l’espace de travail :

    La configuration est à présent effectuée. Désormais, tout client utilisant le serveur DNS pour la résolution de noms et disposant d’une route vers le point de terminaison privé Azure Machine Learning peut accéder à l’espace de travail. Le client commence par interroger le serveur DNS pour obtenir l’adresse des FQDN suivants :

    Régions publiques 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 - Utilisé par les points de terminaison en ligne managés

    Microsoft Azure géré par 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 - Utilisé par les points de terminaison en ligne managés

    Régions 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 - Utilisé par les points de terminaison en ligne managés

  5. Azure DNS résout de manière récursive le domaine de l’espace de travail en CNAME :

    Le serveur DNS résout les FQDN de l’étape 4 à partir d’Azure DNS. Azure DNS répond avec l’un des domaines listés à l’étape 1.

  6. Le serveur DNS résout de manière récursive l’enregistrement CNAME du domaine de l’espace de travail à partir d’Azure DNS :

    Le serveur DNS procède à la résolution du CNAME reçu à l’étape 5 de manière récursive. Comme un redirecteur conditionnel a été configuré à l’étape 3, le serveur DNS envoie la requête à l’adresse IP du serveur virtuel Azure DNS pour la résolution.

  7. Azure DNS retourne les enregistrements de la zone DNS privée :

    Les enregistrements correspondants stockés dans les zones DNS privées sont retournés au serveur DNS, ce qui signifie que le serveur virtuel Azure DNS retourne les adresses IP du point de terminaison privé.

  8. Le serveur DNS personnalisé résout le nom de domaine de l’espace de travail en adresse du point de terminaison privé :

    Le serveur DNS personnalisé retourne à présent les adresses IP du point de terminaison privé au client de l’étape 4. Ceci garantit que tout le trafic vers l’espace de travail Azure Machine Learning s’effectue par le biais du point de terminaison privé.

Résolution des problèmes

Si vous ne pouvez pas accéder à l’espace de travail à partir d’une machine virtuelle ou si des travaux échouent sur des ressources de calcul dans le réseau virtuel, effectuez les étapes suivantes pour en identifier la cause :

  1. Localiser les FQDN de l’espace de travail sur le point de terminaison privé :

    Accédez au portail Azure avec l’un des liens suivants :

    Accédez au point de terminaison privé vers l’espace de travail Azure Machine Learning. Les FQDN de l’espace de travail sont listés sous l’onglet « vue d’ensemble ».

  2. Accéder à la ressource de calcul dans la topologie de réseau virtuel :

    Accédez à une ressource de calcul dans la topologie de réseau virtuel Azure. Ceci nécessitera probablement l’accès à une machine virtuelle dans un réseau virtuel appairé au réseau virtuel hub.

  3. Résoudre les FQDN de l’espace de travail :

    Ouvrez une invite de commandes, l’interpréteur de commandes ou PowerShell. Ensuite, pour chacun des FQDN de l’espace de travail, exécutez la commande suivante :

    nslookup <workspace FQDN>

    Chaque commande nslookup doit retourner l’une des deux adresses IP privées sur le point de terminaison privé vers l’espace de travail Azure Machine Learning. Si ce n’est pas le cas, cela signifie que la solution DNS personnalisée est configurée de façon incorrecte.

    Causes possibles :

    • La ressource de calcul qui exécute les commandes de résolution des problèmes n’utilise pas le serveur DNS pour la résolution DNS.
    • Les zones DNS privées choisies à la création du point de terminaison privé ne sont pas liées au réseau virtuel du serveur DNS.
    • Les redirecteurs conditionnels vers l’IP du serveur virtuel Azure DNS n’ont pas été configurés correctement.

Exemple : Serveur DNS personnalisé hébergé localement

Cette architecture utilise la topologie de réseau virtuel courante hub-and-spoke. ExpressRoute est utilisé pour la connexion à partir de votre réseau local au réseau virtuel hub. Le serveur DNS personnalisé est hébergé localement. Un réseau virtuel distinct contient le point de terminaison privé vers l’espace de travail Azure Machine Learning et les ressources associées. Cette topologie implique la présence d’un autre réseau virtuel hébergeant un serveur DNS qui peut envoyer des requêtes à l’adresse IP du serveur virtuel Azure DNS.

Diagramme de la topologie avec DNS personnalisé hébergé localement

Les étapes suivantes décrivent le fonctionnement de cette topologie :

  1. Créer une zone DNS privée et la lier au réseau virtuel du serveur DNS :

    Pour garantir le bon fonctionnement d’une solution DNS personnalisée avec votre espace de travail Azure Machine Learning, la première étape consiste à créer deux zones DNS privées avec, pour racine, les domaines suivants :

    Régions publiques Azure :

    • privatelink.api.azureml.ms
    • privatelink.notebooks.azure.net

    Microsoft Azure géré par 21Vianet :

    • privatelink.api.ml.azure.cn
    • privatelink.notebooks.chinacloudapi.cn

    Régions Azure US Government :

    • privatelink.api.ml.azure.us
    • privatelink.notebooks.usgovcloudapi.net

    Notes

    Les points de terminaison en ligne managés partagent le point de terminaison privé de l’espace de travail. Si vous ajoutez manuellement des enregistrements DNS à la zone DNS privée privatelink.api.azureml.ms, un enregistrement A contenant un caractère générique *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms doit être ajouté pour acheminer tous les points de terminaison de l’espace de travail vers le point de terminaison privé.

    Après sa création, la zone DNS privée doit être liée au réseau virtuel du serveur DNS (le réseau virtuel qui contient le serveur DNS).

    Notes

    Le serveur DNS dans le réseau virtuel est séparé du serveur DNS local.

    Une zone DNS privée remplace la résolution de noms pour tous les noms dans l’étendue de la racine de la zone. Ce remplacement s’applique à tous les réseaux virtuels auxquels la zone DNS privée est liée. Par exemple, si une zone DNS privée avec privatelink.api.azureml.ms pour racine est liée au réseau virtuel foo, toutes les ressources du réseau virtuel foo qui tentent de résoudre bar.workspace.westus2.privatelink.api.azureml.ms recevront un enregistrement listé dans la zone privatelink.api.azureml.m.

    Toutefois, les enregistrements listés dans les zones DNS privées sont retournés uniquement aux appareils qui résolvent les domaines en utilisant l’adresse IP par défaut du serveur virtuel Azure DNS. L’adresse IP du serveur virtuel Azure DNS est valide uniquement dans le contexte d’un réseau virtuel. Quand un serveur DNS local est utilisé, il ne peut pas interroger l’adresse IP du serveur virtuel Azure DNS pour récupérer les enregistrements.

    Pour contourner ce problème, créez un serveur DNS intermédiaire dans un réseau virtuel. Ce serveur DNS peut interroger l’adresse IP du serveur virtuel Azure DNS pour récupérer les enregistrements de n’importe quelle zone DNS privée liée au réseau virtuel.

    Même si le serveur DNS local résout les domaines pour tous les appareils présents dans votre topologie réseau, il résout les domaines liés à Azure Machine Learning par rapport au serveur DNS. Le serveur DNS résout ces domaines à partir de l’adresse IP du serveur virtuel Azure DNS.

  2. Créer un point de terminaison privé avec intégration au DNS privé, ciblant la zone DNS privée liée au réseau virtuel du serveur DNS :

    L’étape suivante consiste à créer un point de terminaison privé vers l’espace de travail Azure Machine Learning. Le point de terminaison privé cible les deux zones DNS privées créées à l’étape 1. Ceci garantit que toutes les communications avec l’espace de travail sont effectuées par le biais du point de terminaison privé dans le réseau virtuel Azure Machine Learning.

    Important

    Le point de terminaison privé doit avoir l’intégration à un DNS privé activée pour que cet exemple fonctionne correctement.

  3. Créer un redirecteur conditionnel dans le serveur DNS pour la redirection vers Azure DNS :

    Vous allez à présent créer un redirecteur conditionnel vers le serveur virtuel Azure DNS. Le redirecteur conditionnel garantit que le serveur DNS interroge toujours l’adresse IP du serveur virtuel Azure DNS pour obtenir les FQDN associés à votre espace de travail. Cela signifie que le serveur DNS retourne l’enregistrement correspondant à partir de la zone DNS privée.

    Les zones concernées par la redirection conditionnelle sont listées ci-dessous. L’adresse IP du serveur virtuel Azure DNS est 168.63.129.16.

    Régions publiques Azure :

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • aznbcontent.net
    • inference.ml.azure.com - Utilisé par les points de terminaison en ligne managés

    Microsoft Azure géré par 21Vianet :

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • aznbcontent.net
    • inference.ml.azure.cn - Utilisé par les points de terminaison en ligne managés

    Régions Azure US Government :

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • aznbcontent.net
    • inference.ml.azure.us - Utilisé par les points de terminaison en ligne managés

    Important

    Les étapes de configuration du serveur DNS ne sont pas abordées ici, car de nombreuses solutions DNS peuvent être utilisées comme serveur DNS personnalisé. Reportez-vous à la documentation de votre solution DNS pour savoir comment configurer correctement la redirection conditionnelle.

  4. Créer un redirecteur conditionnel dans le serveur DNS local pour la redirection vers le serveur DNS :

    Vous allez à présent créer un redirecteur conditionnel vers le serveur DNS dans le réseau virtuel du serveur DNS. Ce redirecteur concerne les zones listées à l’étape 1. Ceci s’apparente à l’étape 3. Cependant, au lieu d’effectuer la redirection vers l’adresse IP du serveur virtuel Azure DNS, le serveur DNS local ciblera l’adresse IP du serveur DNS. Étant donné que le serveur DNS local n’est pas dans Azure, il n’est pas en mesure de résoudre directement les enregistrements en zones DNS privées. Dans le cas présent, le serveur DNS redirige les requêtes du serveur DNS local vers l’IP du serveur virtuel Azure DNS. Ceci permet au serveur DNS local de récupérer les enregistrements dans les zones DNS privées liées au réseau virtuel du serveur DNS.

    Les zones concernées par la redirection conditionnelle sont listées ci-dessous. Les adresses IP vers lesquelles la redirection doit être effectuée sont celles de vos serveurs DNS :

    Régions publiques Azure :

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • inference.ml.azure.com - Utilisé par les points de terminaison en ligne managés

    Microsoft Azure géré par 21Vianet :

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • inference.ml.azure.cn - Utilisé par les points de terminaison en ligne managés

    Régions Azure US Government :

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • inference.ml.azure.us - Utilisé par les points de terminaison en ligne managés

    Important

    Les étapes de configuration du serveur DNS ne sont pas abordées ici, car de nombreuses solutions DNS peuvent être utilisées comme serveur DNS personnalisé. Reportez-vous à la documentation de votre solution DNS pour savoir comment configurer correctement la redirection conditionnelle.

  5. Résoudre le domaine de l’espace de travail :

    La configuration est à présent effectuée. Tout client utilisant le serveur DNS local pour la résolution de noms et disposant d’une route vers le point de terminaison privé Azure Machine Learning peut accéder à l’espace de travail.

    Le client commence par interroger le serveur DNS local pour obtenir l’adresse des FQDN suivants :

    Régions publiques 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 - Utilisé par les points de terminaison en ligne managés

    Microsoft Azure géré par 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 - Utilisé par les points de terminaison en ligne managés

    Régions 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 - Utilisé par les points de terminaison en ligne managés

  6. Le serveur DNS local résout de manière récursive le domaine de l’espace de travail :

    Le serveur DNS local résout les noms de domaine complets de l’étape 5 à partir du serveur DNS. En raison de l’existence d’un redirecteur conditionnel (étape 4), le serveur DNS local envoie la demande au serveur DNS pour la résolution.

  7. Le serveur DNS résout le domaine de l’espace de travail en CNAME à partir d’Azure DNS :

    Le serveur DNS résout les FQDN de l’étape 5 à partir d’Azure DNS. Azure DNS répond avec l’un des domaines listés à l’étape 1.

  8. Le serveur DNS local résout de manière récursive l’enregistrement CNAME du domaine de l’espace de travail à partir du serveur DNS :

    Le serveur DNS local procède à la résolution du CNAME reçu à l’étape 7 de manière récursive. Comme un redirecteur conditionnel a été configuré à l’étape 4, le serveur DNS local envoie la requête au serveur DNS pour la résolution.

  9. Le serveur DNS résout de manière récursive l’enregistrement CNAME du domaine de l’espace de travail à partir d’Azure DNS :

    Le serveur DNS procède à la résolution du CNAME reçu à l’étape 7 de manière récursive. Comme un redirecteur conditionnel a été configuré à l’étape 3, le serveur DNS envoie la requête à l’adresse IP du serveur virtuel Azure DNS pour la résolution.

  10. Azure DNS retourne les enregistrements de la zone DNS privée :

    Les enregistrements correspondants stockés dans les zones DNS privées sont retournés au serveur DNS, ce qui signifie que le serveur virtuel Azure DNS retourne les adresses IP du point de terminaison privé.

  11. Le serveur DNS local résout le nom de domaine de l’espace de travail en adresse du point de terminaison privé :

    La requête du serveur DNS local au serveur DNS effectuée à l’étape 8 retourne finalement les adresses IP associées au point de terminaison privé vers l’espace de travail Azure Machine Learning. Ces adresses IP sont retournées au client d’origine, qui communique désormais avec l’espace de travail Azure Machine Learning sur le point de terminaison privé configuré à l’étape 1.

    Important

    Si la passerelle VPN est utilisée dans cette configuration avec des adresses IP personnalisées du serveur DNS sur le réseau virtuel, l’adresse IP AZURE DNS (168.63.129.16) doit également être ajoutée à la liste pour garder une communication non interrompue.

Exemple : fichier hosts

Le fichier hosts est un document texte que Linux, macOS et Windows utilisent tous pour remplacer la résolution de noms pour l’ordinateur local. Le fichier contient une liste d’adresses IP et le nom d’hôte correspondant. Quand l’ordinateur local tente de résoudre un nom d’hôte, si ce dernier est listé dans le fichier hosts, le nom est résolu en l’adresse IP correspondante.

Important

Le fichier hosts remplace uniquement la résolution de noms pour l’ordinateur local. Si vous souhaitez utiliser un fichier hosts avec plusieurs ordinateurs, vous devez le modifier individuellement sur chaque ordinateur.

Le tableau suivant liste l’emplacement du fichier hosts :

Système d’exploitation Emplacement
Linux /etc/hosts
macOS /etc/hosts
Windows %SystemRoot%\System32\drivers\etc\hosts

Conseil

Le nom du fichier est hosts sans extension. Quand vous modifiez le fichier, utilisez un accès administrateur. Par exemple, sur Linux ou macOS, vous pouvez utiliser sudo vi. Sur Windows, exécutez le Bloc-notes en tant qu’administrateur.

Voici un exemple d’entrées de fichier hosts pour 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

Pour plus d’informations sur le fichier hosts, consultez https://wikipedia.org/wiki/Hosts_(file).

Résolution DNS des services de dépendance

Les services sur lesquels repose votre espace de travail peuvent également être sécurisés à l’aide d’un point de terminaison privé. Dans ce cas, vous devrez peut-être créer un enregistrement DNS personnalisé si vous avez besoin de communiquer directement avec le service. Par exemple, si vous souhaitez utiliser directement les données dans un compte Stockage Azure utilisé par votre espace de travail.

Notes

Certains services disposent de plusieurs points de terminaison privés pour des sous-services ou des fonctionnalités. Par exemple, un compte de stockage Azure peut avoir des points de terminaison privés individuels pour les blobs, les fichiers et DFS. Si vous avez besoin d’accéder à la fois au stockage de blobs et de fichiers, vous devez activer la résolution pour chaque point de terminaison privé spécifique.

Pour plus d’informations sur les services et la résolution DNS, consultez Configuration DNS des points de terminaison privés Azure.

Résolution des problèmes

Si, après avoir effectué les étapes ci-dessus, vous ne parvenez pas à accéder à l’espace de travail à partir d’une machine virtuelle ou si des travaux échouent sur des ressources de calcul dans le réseau virtuel contenant le point de terminaison privé vers l’espace de travail Azure Machine Learning, effectuez les étapes suivantes pour essayer d’en identifier la cause.

  1. Localiser les FQDN de l’espace de travail sur le point de terminaison privé :

    Accédez au portail Azure avec l’un des liens suivants :

    Accédez au point de terminaison privé vers l’espace de travail Azure Machine Learning. Les FQDN de l’espace de travail sont listés sous l’onglet « vue d’ensemble ».

  2. Accéder à la ressource de calcul dans la topologie de réseau virtuel :

    Accédez à une ressource de calcul dans la topologie de réseau virtuel Azure. Ceci nécessitera probablement l’accès à une machine virtuelle dans un réseau virtuel appairé au réseau virtuel hub.

  3. Résoudre les FQDN de l’espace de travail :

    Ouvrez une invite de commandes, l’interpréteur de commandes ou PowerShell. Ensuite, pour chacun des FQDN de l’espace de travail, exécutez la commande suivante :

    nslookup <workspace FQDN>

    Chaque commande nslookup doit retourner l’une des deux adresses IP privées sur le point de terminaison privé vers l’espace de travail Azure Machine Learning. Si ce n’est pas le cas, cela signifie que la solution DNS personnalisée est configurée de façon incorrecte.

    Causes possibles :

    • La ressource de calcul qui exécute les commandes de résolution des problèmes n’utilise pas le serveur DNS pour la résolution DNS.
    • Les zones DNS privées choisies à la création du point de terminaison privé ne sont pas liées au réseau virtuel du serveur DNS.
    • Les redirecteurs conditionnels du serveur DNS vers l’IP du serveur virtuel Azure DNS n’ont pas été configurés correctement.
    • Les redirecteurs conditionnels du serveur DNS local vers le serveur DNS n’ont pas été configurés correctement.

Contenu connexe

Pour plus d’informations sur l’intégration des points de terminaison privés dans votre configuration DNS, consultez Configuration DNS du point de terminaison privé Azure.