Absichern einer Azure Machine Learning-Trainingsumgebung mit virtuellen Netzwerken

GILT FÜR: Python SDK azure-ai-ml v2 (aktuell)

Azure Machine Learning-Compute-Instanz, serverloses Computing und Computecluster können zum sicheren Trainieren von Modellen in einem virtuellen Azure-Netzwerk verwendet werden. Beim Planen Ihrer Umgebung können Sie die Compute-Instanz/den Cluster oder serverloses Computing mit oder ohne öffentliche IP-Adresse konfigurieren. Die allgemeinen Unterschiede zwischen den beiden sind:

• Keine öffentliche IP-Adresse: Reduziert die Kosten, da nicht die gleichen Anforderungen an die Netzwerkressourcen gestellt werden. Verbessert die Sicherheit, indem die Anforderung für eingehenden Datenverkehr aus dem Internet beseitigt wird. Es sind jedoch zusätzliche Konfigurationsänderungen erforderlich, um den ausgehenden Zugriff auf erforderliche Ressourcen (Microsoft Entra ID, Azure Resource Manager usw.) zu ermöglichen.
• Öffentliche IP-Adresse: Funktioniert standardmäßig, kostet aber aufgrund zusätzlicher Azure-Netzwerkressourcen mehr. Erfordert eingehende Kommunikation vom Azure Machine Learning Service über das öffentliche Internet.

Die folgende Tabelle enthält die Unterschiede zwischen diesen Konfigurationen:

Sie können auch Azure Databricks oder HDInsight verwenden, um Modelle in einem virtuellen Netzwerk zu trainieren.

Dieser Artikel ist Teil einer Reihe zum Schützen eines Azure Machine Learning-Workflows. Sehen Sie sich auch die anderen Artikel in dieser Reihe an:

• Virtuelle Netzwerke im Überblick
• Schützen Sie Arbeitsbereichsressourcen
• Sichern Sie die Inferenzumgebung
• Aktivieren von Studio-Funktionalität
• Verwenden von benutzerdefiniertem DNS
• Verwenden einer Firewall

Ein Tutorial zum Erstellen eines sicheren Arbeitsbereichs finden Sie unter Tutorial: Erstellen eines sicheren Arbeitsbereichs, Bicep-Vorlage oder Terraform-Vorlage.

In diesem Artikel erfahren Sie, wie Sie die folgenden Trainingscomputeressourcen in einem virtuellen Netzwerk schützen:

Voraussetzungen

• Im Artikel Übersicht über die Netzwerksicherheit finden Sie Informationen zu gängigen Szenarien im Zusammenhang mit virtuellen Netzwerken sowie zur Gesamtarchitektur virtueller Netzwerke.

• Ein vorhandenes virtuelles Netzwerk und Subnetz, die mit Ihren Computeressourcen verwendet werden können Dieses virtuelle Netzwerk muss sich im selben Abonnement wie Ihr Azure Machine Learning Arbeitsbereich befinden.

  • Es wird empfohlen, die Speicherkonten, die von Ihrem Arbeitsbereich und Trainingsaufträgen verwendet werden, in derselben Azure-Region zu platzieren, die Sie für Compute-Instanzen, serverloses Computing und Cluster verwenden möchten. Wenn sie sich nicht in derselben Azure-Region befinden, fallen möglicherweise Kosten für die Datenübertragung und eine erhöhte Netzwerklatenz an.
  • Stellen Sie sicher, dass die Kommunikation über WebSocket zu *.instances.azureml.net und *.instances.azureml.ms in Ihrem virtuellen Netzwerk zulässig ist. WebSockets werden von Jupyter auf Compute-Instanzen verwendet.

• Ein vorhandenes Subnetz im virtuellen Netzwerk. Dieses Subnetz wird beim Erstellen von Compute-Instanzen, Clustern und Knoten für serverloses Computing verwendet.

  • Stellen Sie sicher, dass das Subnetz nicht an andere Azure-Dienste delegiert wird.
  • Stellen Sie sicher, dass das Subnetz genügend freie IP-Adressen enthält. Jede Compute-Instanz erfordert eine IP-Adresse. Jeder Knoten innerhalb eines Computeclusters und jeder Knoten für serverloses Computing erfordert eine IP-Adresse.

• Wenn Sie über einen eigenen DNS-Server verfügen, wird empfohlen, die DNS-Weiterleitung zu verwenden, um die vollqualifizierten Domänennamen (FQDN) von Compute-Instanzen und Clustern aufzulösen. Weitere Informationen finden Sie unter Verwenden eines benutzerdefinierten DNS mit Azure Machine Learning.

• Ihr Benutzerkonto muss über die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) zu den folgenden Aktionen berechtigt werden, um Ressourcen in einem virtuellen Netzwerk oder Subnetz bereitstellen zu können:

  • „Microsoft.Network/*/read“ auf der virtuellen Netzwerkressource. Diese Berechtigung ist für ARM-Vorlagenbereitstellungen (Azure Resource Manager) nicht erforderlich.
  • „Microsoft.Network/virtualNetworks/join/action“ auf der virtuellen Netzwerkressource
  • „Microsoft.Network/virtualNetworks/subnets/join/action“ in der Subnetzressource

  Weitere Informationen zu Azure RBAC für Netzwerkfunktionen finden Sie unter Integrierte Rollen für Netzwerkfunktionen.

Begrenzungen

• Die Bereitstellung von Computeclustern/-Instanzen und serverlosem Computing im virtuellen Netzwerk wird mit Azure Lighthouse nicht unterstützt.

• Port 445 muss für die private Netzwerkkommunikation während des Trainings zwischen Ihren Compute-Instanzen und dem Standardspeicherkonto geöffnet sein. Wenn sich Ihre Berechnungen beispielsweise in einem virtuellen Netzwerk befinden und sich das Speicherkonto in einem anderen befindet, blockieren Sie port 445 nicht für das virtuelle Speicherkonto.

Computecluster in einem anderen virtuellen Netzwerk oder einer anderen Region als Arbeitsbereich

Zum Erstellen eines Computeclusters in einer Azure Virtual Network in einer anderen Region als in Ihrem virtuellen Arbeitsbereichsnetzwerk haben Sie mehrere Optionen, um die Kommunikation zwischen den beiden virtuellen Netzwerken zu ermöglichen.

• Verwenden Sie peering für virtuelle Netzwerke.
• Fügen Sie einen privaten Endpunkt für Ihren Arbeitsbereich im virtuellen Netzwerk hinzu, das den Computecluster enthält.

Szenario: virtuelles Netzwerk-Peering

1. Konfigurieren Sie Ihren Arbeitsbereich für die Verwendung eines Azure Virtual Network. Weitere Informationen finden Sie unter Schützen Sie Ihre Arbeitsbereichsressourcen.

2. Erstellen Sie ein zweites Azure Virtual Network, das für Ihre Computecluster verwendet wird. Es kann sich in einer anderen Azure-Region als in der Region befinden, die für Ihren Arbeitsbereich verwendet wird.

3. Konfigurieren Sie virtuelles Netzwerk-Peering zwischen den beiden virtuellen Netzwerken.

   Tipp

   Warten Sie, bis das Peering virtueller Netzwerke den Status Connected hat, bevor Sie fortfahren.

4. Ändern Sie die privatelink.api.azureml.ms DNS-Zone, um einen Link zum virtuellen Netzwerk für den Computecluster hinzuzufügen. Diese Zone wird von Ihrem Azure Machine Learning Arbeitsbereich erstellt, wenn ein privater Endpunkt für die Teilnahme an einem virtuellen Netzwerk verwendet wird.

   1. Fügen Sie der DNS-Zone eine neue VNet-Verbindung hinzu. Hierfür gibt es mehrere Möglichkeiten:

      • Navigieren Sie vom Azure-Portal zur DNS-Zone, und wählen Sie VNet-Verbindungen aus. Wählen Sie dann +Hinzufügen und dann das virtuelle Netzwerk aus, das Sie für Ihre Computecluster erstellt haben.
      • Verwenden Sie über die Azure CLI den Befehl az network private-dns link vnet create. Weitere Informationen finden Sie unter az network private-dns link vnet create.
      • Verwenden Sie über Azure PowerShell den Befehl New-AzPrivateDnsVirtualNetworkLink. Weitere Informationen finden Sie unter New-AzPrivateDnsVirtualNetworkLink.

5. Wiederholen Sie den vorherigen Schritt und die Unterschritte für die privatelink.notebooks.azure.net-DNS-Zone.

6. Konfigurieren Sie die folgenden Azure Ressourcen, um den Zugriff von beiden virtuellen Netzwerken zu ermöglichen.

   • Das Standardspeicherkonto für den Arbeitsbereich.
   • Die Azure Container Registry für den Arbeitsbereich.
   • Der Azure Key Vault für den Arbeitsbereich.

   Tipp

   Es gibt mehrere Möglichkeiten, wie Sie diese Dienste konfigurieren können, um den Zugriff auf die virtuellen Netzwerke zu ermöglichen. Sie können beispielsweise einen privaten Endpunkt für jede Ressource in beiden virtuellen Netzwerken erstellen. Oder Sie können die Ressourcen so konfigurieren, dass der Zugriff von beiden virtuellen Netzwerken zugelassen wird.

7. Erstellen Sie einen Computecluster wie gewohnt, wenn Sie ein virtuelles Netzwerk verwenden, aber wählen Sie das virtuelle Netzwerk aus, das Sie für den Computecluster erstellt haben. Wenn sich das virtuelle Netzwerk in einer anderen Region befindet, wählen Sie diese Region aus, wenn Sie den Computecluster erstellen.

   Warnung

   Wenn Sie bei der Festlegung der Region eine andere Region als Ihren Arbeitsbereich oder Ihre Datenspeicher wählen, können erhöhte Netzwerklatenz und Datenübertragungskosten die Folge sein. Latenz und Kosten können beim Erstellen des Clusters und beim Anwenden von Aufträgen auf den Cluster anfallen.

Szenario: Privater Endpunkt

1. Konfigurieren Sie Ihren Arbeitsbereich für die Verwendung eines Azure Virtual Network. Weitere Informationen finden Sie unter Schützen Sie Ihre Arbeitsbereichsressourcen.

2. Erstellen Sie ein zweites Azure Virtual Network, das für Ihre Computecluster verwendet wird. Es kann sich in einer anderen Azure-Region als in der Region befinden, die für Ihren Arbeitsbereich verwendet wird.

3. Erstellen Sie einen neuen privaten Endpunkt für Ihren Arbeitsbereich im virtuellen Netzwerk, der den Computecluster enthält.

   • Um mithilfe des Azure-Portals einen neuen privaten Endpunkt hinzuzufügen, wählen Sie Ihren Arbeitsbereich und dann Netzwerk aus. Wählen Sie Private Endpunktverbindungen, + Privater Endpunkt aus, und erstellen Sie mithilfe der Felder einen neuen privaten Endpunkt.

     • Wählen Sie beim Festlegen von Region die gleiche Region wie für Ihr virtuelles Netzwerk aus.
     • Verwenden Sie beim Auswählen von Ressourcentyp die Option Microsoft.MachineLearningServices/workspaces.
     • Setzen Sie die Ressource auf den Namen Ihres Arbeitsbereichs fest.
     • Legen Sie das virtuelle Netzwerk und das Subnetz auf das virtuelle Netzwerk und das Subnetz fest, das Sie für Ihre Computecluster erstellt haben.

     Wählen Sie abschließend Erstellen aus, um den privaten Endpunkt zu erstellen.

   • Um einen neuen privaten Endpunkt mithilfe der Azure CLI hinzuzufügen, verwenden Sie den Befehl az network private-endpoint create. Ein Beispiel für die Verwendung dieses Befehls finden Sie unter Konfigurieren eines privaten Endpunkts für den Azure Machine Learning-Arbeitsbereich.

4. Erstellen Sie einen Computecluster wie gewohnt, wenn Sie ein virtuelles Netzwerk verwenden, aber wählen Sie das virtuelle Netzwerk aus, das Sie für den Computecluster erstellt haben. Wenn sich das virtuelle Netzwerk in einer anderen Region befindet, wählen Sie diese Region aus, wenn Sie den Computecluster erstellen.

   Warnung

   Wenn Sie bei der Festlegung der Region eine andere Region als Ihren Arbeitsbereich oder Ihre Datenspeicher wählen, können erhöhte Netzwerklatenz und Datenübertragungskosten die Folge sein. Latenz und Kosten können beim Erstellen des Clusters und beim Anwenden von Aufträgen auf den Cluster anfallen.

Recheninstanz/-cluster oder serverlose Rechenleistung ohne öffentliche IP-Adresse

Die folgenden Konfigurationen gelten zusätzlich zu den im Abschnitt Voraussetzungen aufgeführten und sind spezifisch für das Erstellen von Compute-Instanzen/Clustern, die für keine öffentliche IP-Adresse konfiguriert sind. Sie gelten auch für serverloses Computing:

• Sie müssen einen privaten Arbeitsbereichsendpunkt für die Computeressource verwenden, um mit Azure Machine Learning Diensten aus dem virtuellen Netzwerk zu kommunizieren. Weitere Informationen finden Sie unter „Konfigurieren eines privaten Endpunkts für Azure Machine Learning Workspace“.

• Lassen Sie in Ihrem virtuellen Netzwerk ausgehenden Datenverkehr zu den folgenden Diensttags oder vollqualifizierten Domänennamen (FQDN) zu:

  Service-Tag	Protokoll	Hafen	Notizen
  AzureMachineLearning	TCP UDP	443/8787/18881 5831	Kommunikation mit dem Azure Machine Learning Service.
  BatchNodeManagement.<region>	BELIEBIG	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Kommunikation mit Azure Batch. Compute-Instanz und Computecluster werden mithilfe des Azure Batch-Diensts implementiert.
  Storage.<region>	TCP	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Dieses Diensttag wird verwendet, um mit dem von Azure Batch verwendeten Azure Storage-Konto zu kommunizieren.

  Wichtig

  Der ausgehende Zugriff auf Storage.<region> könnte potenziell dazu verwendet werden, Daten aus Ihrem Arbeitsbereich zu exfiltrieren. Mithilfe einer Richtlinie für Dienstendpunkte können Sie dieses Sicherheitsrisiko entschärfen. Weitere Informationen finden Sie im Artikel Verhinderung der Azure Machine Learning-Datenexfiltration.

  FQDN	Protokoll	Hafen	Notizen
  <region>.tundra.azureml.ms	UDP	5831	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält.
  graph.microsoft.com	TCP	443	Kommunikation mit der Microsoft Graph-API.
  *.instances.azureml.ms	TCP	443/8787/18881	Kommunikation mit Azure Machine Learning.
  *.<region>.batch.azure.com	BELIEBIG	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Kommunikation mit Azure Batch.
  *.<region>.service.batch.azure.com	BELIEBIG	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Kommunikation mit Azure Batch.
  *.blob.core.windows.net	TCP	443	Kommunikation mit Azure Blob Storage.
  *.queue.core.windows.net	TCP	443	Kommunikation mit Azure Queue Storage.
  *.table.core.windows.net	TCP	443	Kommunikation mit Azure Table Storage.

• Standardmäßig verfügt eine Computeinstanz/ein Cluster, der für keine öffentliche IP-Adresse konfiguriert ist, über keinen ausgehenden Zugriff auf das Internet. Wenn Sie von dort aus auf das Internet zugreifen können, liegt dies am ausgehenden Standardzugriff von Azure, und Sie verfügen über eine NSG, die ausgehenden Datenverkehr in das Internet zulässt. Es wird jedoch nicht empfohlen, den ausgehenden Standardzugriff zu verwenden. Wenn Sie ausgehenden Zugriff auf das Internet benötigen, empfiehlt es sich, entweder eine Firewall und Ausgangsregeln oder ein NAT-Gateway und Netzwerkdienstgruppen zu verwenden, um ausgehenden Datenverkehr zuzulassen.

  Weitere Informationen zum ausgehenden Datenverkehr, der von Azure Machine Learning verwendet wird, finden Sie in den folgenden Artikeln:

  • Konfigurieren von ein- und ausgehendem Netzwerkdatenverkehr.
  • Methoden für ausgehende Verbindungen in Azure.

  Weitere Informationen zu Diensttags, die mit Azure Firewall verwendet werden können, finden Sie im Artikel Diensttags für virtuelle Netzwerke.

Verwenden Sie die folgenden Informationen, um eine Compute-Instanz oder einen Cluster ohne öffentliche IP-Adresse zu erstellen:

# create a compute cluster with no public IP
az ml compute create --name cpu-cluster --resource-group rg --workspace-name ws --vnet-name yourvnet --subnet yoursubnet --type AmlCompute --set enable_node_public_ip=False

# create a compute instance with no public IP
az ml compute create --name myci --resource-group rg --workspace-name ws --vnet-name yourvnet --subnet yoursubnet --type ComputeInstance --set enable_node_public_ip=False

from azure.ai.ml.entities import AmlCompute, NetworkSettings

network_settings = NetworkSettings(vnet_name="<vnet-name>", subnet="<subnet-name>")
compute = AmlCompute(
    name=cpu_compute_target,
    size="STANDARD_D2_V2",
    min_instances=0,
    max_instances=4,
    enable_node_public_ip=False,
    network_settings=network_settings
)
ml_client.begin_create_or_update(entity=compute)

Verwenden Sie die folgenden Informationen, um serverlose Computeknoten ohne öffentliche IP-Adresse im virtuellen Netzwerk für einen bestimmten Arbeitsbereich zu konfigurieren:

az ml workspace create -n <workspace-name> -g <resource-group-name> --file serverlesscomputevnetsettings.yml

name: testserverlesswithnpip
location: eastus
public_network_access: Disabled
serverless_compute:
  custom_subnet: /subscriptions/<sub id>/resourceGroups/<resource group>/providers/Microsoft.Network/virtualNetworks/<vnet name>/subnets/<subnet name>
  no_public_ip: true

az ml workspace update -n <workspace-name> -g <resource-group-name> --file serverlesscomputevnetsettings.yml

serverless_compute:
  custom_subnet: /subscriptions/<sub id>/resourceGroups/<resource group>/providers/Microsoft.Network/virtualNetworks/<vnet name>/subnets/<subnet name>
  no_public_ip: true

from azure.ai.ml import MLClient
from azure.ai.ml.entities import ServerlessComputeSettings, Workspace
from azure.identity import DefaultAzureCredential

subscription_id = "<sub id>"
resource_group = "<resource group>"
workspace_name = "<workspace name>"
ml_client = MLClient(
    DefaultAzureCredential(), subscription_id, resource_group
)

workspace = Workspace(
    name=workspace_name,
    serverless_compute=ServerlessComputeSettings(
        custom_subnet="<subnet id>",
        no_public_ip=True,
    )
)

workspace = ml_client.workspaces.begin_update(workspace)

Recheninstanz/-Cluster oder serverlose Compute-Ressourcen mit öffentlicher IP-Adresse

Die folgenden Konfigurationen gelten zusätzlich zu den im Abschnitt Voraussetzungen aufgeführten und sind spezifisch für das Erstellen von Compute-Instanzen/Clustern mit öffentlicher IP-Adresse. Sie gelten auch für serverloses Computing:

• Wenn Sie mehrere Compute-Instanzen/Cluster in einem einzelnen virtuellen Netzwerk platzieren möchten, müssen Sie möglicherweise eine Kontingenterhöhung für eine oder mehrere Ihrer Ressourcen anfordern. Die Machine Learning-Compute-Instanz bzw. der Cluster ordnet in der Ressourcengruppe mit dem virtuellen Netzwerk automatisch Netzwerkressourcen zu. Für alle Compute-Instanzen und -cluster ordnet der Dienst folgende Ressourcen zu:

  • Eine Netzwerksicherheitsgruppe (NSG) wird automatisch erstellt. Diese NSG lässt eingehenden TCP-Datenverkehr auf Port 44224 vom Diensttag AzureMachineLearning zu.

    Wichtig

    Compute-Instanz und Compute-Cluster erstellen automatisch eine NSG mit den erforderlichen Regeln.

    Wenn Sie eine andere NSG auf Subnetzebene haben, dürfen die Regeln in der NSG auf Subnetzebene nicht mit den Regeln in der automatisch erstellten NSG in Konflikt stehen.

    Informationen dazu, wie die NSGs Ihren Netzwerkverkehr filtern, finden Sie unter So filtern Netzwerksicherheitsgruppen den Netzwerkverkehr.

  • Ein Load Balancer

  Bei Computeclustern werden diese Ressourcen bei jedem Herunterskalieren des Clusters auf 0 Knoten gelöscht und beim Hochskalieren erstellt.

  Bei einer Compute-Instanz werden diese Ressourcen beibehalten, bis die Instanz gelöscht wird. Durch das Beenden der Instanz werden die Ressourcen nicht entfernt.

  Wichtig

  Diese Ressourcen werden durch die Ressourcenkontingente des Abonnements beschränkt. Ist die Ressourcengruppe des virtuellen Netzwerks gesperrt, kann der Computecluster/die Compute-Instanz nicht erfolgreich gelöscht werden. Der Load Balancer kann nicht gelöscht werden, solange das Compute-Cluster bzw. die Compute-Instanz nicht gelöscht ist. Stellen Sie außerdem sicher, dass keine Azure-Richtlinienzuweisungen vorhanden sind, die die Erstellung von Netzwerksicherheitsgruppen verhindern.

• Lassen Sie in Ihrem virtuellen Netzwerk eingehenden TCP-Datenverkehr auf Port 44224 aus dem AzureMachineLearning-Diensttag zu.

  Wichtig

  Der Compute-Instanz/dem Cluster wird beim Erstellen dynamisch eine IP-Adresse zugewiesen. Da die Adresse vor der Erstellung nicht bekannt ist und eingehender Zugriff im Rahmen des Erstellungsprozesses erforderlich ist, können Sie sie Ihrer Firewall nicht statisch zuweisen. Wenn Sie stattdessen eine Firewall mit dem virtuellen Netzwerk verwenden, müssen Sie eine benutzerdefinierte Route erstellen, um diesen eingehenden Datenverkehr zuzulassen.

• Lassen Sie in Ihrem virtuellen Netzwerk ausgehenden Datenverkehr für die folgenden Diensttags zu:

  Service-Tag	Protokoll	Hafen	Notizen
  AzureMachineLearning	TCP UDP	443/8787/18881 5831	Kommunikation mit dem Azure Machine Learning Service.
  BatchNodeManagement.<region>	BELIEBIG	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Kommunikation mit Azure Batch. Compute-Instanz und Computecluster werden mithilfe des Azure Batch-Diensts implementiert.
  Storage.<region>	TCP	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Dieses Diensttag wird verwendet, um mit dem von Azure Batch verwendeten Azure Storage-Konto zu kommunizieren.

  Wichtig

  Der ausgehende Zugriff auf Storage.<region> könnte potenziell dazu verwendet werden, Daten aus Ihrem Arbeitsbereich zu exfiltrieren. Mithilfe einer Richtlinie für Dienstendpunkte können Sie dieses Sicherheitsrisiko entschärfen. Weitere Informationen finden Sie im Artikel Verhinderung der Azure Machine Learning-Datenexfiltration.

  FQDN	Protokoll	Hafen	Notizen
  <region>.tundra.azureml.ms	UDP	5831	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält.
  graph.microsoft.com	TCP	443	Kommunikation mit der Microsoft Graph-API.
  *.instances.azureml.ms	TCP	443/8787/18881	Kommunikation mit Azure Machine Learning.
  *.<region>.batch.azure.com	BELIEBIG	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Kommunikation mit Azure Batch.
  *.<region>.service.batch.azure.com	BELIEBIG	443	Ersetzen Sie <region> durch die Azure-Region, die Ihren Azure Machine Learning-Arbeitsbereich enthält. Kommunikation mit Azure Batch.
  *.blob.core.windows.net	TCP	443	Kommunikation mit Azure Blob Storage.
  *.queue.core.windows.net	TCP	443	Kommunikation mit Azure Queue Storage.
  *.table.core.windows.net	TCP	443	Kommunikation mit Azure Table Storage.

Verwenden Sie die folgenden Informationen, um eine Computeinstanz oder einen Cluster mit einer öffentlichen IP-Adresse im virtuellen Netzwerk zu erstellen:

# create a compute cluster with a public IP
az ml compute create --name cpu-cluster --resource-group rg --workspace-name ws --vnet-name yourvnet --subnet yoursubnet --type AmlCompute

# create a compute instance with a public IP
az ml compute create --name myci --resource-group rg --workspace-name ws --vnet-name yourvnet --subnet yoursubnet --type ComputeInstance

from azure.ai.ml.entities import AmlCompute, NetworkSettings

network_settings = NetworkSettings(vnet_name="<vnet-name>", subnet="<subnet-name>")
compute = AmlCompute(
    name=cpu_compute_target,
    size="STANDARD_D2_V2",
    min_instances=0,
    max_instances=4,
    network_settings=network_settings
)
ml_client.begin_create_or_update(entity=compute)

Verwenden Sie die folgenden Informationen, um serverlose Computeknoten mit einer öffentlichen IP-Adresse im virtuellen Netzwerk für einen bestimmten Arbeitsbereich zu konfigurieren:

az ml workspace create -n <workspace-name> -g <resource-group-name> --file serverlesscomputevnetsettings.yml

name: testserverlesswithvnet
location: eastus
serverless_compute:
  custom_subnet: /subscriptions/<sub id>/resourceGroups/<resource group>/providers/Microsoft.Network/virtualNetworks/<vnet name>/subnets/<subnet name>
  no_public_ip: false

az ml workspace update -n <workspace-name> -g <resource-group-name> --file serverlesscomputevnetsettings.yml

serverless_compute:
  custom_subnet: /subscriptions/<sub id>/resourceGroups/<resource group>/providers/Microsoft.Network/virtualNetworks/<vnet name>/subnets/<subnet name>
  no_public_ip: false

from azure.ai.ml import MLClient
from azure.ai.ml.entities import ServerlessComputeSettings, Workspace
from azure.identity import DefaultAzureCredential

subscription_id = "<sub id>"
resource_group = "<resource group>"
workspace_name = "<workspace name>"
ml_client = MLClient(
    DefaultAzureCredential(), subscription_id, resource_group
)

workspace = Workspace(
    name=workspace_name,
    serverless_compute=ServerlessComputeSettings(
        custom_subnet="<subnet id>",
        no_public_ip=False,
    )
)

workspace = ml_client.workspaces.begin_update(workspace)

Azure Databricks

• Das virtuelle Netzwerk muss sich im selben Abonnement und in derselben Region befinden wie der Azure Machine Learning-Arbeitsbereich.
• Wenn die Azure Storage-Konten für den Arbeitsbereich ebenfalls in einem virtuellen Netzwerk geschützt sind, müssen sie sich im selben virtuellen Netzwerk befinden wie der Azure Databricks-Cluster.
• Zusätzlich zu den von Azure Databricks verwendeten Subnetzen databricks-private und databricks-public ist auch das für das virtuelle Netzwerk erstellte standardmäßige Subnetz erforderlich.
• Azure Databricks verwendet keinen privaten Endpunkt für die Kommunikation mit dem virtuellen Netzwerk.

Weitere Informationen zur Verwendung von Azure Databricks mit einem virtuellen Netzwerk finden Sie unter Bereitstellen von Azure Databricks in Ihrem Azure Virtual Network.

Virtueller Computer oder HDInsight-Cluster

In diesem Abschnitt erfahren Sie, wie Sie einen virtuellen Computer oder einen Azure HDInsight-Cluster in einem virtuellen Netzwerk mit Ihrem Arbeitsbereich verwenden.

Erstellen der VM oder des HDInsight-Clusters

Erstellen Sie einen virtuellen Computer oder einen HDInsight-Cluster mithilfe des Azure-Portals oder der Azure-Befehlszeilenschnittstelle, und platzieren Sie den Cluster in einem virtuellen Azure-Netzwerk. Weitere Informationen finden Sie in den folgenden Artikeln:

• Erstellen und Verwalten virtueller Azure-Netzwerke für virtuelle Linux-Computer

• Erweitern von Azure HDInsight per Azure Virtual Network

Konfigurieren der Netzwerkports

Damit Azure Machine Learning mit dem SSH-Port des virtuellen Computers oder des Clusters kommunizieren kann, konfigurieren Sie einen Quelleintrag für die Netzwerksicherheitsgruppe. Der SSH-Port ist in der Regel der Port 22. Gehen Sie wie folgt vor, um Datenverkehr aus dieser Quelle zuzulassen:

1. Wählen Sie in der Dropdown-Liste QuelleService-Tag aus.

2. Wählen Sie in der Dropdownliste Quelldiensttag den Eintrag AzureMachineLearning aus.

   

3. Wählen Sie in der Dropdownliste Quellportbereiche den Eintrag * aus.

4. Wählen in der Dropdownliste Ziel die Option Alle aus.

5. Wählen Sie in der Dropdownliste Quellportbereiche den Eintrag 22 aus.

6. Wählen Sie unter Protokoll die Option Alle aus.

7. Wählen Sie für Aktion die Option Zulassen aus.

Behalten Sie die Standardausgangsregeln für die Netzwerksicherheitsgruppe bei. Weitere Informationen finden Sie unter Sicherheitsgruppen bei den Standardsicherheitsregeln.

Wenn Sie die Standardausgangsregeln nicht verwenden und den ausgehenden Zugriff auf Ihr virtuelles Netzwerk beschränken möchten, lesen Sie den Abschnitt Erforderlicher öffentlicher Internetzugriff.

Anfügen der VM oder des HDInsight-Clusters

Fügen Sie den virtuellen Computer oder den HDInsight-Cluster an Ihren Azure Machine Learning-Arbeitsbereich an. Weitere Informationen finden Sie unter Verwalten von Computeressourcen für das Modelltraining und die Bereitstellung in Studio.

Erforderlicher öffentlicher Internetzugriff zum Trainieren von Modellen

Azure Machine Learning erfordert sowohl eingehenden als auch ausgehenden Zugriff auf das öffentliche Internet. Die folgenden Tabellen bieten eine Übersicht darüber, welcher Zugriff erforderlich ist und welchem Zweck der Zugriff dient. Ersetzen Sie bei Diensttags, die auf .region enden, region durch die Azure-Region, die Ihren Arbeitsbereich enthält. Zum Beispiel Storage.westus:

Unter Umständen muss auch ausgehender Datenverkehr für Visual Studio Code und Microsoft-fremde Websites zugelassen werden, um die Installation von Paketen zu ermöglichen, die für Ihr Machine Learning-Projekt erforderlich sind. Die folgende Tabelle enthält gängige Repositorys für maschinelles Lernen:

Wenn Sie Azure Kubernetes Service (AKS) mit Azure Machine Learning verwenden, lassen Sie den folgenden Datenverkehr an das AKS-VNET zu:

• Allgemeine Anforderungen für eingehenden/ausgehenden Datenverkehr für AKS, wie im Artikel Einschränken des ausgehenden Datenverkehrs in Azure Kubernetes Service beschrieben.
• Ausgehend zu mcr.microsoft.com.
• Wenn Sie ein Modell in einem AKS-Cluster bereitstellen, beziehen Sie sich auf den Leitfaden im Artikel Bereitstellen von ML-Modellen in Azure Kubernetes Service.

Informationen zur Verwendung einer Firewalllösung finden Sie unter Verwenden einer Firewall mit Azure Machine Learning.

Nächste Schritte

Dieser Artikel ist Teil einer Reihe zum Schützen eines Azure Machine Learning-Workflows. Sehen Sie sich auch die anderen Artikel in dieser Reihe an:

• Virtuelle Netzwerke im Überblick
• Schützen Sie Arbeitsbereichsressourcen
• Sichern Sie die Inferenzumgebung
• Aktivieren von Studio-Funktionalität
• Verwenden von benutzerdefiniertem DNS
• Verwenden einer Firewall