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.
# AWS ParallelCluster résolution des problèmes
Les sections suivantes fournissent des conseils de résolution des problèmes susceptibles de survenir lors de l'utilisation AWS ParallelCluster. La AWS ParallelCluster communauté gère une page Wiki qui fournit de nombreux conseils de résolution des problèmes sur le [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/). Pour obtenir la liste des problèmes connus, consultez la section [Problèmes connus](https://github.com/aws/aws-parallelcluster/wiki#known-issues-).
**Topics**
+ [Essayer de créer un cluster](troubleshooting-fc-v3-create-cluster.md)
+ [Essayer d'exécuter une tâche](troubleshooting-fc-v3-run-job.md)
+ [Essayer de mettre à jour un cluster](troubleshooting-fc-v3-update-cluster.md)
+ [Essayer d'accéder au stockage](troubleshooting-fc-v3-access-storage.md)
+ [Essayer de supprimer un cluster](troubleshooting-fc-v3-delete-cluster.md)
+ [Essayer de mettre à niveau la pile AWS ParallelCluster d'API](troubleshooting-fc-v3-upgrade-stack-v3.md)
+ [Observation des erreurs lors de l'initialisation des nœuds de calcul](troubleshooting-fc-v3-compute-node-initialization-v3.md)
+ [Résolution des problèmes liés aux indicateurs de santé du](troubleshooting-v3-cluster-health-metrics.md)
+ [Résolution des problèmes de déploiement de clusters](troubleshooting-v3-cluster-deployment.md)
+ [Résolution des problèmes de déploiement de clusters à l'aide de Terraform](troubleshooting-v3-terraform.md)
+ [Résolution des problèmes de dimensionnement](troubleshooting-v3-scaling-issues.md)
+ [Problèmes liés aux groupes de placement et au lancement d'instances](troubleshooting-v3-placemment-groups.md)
+ [Remplacement de répertoires](troubleshooting-v3-dirs-must-keep.md)
+ [Résolution des problèmes dans Amazon DCV](troubleshooting-v3-nice-dcv.md)
+ [Résolution des problèmes dans les clusters avec AWS Batch intégration](troubleshooting-v3-batch.md)
+ [Résolution des problèmes d'intégration multi-utilisateurs avec Active Directory](troubleshooting-v3-multi-user.md)
+ [Résolution des problèmes liés aux AMI personnalisées](troubleshooting-v3-custom-amis.md)
+ [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)
+ [Dépannage du réseau](troubleshooting-v3-networking.md)
+ [La mise à jour du cluster a échoué lors d'`onNodeUpdated`une action personnalisée](troubleshooting-v3-on-node-updated.md)
+ [Voir les erreurs liées à la Slurm configuration personnalisée](troubleshooting-v3-custom-slurm-config.md)
+ [Alarmes de cluster](troubleshooting-v3-cluster-alarms.md)
+ [Résolution des modifications de configuration du système d'exploitation à l'origine d'erreurs ou de défaillances](resolving-os-configuration-changes.md)
# Essayer de créer un cluster
Lorsque vous utilisez AWS ParallelCluster la version 3.5.0 ou ultérieure pour créer un cluster et que la création d'un cluster a échoué avec `--rollback-on-failure` set to`false`, utilisez la commande [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md) CLI pour obtenir des informations sur l'état et les défaillances. Dans ce cas, le `pcluster describe-cluster` résultat attendu `clusterStatus` est`CREATE_FAILED`. Consultez la `failures` section de la sortie pour trouver le `failureCode` et`failureReason`. Ensuite, dans la section suivante, recherchez la solution correspondante `failureCode` pour obtenir une aide supplémentaire en matière de dépannage. Pour de plus amples informations, veuillez consulter [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md).
Dans les sections suivantes, nous vous recommandons de consulter les journaux du nœud principal, tels que les `/var/log/chef-client.log` fichiers `/var/log/cfn-init.log` et. Pour plus d'informations sur AWS ParallelCluster les journaux et sur la façon de les consulter, consultez [Journaux clés pour le débogage](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) et[Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
Si vous n'en avez pas`failureCode`, accédez à la CloudFormation console pour afficher la pile du cluster. Vérifiez les `Status Reason` défaillances `HeadNodeWaitCondition` ou sur d'autres ressources pour obtenir des informations supplémentaires sur les défaillances. Pour de plus amples informations, veuillez consulter [Afficher CloudFormation les événements sur `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events). Vérifiez les `/var/log/chef-client.log` fichiers `/var/log/cfn-init.log` et sur le nœud principal. Si la création du cluster échoue en raison d'un échec de création du nœud principal et que les journaux du cluster ne sont pas disponibles dans le groupe de journaux du cluster, vous devez conserver le cluster en cas d'échec, spécifier `--rollback-on-failure` = `True` et récupérer les journaux depuis le nœud principal lui-même.
## `failureCode` est `OnNodeConfiguredExecutionFailure`
+ **Pourquoi a-t-il échoué ?**
Vous avez fourni un script personnalisé dans la section `OnNodeConfigured` du nœud principal de la configuration pour créer un cluster. Cependant, le script personnalisé n'a pas pu être exécuté.
+ **Comment résoudre le problème ?**
Consultez le `/var/log/cfn-init.log` fichier pour en savoir plus sur l'échec et sur la manière de résoudre le problème dans votre script personnalisé. Vers la fin de ce journal, des informations relatives à l'exécution du `OnNodeConfigured` script peuvent s'afficher après le `Running command runpostinstall` message.
## `failureCode` est `OnNodeConfiguredDownloadFailure`
+ **Pourquoi a-t-il échoué ?**
Vous avez fourni un script personnalisé dans la section `OnNodeConfigured` du nœud principal de la configuration pour créer un cluster. Cependant, le script personnalisé n'a pas pu être téléchargé.
+ **Comment résoudre le problème ?**
Assurez-vous que l'URL est valide et que l'accès est correctement configuré. Pour plus d'informations sur la configuration des scripts bootstrap personnalisés, consultez[Actions de bootstrap personnalisées](custom-bootstrap-actions-v3.md).
Vérifiez le `/var/log/cfn-init.log` fichier. Vers la fin de ce journal, vous pouvez voir des informations d'exécution relatives au traitement du `OnNodeConfigured` script, y compris au téléchargement, après le `Running command runpostinstall` message.
## `failureCode` est `OnNodeConfiguredFailure`
+ **Pourquoi a-t-il échoué ?**
Vous avez fourni un script personnalisé dans la section `OnNodeConfigured` du nœud principal de la configuration pour créer un cluster. Cependant, l'utilisation du script personnalisé a échoué lors du déploiement du cluster. Aucune cause immédiate ne peut être déterminée et une enquête supplémentaire est nécessaire.
+ **Comment résoudre le problème ?**
Vérifiez le `/var/log/cfn-init.log` fichier. Vers la fin de ce journal, vous pouvez voir des informations d'exécution relatives au traitement du `OnNodeConfigured` script après le `Running command runpostinstall` message.
## `failureCode` est `OnNodeStartExecutionFailure`
+ **Pourquoi a-t-il échoué ?**
Vous avez fourni un script personnalisé dans la section `OnNodeStart` du nœud principal de la configuration pour créer un cluster. Cependant, le script personnalisé n'a pas pu être exécuté.
+ **Comment résoudre le problème ?**
Consultez le `/var/log/cfn-init.log` fichier pour en savoir plus sur l'échec et sur la manière de résoudre le problème dans votre script personnalisé. Vers la fin de ce journal, des informations relatives à l'exécution du `OnNodeStart` script peuvent s'afficher après le `Running command runpreinstall` message.
## `failureCode` est `OnNodeStartDownloadFailure`
+ **Pourquoi a-t-il échoué ?**
Vous avez fourni un script personnalisé dans la section `OnNodeStart` du nœud principal de la configuration pour créer un cluster. Cependant, le script personnalisé n'a pas pu être téléchargé.
+ **Comment résoudre le problème ?**
Assurez-vous que l'URL est valide et que l'accès est correctement configuré. Pour plus d'informations sur la configuration des scripts bootstrap personnalisés, consultez[Actions de bootstrap personnalisées](custom-bootstrap-actions-v3.md).
Vérifiez le `/var/log/cfn-init.log` fichier. Vers la fin de ce journal, vous pouvez voir des informations d'exécution relatives au traitement du `OnNodeStart` script, y compris au téléchargement, après le `Running command runpreinstall` message.
## `failureCode` est `OnNodeStartFailure`
+ **Pourquoi a-t-il échoué ?**
Vous avez fourni un script personnalisé dans la section `OnNodeStart` du nœud principal de la configuration pour créer un cluster. Cependant, l'utilisation du script personnalisé a échoué lors du déploiement du cluster. Aucune cause immédiate ne peut être déterminée et une enquête supplémentaire est nécessaire.
+ **Comment résoudre le problème ?**
Vérifiez le `/var/log/cfn-init.log` fichier. Vers la fin de ce journal, vous pouvez voir des informations d'exécution relatives au traitement du `OnNodeStart` script après le `Running command runpreinstall` message.
## `failureCode` est `EbsMountFailure`
+ **Pourquoi a-t-il échoué ?**
Le volume EBS défini dans la configuration du cluster n'a pas pu être monté.
+ **Comment résoudre le problème ?**
Consultez le `/var/log/chef-client.log` fichier pour obtenir des informations détaillées sur l'échec.
## `failureCode` est `EfsMountFailure`
+ **Pourquoi a-t-il échoué ?**
Le volume Amazon EFS défini dans la configuration du cluster n'a pas pu être monté.
+ **Comment résoudre le problème ?**
Si vous avez défini un système de fichiers Amazon EFS existant, assurez-vous que le trafic est autorisé entre le cluster et le système de fichiers. Pour plus d'informations, consultez [`SharedStorage`](SharedStorage-v3.md)/[`EfsSettings`](SharedStorage-v3.md#SharedStorage-v3-EfsSettings)/[`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId).
Consultez le `/var/log/chef-client.log` fichier pour obtenir des informations détaillées sur l'échec.
## `failureCode` est `FsxMountFailure`
+ **Pourquoi a-t-il échoué ?**
Le système de FSx fichiers Amazon défini dans la configuration du cluster n'a pas pu être monté.
+ **Comment résoudre le problème ?**
Si vous avez défini un système de FSx fichiers Amazon existant, assurez-vous que le trafic est autorisé entre le cluster et le système de fichiers. Pour plus d'informations, consultez [`SharedStorage`](SharedStorage-v3.md)/[`FsxLustreSettings`](SharedStorage-v3.md#SharedStorage-v3-FsxLustreSettings)/[`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId).
Consultez le `/var/log/chef-client.log` fichier pour obtenir des informations détaillées sur l'échec.
## `failureCode` est `RaidMountFailure`
+ **Pourquoi a-t-il échoué ?**
Les volumes RAID définis dans la configuration du cluster n'ont pas pu être montés.
+ **Comment résoudre le problème ?**
Consultez le `/var/log/chef-client.log` fichier pour obtenir des informations détaillées sur l'échec.
## `failureCode` est `AmiVersionMismatch`
+ **Pourquoi a-t-il échoué ?**
La AWS ParallelCluster version utilisée pour créer l'AMI personnalisée est différente de AWS ParallelCluster celle utilisée pour configurer le cluster. Dans la CloudFormation console, consultez les détails de la CloudFormation pile de clusters et cochez la case « `Status Reason` for `HeadNodeWaitCondition` the » pour obtenir des informations supplémentaires sur les AWS ParallelCluster versions et l'AMI. Pour de plus amples informations, veuillez consulter [Afficher CloudFormation les événements sur `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events).
+ **Comment résoudre le problème ?**
Assurez-vous que la AWS ParallelCluster version utilisée pour créer l'AMI personnalisée est la même que celle AWS ParallelCluster utilisée pour configurer le cluster. Vous pouvez modifier la version personnalisée de l'AMI ou la version de la `pcluster` CLI pour les rendre identiques.
## `failureCode` est `InvalidAmi`
+ **Pourquoi a-t-il échoué ?**
L'AMI personnalisée n'est pas valide car elle n'a pas été créée à l'aide de AWS ParallelCluster.
+ **Comment résoudre le problème ?**
Utilisez la `pcluster build-image` commande pour créer une AMI en faisant de votre AMI l'image parent. Pour de plus amples informations, veuillez consulter [`pcluster build-image`](pcluster.build-image-v3.md).
## `failureCode`porte `HeadNodeBootstrapFailure` la mention « `failureReason` Impossible de configurer le nœud principal ».
+ **Pourquoi a-t-il échoué ?**
Aucune cause immédiate ne peut être déterminée et une enquête supplémentaire est nécessaire. Par exemple, il se peut que le cluster soit protégé, ce qui peut être dû à un échec du provisionnement du parc informatique statique.
+ **Comment résoudre le problème ?**
Consultez le `/var/log/chef-client.log.` fichier pour obtenir des informations détaillées sur l'échec.
**Note**
Si vous `RuntimeError` `Cluster state has been set to PROTECTED mode due to failures detected in static node provisioning` constatez une exception, le cluster est protégé. Pour de plus amples informations, veuillez consulter [Comment déboguer le mode protégé](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3).
## `failureCode`est que `HeadNodeBootstrapFailure` le délai de création `failureReason` du cluster est expiré.
+ **Pourquoi a-t-il échoué ?**
Par défaut, la création du cluster est limitée à 30 minutes. Si la création du cluster n'est pas terminée dans ce délai, la création du cluster échoue avec une erreur de temporisation. La création du cluster peut être interrompue pour différentes raisons. Par exemple, les délais d'expiration peuvent être dus à un échec de création d'un nœud principal, à un problème réseau, à l'exécution de scripts personnalisés trop longs dans le nœud principal, à une erreur dans un script personnalisé exécuté dans les nœuds de calcul ou à de longs délais d'attente pour le provisionnement du nœud de calcul. Aucune cause immédiate ne peut être déterminée et une enquête supplémentaire est nécessaire.
+ **Comment résoudre le problème ?**
Consultez les `/var/log/chef-client.log` fichiers `/var/log/cfn-init.log` et pour obtenir des informations détaillées sur les défaillances. Pour plus d'informations sur AWS ParallelCluster les journaux et sur la façon de les obtenir, consultez [Journaux clés pour le débogage](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) et[Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
Vous découvrirez peut-être ce qui suit dans ces journaux.
+ **Vu `Waiting for static fleet capacity provisioning` vers la fin du `chef-client.log`**
Cela indique que le délai de création du cluster a expiré lors de l'attente du démarrage des nœuds statiques. Pour de plus amples informations, veuillez consulter [Observation des erreurs lors de l'initialisation des nœuds de calcul](troubleshooting-fc-v3-compute-node-initialization-v3.md).
+ **Le script Seeing `OnNodeConfigured` ou `OnNodeStart` Head Node n'est pas terminé à la fin du `cfn-init.log`**
Cela indique que l'exécution du script `OnNodeConfigured` ou du script `OnNodeStart` personnalisé a pris du temps et a provoqué une erreur de temporisation. Vérifiez que votre script personnalisé ne présente aucun problème susceptible de provoquer son exécution prolongée. Si l'exécution de votre script personnalisé prend du temps, pensez à modifier le délai d'expiration en ajoutant une `DevSettings` section au fichier de configuration de votre cluster, comme illustré dans l'exemple suivant :
```
DevSettings:
Timeouts:
HeadNodeBootstrapTimeout: 1800 # default setting: 1800 seconds
```
+ **Impossible de trouver les journaux ou le nœud principal n'a pas été créé correctement**
Il est possible que le nœud principal n'ait pas été créé correctement et que les journaux soient introuvables. Dans ce cas, vous pouvez obtenir des informations supplémentaires sur les défaillances en consultant les événements de la CloudFormation pile et le journal de la console du nœud principal. Vous pouvez récupérer le journal de la console du nœud principal via la console Amazon EC2 ou en exécutant la commande Amazon EC2 CLI suivante :
```
aws ec2 get-console-output --instance-id HEAD_NODE_INSTANCE_ID --output text
```
## `failureCode`est `HeadNodeBootstrapFailure` associé à `failureReason` Failed to bootstrap the head node.
+ **Pourquoi a-t-il échoué ?**
Aucune cause immédiate ne peut être déterminée et une enquête supplémentaire est nécessaire.
+ **Comment résoudre le problème ?**
Vérifiez les `/var/log/chef-client.log` fichiers `/var/log/cfn-init.log` et.
## `failureCode` est `ResourceCreationFailure`
+ **Pourquoi a-t-il échoué ?**
La création de certaines ressources a échoué lors du processus de création du cluster. La panne peut survenir pour diverses raisons. Par exemple, les échecs de création de ressources peuvent être dus à des problèmes de capacité ou à une politique IAM mal configurée.
+ **Comment résoudre le problème ?**
Dans la CloudFormation console, consultez la pile de clusters pour vérifier les détails supplémentaires relatifs à l'échec de création de ressources.
## `failureCode` est `ClusterCreationFailure`
+ **Pourquoi a-t-il échoué ?**
Aucune cause immédiate ne peut être déterminée et une enquête supplémentaire est nécessaire.
+ **Comment résoudre le problème ?**
Dans la CloudFormation console, consultez la pile du cluster et vérifiez la présence de `Status Reason` `HeadNodeWaitCondition` pour trouver des informations supplémentaires sur les défaillances.
Vérifiez les `/var/log/chef-client.log` fichiers `/var/log/cfn-init.log` et.
## Voir `WaitCondition timed out...` dans la CloudFormation pile
Pour de plus amples informations, veuillez consulter [`failureCode`est que `HeadNodeBootstrapFailure` le délai de création `failureReason` du cluster est expiré.](#create-cluster-head-node-bootstrap-timeout-failure-v3).
## Voir `Resource creation cancelled` dans la CloudFormation pile
Pour de plus amples informations, veuillez consulter [`failureCode` est `ResourceCreationFailure`](#create-cluster-resource-creation-failure-v3).
## Erreurs `Failed to run cfn-init...` visibles ou autres dans la CloudFormation pile
Consultez le `/var/log/cfn-init.log` et `/var/log/chef-client.log` pour obtenir des informations supplémentaires sur les défaillances.
## Voir `chef-client.log` se termine par `INFO: Waiting for static fleet capacity provisioning`
Cela est lié au délai de création du cluster lorsque vous attendez que les nœuds statiques s'allument. Pour de plus amples informations, veuillez consulter [Observation des erreurs lors de l'initialisation des nœuds de calcul](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Voyant `Failed to run preinstall or postinstall in cfn-init.log`
Vous avez un `OnNodeStart` script `OnNodeConfigured` or dans la `HeadNode` section de configuration du cluster. Le script ne fonctionne pas correctement. Consultez le `/var/log/cfn-init.log` fichier pour obtenir des informations détaillées sur les erreurs de script personnalisées.
## Voir `This AMI was created with xxx, but is trying to be used with xxx...` dans la CloudFormation pile
Pour de plus amples informations, veuillez consulter [`failureCode` est `AmiVersionMismatch`](#create-cluster-ami-version-mismatch-v3).
## Voir `This AMI was not baked by AWS ParallelCluster...` dans la CloudFormation pile
Pour de plus amples informations, veuillez consulter [`failureCode` est `InvalidAmi`](#create-cluster-invalid-ami-v3).
## Voir que `pcluster create-cluster` la commande 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.
## Support supplémentaire
Suivez les instructions de dépannage dans[Résolution des problèmes de déploiement de clusters](troubleshooting-v3-cluster-deployment.md).
Vérifiez si votre scénario est couvert dans la section [Problèmes GitHub connus](https://github.com/aws/aws-parallelcluster/wiki) à AWS ParallelCluster On GitHub.
# Essayer d'exécuter une tâche
La section suivante propose des solutions de dépannage possibles si vous rencontrez des problèmes lors de l'exécution d'une tâche.
## `srun`la tâche interactive échoue avec une erreur `srun: error: fwd_tree_thread: can't find address for , check slurm.conf`
+ **Pourquoi a-t-il échoué ?**
Vous avez exécuté la `srun` commande pour soumettre une tâche, puis vous avez augmenté la taille d'une file d'attente en utilisant la `pcluster update-cluster` commande sans redémarrer les Slurm démons une fois la mise à jour terminée.
Slurmorganise Slurm les démons dans une arborescence afin d'optimiser la communication. Cette hiérarchie n'est mise à jour que lorsque les démons démarrent.
Supposons que vous `srun` lanciez une tâche, puis que vous exécutiez la `pcluster update-cluster` commande pour augmenter la taille de la file d'attente. De nouveaux nœuds de calcul sont lancés dans le cadre de la mise à jour. Ensuite, place votre tâche en Slurm file d'attente sur l'un des nouveaux nœuds de calcul. Dans ce cas, les Slurm daemons et les `srun` don't détectent les nouveaux nœuds de calcul. `srun`renvoie une erreur car il ne détecte pas les nouveaux nœuds.
+ **Comment résoudre le problème ?**
Redémarrez les Slurm démons sur tous les nœuds de calcul, puis utilisez-les `srun` pour soumettre votre tâche. Vous pouvez planifier le redémarrage Slurm des démons en exécutant la `scontrol reboot` commande qui redémarre les nœuds de calcul. Pour plus d'informations, consultez [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot) dans la Slurm documentation. Vous pouvez également redémarrer manuellement les Slurm démons sur les nœuds de calcul en demandant le redémarrage des services correspondants`systemd`.
## Job bloqué dans son `CF` état avec `squeue` la commande
Cela peut être dû au démarrage des nœuds dynamiques. Pour de plus amples informations, veuillez consulter [Observation des erreurs lors de l'initialisation des nœuds de calcul](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Exécuter des travaux à grande échelle et voir `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
Avec un système de fichiers en réseau, lorsque les limites du réseau sont atteintes, le temps I/O d'attente augmente également. Cela peut entraîner des blocages logiciels, car le réseau est utilisé pour écrire des données à la fois pour le réseau et I/O pour les métriques.
Avec les instances de 5e génération, nous utilisons le pilote ENA pour exposer les compteurs de paquets. Ces compteurs comptent les paquets façonnés AWS lorsque le réseau atteint les limites de bande passante de l'instance. Vous pouvez vérifier ces compteurs pour voir s'ils sont supérieurs à 0. Si tel est le cas, cela signifie que vous avez dépassé vos limites de bande passante. Vous pouvez consulter ces compteurs en courant`ethtool -S eth0 | grep exceeded`.
Le dépassement des limites du réseau est souvent dû à la prise en charge d'un trop grand nombre de connexions NFS. C'est l'une des premières choses à vérifier lorsque vous atteignez ou dépassez les limites du réseau.
Par exemple, le résultat suivant montre les packages abandonnés :
```
$ ethtool -S eth0 | grep exceeded
bw_in_allowance_exceeded: 38750610
bw_out_allowance_exceeded: 1165693
pps_allowance_exceeded: 103
conntrack_allowance_exceeded: 0
linklocal_allowance_exceeded: 0
```
Pour éviter de recevoir ce message, envisagez de remplacer le type d'instance du nœud principal par un type d'instance plus performant. Envisagez de déplacer votre stockage de données vers des systèmes de fichiers de stockage partagés qui ne sont pas exportés sous forme de partage NFS, tels qu'Amazon EFS ou Amazon FSx. Pour plus d'informations, consultez [Stockage partagé](shared-storage-quotas-integration-v3.md) les [meilleures pratiques](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) sur le AWS ParallelCluster Wiki sur GitHub.
## Exécution d'une tâche MPI
### Activation du mode de débogage
Pour activer le mode de débogage d'OpenMPI, [voir Quelles sont les commandes d'Open MPI qui facilitent](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls) le débogage ?
Pour activer le mode de débogage IntelMPI, consultez la section [Autres](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html) variables d'environnement.
### Voir `MPI_ERRORS_ARE_FATAL` et `OPAL ERROR` intégrer le résultat du travail
Ces codes d'erreur proviennent de la couche MPI de votre application. Pour savoir comment obtenir les journaux de débogage MPI à partir de votre application, consultez. [Activation du mode de débogage](#run-job-mpi-enable-v3)
Cette erreur peut être due au fait que votre application a été compilée pour une implémentation MPI spécifique, telle qu'OpenMPI, et que vous essayez de l'exécuter avec une autre implémentation MPI, telle qu'IntelMPI. Assurez-vous de compiler et d'exécuter votre application avec la même implémentation MPI.
### Utilisation `mpirun` avec DNS géré désactivé
Pour les clusters créés avec [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Dns/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)et [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) définis sur`true`, le nom du Slurm nœud n'est pas résolu par le DNS](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns). Slurmpeut démarrer des processus MPI lorsqu'ils `nodenames` ne sont pas activés et si la tâche MPI est exécutée dans un contexte. Slurm Nous vous recommandons de suivre les instructions du [guide de l'utilisateur Slurm MPI](https://slurm.schedmd.com/mpi_guide.html) pour exécuter des tâches MPI avec. Slurm
# Essayer de mettre à jour un cluster
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
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
### 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](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster sur on 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
```
## Le délai de mise à jour du cluster a expiré
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.
# Essayer d'accéder au stockage
Découvrez les conseils de résolution des problèmes relatifs aux tentatives d'accès au stockage.
## Utilisation d'un système de fichiers Amazon FSx for Lustre externe
Assurez-vous que le trafic est autorisé entre le cluster et le système de fichiers. Le système de fichiers doit être associé à un groupe de sécurité qui autorise le trafic TCP entrant et sortant via les ports 988, 1021, 1022 et 1023. Pour plus d'informations sur la configuration des groupes de sécurité, consultez [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId).
## Utilisation d'un système de fichiers Amazon Elastic File System externe
Assurez-vous que le trafic est autorisé entre le cluster et le système de fichiers. Le système de fichiers doit être associé à un groupe de sécurité qui autorise le trafic TCP entrant et sortant via les ports 988, 1021, 1022 et 1023. Pour plus d'informations sur la configuration des groupes de sécurité, consultez [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId).
# Essayer de supprimer un cluster
Si un message d'erreur s'affiche lors de la tentative de suppression d'un cluster, les sections suivantes fournissent des conseils de résolution des problèmes pour les scénarios courants.
## La `pcluster delete-cluster` commande ne s'exécute pas localement
Vérifiez le `~/.parallelcluster/pcluster-cli.log` fichier dans votre système de fichiers local.
## La pile de clusters ne parvient pas à être supprimée
Si la pile de clusters ne parvient pas à être supprimée, consultez le message relatif aux événements de la CloudFormation pile.
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 Activé GitHub.
# Essayer de mettre à niveau la pile AWS ParallelCluster d'API
Si vous recevez une erreur, par exemple `UPDATE_FAILED` lorsque vous essayez de mettre à niveau la pile d' AWS ParallelCluster API, nous vous recommandons de rechercher une solution dans les sections **Problèmes connus** du [AWS ParallelCluster Wiki](https://github.com/aws/aws-parallelcluster/wiki) sur GitHub. Par exemple, consultez la section [ParallelCluster API Stack Upgrade Fails pour les ressources ECR](https://github.com/aws/aws-parallelcluster/wiki/(3.0.0-3.1.4)-ParallelCluster-API-Stack-Upgrade-Fails-for-ECR-resources), qui identifie un problème possible et propose des options d'atténuation.
# Observation des erreurs lors de l'initialisation des nœuds de calcul
Les sections suivantes fournissent des conseils de résolution des problèmes lorsque vous constatez des erreurs lors de l'initialisation des nœuds de calcul. Cela inclut les erreurs d'amorçage, l'affichage des erreurs dans les journaux et la marche à suivre si aucun des scénarios ne s'applique à votre situation spécifique.
**Topics**
+ [Voir à `Node bootstrap error` l'intérieur `clustermgtd.log`](compute-node-initialization-bootstrap-error-v3.md)
+ [J'ai configuré des réservations de capacité à la demande (ODCRs) ou des instances réservées zonales](compute-node-initialization-odcr-v3.md)
+ [Voir `An error occurred (VcpuLimitExceeded)` `slurm_resume.log` quand je ne parviens pas à exécuter une tâche, ou quand je ne parviens pas à créer un cluster `clustermgtd.log`](compute-node-initialization-vpc-limit-v3.md)
+ [Voir `An error occurred (InsufficientInstanceCapacity)` `slurm_resume.log` quand je ne parviens pas à exécuter une tâche, ou quand je ne parviens pas à créer un cluster `clustermgtd.log`](compute-node-initialization-ice-failure-v3.md)
+ [Voir que les nœuds sont en `DOWN` état avec `Reason (Code:InsufficientInstanceCapacity)...`](compute-node-initialization-down-nodes-v3.md)
+ [Voir à `cannot change locale (en_US.utf-8) because it has an invalid name` l'intérieur `slurm_resume.log`](compute-node-initialization-locale-v3.md)
+ [Aucun des scénarios précédents ne s'applique à ma situation](compute-node-initialization-not-found-v3.md)
# Voir à `Node bootstrap error` l'intérieur `clustermgtd.log`
Le problème est lié à l'échec du démarrage des nœuds de calcul. Pour plus d'informations sur la façon de déboguer un problème lié au mode protégé par cluster, consultez[Comment déboguer le mode protégé](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3).
# J'ai configuré des réservations de capacité à la demande (ODCRs) ou des instances réservées zonales
## ODCRs qui incluent des instances dotées de plusieurs interfaces réseau, telles que P4d, P4de et AWS Trainium (Trn)
Dans le fichier de configuration du cluster, vérifiez que le `HeadNode` se trouve dans un sous-réseau public et que les nœuds de calcul se trouvent dans un sous-réseau privé.
## ODCRs sont des ODCRS ciblés
### `Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.`Même si je l'ai déjà mis `/opt/slurm/etc/pcluster/run_instances_overrides.json` en place, en suivant les instructions données dans [Lancez des instances avec des réservations de capacité à la demande (ODCR)](launch-instances-odcr-v3.md)
Si vous utilisez AWS ParallelCluster les versions 3.1.1 à 3.2.1 avec targeted ODCRs et que vous utilisez également le fichier JSON [run instances override, il est possible que le fichier JSON](launch-instances-odcr-v3.md) ne soit pas correctement formaté. Une erreur peut s'afficher`clustermgtd.log`, telle que la suivante :
```
Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.
Using default: {} in /var/log/parallelcluster/clustermgtd.
```
Vérifiez que le format de fichier JSON est correct en exécutant ce qui suit :
```
$ echo /opt/slurm/etc/pcluster/run_instances_overrides.json | jq
```
### Voir `Found RunInstances parameters override.` en `clustermgtd.log` cas d'échec de la création du cluster ou en `slurm_resume.log` cas d'échec de la tâche d'exécution
Si vous utilisez le [fichier Run Instances Override JSON](launch-instances-odcr-v3.md), vérifiez que vous avez correctement défini le nom de la file d'attente et le nom des ressources de calcul dans le `/opt/slurm/etc/pcluster/run_instances_overrides.json` fichier.
### Voir `An error occurred (InsufficientInstanceCapacity)` `slurm_resume.log` quand je ne parviens pas à exécuter une tâche, ou `clustermgtd.log` quand je ne parviens pas à créer un cluster
#### Utilisation du PG-ODCR (groupe de placement ODCR)
Lors de la création d'un ODCR avec un groupe de placement associé, le même nom de groupe de placement doit être utilisé dans le fichier de configuration. Définissez le [nom du groupe de placement](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) correspondant dans la configuration du cluster.
#### Utilisation d'instances réservées zonales
Si vous utilisez des instances réservées zonales avec`PlacementGroup`/`Enabled`to `true` dans la configuration du cluster, une erreur peut s'afficher, telle que la suivante :
```
We currently do not have sufficient trn1.32xlarge capacity in the Availability Zone you requested (us-east-1d). Our system will be working on provisioning additional capacity.
You can currently get trn1.32xlarge capacity by not specifying an Availability Zone in your request or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1e, us-east-1f.
```
Cela peut être dû au fait que les instances réservées zonales ne sont pas placées dans le même UC (ou épine dorsale), ce qui peut entraîner des erreurs de capacité insuffisantes (ICEs) lors de l'utilisation de groupes de placement. Vous pouvez vérifier ce cas en désactivant le paramètre `PlacementGroup` Groupe dans la configuration du cluster afin de déterminer si le cluster peut allouer les instances.
# Voir `An error occurred (VcpuLimitExceeded)` `slurm_resume.log` quand je ne parviens pas à exécuter une tâche, ou quand je ne parviens pas à créer un cluster `clustermgtd.log`
Vérifiez les limites de vCPU de votre compte pour le type d'instance Amazon EC2 spécifique que vous utilisez. Si vous voyez zéro v ou moins CPUs que ce que vous demandez, demandez une augmentation de vos limites. Pour plus d'informations sur la façon de consulter les limites actuelles et de demander de nouvelles limites, consultez les [quotas de service Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) dans le guide de l'utilisateur *Amazon EC2*.
# Voir `An error occurred (InsufficientInstanceCapacity)` `slurm_resume.log` quand je ne parviens pas à exécuter une tâche, ou quand je ne parviens pas à créer un cluster `clustermgtd.log`
Vous rencontrez un problème de capacité insuffisante. Suivez [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)pour résoudre le problème.
# Voir que les nœuds sont en `DOWN` état avec `Reason (Code:InsufficientInstanceCapacity)...`
Vous rencontrez un problème de capacité insuffisante. Suivez [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)pour résoudre le problème. Pour plus d'informations sur AWS ParallelCluster le mode de basculement rapide en cas de capacité insuffisante, consultez. [Slurmbasculement rapide d'une capacité insuffisante du cluster](slurm-short-capacity-fail-mode-v3.md)
# Voir à `cannot change locale (en_US.utf-8) because it has an invalid name` l'intérieur `slurm_resume.log`
Cela peut se produire en cas d'échec du processus `yum` d'installation qui a laissé les paramètres régionaux dans un état incohérent. Cela peut se produire, par exemple, lorsqu'un utilisateur met fin au processus d'installation.
**Pour en vérifier la cause, effectuez les actions suivantes :**
+ Exécutez `su - pcluster-admin`.
Le shell affiche une erreur, telle que,`cannot change locale...no such file or directory`.
+ Exécutez `localedef --list`.
Renvoie une liste vide ou ne contient pas les paramètres régionaux par défaut.
+ Vérifiez la dernière `yum` commande avec `yum history` et`yum history info #ID`. Est-ce que la dernière pièce d'identité existe `Return-Code: Success` ?
Si le dernier ID n'en a pas`Return-Code: Success`, les scripts de post-installation ne se sont peut-être pas exécutés correctement.
Pour résoudre le problème, essayez de reconstruire les paramètres régionaux avec`yum reinstall glibc-all-langpacks`. Après la reconstruction, aucun message d'erreur ou d'avertissement `su - pcluster-admin` ne s'affiche si le problème est résolu.
# Aucun des scénarios précédents ne s'applique à ma situation
Pour résoudre les problèmes d'initialisation des nœuds de calcul, consultez. [Résolution des problèmes d'initialisation des nœuds](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init)
Vérifiez si votre scénario est couvert dans la section [Problèmes GitHub connus](https://github.com/aws/aws-parallelcluster/wiki) à AWS ParallelCluster On GitHub.
# Résolution des problèmes liés aux indicateurs de santé du
Les métriques de santé du cluster sont ajoutées au tableau de CloudWatch bord AWS ParallelCluster Amazon à partir de AWS ParallelCluster la version 3.6.0. Dans les sections suivantes, vous découvrirez les indicateurs de santé du tableau de bord et les mesures que vous pouvez prendre pour résoudre les problèmes.
**Topics**
+ [Voir le graphique des **erreurs de provisionnement des instances**](#troubleshooting-v3-cluster-health-metrics-instance-provisioning)
+ [Affichage du graphique **des erreurs d'instance non** conformes](#troubleshooting-v3-cluster-health-metrics-unhealthy-instance)
+ [Voir le graphique des **temps d'inactivité de la flotte de calcul**](#troubleshooting-v3-cluster-health-metrics-idle-time-errors)
## Voir le graphique des **erreurs de provisionnement des instances**
Si vous voyez une valeur différente de zéro dans le `Instance Provisioning Errors` graphique, cela signifie que l'instance Amazon EC2 de sauvegarde des nœuds slurm n'a pas pu être lancée sur l'API or. `CreateFleet` `RunInstance`
### Voyant `IAMPolicyErrors`
+ **Que s'est-il passé ?**
Un certain nombre d'instances n'ont pas pu être lancées, en raison d'autorisations insuffisantes accompagnées d'un code d'erreur`UnauthorizedOperation`.
+ **Comment résoudre le problème ?**
Si vous avez configuré un [`InstanceRole`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceRole)ou personnalisé [`InstanceProfile`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceProfile), vérifiez vos politiques IAM et vérifiez que vous utilisez les informations d'identification correctes.
Consultez le `clustermgtd` fichier pour obtenir des informations détaillées sur les erreurs du nœud statique. Consultez le `slurm_resume.log` fichier pour obtenir des informations détaillées sur les erreurs de nœud dynamique. Utilisez les informations pour en savoir plus sur les autorisations manquantes qui doivent être ajoutées.
### Voyant `VcpuLimitErrors`
+ **Que s'est-il passé ?**
AWS ParallelCluster n'a pas réussi à lancer les instances car la limite de vCPU que vous avez fixée Compte AWS pour un type d'instance Amazon EC2 spécifique que vous avez configuré pour les nœuds de calcul en cluster a été atteint.
+ **Comment résoudre le problème ?**
Vérifiez l'`VcpuLimitExceeded`erreur dans le `clustermgtd` fichier pour les nœuds statiques et dans le `slurm_resume.log` fichier pour les nœuds dynamiques pour obtenir des informations supplémentaires. Pour résoudre ce problème, vous pouvez demander une augmentation des limites de vos vCPU. Pour plus d'informations sur la façon de consulter les limites actuelles et de demander de nouvelles limites, consultez les [quotas de service Amazon Elastic Compute Cloud](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-resource-limits.html) dans le *guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux*.
### Voyant `VolumeLimitErrors`
+ **Que s'est-il passé ?**
Vous avez atteint la limite de volume Amazon EBS sur votre Compte AWS, et AWS ParallelCluster vous ne parvenez pas à lancer des instances avec un code d'erreur `InsufficientVolumeCapacity` ou`VolumeLimitExceeded`.
+ **Comment résoudre le problème ?**
Vérifiez le `clustermgtd` fichier pour les nœuds statiques et pour les `slurm_resume.log` nœuds dynamiques pour obtenir des informations supplémentaires sur les limites de volume. Pour résoudre ce problème, vous pouvez utiliser un autre volume Région AWS, nettoyer les volumes existants ou contacter le AWS Support Center pour soumettre une demande d'augmentation de votre limite de volume Amazon EBS.
### Voyant `InsufficientCapacityErrors`
+ **Que s'est-il passé ?**
AWS ParallelCluster ne dispose pas d'une capacité suffisante pour lancer des instances Amazon EC2 sur des nœuds principaux.
+ **Comment résoudre le problème ?**
Vérifiez le `clustermgtd` fichier pour les nœuds statiques et pour les nœuds dynamiques afin d'obtenir des informations détaillées sur les erreurs de capacité insuffisante. `slurm_resume.log` Pour résoudre le problème, suivez les instructions du [https://aws.amazon.com/premiumsupport/centre de connaissances/ec2-/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/). insufficient-capacity-errors
### `OtherInstanceLaunchFailures`
+ **Que s'est-il passé ?**
L'instance Amazon EC2 de sauvegarde des nœuds de calcul n'a pas pu être lancée avec l'API `CreateFleet` or`RunInstance`.
+ **Comment résoudre le problème ?**
Vérifiez le `clustermgtd` fichier pour les nœuds statiques et pour les `slurm_resume.log` nœuds dynamiques pour obtenir des informations sur les erreurs.
## Affichage du graphique **des erreurs d'instance non** conformes
+ **Que s'est-il passé ?**
Un certain nombre d'instances de calcul ont été lancées mais ont par la suite été interrompues pour cause de défaillance.
+ **Comment résoudre le problème ?**
Pour plus d'informations sur la résolution des problèmes liés aux nœuds défectueux, consultez[**Résolution des problèmes de remplacement et de terminaison inattendus de nœuds**](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-unexpected-node-replacements-and-terminations).
### Voyant `InstanceBootstrapTimeoutError`
+ **Que s'est-il passé ?**
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). Cela peut se produire si le réseau n'est pas configuré correctement pour les nœuds de calcul, ou si les scripts personnalisés exécutés sur le nœud de calcul mettent trop de temps à se terminer.
+ **Comment résoudre le problème ?**
Pour les nœuds dynamiques, vérifiez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) l'adresse IP du nœud de calcul et les erreurs telles que les suivantes :
```
Node bootstrap error: Resume timeout expires for node
```
Pour les nœuds statiques, vérifiez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) l'adresse IP du nœud de calcul et les erreurs telles que les suivantes :
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
Pour plus de détails, vérifiez que le `/var/log/cloud-init-output.log` fichier ne contient pas d'erreurs. Vous pouvez récupérer les adresses IP des nœuds de calcul problématiques dans les fichiers `slurm_resume` journaux `clustermgtd` et.
### Voyant `EC2HealthCheckErrors`
+ **Que s'est-il passé ?**
Le bilan de santé d'une instance a échoué sur Amazon EC2.
+ **Comment résoudre le problème ?**
Pour plus d'informations sur la façon de résoudre ce problème, consultez [Résoudre les problèmes des instances dont les vérifications d'état ont échoué](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).
### Voyant `ScheduledEventHealthCheckErrors`
+ **Que s'est-il passé ?**
Une instance a échoué lors d'une vérification de l'état d'un événement planifié par Amazon EC2, et elle ne fonctionne pas correctement.
+ **Comment résoudre le problème ?**
Pour plus d'informations sur la manière de résoudre ce problème, consultez la section [Événements planifiés pour vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).
### Voyant `NoCorrespondingInstanceErrors`
+ **Que s'est-il passé ?**
AWS ParallelCluster Impossible de trouver les instances qui soutiennent les nœuds. Les nœuds se sont probablement terminés automatiquement lors des opérations d'amorçage. [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)Des erreurs de [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)script [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)//[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1 ou de réseau peuvent se produire`NoCorrespondingInstanceErrors`.
+ **Comment résoudre le problème ?**
Pour plus de détails, consultez `/var/log/cloud-init-output.log` le nœud de calcul.
## Voir le graphique des **temps d'inactivité de la flotte de calcul**
### Observer un `MaxDynamicNodeIdleTime` délai nettement supérieur au seuil de réduction **du temps d'inactivité**
+ **Que s'est-il passé ?**
Votre instance ne s'arrête pas correctement. `MaxDynamicNodeIdleTime`indique la durée maximale en secondes pendant laquelle un nœud dynamique, soutenu par une instance Amazon EC2, est inactif. Le seuil **de réduction du temps d'inactivité** est dérivé du paramètre de configuration [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)du cluster. Lorsqu'un nœud de calcul est inactif pendant plus de quelques secondes, **Scaledown** met le nœud hors Slurm tension et AWS ParallelCluster met fin à l'instance de sauvegarde. Dans ce cas, quelque chose empêche la fermeture de l'instance.
+ **Comment résoudre le problème ?**
Pour plus d'informations sur ce problème, voir [**Remplacement, arrêt ou mise hors tension des instances et des nœuds problématiques**](troubleshooting-v3-scaling-issues.md#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3) dans[Résolution des problèmes de dimensionnement](troubleshooting-v3-scaling-issues.md).
# Résolution des problèmes de déploiement de clusters
Si votre cluster ne parvient pas à être créé et annule la création de la pile, vous pouvez consulter les fichiers journaux pour diagnostiquer le problème. Le message d'échec ressemble probablement au résultat suivant :
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster describe-cluster --cluster-name mycluster --region eu-west-1
{
"creationTime": "2021-09-06T11:03:47.696Z",
...
"cloudFormationStackStatus": "ROLLBACK_IN_PROGRESS",
"clusterName": "mycluster",
"computeFleetStatus": "UNKNOWN",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"lastUpdatedTime": "2021-09-06T11:03:47.696Z",
"region": "eu-west-1",
"clusterStatus": "CREATE_FAILED"
}
```
**Topics**
+ [Afficher CloudFormation les événements sur `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-events)
+ [Utiliser la CLI pour afficher les flux de journaux](#troubleshooting-v3-cluster-deployment-cli-logstreams)
+ [Recréez le cluster défaillant avec `rollback-on-failure`](#troubleshooting-v3-cluster-deployment-cli-fail-rollback)
## Afficher CloudFormation les événements sur `CREATE_FAILED`
Vous pouvez utiliser la console ou la AWS ParallelCluster CLI pour afficher les CloudFormation événements relatifs aux `CREATE_FAILED` erreurs afin d'en trouver la cause première.
**Topics**
+ [Afficher les événements dans la CloudFormation console](#troubleshooting-v3-cluster-deployment-cloudformation)
+ [Utilisez la CLI pour afficher et filtrer CloudFormation les événements sur `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-cli-events)
### Afficher les événements dans la CloudFormation console
Pour obtenir plus d'informations sur la cause de ce `"CREATE_FAILED"` statut, vous pouvez utiliser la CloudFormation console.
**Afficher les messages CloudFormation d'erreur depuis la console.**
1. Connectez-vous au AWS Management Console et naviguez vers [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sélectionnez la pile nommée *cluster\$1name*.
1. Sélectionnez l’onglet **Événements**.
1. Vérifiez l'**état** de la ressource dont la création a échoué en faisant défiler la liste des événements de ressource par ID **logique**. Si la création d'une sous-tâche a échoué, revenez en arrière pour trouver l'événement de ressource ayant échoué.
1. Par exemple, si le message d'état suivant s'affiche, vous devez utiliser des types d'instances qui ne dépasseront pas votre limite de vCPU actuelle ou qui ne demanderont pas une capacité de vCPU accrue.
```
2022-02-04 16:09:44 UTC-0800 HeadNode CREATE_FAILED You have requested more vCPU capacity than your current vCPU limit of 0 allows
for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.
(Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null).
```
### Utilisez la CLI pour afficher et filtrer CloudFormation les événements sur `CREATE_FAILED`
Pour diagnostiquer le problème de création de clusters, vous pouvez utiliser la [`pcluster get-cluster-stack-events`](pcluster.get-cluster-stack-events-v3.md) commande en filtrant par `CREATE_FAILED` état. Pour plus d'informations, consultez la section [Filtrage AWS CLI de la sortie](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html) dans le *guide de AWS Command Line Interface l'utilisateur*.
```
$ pcluster get-cluster-stack-events --cluster-name mycluster --region eu-west-1 \
--query 'events[?resourceStatus==`CREATE_FAILED`]'
[
{
"eventId": "3ccdedd0-0f03-11ec-8c06-02c352fe2ef9",
"physicalResourceId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "The following resource(s) failed to create: [HeadNode]. ",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "mycluster",
"resourceType": "AWS::CloudFormation::Stack",
"timestamp": "2021-09-06T11:11:51.780Z"
},
{
"eventId": "HeadNode-CREATE_FAILED-2021-09-06T11:11:50.127Z",
"physicalResourceId": "i-04e91cc1f4ea796fe",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "Received FAILURE signal with UniqueId i-04e91cc1f4ea796fe",
"resourceProperties": "{\"LaunchTemplate\":{\"Version\":\"1\",\"LaunchTemplateId\":\"lt-057d2b1e687f05a62\"}}",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "HeadNode",
"resourceType": "AWS::EC2::Instance",
"timestamp": "2021-09-06T11:11:50.127Z"
}
]
```
Dans l'exemple précédent, l'échec était lié à la configuration du nœud principal.
## Utiliser la CLI pour afficher les flux de journaux
Pour résoudre ce type de problème, vous pouvez répertorier les flux de journaux disponibles depuis le nœud principal [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) en filtrant `node-type` puis en analysant le contenu des flux de journaux.
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=node-type,Values=HeadNode'
{
"logStreams": [
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
...
},
...
]
}
```
Les deux principaux flux de log que vous pouvez utiliser pour détecter les erreurs d'initialisation sont les suivants :
+ `cfn-init`est le journal du `cfn-init` script. Vérifiez d'abord ce flux de journal. Vous verrez probablement l'`Command chef failed`erreur dans ce journal. Regardez les lignes juste avant cette ligne pour plus de détails liés au message d'erreur. Pour plus d'informations, consultez [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html).
+ `cloud-init`est le journal de [cloud-init](https://cloudinit.readthedocs.io/). Si rien ne s'y trouve`cfn-init`, essayez ensuite de consulter ce journal.
Vous pouvez récupérer le contenu du flux de log à l'aide de l'option [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) (notez l'`--limit 5`option permettant de limiter le nombre d'événements récupérés) :
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init \
--limit 5
{
"nextToken": "f/36370880979637159565202782352491087067973952362220945409/s",
"prevToken": "b/36370880752972385367337528725601470541902663176996585497/s",
"events": [
{
"message": "2021-09-06 11:11:39,049 [ERROR] Unhandled exception during build: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "Traceback (most recent call last):\n File \"/opt/aws/bin/cfn-init\", line 176, in \n worklog.build(metadata, configSets)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 135, in build\n Contractor(metadata).build(configSets, self)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 561, in build\n self.run_config(config, worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 573, in run_config\n CloudFormationCarpenter(config, self._auth_config).build(worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 273, in build\n self._config.commands)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py\", line 127, in apply\n raise ToolError(u\"Command %s failed\" % name)",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "cfnbootstrap.construction_errors.ToolError: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "2021-09-06 11:11:49,212 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.eu-west-1.amazonaws.com",
"timestamp": "2021-09-06T11:11:49.212Z"
},
{
"message": "2021-09-06 11:11:49,213 [DEBUG] Signaling resource HeadNode in stack mycluster with unique ID i-04e91cc1f4ea796fe and status FAILURE",
"timestamp": "2021-09-06T11:11:49.213Z"
}
]
}
```
Dans l'exemple précédent, l'échec est dû à un `runpostinstall` échec. Il est donc strictement lié au contenu du script bootstrap personnalisé utilisé dans le paramètre de `OnNodeConfigured` configuration du[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions).
## Recréez le cluster défaillant avec `rollback-on-failure`
AWS ParallelCluster crée des flux de CloudWatch journaux de cluster dans des groupes de journaux. Vous pouvez consulter ces journaux dans les **tableaux de bord personnalisés** ou les **groupes de journaux** de la CloudWatch console. Pour plus d’informations, consultez [Intégration à Amazon CloudWatch Logs](cloudwatch-logs-v3.md) et [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md). Si aucun flux de journal n'est disponible, l'échec peut être dû au script de démarrage [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) personnalisé ou à un problème lié à l'AMI. Pour diagnostiquer le problème de création dans ce cas, créez à nouveau le cluster en utilisant[`pcluster create-cluster`](pcluster.create-cluster-v3.md), y compris le `--rollback-on-failure` paramètre défini sur`false`. Utilisez ensuite SSH pour afficher le cluster, comme indiqué ci-dessous :
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml --rollback-on-failure false
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster ssh --cluster-name mycluster
```
Une fois connecté au nœud principal, vous devriez trouver trois fichiers journaux principaux que vous pouvez utiliser pour trouver l'erreur.
+ `/var/log/cfn-init.log`est le journal du `cfn-init` script. Vérifiez d'abord ce journal. Il est probable que vous rencontriez une erreur comme `Command chef failed` dans ce journal. Regardez les lignes juste avant cette ligne pour plus de détails liés au message d'erreur. Pour plus d'informations, consultez [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html).
+ `/var/log/cloud-init.log`est le journal de [cloud-init](https://cloudinit.readthedocs.io/). Si rien ne s'y trouve`cfn-init.log`, essayez ensuite de consulter ce journal.
+ `/var/log/cloud-init-output.log`est le résultat des commandes exécutées par [cloud-init](https://cloudinit.readthedocs.io/). Cela inclut la sortie de`cfn-init`. Dans la plupart des cas, il n'est pas nécessaire de consulter ce journal pour résoudre ce type de problème.
# Résolution des problèmes de déploiement de clusters à l'aide de Terraform
Cette section concerne les clusters déployés à l'aide de Terraform.
## ParallelCluster API introuvable
La planification peut échouer car l' ParallelCluster API est introuvable. Dans ce cas, l'erreur renvoyée serait quelque chose comme :
```
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Unable to retrieve ParallelCluster API cloudformation stack.
│
│ with provider["registry.terraform.io/aws-tf/aws-parallelcluster"],
│ on providers.tf line 6, in provider "aws-parallelcluster":
│ 6: provider "aws-parallelcluster" {
│
│ operation error CloudFormation: DescribeStacks, https response error StatusCode: 400, RequestID: REQUEST_ID, api error ValidationError: Stack with id PCAPI_STACK_NAME does not exist
```
Pour résoudre cette erreur, déployez l' ParallelCluster API dans le compte sur lequel les clusters vont être créés. Consultez [Création d'un cluster avec Terraform](tutorial-create-cluster-terraform.md).
## L'utilisateur n'est pas autorisé à appeler ParallelCluster l'API
La planification peut échouer car l'IAM que role/user vous avez supposé déployer votre projet Terraform n'est pas autorisé à interagir avec l'API. ParallelCluster Dans ce cas, l'erreur renvoyée serait quelque chose comme :
```
Planning failed. Terraform encountered an error while generating this plan.
│ Error: 403 Forbidden
│
│ with module.parallelcluster_clusters.module.clusters[0].pcluster_cluster.managed_configs["DemoCluster01"],
│ on .terraform/modules/parallelcluster_clusters/modules/clusters/main.tf line 35, in resource "pcluster_cluster" "managed_configs":
│ 35: resource "pcluster_cluster" "managed_configs" {
│
│ {{"Message":"User: USER_ARN is not authorized to perform: execute-api:Invoke on resource: PC_API_REST_RESOURCE with an explicit deny"}
│ }
```
Pour résoudre cette erreur, configurez le ParallelCluster fournisseur de manière à ce qu'il utilise le rôle d' ParallelCluster API pour interagir avec l'API.
```
provider "aws-parallelcluster" {
region = var.region
profile = var.profile
api_stack_name = var.api_stack_name
**use_user_role** **= true**
}
```
# Résolution des problèmes de dimensionnement
Cette section concerne les clusters installés à l'aide de la AWS ParallelCluster version 3.0.0 ou ultérieure avec le planificateur de Slurm tâches. Pour plus d'informations sur la configuration de plusieurs files d'attente, consultez[Configuration de plusieurs files d'attente](configuration-of-multiple-queues-v3.md).
Si l'un de vos clusters en cours d'exécution rencontre des problèmes, mettez-le dans un `STOPPED` état en exécutant la commande suivante avant de commencer le dépannage. Cela évite d'encourir des coûts imprévus.
```
$ pcluster update-compute-fleet --cluster-name mycluster \
--status STOP_REQUESTED
```
Vous pouvez répertorier les flux de journaux disponibles à partir des nœuds du cluster à l'aide de la [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) commande et en filtrant à l'`private-dns-name`aide de l'un des nœuds défaillants ou du nœud principal :
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=private-dns-name,Values=ip-10-0-0-101'
```
Vous pouvez ensuite récupérer le contenu du flux de journaux pour l'analyser en utilisant la [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) commande et en transmettant le `--log-stream-name` correspondant à l'un des journaux clés mentionnés dans la section suivante :
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init
```
AWS ParallelCluster crée des flux de CloudWatch journaux de cluster dans des groupes de journaux. Vous pouvez consulter ces journaux dans les **tableaux de bord personnalisés** ou les **groupes de journaux** de la CloudWatch console. Pour plus d’informations, consultez [Intégration à Amazon CloudWatch Logs](cloudwatch-logs-v3.md) et [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md).
**Topics**
+ [Journaux clés pour le débogage](#troubleshooting-v3-key-logs)
+ [Affichage `InsufficientInstanceCapacity` d'une erreur `slurm_resume.log` lorsque je ne parviens pas à exécuter une tâche ou `clustermgtd.log` lorsque je ne parviens pas à créer un cluster](#compute-node-initialization-ice-failure-v3-c2)
+ [Résolution des problèmes d'initialisation des nœuds](#troubleshooting-v3-node-init)
+ [**Résolution des problèmes de remplacement et de terminaison inattendus de nœuds**](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [**Remplacement, arrêt ou mise hors tension des instances et des nœuds problématiques**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [`Inactive`État de la file d'attente (partition)](#troubleshooting-v3-queues)
+ [Résolution d'autres problèmes connus liés aux nœuds et aux tâches](#troubleshooting-v3-other-node-job-issues)
## Journaux clés pour le débogage
Le tableau suivant fournit une vue d'ensemble des journaux clés du nœud principal :
+ `/var/log/cfn-init.log`- Voici le journal CloudFormation d'initialisation. Il contient toutes les commandes exécutées lors de la configuration d'une instance. Utilisez-le pour résoudre les problèmes d'initialisation.
+ `/var/log/chef-client.log`- Voici le journal du client Chef. Il contient toutes les commandes qui ont été exécutées via CHEF/CINC. Utilisez-le pour résoudre les problèmes d'initialisation.
+ `/var/log/parallelcluster/slurm_resume.log`- C'est un `ResumeProgram` journal. Il lance des instances pour les nœuds dynamiques. Utilisez-le pour résoudre les problèmes de lancement des nœuds dynamiques.
+ `/var/log/parallelcluster/slurm_suspend.log`- Voici le `SuspendProgram` journal. Il est appelé lorsque des instances sont résiliées pour des nœuds dynamiques. Utilisez-le pour résoudre les problèmes de terminaison des nœuds dynamiques. Lorsque vous consultez ce journal, vous devez également le `clustermgtd` consulter.
+ `/var/log/parallelcluster/clustermgtd`- Voici le `clustermgtd` journal. Il s'exécute en tant que démon centralisé qui gère la plupart des actions des opérations de cluster. Utilisez-le pour résoudre les problèmes de lancement, de terminaison ou de fonctionnement du cluster.
+ `/var/log/slurmctld.log`- Il s'agit du journal du démon de Slurm contrôle. AWS ParallelCluster ne prend pas de décisions de mise à l'échelle. Au contraire, il tente uniquement de lancer des ressources pour répondre aux Slurm exigences. Il est utile pour les problèmes de dimensionnement et d'allocation, les problèmes liés au travail et les problèmes de lancement et de résiliation liés au planificateur.
+ `/var/log/parallelcluster/compute_console_output`- Ce journal enregistre la sortie de console d'un exemple de sous-ensemble de nœuds de calcul statiques qui se sont arrêtés de façon inattendue. Utilisez ce journal si les nœuds de calcul statiques se terminent et que les journaux des nœuds de calcul ne sont pas disponibles dans CloudWatch. Le `compute_console_output log` contenu que vous recevez est le même lorsque vous utilisez la console Amazon EC2 ou AWS CLI pour récupérer la sortie de la console d'instance.
Voici les principaux journaux des nœuds de calcul :
+ `/var/log/cloud-init-output.log`- Il s'agit du journal [cloud-init](https://cloudinit.readthedocs.io/). Il contient toutes les commandes exécutées lors de la configuration d'une instance. Utilisez-le pour résoudre les problèmes d'initialisation.
+ `/var/log/parallelcluster/computemgtd`- Voici le `computemgtd` journal. Il s'exécute sur chaque nœud de calcul pour surveiller le nœud dans le cas peu fréquent où le `clustermgtd` démon du nœud principal est hors ligne. Utilisez-le pour résoudre les problèmes de résiliation inattendus.
+ `/var/log/slurmd.log`- Il s'agit du journal du démon de Slurm calcul. Utilisez-le pour résoudre les problèmes d'initialisation et de défaillance du calcul.
## Affichage `InsufficientInstanceCapacity` d'une erreur `slurm_resume.log` lorsque je ne parviens pas à exécuter une tâche ou `clustermgtd.log` lorsque je ne parviens pas à créer un cluster
Si le cluster utilise un Slurm planificateur, vous rencontrez un problème de capacité insuffisante. S'il n'y a pas suffisamment d'instances disponibles lorsqu'une demande de lancement d'instance est faite, une `InsufficientInstanceCapacity` erreur est renvoyée.
Pour la capacité d'instance statique, vous pouvez trouver l'erreur dans le `clustermgtd` journal à l'adresse`/var/log/parallelcluster/clustermgtd`.
Pour ce qui est de la capacité dynamique de l'instance, vous pouvez trouver l'erreur dans le `ResumeProgram` journal à l'adresse`/var/log/parallelcluster/slurm_resume.log`.
Le message ressemble à l'exemple suivant :
```
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...
```
En fonction de votre cas d'utilisation, envisagez d'utiliser l'une des méthodes suivantes pour éviter de recevoir ce type de message d'erreur :
+ Désactivez le groupe de placement s'il est activé. Pour de plus amples informations, veuillez consulter [Problèmes liés aux groupes de placement et au lancement d'instances](troubleshooting-v3-placemment-groups.md).
+ Réservez de la capacité pour les instances et lancez-les avec ODCR (On-Demand Capacity Reservations). Pour de plus amples informations, veuillez consulter [Lancez des instances avec des réservations de capacité à la demande (ODCR)](launch-instances-odcr-v3.md).
+ Configurez plusieurs ressources de calcul avec différents types d'instances. Si votre charge de travail ne nécessite aucun type d'instance spécifique, vous pouvez tirer parti du basculement rapide en cas de capacité insuffisante avec plusieurs ressources de calcul. Pour de plus amples informations, veuillez consulter [Slurmbasculement rapide d'une capacité insuffisante du cluster](slurm-short-capacity-fail-mode-v3.md).
+ Configurez plusieurs types d'instances dans la même ressource de calcul et tirez parti de l'allocation de plusieurs types d'instances. Pour plus d'informations sur la configuration de plusieurs instances, consultez [Allocation de plusieurs types d'instances avec Slurm](slurm-multiple-instance-allocation-v3.md) et [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
+ Déplacez la file d'attente vers une autre zone de disponibilité en modifiant l'ID de sous-réseau dans la configuration du cluster [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds).
+ Si votre charge de travail n'est pas étroitement liée, répartissez la file d'attente sur différentes zones de disponibilité. Pour plus d'informations sur la configuration de plusieurs sous-réseaux, consultez [`Scheduling`](Scheduling-v3.md)//[`SlurmQueues`[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds).
## Résolution des problèmes d'initialisation des nœuds
Cette section explique comment résoudre les problèmes d'initialisation des nœuds. Cela inclut les problèmes où le nœud ne parvient pas à démarrer, à démarrer ou à rejoindre un cluster.
**Topics**
+ [Nœud principal](#troubleshooting-v3-node-init.head-node)
+ [Nœuds de calcul](#troubleshooting-v3-node-init.compute-node)
### Nœud principal
Journaux applicables :
+ `/var/log/cfn-init.log`
+ `/var/log/chef-client.log`
+ `/var/log/parallelcluster/clustermgtd`
+ `/var/log/parallelcluster/slurm_resume.log`
+ `/var/log/slurmctld.log`
Consultez les `/var/log/chef-client.log` journaux `/var/log/cfn-init.log` et ou les flux de journaux correspondants. Ces journaux contiennent toutes les actions exécutées lors de la configuration du nœud principal. La plupart des erreurs survenant lors de l'installation doivent contenir des messages d'erreur dans le `/var/log/chef-client.log` journal. Si `OnNodeStart` des `OnNodeConfigured` scripts sont spécifiés dans la configuration du cluster, vérifiez que le script s'exécute correctement via les messages du journal.
Lorsqu'un cluster est créé, le nœud principal doit attendre que les nœuds de calcul rejoignent le cluster avant de pouvoir le rejoindre. De ce fait, si les nœuds de calcul ne parviennent pas à rejoindre le cluster, le nœud principal échoue également. Vous pouvez suivre l'un de ces ensembles de procédures, en fonction du type de notes de calcul que vous utilisez, pour résoudre ce type de problème :
### Nœuds de calcul
+ Journaux applicables :
+ `/var/log/cloud-init-output.log`
+ `/var/log/slurmd.log`
+ Si un nœud de calcul est lancé, vérifiez d'abord`/var/log/cloud-init-output.log`, qui doit contenir les journaux de configuration similaires à ceux du nœud principal. `/var/log/chef-client.log` La plupart des erreurs survenant lors de l'installation doivent contenir des messages d'erreur dans le `/var/log/cloud-init-output.log` journal. Si des scripts de pré-installation ou de post-installation sont spécifiés dans la configuration du cluster, vérifiez qu'ils ont été exécutés correctement.
+ Si vous utilisez une AMI personnalisée avec modification de la Slurm configuration, il se peut qu'une erreur Slurm liée empêche le nœud de calcul de rejoindre le cluster. Pour les erreurs liées au planificateur, consultez le `/var/log/slurmd.log` journal.
**Nœuds de calcul dynamiques :**
+ Recherchez dans le `ResumeProgram` journal (`/var/log/parallelcluster/slurm_resume.log`) le nom de votre nœud de calcul pour voir s'il `ResumeProgram` a déjà été appelé avec le nœud. (Si vous `ResumeProgram` n'avez jamais été appelé, vous pouvez consulter le `slurmctld` journal (`/var/log/slurmctld.log`) pour déterminer si vous avez Slurm déjà essayé `ResumeProgram` d'appeler le nœud).
+ Notez que des autorisations incorrectes pour `ResumeProgram` peuvent `ResumeProgram` entraîner un échec silencieux. Si vous utilisez une AMI personnalisée dont la `ResumeProgram` configuration a été modifiée, vérifiez qu'elle `ResumeProgram` appartient à l'`slurm`utilisateur et qu'elle dispose de l'autorisation `744` (`rwxr--r--`).
+ En cas `ResumeProgram` d'appel, vérifiez si une instance est lancée pour le nœud. Si aucune instance n'a été lancée, un message d'erreur décrivant l'échec du lancement peut s'afficher.
+ Si l'instance est lancée, il se peut qu'un problème se soit produit pendant le processus de configuration. Vous devriez voir l'adresse IP privée et l'ID d'instance correspondants dans le `ResumeProgram` journal. De plus, vous pouvez consulter les journaux de configuration correspondants pour l'instance en question. Pour plus d'informations sur la résolution d'une erreur de configuration avec un nœud de calcul, consultez la section suivante.
**Nœuds de calcul statiques :**
+ Consultez le journal `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) pour voir si des instances ont été lancées pour le nœud. S'ils n'ont pas été lancés, un message d'erreur clair devrait s'afficher détaillant l'échec du lancement.
+ Si l'instance est lancée, il y a un problème pendant le processus de configuration. Vous devriez voir l'adresse IP privée et l'ID d'instance correspondants dans le `ResumeProgram` journal. De plus, vous pouvez consulter les journaux de configuration correspondants pour l'instance en question.
**Nœuds de calcul soutenus par des instances Spot :**
+ Si c'est la première fois que vous utilisez des instances Spot et que la tâche est toujours au format PDF (état en attente), vérifiez le `/var/log/parallelcluster/slurm_resume.log` fichier. Vous trouverez probablement une erreur comme celle-ci :
```
2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for Amazon EC2 Spot Instances.
```
Lorsque vous utilisez des instances Spot, un rôle `AWSServiceRoleForEC2Spot` lié au service doit exister dans votre compte. Pour créer ce rôle dans votre compte à l'aide de AWS CLI, exécutez la commande suivante :
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Pour plus d'informations, consultez le guide [Utilisation de instances Spot](spot-v3.md) de l' AWS ParallelCluster utilisateur et le [rôle lié au service pour les demandes d'instance Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) dans le guide de l'utilisateur *Amazon EC2*.
## **Résolution des problèmes de remplacement et de terminaison inattendus de nœuds**
Cette section continue à explorer comment résoudre les problèmes liés aux nœuds, en particulier lorsqu'un nœud est remplacé ou arrêté de manière inattendue.
+ **Journaux applicables :**
+ `/var/log/parallelcluster/clustermgtd`(nœud principal)
+ `/var/log/slurmctld.log`(nœud principal)
+ `/var/log/parallelcluster/computemgtd`(nœud de calcul)
**Nœuds remplacés ou interrompus de façon inattendue**
+ Consultez le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) pour voir si un nœud `clustermgtd` a été remplacé ou résilié. Notez que cela `clustermgtd` gère toutes les actions de maintenance normales du nœud.
+ En cas de `clustermgtd` remplacement ou de résiliation du nœud, un message doit s'afficher expliquant pourquoi cette action a été entreprise sur le nœud. Si la raison est liée au planificateur (par exemple, parce que le nœud est dedans`DOWN`), consultez le `slurmctld` journal pour plus d'informations. Si la raison est liée à Amazon EC2, il doit y avoir un message informatif détaillant le problème lié à Amazon EC2 qui a nécessité le remplacement.
+ Si cela `clustermgtd` n'a pas mis fin au nœud, vérifiez d'abord s'il s'agit d'une résiliation prévue par Amazon EC2, plus précisément d'une résiliation ponctuelle. `computemgtd`, exécuté sur un nœud de calcul, peut également arrêter un nœud s'`clustermgtd`il est jugé défectueux. Vérifiez `computemgtd` log (`/var/log/parallelcluster/computemgtd`) pour voir si le `computemgtd` nœud a été arrêté.
**Les nœuds ont échoué**
+ Consultez `slurmctld` log (`/var/log/slurmctld.log`) pour savoir pourquoi une tâche ou un nœud a échoué. Notez que les tâches sont automatiquement mises en file d'attente en cas de défaillance d'un nœud.
+ Si vous `slurm_resume` signalez que le nœud est lancé et qu'il `clustermgtd` indique au bout de quelques minutes qu'il n'existe aucune instance correspondante dans Amazon EC2 pour ce nœud, le nœud risque de tomber en panne lors de la configuration. Pour récupérer le journal depuis un compute (`/var/log/cloud-init-output.log`), procédez comme suit :
+ Soumettez une offre d'emploi Slurm pour créer un nouveau nœud.
+ Attendez que le nœud de calcul démarre.
+ Modifiez le comportement d'arrêt initié par l'instance afin qu'un nœud de calcul défaillant soit arrêté plutôt que résilié.
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"
```
+ Activer la protection de la résiliation.
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--disable-api-termination
```
+ Marquez le nœud pour qu'il soit facilement identifiable.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=Name,Value=QUARANTINED-Compute
```
+ Détachez le nœud du cluster en modifiant le `parallelcluster:cluster-name` tag.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName
```
+ Récupérez la sortie de console depuis le nœud à l'aide de cette commande.
```
$ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text
```
## **Remplacement, arrêt ou mise hors tension des instances et des nœuds problématiques**
+ **Journaux applicables :**
+ `/var/log/parallelcluster/clustermgtd`(nœud principal)
+ `/var/log/parallelcluster/slurm_suspend.log`(nœud principal)
+ Dans la plupart des cas, `clustermgtd` gère toutes les actions de fermeture d'instance attendues. Consultez le `clustermgtd` journal pour savoir pourquoi il n'a pas réussi à remplacer ou à mettre fin à un nœud.
+ En cas d'échec d'un nœud dynamique[`SlurmSettings`Propriétés](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties), consultez le `SuspendProgram` journal pour voir s'`SuspendProgram`il a été appelé `slurmctld` avec le nœud spécifique comme argument. Notez qu'`SuspendProgram`aucune action n'est réellement exécutée. Au contraire, il ne se connecte que lorsqu'il est appelé. La résiliation et la `NodeAddr` réinitialisation de toutes les instances sont effectuées par`clustermgtd`. Slurmremet `SuspendTimeout` automatiquement les nœuds dans un `POWER_SAVING` état ultérieur.
+ Si les nœuds de calcul échouent continuellement en raison d'échecs d'amorçage, vérifiez s'ils sont lancés avec [Slurm mode protégé par cluster](slurm-protected-mode-v3.md) cette option activée. Si le mode protégé n'est pas activé, modifiez les paramètres du mode protégé pour activer le mode protégé. Résolvez et corrigez le script bootstrap.
## `Inactive`État de la file d'attente (partition)
Si vous exécutez `sinfo` et que le résultat affiche des files d'attente dont le `AVAIL` statut est égal à`inact`, il est possible que votre cluster soit [Slurm mode protégé par cluster](slurm-protected-mode-v3.md) activé et que la file d'attente ait été définie sur `INACTIVE` cet état pendant une période prédéfinie.
## Résolution d'autres problèmes connus liés aux nœuds et aux tâches
Un autre type de problème connu est celui qui AWS ParallelCluster peut ne pas permettre d'allouer des tâches ou de prendre des décisions de dimensionnement. Dans ce type de problème, AWS ParallelCluster seules les ressources sont lancées, résiliées ou maintenues conformément aux Slurm instructions. Pour ces problèmes, consultez le `slurmctld` journal pour les résoudre.
# Problèmes liés aux groupes de placement et au lancement d'instances
Pour obtenir le plus faible temps de latence entre nœuds, utilisez un *groupe de placement*. Un groupe de placement garantit que vos instances se trouvent sur le même backbone réseau. S'il n'y a pas suffisamment d'instances disponibles lorsqu'une demande est faite, une `InsufficientInstanceCapacity` erreur est renvoyée. Pour réduire le risque de recevoir cette erreur lors de l'utilisation de groupes de placement de clusters, définissez le [`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Enabled)paramètre [`SlurmQueues`[`Networking`[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)///sur`false`.
Pour un contrôle accru de l'accès aux capacités, envisagez de [lancer des instances avec ODCR (On-Demand Capacity Reservations).](launch-instances-odcr-v3.md)
Pour plus d'informations, consultez les sections [Résolution des problèmes de lancement d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) et [Rôles et limites des groupes de placement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) dans le *Guide de l'utilisateur Amazon EC2 pour les instances Linux.*
# Remplacement de répertoires
Certains répertoires ne peuvent pas être remplacés. Si vous rencontrez des problèmes pour remplacer le répertoire, c'est peut-être le cas. Les répertoires suivants sont partagés entre les nœuds et ne peuvent pas être remplacés.
+ `/opt/intel`- Cela inclut Intel MPI, Intel Parallel Studio et les fichiers associés.
+ `/opt/slurm`- Cela inclut le gestionnaire Slurm de charge de travail et les fichiers associés. (Conditionnel, seulement si `Scheduler: slurm`.)
# Résolution des problèmes dans Amazon DCV
**Topics**
+ [Journaux pour Amazon DCV](#troubleshooting-v3-nice-dcv-logs)
+ [Problèmes liés à Ubuntu Amazon DCV](#troubleshooting-v3-nice-dcv-modules)
## Journaux pour Amazon DCV
Les journaux d'Amazon DCV sont écrits dans des fichiers du `/var/log/dcv/` répertoire. L'examen de ces journaux peut aider à résoudre les problèmes.
Le type d'instance doit disposer d'au moins 1,7 Gibioctet (GiB) de RAM pour exécuter Amazon DCV. Les types d'instances nano et micro ne disposent pas de suffisamment de mémoire pour exécuter Amazon DCV.
AWS ParallelCluster crée des flux de journaux Amazon DCV dans des groupes de journaux. Vous pouvez consulter ces journaux dans les **tableaux de bord personnalisés** ou les **groupes de journaux** de la CloudWatch console. Pour plus d’informations, consultez [Intégration à Amazon CloudWatch Logs](cloudwatch-logs-v3.md) et [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md).
## Problèmes liés à Ubuntu Amazon DCV
Lorsque vous exécutez Gnome Terminal sur une session Amazon DCV sur Ubuntu, il se peut que vous n'ayez pas automatiquement accès à l'environnement utilisateur mis à disposition AWS ParallelCluster via le shell de connexion. L'environnement utilisateur fournit des modules d'environnement tels que openmpi ou intelmpi, ainsi que d'autres paramètres utilisateur.
Les paramètres par défaut de Gnome Terminal empêchent le shell de démarrer en tant que shell de connexion. Cela signifie que les profils shell ne sont pas générés automatiquement et que l'environnement AWS ParallelCluster utilisateur n'est pas chargé.
Pour obtenir correctement le profil shell et accéder à l'environnement AWS ParallelCluster utilisateur, effectuez l'une des opérations suivantes :
+
**Modifiez les paramètres par défaut du terminal :**
1. Choisissez le menu **Edition** dans le terminal Gnome.
1. Sélectionnez **Préférences**, puis **Profils**.
1. Choisissez **Command**, puis sélectionnez **Exécuter la commande en tant que shell de connexion**.
1. Ouvrez un nouveau terminal.
+ **Utilisez la ligne de commande pour rechercher les profils disponibles :**
```
$ source /etc/profile && source $HOME/.bashrc
```
# Résolution des problèmes dans les clusters avec AWS Batch intégration
Cette section fournit des conseils de dépannage possibles pour les clusters intégrant un AWS Batch planificateur, en particulier en ce qui concerne les problèmes de nœud principal, les problèmes de calcul, les échecs de tâches et les erreurs de délai d'attente.
**Topics**
+ [Problèmes liés au nœud principal](#troubleshooting-v3-batch-head-node)
+ [Problèmes de calcul](#troubleshooting-v3-batch-compute-nodes)
+ [Échecs des tâches](#troubleshooting-v3-batch-job-fail)
+ [Erreur d'expiration du délai de connexion en cas d'URL du point de terminaison](#troubleshooting-v3-batch-connect-timeout)
## Problèmes liés au nœud principal
Vous pouvez résoudre les problèmes de configuration du nœud principal de la même manière qu'un Slurm cluster (sauf pour les journaux Slurm spécifiques). Pour de plus amples informations sur ces problèmes, veuillez consulter [Nœud principal](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init.head-node).
## Problèmes de calcul
AWS Batch gère les aspects de dimensionnement et de calcul de vos services. Si vous rencontrez des problèmes liés au calcul, consultez la documentation de AWS Batch [dépannage](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html) pour obtenir de l'aide.
## Échecs des tâches
Si une tâche échoue, vous pouvez exécuter la [`awsbout`](awsbatchcli.awsbout-v3.md) commande pour récupérer le résultat de la tâche. Vous pouvez également exécuter la [`awsbstat`](awsbatchcli.awsbstat-v3.md) commande pour obtenir un lien vers les journaux des tâches stockés par Amazon CloudWatch.
## Erreur d'expiration du délai de connexion en cas d'URL du point de terminaison
Si les tâches parallèles sur plusieurs nœuds échouent avec une erreur : `Connect timeout on endpoint URL`
+ Dans le journal `awsbout` de sortie, vérifiez que la tâche est parallèle à plusieurs nœuds par rapport à la sortie : `Detected 3/3 compute nodes. Waiting for all compute nodes to start.`
+ Vérifiez si le sous-réseau des nœuds de calcul est public.
Les tâches parallèles à nœuds multiples ne prennent pas en charge l'utilisation de sous-réseaux publics lors de leur utilisation AWS Batch dans. AWS ParallelCluster Utilisez un sous-réseau privé pour vos nœuds de calcul et vos tâches. Pour plus d'informations, consultez la section [Considérations relatives à l'environnement informatique](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html#mnp-ce) dans le *Guide de AWS Batch l'utilisateur*. Pour configurer un sous-réseau privé pour vos nœuds de calcul, consultez[AWS ParallelCluster avec AWS Batch planificateur](network-configuration-v3-batch.md).
# Résolution des problèmes d'intégration multi-utilisateurs avec Active Directory
Cette section concerne les clusters intégrés à un Active Directory.
Si la fonctionnalité d'intégration d'Active Directory ne fonctionne pas comme prévu, les journaux SSSD peuvent fournir des informations de diagnostic utiles. Ces journaux se trouvent `/var/log/sssd` sur les nœuds du cluster. Par défaut, ils sont également stockés dans le groupe de CloudWatch journaux Amazon d'un cluster.
**Topics**
+ [Résolution des problèmes spécifiques à Active Directory](#troubleshooting-v3-multi-ad-specific)
+ [Activer le mode de débogage](#troubleshooting-v3-multi-user-debug)
+ [Comment passer de LDAPS à LDAP](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [Comment désactiver la vérification du certificat du serveur LDAPS](#troubleshooting-v3-multi-user-ldaps-verify)
+ [Comment se connecter avec une clé SSH plutôt qu'un mot de passe](#troubleshooting-v3-multi-user-ssh-login)
+ [Comment réinitialiser le mot de passe d'un utilisateur et les mots de passe expirés](#troubleshooting-v3-multi-user-reset-passwd)
+ [Comment vérifier le domaine joint](#troubleshooting-v3-multi-user-domain-verify)
+ [Comment résoudre les problèmes liés aux certificats](#troubleshooting-v3-multi-user-certificates)
+ [Comment vérifier que l'intégration avec Active Directory fonctionne](#troubleshooting-v3-multi-user-ad-verify)
+ [Comment résoudre les problèmes de connexion aux nœuds de calcul](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [Problèmes connus liés aux tâches SimCenter StarCCM\$1 dans un environnement multi-utilisateurs](#troubleshooting-v3-multi-user-ad-starccm)
+ [Problèmes connus liés à la résolution des noms d'utilisateur](#troubleshooting-v3-multi-user-name-resolution)
+ [Comment résoudre les problèmes de création du répertoire de base](#troubleshooting-v3-multi-home-directory)
## Résolution des problèmes spécifiques à Active Directory
Cette section concerne le dépannage spécifique à un type d'Active Directory.
### Simple AD
+ La `DomainReadOnlyUser` valeur doit correspondre à la recherche de base d'annuaires Simple AD pour les utilisateurs :
`cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com`
Remarque `cn` pour`Users`.
+ L'utilisateur administrateur par défaut est`Administrator`.
+ `Ldapsearch`nécessite le nom NetBIOS avant le nom d'utilisateur.
`Ldapsearch`la syntaxe doit être la suivante :
```
$ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \
-b "cn=Users,dc=corp,dc=example,dc=com"
```
### AWS Managed Microsoft AD
+ La `DomainReadOnlyUser` valeur doit correspondre à la recherche dans la base de AWS Managed Microsoft AD répertoires pour les utilisateurs :
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com`
+ L'utilisateur administrateur par défaut est`Admin`.
+ `Ldapsearch`la syntaxe doit être la suivante :
```
$ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
-b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"
```
## Activer le mode de débogage
Les journaux de débogage de SSSD peuvent être utiles pour résoudre les problèmes. Pour activer le mode de débogage, vous devez mettre à jour le cluster avec les modifications suivantes apportées à la configuration du cluster :
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## Comment passer de LDAPS à LDAP
Il est déconseillé de passer du protocole LDAPS (LDAP avec TLS/SSL) au protocole LDAP, car le protocole LDAP seul ne fournit aucun chiffrement. Néanmoins, cela peut être utile à des fins de test et de dépannage.
Vous pouvez rétablir la configuration précédente du cluster en le mettant à jour avec la définition de configuration précédente.
Pour passer de LDAPS à LDAP, vous devez mettre à jour le cluster en apportant les modifications suivantes à la configuration du cluster :
```
DirectoryService:
LdapTlsReqCert: never
AdditionalSssdConfigs:
ldap_auth_disable_tls_never_use_in_production: True
```
## Comment désactiver la vérification du certificat du serveur LDAPS
Il peut être utile de désactiver temporairement la vérification du certificat du serveur LDAPS sur le nœud principal, à des fins de test ou de dépannage.
Vous pouvez rétablir la configuration précédente du cluster en le mettant à jour avec la définition de configuration précédente.
Pour désactiver la vérification du certificat du serveur LDAPS, vous devez mettre à jour le cluster en apportant les modifications suivantes à la configuration du cluster :
```
DirectoryService:
LdapTlsReqCert: never
```
## Comment se connecter avec une clé SSH plutôt qu'un mot de passe
La clé SSH est créée lorsque vous vous connectez pour la première fois avec un mot de passe. `/home/$user/.ssh/id_rsa` Pour vous connecter avec la clé SSH, vous devez vous connecter avec votre mot de passe, copier la clé SSH localement, puis l'utiliser pour utiliser le protocole SSH sans mot de passe, comme d'habitude :
```
$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
```
## Comment réinitialiser le mot de passe d'un utilisateur et les mots de passe expirés
Si un utilisateur perd l'accès à un cluster, son [AWS Managed Microsoft AD mot de passe a peut-être expiré](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html).
Pour réinitialiser le mot de passe, exécutez la commande suivante avec un utilisateur et un rôle autorisés à écrire sur le répertoire :
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
Si vous réinitialisez le mot de passe du [`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser):
1. Assurez-vous de mettre à jour le [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn)secret avec le nouveau mot de passe.
1. Mettez à jour le cluster pour la nouvelle valeur secrète :
1. Arrêtez le parc informatique à l'aide de la `pcluster update-compute-fleet` commande.
1. Exécutez la commande suivante depuis le nœud principal du cluster.
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
Après la réinitialisation du mot de passe et la mise à jour du cluster, l'accès au cluster de l'utilisateur doit être rétabli.
Pour plus d'informations, voir [Réinitialiser un mot de passe utilisateur](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html) dans le *Guide d'Directory Service administration*.
## Comment vérifier le domaine joint
La commande suivante doit être exécutée à partir d'une instance jointe au domaine, et non du nœud principal.
```
$ realm list corp.example.com \
type: kerberos \
realm-name: CORP.EXAMPLE.COM \
domain-name: corp.example.com \
configured: kerberos-member \
server-software: active-directory \
client-software: sssd \
required-package: oddjob \
required-package: oddjob-mkhomedir \
required-package: sssd \
required-package: adcli \
required-package: samba-common-tools \
login-formats: %U \
login-policy: allow-realm-logins
```
## Comment résoudre les problèmes liés aux certificats
Lorsque la communication LDAPS ne fonctionne pas, cela peut être dû à des erreurs dans la communication TLS, qui à leur tour peuvent être dues à des problèmes liés aux certificats.
**Remarques concernant les certificats :**
+ Le certificat spécifié dans la configuration du cluster `LdapTlsCaCert` doit être un ensemble de certificats PEM contenant les certificats de l'ensemble de la chaîne de certificats d'autorité (CA) qui a émis les certificats pour les contrôleurs de domaine.
+ Un bundle de certificats PEM est un fichier constitué de la concaténation de certificats PEM.
+ Un certificat au format PEM (généralement utilisé sous Linux) est équivalent à un certificat au format Base64 DER (généralement exporté par Windows).
+ Si le certificat pour les contrôleurs de domaine est émis par une autorité de certification subordonnée, le bundle de certificats doit contenir le certificat de l'autorité de certification subordonnée et celui de l'autorité de certification racine.
**Étapes de vérification du dépannage :**
Les étapes de vérification suivantes supposent que les commandes sont exécutées depuis le nœud principal du cluster et que le contrôleur de domaine est accessible à l'adresse`SERVER:PORT`.
Pour résoudre un problème lié aux certificats, suivez les étapes de vérification suivantes :
**Étapes de vérification :**
1. **Vérifiez la connexion aux contrôleurs de domaine Active Directory :**
Vérifiez que vous pouvez vous connecter à un contrôleur de domaine. Si cette étape réussit, la connexion SSL au contrôleur de domaine aboutit et le certificat est vérifié. Votre problème n'est pas lié aux certificats.
Si cette étape échoue, passez à la prochaine vérification.
```
$ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
```
1. **Vérifiez la vérification du certificat :**
Vérifiez que le bundle de certificats CA local peut valider le certificat fourni par le contrôleur de domaine. Si cette étape aboutit, votre problème n'est pas lié aux certificats, mais à d'autres problèmes de réseau.
Si cette étape échoue, passez à la prochaine vérification.
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. **Vérifiez le certificat fourni par les contrôleurs de domaine Active Directory :**
Vérifiez que le contenu du certificat fourni par les contrôleurs de domaine est conforme aux attentes. Si cette étape aboutit, vous rencontrez probablement des problèmes avec le certificat CA utilisé pour vérifier les contrôleurs. Passez à l'étape de résolution des problèmes suivante.
Si cette étape échoue, vous devez corriger le certificat émis pour les contrôleurs de domaine et réexécuter les étapes de dépannage.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Vérifiez le contenu d'un certificat :**
Vérifiez que le contenu du certificat fourni par les contrôleurs de domaine est conforme aux attentes. Si cette étape aboutit, vous avez probablement des problèmes avec le certificat CA utilisé pour vérifier le contrôleur. Passez à l'étape de résolution des problèmes suivante.
Si cette étape échoue, vous devez corriger le certificat émis pour les contrôleurs de domaine et réexécuter les étapes de résolution des problèmes.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Vérifiez le contenu du bundle de certificats CA local :**
Vérifiez que le contenu du bundle de certificats CA local utilisé pour valider le certificat des contrôleurs de domaine est conforme aux attentes. Si cette étape aboutit, vous rencontrez probablement des problèmes avec le certificat fourni par les contrôleurs de domaine.
Si cette étape échoue, vous devez corriger le bundle de certificats CA émis pour les contrôleurs de domaine et réexécuter les étapes de dépannage.
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Comment vérifier que l'intégration avec Active Directory fonctionne
Si les deux vérifications suivantes aboutissent, l'intégration avec Active Directory fonctionne.
**Contrôles :**
1. **Vous pouvez découvrir les utilisateurs définis dans l'annuaire :**
Depuis le nœud principal du cluster, en tant que `ec2-user` :
```
$ getent passwd $ANY_AD_USER
```
1. **Vous pouvez vous connecter par SSH au nœud principal en fournissant le mot de passe utilisateur :**
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
Si le premier contrôle échoue, nous nous attendons à ce que le contrôle deux échoue également.
Contrôles de résolution des problèmes supplémentaires :
+ Vérifiez que l'utilisateur existe dans l'annuaire.
+ Activez la [journalisation du débogage](#troubleshooting-v3-multi-user-debug).
+ Envisagez de désactiver temporairement le chiffrement en [passant du protocole LDAPS au protocole LDAP afin d'éliminer les problèmes liés au protocole LDAPS](#troubleshooting-v3-multi-user-ldaps-ldap).
## Comment résoudre les problèmes de connexion aux nœuds de calcul
Cette section concerne la connexion aux nœuds de calcul des clusters intégrés à Active Directory.
Avec AWS ParallelCluster, les connexions par mot de passe aux nœuds de calcul du cluster sont désactivées par conception.
Tous les utilisateurs doivent utiliser leur propre clé SSH pour se connecter aux nœuds de calcul.
Les utilisateurs peuvent récupérer leur clé SSH dans le nœud principal après la première authentification (par exemple, connexion), si cette option [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers)est activée dans la configuration du cluster.
Lorsque les utilisateurs s'authentifient sur le nœud principal pour la première fois, ils peuvent récupérer les clés SSH qui sont automatiquement générées pour eux en tant qu'utilisateurs de l'annuaire. Des répertoires personnels pour l'utilisateur sont également créés. Cela peut également se produire la première fois qu'un sudo-utilisateur passe à un utilisateur du nœud principal.
Si un utilisateur ne s'est pas connecté au nœud principal, les clés SSH ne sont pas générées et l'utilisateur ne pourra pas se connecter aux nœuds de calcul.
## Problèmes connus liés aux tâches SimCenter StarCCM\$1 dans un environnement multi-utilisateurs
Cette section concerne les tâches lancées dans un environnement multi-utilisateurs par le logiciel de dynamique des fluides Simcenter StarCCM\$1 de Siemens.
Si vous exécutez des tâches StarCCM\$1 v16 configurées pour utiliser l'IntelMPI intégré, les processus MPI sont initialisés par défaut à l'aide de SSH.
En raison d'un [Slurmbogue](https://bugs.schedmd.com/show_bug.cgi?id=13385) connu qui entraîne une mauvaise résolution du nom d'utilisateur, les tâches peuvent échouer avec une erreur telle que`error setting up the bootstrap proxies`. Ce bogue n'affecte que AWS ParallelCluster les versions 3.1.1 et 3.1.2.
Pour éviter que cela ne se produise, forcez IntelMPI à l'utiliser Slurm comme méthode d'amorçage MPI. Exportez la variable d'environnement `I_MPI_HYDRA_BOOTSTRAP=slurm` dans le script de tâche qui lance StarCCM\$1, comme décrit dans la documentation officielle d'[IntelMPI](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html).
## Problèmes connus liés à la résolution des noms d'utilisateur
Cette section est pertinente pour récupérer les noms d'utilisateur dans les tâches.
En raison d'un [bogue connu dans Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385), le nom d'utilisateur récupéré dans un processus de travail peut être le `nobody` cas si vous exécutez un travail sans. `srun` Ce bogue n'affecte que AWS ParallelCluster les versions 3.1.1 et 3.1.2.
Par exemple, si vous exécutez la commande `sbatch --wrap 'srun id'` en tant qu'utilisateur de l'annuaire, le nom d'utilisateur correct est renvoyé. Toutefois, si vous l'exécutez `sbatch --wrap 'id'` en tant qu'utilisateur d'annuaire, `nobody` il peut être renvoyé sous forme de nom d'utilisateur.
Vous pouvez utiliser les solutions suivantes.
1. Lancez votre travail avec `'srun'` au lieu de`'sbatch'`, si possible.
1. Activez l'énumération SSSD en définissant la [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)configuration du cluster comme suit.
```
AdditionalSssdConfigs:
enumerate: true
```
## Comment résoudre les problèmes de création du répertoire de base
Cette section concerne les problèmes liés à la création du répertoire de base.
Si vous voyez des erreurs comme celle illustrée dans l'exemple suivant, aucun répertoire personnel n'a été créé pour vous lorsque vous vous êtes connecté pour la première fois au nœud principal. Ou bien, aucun répertoire de base n'a été créé pour vous lorsque vous êtes passé pour la première fois d'un sudoer à un utilisateur Active Directory dans le nœud principal.
```
$ ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
Could not chdir to home directory /home/PclusterUser85: No such file or directory
```
L'échec de création du répertoire de base peut être dû aux `oddjob-mkhomedir` packages `oddjob` et installés dans le nœud principal du cluster.
Sans répertoire de base et clé SSH, l'utilisateur ne peut pas envoyer de tâches ou de SSH aux nœuds du cluster.
Si vous avez besoin des `oddjob` packages dans votre système, vérifiez que le `oddjobd` service est en cours d'exécution et actualisez les fichiers de configuration PAM pour vous assurer que le répertoire de base a été créé. Pour ce faire, exécutez les commandes dans le nœud principal comme indiqué dans l'exemple suivant.
```
sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall
```
Si vous n'avez pas besoin des `oddjob` packages dans votre système, désinstallez-les et actualisez les fichiers de configuration PAM pour vous assurer que le répertoire de base a été créé. Pour ce faire, exécutez les commandes dans le nœud principal comme indiqué dans l'exemple suivant.
```
sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall
```
# Résolution des problèmes liés aux AMI personnalisées
Cette section fournit des conseils de dépannage possibles pour les problèmes liés aux AMI personnalisées.
Lorsque vous utilisez une AMI personnalisée, les avertissements suivants peuvent s'afficher :
```
"validationMessages": [
{
"level": "WARNING",
"type": "CustomAmiTagValidator",
"message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting."
},
{
"level": "WARNING",
"type": "AmiOsCompatibleValidator",
"message": "Could not check node AMI ami-0000012345 OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations."
}
]
```
Si vous êtes sûr que l'AMI utilisée est correcte, vous pouvez ignorer ces avertissements.
Si vous ne souhaitez pas voir ces avertissements à l'avenir, balisez l'AMI personnalisée avec les balises suivantes, où se `my-os` trouve l'une des balises suivantes `alinux2` `alinux2023``ubuntu2404`,`ubuntu2204`,`rhel8`,, ou `rhel9` et *"3.15.0"* quelle est la `pcluster` version utilisée :
```
$ aws ec2 create-tags \
--resources ami-yourcustomAmi \
--tags Key="parallelcluster:version",Value="3.15.0" Key="parallelcluster:os",Value="my-os"
```
# Résolution d'un délai d'expiration de mise à jour du cluster en cas `cfn-hup` d'inexécution
Le script d’assistance `cfn-hup` est un démon qui détecte les modifications des métadonnées de ressources et exécute les actions définies par l’utilisateur lorsqu’un changement est détecté. C'est ainsi que vous pouvez effectuer des mises à jour de configuration sur vos instances Amazon EC2 en cours d'exécution par le biais de l'action `UpdateStack` API.
Actuellement, le `cfn-hup` daemon est lancé par le`supervisord`. Mais après le lancement, le `cfn-hup` processus est déconnecté du `supervisord` contrôle. Si le `cfn-hup` démon est tué par un acteur externe, il ne redémarre pas 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 la pile finit par atteindre un délai d'expiration. Dans les journaux du cluster`/var/log/chef-client`, vous pouvez voir que la recette de mise à jour n'est jamais invoquée.
**Vérifiez et redémarrez `cfn-hup` en cas de panne**
1. Sur le nœud principal, vérifiez s'il `cfn-hup` est en cours d'exécution :
```
$ ps aux | grep cfn-hup
```
1. Vérifiez `cfn-hup` le journal `/var/log/cfn-hup.log` et `/var/log/supervisord.log` le nœud principal.
1. S'il `cfn-hup` n'est pas en cours d'exécution, essayez de le redémarrer en exécutant :
```
$ sudo /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/supervisorctl start cfn-hup
```
# Dépannage du réseau
Cette section fournit des conseils de dépannage lorsque vous rencontrez des problèmes de réseau, en particulier lorsqu'il s'agit d'un problème de cluster dans un seul sous-réseau public.
## Problèmes liés au regroupement dans un seul sous-réseau public
Vérifiez le `cloud-init-output.log` depuis l'un des nœuds de calcul. Si vous trouvez quelque chose comme ce qui suit qui indique que le nœud est bloqué lors de l'Slurminitialisation, cela est probablement dû à l'absence d'un point de terminaison DynamoDB VPC. Ajoutez le point de terminaison DynamoDB. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster dans un seul sous-réseau sans accès à Internet](aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.md).
```
ruby_block[retrieve compute node info] action run[2022-03-11T17:47:11+00:00] INFO: Processing ruby_block[retrieve compute node info] action run (aws-parallelcluster-slurm::init line 31)
```
# La mise à jour du cluster a échoué lors d'`onNodeUpdated`une action personnalisée
Lorsqu'un [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated)script [`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)/échoue, la mise à jour échoue et le script n'est pas exécuté au moment de la restauration. Il est de votre responsabilité d'effectuer manuellement les nettoyages nécessaires une fois la restauration terminée. Par exemple, si le `OnNodeUpdated` script modifie le statut d'un champ dans un fichier de configuration (par exemple, de `true` à`false`) puis échoue, vous devez restaurer manuellement la valeur de ce champ à son état antérieur à la mise à jour (par exemple, `false` à`true`). Pour de plus amples informations, veuillez consulter [Actions de bootstrap personnalisées](custom-bootstrap-actions-v3.md).
# Voir les erreurs liées à la Slurm configuration personnalisée
À partir de AWS ParallelCluster la version 3.6.0, vous ne pouvez plus cibler un `prolog` ou plusieurs `epilog` scripts en les incluant dans une Slurm configuration personnalisée. Dans les AWS ParallelCluster versions 3.6.0 et ultérieures, vous devez localiser les scripts personnalisés `prolog` et les `epilog` scripts dans les `Epilog` dossiers `Prolog` et correspondants. Ces dossiers sont configurés par défaut pour pointer vers :
+ `Prolog`pointe vers`/opt/slurm/etc/scripts/prolog.d/`.
+ `Epilog`pointe vers`/opt/slurm/etc/scripts/epilog.d/`.
Nous vous recommandons de conserver le script `90_plcuster_health_check_manager` prolog et le script `90_pcluster_noop` epilog en place.
Slurmexécute les scripts dans l'ordre alphabétique inverse. Le `Epilog` dossier `Prolog` et doit contenir au moins un fichier. Pour plus d’informations, consultez [Slurm et `prolog` `epilog`](slurm-prolog-epilog-v3.md) et [Slurm personnalisation de la configuration](slurm-configuration-settings-v3.md).
# Alarmes de cluster
La surveillance de l'état du cluster est essentielle pour garantir des performances optimales. AWS ParallelCluster vous permet de surveiller plusieurs alarmes CloudWatch basées sur le nœud principal du cluster.
Cette section fournit des détails sur chaque type d'alarmes du cluster de nœuds principaux, y compris ses conventions de dénomination, les conditions spécifiques qui déclenchent les alarmes et les étapes de dépannage suggérées.
La convention de dénomination pour les alarmes de cluster est`CLUSTER_NAME-COMPONENT-METRIC`, par `mycluster-HeadNode-Cpu` ex.
+ `CLUSTER_NAME-HeadNode`: indique l'état général du nœud principal. Il est rouge si au moins l'une des alarmes ci-dessous l'est.
+ `CLUSTER_NAME-HeadNode-Health`: rouge s'il y a au moins un échec d'Amazon EC2 Health Check. En cas d'alarme, nous vous suggérons de consulter la section [Résoudre les problèmes des instances dont les vérifications d'état ont échoué](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).
+ `CLUSTER_NAME-HeadNode-Cpu`: rouge si l'utilisation du processeur est supérieure à 90 %. En cas d'alarme, vérifiez les processus qui consomment le plus le processeur`ps -aux --sort=-%cpu | head -n 10`.
+ `CLUSTER_NAME-HeadNode-Mem`: rouge si l'utilisation de la mémoire est supérieure à 90 %. En cas d'alarme, vérifiez les processus qui consomment le plus de mémoire`ps -aux --sort=-%mem | head -n 10`.
+ `CLUSTER_NAME-HeadNode-Disk`: rouge si l'espace disque occupé est supérieur à 90 % sur le chemin /. En cas d'alarme, vérifiez les dossiers qui occupent la plus grande partie de l'espace`du -h --max-depth=2 / 2> /dev/null | sort -hr`.
# Résolution des modifications de configuration du système d'exploitation à l'origine d'erreurs ou de défaillances
Lorsque vous modifiez la configuration du système d'exploitation sur AWS ParallelCluster les nœuds, divers problèmes peuvent survenir et entraîner des échecs de création, de mise à jour ou de fonctionnement du cluster. Cette section fournit des conseils pour identifier et résoudre les problèmes courants liés à la configuration du système d'exploitation.
## Problèmes courants de configuration du système d'exploitation
### Problèmes de configuration locale
L'un des problèmes de configuration du système d'exploitation les plus courants est lié aux paramètres régionaux. Si vous voyez des erreurs telles que :
```
cannot change locale (en_US.utf-8) because it has an invalid name
```
Cela se produit généralement lorsque :
+ Un processus `yum` d'installation a échoué et a laissé les paramètres régionaux dans un état incohérent
+ Un utilisateur a mis fin à un processus d'installation prématurément
+ Les packages régionaux sont manquants ou endommagés
#### Comment diagnostiquer
1. Vérifiez si vous pouvez passer à l'utilisateur pcluster-admin :
```
$ su - pcluster-admin
```
Si un message d'erreur de ce type s'affiche`cannot change locale...no such file or directory`, cela confirme le problème.
1. Vérifiez les langues disponibles :
```
$ localedef --list
```
Si cela renvoie une liste vide ou ne contient pas les paramètres régionaux par défaut, cela signifie que votre configuration locale est interrompue.
1. Vérifiez la dernière `yum` commande :
```
$ yum history
$ yum history info #ID
```
Si le dernier ID n'en a pas`Return-Code: Success`, les scripts de post-installation ne se sont peut-être pas exécutés correctement.
#### Comment résoudre
Reconstruisez les paramètres régionaux en réinstallant les modules linguistiques :
```
$ sudo yum reinstall glibc-all-langpacks
```
Après la reconstruction, vérifiez que le problème est résolu en exécutant :
```
$ su - pcluster-admin
```
Si aucune erreur ou aucun avertissement n'apparaît, le problème a été résolu.
### Conflits de packages du système
Lors de l'installation de packages personnalisés ou de la modification de packages système, des conflits peuvent survenir et empêcher le bon fonctionnement du cluster.
#### Comment diagnostiquer
1. Consultez le journal chef-client pour détecter les erreurs liées au package :
```
$ less /var/log/chef-client.log
```
1. Recherchez les conflits de dépendance des packages dans le journal cfn-init :
```
$ less /var/log/cfn-init.log
```
#### Comment résoudre
1. Si un package spécifique pose problème, essayez de le réinstaller :
```
$ sudo yum reinstall package-name
```
1. En cas de conflit de dépendance, vous devrez peut-être supprimer les packages en conflit :
```
$ sudo yum remove conflicting-package
```
1. Si le problème persiste, envisagez de créer une AMI personnalisée avec les packages requis préinstallés à l'aide de la `pcluster build-image` commande. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster Personnalisation de l'AMI](custom-ami-v3.md).
### Modifications du fichier de configuration du système
La modification des fichiers de configuration système critiques peut provoquer des défaillances de clusters, en particulier si ces fichiers sont gérés par AWS ParallelCluster.
#### Comment diagnostiquer
1. Vérifiez les erreurs dans le journal chef-client qui mentionnent des fichiers de configuration spécifiques :
```
$ grep -i "config" /var/log/chef-client.log
```
1. Recherchez les erreurs d'autorisation ou de syntaxe dans les fichiers de configuration :
```
$ less /var/log/cfn-init.log
```
#### Comment résoudre
1. Restaurez les fichiers de configuration modifiés dans leur état d'origine :
```
$ sudo cp /etc/file.conf.bak /etc/file.conf
```
1. Si vous devez apporter des modifications persistantes aux fichiers de configuration du système, utilisez des actions d'amorçage personnalisées au lieu de modifier directement les fichiers :
```
HeadNode:
CustomActions:
OnNodeConfigured:
Script: s3://bucket-name/config-script.sh
```
Pour de plus amples informations, veuillez consulter [Actions de bootstrap personnalisées](custom-bootstrap-actions-v3.md).
1. Pour les modifications de configuration qui doivent être apportées directement aux fichiers système, pensez à créer une AMI personnalisée. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster Personnalisation de l'AMI](custom-ami-v3.md).
### Mises à jour du noyau et problèmes de compatibilité
Les mises à jour du noyau peuvent entraîner des problèmes de compatibilité avec certains AWS services, en particulier avec Amazon FSx for Lustre.
#### Comment diagnostiquer
1. Vérifiez si les mises à jour du noyau ont été appliquées :
```
$ uname -r
```
1. Recherchez les échecs de FSx montage d'Amazon dans les journaux :
```
$ grep -i "fsx" /var/log/chef-client.log
```
#### Comment résoudre
1. Pour Ubuntu 22.04, évitez de mettre à jour le dernier noyau car il n'existe aucun FSx client Amazon pour ce noyau. Pour de plus amples informations, veuillez consulter [Considérations relatives au système d'exploitation](operating-systems-v3.md#OS-Consideration-v3).
1. Si vous avez déjà mis à jour le noyau et que vous rencontrez des problèmes, pensez à le rétrograder vers une version compatible :
```
$ sudo apt install linux-image-previous-version
```
1. Pour les personnalisations persistantes du noyau, créez une AMI personnalisée avec la version de noyau spécifique dont vous avez besoin. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster Personnalisation de l'AMI](custom-ami-v3.md).
## Bonnes pratiques pour les modifications de configuration du système d'exploitation
Pour minimiser les problèmes lors de la modification de la configuration du système d'exploitation :
1. **Utilisez des actions Bootstrap personnalisées** : au lieu de modifier directement les fichiers système, utilisez `OnNodeStart` des `OnNodeConfigured` scripts pour apporter des modifications de manière contrôlée. Pour de plus amples informations, veuillez consulter [Actions de bootstrap personnalisées](custom-bootstrap-actions-v3.md).
1. **Création personnalisée AMIs** : pour les modifications importantes du système d'exploitation, créez une AMI personnalisée en utilisant `pcluster build-image` plutôt que d'apporter des modifications aux instances en cours d'exécution. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster Personnalisation de l'AMI](custom-ami-v3.md).
1. **Testez d'abord les modifications** : avant d'appliquer des modifications à un cluster de production, testez-les sur un petit cluster de test pour garantir la compatibilité.
1. **Modifications apportées aux documents** : gardez une trace de toutes les modifications apportées à la configuration du système d'exploitation pour faciliter le dépannage.
1. **Fichiers de configuration de sauvegarde** : Avant de modifier un fichier de configuration système, créez une sauvegarde :
```
$ sudo cp /etc/file.conf /etc/file.conf.bak
```
1. **Vérifier les journaux après les modifications** : après avoir modifié la configuration du système d'exploitation, vérifiez les journaux pour détecter d'éventuelles erreurs :
```
$ less /var/log/cfn-init.log
$ less /var/log/chef-client.log
```
En suivant ces directives, vous pouvez minimiser le risque que des modifications de configuration du système d'exploitation entraînent des défaillances de clusters et résoudre plus efficacement les problèmes éventuels.