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. Dies ist die Standardeinstellung für docker bridge network und kann mit anderen Netzwerken in Konflikt treten, 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 genügend nicht zugewiesene IP-Adressen verfügt, weist der Pool die Rechenknoten nur teilweise zu, und es tritt ein Fehler bei der Größenänderung 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 gekoppelte virtuelle Netzwerk, das für Batch-Pools verwendet wird, sollte keine überlappenden IP-Adressbereiche mit dem softwaredefinierten Netzwerkbetrieb oder dem Routing auf Computeknoten aufweisen. Eine häufige Quelle von Konflikten stammt aus der Verwendung einer Containerlaufzeit, z. B. 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 Computeknoten und dem Batchdienst bereitzustellen, werden diese NSGs so konfiguriert, dass:

• Eingehender TCP-Datenverkehr an den Ports 29876 und 29877 von IP-Adressen des Batch-Diensts, die dem Diensttag „BatchNodeManagement.region“ entsprechen. Diese Regel wird nur im Poolkommunikationsmodus classic erstellt.
• Jeglichen ausgehenden Datenverkehr über Port 443 zu den IP-Adressen des Batch-Diensts zulassen, die dem Diensttag „BatchNodeManagement.region“ entsprechen.
• Ausgehender Datenverkehr an allen Ports zum virtuellen Netzwerk Diese Regel kann gemäß den NSG-Regeln auf Subnetzebene geändert werden.
• Ausgehender Datenverkehr an allen Ports zum Internet. Diese Regel kann gemäß den 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.

Sicherheitsregeln für eingehenden Datenverkehr

Konfigurieren Sie eingehenden Datenverkehr über Port 3389 (Windows) bzw. 22 (Linux) nur, wenn Sie Remotezugriff auf die Rechenknoten aus externen Quellen über die standardmäßigen RDP- bzw. 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 über diese Ports ist nicht zwingend erforderlich, damit die Computeknoten des Pools verwendet werden können. Sie können auch den Standardremotezugriff auf diese Ports deaktivieren, indem Sie Poolendpunkte konfigurieren.

Ausgehende Sicherheitsregeln

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 in der Suchleiste oben im Azure-Portal nach Batch-Konten, und wählen Sie sie 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, Zielanzahl dedizierter Knoten und Zielanzahl von Spot-/Niedrigprioritätsknoten 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. Außerdem haben Sie möglicherweise erzwungenes Tunneling für die Subnetze 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 Diensttag „BatchNodeManagement.regionservice tag“ in der Region entspricht, in der sich Ihr Batch-Konto befindet. Legen Sie den Typ des nächsten Hops 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 On-Premises-Netzwerk den ausgehenden TCP-/UDP-Datenverkehr für das Azure Batch-Diensttag „BatchNodeManagement.region“ über den 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: Netzwerkdatenverkehr mithilfe einer Routingtabelle über das Azure-Portal weiterleiten