Erstellen eines Azure Batch-Pools in einem virtuellen Netzwerk

Wenn Sie ein Azure Batch-Pool erstellen, können Sie den Pool in einem von Ihnen angegebenen Subnetz eines virtuellen Azure-Netzwerks bereitstellen. In diesem Artikel wird erklärt, wie Sie einen Batch-Pool in einem virtuellem Netzwerk einrichten.

Gründe für die Verwendung eines virtuellen Netzwerks

Computeknoten in einem Pool können miteinander kommunizieren, z. B. zum Ausführen von Aufgaben mit mehreren Instanzen, ohne dass ein separates virtuelles Netzwerk erforderlich ist. Allerdings können Knoten in einem Pool standardmäßig nicht mit jedem virtuellen Computer (VM) außerhalb des Pools kommunizieren, z. B. Lizenz- oder Dateiservern.

Um die sichere Kommunikation zwischen Serverknoten und virtuellen Computern oder lokalen Netzwerken zu ermöglichen, können Sie den Pool in einem Subnetz eines virtuellen Netzwerks bereitstellen.

Voraussetzungen

• Authentifizierung. Um ein virtuelles Azure-Netzwerk zu verwenden, muss die Batch-Client-API die Microsoft Entra-Authentifizierung verwenden. Weitere Informationen finden Sie unter Authentifizieren von Lösungen des Azure Batch-Diensts mit Active Directory.

• Ein virtuelles Azure-Netzwerk. Um ein virtuelles Netzwerk mit einem oder mehreren Subnetzen im Voraus vorzubereiten, können Sie das Azure-Portal, Azure PowerShell, die Azure-CLI oder andere Methoden verwenden.

  • Um ein auf Azure Resource Manager basiertes VNET zu erstellen, lesen Sie die Informationen unter Erstellen eines virtuellen Netzwerks. Ein auf Resource Manager basiertes virtuelles Netzwerk wird für neue Bereitstellungen empfohlen und wird nur für Pools mit einer Konfiguration für virtuelle Computer unterstützt.

  • Um ein klassisches virtuelles Netzwerk zu erstellen, können Sie sich unter Erstellen eines (klassischen) virtuellen Netzwerks mit mehreren Subnetzen informieren. Ein klassisches virtuelles Netzwerk wird nur für Pools mit einer Konfiguration für Cloud Services unterstützt.

    Wichtig

    Vermeiden Sie die Verwendung von 172.17.0.0/16 für das VNet des Azure Batch-Pools. Dabei handelt es sich um die Standardeinstellung für das Docker-Brückennetzwerk. Diese könnte einen Konflikt mit anderen Netzwerken verursachen, die Sie mit dem VNet verbinden möchten. Das Erstellen eines virtuellen Netzwerks für den Azure Batch-Pool erfordert eine sorgfältige Planung Ihrer Netzwerkinfrastruktur.

Allgemeine Anforderungen für virtuelle Netzwerke

• Das virtuelle Netzwerk muss sich im gleichen Abonnement und in der gleichen Region befinden wie das für die Poolerstellung verwendete Batch-Konto.

• Das für den Pool angegebene Subnetz muss über ausreichend nicht zugewiesene IP-Adressen verfügen, um die Anzahl virtueller Computer aufnehmen zu können, die für den Pool geplant sind, genug um die targetDedicatedNodes- und targetLowPriorityNodes-Eigenschaften des Pools zu aufzunehmen. Wenn das Subnetz nicht über ausreichend nicht zugewiesene IP-Adressen verfügt, belegt der Pool teilweise die Computeknoten und es tritt ein Anpassungsfehler auf.

• Wenn Sie die vereinfachte Kommunikation von Serverknoten nicht verwenden, müssen Sie Azure Storage-Endpunkte auflösen, indem Sie alle benutzerdefinierten DNS-Server verwenden, die Ihr virtuelles Netzwerk bedienen. Insbesondere URLs im Format <account>.table.core.windows.net, <account>.queue.core.windows.net und <account>.blob.core.windows.net müssen auflösbar sein.

• Mehrere Pools können im gleichen virtuellen Netzwerk oder im gleichen Subnetz erstellt werden (sofern der Adressraum ausreicht). Ein einzelner Pool kann nicht in mehreren virtuellen Netzwerken oder Subnetzen vorhanden sein.

• Jedes virtuelle Netzwerk oder jedes virtuelle Netzwerk mit Peering, das für Batch-Pools verwendet wird, sollte keine überlappenden IP-Adressbereiche mit softwaredefinierten Netzwerken oder Routing auf Serverknoten aufweisen. Eine häufige Konfliktquelle ist die Verwendung einer Containerruntime wie Docker. Docker erstellt eine Standardnetzwerkbrücke mit einem definierten Subnetzbereich von 172.17.0.0/16. Alle Dienste, die in einem virtuellen Netzwerk in diesem IP-Standardadressraum ausgeführt werden, verursachen einen Konflikt mit Diensten auf dem Serverknoten, z. B. der Remotezugriff über SSH.

Pools in der Konfiguration des virtuellen Computers

Anforderungen:

• Unterstützte virtuelle Netzwerke: Nur auf Azure Resource Manager basierende virtuelle Netzwerke.
• Subnetz-ID: Verwenden Sie den Ressourcenbezeichner des Subnetzes, wenn Sie das Subnetz über die Batch-APIs angeben. Die Subnetz-ID hat folgendes Format:

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}

• Berechtigungen: Überprüfen Sie, ob Benutzerberechtigungen für die Verwaltung des virtuellen Netzwerks durch Ihre Sicherheitsrichtlinien oder -sperren für das Abonnement oder die Ressourcengruppe Ihres virtuellen Netzwerks eingeschränkt werden.
• Netzwerkressourcen: Batch erstellt in der Ressourcengruppe, die das virtuelle Netzwerk enthält, automatisch weitere Netzwerkressourcen.

Netzwerksicherheitsgruppen für Konfigurationspools für virtuelle Computer: Batch-Standardeinstellung

Batch erstellt eine Netzwerksicherheitsgruppe (NSG) auf der Netzwerkschnittstellenebene jeder VM-Skalierungsgruppenbereitstellung in einem Batch-Pool. Für Pools ohne öffentliche IP-Adressen in der Serverknotenkommunikation simplified werden keine NSGs erstellt.

Um die erforderliche Kommunikation zwischen Serverknoten und dem Batch-Dienst zu ermöglichen, werden diese NSGs wie folgt konfiguriert:

• Eingehender TCP-Datenverkehr an den Ports 29876 und 29877 von IP-Adressen des Batch-Diensts mit dem Diensttag „BatchNodeManagement.region“ Diese Regel wird nur im Poolkommunikationsmodus classic erstellt.
• Eingehender TCP-Datenverkehr an Port 22 (Linux-Knoten) oder Port 3389 (Windows-Knoten), um Remotezugriff für SSH bzw. RDP an Standardports zuzulassen. Für bestimmte Arten von Tasks mit mehreren Instanzen unter Linux (z. B. MPI) müssen Sie den SSH-Datenverkehr für IPs in dem Subnetz zulassen, das Batch-Serverknoten enthält. Bestimmte MPI-Runtimes erfordern möglicherweise das Starten über SSH, das in der Regel über den privaten IP-Adressraum weitergeleitet wird. Dieser Datenverkehr kann durch NSG-Regeln auf Subnetzebene blockiert werden.
• Ausgehender Datenverkehr an Port 443 zu IP-Adressen des Batch-Diensts mit dem Diensttag „BatchNodeManagement.region“
• Ausgehender Datenverkehr an allen Ports zum virtuellen Netzwerk Diese Regel kann pro NSG-Regeln auf Subnetzebene geändert werden.
• Ausgehender Datenverkehr an allen Ports zum Internet. Diese Regel kann pro NSG-Regeln auf Subnetzebene geändert werden.

Netzwerksicherheitsgruppen für Konfigurationspools für virtuelle Computer: Angeben von Regeln auf Subnetzebene

Wenn eine Ihrer NSGs dem Subnetz für Batch-Serverknoten zugeordnet ist, müssen Sie diese NSG mindestens mit den in den folgenden Tabellen gezeigten Eingangs- und Ausgangssicherheitsregeln konfigurieren.

Eingangssicherheitsregeln

Konfigurieren Sie eingehenden Datenverkehr am Port 3389 (Windows) bzw. Port 22 (Linux) nur, wenn Sie Remotezugriff auf die Serverknoten von externen Quellen aus auf RDP- oder SSH-Ports zulassen müssen. Möglicherweise müssen Sie SSH-Datenverkehr unter Linux zulassen, wenn Sie Unterstützung für Aufgaben mit mehreren Instanzen mit bestimmten MPI-Runtimes (Message Passing Interface) in dem Subnetz benötigen, das die Batch-Serverknoten enthält, da Datenverkehr möglicherweise mit NSG-Regeln auf Subnetzebene blockiert wird. MPI-Datenverkehr erfolgt in der Regel über den privaten IP-Adressraum, kann aber zwischen MPI-Runtimes und Laufzeitkonfiguration variieren. Das Zulassen von Datenverkehr an diesen Ports ist für die Verwendung der Poolserverknoten nicht zwingend erforderlich. Sie können auch den Standardremotezugriff auf diese Ports deaktivieren, indem Sie Poolendpunkte konfigurieren.

Ausgangssicherheitsregeln

Das Diensttag „BatchNodeManagement.region“ ist für ausgehenden Datenverkehr im classic-Poolkommunikationsmodus erforderlich, wenn Sie Auftrags-Manager-Tasks verwenden oder wenn die Tasks mit dem Batch-Dienst kommunizieren müssen. Für ausgehenden Datenverkehr an „BatchNodeManagement.region“ im simplified-Poolkommunikationsmodus verwendet der Batch-Dienst derzeit nur das TCP-Protokoll, zur Gewährleistung künftiger Kompatibilität ist jedoch möglicherweise UDP erforderlich. Für Pools ohne öffentliche IP-Adressen im Kommunikationsmodus simplified und mit einem privaten Endpunkt für die Knotenverwaltung ist keine NSG erforderlich. Weitere Informationen zu Ausgangssicherheitsregeln für das Diensttag „BatchNodeManagement.region“ finden Sie unter Verwenden der vereinfachten Kommunikation mit Serverknoten.

Erstellen eines Pools mit einem virtuellen Netzwerk im Azure-Portal

Nachdem Sie ein virtuelles Netzwerk erstellt und ihm ein Subnetz zugewiesen haben, können Sie einen Batch-Pool mit diesem virtuellen Netzwerk erstellen. Führen Sie die folgenden Schritte aus, um einen Pool im Azure-Portal zu erstellen:

1. Suchen Sie über die Suchleiste oben im Azure-Portal nach Batch-Konten, und wählen Sie den Eintrag aus. Wählen Sie Ihr Batch-Konto aus. Das Konto muss sich im gleichen Abonnement und der gleichen Region wie die Ressourcengruppe befinden, die das virtuelle Netzwerk enthält, das Sie verwenden möchten.

2. Wählen Sie Pools im linken Navigationsbereich aus.

3. Wählen Sie im Fenster Pools die Option Hinzufügen aus.

   

4. Wählen Sie auf der Seite Pool hinzufügen die Optionen aus, und geben Sie die Informationen für Ihren Pool ein. Weitere Informationen zum Erstellen von Pools für Ihr Batch-Konto finden Sie unter Erstellen eines Pools mit Computeknoten. Knotengröße, Ziel für dedizierte Knoten und Spot-Zielknoten/Zielknoten mit niedriger Priorität, sowie alle gewünschten optionalen Einstellungen.

5. Wählen Sie unter Virtuelles Netzwerk das virtuelle Netzwerk und Subnetz aus, die Sie verwenden möchten.

6. Klicken Sie auf OK, um Ihren Pool zu erstellen.

Benutzerdefinierte Routen für erzwungenes Tunneln

Ihr Unternehmen erfordert möglicherweise zu Überprüfungs- und Protokollierungszwecken das (erzwungene) Weiterleiten von Internetdatenverkehr vom Subnetz zurück zum lokalen Standort. Möglicherweise ist außerdem die Tunnelerzwingung für das Subnetz in Ihrem virtuellen Netzwerk aktiviert.

Um sicherzustellen, dass die Knoten im Pool in einem virtuellen Netzwerk funktionieren, in dem die Tunnelerzwingung aktiviert ist, müssen Sie folgende benutzerdefinierte Routen (User-Defined Routes, UDR) für dieses Subnetz hinzufügen.

Für Pools mit klassischem Kommunikationsmodus:

• Der Batch-Dienst muss für die zeitliche Planung von Tasks mit den Knoten kommunizieren. Um diese Kommunikation zu ermöglichen, fügen Sie eine UDR hinzu, die dem „BatchNodeManagement.region“-Diensttag in der Region entspricht, in der Ihr Batch-Konto existiert. Legen Sie den nächsten Hoptyp auf Internet fest.

• Stellen Sie sicher, dass Ihr lokales Netzwerk den ausgehenden TCP-Datenverkehr zu Azure Storage am Zielport 443 nicht blockiert (also URLs im Format *.table.core.windows.net, *.queue.core.windows.net und *.blob.core.windows.net).

Für Pools mit vereinfachtem Kommunikationsmodus ohne Verwendung des privaten Endpunkts für die Knotenverwaltung:

• Stellen Sie sicher, dass Ihr lokales Netzwerk den ausgehenden TCP-/UDP-Datenverkehr zum Azure Batch-Diensttag „BatchNodeManagement.region“ an Zielport 443 nicht blockiert. Derzeit wird nur das TCP-Protokoll verwendet, zur Gewährleistung künftiger Kompatibilität ist jedoch möglicherweise UDP erforderlich.

Für alle Pools:

• Wenn Sie virtuelle Dateieinbindung verwenden, überprüfen Sie die Netzwerkanforderungen, und stellen Sie sicher, dass kein erforderlicher Datenverkehr blockiert ist.

Nächste Schritte

• Workflow und Ressourcen des Batch-Diensts
• Tutorial: Weiterleiten von Netzwerkdatenverkehr mithilfe des Azure-Portals