Freigeben über

Verwenden Ihres Arbeitsbereichs mit einem benutzerdefinierten DNS-Server

  • Artikel

Wenn Sie einen Azure Machine Learning-Arbeitsbereich (einschließlich Azure KI-Hubs) mit einem privaten Endpunkt verwenden, gibt es verschiedene Möglichkeiten, die DNS-Namensauflösung zu verarbeiten. Standardmäßig übernimmt Azure automatisch die Namensauflösung für Ihren Arbeitsbereich und Ihren privaten Endpunkt. Wenn Sie stattdessen Ihren eigenen benutzerdefinierten DNS-Server verwenden, müssen Sie DNS-Einträge für den Arbeitsbereich manuell erstellen oder bedingte Weiterleitungen verwenden.

Wichtig

In diesem Artikel wird beschrieben, wie Sie die vollqualifizierten Domänennamen (Fully Qualified Domain Namas, FQDN) und IP-Adressen für diese Einträge finden, wenn Sie DNS-Einträge manuell in Ihrer DNS-Lösung registrieren möchten. Darüber hinaus enthält dieser Artikel Architekturempfehlungen zum Konfigurieren Ihrer benutzerdefinierten DNS-Lösung, um FQDNs automatisch in die richtigen IP-Adressen aufzulösen. Dieser Artikel enthält KEINE Informationen zum Konfigurieren der DNS-Einträge für diese Elemente. Weitere Informationen zum Hinzufügen von Einträgen finden Sie in der Dokumentation zu Ihrer DNS-Software.

Voraussetzungen

Automatisierte DNS-Serverintegration

Einführung

Es gibt zwei gängige Architekturen für die Verwendung der automatisierten DNS-Serverintegration mit Azure Machine Learning:

Ihre Architektur kann sich zwar von diesen Beispielen unterscheiden, Sie können sie jedoch als Bezugspunkt verwenden. Beide Beispielarchitekturen bieten Schritte zur Problembehandlung, mit denen Sie Komponenten identifizieren können, die möglicherweise falsch konfiguriert sind.

Eine weitere Möglichkeit besteht in der Änderung der hosts-Datei auf dem Client, der eine Verbindung mit dem Azure Virtual Network (VNet) herstellt, das Ihren Arbeitsbereich enthält. Weitere Informationen finden Sie im Abschnitt Hostdatei.

DNS-Auflösungspfad des Arbeitsbereichs

Der Zugriff auf einen bestimmten Azure Machine Learning-Arbeitsbereich über Private Link erfolgt durch die Kommunikation mit den folgenden vollqualifizierten Domänen (als Arbeitsbereichs-FQDNs bezeichnet), die unten aufgeführt sind:

Wichtig

Wenn Sie einen Hubarbeitsbereich (einschließlich Azure KI Studio-Hub) verwenden, werden Sie über zusätzliche Einträge für jeden Projektarbeitsbereich verfügen, der über den Hub erstellt wurde.

öffentliche Azure-Regionen:

  • <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: Wird vom Befehl az ml compute connect-ssh verwendet, um eine Verbindung mit Computeressourcen in einem verwalteten virtuellen Netzwerk herzustellen.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
  • <managed online endpoint name>.<region>.inference.ml.azure.com: Wird von verwalteten Onlineendpunkten verwendet.

Tipp

Wenn Sie einen Hubarbeitsbereich verwenden, gibt es auch die folgenden FQDNs für jeden Projektarbeitsbereich, der aus dem Hubarbeitsbereich erstellt wurde:

  • <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

Regionen vom Typ „Microsoft Azure, betrieben von 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: Wird vom Befehl az ml compute connect-ssh verwendet, um eine Verbindung mit Computeressourcen in einem verwalteten virtuellen Netzwerk herzustellen.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
  • <managed online endpoint name>.<region>.inference.ml.azure.cn: Wird von verwalteten Onlineendpunkten verwendet.

Tipp

Wenn Sie einen Hubarbeitsbereich verwenden, gibt es auch die folgenden FQDNs für jeden Projektarbeitsbereich, der aus dem Hubarbeitsbereich erstellt wurde:

  • <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-Regionen:

  • <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: Wird vom Befehl az ml compute connect-ssh verwendet, um eine Verbindung mit Computeressourcen in einem verwalteten virtuellen Netzwerk herzustellen.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
  • <managed online endpoint name>.<region>.inference.ml.azure.us: Wird von verwalteten Onlineendpunkten verwendet.

Tipp

Wenn Sie einen Hubarbeitsbereich verwenden, gibt es auch die folgenden FQDNs für jeden Projektarbeitsbereich, der aus dem Hubarbeitsbereich erstellt wurde:

  • <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

Die vollqualifizierten Domänen werden in die folgenden kanonischen Namen (Canonical Names, CNAMEs) namens Arbeitsbereich Private Link FQDNs aufgelöst:

öffentliche Azure-Regionen:

  • <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: Wird von verwalteten Onlineendpunkten verwendet.

Regionen vom Typ „Azure, betrieben von 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: Wird von verwalteten Onlineendpunkten verwendet.

Azure US Government-Regionen:

  • <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: Wird von verwalteten Onlineendpunkten verwendet.

Die FQDNs werden in die IP-Adressen des Azure Machine Learning-Arbeitsbereichs in dieser Region auflösen. Die Auflösung der FQDNs des Arbeitsbereichs „Private Link“ kann jedoch mithilfe eines benutzerdefinierten DNS-Servers, der im virtuellen Netzwerk gehostet wird, außer Kraft gesetzt werden. Ein Beispiel für diese Architektur finden Sie in dem Beispiel für den benutzerdefinierten DNS-Server, der in einem VNet gehostet wird. Für Hub- und Projektarbeitsbereiche werden die FQDNs aller Projektarbeitsbereiche in die IP-Adresse des Hubarbeitsbereichs aufgelöst.

Hinweis

Verwaltete Onlineendpunkte nutzen den privaten Endpunkt des Arbeitsbereichs gemeinsam. Wenn Sie DNS-Einträge manuell zur privaten DNS-Zone privatelink.api.azureml.ms hinzufügen, sollte ein A-Eintrag mit dem Platzhalter *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms hinzugefügt werden, um alle Endpunkte des Arbeitsbereichs an den privaten Endpunkt weiterzuleiten.

Manuelle DNS-Serverintegration

In diesem Abschnitt wird erläutert, für welche vollqualifizierten Domänen A-Einträge auf einem DNS-Server erstellt werden und auf welche IP-Adresse der Wert des A-Eintrags festgelegt werden soll.

Abrufen von FQDNs für private Endpunkte

Öffentliche Azure-Region

Die folgende Liste enthält den FQDN (vollqualifizierter Domänenname), der von Ihrem Arbeitsbereich verwendet wird, wenn dieser sich in einer Azure Public Cloud befindet:

  • <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

    Hinweis

    Der Arbeitsbereichsname für diesen FQDN wird unter Umständen abgeschnitten. Hierdurch wird das Limit von 63 Zeichen oder weniger für ml-<workspace-name, truncated>-<region>-<workspace-guid> eingehalten.

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

    Hinweis

    • Auf Compute-Instanzen kann nur innerhalb des virtuellen Netzwerks zugegriffen werden.
    • Die IP-Adresse für diesen vollqualifizierten Domänennamen ist nicht die IP-Adresse der Compute-Instanz. Verwenden Sie stattdessen die private IP-Adresse des privaten Arbeitsbereichsendpunkts (die IP-Adresse der *.api.azureml.ms-Einträge).

  • <instance-name>-22.<region>.instances.azureml.ms: Wird nur vom Befehl az ml compute connect-ssh verwendet, um eine Verbindung mit Computeressourcen in einem verwalteten virtuellen Netzwerk herzustellen. Nicht erforderlich, wenn Sie kein verwaltetes Netzwerk oder SSH-Verbindungen verwenden.

  • <managed online endpoint name>.<region>.inference.ml.azure.com: Wird von verwalteten Onlineendpunkten verwendet.

Tipp

Wenn Sie Hub- und Projektarbeitsbereiche verwenden, verfügt jeder Projektarbeitsbereich über seinen eigenen Satz zusätzlicher FQDNs. Weitere Informationen finden Sie im Abschnitt zur DNS-Auflösung des Arbeitsbereichs.

Region vom Typ „Microsoft Azure, betrieben von 21Vianet“

Die folgenden FQDNs gelten für Regionen vom Typ „Microsoft Azure, betrieben von 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

    Hinweis

    Der Arbeitsbereichsname für diesen FQDN wird unter Umständen abgeschnitten. Hierdurch wird das Limit von 63 Zeichen oder weniger für ml-<workspace-name, truncated>-<region>-<workspace-guid> eingehalten.

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

    • Die IP-Adresse für diesen vollqualifizierten Domänennamen ist nicht die IP-Adresse der Compute-Instanz. Verwenden Sie stattdessen die private IP-Adresse des privaten Arbeitsbereichsendpunkts (die IP-Adresse der *.api.azureml.ms-Einträge).

  • <instance-name>-22.<region>.instances.azureml.cn: Wird nur vom Befehl az ml compute connect-ssh verwendet, um eine Verbindung mit Computeressourcen in einem verwalteten virtuellen Netzwerk herzustellen. Nicht erforderlich, wenn Sie kein verwaltetes Netzwerk oder SSH-Verbindungen verwenden.

  • <managed online endpoint name>.<region>.inference.ml.azure.cn: Wird von verwalteten Onlineendpunkten verwendet.

Tipp

Wenn Sie Hub- und Projektarbeitsbereiche verwenden, verfügt jeder Projektarbeitsbereich über seinen eigenen Satz zusätzlicher FQDNs. Weitere Informationen finden Sie im Abschnitt zur DNS-Auflösung des Arbeitsbereichs.

Azure US Government

Die folgenden FQDNs gelten für Azure US Government-Regionen:

  • <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

    Hinweis

    Der Arbeitsbereichsname für diesen FQDN wird unter Umständen abgeschnitten. Hierdurch wird das Limit von 63 Zeichen oder weniger für ml-<workspace-name, truncated>-<region>-<workspace-guid> eingehalten.

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

    • Die IP-Adresse für diesen vollqualifizierten Domänennamen ist nicht die IP-Adresse der Compute-Instanz. Verwenden Sie stattdessen die private IP-Adresse des privaten Arbeitsbereichsendpunkts (die IP-Adresse der *.api.azureml.ms-Einträge).

  • <instance-name>-22.<region>.instances.azureml.us: Wird nur vom Befehl az ml compute connect-ssh verwendet, um eine Verbindung mit Computeressourcen in einem verwalteten virtuellen Netzwerk herzustellen. Nicht erforderlich, wenn Sie kein verwaltetes Netzwerk oder SSH-Verbindungen verwenden.

  • <managed online endpoint name>.<region>.inference.ml.azure.us: Wird von verwalteten Onlineendpunkten verwendet.

Tipp

Wenn Sie Hub- und Projektarbeitsbereiche verwenden, verfügt jeder Projektarbeitsbereich über seinen eigenen Satz zusätzlicher FQDNs. Weitere Informationen finden Sie im Abschnitt zur DNS-Auflösung des Arbeitsbereichs.

Suchen der IP-Adressen

Verwenden Sie eine der folgenden Methoden, um die internen IP-Adressen für die FQDNs im VNet zu finden:

Hinweis

Die vollqualifizierten Domänennamen und IP-Adressen variieren je nach Ihrer Konfiguration. Beispielsweise ist der GUID-Wert im Domänennamen spezifisch für Ihren Arbeitsbereich.

  1. Verwenden Sie den folgenden Befehl, um die ID der Netzwerkschnittstelle des privaten Endpunkts zu erhalten:

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

  2. Verwenden Sie den folgenden Befehl, um die IP-Adresse und die FQDN-Informationen für den Arbeitsbereich oder den Hubarbeitsbereich abzurufen. Ersetzen Sie <resource-id> durch die ID aus dem vorherigen Schritt:

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

    Die Ausgabedaten ähneln dem folgenden Text:

    [
    {
        "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. Wenn Sie einen Hubarbeitsbereich verwenden, führen Sie die folgenden Schritte für jeden Projektarbeitsbereich aus, der über den Hub erstellt wurde:

    1. Verwenden Sie den folgenden Befehl, um die Projektarbeitsbereichs-ID abzurufen:

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

      Der zurückgegebene Wert wird dem 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> folgen.

    2. Verwenden Sie die vom Hubarbeitsbereich zurückgegeben FQDNS, die in workspace.<region>.api.azureml.ms und workspace.<region>.cert.api.azureml.ms enden. Ersetzen Sie den GUID-Wert am Anfang dieser FQDNs durch die Projektarbeitsbereichs-ID. Diese FQDNs sind zusätzlich zu den FQDNs des Hubarbeitsbereichs.

    3. Verwenden Sie den vom Hubarbeitsbereich zurückgegebenen FQDN, der dem Format in <workspace-name>-<region>-<GUID>.<region>.notebooks.azure.net folgt. Ersetzen Sie den GUID-Wert durch die Projektarbeitsbereichs-ID. Ersetzen Sie den Namen des Hubarbeitsbereichs durch den Namen des Projektarbeitsbereichs. Möglicherweise müssen Sie den Arbeitsbereichsnamen kürzen, um diesen Eintrag auf 63 Zeichen oder weniger zu beschränken. Dieser FQDN ist zusätzlich zum FQDN des Hubarbeitsbereichs.

Die Informationen, die von allen Methoden zurückgegeben werden, sind dieselben: Eine Liste des FQDN und der privaten IP-Adresse für die Ressourcen. Das folgende Beispiel ist aus der Azure Public Cloud:

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

Die folgende Tabelle enthält Beispiele für IP-Adressen aus Regionen vom Typ „Microsoft Azure, betrieben von 21Vianet“:

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

Die folgende Tabelle enthält Beispiele für IP-Adressen aus Azure US Government-Regionen:

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

Hinweis

Verwaltete Onlineendpunkte nutzen den privaten Endpunkt des Arbeitsbereichs gemeinsam. Wenn Sie DNS-Einträge manuell zur privaten DNS-Zone privatelink.api.azureml.ms hinzufügen, sollte ein A-Eintrag mit dem Platzhalter *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms hinzugefügt werden, um alle Endpunkte des Arbeitsbereichs an den privaten Endpunkt weiterzuleiten.

Erstellen von A-Einträgen auf einem benutzerdefinierten DNS-Server

Nachdem die Liste der FQDNs und entsprechenden IP-Adressen erfasst wurde, fahren Sie mit dem Erstellen von A-Einträgen auf dem konfigurierten DNS-Server fort. Informationen zum Erstellen von A-Einträgen finden Sie in der Dokumentation für Ihren DNS-Server. Beachten Sie, dass empfohlen wird, eine eindeutige Zone für den gesamten FQDN und den A-Eintrag im Stamm der Zone zu erstellen.

Beispiel: Benutzerdefinierter DNS-Server, der im VNET gehostet wird

In dieser Architektur wird die allgemeine Hub-and-Spoke-Topologie des virtuellen Netzwerks verwendet. Das eine virtuelle Netzwerk enthält den DNS-Server und das andere den privaten Endpunkt für den Azure Machine Learning-Arbeitsbereich und die zugehörigen Ressourcen. Zwischen beiden virtuellen Netzwerken muss eine gültige Route vorhanden sein. Beispielsweise über eine Reihe von mittels Peering vernetzten virtuellen Netzwerken.

Diagramm des benutzerdefinierten DNS, das in der Azure-Topologie gehostet wird

Die folgenden Schritte beschreiben, wie diese Topologie funktioniert:

  1. Erstellen Sie eine Private DNS-Zone und verknüpfen Sie sie mit DNS Server Virtual Network:

    Der erste Schritt, um sicherzustellen, dass eine benutzerdefinierte DNS-Lösung mit Ihrem Azure Machine Learning-Arbeitsbereich funktioniert, besteht darin, zwei Private DNS-Zonen zu erstellen, die von den folgenden Domänen entfernt sind:

    öffentliche Azure-Regionen:

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

    Regionen vom Typ „Microsoft Azure, betrieben von 21Vianet“:

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

    Azure US Government-Regionen:

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

    Hinweis

    Verwaltete Onlineendpunkte nutzen den privaten Endpunkt des Arbeitsbereichs gemeinsam. Wenn Sie DNS-Einträge manuell zur privaten DNS-Zone privatelink.api.azureml.ms hinzufügen, sollte ein A-Eintrag mit dem Platzhalter *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms hinzugefügt werden, um alle Endpunkte des Arbeitsbereichs an den privaten Endpunkt weiterzuleiten.

    Nach der Erstellung der Private DNS-Zone muss sie mit der DNS-Server-Virtual Network verknüpft werden. Das virtuelle Netzwerk, das den DNS-Server enthält.

    Eine Private DNS-Zone überschreibt die Namensauflösung für alle Namen innerhalb des Bereichs des Stamms der Zone. Diese Außerkraftsetzung gilt für alle virtuellen Netzwerke, mit der Privaten DNS-Zone verknüpft sind. Wenn z. B. eine Private DNS-Zone mit privatelink.api.azureml.ms-Stamm mit Virtual Network foo verknüpft ist, erhalten alle Ressourcen in Virtual Network foo, die versuchen, bar.workspace.westus2.privatelink.api.azureml.ms aufzulösen, alle in der privatelink.api.azureml.ms -Zone aufgeführten Daten.

    Datensätze, die in Privaten DNS-Zonen aufgeführt sind, werden jedoch nur an Geräte zurückgegeben, die Domänen mithilfe der Standard-Azure DNS IP-Adresse des virtuellen Servers auflösen. Daher löst der benutzerdefinierte DNS-Server Domänen für Geräte auf, die in Ihrer Netzwerktopologie verteilt sind. Der benutzerdefinierte DNS-Server muss jedoch Azure Machine Learning-Domänen mit der IP-Adresse des Azure DNS Virtual Servers auflösen.

  2. Erstellen Sie einen privaten Endpunkt mit privater DNS-Integration für die Private DNS-Zone, die mit DNS Server Virtual Network verbunden ist:

    Im nächsten Schritt erstellen Sie einen privaten Endpunkt für den Azure Machine Learning-Arbeitsbereich. Der private Endpunkt ist für beide Private DNS-Zonen, die in Schritt 1 erstellt wurden. Dadurch wird sichergestellt, dass die gesamte Kommunikation mit dem Arbeitsbereich über den privaten Endpunkt im Azure Machine Learning Virtual Network durchgeführt wird.

    Wichtig

    Für den privaten Endpunkt muss die Integration von „Privates DNS“ aktiviert sein, damit dieses Beispiel ordnungsgemäß funktioniert.

  3. Erstellen Sie eine bedingte Weiterleitungsanweisung auf dem DNS-Server, um sie an Azure DNS weiterzuleiten:

    Erstellen Sie als Nächstes eine bedingte Weiterleitung an den Azure DNS Virtual Server. Die bedingte Weiterleitung stellt sicher, dass der DNS-Server die IP-Adresse Azure DNS virtuellen Servers immer nach FQDNs abfragt, die mit Ihrem Arbeitsbereich verknüpft sind. Dies bedeutet, dass der DNS-Server den entsprechenden Eintrag aus der Private DNS-Zone zurückgibt.

    Die Zonen, die bedingt weitergeleitet werden sollen, sind unten aufgeführt. Die Azure DNS-IP-Adresse des virtuellen Servers lautet 168.63.129.16:

    öffentliche Azure-Regionen:

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • aznbcontent.net
    • inference.ml.azure.com: Wird von verwalteten Onlineendpunkten verwendet.

    Regionen vom Typ „Microsoft Azure, betrieben von 21Vianet“:

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • aznbcontent.net
    • inference.ml.azure.cn: Wird von verwalteten Onlineendpunkten verwendet.

    Azure US Government-Regionen:

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • aznbcontent.net
    • inference.ml.azure.us: Wird von verwalteten Onlineendpunkten verwendet.

    Wichtig

    Konfigurationsschritte für den DNS-Server sind hier nicht enthalten, da viele DNS-Lösungen verfügbar sind, die als benutzerdefinierter DNS-Server verwendet werden können. Informationen zum ordnungsgemäßen Konfigurieren der bedingten Weiterleitung finden Sie in der Dokumentation zu Ihrer DNS-Lösung.

  4. Auflösen der Arbeitsbereichsdomäne:

    An diesem Punkt wird das Setup-Programm durchgeführt. Nun kann jeder Client, der DNS-Server für die Namensauflösung verwendet und über eine Route zum privaten Endpunkt von Azure Machine Learning verfügt mit dem Zugriff auf den Arbeitsbereich fortfahren. Der Client beginnt zunächst mit der Abfrage des DNS-Servers nach der Adresse der folgenden FQDNs:

    öffentliche Azure-Regionen:

    • <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: Wird von verwalteten Onlineendpunkten verwendet.

    Regionen vom Typ „Microsoft Azure, betrieben von 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: Wird von verwalteten Onlineendpunkten verwendet.

    Azure US Government-Regionen:

    • <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: Wird von verwalteten Onlineendpunkten verwendet.

  5. Azure DNS löst die Arbeitsbereichsdomäne rekursiv zu CNAME auf:

    Der DNS-Server wird die FQDNs aus Schritt 4 von Azure DNS auflösen. Azure DNS antwortet mit einer der in Schritt 1 aufgeführten Domänen.

  6. Der DNS-Server löst den CNAME-Eintrag der Arbeitsbereichsdomäne rekursiv aus Azure DNS auf:

    Der DNS-Server löst den in Schritt 5 empfangenen CNAME rekursiv auf. Da in Schritt 3 eine bedingte Weiterleitung eingerichtet wurde, sendet der DNS-Server die Anforderung zur Auflösung an die IP-Adresse des Azure DNS Virtual Servers.

  7. Azure DNS gibt Datensätze aus Private DNS-Zone zurück:

    Die entsprechenden Datensätze, die in den Private DNS-Zonen gespeichert sind, werden an den DNS-Server zurückgegeben. Dies bedeutet, dass Azure DNS Virtueller Server die IP-Adressen des privaten Endpunkts zurückgibt.

  8. Der benutzerdefinierte DNS-Server löst den Domänennamen des Arbeitsbereichs in die Adresse des privaten Endpunkts auf:

    Letztendlich gibt der benutzerdefinierte DNS-Server nun die IP-Adressen des privaten Endpunkts aus Schritt 4 an den Client zurück. Dadurch wird sichergestellt, dass der gesamte Datenverkehr zum Azure Machine Learning-Arbeitsbereich über den privaten Endpunkt erfolgt.

Problembehandlung

Wenn Sie von einem virtuellen Computer aus nicht auf den Arbeitsbereich zugreifen können oder bei Aufträgen für Computeressourcen im virtuellen Netzwerk Fehler verursachen, führen Sie die folgenden Schritte aus, um die Ursache zu ermitteln:

  1. Suchen Sie die Arbeitsbereichs-FQDNs auf dem privaten Endpunkt:

    Navigieren Sie über einen der folgenden Links zum Azure-Portal:

    Navigieren Sie zum privaten Endpunkt zum Azure Machine Learning-Arbeitsbereich. Die FQDNs des Arbeitsbereichs werden auf der Registerkarte „Übersicht“ aufgeführt.

  2. Zugreifen auf Computeressourcen in der Virtual Network-Topologie:

    Fahren Sie mit dem Zugriff auf eine Computeressource in der Azure Virtual Network-Topologie fort. Dies erfordert wahrscheinlich den Zugriff auf einen virtuellen Computer in einem virtuellen Netzwerk, das mit dem Hub Virtual Network mittels Peering verbunden ist.

  3. Auflösen der Arbeitsbereich-FQDNs:

    Öffnen Sie eine Eingabeaufforderung, Shell oder PowerShell. Führen Sie dann für jeden der Arbeitsbereichs-FQDNs den folgenden Befehl aus:

    nslookup <workspace FQDN>

    Das Ergebnis jedes nslookup-Endpunkts sollte eine der beiden privaten IP-Adressen auf dem privaten Endpunkt an den Azure Machine Learning-Arbeitsbereich zurückgeben. Wenn dies nicht der Fehler ist, wurde in der benutzerdefinierten DNS-Lösung etwas falsch konfiguriert.

    Mögliche Ursachen:

    • Die Computeressource, auf der die Problembehandlungsbefehle ausgeführt werden, verwendet keinen DNS-Server für die DNS-Auflösung
    • Die Private DNS-Zonen, die beim Erstellen des privaten Endpunkts ausgewählt wurden, sind nicht mit dem DNS-Server-VNet verknüpft
    • Die bedingten Weiterleitungen an Azure DNS IP-Adresse des virtuellen Servers wurden nicht ordnungsgemäß konfiguriert

Beispiel: Benutzerdefinierter DNS-Server, der lokal gehostet wird

In dieser Architektur wird die allgemeine Hub-and-Spoke-Topologie des virtuellen Netzwerks verwendet. ExpressRoute wird verwendet, um eine Verbindung zwischen Ihrem lokalen Netzwerk und dem virtuellen Hubnetzwerk herzustellen. Der benutzerdefinierte DNS-Server wird lokal gehostet. Ein gesondertes virtuelles Netzwerk enthält den privaten Endpunkt für den Azure Machine Learning-Arbeitsbereich und die zugehörigen Ressourcen. Bei dieser Topologie muss ein weiteres virtuelles Netzwerk vorhanden sein, das einen DNS-Server hosten kann, der Anforderungen an die IP-Adresse Azure DNS Virtual Servers senden kann.

Diagramm der benutzerdefinierten, lokal gehosteten DNS-Topologie

Die folgenden Schritte beschreiben, wie diese Topologie funktioniert:

  1. Erstellen Sie eine Private DNS-Zone und verknüpfen Sie sie mit DNS Server Virtual Network:

    Der erste Schritt, um sicherzustellen, dass eine benutzerdefinierte DNS-Lösung mit Ihrem Azure Machine Learning-Arbeitsbereich funktioniert, besteht darin, zwei Private DNS-Zonen zu erstellen, die von den folgenden Domänen entfernt sind:

    öffentliche Azure-Regionen:

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

    Regionen vom Typ „Microsoft Azure, betrieben von 21Vianet“:

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

    Azure US Government-Regionen:

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

    Hinweis

    Verwaltete Onlineendpunkte nutzen den privaten Endpunkt des Arbeitsbereichs gemeinsam. Wenn Sie DNS-Einträge manuell zur privaten DNS-Zone privatelink.api.azureml.ms hinzufügen, sollte ein A-Eintrag mit dem Platzhalter *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms hinzugefügt werden, um alle Endpunkte des Arbeitsbereichs an den privaten Endpunkt weiterzuleiten.

    Nach der Erstellung der Private DNS-Zone muss diese mit dem DNS-Server-VNet verknüpft werden: dem virtuellen Netzwerk, das den DNS-Server enthält.

    Hinweis

    Der DNS-Server im virtuellen Netzwerk ist vom lokalen DNS-Server getrennt.

    Eine Private DNS-Zone überschreibt die Namensauflösung für alle Namen innerhalb des Bereichs des Stamms der Zone. Diese Außerkraftsetzung gilt für alle virtuellen Netzwerke, mit der Privaten DNS-Zone verknüpft sind. Wenn z. B. eine Private DNS-Zone mit privatelink.api.azureml.ms-Stamm mit Virtual Network foo verknüpft ist, erhalten alle Ressourcen in Virtual Network foo, die versuchen, bar.workspace.westus2.privatelink.api.azureml.ms aufzulösen, alle in der privatelink.api.azureml.ms-Zone aufgeführten Daten.

    Datensätze, die in Private DNS-Zonen aufgeführt sind, werden jedoch nur an Geräte zurückgegeben, die Domänen mithilfe der Standard-Azure DNS IP-Adresse des virtuellen Servers auflösen. Die IP-Adresse des Azure DNS Virtual Servers ist nur im Kontext eines virtuellen Netzwerks gültig. Bei Verwendung eines lokalen DNS-Servers kann die IP-Adresse des Azure DNS Virtual Servers nicht abgefragt werden, um Datensätze abzurufen.

    Um dieses Verhalten zu umgehen, erstellen Sie einen zwischengeschalteten DNS-Server in einem virtuellen Netzwerk. Dieser DNS-Server kann die IP-Adresse des Azure DNS Virtual Servers abfragen, um Datensätze für alle Private DNS-Zonen abzurufen, die mit dem virtuellen Netzwerk verknüpft sind.

    Während der lokale DNS-Server Domänen für Geräte auflöst, die in Ihrer Netzwerktopologie verteilt sind, löst er Azure Machine Learning bezogene Domänen für den DNS-Server auf. Der DNS-Server löst diese Domänen aus der IP-Adresse Azure DNS Virtual Servers auf.

  2. Erstellen Sie einen privaten Endpunkt mit privater DNS-Integration für die Private DNS-Zone, die mit DNS Server Virtual Network verbunden ist:

    Im nächsten Schritt erstellen Sie einen privaten Endpunkt für den Azure Machine Learning-Arbeitsbereich. Der private Endpunkt ist für beide Private DNS-Zonen, die in Schritt 1 erstellt wurden. Dadurch wird sichergestellt, dass die gesamte Kommunikation mit dem Arbeitsbereich über den privaten Endpunkt im Azure Machine Learning Virtual Network durchgeführt wird.

    Wichtig

    Für den privaten Endpunkt muss die Integration von „Privates DNS“ aktiviert sein, damit dieses Beispiel ordnungsgemäß funktioniert.

  3. Erstellen Sie eine bedingte Weiterleitungsanweisung auf dem DNS-Server, um sie an Azure DNS weiterzuleiten:

    Erstellen Sie als Nächstes eine bedingte Weiterleitung an den Azure DNS Virtual Server. Die bedingte Weiterleitung stellt sicher, dass der DNS-Server die IP-Adresse Azure DNS virtuellen Servers immer nach FQDNs abfragt, die mit Ihrem Arbeitsbereich verknüpft sind. Dies bedeutet, dass der DNS-Server den entsprechenden Eintrag aus der Private DNS-Zone zurückgibt.

    Die Zonen, die bedingt weitergeleitet werden sollen, sind unten aufgeführt. Die Azure DNS-IP-Adresse des virtuellen Servers lautet 168.63.129.16.

    öffentliche Azure-Regionen:

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • aznbcontent.net
    • inference.ml.azure.com: Wird von verwalteten Onlineendpunkten verwendet.

    Regionen vom Typ „Microsoft Azure, betrieben von 21Vianet“:

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • aznbcontent.net
    • inference.ml.azure.cn: Wird von verwalteten Onlineendpunkten verwendet.

    Azure US Government-Regionen:

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • aznbcontent.net
    • inference.ml.azure.us: Wird von verwalteten Onlineendpunkten verwendet.

    Wichtig

    Konfigurationsschritte für den DNS-Server sind hier nicht enthalten, da viele DNS-Lösungen verfügbar sind, die als benutzerdefinierter DNS-Server verwendet werden können. Informationen zum ordnungsgemäßen Konfigurieren der bedingten Weiterleitung finden Sie in der Dokumentation zu Ihrer DNS-Lösung.

  4. Erstellen Sie eine bedingte Weiterleitung auf dem lokalen DNS-Server, um sie an den DNS-Server weiterzuleiten:

    Erstellen Sie als Nächstes im DNS Server Virtual Network eine bedingte Weiterleitung an den DNS-Server. Diese Weiterleitung gilt für die in Schritt 1 aufgeführten Zonen. Dies ähnelt Schritt 3, aber anstatt an die IP-Adresse des Azure DNS Virtual Servers weiterzusenden, wird der lokale DNS-Server auf die IP-Adresse des DNS-Servers abzielen. Da sich der lokale DNS-Server nicht in Azure befindet, ist er nicht in der Lage, Datensätze in Private DNS-aufzulösen. In diesem Fall sendet der DNS-Server Proxyanforderungen vom lokalen DNS-Server an die IP-Adresse des Azure DNS Virtual Server. Dadurch kann der lokale DNS-Server Datensätze in den Private DNS-Zonen abrufen, die mit dem DNS Server Virtual Network verknüpft sind.

    Die Zonen, die bedingt weitergeleitet werden sollen, sind unten aufgeführt. Die IP-Adressen, an die weitergeleitet werden soll, sind die IP-Adressen Ihrer DNS-Server:

    öffentliche Azure-Regionen:

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • inference.ml.azure.com: Wird von verwalteten Onlineendpunkten verwendet.

    Regionen vom Typ „Microsoft Azure, betrieben von 21Vianet“:

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • inference.ml.azure.cn: Wird von verwalteten Onlineendpunkten verwendet.

    Azure US Government-Regionen:

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • inference.ml.azure.us: Wird von verwalteten Onlineendpunkten verwendet.

    Wichtig

    Konfigurationsschritte für den DNS-Server sind hier nicht enthalten, da viele DNS-Lösungen verfügbar sind, die als benutzerdefinierter DNS-Server verwendet werden können. Informationen zum ordnungsgemäßen Konfigurieren der bedingten Weiterleitung finden Sie in der Dokumentation zu Ihrer DNS-Lösung.

  5. Auflösen der Arbeitsbereichsdomäne:

    An diesem Punkt wird das Setup-Programm durchgeführt. Jeder Client, der lokale DNS-Server für die Namensauflösung verwendet und über eine Route zum privaten Endpunkt von Azure Machine Learning verfügt, kann mit dem Zugriff auf den Arbeitsbereich fortfahren.

    Der Client beginnt zunächst mit der Abfrage des DNS-Servers nach der Adresse der folgenden FQDNs:

    öffentliche Azure-Regionen:

    • <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: Wird von verwalteten Onlineendpunkten verwendet.

    Regionen vom Typ „Microsoft Azure, betrieben von 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: Wird von verwalteten Onlineendpunkten verwendet.

    Azure US Government-Regionen:

    • <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: Wird von verwalteten Onlineendpunkten verwendet.

  6. Der lokale DNS-Server löst die Arbeitsbereichsdomäne rekursiv auf:

    Der lokale DNS-Server löst die FQDNs aus Schritt 5 vom DNS-Server auf. Da es eine bedingte Weiterleitung gibt (Schritt 4), sendet der lokale DNS-Server die Anforderung zur Auflösung an den DNS-Server.

  7. Der DNS-Server löst die Arbeitsbereichsdomäne in CNAME aus Azure DNS auf:

    Der DNS-Server wird die FQDNs aus Schritt 5 von Azure DNS auflösen. Azure DNS antwortet mit einer der in Schritt 1 aufgeführten Domänen.

  8. Der lokale DNS-Server löst den CNAME-Eintrag der Arbeitsbereichsdomäne rekursiv aus dem DNS-Server auf:

    Der lokale DNS-Server löst den in Schritt 7 empfangenen CNAME rekursiv auf. Da in Schritt 4 eine bedingte Weiterleitung eingerichtet wurde, sendet der lokale DNS-Server die Anforderung zur Auflösung an den DNS-Server.

  9. Der DNS-Server löst den CNAME-Eintrag der Arbeitsbereichsdomäne rekursiv aus Azure DNS auf:

    Der DNS-Server löst den in Schritt 7 empfangenen CNAME rekursiv auf. Da in Schritt 3 eine bedingte Weiterleitung eingerichtet wurde, sendet der DNS-Server die Anforderung zur Auflösung an die IP-Adresse des Azure DNS Virtual Servers.

  10. Azure DNS gibt Datensätze aus Private DNS-Zone zurück:

    Die entsprechenden Datensätze, die in den Private DNS-Zonen gespeichert sind, werden an den DNS-Server zurückgegeben. Dies bedeutet, dass der Azure DNS Virtual Server die IP-Adressen des privaten Endpunkts zurückgibt.

  11. Der lokale DNS-Server löst den Domänennamen des Arbeitsbereichs in die Adresse des privaten Endpunkts auf:

    Die Abfrage vom lokalen DNS-Server zum DNS-Server in Schritt 8 gibt letztendlich die IP-Adressen, die dem privaten Endpunkt zugeordnet sind, an den Azure Machine Learning-Arbeitsbereich zurück. Diese IP-Adressen werden an den ursprünglichen Client zurückgegeben, der nun über den in Schritt 1 konfigurierten privaten Endpunkt mit dem Azure Machine Learning-Arbeitsbereich kommuniziert.

    Wichtig

    Wenn VPN Gateway in dieser Einrichtung zusammen mit benutzerdefinierten DNS-Server-IP-Adressen im VNet verwendet wird, muss die Azure DNS-IP-Adresse (168.63.129.16) der Liste hinzugefügt werden, um eine unterbrechungsfreie Kommunikation zu gewährleisten.

Beispiel: Datei „hosts“

Die hosts-Datei ist ein Textdokument, das Linux, macOS und Windows alle verwenden, um die Namensauflösung für den lokalen Computer außer Kraft zu setzen. Die Datei enthält eine Liste von IP-Adressen und den entsprechenden Hostnamen. Wenn der lokale Computer versucht, einen Hostnamen aufzulösen, wird der Name in die entsprechende IP-Adresse aufgelöst, wenn der Hostname in der hosts-Datei aufgeführt ist.

Wichtig

Die hosts-Datei setzt nur die Namensauflösung für den lokalen Computer außer Kraft. Wenn Sie eine hosts-Datei mit mehreren Computern verwenden möchten, müssen Sie sie auf jedem Computer einzeln ändern.

In der folgenden Tabelle ist der Speicherort der hosts-Datei aufgeführt:

Betriebssystem Standort
Linux /etc/hosts
macOS /etc/hosts
Windows %SystemRoot%\System32\drivers\etc\hosts

Tipp

Der Name der hosts-Datei hat keine Erweiterung. Verwenden Sie beim Bearbeiten der Datei den Administratorzugriff. Unter Linux oder macOS können Sie z. B. sudo vi verwenden. Unter Windows führen Sie Editor als Administrator aus.

Im Folgenden finden Sie ein Beispiel für hosts-Dateieinträge für 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

Weitere Informationen zur hosts-Datei finden Sie unter https://wikipedia.org/wiki/Hosts_(file).

DNS-Auflösung für Abhängigkeitsdienste

Die Dienste, auf denen Ihr Arbeitsbereich basiert, können auch mithilfe eines privaten Endpunkts gesichert werden. Wenn dies der Fall ist, müssen Sie möglicherweise einen benutzerdefinierten DNS-Eintrag erstellen, wenn Sie direkt mit dem Dienst kommunizieren müssen. Wenn Sie z. B. direkt mit den Daten in einem Azure Storage-Konto arbeiten möchten, das von Ihrem Arbeitsbereich verwendet wird.

Hinweis

Einige Dienste verfügen über mehrere private Endpunkte für untergeordnete Dienste oder Features. Beispielsweise kann ein Azure Storage-Konto über einzelne private Endpunkte für Blob, Datei und DFS verfügen. Wenn Sie sowohl auf Blob- als auch auf Dateispeicher zugreifen müssen, muss die Auflösung für jeden bestimmten privaten Endpunkt aktiviert werden.

Weitere Informationen zu den Diensten und zur DNS-Auflösung finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

Problembehandlung

Wenn Sie nach dem Ausführen der oben genannten Schritte nicht von einem virtuellen Computer aus auf den Arbeitsbereich zugreifen können oder Aufträge auf Compute-Ressourcen im virtuellen Netzwerk mit dem privaten Endpunkt für den Azure Machine Learning-Arbeitsbereich fehlschlagen, führen Sie die folgenden Schritte aus, um die Ursache zu ermitteln.

  1. Suchen Sie die Arbeitsbereichs-FQDNs auf dem privaten Endpunkt:

    Navigieren Sie über einen der folgenden Links zum Azure-Portal:

    Navigieren Sie zum privaten Endpunkt zum Azure Machine Learning-Arbeitsbereich. Die FQDNs des Arbeitsbereichs werden auf der Registerkarte „Übersicht“ aufgeführt.

  2. Zugreifen auf Computeressourcen in der Virtual Network-Topologie:

    Fahren Sie mit dem Zugriff auf eine Computeressource in der Azure Virtual Network-Topologie fort. Dies erfordert wahrscheinlich den Zugriff auf einen virtuellen Computer in einem virtuellen Netzwerk, das mit dem Hub Virtual Network mittels Peering verbunden ist.

  3. Auflösen der Arbeitsbereich-FQDNs:

    Öffnen Sie eine Eingabeaufforderung, Shell oder PowerShell. Führen Sie dann für jeden der Arbeitsbereichs-FQDNs den folgenden Befehl aus:

    nslookup <workspace FQDN>

    Das Ergebnis jedes nslookup-Endpunkts sollte eine der beiden privaten IP-Adressen auf dem privaten Endpunkt am Azure Machine Learning-Arbeitsbereich anhalten. Wenn dies nicht der Fehler ist, wurde in der benutzerdefinierten DNS-Lösung etwas falsch konfiguriert.

    Mögliche Ursachen:

    • Die Computeressource, auf der die Problembehandlungsbefehle ausgeführt werden, verwendet keinen DNS-Server für die DNS-Auflösung
    • Die Private DNS-Zonen, die beim Erstellen des privaten Endpunkts ausgewählt wurden, sind nicht mit dem DNS-Server-VNet verknüpft
    • Die bedingten Weiterleitungen vom DNS-Server an Azure DNS IP-Adresse des virtuellen Servers wurden nicht ordnungsgemäß konfiguriert
    • Bedingte Weiterleitungen vom lokalen DNS-Server zum DNS-Server wurden nicht ordnungsgemäß konfiguriert

Zugehöriger Inhalt

Informationen zur Integration privater Endpunkte in Ihre DNS-Konfiguration finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.