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.

# Essayer de mettre à jour un cluster
<a name="troubleshooting-fc-v3-update-cluster"></a>

La section suivante propose des solutions de résolution des problèmes susceptibles de se produire lorsque vous essayez de mettre à jour un cluster.

## `pcluster update-cluster`la commande ne s'exécute pas localement
<a name="update-cluster-failure-cli-v3"></a>

Consultez le fichier `~/.parallelcluster/pcluster-cli.log` de votre système de fichiers local pour obtenir des informations sur les défaillances.

## Voir `clusterStatus` c'est `UPDATE_FAILED` avec `pcluster describe-cluster` commande
<a name="update-cluster-failure-v3"></a>

### Provoquant les racines
<a name="update-cluster-failure-v3-root-causing"></a>

Pour identifier la cause première de la défaillance, il faut commencer par examiner les événements liés à la pile de clusters et `/var/log/chef-client.log` au nœud principal.

Cela peut être dû au fait qu'au moins un nœud du cluster n'a pas appliqué la mise à jour. Vous pouvez récupérer la liste des nœuds qui n'ont pas pu être mis à jour `/var/log/chef-client.log` dans le nœud principal en recherchant `Check cluster readiness` dans le journal.

Vérifiez si votre problème est mentionné dans la section [Problèmes GitHub connus](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster sur on GitHub.

### Prévenir
<a name="update-cluster-failure-v3-preventing"></a>

La mise à jour d'un cluster peut échouer si au moins un nœud du cluster n'a pas correctement appliqué la mise à jour. Pour réduire le risque d'échec de la mise à jour du cluster, nous vous recommandons de mettre fin aux nœuds défectueux avant de lancer la mise à jour. Les nœuds de calcul bloqués plus longtemps que la durée d'épilogue prévue constituent `COMPLETING` un exemple de nœuds susceptibles d'être cassés. Pour détecter ces nœuds, vous pouvez exécuter la commande suivante en adaptant la `threshold` valeur à vos besoins (la valeur doit être supérieure à la durée maximale prévue pour vos epilogs). 

```
$ scontrol show nodes --json | jq -r --argjson threshold 60 '
  .nodes[] | select(.state | index("COMPLETING")) |
  select((now - .last_busy.number) > $threshold) |
  .name
'
```

### Récupération
<a name="update-cluster-failure-v3-recovering"></a>

En cas d'échec de la mise à jour, le rollback est le mécanisme censé rétablir l'état du cluster.

 Si le rollback échoue, l'état du cluster n'est pas déterministe. Dans ce cas, il se peut que cela `clustermgtd` ait été arrêté pour éviter l'amplification des défaillances. Nous vous recommandons de le démarrer en exécutant la commande suivante sur le nœud principal. Adaptez la version de Python à celle livrée avec votre AWS ParallelCluster version : 

```
$ /opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd
```

## Le délai de mise à jour du cluster a expiré
<a name="update-cluster-failure-timeout-v3"></a>

Il peut s'agir d'un problème lié à l'`cfn-hup`inexécution. Si le `cfn-hup` démon est arrêté pour une cause externe, il n'est pas redémarré automatiquement. S'il `cfn-hup` n'est pas en cours d'exécution, lors d'une mise à jour du cluster, la CloudFormation pile lance le processus de mise à jour comme prévu, mais la procédure de mise à jour n'est pas activée sur le nœud principal et le déploiement de la pile finit par expirer. Pour plus d'informations, consultez [Résolution d'un délai d'expiration de mise à jour du cluster en cas `cfn-hup` d'inexécution](troubleshooting-v3-cluster-update-timeout.md) la section pour résoudre le problème et résoudre le problème.