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

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

La commande pcluster update-cluster ne s'exécute pas localement

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

Le délai de mise à jour du cluster a expiré

Il peut s'agir d'un problème lié à l'cfn-hupinexé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 lorsque cfn-hup n'est pas en cours d'exécution la section pour résoudre le problème et résoudre le problème.

ClusterStatus est UPDATE_FAILED

Provoquant les racines

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 AWS ParallelCluster sur Activé GitHub.

Prévenir

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

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

ClusterStatus est UPDATE_FAILED et le cloud est UPDATE_ROLLBACK_FAILED FormationStackStatus

Lorsque vous pcluster describe-cluster signalez que clusterStatus c'est le cas UPDATE_FAILED et que cloudFormationStackStatus c'est le casUPDATE_ROLLBACK_FAILED, la mise à jour du cluster et la restauration ultérieure ont échoué. Dans cet état, la pile de clusters ne peut accepter aucune autre mise à jour et nécessite une intervention manuelle pour être débloquée.

Pour débloquer la pile de clusters, procédez comme suit :

La pile de clusters apparaît bloquée dans UPDATE_IN_PROGRESS ou UPDATE_ROLLBACK_IN_PROGRESS

La pile de clusters peut être bloquée UPDATE_IN_PROGRESS ou UPDATE_ROLLBACK_IN_PROGRESS rester bloquée pendant une heure au maximum si le groupe Auto Scaling des nœuds de connexion ne parvient pas à se stabiliser en raison de défaillances du bootstrap dans les nœuds de connexion.

Pour vérifier si vous vous trouvez dans cette situation à cause du groupe Auto Scaling des nœuds de connexion, vous devez effectuer les vérifications suivantes : Dans la pile principale, la seule ressource présente UPDATE_IN_PROGRESS est la pile imbriquée des nœuds de connexion. Dans la pile imbriquée des nœuds de connexion, la seule ressource bloquée UPDATE_IN_PROGRESS est le groupe Auto Scaling des nœuds de connexion.

Dans ce scénario, vous pouvez annuler la mise à jour afin de ne pas avoir à attendre 1 heure pour qu'elle soit terminée.

$ aws cloudformation cancel-update-stack --region REGION --stack-name CLUSTER_STACK_NAME

L'annulation de la mise à jour déclenche le rollback. Vous ne pouvez pas réduire le délai d'une heure avant l'annulation. Dans le pire des cas, vous devez attendre que la restauration atteigne son état final.

Si l'annulation aboutit, vous pouvez immédiatement réessayer la mise à jour initiale de votre cluster une fois que vous avez résolu la cause première de l'échec. Sinon, consultez ClusterStatus est UPDATE_FAILED et le cloud est UPDATE_ROLLBACK_FAILED FormationStackStatus.