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
Ici, vous pouvez apprendre comment Slurm gérer AWS ParallelCluster les nœuds de file d'attente (partition) et comment surveiller l'état des files d'attente et des nœuds.
## Présentation de
L'architecture de mise à l'échelle est basée sur le [guide Slurm de planification cloud](https://slurm.schedmd.com/elastic_computing.html) 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](https://slurm.schedmd.com/power_save.html). 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 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 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 exemple`idle#`) 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 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 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 exemple`idle%`) dans. `sinfo` Les nœuds dynamiques entrent automatiquement dans l'`POWER_DOWN`état suivant [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime).
Le [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)paramètre est enregistré dans le `SuspendTimeout` paramètre Slurm de configuration.
+ **Un nœud hors ligne apparaît** avec un `*` suffixe (par exemple`down*`) dans`sinfo`. 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'`sinfo`exemple 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 d'ici 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 exemple`ssh 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 (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 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'`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 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`), probablement en attente de la disponibilité des instances.
```
# 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 sont défectueuses. Pour de plus amples informations, veuillez consulter [`clustermgtd`](processes-v3.md#clustermgtd-v3).
## É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 le`Status`. 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 (appelée 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 exemple`queue1-dy-spotcompute1-[1-2]`).
+ `ResumeProgram`lance deux instances Amazon EC2 et attribue les adresses IP privées et les noms d'hôte de`queue1-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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.
+ `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-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 à être redémarré 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]`
+ `ResumeProgram`lance une (1) seule instance Amazon EC2 et la configure`queue1-dy-spotcompute1-1`, avec une (1) instance`queue1-dy-spotcompute1-2`, en échouant au lancement.
+ `queue1-dy-spotcompute1-1`n'est pas concerné et se connecte après avoir atteint l'`POWER_UP`État.
+ `queue1-dy-spotcompute1-2`passe à 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-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 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 de procéder à une extension `ResumeTimeout` si le processus pre/post d'installation prend presque autant de temps.
+ `ResumeTimeout`est é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 `POWER_DOWN` cet état et n'est pas disponible pour le planificateur.
## Logs pour l'architecture
La liste suivante contient les journaux clés. 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.
+ `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'`ResumeProgram`il 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, des erreurs claires devraient apparaître quant à la raison pour laquelle 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 de replaced/terminated manière 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 à 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 par`clustermgtd`. Slurmfait passer les nœuds vers les `IDLE` nœuds suivants`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 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.