Slurm guide pour le mode de file d'attente multiple - AWS ParallelCluster
PrésentationCycle de vie des nœuds cloudUtilisation d'un nœud disponibleÉtat des offres d'emploi et soumissionÉtat et fonctionnalités du nœudÉtats de partitiondémarrage et arrêt de pclusterContrôle manuel des files d'attenteComportement de dimensionnement et ajustementsJournaux pour une 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 de file d'attente multiple

AWS ParallelCluster la version 2.9.0 a introduit le mode de 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 doté de la nouvelle architecture de mise à l'échelle.

Présentation

La nouvelle architecture de mise à l'échelle est basée sur Slurmle guide de planification dans le cloud et le plugin d'économie d'énergie. Pour plus d'informations sur le plug-in d'économie d'énergie, voir Slurm Guide d'économie d'énergie. Dans la nouvelle architecture, les ressources susceptibles d'être mises à disposition pour un cluster sont généralement prédéfinies dans 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 EC2 instance ne soutient le nœud. Toutefois, Slurm peut 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

  • Lorsque Slurm alloue une tâche à un nœud dans un POWER_SAVING état, le nœud est automatiquement transféré dans un POWER_UP état. Sinon, les nœuds peuvent être placés dans l'POWER_UPétat manuellement à l'aide de la scontrol update nodename=nodename state=power_up commande. À ce stade, le ResumeProgram est invoqué, et les EC2 instances 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 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 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 leur POWER_DOWN état par la suitescaledown_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 l'POWER_DOWNé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 interrompue et le nœud est remis à son POWER_SAVING état pour une utilisation future par la suitescaledown_idletime. Le scaledown-idletime réglage est enregistré dans le Slurm configuration comme SuspendTimeout paramètre.

  • Un nœud hors ligne apparaît avec un * suffixe (par exempledown*) danssinfo. Un nœud est déconnecté si Slurm le 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 interrompues.

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 bon état et devraient être disponibles dans quelques minutes. Le gpu-dy-g38xlarge-1 nœud est dans l'POWER_DOWNétat, et il passera à POWER_SAVING l'état par la suite scaledown_idletime (120 secondes par défaut).

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

Utilisation d'un nœud disponible

Un nœud disponible est soutenu par une EC2 instance. Par défaut, le nom du nœud peut être utilisé pour accéder SSH directement à l'instance (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 vérifiant le NodeAddr champ. Pour les nœuds qui ne sont pas disponibles, le NodeAddr champ ne doit pas pointer vers une EC2 instance 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 (connue sous le nom de partition dans Slurm). 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 static de l'autre)

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 GPU nœud 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 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-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 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 sont défectueuses. Pour de plus amples informations, veuillez consulter clustermgtd.

États de partition

AWS ParallelCluster prend en charge les états de partition suivants. A Slurm la 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.

démarrage et arrêt de pcluster

Lorsqu'il pcluster stop est exécuté, toutes les partitions sont placées dans l'INACTIVEétat, et les AWS ParallelCluster processus les maintiennent dans INACTIVE cet état.

Lorsqu'il pcluster start est exécuté, toutes les partitions sont initialement placées dans UP cet é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. Si initial_count cette valeur est supérieure àmax_count, elle initial_count peut ne pas être satisfaite lorsque l'état de la partition passe à l'UPétat actuel.

Lorsqu'il est pcluster start pcluster stop en cours d'exécution, vous pouvez vérifier l'état du cluster en exécutant la pcluster status commande et en vérifiant leComputeFleetStatus. 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 de démarrage est terminé, 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 (connue sous le nom de partition dans Slurm) dans un cluster. Vous pouvez gérer les nœuds d'un cluster à l'aide des procédures courantes suivantes.

  • Activez 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 fictive demandant un certain nombre de nœuds et comptez sur Slurm pour alimenter le nombre de nœuds requis.

  • Éteignez les nœuds dynamiques 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 tombés en panne. En général, nous ne recommandons pas de configurer les nœuds pour qu'POWER_DOWNils utilisent directement 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é. Aucune intervention manuelle n'est nécessaire. Par conséquent, nous vous recommandons d'essayer de définir les nœuds sur DOWN chaque fois que cela est possible.

  • Désactiver une file d'attente (partition) ou arrêter tous les nœuds statiques d'une partition spécifique : définissez la file d'attente sur INACTIVE avec la scontrol update partition=queue name state=inactive commande. Cela 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 EC2 instances 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. Job commence à s'exécuter sur des instances.

  • Job est terminé.

  • Une fois la configuration SuspendTime expirée (qui est définie surscaledown_idletime), les instances sont mises dans l'POWER_SAVINGétat par le planificateur. Le planificateur place queue1-dy-c5xlarge-[1-2] dans POWER_DOWN l'é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-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 réalimentés pour de futures tâches.

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

  • ResumeProgramne lance qu'une (1) EC2 instance et la configurequeue1-dy-c5xlarge-1, mais il n'a pas réussi à lancer une instance pourqueue1-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é en POWER_DOWN état, et la tâche est automatiquement mise en attente car 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 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 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 60 minutes (1 heure)) : ResumeTimeout contrôle le temps Slurm attend avant de mettre le nœud à l'état inactif.

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

    • Il s'agit également du 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. 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 réinséré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 est capable d'essayer de lancer des instances plus fréquemment.

    • Une durée plus SuspendTimeout longue ralentit la réinitialisation des nœuds défaillants. Dans l'intervalle, Slurm essaie d'utiliser d'autres nœuds. Si SuspendTimeout c'est plus que 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 sur Slurm en remettant fréquemment en file d'attente les emplois défaillants.

    • 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 cette période, le nœud reste hors tension et n'est pas disponible pour une utilisation dans le planificateur.

Journaux pour une nouvelle architecture

La liste suivante contient les journaux clés de l'architecture à files d'attente multiples. Le nom du flux de journal utilisé avec Amazon CloudWatch Logs a le format {hostname}.{instance_id}.{logIdentifier} suivant : logIdentifier suit les noms des journaux. Pour de plus amples informations, veuillez consulter Intégration à 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 réussi à démarrer, à démarrer 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 Slurm J'ai déjà essayé d'appeler ResumeProgram avec 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 ne peut pas être lancée, un message d'erreur clair devrait s'afficher expliquant pourquoi le lancement de l'instance n'a pas pu être lancé.

    • 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. Dans le cas contraire, il devrait y avoir des erreurs claires expliquant pourquoi les instances n'ont pas pu être lancées.

    • Si une instance a été lancée, il y a un problème pendant le processus de démarrage. 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 façon inattendue, 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 EC2 liée, utilisez des outils 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 son état EC2 de santé ont échoué.

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

  • Défaillances 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à.

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 d'un nœud dynamiquescaledown_idletime, consultez le SuspendProgram journal pour voir si un programme slurmctld utilise 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é. La résiliation et la NodeAddr réinitialisation de toutes les instances sont terminées parclustermgtd. Slurm place les nœuds dans IDLE AfterSuspendTimeout.

Autres problèmes

  • AWS ParallelCluster ne prend pas de décisions relatives à l'attribution des tâches ou à la mise à l'échelle. Il essaie simplement de lancer, de résilier et de maintenir les ressources conformément à Slurminstructions.

    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.