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

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

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, consultezRécupérez les journaux d'instance.

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

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

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 :

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.11ACTIVE, 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, consultezVersions Slurm en AWS PIÈCES.

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ésUPDATING. 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é, 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 :

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, consultezAmazon Machine Images (AMI) pour AWS PIÈCES. Pour plus d'informations sur les versions de l'agent AWS PCS, consultezAWS Versions de l'agent PCS.

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 AllowQOSDenyQOS, ou avant de mettre à jour le cluster.