Slurmguide pour le mode de file d'attente multiple

Ici, vous pouvez apprendre comment Slurm gérer AWS ParallelCluster les nœuds de file d'attente (partition) et comment surveiller l'état de la file d'attente et des nœuds.

Présentation

L'architecture de mise à l'échelle est basée sur le guide Slurm de planification dans le cloud et sur 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 l'architecture, les ressources susceptibles d'être mises à disposition pour un cluster sont généralement prédéfinies dans la Slurm configuration sous forme de 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 voire dans tous les cas :, 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 de cloud.

• Un nœud dans un POWER_SAVING état apparaît avec un ~ suffixe (par exempleidle~) danssinfo. Dans cet état, aucune instance EC2 ne sauvegarde le nœud. Cependant, Slurm vous pouvez toujours allouer 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 Un nœud passe automatiquement à un POWER_UP état lorsqu'il Slurm alloue une tâche à un nœud dans un POWER_SAVING état.

  Vous pouvez également faire passer les nœuds à l'POWER_UPétat manuellement en tant qu'utilisateur su root à l'aide de la commande suivante :

  $ scontrol update nodename=nodename state=power_up

  À ce stade, le ResumeProgram est invoqué, les instances EC2 sont lancées et configurées, et le nœud passe à l'POWER_UPétat.

• Un nœud actuellement disponible apparaît sans suffixe (par exempleidle) danssinfo. Une fois le nœud configuré et 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 Amazon EC2 soit identique au nombre de nœuds disponibles. Dans la plupart des cas, les nœuds statiques sont 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 l'POWER_DOWNétat suivant ScaledownIdletime. En revanche, dans la plupart des cas, les nœuds statiques ne sont pas hors tension. Cependant, vous pouvez placer les nœuds dans l'POWER_DOWNétat manuellement en tant qu'utilisateur su root à l'aide de la commande suivante :

  $ scontrol update nodename=nodename state=down reason="manual draining"

  Dans cet état, les instances associées à un nœud sont résiliées, et le nœud est remis à son POWER_SAVING état et peut être utilisé ultérieurement ScaledownIdletime.

  Le ScaledownIdletimeparamètre est enregistré dans le SuspendTimeout paramètre Slurm de configuration.

• Un nœud hors ligne apparaît avec un * suffixe (par exempledown*) danssinfo. Un nœud est déconnecté si le Slurm contrôleur ne parvient pas à le contacter ou si les nœuds statiques sont désactivés et que les instances de support sont interrompues.

Examinez 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-efacompute1-[1-4]
  efa          up   infinite      1   idle efa-st-efacompute1-1
  gpu          up   infinite      1  idle% gpu-dy-gpucompute1-1
  gpu          up   infinite      9  idle~ gpu-dy-gpucompute1-[2-10]
  ondemand     up   infinite      2   mix# ondemand-dy-ondemandcompute1-[1-2]
  ondemand     up   infinite     18  idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
  spot*        up   infinite     13  idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
  spot*        up   infinite      2   idle spot-st-spotcompute2-[1-2]

Les efa-st-efacompute1-1 nœuds spot-st-spotcompute2-[1-2] et ont déjà des instances de sauvegarde configurées et peuvent être utilisées. Les ondemand-dy-ondemandcompute1-[1-2] nœuds sont en bon POWER_UP état et devraient être disponibles dans quelques minutes. Le gpu-dy-gpucompute1-1 nœud est dans l'POWER_DOWNétat, et il passe à POWER_SAVING l'état par la suite ScaledownIdletime(10 minutes par défaut).

Tous les autres nœuds sont dans un POWER_SAVING état sans qu'aucune instance EC2 ne les soutienne.

Utilisation d'un nœud disponible

Un nœud disponible est soutenu par une instance Amazon EC2. Par défaut, le nom du nœud peut être utilisé pour accéder directement à l'instance en SSH (par exemplessh efa-st-efacompute1-1). L'adresse IP privée de l'instance peut être récupérée à l'aide de la commande :

$ scontrol show nodes nodename

Vérifiez l'adresse IP dans le NodeAddr champ renvoyé.

Pour les nœuds qui ne sont pas disponibles, le NodeAddr champ ne doit pas pointer vers une instance Amazon EC2 en cours d'exécution. Il doit plutôt être identique au nom du nœud.

État des offres d'emploi et soumission

Dans la plupart des cas, les tâches soumises sont immédiatement alloué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 inSlurm). 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)

• Type de nœud (il s'agit de l'un dynamic ou static de l'autre)

Vous pouvez voir les fonctionnalités d'un nœud en particulier à l'aide de la commande :

$ scontrol show nodes nodename

Au retour, consultez la AvailableFeatures liste.

Tenez compte de l'état initial du cluster, que vous pouvez consulter en exécutant la sinfo commande.

$ sinfo
  PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
  efa          up   infinite      4  idle~ efa-dy-efacompute1-[1-4]
  efa          up   infinite      1   idle efa-st-efacompute1-1
  gpu          up   infinite     10  idle~ gpu-dy-gpucompute1-[1-10]
  ondemand     up   infinite     20  idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
  spot*        up   infinite     13  idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
  spot*        up   infinite      2   idle spot-st-spotcompute2-[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 de 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 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-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
  13        gpu     wrap   ubuntu CF       0:05      1 gpu-dy-gpucompute1-1
   7       spot     wrap   ubuntu  R       2:48      1 spot-st-spotcompute2-1
   8        efa     wrap   ubuntu  R       0:39      1 efa-dy-efacompute1-1

Les tâches 7 et 8 (dans les efa files d'attente spot et) sont déjà en cours d'exécution (R). Les jobs 12 et 13 sont toujours en cours de configuration (CF), attendant 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-efacompute1-[2-4]
 efa          up   infinite      1    mix efa-dy-efacompute1-1
 efa          up   infinite      1   idle efa-st-efacompute1-1
 gpu          up   infinite      1   mix~ gpu-dy-gpucompute1-1
 gpu          up   infinite      9  idle~ gpu-dy-gpucompute1-[2-10]
 ondemand     up   infinite     10   mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
 ondemand     up   infinite     10  idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
 spot*        up   infinite     13  idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
 spot*        up   infinite      1    mix spot-st-spotcompute2-1
 spot*        up   infinite      1   idle spot-st-spotcompute2-2 

État et fonctionnalités 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 de cloud décrits plus haut dans cette rubrique.

Toutefois, remplace ou arrête AWS ParallelCluster également les nœuds défectueux dans les DRAINED états DOWN et les nœuds dont les instances de sauvegarde ne fonctionnent pas correctement. Pour plus d’informations, consultez clustermgtd.

États de partition

AWS ParallelCluster prend en charge les états de partition suivants. Une Slurm partition est une file d'attente dans 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 soutiennent les nœuds d'une partition inactive sont arrêtées. Les nouvelles instances ne sont pas lancées pour les nœuds d'une partition inactive.

cluster update-compute-fleet

• Arrêt du parc informatique : lorsque la commande suivante est exécutée, toutes les partitions passent à l'INACTIVEétat, et AWS ParallelCluster les processus les maintiennent dans INACTIVE cet état.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status STOP_REQUESTED

• Démarrage du parc informatique : lorsque la commande suivante est exécutée, toutes les partitions passent initialement à l'UPétat. Cependant, AWS ParallelCluster les processus ne maintiennent pas la partition dans un UP état. Vous devez modifier l'état des partitions manuellement. Tous les nœuds statiques sont disponibles au bout de quelques minutes. Notez que le fait de définir une partition sur UP n'augmente aucune capacité dynamique.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status START_REQUESTED

Lorsqu'il update-compute-fleet est exécuté, vous pouvez vérifier l'état du cluster en exécutant la pcluster describe-compute-fleet commande et en vérifiant leStatus. La liste suivante répertorie les états possibles :

• STOP_REQUESTED: La demande d'arrêt du parc informatique est envoyée au cluster.

• STOPPING: Le pcluster processus arrête actuellement le parc informatique.

• 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 demande de démarrage de la flotte de calcul est envoyée au cluster.

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

• RUNNING: le pcluster processus de démarrage est terminé, toutes les partitions sont en UP état et les nœuds statiques sont disponibles au bout de quelques minutes.

• PROTECTED: Cet état indique que certaines partitions présentent des échecs d'amorçage constants. Les partitions concernées sont inactives. Examinez le problème, puis lancez-vous update-compute-fleet pour réactiver le parc.

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 (connue sous le nom de partition dansSlurm) d'un cluster. Vous pouvez gérer les nœuds d'un cluster à l'aide des procédures courantes suivantes à l'aide de la scontrol commande.

• Allumez les nœuds dynamiques en POWER_SAVING état

  Exécutez la commande en tant qu'utilisateur su root :

  $ scontrol update nodename=nodename state=power_up

  Vous pouvez également soumettre une sleep 1 tâche fictive demandant un certain nombre de nœuds, puis vous en servir Slurm pour alimenter le nombre de nœuds requis.

• Éteignez les nœuds dynamiques avant ScaledownIdletime

  Nous vous recommandons de définir les nœuds dynamiques en DOWN tant qu'utilisateur su root à l'aide de la commande suivante :

  $ scontrol update nodename=nodename state=down reason="manually draining"

  AWS ParallelCluster arrête et réinitialise automatiquement les nœuds dynamiques tombés en panne.

  En général, il est déconseillé de définir les nœuds sur POWER_DOWN directement à l'aide de la scontrol update nodename=nodename state=power_down commande. Cela est dû au fait que le processus de mise hors tension est AWS ParallelCluster automatiquement géré.

• Désactiver une file d'attente (partition) ou arrêter tous les nœuds statiques d'une partition spécifique

  Définissez une file d'attente spécifique en INACTIVE tant qu'utilisateur su root à l'aide de la commande :

  $ scontrol update partition=queuename state=inactive

  Cela met fin à toutes les instances qui soutiennent les nœuds de la partition.

• Activer une file d'attente (partition)

  Définissez une file d'attente spécifique pour UP un utilisateur su root à l'aide de la commande :

  $ scontrol update partition=queuename state=up

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-spotcompute1-[1-2]).

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

• Les instances sont configurées et rejoignent le cluster. Une tâche commence à s'exécuter sur des instances.

• La tâche se termine et s'arrête.

• Une fois la configuration SuspendTime expirée (qui est définie sur ScaledownIdletime), le planificateur définit l'état des instances. POWER_SAVING Le planificateur passe ensuite queue1-dy-spotcompute1-[1-2] à l'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 en restant 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-spotcompute1-[1-2] à l'état inactif et réinitialise l'adresse IP privée et le nom d'hôte afin qu'il soit prêt à fonctionner pour de futures tâches.

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 fait passer deux nœuds éclatants dans le cloud à l'POWER_UPétat et appelle ResumeProgram avec les noms de nœuds (par exemple). queue1-dy-spotcompute1-[1-2]

• ResumeProgramlance une (1) seule instance Amazon EC2 et la configurequeue1-dy-spotcompute1-1, avec une (1) instancequeue1-dy-spotcompute1-2, en échouant au lancement.

• queue1-dy-spotcompute1-1n'est pas concerné et se connecte après avoir atteint l'POWER_UPÉtat.

• queue1-dy-spotcompute1-2passe à l'POWER_DOWNétat, et la tâche est automatiquement mise en attente car elle Slurm détecte une défaillance du nœud.

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

• Le processus ci-dessus se répète jusqu'à ce que la tâche puisse s'exécuter sur un nœud disponible sans qu'une défaillance se produise.

Deux paramètres de chronométrage peuvent être ajustés si nécessaire :

• ResumeTimeout(la valeur par défaut est de 30 minutes) : ResumeTimeout contrôle le temps d'Slurmattente avant de faire passer le nœud à l'état inactif.

  • Il peut être utile d'étendre ResumeTimeout si votre processus de pré-installation ou de post-installation prend presque autant de temps.

  • ResumeTimeoutest également le temps d' AWS ParallelCluster attente maximal 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. AWS ParallelCluster les processus remplacent un nœud lors de la détection d'une instance interrompue.

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

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

  • Une valeur plus longue SuspendTimeout signifie que les nœuds défaillants sont réinitialisés plus lentement. En attendant, Slurm essaie d'utiliser d'autres nœuds. Si cela SuspendTimeout dure plus de quelques minutes, Slurm essaie de parcourir tous les nœuds du système. Un délai plus long SuspendTimeout peut être bénéfique pour les systèmes à grande échelle (plus de 1 000 nœuds) afin de réduire le stress Slurm lorsqu'ils tentent fréquemment de remettre en file d'attente des 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 résiliées. Le processus de terminaison est généralement terminé en quelques minutes. Cependant, pendant ce temps, le nœud reste dans cet POWER_DOWN état et n'est pas disponible pour l'utilisation du planificateur.

Logs pour l'architecture

La liste suivante contient les journaux clés. Le nom du flux de journal utilisé avec Amazon CloudWatch Logs a le format {hostname}.{instance_id}.{logIdentifier} suivant lequel LogIdentifier suit les noms des journaux.

• 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 réussi à démarrer, à démarrer ou à rejoindre le cluster

• Nœuds dynamiques :

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

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

  • Si une instance a été lancée, il se peut qu'il y ait eu un problème pendant le processus de démarrage. Trouvez l'adresse IP privée et l'ID d'instance correspondants dans le ResumeProgram journal et consultez les journaux de démarrage 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 les instances ne se sont pas lancées, il devrait y avoir des erreurs claires expliquant pourquoi elles n'ont pas pu être lancées.

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

Nœuds remplacés ou interrompus de manière inattendue, et défaillances de nœuds

• Nœuds remplacés/interrompus de façon inattendue :

  • 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 résiliation du nœud, un message doit apparaître indiquant le motif 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 à Amazon EC2, utilisez des outils tels qu'Amazon CloudWatch ou la console Amazon EC2, la CLI ou les kits SDK pour vérifier le statut ou les journaux de cette instance. Par exemple, vous pouvez vérifier si l'instance a connu des événements planifiés ou si les vérifications de l'état de santé d'Amazon EC2 ont échoué.

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

• Défaillances des 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 évaluez la situation à partir de là.

Défaillance lors du remplacement ou de l'arrêt d'instances, défaillance lors de la mise hors tension des nœuds

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

• En cas d'échec de nœuds dynamiques ScaledownIdletime, consultez le SuspendProgram journal pour voir si slurmctld les processus ont effectué des appels avec le nœud spécifique comme argument. Remarque SuspendProgram n'effectue en fait aucune action spécifique. Au contraire, il ne se connecte que lorsqu'il est appelé. Toutes les fermetures et NodeAddr réinitialisations d'instances sont terminées parclustermgtd. Slurmfait passer les nœuds vers les IDLE nœuds suivantsSuspendTimeout.

Autres problèmes :

• AWS ParallelCluster ne prend pas de décisions relatives à l'attribution des tâches ou à la mise à l'échelle. Il essaie uniquement de lancer, d'arrêter et de maintenir les ressources conformément Slurm aux instructions.

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