Meilleures pratiques relatives à Azure Batch

Cet article présente les bonnes pratiques et des conseils utiles pour utiliser le service Azure Batch de manière efficace. Ces conseils peuvent vous aider à améliorer les performances et à éviter les pièges de conception dans vos solutions Batch.

Pools

Les pools sont les ressources de calcul pour l’exécution de travaux sur le service Batch. Les sections suivantes fournissent des recommandations sur l’utilisation des pools Batch.

Configuration et dénomination de pools

• Mode d’allocation de pool : lorsque vous créez un compte Batch, vous pouvez choisir entre deux modes d’allocation de pool : service Batch ou abonnement utilisateur. Dans la plupart des cas, vous devez utiliser le mode de service Batch par défaut. Les pools sont alloués en arrière-plan dans des abonnements managés par Azure Batch. Dans l’autre mode d’abonnement utilisateur, les machines virtuelles Batch et les autres ressources sont créées directement dans l’abonnement lors de la création d’un pool. Les comptes d’abonnement utilisateur sont principalement utilisés pour permettre un petit sous-ensemble important de scénarios. Pour plus d’informations, voir Configuration pour le mode d’abonnement utilisateur.

• Mode de communication de nœud classic ou simplified : les pools peuvent être configurés dans l’un des deux modes de communication de nœud, classique ou simplifié. Dans le modèle de communication de nœud classique, le service Batch lance la communication avec les nœuds de calcul, et ces derniers nécessitent également la communication avec Stockage Azure. Dans le modèle de communication de nœud simplifié, les nœuds de calcul lancent la communication avec le service Batch. Étant donné que l’étendue des connexions entrantes/sortantes requises est réduite et qu’aucun accès sortant Stockage Azure n’est nécessaire pour l’opération de base, nous vous recommandons d’utiliser le modèle de communication de nœud simplifié. Certaines améliorations futures du service Batch nécessiteront également le modèle de communication de nœud simplifié. Le modèle classique de communication entre les nœuds sera mis hors service le 31 mars 2026.

• Considérations en matière de durée d’exécution des travaux et des tâches : Si vous avez des travaux constitués principalement de tâches de courte durée et que le nombre total de tâches attendu est faible, de sorte que le temps d’exécution global prévu du travail n’est pas long, n’allouez pas de nouveau pool pour chaque travail. Le temps de répartition des nœuds diminuera le temps d’exécution du travail.

• Plusieurs nœuds de calcul : Il n’est pas garanti que les nœuds individuels soient toujours disponibles. Bien que rares, les défaillances matérielles, les mises à jour du système d’exploitation et une foule d’autres problèmes peuvent entraîner la déconnexion de nœuds individuels. Si votre charge de travail Batch requiert une progression déterministe et garantie, vous devez allouer des pools avec plusieurs nœuds.

• Images avec des dates de fin de vie (EOL) imminentes : Il est fortement recommandé d’éviter les images dont les dates de fin de vie (EOL) de la prise en charge de Batch sont imminentes. Vous pouvez découvrir ces dates via l’ListSupportedImagesAPI , PowerShell ou Azure CLI. Il vous incombe d’actualiser régulièrement votre affichage des dates de fin de vie pertinentes pour vos pools, et de migrer vos charges de travail avant la date de fin de vie. Si vous utilisez une image personnalisée avec un agent de nœud spécifié, veillez à suivre les dates de fin de vie de prise en charge de Batch pour l’image pour laquelle votre image personnalisée est dérivée ou avec laquelle elle est alignée. Une image sans date spécifiée batchSupportEndOfLife indique qu’une telle date n’a pas encore été déterminée par le service Batch. L’absence d’une date n’indique pas que l’image respective sera prise en charge indéfiniment. Une date de fin de vie peut être ajoutée ou mise à jour à l’avenir à tout moment.

• Références SKU de machine virtuelle avec des dates de fin de vie (EOL) imminentes : Comme avec les images de machine virtuelle, les références SKU de machine virtuelle ou les familles peuvent également atteindre la fin de vie du support Batch (EOL). Vous pouvez découvrir ces dates via l’ListSupportedVirtualMachineSkusAPI , PowerShell ou Azure CLI. Planifiez la migration de votre charge de travail vers une référence SKU de machine virtuelle non-EOL en créant un pool avec une référence SKU de machine virtuelle prise en charge appropriée. L’absence d’une date batchSupportEndOfLife associée pour une référence SKU de machine virtuelle n’indique pas que la référence SKU de machine virtuelle particulière sera prise en charge indéfiniment. Une date de fin de vie peut être ajoutée ou mise à jour à l’avenir à tout moment.

• Noms de ressources uniques : Les ressources Batch (travaux, pools, etc.) vont et viennent souvent au fil du temps. Par exemple, vous pouvez créer un pool le lundi, le supprimer le mardi, puis créer un autre pool similaire le jeudi. Chaque nouvelle ressource que vous créez doit avoir un nom unique que vous n’avez pas utilisé auparavant. Vous pouvez créer de l'unicité en utilisant un GUID (comme nom complet de la ressource ou comme partie de celui-ci) ou incorporant l’heure et la date de création de la ressource dans son nom. Batch prend en charge DisplayName, ce qui permet de donner un nom lisible à une ressource, même si l’ID réel de la ressource est un nom qui n’est pas convivial. L’utilisation de noms uniques facilite la différenciation des ressources particulières dans les journaux et les métriques. Cela élimine également toute ambiguïté si vous devez créer une demande de support pour une ressource.

• Continuité pendant la maintenance et la défaillance des pools : il est préférable que vos travaux utilisent des pools de manière dynamique. Si vos travaux utilisent le même pool pour tout, il y a une chance que les travaux ne soient pas exécutés en cas de problème avec le pool. Ce principe est particulièrement important pour les charges de travail urgentes. Par exemple, sélectionnez ou créez un pool de manière dynamique lorsque vous planifiez chaque travail, ou disposez d’un moyen de substituer le nom du pool pour pouvoir ignorer un pool non sain.

• Continuité de l’activité pendant la maintenance et la défaillance des pools : Il existe de nombreuses raisons pour lesquelles un pool ne peut pas croître jusqu’à la taille souhaitée, telles que des erreurs internes ou des contraintes de capacité. Veillez à recibler des travaux dans un autre pool (éventuellement avec une taille de machine virtuelle différente avec UpdateJob) le cas échéant. Évitez d’utiliser un ID de pool statique en pensant qu’il ne sera jamais supprimé et jamais modifié.

Sécurité du pool

Limite d’isolation

À des fins d’isolation, si votre scénario nécessite l’isolation des travaux ou des tâches les uns des autres, isolez-les en les plaçant dans des pools distincts. Un pool est la limite d’isolation de sécurité dans Batch et, par défaut, deux pools ne sont pas visibles l’un par l’autre ni en mesure de communiquer entre eux. Évitez d’utiliser des comptes Batch distincts comme moyen d’isolation de sécurité, sauf si l’environnement plus grand à partir duquel le compte Batch fonctionne dans une isolation requise.

Mises à jour de l’agent de nœud Batch

Les agents de nœud Batch ne sont pas automatiquement mis à niveau pour les pools qui ont des nœuds de calcul différent de zéro. Pour vous assurer que vos pools Batch reçoivent les derniers correctifs de sécurité et mises à jour de l’agent de nœud Batch, vous devez redimensionner le pool en zéro nœuds de calcul ou recréer le pool. Il est recommandé de surveiller les notes de publication de l’Agent de nœud Batch pour comprendre les modifications apportées aux nouvelles versions de l’agent de nœud Batch. La vérification régulière des mises à jour lors de leur publication vous permet de planifier les mises à niveau vers la dernière version de l’agent.

Avant de recréer ou de redimensionner votre pool, vous devez télécharger les journaux d’activité de l’agent de nœud à des fins de débogage si vous rencontrez des problèmes avec votre pool Batch ou vos nœuds de calcul. Ce processus est décrit plus en détail dans la section Nœuds.

Mises à jour de système d’exploitation

Il est recommandé que l’image de machine virtuelle sélectionnée pour un pool Batch soit à jour avec les dernières mises à jour de sécurité fournies par l’éditeur. Certaines images peuvent effectuer des mises à jour automatiques de packages au démarrage (ou peu après), ce qui peut interférer avec certaines actions dirigées par l’utilisateur, telles que la récupération des mises à jour du référentiel de packages (par exemple, apt update) ou l’installation de packages pendant des actions telles qu’une tâche StartTask.

Il est recommandé d’activer la Mise à niveau automatique du système d’exploitation des pools Batch, ce qui permet à l’infrastructure Azure sous-jacente de coordonner les mises à jour sur le pool. Cette option peut être configurée pour ne pas perturber l’exécution des tâches. La mise à niveau automatique du système d’exploitation ne prend pas en charge tous les systèmes d’exploitation pris en charge par Batch. Pour plus d’informations, consultez la Matrice de support de la mise à niveau automatique des systèmes d'exploitation des groupes de machines virtuelles identiques. Pour les systèmes d’exploitation Windows, vérifiez que vous n’activez pas la propriété virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates lors de l’utilisation de la mise à niveau automatique du système d’exploitation sur le pool Batch.

Azure Batch ne vérifie ni ne garantit que les images autorisées à être utilisées avec le service disposent des dernières mises à jour de sécurité. Les mises à jour des images sont sous la compétence de l’éditeur de l’image, et non celle d’Azure Batch. Pour certaines images publiées sous microsoft-azure-batch, il n’existe aucune garantie que ces images sont maintenues à jour avec leur image dérivée en amont.

Durée de vie et facturation d’un pool

La durée de vie d’un pool peut varier en fonction de la méthode de répartition et des options appliquées à la configuration du pool. À tout moment, les pools peuvent avoir une durée de vie arbitraire et un nombre variable de nœuds de calcul. Il vous incombe de gérer les nœuds de calcul dans le pool, soit explicitement, soit par le biais de fonctionnalités fournies par le service (mise à l’échelle automatique ou pool automatique).

• Recréation de pool : Dans le même ordre d’idées, évitez de supprimer et de recréer des pools quotidiennement. Au lieu de cela, créez un pool, puis mettez à jour vos travaux existants pour qu’ils pointent vers le nouveau pool. Une fois que toutes les tâches ont été déplacées vers le nouveau pool, supprimez l’ancien pool.

• Efficacité et facturation du pool : Batch lui-même n’entraîne aucun frais supplémentaire. Cependant, vous devez payer les ressources Azure utilisées, telles que le calcul, le stockage, la mise en réseau et toute autre ressource pouvant être requise pour votre charge de travail Batch. Vous êtes facturé pour chaque nœud de calcul dans le pool, quel que soit l’état dans lequel il se trouve. Pour plus d’informations, consultez Analyse des coûts et budgets pour Azure Batch.

• Disques de système d’exploitation éphémères : Les pools de configuration de machines virtuelles peuvent utiliser des disques de système d’exploitation éphémères, qui créent le disque de système d’exploitation sur le cache de la machine virtuelle ou sur un SSD temporaire, afin d’éviter les coûts supplémentaires associés aux disques managés.

Échecs de répartition de pool

Les échecs de répartition de pool peuvent se produire à tout moment pendant la première répartition ou lors de redimensionnements ultérieurs. Ces échecs peuvent être dus à un épuisement temporaire de la capacité dans une région ou à des défaillances dans d’autres services Azure sur lesquels Batch s’appuie. Votre quota de base n’est pas une garantie, mais plutôt une limite.

Temps d’arrêt non planifié

Il est possible que les pools Batch rencontrent des événements de temps d’arrêt dans Azure. Comprenez que des problèmes peuvent survenir et vous devez développer votre flux de travail pour qu’il soit résilient aux ré-exécutions. Si des nœuds échouent, Batch tente automatiquement de récupérer ces nœuds de calcul en votre nom. Cette récupération peut déclencher le rééchelonnement de toute tâche en cours d’exécution sur le nœud restauré ou sur un autre nœud disponible. Pour en savoir plus sur les tâches interrompues, consultez Conception des nouvelles tentatives.

Pools d’images personnalisés

Quand vous créez un pool Azure Batch à l’aide de Configuration de la machine virtuelle, vous spécifiez une image de machine virtuelle qui fournit le système d’exploitation pour chaque nœud de calcul dans le pool. Vous pouvez créer le pool en utilisant une image prise en charge de la Place de Marché Azure ou en créant une image personnalisée avec une image Azure Compute Gallery. Bien que vous puissiez également utiliser une image managée pour créer un pool d’images personnalisé, nous vous recommandons de créer des images personnalisées à l’aide de la galerie Azure Compute Gallery chaque fois que c’est possible. La galerie Azure Compute Gallery permet d’approvisionner des pools plus rapidement, de mettre à l’échelle de grandes quantités de machines virtuelles et d’améliorer la fiabilité lors de l’approvisionnement de machines virtuelles.

Images tierces

Les pools peuvent être créés à l’aide d’images tierces publiées sur Place de marché Azure. Avec les comptes Batch en mode d’abonnement utilisateur, vous pouvez voir l’erreur « Échec d’allocation en raison de la vérification de l’éligibilité d’achat sur le marketplace » lors de la création d’un pool avec certaines images tierces. Pour résoudre cette erreur, acceptez les conditions définies par l’éditeur de l’image. Vous pouvez le faire en utilisant Azure PowerShell ou Azure CLI.

Pools de conteneurs

Lorsque vous créez un pool Batch avec un réseau virtuel, il peut y avoir des effets secondaires d’interaction entre le réseau virtuel spécifié et le pont Docker par défaut. Par défaut, Docker crée un pont réseau avec une spécification de sous-réseau de 172.17.0.0/16. Assurez-vous qu’il n’y a pas de conflit de plages IP entre le pont réseau Docker et votre réseau virtuel.

Docker Hub limite le nombre de tirages d’images. Vérifiez que votre charge de travail ne dépasse pas les limites de débit publiées pour les images Docker Hub. Il est recommandé d’utiliser Azure Container Registry directement ou tirer parti du cache d’artefacts dans ACR.

Dépendance de région Azure

Vous ne devriez pas dépendre d’une seule région Azure si vous avez une charge de travail de production ou soumise à une contrainte de temps. Bien que rare, il existe des problèmes qui peuvent perturber une région entière. Par exemple, si votre traitement doit démarrer à un moment donné, envisagez d’augmenter l’échelle du pool dans votre région primaire bien avant votre heure de début. Si cette mise à l’échelle du pool échoue, vous pouvez vous replier sur l’augmentation de l’échelle d’un pool dans une ou plusieurs régions de sauvegarde.

Les pools sur plusieurs comptes et dans différentes régions fournissent une sauvegarde prête et facilement accessible en cas de problème avec un autre pool. Pour plus d’informations, consultez Conception de votre application pour une haute disponibilité.

travaux

Une tâche est un conteneur conçu pour contenir des centaines, des milliers, voire des millions de tâches. Suivez ces recommandations pendant la création des travaux.

Moins de travaux, plus de tâches

L’utilisation d’un travail pour exécuter une seule tâche est inefficace. Par exemple, il est plus efficace d’utiliser un seul travail contenant 1 000 tâches plutôt que de créer 100 travaux qui contiennent 10 tâches chacun. Si vous utilisiez 1 000 tâches, chacune d’entre elles étant unique, ce serait l’approche la moins efficace, la plus lente et la plus coûteuse à adopter.

Évitez de concevoir une solution Batch qui nécessite des milliers de travaux actifs simultanément. Étant donné qu’il n’existe aucun quota pour les tâches, l’exécution d’autant de tâches que possible sous le moins de travaux possible utilise efficacement vos quotas de travail et de planification de travail.

Durée de vie du travail

Un travail Batch a une durée de vie illimitée jusqu’à ce qu’il soit supprimé du système. Son état indique s’il peut ou non accepter des tâches supplémentaires pour la planification.

Un travail ne passe pas automatiquement à l’état terminé, sauf s’il a été arrêté explicitement. Cette action est déclenchée automatiquement via la propriété onAllTasksComplete ou maxWallClockTime.

Il existe un quota de travail actif et de planification de travail par défaut. Les travaux et les planifications de travail à l’état terminé ne sont pas comptabilisés dans ce quota.

Supprimez les travaux lorsqu’ils ne sont plus nécessaires, même s’ils sont en état terminé. Bien que les travaux terminés ne comptent pas dans le quota de travaux actifs, il est utile de nettoyer régulièrement les travaux terminés. Par exemple, répertorier les travaux sera plus efficace lorsque le nombre total de travaux est un ensemble plus petit (même si des filtres appropriés sont appliqués à la demande).

Tâches

Les tâches sont des unités fonctionnelles individuelles qui composent un travail. Les tâches sont soumises par l’utilisateur et planifiées par Batch sur les nœuds de calcul. Les sections suivantes fournissent des suggestions pour concevoir vos tâches de manière à ce qu’elles s’exécutent et gèrent les problèmes efficacement.

Enregistrer des données de tâche

Les nœuds de calcul sont éphémères par nature. Les fonctionnalités Batch telles que le pool automatique et la mise à l’échelle automatique peuvent faciliter la disparition des nœuds. Quand des nœuds quittent un pool (en raison d’un redimensionnement ou d’une suppression de pool), tous les fichiers figurant sur ces nœuds sont également supprimés. À cause de ce comportement, une tâche devrait déplacer sa sortie du nœud sur lequel elle s’exécute vers un magasin durable avant de se terminer. De même, si une tâche échoue, elle devrait déplacer les journaux requis pour diagnostiquer l’échec dans un magasin durable.

Batch prend en charge Stockage Azure afin de charger des données via OutputFiles, ainsi qu’un large éventail de systèmes de fichiers partagés, ou vous pouvez effectuer le chargement vous-même dans vos tâches.

Gérer la durée de vie des tâches

Supprimez les tâches lorsqu’elles ne sont plus nécessaires, ou définissez une contrainte de tâche retentionTime. Si une retentionTime est définie, Batch nettoie automatiquement l’espace disque utilisé par la tâche lorsque retentionTime expire.

La suppression de tâches permet deux choses :

• Garantit que vous n’avez pas d’accumulation de tâches dans le travail. Cette action vous aidera à éviter toute difficulté à trouver la tâche qui vous intéresse, car vous devrez filtrer les tâches terminées.
• Nettoie également les données de tâche correspondantes sur le nœud (à condition que la contrainte retentionTime n’ait pas déjà été atteinte). Cette action garantit que vos nœuds ne se remplissent pas de données de tâches et ne manquent pas d’espace disque.

Envoyer un grand nombre de tâches dans une collection

Les tâches peuvent être envoyées individuellement ou dans des collections. Soumettez des tâches dans des collections jusqu’à 100 à la fois lorsque vous envoyez des tâches en masse afin de réduire le temps de traitement et d’envoi.

Définir correctement le nombre maximal de tâches par nœud

Batch prend en charge le surabonnement de tâches sur les nœuds (exécuter plus de tâches qu’un nœud n’a de cœurs). C’est à vous de veiller à ce que vos tâches sont adaptés aux nœuds de votre pool. Par exemple, vous pouvez avoir une dégradation de l’expérience si vous tentez de planifier huit tâches qui consomment chacune 25 % de l’utilisation de l’UC sur un nœud (dans un pool avec taskSlotsPerNode = 8).

Concevoir pour les nouvelles tentatives et la réexécution

Batch peut retenter automatiquement les tâches. Il existe deux types de nouvelles tentatives : contrôlée par l’utilisateur et interne. Les nouvelles tentatives contrôlées par l’utilisateur sont spécifiées par le paramètre maxTaskRetryCount de la tâche. Lorsqu’un programme spécifié dans la tâche s’arrête avec un code de sortie différent de zéro, la tâche est retentée jusqu’à la valeur du maxTaskRetryCount.

Bien que cela soit rare, une tâche peut être retentée en interne en raison de défaillances sur le nœud de calcul, comme l’impossibilité de mettre à jour l’état interne ou une défaillance sur le nœud pendant l’exécution de la tâche. La tâche sera retentée sur le même nœud de calcul, si possible, jusqu’à une limite interne avant d’être abandonnée et différée. Elle sera alors replanifiée par Batch, éventuellement sur un nœud de calcul différent.

Il n’existe aucune différence de conception lors de l’exécution de vos tâches sur des nœuds dédiés ou des nœuds spot. Qu’une tâche soit préemptée lorsqu’elle est exécutée sur un nœud spot ou qu’elle soit interrompue en raison d’une défaillance sur un nœud dédié, ces deux situations peuvent être atténuées si vous concevez la tâche dans le but de résister à une défaillance.

Créer des tâches durables

Les tâches doivent être conçues pour résister aux défaillances et prendre en charge les nouvelles tentatives. Ce principe est particulièrement important pour les tâches durables. Vérifiez que les tâches produisent le même résultat, même si elles sont exécutées plusieurs fois. Pour achever ce résultat, vous pouvez créer des tâches de « recherche d’objectif ». Une autre méthode consiste à s’assurer que vos tâches sont idempotent (c’est-à-dire qu’elles auront le même résultat, quel que soit le nombre de fois qu’elles sont exécutées).

Un exemple courant est une tâche de copie de fichiers vers un nœud de calcul. Une approche simple est une tâche qui copie tous les fichiers spécifiés à chaque fois qu’elle s’exécute, ce qui est inefficace et n’est pas conçu pour résister à une défaillance. Au lieu de cela, créez une tâche pour vous assurer que les fichiers se trouvent sur le nœud de calcul, c’est-à-dire une tâche qui ne recopie pas les fichiers déjà présents. De cette façon, la tâche reprends là où elle s’est arrêtée si elle a été interrompue.

Éviter une durée d’exécution réduite

Les tâches qui ne durent qu’une à deux secondes ne sont pas idéales. Essayez d’effectuer une grande quantité de travail dans une tâche individuelle (entre 10 secondes minimum, et des heures voire des jours). Si chaque tâche s’exécute pendant une minute (ou plus), la surcharge de planification en tant que fraction du temps de calcul global est faible.

Utiliser l’étendue du pool pour les tâches courtes sur les nœuds Windows

Lorsque vous planifiez une tâche sur des nœuds Batch, vous pouvez choisir de l'exécuter dans l’étendue d'une tâche ou d'un pool. Si la tâche s’exécute uniquement pendant une brève période, l’étendue de la tâche peut être inefficace en raison des ressources nécessaires à la création du compte d’utilisateur automatique pour cette tâche. Pour plus d’efficacité, vous pouvez définir ces tâches sur l’étendue du pool. Pour plus d’informations, consultez Exécution d’une tâche en tant qu’utilisateur automatique avec une étendue de pool.

Nœuds

Un nœud de calcul est une machine virtuelle Azure ou une machine virtuelle de service cloud dédiée au traitement d’une partie de la charge de travail de votre application. Suivez ces recommandations lorsque vous utilisez des nœuds.

Démarrer les tâches : durée de vie et idempotence

Comme pour d’autres tâches, le nœud démarrer la tâche doit être idempotent. Les tâches de démarrage sont réexécutées lorsque le nœud de calcul redémarre ou lorsque l’agent Batch redémarre. Une tâche idempotente est simplement une tâche qui produit un résultat constant lorsqu’elle est exécutée plusieurs fois.

Les tâches de démarrage ne doivent pas être longues ou être couplées à la durée de vie du nœud de calcul. Si vous devez démarrer des programmes qui sont des services ou des services de nature similaire, construisez une tâche de démarrage qui permet à ces programmes d’être démarrés et gérés par des dispositifs du système d’exploitation tels que systemd sur Linux ou les services Windows. La tâche de démarrage doit toujours être construite comme idempotente, de sorte que l’exécution ultérieure de la tâche de démarrage soit gérée correctement si ces programmes ont été précédemment installés en tant que services.

Ces services ne doivent pas prendre de verrous de fichier sur les fichiers des répertoires gérés par Batch sur le nœud, sans quoi Batch ne pourra pas supprimer ces répertoires en raison de ces verrous de fichier. Par exemple, au lieu de configurer le lancement du service directement à partir du répertoire de travail de la tâche de démarrage, copiez les fichiers ailleurs de manière idempotente. Installez ensuite le service à partir de cet emplacement en utilisant les installations du système d’exploitation.

Nœuds isolés

Envisagez d’utiliser des tailles de machines virtuelles isolées pour des charges de travail assorties d’exigences de conformité ou réglementaires. Les tailles isolées prises en charge en mode de configuration de machine virtuelle incluent Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5 et Standard_E64i_v3. Pour plus d’informations sur les tailles de machines virtuelles isolées, consultez Isolation de machine virtuelle dans Azure.

Éviter de créer des jonctions de répertoires dans Windows

Les jonctions de répertoires, parfois appelées liens physiques de répertoires, sont difficiles à gérer lors du nettoyage des tâches et des travaux. Utilisez des symlinks (liens symboliques) plutôt que des liens physiques.

Disques temporaires et AZ_BATCH_NODE_ROOT_DIR

Batch s’appuie sur des disques temporaires de machine virtuelle, pour les tailles de machines virtuelles compatibles avec Batch, pour stocker les métadonnées liées à l’exécution des tâches, ainsi que tous les artefacts de chaque exécution de tâche sur ce disque temporaire. Voici des exemples de ces points ou répertoires de montage de disque temporaires : /mnt/batch, /mnt/resource/batchet D:\batch\tasks. Le remplacement, le remontage, la jonction, la liaison symbolique ou la redirection de ces points de montage et répertoires ou de l’un des répertoires parents n’est pas pris en charge et peut entraîner une instabilité. Si vous avez besoin de plus d’espace disque, envisagez d’utiliser une taille ou une famille de machines virtuelles disposant d’un espace disque temporaire qui répond à vos besoins ou d’attacher des disques de données. Pour plus d’informations, consultez la section suivante sur l’attachement et la préparation de disques de données pour les nœuds de calcul.

Attachement et préparation des disques de données

Chaque nœud de calcul individuel aura exactement la même spécification de disque de données attachée si elle est spécifiée dans le cadre de l’instance du pool Batch. Seuls les nouveaux disques de données peuvent être attachés à des pools Batch. Ces disques de données attachés aux nœuds de calcul ne sont pas automatiquement partitionnés, formatés ou montés. Il est de votre responsabilité d’effectuer ces opérations dans le cadre de votre tâche de démarrage. Ces tâches de début doivent être conçues pour être idempotentes. Il est possible de réexécuter les tâches de démarrage sur les nœuds de calcul. Si la tâche de démarrage n’est pas idempotente, une perte de données potentielle peut se produire sur les disques de données.

Préparation de disques de données dans des pools Batch Linux

Les disques de données Azure dans Linux sont présentés en tant que périphériques de blocs et sont affectés à un identificateur standard sd[X] . Vous ne devez pas vous appuyer sur des affectations statiques sd[X], car ces étiquettes sont attribuées dynamiquement au démarrage et ne sont pas garanties d’être cohérentes entre le premier et les démarrages suivants. Vous devez identifier vos disques attachés via les mappages présentés dans /dev/disk/azure/scsi1/. Par exemple, si vous avez spécifié LUN 0 pour votre disque de données dans l’API AddPool, ce disque se manifeste sous la forme /dev/disk/azure/scsi1/lun0. Par exemple, si vous deviez répertorier ce répertoire, vous pourriez voir :

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

Il n’est pas nécessaire de traduire la référence sd[X] en mappage dans votre script de préparation, mais de faire référence directement à l’appareil. Dans cet exemple, l’appareil est représenté par /dev/disk/azure/scsi1/lun0. Vous pouvez fournir cet ID directement àfdisket à mkfstout autre outil requis pour votre workflow. Vous pouvez également utiliser lsblk avec blkid pour mapper l’UUID pour le disque.

Pour plus d’informations sur les disques de données Azure dans Linux, notamment les autres méthodes de localisation des disques de données et des options /etc/fstab, consultez cet article. Assurez-vous qu’il n’y a pas de dépendances ou de races, comme décrit par la note de conseil avant d’utiliser votre méthode en production.

Préparation des disques de données dans des pools Windows Batch

Les disques de données Azure attachés aux nœuds de calcul Windows Batch sont présentés sans partition et non mis en forme. Dans le cadre de votre tâche de démarrage, vous devez énumérer les disques comportant des partitions RAW afin d’effectuer des actions. Ces informations peuvent être récupérées à l’aide de l’applet de commande Get-Disk PowerShell. Par exemple, vous pouvez potentiellement voir :

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

Où disque numéro 2 est le disque de données non initialisé attaché à ce nœud de calcul. Ces disques peuvent ensuite être initialisés, partitionnés et mis en forme selon les besoins de votre flux de travail.

Pour plus d’informations sur les disques de données Azure dans Windows, notamment des exemples de scripts PowerShell, consultez cet article. Vérifiez que tous les exemples de scripts sont validés pour l’idempotence avant d’être utilisés en production.

Collecter les journaux de l’agent Batch

Si vous remarquez un problème impliquant le comportement d’un nœud ou de tâches en cours d’exécution sur un nœud, collectez les journaux de l’agent Batch avant de libérer les nœuds en question. Les journaux de l’agent Batch peuvent être collectés à l’aide de l’API de chargement des journaux du service Batch. Ces journaux peuvent être fournis dans le cadre d’un ticket de support envoyé à Microsoft. Ils vous aideront à détecter les problèmes et à les résoudre.

API Batch

Échecs de délai d’expiration

Les échecs de délai d’expiration n’indiquent pas nécessairement que le service n’a pas pu traiter la demande. Lorsqu’un échec de délai d’expiration se produit, vous devez réessayer l’opération ou récupérer l’état de la ressource, le cas échéant, afin de vérifier si l’opération a réussi ou échoué.

Connectivité

Passez en revue les recommandations suivantes associées à la connectivité dans vos solutions Batch.

Groupes de sécurité réseau (NSG) et Itinéraires définis par l’utilisateur (UDR)

Quand vous approvisionnez des pools Batch dans un réseau virtuel, veillez à respecter scrupuleusement les instructions relatives à l’utilisation de l’étiquette de service BatchNodeManagement.région, des ports, des protocoles et de la direction de la règle. L'utilisation de l'étiquette de service est fortement recommandée ; n'utilisez pas les adresses IP du service Batch sous-jacent car elles peuvent changer au fil du temps. L’utilisation directe d’adresses IP du service Batch peut entraîner une instabilité, des interruptions ou des pannes au niveau de vos pools Batch.

Pour les itinéraires définis par l’utilisateur (UDR), il est recommandé d’utiliser des étiquettes de service BatchNodeManagement.région au lieu d’adresses IP de service Batch, car elles peuvent changer au fil du temps.

Respect du DNS

Vérifiez que vos systèmes respectent la durée de vie (TTL) du DNS pour l’URL de service de votre compte Batch. Par ailleurs, assurez-vous que les clients de votre service Batch et d’autres mécanismes de connectivité au service Batch ne reposent pas sur des adresses IP.

Toutes les requêtes HTTP avec des codes d’état de niveau 5xx ainsi qu’un en-tête « Connexion : fermer » dans la réponse nécessitent l’ajustement du comportement de votre client de service Batch. Le client de votre service Batch doit respecter la recommandation en fermant la connexion existante, en résolvant le DNS pour l’URL de service du compte Batch, et en essayant les demandes suivantes sur une nouvelle connexion.

Nouvelles tentatives automatiques des demandes

Assurez-vous que les clients de votre service Batch disposent de stratégies de nouvelle tentative appropriées pour réessayer automatiquement vos demandes, même pendant un fonctionnement normal, et non exclusivement pendant les périodes de maintenance du service. Ces stratégies de nouvelle tentative doivent couvrir un intervalle d’au moins 5 minutes. Les fonctionnalités de nouvelles tentatives automatiques sont fournies avec divers kits de développement logiciel Batch, tels que la classe .NET RetryPolicyProvider.

Adresses IP publiques statiques

En règle générale, les machines virtuelles d’un pool Batch sont accessibles par le biais d’adresses IP publiques qui peuvent changer au cours de la durée de vie du pool. Cette nature dynamique peut compliquer l’interaction avec une base de données ou un autre service externe qui limite l’accès à certaines adresses IP. Pour résoudre ce problème, vous pouvez créer un pool en utilisant un ensemble d’adresses IP publiques statiques que vous contrôlez. Pour plus d’informations, consultez Créer un pool Azure Batch avec des adresses IP publiques spécifiées.

Dépendances sous-jacentes du nœud Batch

Tenez compte des dépendances et restrictions suivantes lors de la conception de vos solutions Batch.

Ressources créées par le système

Azure Batch crée et gère un ensemble d’utilisateurs et de groupes sur la machine virtuelle, qui ne doit pas être modifié :

Windows :

• Un utilisateur nommé PoolNonAdmin
• Un groupe d’utilisateurs nommé WATaskCommon

Linux :

• Un utilisateur nommé _azbatch

Nettoyage du fichier

Batch tente activement de nettoyer le répertoire de travail dans lequel les tâches sont exécutées, une fois leur durée de rétention expirée. Il vous incombe de nettoyer tous les fichiers écrits en dehors de ce répertoire afin d’éviter de saturer l’espace disque.

Le nettoyage automatisé du répertoire de travail sera bloqué si vous exécutez un service sur Windows à partir du répertoire de travail start Task, du fait que le dossier est toujours en cours d’utilisation. Cette action entraîne une dégradation des performances. Pour résoudre ce problème, remplacez le répertoire de ce service par un répertoire distinct qui n’est pas géré par Batch.

Étapes suivantes

• Apprenez-en davantage sur le flux de travail et les ressources principales du service Batch, telles que les pools, les nœuds, les travaux et les tâches.
• Apprenez-en davantage sur les contraintes, les limites et les quotas par défaut d’Azure Batch, et comment demander une augmentation de quota.
• Découvrez comment détecter et éviter les défaillances dans les opérations d’arrière-plan des pools et des nœuds .