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-Batchpools. Dies ist die Standardeinstellung für docker bridge network und kann mit anderen Netzwerken in Konflikt stehen, die Sie mit dem VNet verbinden möchten. Das Erstellen eines virtuellen Netzwerks für azure Batchpool 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- undtargetLowPriorityNodes-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.netund<account>.blob.core.windows.netmü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.
Andere Anforderungen an virtuelle Netzwerke unterscheiden sich, je nachdem, ob sich der Batch-Pool in VirtualMachineConfiguration oder CloudServiceConfiguration befindet. VirtualMachineConfiguration für Batch-Pools wird empfohlen, da CloudServiceConfiguration-Pools veraltet sind.
Wichtig
Batch-Pools können in einem von zwei Knotenkommunikationsmodi konfiguriert werden. Im klassischen Knotenkommunikationsmodus initiiert der Batch-Dienst die Kommunikation mit den Serverknoten. Beim vereinfachten Knotenkommunikationsmodus initiieren die Serverknoten die Kommunikation mit dem Batch-Knoten.
- Jedes virtuelle Netzwerk oder peered virtuelle Netzwerk, das für Batchpools verwendet wird, sollte keine überlappenden IP-Adressbereiche mit softwaredefinierten Netzwerken oder Routing auf Computeknoten aufweisen. Eine häufige Quelle für Konflikte 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 Standard-IP-Adressraum ausgeführt werden, stehen in Konflikt mit Diensten auf dem Computeknoten, z. B. 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.
Wichtig
Dabei erstellt Batch pro 100 dedizierten Knoten oder Knoten mit niedriger Priorität jeweils eine Netzwerksicherheitsgruppe (NSG), eine öffentliche IP-Adresse und einen Lastenausgleich. Diese Ressourcen werden durch die Ressourcenkontingente des Abonnements beschränkt. Bei umfangreichen Pools muss ggf. eine Kontingenterhöhung für eine oder mehrere der Ressourcen angefordert werden.
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
classicerstellt. - 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.
Wichtig
Seien Sie vorsichtig, wenn Sie Eingangs- und Ausgangsregeln in von Batch konfigurierten NSGs ändern. Falls die Kommunikation mit den Computeknoten im angegebenen Subnetz durch eine Netzwerksicherheitsgruppe (NSG) verhindert wird, legt der Batch-Dienst den Zustand der Computeknoten auf Nicht verwendbar fest. Darüber hinaus dürfen keine Ressourcensperren auf von Batch erstellte Ressourcen angewendet werden, da sonst möglicherweise die Bereinigung von Ressourcen infolge der vom Benutzer initiierten Aktionen (etwa Löschen eines Pools) verhindert wird.
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.
Warnung
IP-Adressen des Batch-Diensts können sich im Laufe der Zeit ändern. Daher sollten Sie das Diensttag „BatchNodeManagement.region“ für die NSG-Regeln, die in den folgenden Tabellen aufgeführt sind, verwenden. Vermeiden Sie das Auffüllen von NSG-Regeln mit bestimmten Batch-Dienst-IP-Adressen.
Eingangssicherheitsregeln
| Quelldiensttag oder IP-Adressen | Zielports | Protocol | Poolkommunikationsmodus | Erforderlich |
|---|---|---|---|---|
| „BatchNodeManagement.region“-Diensttag | 29876–29877 | TCP | Klassisch | Ja |
| Quell-IP-Adressen für den Remotezugriff auf Serverknoten | 3389 (Windows), 22 (Linux) | TCP | Klassisch oder vereinfacht | Nein |
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
| Zieldiensttag | Zielports | Protocol | Poolkommunikationsmodus | Erforderlich |
|---|---|---|---|---|
| „BatchNodeManagement.region“-Diensttag | 443 | * | Vereinfacht | Ja |
| „Storage.region“-Diensttag | 443 | TCP | Klassisch | Ja |
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.
Pools in der Cloud Services-Konfiguration
Warnung
Cloud Services-Konfigurationspools sind veraltet. Verwenden Sie stattdessen VM-Konfigurationspools.
Anforderungen:
Unterstützte virtuelle Netzwerke: Nur klassische 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.ClassicNetwork/virtualNetworks/{network}/subnets/{subnet}Berechtigungen: Der Dienstprinzipal „
Microsoft Azure Batch“ muss für das angegebene virtuelle Netzwerk über die Azure-Rolle „Classic Virtual Machine Contributor“ verfügen.
Netzwerksicherheitsgruppen für Cloud Services-Konfigurationspools
Das Subnetz muss eingehende Kommunikation des Batch-Diensts zulassen, um Aufgaben auf den Computeknoten planen zu können, und ausgehende Kommunikation, um mit Azure Storage und anderen Ressourcen kommunizieren zu können.
Sie müssen keine NSG angeben, da Batch nur eingehende Kommunikation von Batch-IP-Adressen an die Poolknoten konfiguriert. Wenn das angegebene Subnetz allerdings über zugewiesene NSGs und/oder eine Firewall verfügt, konfigurieren Sie die Eingangs- und Ausgangssicherheitsregeln gemäß den folgenden Tabellen. Falls die Kommunikation mit den Computeknoten im angegebenen Subnetz durch eine Netzwerksicherheitsgruppe (NSG) verhindert wird, legt der Batch-Dienst den Zustand der Computeknoten auf Nicht verwendbar fest.
Konfigurieren Sie eingehenden Datenverkehr am Port 3389 für Windows, wenn Sie RDP-Zugriff auf die Poolknoten zulassen müssen. Diese Regel ist für die Nutzung der Poolknoten nicht erforderlich.
Eingangssicherheitsregeln
| Quell-IP-Adressen | Quellports | Destination | Zielports | Protocol | Aktion |
|---|---|---|---|---|---|
| Any Für diese Regel ist zwar im Grunde die Zulassung aller IP-Adressen erforderlich, der Batch-Dienst wendet jedoch auf der Ebene jedes Knotens eine ACL-Regel an, die alle nicht vom Batch-Dienst stammenden IP-Adressen herausfiltert. |
* | Beliebig | 10100, 20100, 30100 | TCP | Allow |
| Optional, um RDP-Zugriff auf Computeknoten zu ermöglichen. | * | Any | 3389 | TCP | Allow |
Ausgangssicherheitsregeln
| `Source` | Quellports | Destination | Zielports | Protocol | Aktion |
|---|---|---|---|---|---|
| Any | * | Any | 443 | Any | Allow |
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:
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.
Wählen Sie Pools im linken Navigationsbereich aus.
Wählen Sie im Fenster Pools die Option Hinzufügen aus.
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.
Wählen Sie unter Virtuelles Netzwerk das virtuelle Netzwerk und Subnetz aus, die Sie verwenden möchten.
Klicken Sie auf OK, um Ihren Pool zu erstellen.
Wichtig
Wenn Sie versuchen, ein Subnetz zu löschen, das von einem Pool verwendet wird, erhalten Sie eine Fehlermeldung. Alle Pools, die ein Subnetz verwenden, müssen gelöscht werden, bevor Sie dieses Subnetz löschen.
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.netund*.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.
Warnung
IP-Adressen des Batch-Diensts können sich im Laufe der Zeit ändern. Geben Sie IP-Adressen nicht direkt an, um Ausfälle aufgrund von Änderungen der IP-Adresse des Batch-Diensts zu vermeiden. Verwenden Sie stattdessen das „BatchNodeManagement.region“-Diensttag.