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 mode protégé par cluster
Lorsqu'un cluster s'exécute avec le mode protégé activé, il AWS ParallelCluster surveille et suit les défaillances de démarrage des nœuds de calcul lors du lancement des nœuds de calcul. Il le fait pour détecter si ces défaillances se produisent en continu.
Si les éléments suivants sont détectés dans une file d'attente (partition), le cluster passe à l'état protégé :
1. Les défaillances consécutives du bootstrap du nœud de calcul se produisent continuellement en l'absence de lancement réussi du nœud de calcul.
1. Le nombre de défaillances atteint un seuil prédéfini.
Une fois que le cluster est devenu protégé, AWS ParallelCluster désactive les files d'attente présentant des défaillances égales ou supérieures au seuil prédéfini.
Slurm le mode protégé par cluster a été ajouté dans AWS ParallelCluster la version 3.0.0.
Vous pouvez utiliser le mode protégé pour réduire le temps et les ressources consacrés au cycle de défaillance du bootstrap des nœuds de calcul.
## Paramètre du mode protégé
**`protected_failure_count`**
`protected_failure_count`indique le nombre de défaillances consécutives dans une file d'attente (partition) qui active le statut de protection du cluster.
La valeur par défaut `protected_failure_count` est 10 et le mode protégé est activé.
S'il `protected_failure_count` est supérieur à zéro, le mode protégé est activé.
S'`protected_failure_count`il est inférieur ou égal à zéro, le mode protégé est désactivé.
Vous pouvez modifier la `protected_failure_count` valeur en ajoutant le paramètre dans le fichier de `clustermgtd` configuration situé `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` dans le`HeadNode`.
Vous pouvez mettre à jour ce paramètre à tout moment et vous n'avez pas besoin d'arrêter le parc informatique pour le faire. Si un lancement réussit dans une file d'attente avant que le nombre d'échecs n'atteigne`protected_failure_count`, le nombre d'échecs est remis à zéro.
## Vérifier l'état du cluster dans l'état protégé
Lorsqu'un cluster est protégé, vous pouvez vérifier l'état du parc informatique et l'état des nœuds.
### Calculer l'état du parc
L'état du parc informatique est celui `PROTECTED` d'un cluster fonctionnant en état protégé.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### État du nœud
Pour savoir quelles files d'attente (partitions) présentent des défaillances de démarrage ayant activé le statut protégé, connectez-vous au cluster et exécutez la `sinfo` commande. Les partitions présentant des défaillances de bootstrap égales ou supérieures `protected_failure_count` sont dans `INACTIVE` cet état. Les partitions ne présentant pas d'échec du bootstrap égal ou supérieur `protected_failure_count` sont dans l'`UP`état et fonctionnent comme prévu.
`PROTECTED`le statut n'a aucun impact sur les tâches en cours d'exécution. Si des tâches sont exécutées sur une partition présentant des échecs de démarrage égaux ou supérieurs`protected_failure_count`, la partition est définie sur une `INACTIVE` fois les tâches en cours d'exécution terminées.
Examinez les états des nœuds illustrés dans l'exemple suivant.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
`queue1`La partition est `INACTIVE` due au fait que 10 défaillances consécutives du bootstrap du nœud de calcul ont été détectées.
Les instances situées derrière les nœuds ont `queue1-dy-c5xlarge-[1-10]` été lancées mais n'ont pas réussi à rejoindre le cluster en raison d'un état défectueux.
Le cluster est protégé.
La partition `queue2` n'est pas affectée par les échecs de bootstrap dans`queue1`. Il est dans l'`UP`état et peut toujours exécuter des tâches.
## Comment désactiver le statut protégé
Une fois l'erreur de démarrage résolue, vous pouvez exécuter la commande suivante pour sortir le cluster de son statut protégé.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## Défaillances du bootstrap qui activent le statut protégé
Les erreurs de démarrage qui activent le statut protégé sont subdivisées en trois types suivants. Pour identifier le type et le problème, vous pouvez vérifier si des journaux AWS ParallelCluster ont été générés. Si des journaux ont été générés, vous pouvez vérifier les détails des erreurs. Pour de plus amples informations, veuillez consulter [Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
1. **Erreur de démarrage qui provoque l'arrêt automatique d'une instance**.
Une instance échoue au début du processus de démarrage, par exemple une instance qui s'arrête automatiquement en raison d'erreurs dans le script [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)\$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)\$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1. [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)
Pour les nœuds dynamiques, recherchez les erreurs similaires aux suivantes :
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
Pour les nœuds statiques, recherchez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) les erreurs similaires aux suivantes :
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **Nœuds `resume_timeout` ou `node_replacement_timeout` expirations**.
Une instance ne peut pas rejoindre le cluster au sein du `resume_timeout` (pour les nœuds dynamiques) ou `node_replacement_timeout` (pour les nœuds statiques). Il ne s'arrête pas automatiquement avant le délai imparti. Par exemple, le réseau n'est pas configuré correctement pour le cluster et le nœud est défini sur l'`DOWN`état par Slurm une fois le délai expiré.
Pour les nœuds dynamiques, recherchez les erreurs similaires aux suivantes :
```
Node bootstrap error: Resume timeout expires for node
```
Pour les nœuds statiques, recherchez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) les erreurs similaires aux suivantes :
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. Le **contrôle de santé des nœuds échoue**.
Une instance située derrière le nœud échoue à un bilan de EC2 santé Amazon ou à un contrôle d'état d'un événement planifié, et les nœuds sont traités comme des nœuds de défaillance du bootstrap. Dans ce cas, l'instance se termine pour une raison indépendante de la volonté de AWS ParallelCluster.
Recherchez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) les erreurs similaires aux suivantes :
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **Défaillance des nœuds de calcul Slurm enregistrement**.
L'enregistrement du `slurmd` daemon auprès du Slurm control daemon (`slurmctld`) échoue et fait passer l'état du nœud de calcul à `INVALID_REG` cet état. Configuration incorrecte Slurm les nœuds de calcul peuvent provoquer cette erreur, par exemple les nœuds calculés configurés avec des erreurs de spécification des nœuds de [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)calcul.
Consultez le fichier `slurmctld` journal (`/var/log/slurmctld.log`) du nœud principal ou le fichier `slurmd` journal (`/var/log/slurmd.log`) du nœud de calcul défaillant pour détecter des erreurs similaires aux suivantes :
```
Setting node %s to INVAL with reason: ...
```
## Comment déboguer le mode protégé
Si votre cluster est protégé et s'il a AWS ParallelCluster généré des `clustermgtd` journaux à partir des nœuds de calcul problématiques `HeadNode` et des `cloud-init-output` journaux à partir de nœuds de calcul, vous pouvez consulter les journaux pour obtenir des informations détaillées sur les erreurs. Pour plus d'informations sur la façon de récupérer les journaux, consultez[Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
**`clustermgtd`log (`/var/log/parallelcluster/clustermgtd`) sur le nœud principal**
Les messages du journal indiquent quelles partitions présentent des échecs d'amorçage et le nombre d'échecs d'amorçage correspondant.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
Dans le `clustermgtd` journal, recherchez le `Found the following bootstrap failure nodes` nœud qui n'a pas pu démarrer.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
Dans le `clustermgtd` journal, recherchez `Node bootstrap error` la raison de l'échec.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**`cloud-init-output`log (`/var/log/cloud-init-output.log`) sur les nœuds de calcul**
Après avoir obtenu l'adresse IP privée du nœud de défaillance du bootstrap dans le `clustermgtd` journal, vous pouvez trouver le journal du nœud de calcul correspondant en vous connectant au nœud de calcul ou en suivant les instructions [Récupération et conservation des journaux](troubleshooting-v3-get-logs.md) pour récupérer les journaux. Dans la plupart des cas, le `/var/log/cloud-init-output` journal du nœud problématique indique l'étape à l'origine de l'échec du bootstrap du nœud de calcul.