Créer un pool Azure Batch dans un réseau virtuel

Quand vous créez un pool Azure Batch, vous pouvez provisionner le pool sur un sous-réseau d’un réseau virtuel Azure que vous spécifiez. Cet article explique comment configurer un pool Batch dans un réseau virtuel.

Pourquoi utiliser un réseau virtuel ?

Les nœuds de calcul d’un pool peuvent communiquer entre eux, par exemple pour exécuter des tâches multi-instances, sans exiger de réseau virtuel. Toutefois, par défaut, les nœuds d’un pool ne peuvent pas communiquer avec les machines virtuelles (VM) se trouvant en dehors du pool, telles que les serveurs de licences ou de fichiers.

Pour autoriser les nœuds de calcul à communiquer de façon sécurisée avec d’autres machines virtuelles, ou avec un réseau local, vous pouvez configurer le pool dans un sous-réseau d’un réseau virtuel.

Prérequis

• Authentification. Pour utiliser un réseau virtuel Azure, l’API du client Batch doit utiliser l’authentification Microsoft Entra. Pour plus d’informations, consultez Authentifier des solutions de service Batch avec Active Directory.

• Un réseau virtuel Azure. Pour préparer un réseau virtuel avec un ou plusieurs sous-réseaux à l’avance, vous pouvez utiliser le portail Azure, Azure PowerShell, Microsoft Azure CLI (CLI) ou d’autres méthodes.

  • Pour créer un réseau virtuel basé sur Azure Resource Manager, consultez Créer un réseau virtuel. Pour les nouveaux déploiements, il est recommandé d’utiliser un réseau virtuel Resource Manager. Celui-ci est pris en charge uniquement par les pools qui utilisent la configuration Machine virtuelle.

  • Pour créer un réseau virtuel classique, consultez Créer un réseau virtuel (Classic) comprenant plusieurs sous-réseaux. Le réseau virtuel Classic est pris en charge uniquement par les pools qui utilisent la configuration Services cloud.

    Important

    Évitez d’utiliser 172.17.0.0/16 pour le réseau virtuel du pool Azure Batch. Il s’agit de la valeur par défaut du réseau de pont Docker et peut entrer en conflit avec d’autres réseaux que vous souhaitez connecter au réseau virtuel. La création d’un réseau virtuel pour un pool Azure Batch nécessite une planification minutieuse de votre infrastructure réseau.

Conditions requises du réseau virtuel

• Le réseau virtuel doit se trouver dans la même région et le même abonnement que le compte Batch utilisé pour créer le pool.

• Le sous-réseau spécifié pour le pool doit avoir suffisamment d’adresses IP non attribuées pour contenir le nombre de machines virtuelles ciblées pour le pool, suffisamment pour accueillir les propriétés targetDedicatedNodes et targetLowPriorityNodes du pool. Si le sous-réseau ne dispose pas de suffisamment d’adresses IP non attribuées, le pool alloue partiellement les nœuds de calcul, et une erreur de redimensionnement se produit.

• Si vous n’utilisez pas la communication de nœud de calcul simplifiée, les points de terminaison de stockage Azure doivent être résolus par tous les serveurs DNS personnalisés qui servent votre réseau virtuel. Plus précisément, les URL sous la forme <account>.table.core.windows.net, <account>.queue.core.windows.net et <account>.blob.core.windows.net doivent être résolvables.

• Vous pouvez créer plusieurs pools dans le même réseau virtuel ou dans le même sous-réseau (à condition qu’il dispose de suffisamment d’espace d’adressage). Un même pool ne peut pas exister dans plusieurs réseaux virtuels ou sous-réseaux.

• Tout réseau virtuel ou réseau virtuel appairé qui sera utilisé pour les pools Batch ne doit pas avoir de plages d’adresses IP qui se chevauchent avec la mise en réseau ou le routage défini par logiciel sur les nœuds de calcul. Une source courante pour les conflits provient de l’utilisation d’un runtime de conteneur, comme Docker. Docker crée un pont réseau par défaut avec une plage de sous-réseaux définie de 172.17.0.0/16. Tous les services exécutés dans un réseau virtuel dans cet espace d’adressage IP par défaut sont en conflit avec les services sur le nœud de calcul, tels que l’accès à distance via SSH.

Pools dans la configuration de la machine virtuelle

Conditions requises :

• Réseaux virtuels pris en charge : réseaux virtuels Azure Resource Manager uniquement.
• ID de sous-réseau : lorsque vous spécifiez le sous-réseau à l’aide de l’API Batch, utilisez l’identificateur de ressource du sous-réseau. L’identificateur du sous-réseau est au format :

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

• Autorisations : vérifiez si vos stratégies ou verrous de sécurité sur l’abonnement ou le groupe de ressources du réseau virtuel restreignent les autorisations pour gérer le réseau virtuel.
• Ressources de mise en réseau : Batch crée automatiquement des ressources de mise en réseau dans le groupe de ressources contenant le réseau virtuel.

Groupes de sécurité réseau pour les pools de configuration de machines virtuelles : Batch par défaut

Batch crée un groupe de sécurité réseau (NSG) au niveau de l’interface réseau de chaque déploiement de groupe de machines virtuelles identiques au sein d’un pool Batch. Pour les pools qui n’ont pas d’adresses IP publiques sous communication de nœud de calcul simplified, les groupes de sécurité réseau ne sont pas créés.

Pour fournir la communication nécessaire entre les nœuds de calcul et le service Batch, ces groupes de sécurité réseau sont configurés de manière à :

• Le trafic TCP entrant sur les ports 29876 et 29877 à partir d’adresses IP de service Batch qui correspondent à l’étiquette de service BatchNodeManagement.region. Cette règle est créée uniquement en mode de communication de poolclassic.
• Trafic TCP entrant sur le port 22 (nœuds Linux) ou le port 3389 (nœuds Windows) pour autoriser l’accès à distance pour SSH ou RDP sur des ports par défaut, respectivement. Pour certains types de tâches multi-instances sur Linux (par exemple, MPI), vous devez également autoriser le trafic SSH pour les adresses IP dans le sous-réseau contenant des nœuds de calcul Batch. Certains runtimes MPI peuvent nécessiter un lancement via SSH, qui est généralement routé sur l’espace d’adressage IP privé. Ce trafic peut être bloqué par des règles de groupe de sécurité réseau au niveau du sous-réseau.
• Sortant tout trafic sur le port 443 vers les adresses IP du service Batch qui correspondent à la balise de service BatchNodeManagement.region .
• Le trafic sortant sur n’importe quel port vers le réseau virtuel. Cette règle peut être modifiée par des règles de groupe de sécurité réseau au niveau du sous-réseau.
• Le trafic sortant sur n’importe quel port vers internet. Cette règle peut être modifiée par des règles de groupe de sécurité réseau au niveau du sous-réseau.

Groupes de sécurité réseau pour les pools de configuration de machines virtuelles : spécification de règles au niveau du sous-réseau

Si vous avez un NSG associé au sous-réseau pour les nœuds de calcul par lots, vous devez configurer ce NSG avec au moins les règles de sécurité entrantes et sortantes qui sont présentées dans les tableaux suivants.

Règles de sécurité de trafic entrant

Configurez le trafic entrant sur le port 3389 (Windows) ou 22 (Linux) uniquement si vous avez besoin d’autoriser l’accès à distance aux nœuds de calcul à partir de sources externes sur des ports RDP ou SSH par défaut, respectivement. Il est possible que vous deviez autoriser le trafic SSH sur Linux si vous avez besoin d’une prise en charge des tâches multi-instances avec certains runtimes d’interface de passage de messages (MPI) dans le sous-réseau contenant les nœuds de calcul Batch, car le trafic peut être bloqué par des règles de groupe de sécurité réseau au niveau du sous-réseau. Le trafic MPI se trouve généralement sur un espace d’adressage IP privé, mais il peut varier entre les runtimes MPI et la configuration du runtime. Toutefois, le fait d’autoriser le trafic sur ces ports n’est pas strictement nécessaire pour que les nœuds de calcul du pool soient utilisables. Vous pouvez également désactiver l’accès à distance par défaut sur ces ports en configurant des points de terminaison de pool.

Règles de sécurité de trafic entrant

Le trafic sortant vers l’étiquette de service BatchNodeManagement.region est requise en mode de communication du pool classic si vous utilisez des tâches du Manager de tâches ou si vos tâches doivent communiquer de nouveau avec le service Batch. Pour le trafic sortant vers BatchNodeManagement.region en mode de communication du poolsimplified, le service Batch utilise actuellement uniquement le protocole TCP, mais UDP peut être requis pour la compatibilité future. Pour les pools sans adresses IP publiques utilisant le mode de communication simplified et avec un point de terminaison privé de gestion des nœuds, un groupe de sécurité réseau n’est pas nécessaire. Pour plus d’informations sur les règles de sécurité sortantes pour la balise de service BatchNodeManagement.region, consultez Utiliser une communication simplifiée de nœud de calcul.

Créer un pool avec un Réseau virtuel dans le Portail Azure

Une fois que vous avez créé un réseau virtuel auquel vous avez affecté un sous-réseau, vous pouvez créer un pool Batch avec ce réseau virtuel. Suivez ces étapes pour créer un pool à partir du portail Azure :

1. Recherchez et sélectionnez Comptes Batch dans la barre de recherche en haut du Portail Azure. Sélectionnez votre compte Batch. Ce compte doit relever du même abonnement et de la même région que le groupe de ressources contenant le réseau virtuel que vous envisagez d’utiliser.

2. Sélectionnez Pools dans le volet de navigation de gauche.

3. Dans la fenêtre Pools, sélectionnez Ajouter.

   

4. Dans la page Ajouter un pool, sélectionnez les options et entrez les informations relatives à votre pool. Pour plus d’informations sur la création de pools pour votre compte Batch, consultez Créer un pool de nœuds de calcul. Taille de nœud, Nœuds dédiés cibles et Nœuds spot/basse priorité cibles et tous les paramètres facultatifs souhaités.

5. Dans Réseau virtuel, sélectionnez le réseau virtuel et le sous-réseau que vous souhaitez utiliser.

6. Sélectionnez OK pour créer votre pool.

Routages définis par l’utilisateur pour le tunneling forcé

Votre organisation vous oblige peut-être à rediriger (forcer) le trafic Internet provenant du sous-réseau vers votre emplacement local à des fins d’inspection et de journalisation. En outre, vous avez peut-être activé le tunneling forcé pour les sous-réseaux de votre réseau virtuel.

Pour vérifier que les nœuds de votre pool fonctionnent dans un réseau virtuel pour lequel le tunneling forcé a été activé, vous devez ajouter les routages définis par l’utilisateur (UDR) suivants pour ce sous-réseau.

Pour les pools de modes de communication classiques :

• Le service Batch doit communiquer avec les nœuds pour la planification des tâches. Pour activer cette communication, ajoutez un UDR correspondant à la balise de service BatchNodeManagement.region dans la région où votre compte Batch existe. Définissez le type de tronçon suivant sur Internet.

• Vérifiez que le trafic TCP sortant à destination du service Stockage Azure (plus précisément, les URL sous la forme *.table.core.windows.net, *.queue.core.windows.net et *.blob.core.windows.net) n'est pas bloqué par votre réseau local sur le port de destination 443.

Pour des pools en mode de communication simplifiés sans utiliser de point de terminaison privé de gestion des nœuds :

• Assurez-vous que le trafic TCP/UDP sortant à destination de l’étiquette de service Azure Batch BatchNodeManagement.region n'est pas bloqué par votre réseau local sur le port de destination 443. Actuellement, seul le protocole TCP est utilisé, mais UDP peut être requis pour la compatibilité future.

Pour tous les pools :

• Si vous utilisez des montages de fichiers virtuels, passez en revue les impératifs réseau, et vérifiez qu’aucun trafic nécessaire n’est bloqué.

Étapes suivantes

• Flux de travail et ressources du service Batch
• Tutoriel : Acheminer le trafic réseau avec une table de routage à l’aide du portail Azure