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.
# Slurmguide 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 avec la nouvelle architecture de mise à l'échelle.
## Présentation de
La nouvelle architecture de mise à l'échelle est basée sur le [guide Slurm de planification dans le cloud](https://slurm.schedmd.com/elastic_computing.html) 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](https://slurm.schedmd.com/power_save.html). Dans la nouvelle 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 suivants`POWER_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 exemple`idle~`) dans`sinfo`. Dans cet état, aucune instance EC2 ne soutient 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 exemple`idle#`) dans. `sinfo`
+ Lorsqu'il Slurm alloue une tâche à un nœud dans un `POWER_SAVING` état, le nœud est automatiquement transféré vers 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 instances EC2 sont lancées et configurées pour sauvegarder un `POWER_UP` nœud.
+ Un nœud actuellement disponible apparaît sans suffixe (par exemple`idle`) dans`sinfo`. 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 dans EC2 soit identique au 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 exemple`idle%`) dans. `sinfo` Les nœuds dynamiques entrent automatiquement dans leur `POWER_DOWN` état par la suite[`scaledown_idletime`](scaling-section.md#scaledown-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 suite[`scaledown_idletime`](scaling-section.md#scaledown-idletime). Le `scaledown-idletime` paramètre est enregistré dans la Slurm configuration en tant que `SuspendTimeout` paramètre.
+ Un nœud hors ligne apparaît avec un `*` suffixe (par exemple`down*`) dans`sinfo`. Un nœud se déconnecte 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 résiliées.
Examinons maintenant les états des nœuds illustrés dans l'`sinfo`exemple 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`](scaling-section.md#scaledown-idletime) (120 secondes par défaut).
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 en SSH (par exemple`ssh 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 instance 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 (connue sous le nom de 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 exemple`c5.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'`spot`agit 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 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 ne fonctionnent pas correctement. Pour de plus amples informations, veuillez consulter [`clustermgtd`](processes.md#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 active. 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`](pcluster.stop.md) 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`](pcluster.start.md) 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`](compute-resource-section.md#compute-resource-initial-count) cette valeur est supérieure à[`max_count`](compute-resource-section.md#compute-resource-max-count), elle [`initial_count`](compute-resource-section.md#compute-resource-initial-count) peut ne pas être satisfaite lorsque l'état de la partition passe à l'`UP`état actuel.
Lorsqu'il est [`pcluster start`](pcluster.start.md) [`pcluster stop`](pcluster.stop.md) en cours d'exécution, vous pouvez vérifier l'état du cluster en exécutant la [`pcluster status`](pcluster.status.md) commande et en vérifiant le`ComputeFleetStatus`. La liste suivante répertorie les états possibles :
+ `STOP_REQUESTED`: La [`pcluster stop`](pcluster.stop.md) demande est envoyée au cluster.
+ `STOPPING`: le `pcluster` processus arrête actuellement 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`](pcluster.start.md) demande est envoyée au cluster.
+ `STARTING`: le `pcluster` processus démarre actuellement 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 (appelée partition dansSlurm) d'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 cette tâche Slurm pour alimenter le nombre de nœuds requis.
+ Éteignez les nœuds dynamiques avant [`scaledown_idletime`](scaling-section.md#scaledown-idletime) : définissez les nœuds dynamiques sur à l'`DOWN`aide 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_DOWN`ils 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'`INACTIVE`aide 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 exemple`queue1-dy-c5xlarge-[1-2]`).
+ `ResumeProgram`lance deux instances EC2 et attribue les adresses IP privées et les noms d'hôte de`queue1-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 sur[`scaledown_idletime`](scaling-section.md#scaledown-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.
+ `SuspendProgram`est 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]`
+ `ResumeProgram`lance une (1) seule instance EC2 et la configure`queue1-dy-c5xlarge-1`, mais aucune instance n'a pu être lancée pour. `queue1-dy-c5xlarge-2`
+ `queue1-dy-c5xlarge-1`ne sera pas affecté et sera mis en ligne après avoir atteint `POWER_UP` l'état.
+ `queue1-dy-c5xlarge-2`est mis en `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-c5xlarge-2`devient 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 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 inactif.
+ Il peut être utile de l'étendre si votre processus pre/post d'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 qu'ils pourront essayer de lancer des instances plus fréquemment.
+ Une durée plus `SuspendTimeout` longue ralentit la réinitialisation des nœuds défaillants. En attendant, essaie Slurm 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) car il 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 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 est au format `{hostname}.{instance_id}.{logIdentifier}` *logIdentifier* suivant lequel suivent les noms des journaux. Pour de plus amples informations, veuillez consulter [Intégration à Amazon CloudWatch Logs](cloudwatch-logs.md).
+ `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 vous avez Slurm déjà essayé `ResumeProgram` d'appeler le nœud. Notez que des autorisations incorrectes `ResumeProgram` peuvent entraîner son échec silencieux.
+ S'`ResumeProgram`il 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**
+ Des nœuds de replaced/terminated 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'était`DOWN`), 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 a connu des événements planifiés ou si les vérifications de l'état de santé 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 de nœuds
+ Dans la plupart des cas, les tâches sont automatiquement mises en 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 dynamique[`scaledown_idletime`](scaling-section.md#scaledown-idletime), consultez le `SuspendProgram` journal pour voir si un programme `slurmctld` utilise le nœud spécifique comme argument. Remarque `SuspendProgram` n'exécute 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 par`clustermgtd`. Slurmplace les nœuds dans `IDLE` After`SuspendTimeout`.
**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 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.