View a markdown version of this page

Slurm guide pour le mode file d'attente multiple - AWS ParallelCluster
Présentation deCycle de vie des nœuds cloudUtilisation d'un nœud disponibleÉtat des tâches et soumissionÉtat et caractéristiques du nœudÉtats de partitiondémarrage et arrêt de pclusterContrôle manuel des files d'attenteComportement de dimensionnement et ajustementsJournaux pour la nouvelle architectureProblèmes courants et procédure de débogage :

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Slurm guide pour le mode file d'attente multiple

AWS ParallelCluster la version 2.9.0 a introduit le mode file d'attente multiple et une nouvelle architecture de dimensionnement pour Slurm Workload Manager (Slurm).

Les sections suivantes fournissent un aperçu général de l'utilisation d'un Slurm cluster avec la nouvelle architecture de dimensionnement.

Présentation de

La nouvelle architecture de dimensionnement est basée sur le Slurm Cloud Scheduling Guide et le plugin d'économie d'énergie. Pour plus d'informations sur le plug-in d'économie d'énergie, consultez le Guide d'économie d'Slurménergie. Dans la nouvelle architecture, les ressources susceptibles d'être mises à la disposition d'un cluster sont généralement prédéfinies dans la Slurm configuration en tant que nœuds cloud.

Cycle de vie des nœuds cloud

Tout au long de leur cycle de vie, les nœuds cloud entrent dans plusieurs des états suivantsPOWER_SAVING, POWER_UP sinon tous :, ALLOCATED (alloc), () et POWER_DOWN (pow_dn). pow_up Dans certains cas, un nœud de cloud peut entrer dans OFFLINE cet état. La liste suivante détaille plusieurs aspects de ces états dans le cycle de vie des nœuds cloud.

  • Un nœud dans un POWER_SAVING état apparaît avec un ~ suffixe (par exempleidle~) danssinfo. Dans cet état, aucune instance EC2 ne soutient le nœud. Cependant, Slurm peut toujours attribuer des tâches au nœud.

  • Un nœud en transition vers un POWER_UP état apparaît avec un # suffixe (par exempleidle#) dans. sinfo

  • Lors de Slurm l'attribution d'une tâche à un nœud dans un POWER_SAVING état, le nœud passe automatiquement à un POWER_UP état. Sinon, les nœuds peuvent être placés dans POWER_UP cet état manuellement à l'aide de la scontrol update nodename=nodename state=power_up commande. À ce stade, les instances EC2 ResumeProgram sont invoquées et sont lancées et configurées pour sauvegarder un POWER_UP nœud.

  • Un nœud actuellement disponible apparaît sans suffixe (par exempleidle) danssinfo. Une fois que le nœud est configuré et a rejoint le cluster, il devient disponible pour exécuter des tâches. À ce stade, le nœud est correctement configuré et prêt à être utilisé. En règle générale, nous recommandons que le nombre d'instances dans EC2 soit le même que le nombre de nœuds disponibles. Dans la plupart des cas, les nœuds statiques sont toujours disponibles après la création du cluster.

  • Un nœud en transition vers un POWER_DOWN état apparaît avec un % suffixe (par exempleidle%) dans. sinfo Les nœuds dynamiques entrent automatiquement dans POWER_DOWN l'état suivantscaledown_idletime. En revanche, dans la plupart des cas, les nœuds statiques ne sont pas hors tension. Cependant, les nœuds peuvent être placés dans POWER_DOWN cet état manuellement à l'aide de la scontrol update nodename=nodename state=powering_down commande. Dans cet état, l'instance associée à un nœud est arrêtée et le nœud est réinitialisé à l'POWER_SAVINGétat pour une utilisation ultérieurescaledown_idletime. Le scaledown-idletime réglage est enregistré dans la Slurm configuration en tant que SuspendTimeout paramètre.

  • Un nœud hors ligne apparaît avec un * suffixe (par exempledown*) danssinfo. Un nœud se déconnecte si le Slurm contrôleur ne peut pas contacter le nœud ou si les nœuds statiques sont désactivés et que les instances de sauvegarde sont fermées.

Examinons maintenant les états des nœuds illustrés dans l'sinfoexemple suivant.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1  idle% gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite      2   mix# ondemand-dy-c52xlarge-[1-2]
ondemand     up   infinite     18  idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Les efa-st-c5n18xlarge-1 nœuds spot-st-t2large-[1-2] et ont déjà des instances de sauvegarde configurées et peuvent être utilisées. Les ondemand-dy-c52xlarge-[1-2] nœuds sont en POWER_UP état et devraient être disponibles d'ici quelques minutes. Le gpu-dy-g38xlarge-1 nœud est dans POWER_DOWN cet état et il passera à l'POWER_SAVINGétat par la suite scaledown_idletime (la valeur par défaut est de 120 secondes).

Tous les autres nœuds sont en POWER_SAVING état et aucune instance EC2 ne les soutient.

Utilisation d'un nœud disponible

Un nœud disponible est soutenu par une instance EC2. Par défaut, le nom du nœud peut être utilisé pour accéder directement à l'instance par SSH (par exemplessh efa-st-c5n18xlarge-1). L'adresse IP privée de l'instance peut être récupérée à l'aide de la scontrol show nodes nodename commande et en cochant le NodeAddr champ. Pour les nœuds qui ne sont pas disponibles, le NodeAddr champ ne doit pas pointer vers une instance EC2 en cours d'exécution. Il doit plutôt être identique au nom du nœud.

État des tâches et soumission

Dans la plupart des cas, les tâches soumises sont immédiatement attribuées aux nœuds du système, ou mises en attente si tous les nœuds sont alloués.

Si les nœuds alloués à une tâche incluent des nœuds dans un POWER_SAVING état, la tâche commence par un CF CONFIGURING état ou. À ce stade, la tâche attend que les nœuds de l'POWER_SAVINGétat passent à l'POWER_UPétat et soient disponibles.

Une fois que tous les nœuds alloués à une tâche sont disponibles, la tâche passe à l'état RUNNING (R).

Par défaut, toutes les tâches sont soumises à la file d'attente par défaut (appelée partition dansSlurm). Cela est indiqué par un * suffixe après le nom de la file d'attente. Vous pouvez sélectionner une file d'attente à l'aide de l'option de soumission des -p tâches.

Tous les nœuds sont configurés avec les fonctionnalités suivantes, qui peuvent être utilisées dans les commandes de soumission de tâches :

  • Un type d'instance (par exemplec5.xlarge)

  • Un type de nœud (il s'agit de l'un dynamic ou de l'autrestatic.)

Vous pouvez voir toutes les fonctionnalités disponibles pour un nœud en particulier en utilisant la scontrol show nodes nodename commande et en consultant la AvailableFeatures liste.

Les emplois constituent un autre facteur à prendre en compte. Examinez d'abord l'état initial du cluster, que vous pouvez visualiser en exécutant la sinfo commande.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite     10  idle~ gpu-dy-g38xlarge-[1-10]
ondemand     up   infinite     20  idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Notez qu'il s'spotagit de la file d'attente par défaut. Il est indiqué par le * suffixe.

Soumettez une tâche à un nœud statique de la file d'attente par défaut (spot).

$ sbatch --wrap "sleep 300" -N 1 -C static

Soumettez une tâche à un nœud dynamique de la EFA file d'attente.

$ sbatch --wrap "sleep 300" -p efa -C dynamic

Soumettez une tâche à huit (8) c5.2xlarge nœuds et deux (2) t2.xlarge nœuds à la ondemand file d'attente.

$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"

Soumettez une tâche à un nœud GPU de la gpu file d'attente.

$ sbatch --wrap "sleep 300" -p gpu -G 1

Examinez maintenant l'état des tâches à l'aide de la squeue commande.

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                12  ondemand     wrap   ubuntu CF       0:36     10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
                13       gpu     wrap   ubuntu CF       0:05      1 gpu-dy-g38xlarge-1
                 7      spot     wrap   ubuntu  R       2:48      1 spot-st-t2large-1
                 8       efa     wrap   ubuntu  R       0:39      1 efa-dy-c5n18xlarge-1

Les jobs 7 et 8 (dans les spot efa files d'attente) sont déjà en cours d'exécution (R). Les jobs 12 et 13 sont toujours en train de configurer (CF) et attendent probablement que les instances soient disponibles.

# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      3  idle~ efa-dy-c5n18xlarge-[2-4]
efa          up   infinite      1    mix efa-dy-c5n18xlarge-1
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1   mix~ gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite     10   mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand     up   infinite     10  idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      1    mix spot-st-t2large-1
spot*        up   infinite      1   idle spot-st-t2large-2

État et caractéristiques du nœud

Dans la plupart des cas, les états des nœuds sont entièrement gérés AWS ParallelCluster conformément aux processus spécifiques du cycle de vie des nœuds cloud décrits plus haut dans cette rubrique.

Toutefois, remplace ou met AWS ParallelCluster également fin aux nœuds défectueux dans DOWN et DRAINED aux états et aux nœuds dont les instances de sauvegarde ne sont pas saines. Pour de plus amples informations, veuillez consulter clustermgtd.

États de partition

AWS ParallelCluster prend en charge les états de partition suivants. Une Slurm partition est une file d'attente AWS ParallelCluster.

  • UP: indique que la partition est dans un état actif. Il s'agit de l'état par défaut d'une partition. Dans cet état, tous les nœuds de la partition sont actifs et peuvent être utilisés.

  • INACTIVE: indique que la partition est inactive. Dans cet état, toutes les instances qui sauvegardent les nœuds d'une partition inactive sont fermées. Aucune nouvelle instance n'est lancée pour les nœuds d'une partition inactive.

démarrage et arrêt de pcluster

Lors pcluster stop de son exécution, toutes les partitions sont placées dans INACTIVE cet état et les AWS ParallelCluster processus conservent les partitions dans INACTIVE cet état.

Lors pcluster start de son exécution, toutes les partitions sont initialement placées dans UP cet état. Cependant, AWS ParallelCluster les processus ne permettent pas de conserver la partition dans un UP état. Vous devez modifier l'état des partitions manuellement. Tous les nœuds statiques deviennent disponibles au bout de quelques minutes. Notez que la définition d'une partition sur UP n'active aucune capacité dynamique. Si la initial_count valeur est supérieure àmax_count, elle initial_count risque de ne pas être satisfaite lorsque l'état de la partition passe à UP cet état.

Pendant pcluster start et pcluster stop pendant l'exécution, vous pouvez vérifier l'état du cluster en exécutant la pcluster status commande et en cochant la caseComputeFleetStatus. La liste suivante répertorie les états possibles :

  • STOP_REQUESTED: La pcluster stop demande est envoyée au cluster.

  • STOPPING: le pcluster processus est en train d'arrêter le cluster.

  • STOPPED: le pcluster processus a terminé le processus d'arrêt, toutes les partitions sont en INACTIVE état et toutes les instances de calcul sont terminées.

  • START_REQUESTED: La pcluster start demande est envoyée au cluster.

  • STARTING: Le pcluster processus est en train de démarrer le cluster

  • RUNNING: le pcluster processus a terminé le processus de démarrage, toutes les partitions sont en UP état et les nœuds statiques seront disponibles après quelques minutes.

Contrôle manuel des files d'attente

Dans certains cas, vous souhaiterez peut-être contrôler manuellement les nœuds ou la file d'attente (appelée partition dansSlurm) d'un cluster. Vous pouvez gérer les nœuds d'un cluster à l'aide des procédures courantes suivantes.

  • Allumez les nœuds dynamiques en POWER_SAVING état : exécutez la scontrol update nodename=nodename state=power_up commande ou soumettez une sleep 1 tâche d'espace réservé demandant un certain nombre de nœuds et comptez sur cette fonction Slurm pour activer le nombre de nœuds requis.

  • Mettez les nœuds dynamiques hors tension avant scaledown_idletime : définissez les nœuds dynamiques sur à l'DOWNaide de la scontrol update nodename=nodename state=down commande. AWS ParallelCluster arrête et réinitialise automatiquement les nœuds dynamiques mis hors service. En général, nous ne recommandons pas de configurer les nœuds POWER_DOWN directement à l'aide de la scontrol update nodename=nodename state=power_down commande. En effet, le processus de mise hors tension est géré AWS ParallelCluster automatiquement. Aucune intervention manuelle n'est nécessaire. Par conséquent, nous vous recommandons d'essayer de configurer les nœuds dans la DOWN mesure du possible.

  • Désactivez une file d'attente (partition) ou arrêtez tous les nœuds statiques d'une partition spécifique : définissez la file d'attente sur spécifique à l'INACTIVEaide de la scontrol update partition=queue name state=inactive commande. Cette opération met fin à toutes les instances qui soutiennent les nœuds de la partition.

  • Activer une file d'attente (partition) : définissez spécifiquement la file d'attente à l'INACTIVEaide de la scontrol update partition=queue name state=up commande.

Comportement de dimensionnement et ajustements

Voici un exemple du flux de travail de dimensionnement normal :

  • Le planificateur reçoit une tâche qui nécessite deux nœuds.

  • Le planificateur fait passer deux nœuds à un POWER_UP état et appelle ResumeProgram avec les noms des nœuds (par exemplequeue1-dy-c5xlarge-[1-2]).

  • ResumeProgramlance deux instances EC2 et attribue les adresses IP privées et les noms d'hôte dequeue1-dy-c5xlarge-[1-2], en attendant ResumeTimeout (la période par défaut est de 60 minutes (1 heure)) avant de réinitialiser les nœuds.

  • Les instances sont configurées et rejoignent le cluster. Le job commence à s'exécuter sur les instances.

  • Le travail est terminé.

  • Une fois que la configuration est SuspendTime écoulée (ce qui est défini surscaledown_idletime), les instances sont mises dans POWER_SAVING cet état par le planificateur. Le planificateur met queue1-dy-c5xlarge-[1-2] en POWER_DOWN état et appelle SuspendProgram avec les noms des nœuds.

  • SuspendProgramest appelé pour deux nœuds. Les nœuds restent dans POWER_DOWN cet état, par exemple idle% pendant un SuspendTimeout (la période par défaut est de 120 secondes (2 minutes)). Après avoir clustermgtd détecté que les nœuds sont hors tension, il met fin aux instances de sauvegarde. Ensuite, il passe à queue1-dy-c5xlarge-[1-2] l'état inactif et réinitialise l'adresse IP privée et le nom d'hôte afin qu'ils puissent être redémarrés pour les tâches futures.

Maintenant, si les choses tournent mal et qu'une instance pour un nœud particulier ne peut pas être lancée pour une raison quelconque, voici ce qui se passe.

  • Le planificateur reçoit une tâche qui nécessite deux nœuds.

  • Le planificateur place deux nœuds cloud bursting en POWER_UP état et appelle ResumeProgram avec les noms des nœuds (par exemple). queue1-dy-c5xlarge-[1-2]

  • ResumeProgramlance une (1) seule instance EC2 et configurequeue1-dy-c5xlarge-1, mais il n'a pas pu lancer une instance pour. queue1-dy-c5xlarge-2

  • queue1-dy-c5xlarge-1ne sera pas affecté et sera mis en ligne après avoir atteint POWER_UP l'État.

  • queue1-dy-c5xlarge-2est placé dans POWER_DOWN cet état et la tâche est automatiquement mise en file d'attente car elle Slurm détecte une défaillance d'un nœud.

  • queue1-dy-c5xlarge-2devient disponible après SuspendTimeout (la valeur par défaut est de 120 secondes (2 minutes)). Entre-temps, la tâche est mise en file d'attente et peut commencer à s'exécuter sur un autre nœud.

  • Le processus ci-dessus est répété jusqu'à ce que la tâche puisse être exécutée sur un nœud disponible sans échec.

Deux paramètres de synchronisation peuvent être ajustés si nécessaire.

  • ResumeTimeout(la valeur par défaut est de 60 minutes (1 heure)) : ResumeTimeout contrôle le temps d'Slurmattente avant de mettre le nœud en état d'arrêt.

    • Il peut être utile de prolonger cette durée si votre processus pre/post d'installation prend presque autant de temps.

    • Il s'agit également du temps d' AWS ParallelCluster attente maximum avant de remplacer ou de réinitialiser un nœud en cas de problème. Les nœuds de calcul s'arrêtent automatiquement en cas d'erreur lors du lancement ou de la configuration. Ensuite, AWS ParallelCluster les processus remplacent également le nœud lorsqu'il constate que l'instance est terminée.

  • SuspendTimeout(la valeur par défaut est de 120 secondes (2 minutes)) : SuspendTimeout contrôle la rapidité avec laquelle les nœuds sont replacés dans le système et prêts à être réutilisés.

    • Une valeur plus courte SuspendTimeout signifierait que les nœuds seront réinitialisés plus rapidement et Slurm pourront essayer de lancer des instances plus fréquemment.

    • Une valeur plus longue SuspendTimeout ralentit la réinitialisation des nœuds défaillants. En attendant, essaie Slurm d'utiliser d'autres nœuds. Si cela SuspendTimeout prend plus de quelques minutes, Slurm essaie de parcourir tous les nœuds du système. Une durée plus longue SuspendTimeout peut être bénéfique pour les systèmes à grande échelle (plus de 1 000 nœuds) car elle permet de réduire le stress en remettant fréquemment Slurm en file d'attente les tâches défaillantes.

    • Notez que SuspendTimeout cela ne fait pas référence au temps d' AWS ParallelCluster attente pour mettre fin à une instance de sauvegarde pour un nœud. Les instances de sauvegarde pour power down les nœuds sont immédiatement interrompues. Le processus de terminaison se termine généralement en quelques minutes. Cependant, pendant ce temps, le nœud reste hors tension et n'est pas disponible pour une utilisation dans le planificateur.

Journaux pour la nouvelle architecture

La liste suivante contient les journaux de clés pour l'architecture à files d'attente multiples. Le nom du flux de CloudWatch journaux utilisé avec Amazon Logs est au format {hostname}.{instance_id}.{logIdentifier} logIdentifier suivant les noms des journaux. Pour de plus amples informations, veuillez consulter Intégration avec Amazon CloudWatch Logs.

  • ResumeProgram:

    /var/log/parallelcluster/slurm_resume.log (slurm_resume)

  • SuspendProgram:

    /var/log/parallelcluster/slurm_suspend.log (slurm_suspend)

  • clustermgtd:

    /var/log/parallelcluster/clustermgtd.log (clustermgtd)

  • computemgtd:

    /var/log/parallelcluster/computemgtd.log (computemgtd)

  • slurmctld:

    /var/log/slurmctld.log (slurmctld)

  • slurmd:

    /var/log/slurmd.log (slurmd)

Problèmes courants et procédure de débogage :

Nœuds qui n'ont pas pu démarrer, mettre sous tension ou rejoindre le cluster :

  • Nœuds dynamiques :

    • Consultez le ResumeProgram journal pour voir s'il ResumeProgram a déjà été appelé avec le nœud. Si ce n'est pas le cas, consultez le slurmctld journal pour déterminer si vous avez Slurm déjà essayé ResumeProgram d'appeler le nœud. Notez que des autorisations incorrectes ResumeProgram peuvent entraîner un échec silencieux.

    • S'ResumeProgramil est appelé, vérifiez si une instance a été lancée pour le nœud. Si l'instance ne peut pas être lancée, un message d'erreur clair devrait apparaître indiquant pourquoi l'instance n'a pas pu être lancée.

    • Si une instance a été lancée, il se peut qu'un problème soit survenu pendant le processus d'initialisation. Recherchez l'adresse IP privée et l'ID d'instance correspondants dans le ResumeProgram journal et consultez les journaux d'amorçage correspondants pour l'instance spécifique dans CloudWatch Logs.

  • Nœuds statiques :

    • Consultez le clustermgtd journal pour voir si des instances ont été lancées pour le nœud. Si ce n'est pas le cas, des erreurs claires devraient indiquer pourquoi les instances n'ont pas pu être lancées.

    • Si une instance a été lancée, il y a un problème lors du processus d'amorçage. Recherchez l'adresse IP privée et l'ID d'instance correspondants dans le clustermgtd journal et consultez les journaux d'amorçage correspondants pour l'instance spécifique dans CloudWatch Logs.

Nœuds remplacés ou arrêtés de façon inattendue, pannes de nœuds

  • Nœuds replaced/terminated inattendus

    • Dans la plupart des cas, clustermgtd gère toutes les actions de maintenance des nœuds. Pour vérifier si un nœud a été clustermgtd remplacé ou résilié, consultez le clustermgtd journal.

    • En cas de clustermgtd remplacement ou de fermeture du nœud, un message devrait indiquer la raison de l'action. Si la raison est liée au planificateur (par exemple, le nœud l'étaitDOWN), consultez le slurmctld journal pour plus de détails. Si la raison est liée à EC2, utilisez des outils pour vérifier l'état ou les journaux de cette instance. Par exemple, vous pouvez vérifier si l'instance avait des événements planifiés ou si les contrôles de l'état de santé EC2 ont échoué.

    • Si vous clustermgtd n'avez pas mis fin au nœud, vérifiez s'il computemgtd a mis fin au nœud ou si EC2 a mis fin à l'instance pour récupérer une instance Spot.

  • Pannes de nœuds

    • Dans la plupart des cas, les tâches sont automatiquement mises en file d'attente en cas de défaillance d'un nœud. Consultez le slurmctld journal pour savoir pourquoi une tâche ou un nœud a échoué et analysez la situation à partir de là.

Échec lors du remplacement ou de la fermeture d'instances, échec lors de la mise hors tension des nœuds

  • En général, clustermgtd gère toutes les actions de terminaison d'instance attendues. Consultez le clustermgtd journal pour savoir pourquoi il n'a pas réussi à remplacer ou à arrêter un nœud.

  • En cas de défaillance des nœuds dynamiquesscaledown_idletime, consultez le SuspendProgram journal pour voir si un programme slurmctld fonctionne avec le nœud spécifique comme argument. Note SuspendProgram n'effectue aucune action spécifique. Au contraire, il ne se connecte que lorsqu'il est appelé. La fermeture et la NodeAddr réinitialisation de toutes les instances sont terminées parclustermgtd. Slurmplace les nœuds IDLE aprèsSuspendTimeout.

Autres problèmes

  • AWS ParallelCluster ne prend pas de décisions en matière de répartition des tâches ou de dimensionnement. Il essaie simplement de lancer, de terminer et de gérer les ressources conformément Slurm aux instructions.

    Pour les problèmes liés à l'attribution des tâches, à l'allocation des nœuds et à la décision de dimensionnement, consultez le slurmctld journal pour détecter les erreurs.