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.
# Résolution des problèmes AWS Mises à jour de la version du cluster
Cette rubrique vous aide à identifier et à résoudre les problèmes courants qui peuvent survenir lors de la mise à jour de la version du planificateur sur un cluster.
+ [Les nœuds de calcul ne parviennent pas à se connecter après la mise à jour](#update-troubleshooting-nodes-fail)
+ [Demande de mise à jour rejetée avec ValidationException](#update-troubleshooting-validation-error)
+ [Le cluster reste en état de mise à jour](#update-troubleshooting-stuck-updating)
+ [Le cluster passe à l'état UPDATE\_FAILED après la mise à jour](#update-troubleshooting-update-failed)
+ [Les nœuds de calcul ne démarrent pas en raison d'erreurs d'analyse de configuration](#update-troubleshooting-config-parse)
+ [Cluster non disponible après la mise à jour en raison d'une configuration QoS non valide](#update-troubleshooting-qos-bootloop)
## Les nœuds de calcul ne parviennent pas à se connecter après la mise à jour
### Cause courante
Après la mise à jour du cluster, les nœuds de calcul récemment lancés ne parviennent pas à s'enregistrer auprès du contrôleur. Les nœuds démarrent mais n'apparaissent jamais en `sinfo` sortie, et le groupe de nœuds de calcul peut parcourir les instances à plusieurs reprises. Cela se produit lorsque l'AMI du groupe de nœuds de calcul contient une version du planificateur qui ne figure pas dans la fenêtre de compatibilité de la nouvelle version du contrôleur.
Par exemple, si vous mettez à jour un cluster de la version 24.11 à la version 25.11 mais que le groupe de nœuds de calcul utilise toujours une AMI avec Slurm 23.11, les nouvelles instances ne peuvent pas se connecter car la version 23.11 est en dehors de la fenêtre de compatibilité de la version 25.11.
### Comment diagnostiquer
Vous pouvez confirmer ce problème en consultant les journaux à deux endroits :
**Journaux du planificateur**
Si la journalisation du planificateur est activée, vérifiez que les journaux du planificateur ne contiennent pas d' CloudWatch erreurs similaires aux suivantes :
```
error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [{{ip-10-0-1-23}}] Incompatible versions of client and server code
```
Ces erreurs indiquent qu'un nœud de calcul dont la version du planificateur est incompatible essaie de se connecter au contrôleur. Pour plus d'informations sur la configuration de la journalisation du planificateur, consultez. [Le planificateur enregistre dans PCS AWS](monitoring_scheduler-logs.md)
**Journaux des instances des nœuds de calcul**
Récupérez la sortie de la console de l'instance ou connectez-vous via Systems Manager et vérifiez que le journal de démarrage ne contient pas d'erreurs similaires aux suivantes :
```
error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed
```
Pour plus d'informations sur la récupération des journaux d'instance, consultez[Récupérez les journaux d'instance](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs).
### Résolution
Mettez à jour le groupe de nœuds de calcul pour utiliser une AMI contenant une version du planificateur dans la fenêtre de compatibilité de votre nouvelle version de cluster :
```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng}} \
--ami-id {{ami-0123456789abcdef0}}
```
Pour déterminer quelles versions du planificateur sont compatibles avec votre cluster, consultez. [Compatibilité des versions](working-with_clusters_version_update.md#version_update-cluster-compatibility)
Pour plus d'informations sur la création d'AMI personnalisées avec la bonne version du planificateur, consultez. [Amazon Machine Images (AMI) pour AWS PIÈCES](working-with_ami.md)
## Demande de mise à jour rejetée avec ValidationException
### Cause courante
La `UpdateCluster` demande est renvoyée immédiatement avec une `ValidationException` erreur indiquant que la mise à jour n'est pas prise en charge. Cela se produit lorsque :
+ La version cible se trouve en dehors de la [fenêtre de compatibilité](https://slurm.schedmd.com/upgrades.html#compatibility_window) de la version actuelle.
+ La version cible est désignée comme étant en fin de vie (EOL) et n'est plus une cible de mise à jour valide.
+ La version cible est antérieure ou égale à la version actuelle (les rétrogradations ne sont pas prises en charge).
### Résolution
Si la version cible se trouve en dehors de la fenêtre de compatibilité, effectuez la mise à jour en plusieurs étapes. Chaque étape doit cibler une version prise en charge dans la fenêtre de compatibilité. Par exemple, pour passer de la version 23.11 à la version 25.11, commencez par effectuer la mise à jour vers la version 25.05, attendez que le cluster revienne à la version 25.11`ACTIVE`, puis effectuez la mise à jour vers la version 25.11.
Si la version cible est EOL, choisissez plutôt une version prise en charge plus récente. Pour plus d'informations sur les versions prises en charge, consultez[Versions Slurm en AWS PIÈCES](slurm-versions.md).
## Le cluster reste en état de mise à jour
### Cause courante
Le cluster reste en `UPDATING` état plus longtemps que prévu (plus de 20 minutes). Cela peut être dû à des problèmes internes transitoires au cours du processus de mise à jour.
### Résolution
AWS PCS restaure automatiquement les clusters bloqués`UPDATING`. Si le cluster ne revient pas dans les `ACTIVE` 30 `UPDATE_FAILED` minutes, contactez le AWS Support pour obtenir de l'aide.
## Le cluster passe à l'état UPDATE\_FAILED après la mise à jour
### Cause courante
Le cluster passe à `UPDATE_FAILED` l'état pendant la mise à jour. Cela peut se produire lorsque des erreurs de service transitoires empêchent la mise à jour de se terminer correctement.
### Résolution
Réessayez la mise à jour en soumettant à nouveau la même `UpdateCluster` demande. Les clusters en `UPDATE_FAILED` état acceptent les nouvelles demandes de mise à jour. Si la mise à jour échoue toujours, contactez le AWS Support.
## Les nœuds de calcul ne démarrent pas en raison d'erreurs d'analyse de configuration
### Cause courante
Après la mise à jour du cluster, les nœuds de calcul ne démarrent pas et n'apparaissent jamais dans la `sinfo` sortie. Les journaux des instances du nœud de calcul indiquent des erreurs similaires aux suivantes :
```
error: _parse_next_key: Parsing error at unrecognized key: {{HashPlugin}}
error: Invalid DebugFlag: {{AuditRPCs}}
fatal: Unable to process configuration file
```
Cela se produit lorsque les nœuds de calcul exécutant la version 23.11 du planificateur reçoivent la configuration d'une version de cluster plus récente. Les versions du planificateur postérieures à 23.11 ont introduit de nouvelles directives de configuration que 23.11 ne peut pas analyser. Contrairement aux autres versions incluses dans la [fenêtre de compatibilité](https://slurm.schedmd.com/upgrades.html#compatibility_window), les nœuds de calcul 23.11 ne peuvent pas se connecter à un cluster plus récent car ils génèrent une erreur fatale sur des clés de configuration non reconnues.
Ce problème peut également se produire si votre AMI personnalisée utilise une version d'agent AWS PCS antérieure à la version v1.4.0. Les anciennes versions de l'agent ne prennent pas en charge le remplacement automatique des versions pour le démon du nœud de calcul.
### Résolution
Reconstruisez votre AMI personnalisée en respectant les exigences suivantes :
+ Scheduler version 24.05 ou ultérieure
+ AWS Agent PCS version 1.4.0 ou ultérieure
Mettez ensuite à jour le groupe de nœuds de calcul pour utiliser la nouvelle AMI :
```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng}} \
--ami-id {{ami-0123456789abcdef0}}
```
Pour plus d'informations sur la création d'AMI personnalisées, consultez[Amazon Machine Images (AMI) pour AWS PIÈCES](working-with_ami.md). Pour plus d'informations sur les versions de l'agent AWS PCS, consultez[AWS Versions de l'agent PCS](pcs-agent-versions.md).
## Cluster non disponible après la mise à jour en raison d'une configuration QoS non valide
### Cause courante
Après la mise à jour vers la version 25.11, le cluster passe à l'`UPDATE_FAILED`état ou le planificateur devient indisponible. Vous ne pouvez pas soumettre de tâches ni exécuter de commandes de planificateur. Les journaux du planificateur indiquent des erreurs similaires aux suivantes :
```
error: Invalid Allow/DenyQOS value: {{low}}
fatal: Partition {{my-queue}} has an invalid DenyQOS ({{low}}), please check your configuration
```
Cela se produit lorsqu'une file d'attente (partition) fait référence à un nom QoS via `AllowQOS` ou à des `QOS` paramètres qui n'existent pas dans la base de données de comptabilité Slurm. `DenyQOS` Slurm 25.11 a introduit une validation plus stricte des références QoS au démarrage du planificateur. Les versions antérieures permettaient de faire référence à des noms de QoS inexistants sans erreur.
### Résolution
Avant de passer à la version 25.11, vérifiez que tous les noms de QoS référencés dans vos configurations de file d'attente existent dans la base de données de comptabilité. Connectez-vous à un nœud de connexion et exécutez la commande suivante pour vérifier si une QoS existe :
```
sacctmgr show qos where name={{low}} format=name
```
Si le QoS n'existe pas, créez-le avant de tenter la mise à jour :
```
sacctmgr add qos {{low}}
```
Vous pouvez également supprimer la référence QoS de la configuration de votre file d'attente en mettant à jour les paramètres personnalisés Slurm de la file d'attente pour supprimer le `QOS` paramètre `AllowQOS``DenyQOS`, ou avant de mettre à jour le cluster.