Udostępnij za pośrednictwem


Jak używać obszaru roboczego z niestandardowym serwerem DNS

W przypadku korzystania z obszaru roboczego usługi Azure Machine Learning (w tym centrów azure AI) z prywatnym punktem końcowym istnieje kilka sposobów obsługi rozpoznawania nazw DNS. Domyślnie platforma Azure automatycznie obsługuje rozpoznawanie nazw dla obszaru roboczego i prywatnego punktu końcowego. Jeśli zamiast tego używasz własnego niestandardowego serwera DNS, musisz ręcznie utworzyć wpisy DNS lub użyć warunkowych usług przesyłania dalej dla obszaru roboczego.

Ważne

W tym artykule opisano sposób znajdowania w pełni kwalifikowanych nazw domen (FQDN) i adresów IP dla tych wpisów, jeśli chcesz ręcznie zarejestrować rekordy DNS w rozwiązaniu DNS. Ponadto ten artykuł zawiera zalecenia dotyczące architektury dotyczące konfigurowania niestandardowego rozwiązania DNS w celu automatycznego rozpoznawania nazw FQDN do poprawnych adresów IP. Ten artykuł nie zawiera informacji na temat konfigurowania rekordów DNS dla tych elementów. Zapoznaj się z dokumentacją oprogramowania DNS, aby uzyskać informacje na temat dodawania rekordów.

Wymagania wstępne

  • Obszar roboczy usługi Azure Machine Learning z prywatnym punktem końcowym, w tym obszary robocze centrum, takie jak te używane przez usługę Azure AI Studio. Aby uzyskać więcej informacji, zobacz Tworzenie obszaru roboczego usługi Azure Machine Learning.

  • Jeśli zasoby zależności obszaru roboczego są zabezpieczone za pomocą sieci wirtualnej platformy Azure, znajomość izolacji sieci podczas trenowania i wnioskowania.

Automatyczna integracja serwera DNS

Wprowadzenie

Istnieją dwie typowe architektury do korzystania z automatycznej integracji serwera DNS z usługą Azure Machine Learning:

Chociaż architektura może się różnić od tych przykładów, można ich użyć jako punktu odniesienia. Obie przykładowe architektury zawierają kroki rozwiązywania problemów, które mogą pomóc w zidentyfikowaniu składników, które mogą być nieprawidłowo skonfigurowane.

Inną opcją jest zmodyfikowanie hosts pliku na kliencie, który łączy się z siecią wirtualną platformy Azure zawierającą obszar roboczy. Aby uzyskać więcej informacji, zobacz sekcję Plik hosta.

Ścieżka rozpoznawania nazw DNS obszaru roboczego

Dostęp do danego obszaru roboczego usługi Azure Machine Learning za pośrednictwem usługi Private Link odbywa się przez komunikację z następującymi w pełni kwalifikowanymi domenami (nazywanymi nazwami FQDN obszaru roboczego) wymienionymi poniżej:

Ważne

Jeśli używasz obszaru roboczego centrum (w tym centrum usługi Azure AI Studio), będziesz mieć dodatkowe wpisy dla każdego obszaru roboczego projektu utworzonego z centrum.

Regiony publiczne platformy 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 — Używane przez az ml compute connect-ssh polecenie do nawiązywania połączenia z obliczeniami w zarządzanej sieci wirtualnej.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.azure.net
  • <managed online endpoint name>.<region>.inference.ml.azure.com — Używane przez zarządzane punkty końcowe online

Napiwek

Jeśli używasz obszaru roboczego centrum, istnieją również następujące nazwy FQDN dla każdego obszaru roboczego projektu utworzonego z poziomu obszaru roboczego centrum:

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

Platforma Microsoft Azure obsługiwana przez regiony 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 — Używane przez az ml compute connect-ssh polecenie do nawiązywania połączenia z obliczeniami w zarządzanej sieci wirtualnej.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.chinacloudapi.cn
  • <managed online endpoint name>.<region>.inference.ml.azure.cn — Używane przez zarządzane punkty końcowe online

Napiwek

Jeśli używasz obszaru roboczego centrum, istnieją również następujące nazwy FQDN dla każdego obszaru roboczego projektu utworzonego z poziomu obszaru roboczego centrum:

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

Regiony świadczenia usługi 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 — Używane przez az ml compute connect-ssh polecenie do nawiązywania połączenia z obliczeniami w zarządzanej sieci wirtualnej.
  • ml-<workspace-name, truncated>-<region>-<per-workspace globally-unique identifier>.<region>.notebooks.usgovcloudapi.net
  • <managed online endpoint name>.<region>.inference.ml.azure.us — Używane przez zarządzane punkty końcowe online

Napiwek

Jeśli używasz obszaru roboczego centrum, istnieją również następujące nazwy FQDN dla każdego obszaru roboczego projektu utworzonego z poziomu obszaru roboczego centrum:

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

W pełni kwalifikowane domeny rozpoznają następujące nazwy kanoniczne (CNAM) nazywane nazwami FQDN usługi Private Link obszaru roboczego:

Regiony publiczne platformy 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 — Używane przez zarządzane punkty końcowe online

Platforma Azure obsługiwana przez regiony 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 — Używane przez zarządzane punkty końcowe online

Regiony świadczenia usługi 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 — Używane przez zarządzane punkty końcowe online

Nazwy FQDN są rozpoznawane jako adresy IP obszaru roboczego usługi Azure Machine Learning w tym regionie. Jednak rozpoznawanie nazw FQDN usługi Private Link w obszarze roboczym można zastąpić przy użyciu niestandardowego serwera DNS hostowanego w sieci wirtualnej. Przykład tej architektury można znaleźć w przykładzie niestandardowego serwera DNS hostowanego w sieci wirtualnej . W przypadku obszarów roboczych centrum i projektu nazwy FQDN wszystkich obszarów roboczych projektu są rozpoznawane jako adres IP obszaru roboczego centrum.

Uwaga

Zarządzane punkty końcowe online współużytkuje prywatny punkt końcowy obszaru roboczego. Jeśli ręcznie dodasz rekordy DNS do prywatnej strefy privatelink.api.azureml.msDNS, należy dodać rekord A z symbolem wieloznacznymi *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms w celu kierowania wszystkich punktów końcowych w obszarze roboczym do prywatnego punktu końcowego.

Ręczna integracja serwera DNS

W tej sekcji omówiono, które w pełni kwalifikowane domeny do utworzenia rekordów A dla serwera DNS oraz adres IP, aby ustawić wartość rekordu A.

Pobieranie nazw FQDN prywatnego punktu końcowego

Region publiczny platformy Azure

Poniższa lista zawiera w pełni kwalifikowane nazwy domen (FQDN) używane przez obszar roboczy, jeśli znajduje się w chmurze publicznej platformy 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

    Uwaga

    Nazwa obszaru roboczego dla tej nazwy FQDN może zostać obcięta. Obcięcie jest wykonywane, aby zachować ml-<workspace-name, truncated>-<region>-<workspace-guid> co najmniej 63 znaki.

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

    Uwaga

    • Dostęp do wystąpień obliczeniowych można uzyskać tylko z poziomu sieci wirtualnej.
    • Adres IP tej nazwy FQDN nie jest adresem IP wystąpienia obliczeniowego. Zamiast tego użyj prywatnego adresu IP prywatnego punktu końcowego obszaru roboczego (adresu IP *.api.azureml.ms wpisów).
  • <instance-name>-22.<region>.instances.azureml.ms — używane tylko przez az ml compute connect-ssh polecenie do łączenia się z obliczeniami w zarządzanej sieci wirtualnej. Nie jest to konieczne, jeśli nie używasz sieci zarządzanej ani połączeń SSH.

  • <managed online endpoint name>.<region>.inference.ml.azure.com — Używane przez zarządzane punkty końcowe online

Napiwek

Jeśli używasz obszarów roboczych centrum i projektu, każdy obszar roboczy projektu ma własny zestaw dodatkowych nazw FQDN. Aby uzyskać więcej informacji, zobacz sekcję rozpoznawania nazw DNS obszaru roboczego.

Platforma Microsoft Azure obsługiwana przez region 21Vianet

Następujące nazwy FQDN są przeznaczone dla platformy Microsoft Azure obsługiwanej przez regiony 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

    Uwaga

    Nazwa obszaru roboczego dla tej nazwy FQDN może zostać obcięta. Obcięcie jest wykonywane, aby zachować ml-<workspace-name, truncated>-<region>-<workspace-guid> co najmniej 63 znaki.

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

    • Adres IP tej nazwy FQDN nie jest adresem IP wystąpienia obliczeniowego. Zamiast tego użyj prywatnego adresu IP prywatnego punktu końcowego obszaru roboczego (adresu IP *.api.azureml.ms wpisów).
  • <instance-name>-22.<region>.instances.azureml.cn — używane tylko przez az ml compute connect-ssh polecenie do łączenia się z obliczeniami w zarządzanej sieci wirtualnej. Nie jest to konieczne, jeśli nie używasz sieci zarządzanej ani połączeń SSH.

  • <managed online endpoint name>.<region>.inference.ml.azure.cn — Używane przez zarządzane punkty końcowe online

Napiwek

Jeśli używasz obszarów roboczych centrum i projektu, każdy obszar roboczy projektu ma własny zestaw dodatkowych nazw FQDN. Aby uzyskać więcej informacji, zobacz sekcję rozpoznawania nazw DNS obszaru roboczego.

Wersja platformy Azure dla administracji USA

Następujące nazwy FQDN dotyczą regionów świadczenia usługi 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

    Uwaga

    Nazwa obszaru roboczego dla tej nazwy FQDN może zostać obcięta. Obcięcie jest wykonywane, aby zachować ml-<workspace-name, truncated>-<region>-<workspace-guid> co najmniej 63 znaki.

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

    • Adres IP tej nazwy FQDN nie jest adresem IP wystąpienia obliczeniowego. Zamiast tego użyj prywatnego adresu IP prywatnego punktu końcowego obszaru roboczego (adresu IP *.api.azureml.ms wpisów).
  • <instance-name>-22.<region>.instances.azureml.us — używane tylko przez az ml compute connect-ssh polecenie do łączenia się z obliczeniami w zarządzanej sieci wirtualnej. Nie jest to konieczne, jeśli nie używasz sieci zarządzanej ani połączeń SSH.

  • <managed online endpoint name>.<region>.inference.ml.azure.us — Używane przez zarządzane punkty końcowe online

Napiwek

Jeśli używasz obszarów roboczych centrum i projektu, każdy obszar roboczy projektu ma własny zestaw dodatkowych nazw FQDN. Aby uzyskać więcej informacji, zobacz sekcję rozpoznawania nazw DNS obszaru roboczego.

Znajdowanie adresów IP

Aby znaleźć wewnętrzne adresy IP nazw FQDN w sieci wirtualnej, użyj jednej z następujących metod:

Uwaga

W pełni kwalifikowane nazwy domen i adresy IP będą się różnić w zależności od konfiguracji. Na przykład wartość identyfikatora GUID w nazwie domeny będzie specyficzna dla obszaru roboczego.

  1. Aby uzyskać identyfikator interfejsu sieciowego prywatnego punktu końcowego, użyj następującego polecenia:

    az network private-endpoint show --name <endpoint> --resource-group <resource-group> --query 'networkInterfaces[*].id' --output table
    
  2. Aby uzyskać informacje o adresie IP i nazwie FQDN dla obszaru roboczego lub obszaru roboczego centrum, użyj następującego polecenia. Zastąp <resource-id> element identyfikatorem z poprzedniego kroku:

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

    Dane wyjściowe będą mieć postać podobną do następującego tekstu:

    [
        {
            "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. Jeśli używasz obszaru roboczego centrum, wykonaj następujące kroki dla każdego obszaru roboczego projektu utworzonego na podstawie centrum:

    1. Aby uzyskać identyfikator obszaru roboczego projektu, użyj następującego polecenia:

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

      Zwrócona wartość będzie stosować 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. Weź nazwy FQDN zwrócone z obszaru roboczego centrum, które kończą się na workspace.<region>.api.azureml.ms wartościach i workspace.<region>.cert.api.azureml.ms. Zastąp wartość identyfikatora GUID na początku tych nazw FQDN identyfikatorem obszaru roboczego projektu. Te nazwy FQDN są dodatkiem do nazw FQDN obszaru roboczego centrum.

    3. Weź nazwę FQDN zwróconą z obszaru roboczego centrum, który jest zgodny z formatem w pliku <workspace-name>-<region>-<GUID>.<region>.notebooks.azure.net. Zastąp wartość identyfikatora GUID identyfikatorem obszaru roboczego projektu. Zastąp nazwę obszaru roboczego centrum nazwą obszaru roboczego projektu. Może być konieczne obcięcie nazwy obszaru roboczego, aby zachować ten wpis o 63 znakach lub mniej. Ta nazwa FQDN jest dodatkiem do nazwy FQDN obszaru roboczego centrum.

Informacje zwrócone ze wszystkich metod są takie same; lista nazw FQDN i prywatny adres IP dla zasobów. Poniższy przykład pochodzi z chmury publicznej platformy Azure:

Nazwa FQDN Adres 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

W poniższej tabeli przedstawiono przykładowe adresy IP z platformy Microsoft Azure obsługiwane przez regiony 21Vianet:

Nazwa FQDN Adres 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

W poniższej tabeli przedstawiono przykładowe adresy IP z regionów świadczenia usługi Azure US Government:

Nazwa FQDN Adres 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

Uwaga

Zarządzane punkty końcowe online udostępniają prywatny punkt końcowy obszaru roboczego. W przypadku ręcznego dodawania rekordów DNS do prywatnej strefy privatelink.api.azureml.msDNS należy dodać rekord A z symbolem wieloznacznymi *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms w celu kierowania wszystkich punktów końcowych w obszarze roboczym do prywatnego punktu końcowego.

Tworzenie rekordów A na niestandardowym serwerze DNS

Po zebraniu listy nazw FQDN i odpowiednich adresów IP przejdź do tworzenia rekordów A na skonfigurowanym serwerze DNS. Zapoznaj się z dokumentacją serwera DNS, aby określić sposób tworzenia rekordów A. Należy pamiętać, że zaleca się utworzenie unikatowej strefy dla całej nazwy FQDN i utworzenie rekordu A w katalogu głównym strefy.

Przykład: niestandardowy serwer DNS hostowany w sieci wirtualnej

Ta architektura używa typowej topologii sieci wirtualnej piasty i szprych. Jedna sieć wirtualna zawiera serwer DNS, a drugi zawiera prywatny punkt końcowy w obszarze roboczym usługi Azure Machine Learning i skojarzonych zasobach. Musi istnieć prawidłowa trasa między obiem sieciami wirtualnymi. Na przykład za pośrednictwem serii równorzędnych sieci wirtualnych.

Diagram niestandardowego systemu DNS hostowanego w topologii platformy Azure

W poniższych krokach opisano sposób działania tej topologii:

  1. Utwórz strefę Prywatna strefa DNS i połącz się z siecią wirtualną serwera DNS:

    Pierwszym krokiem w zapewnieniu współpracy niestandardowego rozwiązania DNS z obszarem roboczym usługi Azure Machine Learning jest utworzenie dwóch stref Prywatna strefa DNS zakorzenionych w następujących domenach:

    Regiony publiczne platformy Azure:

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

    Platforma Microsoft Azure obsługiwana przez regiony 21Vianet:

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

    Regiony świadczenia usługi Azure US Government:

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

    Uwaga

    Zarządzane punkty końcowe online udostępniają prywatny punkt końcowy obszaru roboczego. W przypadku ręcznego dodawania rekordów DNS do prywatnej strefy privatelink.api.azureml.msDNS należy dodać rekord A z symbolem wieloznacznymi *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms w celu kierowania wszystkich punktów końcowych w obszarze roboczym do prywatnego punktu końcowego.

    Po utworzeniu strefy Prywatna strefa DNS należy połączyć ją z siecią wirtualną serwera DNS. Sieć wirtualna zawierająca serwer DNS.

    Prywatna strefa DNS Strefa zastępuje rozpoznawanie nazw dla wszystkich nazw w zakresie katalogu głównego strefy. To zastąpienie dotyczy wszystkich sieci wirtualnych, z których jest połączona strefa Prywatna strefa DNS. Jeśli na przykład Prywatna strefa DNS strefy rooted at privatelink.api.azureml.ms jest połączony z foo sieci wirtualnej, wszystkie zasoby w foo sieci wirtualnej, które próbują rozwiązaćbar.workspace.westus2.privatelink.api.azureml.ms, otrzymają każdy rekord, który znajduje się na liście w privatelink.api.azureml.ms strefie.

    Jednak rekordy wymienione w Prywatna strefa DNS Zones są zwracane tylko do urządzeń rozpoznawania domen przy użyciu domyślnego adresu IP serwera wirtualnego usługi Azure DNS. Dlatego niestandardowy serwer DNS rozpozna domeny dla urządzeń rozmieszczonych w całej topologii sieci. Jednak niestandardowy serwer DNS będzie musiał rozpoznać domeny związane z usługą Azure Machine Learning względem adresu IP serwera wirtualnego usługi Azure DNS.

  2. Utwórz prywatny punkt końcowy z prywatną integracją DNS przeznaczoną dla Prywatna strefa DNS strefy połączonej z siecią wirtualną serwera DNS:

    Następnym krokiem jest utworzenie prywatnego punktu końcowego w obszarze roboczym usługi Azure Machine Learning. Prywatny punkt końcowy jest przeznaczony dla obu stref Prywatna strefa DNS utworzonych w kroku 1. Dzięki temu cała komunikacja z obszarem roboczym odbywa się za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej usługi Azure Machine Learning.

    Ważne

    Prywatny punkt końcowy musi mieć włączoną integrację Prywatna strefa DNS, aby ten przykład działał poprawnie.

  3. Utwórz usługę przesyłania dalej warunkowego na serwerze DNS w celu przekazania do usługi Azure DNS:

    Następnie utwórz warunkowy usługę przesyłania dalej do serwera wirtualnego usługi Azure DNS. Usługa przesyłania dalej warunkowego gwarantuje, że serwer DNS zawsze wysyła zapytanie do adresu IP serwera wirtualnego usługi Azure DNS dla nazw FQDN powiązanych z obszarem roboczym. Oznacza to, że serwer DNS zwróci odpowiedni rekord ze strefy Prywatna strefa DNS.

    Strefy do warunkowego przesyłania dalej są wymienione poniżej. Adres IP serwera wirtualnego usługi Azure DNS to 168.63.129.16:

    Regiony publiczne platformy Azure:

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • aznbcontent.net
    • inference.ml.azure.com — Używane przez zarządzane punkty końcowe online

    Platforma Microsoft Azure obsługiwana przez regiony 21Vianet:

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • aznbcontent.net
    • inference.ml.azure.cn — Używane przez zarządzane punkty końcowe online

    Regiony świadczenia usługi Azure US Government:

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • aznbcontent.net
    • inference.ml.azure.us — Używane przez zarządzane punkty końcowe online

    Ważne

    Kroki konfiguracji serwera DNS nie są uwzględnione w tym miejscu, ponieważ dostępnych jest wiele rozwiązań DNS, które mogą być używane jako niestandardowy serwer DNS. Zapoznaj się z dokumentacją rozwiązania DNS, aby dowiedzieć się, jak odpowiednio skonfigurować przekazywanie warunkowe.

  4. Rozpoznawanie domeny obszaru roboczego:

    W tym momencie wszystkie konfiguracje są wykonywane. Teraz każdy klient, który używa serwera DNS do rozpoznawania nazw i ma trasę do prywatnego punktu końcowego usługi Azure Machine Learning, może przejść do obszaru roboczego. Klient najpierw rozpocznie się od zapytania o serwer DNS dla adresu następujących nazw FQDN:

    Regiony publiczne platformy 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 — Używane przez zarządzane punkty końcowe online

    Platforma Microsoft Azure obsługiwana przez regiony 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 — Używane przez zarządzane punkty końcowe online

    Regiony świadczenia usługi 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 — Używane przez zarządzane punkty końcowe online
  5. Usługa Azure DNS rekursywnie rozpoznaje domenę obszaru roboczego na CNAME:

    Serwer DNS rozpozna nazwy FQDN z kroku 4 z usługi Azure DNS. Usługa Azure DNS odpowie za pomocą jednej z domen wymienionych w kroku 1.

  6. Serwer DNS rekursywnie rozpoznaje rekord CNAME domeny obszaru roboczego z usługi Azure DNS:

    Serwer DNS przejdzie rekursywnie rozpoznać rekord CNAME odebrany w kroku 5. Ponieważ w kroku 3 wystąpiła konfiguracja warunkowego usługi przesyłania dalej, serwer DNS wyśle żądanie do adresu IP serwera wirtualnego usługi Azure DNS w celu rozwiązania problemu.

  7. Usługa Azure DNS zwraca rekordy ze strefy Prywatna strefa DNS:

    Odpowiednie rekordy przechowywane w strefach Prywatna strefa DNS zostaną zwrócone do serwera DNS, co oznacza, że serwer wirtualny usługi Azure DNS zwraca adresy IP prywatnego punktu końcowego.

  8. Niestandardowy serwer DNS rozpoznaje nazwę domeny obszaru roboczego na prywatny adres punktu końcowego:

    Ostatecznie niestandardowy serwer DNS zwraca teraz adresy IP prywatnego punktu końcowego do klienta z kroku 4. Dzięki temu cały ruch do obszaru roboczego usługi Azure Machine Learning odbywa się za pośrednictwem prywatnego punktu końcowego.

Rozwiązywanie problemów

Jeśli nie możesz uzyskać dostępu do obszaru roboczego z maszyny wirtualnej lub zadania kończą się niepowodzeniem w zasobach obliczeniowych w sieci wirtualnej, wykonaj następujące kroki, aby zidentyfikować przyczynę:

  1. Znajdź nazwy FQDN obszaru roboczego w prywatnym punkcie końcowym:

    Przejdź do witryny Azure Portal, korzystając z jednego z następujących linków:

    Przejdź do prywatnego punktu końcowego do obszaru roboczego usługi Azure Machine Learning. Nazwy FQDN obszaru roboczego zostaną wyświetlone na karcie "Przegląd".

  2. Uzyskaj dostęp do zasobu obliczeniowego w topologii sieci wirtualnej:

    Przejdź do zasobu obliczeniowego w topologii usługi Azure Virtual Network. Prawdopodobnie będzie to wymagać dostępu do maszyny wirtualnej w sieci wirtualnej, która jest równorzędna z siecią wirtualną koncentratora.

  3. Rozpoznawanie nazw FQDN obszaru roboczego:

    Otwórz wiersz polecenia, powłokę lub program PowerShell. Następnie dla każdej nazwy FQDN obszaru roboczego uruchom następujące polecenie:

    nslookup <workspace FQDN>

    Wynik każdego polecenia nslookup powinien zwrócić jeden z dwóch prywatnych adresów IP w prywatnym punkcie końcowym do obszaru roboczego usługi Azure Machine Learning. Jeśli tak nie jest, oznacza to. że w niestandardowym rozwiązaniu DNS coś jest nieprawidłowo skonfigurowane.

    Możliwe przyczyny:

    • Zasób obliczeniowy, na którym uruchomiono polecenia rozwiązywania problemów, nie używa serwera DNS do rozpoznawania nazw DNS
    • Prywatne strefy DNS wybrane podczas tworzenia prywatnego punktu końcowego nie są połączone z siecią wirtualną serwera DNS
    • Warunkowe usługi przesyłania dalej do adresu IP serwera wirtualnego usługi Azure DNS nie zostały poprawnie skonfigurowane

Przykład: niestandardowy serwer DNS hostowany lokalnie

Ta architektura używa typowej topologii sieci wirtualnej piasty i szprych. Usługa ExpressRoute służy do nawiązywania połączenia z sieci lokalnej z siecią wirtualną Koncentratora. Niestandardowy serwer DNS jest hostowany lokalnie. Oddzielna sieć wirtualna zawiera prywatny punkt końcowy w obszarze roboczym usługi Azure Machine Learning i skojarzonych zasobach. W tej topologii musi istnieć inna sieć wirtualna hostująca serwer DNS, który może wysyłać żądania do adresu IP serwera wirtualnego usługi Azure DNS.

Diagram niestandardowej topologii hostowanej lokalnie w systemie DNS

W poniższych krokach opisano sposób działania tej topologii:

  1. Utwórz strefę Prywatna strefa DNS i połącz się z siecią wirtualną serwera DNS:

    Pierwszym krokiem w zapewnieniu współpracy niestandardowego rozwiązania DNS z obszarem roboczym usługi Azure Machine Learning jest utworzenie dwóch stref Prywatna strefa DNS zakorzenionych w następujących domenach:

    Regiony publiczne platformy Azure:

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

    Platforma Microsoft Azure obsługiwana przez regiony 21Vianet:

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

    Regiony świadczenia usługi Azure US Government:

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

    Uwaga

    Zarządzane punkty końcowe online udostępniają prywatny punkt końcowy obszaru roboczego. W przypadku ręcznego dodawania rekordów DNS do prywatnej strefy privatelink.api.azureml.msDNS należy dodać rekord A z symbolem wieloznacznymi *.<per-workspace globally-unique identifier>.inference.<region>.privatelink.api.azureml.ms w celu kierowania wszystkich punktów końcowych w obszarze roboczym do prywatnego punktu końcowego.

    Po utworzeniu strefy Prywatna strefa DNS należy połączyć ją z siecią wirtualną serwera DNS — siecią wirtualną zawierającą serwer DNS.

    Uwaga

    Serwer DNS w sieci wirtualnej jest oddzielony od lokalnego serwera DNS.

    Prywatna strefa DNS Strefa zastępuje rozpoznawanie nazw dla wszystkich nazw w zakresie katalogu głównego strefy. To zastąpienie dotyczy wszystkich sieci wirtualnych, z których jest połączona strefa Prywatna strefa DNS. Jeśli na przykład Prywatna strefa DNS strefy rooted at privatelink.api.azureml.ms jest połączony z serwerem sieci wirtualnej, wszystkie zasoby w foo sieci wirtualnej, które spróbują rozwiązaćbar.workspace.westus2.privatelink.api.azureml.ms, otrzymają każdy rekord wymieniony w strefie privatelink.api.azureml.ms.

    Jednak rekordy wymienione w Prywatna strefa DNS Zones są zwracane tylko do urządzeń rozpoznawania domen przy użyciu domyślnego adresu IP serwera wirtualnego usługi Azure DNS. Adres IP serwera wirtualnego usługi Azure DNS jest prawidłowy tylko w kontekście sieci wirtualnej. W przypadku korzystania z lokalnego serwera DNS nie może wykonywać zapytań dotyczących adresu IP serwera wirtualnego usługi Azure DNS w celu pobrania rekordów.

    Aby obejść to zachowanie, utwórz pośredniczący serwer DNS w sieci wirtualnej. Ten serwer DNS może wysyłać zapytania dotyczące adresu IP serwera wirtualnego usługi Azure DNS, aby pobrać rekordy dla dowolnej strefy Prywatna strefa DNS połączonej z siecią wirtualną.

    Podczas gdy lokalny serwer DNS rozpozna domeny dla urządzeń rozmieszczonych w całej topologii sieci, rozpozna domeny związane z usługą Azure Machine Learning względem serwera DNS. Serwer DNS rozpozna te domeny z adresu IP serwera wirtualnego usługi Azure DNS.

  2. Utwórz prywatny punkt końcowy z prywatną integracją DNS przeznaczoną dla Prywatna strefa DNS strefy połączonej z siecią wirtualną serwera DNS:

    Następnym krokiem jest utworzenie prywatnego punktu końcowego w obszarze roboczym usługi Azure Machine Learning. Prywatny punkt końcowy jest przeznaczony dla obu stref Prywatna strefa DNS utworzonych w kroku 1. Dzięki temu cała komunikacja z obszarem roboczym odbywa się za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej usługi Azure Machine Learning.

    Ważne

    Prywatny punkt końcowy musi mieć włączoną integrację Prywatna strefa DNS, aby ten przykład działał poprawnie.

  3. Utwórz usługę przesyłania dalej warunkowego na serwerze DNS w celu przekazania do usługi Azure DNS:

    Następnie utwórz warunkowy usługę przesyłania dalej do serwera wirtualnego usługi Azure DNS. Usługa przesyłania dalej warunkowego gwarantuje, że serwer DNS zawsze wysyła zapytanie do adresu IP serwera wirtualnego usługi Azure DNS dla nazw FQDN powiązanych z obszarem roboczym. Oznacza to, że serwer DNS zwróci odpowiedni rekord ze strefy Prywatna strefa DNS.

    Strefy do warunkowego przesyłania dalej są wymienione poniżej. Adres IP serwera wirtualnego usługi Azure DNS to 168.63.129.16.

    Regiony publiczne platformy Azure:

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • aznbcontent.net
    • inference.ml.azure.com — Używane przez zarządzane punkty końcowe online

    Platforma Microsoft Azure obsługiwana przez regiony 21Vianet:

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • aznbcontent.net
    • inference.ml.azure.cn — Używane przez zarządzane punkty końcowe online

    Regiony świadczenia usługi Azure US Government:

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • aznbcontent.net
    • inference.ml.azure.us — Używane przez zarządzane punkty końcowe online

    Ważne

    Kroki konfiguracji serwera DNS nie są uwzględnione w tym miejscu, ponieważ dostępnych jest wiele rozwiązań DNS, które mogą być używane jako niestandardowy serwer DNS. Zapoznaj się z dokumentacją rozwiązania DNS, aby dowiedzieć się, jak odpowiednio skonfigurować przekazywanie warunkowe.

  4. Utwórz usługę przesyłania dalej warunkowego na lokalnym serwerze DNS, aby przekazywać dalej do serwera DNS:

    Następnie utwórz warunkowy usługę przesyłania dalej do serwera DNS w sieci wirtualnej serwera DNS. Ten element przesyłania dalej dotyczy stref wymienionych w kroku 1. Jest to podobne do kroku 3, ale zamiast przekazywania do adresu IP serwera wirtualnego usługi Azure DNS lokalny serwer DNS będzie przeznaczony dla adresu IP serwera DNS. Ponieważ lokalny serwer DNS nie znajduje się na platformie Azure, nie może bezpośrednio rozpoznawać rekordów w strefach Prywatna strefa DNS. W tym przypadku serwery proxy serwera DNS żądają z lokalnego serwera DNS do adresu IP serwera wirtualnego usługi Azure DNS. Dzięki temu lokalny serwer DNS może pobierać rekordy w strefach Prywatna strefa DNS połączonych z siecią wirtualną serwera DNS.

    Strefy do warunkowego przesyłania dalej są wymienione poniżej. Adresy IP do przekazania to adresy IP serwerów DNS:

    Regiony publiczne platformy Azure:

    • api.azureml.ms
    • notebooks.azure.net
    • instances.azureml.ms
    • inference.ml.azure.com — Używane przez zarządzane punkty końcowe online

    Platforma Microsoft Azure obsługiwana przez regiony 21Vianet:

    • api.ml.azure.cn
    • notebooks.chinacloudapi.cn
    • instances.azureml.cn
    • inference.ml.azure.cn — Używane przez zarządzane punkty końcowe online

    Regiony świadczenia usługi Azure US Government:

    • api.ml.azure.us
    • notebooks.usgovcloudapi.net
    • instances.azureml.us
    • inference.ml.azure.us — Używane przez zarządzane punkty końcowe online

    Ważne

    Kroki konfiguracji serwera DNS nie są uwzględnione w tym miejscu, ponieważ dostępnych jest wiele rozwiązań DNS, które mogą być używane jako niestandardowy serwer DNS. Zapoznaj się z dokumentacją rozwiązania DNS, aby dowiedzieć się, jak odpowiednio skonfigurować przekazywanie warunkowe.

  5. Rozpoznawanie domeny obszaru roboczego:

    W tym momencie wszystkie konfiguracje są wykonywane. Każdy klient, który używa lokalnego serwera DNS do rozpoznawania nazw i ma trasę do prywatnego punktu końcowego usługi Azure Machine Learning, może przejść do obszaru roboczego.

    Klient najpierw uruchomi zapytanie dotyczące lokalnego serwera DNS dla adresu następujących nazw FQDN:

    Regiony publiczne platformy 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 — Używane przez zarządzane punkty końcowe online

    Platforma Microsoft Azure obsługiwana przez regiony 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 — Używane przez zarządzane punkty końcowe online

    Regiony świadczenia usługi 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 — Używane przez zarządzane punkty końcowe online
  6. Lokalny serwer DNS rekursywnie rozpoznaje domenę obszaru roboczego:

    Lokalny serwer DNS rozpozna nazwy FQDN z kroku 5 z serwera DNS. Ponieważ istnieje warunkowy usług przesyłania dalej (krok 4), lokalny serwer DNS wyśle żądanie do serwera DNS w celu rozwiązania problemu.

  7. Serwer DNS rozpoznaje domenę obszaru roboczego na CNAME z usługi Azure DNS:

    Serwer DNS rozpozna nazwy FQDN z kroku 5 z usługi Azure DNS. Usługa Azure DNS odpowie za pomocą jednej z domen wymienionych w kroku 1.

  8. Lokalny serwer DNS rekursywnie rozpoznaje rekord CNAME domeny obszaru roboczego z serwera DNS:

    Lokalny serwer DNS przejdzie rekursywnie rozpoznać rekord CNAME odebrany w kroku 7. Ponieważ w kroku 4 wystąpiła konfiguracja warunkowego usługi przesyłania dalej, lokalny serwer DNS wyśle żądanie do serwera DNS w celu rozwiązania problemu.

  9. Serwer DNS rekursywnie rozpoznaje rekord CNAME domeny obszaru roboczego z usługi Azure DNS:

    Serwer DNS przejdzie rekursywnie rozpoznać rekord CNAME odebrany w kroku 7. Ponieważ w kroku 3 wystąpiła konfiguracja warunkowego usługi przesyłania dalej, serwer DNS wyśle żądanie do adresu IP serwera wirtualnego usługi Azure DNS w celu rozwiązania problemu.

  10. Usługa Azure DNS zwraca rekordy ze strefy Prywatna strefa DNS:

    Odpowiednie rekordy przechowywane w strefach Prywatna strefa DNS zostaną zwrócone do serwera DNS, co oznacza, że serwer wirtualny usługi Azure DNS zwraca adresy IP prywatnego punktu końcowego.

  11. Lokalny serwer DNS rozpoznaje nazwę domeny obszaru roboczego na prywatny adres punktu końcowego:

    Zapytanie z lokalnego serwera DNS do serwera DNS w kroku 8 ostatecznie zwraca adresy IP skojarzone z prywatnym punktem końcowym do obszaru roboczego usługi Azure Machine Learning. Te adresy IP są zwracane do oryginalnego klienta, który będzie teraz komunikować się z obszarem roboczym usługi Azure Machine Learning za pośrednictwem prywatnego punktu końcowego skonfigurowanego w kroku 1.

    Ważne

    Jeśli usługa VPN Gateway jest używana w tej konfiguracji wraz z niestandardowymi adresami IP serwera DNS w sieci wirtualnej, należy również dodać adres IP usługi Azure DNS (168.63.129.16) na liście, a także zachować niedysponowaną komunikację.

Przykład: plik hostów

Plik hosts jest dokumentem tekstowym, którego wszystkie systemy Linux, macOS i Windows używają do zastępowania rozpoznawania nazw dla komputera lokalnego. Plik zawiera listę adresów IP i odpowiednią nazwę hosta. Gdy komputer lokalny próbuje rozpoznać nazwę hosta, jeśli nazwa hosta jest wymieniona w hosts pliku, nazwa jest rozpoznawana jako odpowiedni adres IP.

Ważne

Plik hosts zastępuje tylko rozpoznawanie nazw dla komputera lokalnego. Jeśli chcesz użyć hosts pliku z wieloma komputerami, musisz zmodyfikować go indywidualnie na każdym komputerze.

W poniższej tabeli wymieniono lokalizację hosts pliku:

System operacyjny Lokalizacja
Linux /etc/hosts
macOS /etc/hosts
Windows %SystemRoot%\System32\drivers\etc\hosts

Napiwek

Nazwa pliku nie ma hosts rozszerzenia. Podczas edytowania pliku użyj dostępu administratora. Na przykład w systemie Linux lub macOS możesz użyć polecenia sudo vi. W systemie Windows uruchom Notatnik jako administrator.

Poniżej przedstawiono przykład hosts wpisów plików dla usługi 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

Aby uzyskać więcej informacji na hosts temat pliku, zobacz https://wikipedia.org/wiki/Hosts_(file).

Rozpoznawanie nazw DNS usług zależności

Usługi, na których opiera się obszar roboczy, mogą być również zabezpieczone przy użyciu prywatnego punktu końcowego. Jeśli tak, może być konieczne utworzenie niestandardowego rekordu DNS, jeśli musisz bezpośrednio komunikować się z usługą. Jeśli na przykład chcesz bezpośrednio pracować z danymi na koncie usługi Azure Storage używanym przez obszar roboczy.

Uwaga

Niektóre usługi mają wiele prywatnych punktów końcowych dla usług podrzędnych lub funkcji. Na przykład konto usługi Azure Storage może mieć pojedyncze prywatne punkty końcowe dla obiektów blob, plików i systemu plików DFS. Jeśli potrzebujesz dostępu zarówno do usługi Blob, jak i usługi File Storage, musisz włączyć rozpoznawanie poszczególnych prywatnych punktów końcowych.

Aby uzyskać więcej informacji na temat usług i rozpoznawania nazw DNS, zobacz Konfiguracja dns prywatnego punktu końcowego platformy Azure.

Rozwiązywanie problemów

Jeśli po wykonaniu powyższych kroków nie możesz uzyskać dostępu do obszaru roboczego z maszyny wirtualnej lub zadania kończą się niepowodzeniem w zasobach obliczeniowych w sieci wirtualnej zawierającej prywatny punkt końcowy w obszarze roboczym usługi Azure Machine Learning, wykonaj poniższe kroki, aby spróbować zidentyfikować przyczynę.

  1. Znajdź nazwy FQDN obszaru roboczego w prywatnym punkcie końcowym:

    Przejdź do witryny Azure Portal, korzystając z jednego z następujących linków:

    Przejdź do prywatnego punktu końcowego do obszaru roboczego usługi Azure Machine Learning. Nazwy FQDN obszaru roboczego zostaną wyświetlone na karcie "Przegląd".

  2. Uzyskaj dostęp do zasobu obliczeniowego w topologii sieci wirtualnej:

    Przejdź do zasobu obliczeniowego w topologii usługi Azure Virtual Network. Prawdopodobnie będzie to wymagać dostępu do maszyny wirtualnej w sieci wirtualnej, która jest równorzędna z siecią wirtualną koncentratora.

  3. Rozpoznawanie nazw FQDN obszaru roboczego:

    Otwórz wiersz polecenia, powłokę lub program PowerShell. Następnie dla każdej nazwy FQDN obszaru roboczego uruchom następujące polecenie:

    nslookup <workspace FQDN>

    Wynik każdego polecenia nslookup powinien zwrócić jeden z dwóch prywatnych adresów IP w prywatnym punkcie końcowym do obszaru roboczego usługi Azure Machine Learning. Jeśli tak nie jest, oznacza to. że w niestandardowym rozwiązaniu DNS coś jest nieprawidłowo skonfigurowane.

    Możliwe przyczyny:

    • Zasób obliczeniowy, na którym uruchomiono polecenia rozwiązywania problemów, nie używa serwera DNS do rozpoznawania nazw DNS
    • Prywatne strefy DNS wybrane podczas tworzenia prywatnego punktu końcowego nie są połączone z siecią wirtualną serwera DNS
    • Warunkowe usługi przesyłania dalej z serwera DNS do adresu IP serwera wirtualnego usługi Azure DNS nie zostały poprawnie skonfigurowane
    • Warunkowe usługi przesyłania dalej z lokalnego serwera DNS do serwera DNS nie zostały poprawnie skonfigurowane

Aby uzyskać informacje na temat integrowania prywatnych punktów końcowych z konfiguracją DNS, zobacz Konfiguracja dns prywatnego punktu końcowego platformy Azure.