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 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** + [Récupération et conservation des journaux](#retrieving-and-preserve-logs) + [Résolution des problèmes de déploiement des piles](#troubleshooting-stack-creation-failures) + [Résolution des problèmes dans plusieurs clusters en mode file d'attente](#multiple-queue-mode) + [Résolution des problèmes dans les clusters en mode file d'attente unique](#troubleshooting-issues-in-single-queue-clusters) + [Problèmes liés aux groupes de placement et au lancement d'instances](#placement-groups-and-instance-launch-issues) + [Répertoires qui ne peuvent pas être remplacés](#directories-cannot-be-replaced) + [Résolution des problèmes dans Amazon DCV](#nice-dcv-troubleshooting) + [Résolution des problèmes dans les clusters avec AWS Batch intégration](#clusters-with-aws-batch-integration) + [Résolution des problèmes en cas d'échec de création d'une ressource](#troubleshooting-resource-fails-to-create) + [Résolution des problèmes liés à la taille des politiques IAM](#troubleshooting-policy-size-issues) + [Support supplémentaire](#getting-support) ## Récupération et conservation des journaux Les journaux constituent une ressource utile pour résoudre les problèmes. Avant de pouvoir utiliser les journaux pour résoudre les problèmes liés à vos AWS ParallelCluster ressources, vous devez d'abord créer une archive des journaux du cluster. Suivez les étapes décrites dans la rubrique [Création d'une archive des journaux d'un cluster](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) sur le [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/) pour démarrer ce processus. Si l'un de vos clusters en cours d'exécution rencontre des problèmes, vous devez le placer dans un `STOPPED` état en exécutant la ``pcluster stop` ` commande avant de commencer le dépannage. Cela évite d'encourir des coûts imprévus. S'il `pcluster` cesse de fonctionner ou si vous souhaitez supprimer un cluster tout en préservant ses journaux, exécutez la ``pcluster delete` —keep-logs ` commande. L'exécution de cette commande supprime le cluster tout en conservant le groupe de journaux stocké sur Amazon CloudWatch. Pour plus d'informations sur cette commande, consultez la [`pcluster delete`](pcluster.delete.md) documentation. ## Résolution des problèmes de déploiement des piles Si votre cluster ne parvient pas à être créé et annule la création de la pile, vous pouvez consulter les fichiers journaux suivants pour diagnostiquer le problème. Vous souhaitez rechercher le résultat de `ROLLBACK_IN_PROGRESS` dans ces journaux. Le message d'échec doit se présenter comme suit : ``` $ pcluster create mycluster Creating stack named: parallelcluster-mycluster Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081 ``` Pour diagnostiquer le problème, créez à nouveau le cluster en utilisant[`pcluster create`](pluster.create.md), y compris le `--norollback` drapeau. Ensuite, connectez-vous au cluster en SSH : ``` $ pcluster create mycluster --norollback ... $ pcluster ssh mycluster ``` Une fois connecté au nœud principal, vous devriez trouver trois fichiers journaux principaux que vous pouvez utiliser pour identifier 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 voyiez 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 dans plusieurs clusters en mode file d'attente Cette section concerne les clusters installés à l'aide de la AWS ParallelCluster version 2.9.0 ou ultérieure avec le planificateur de Slurm tâches. Pour plus d'informations sur le mode de file d'attente multiple, consultez[Mode de file d'attente multiple](queue-mode.md). **Topics** + [Journaux clés](#key-logs) + [**Résolution des problèmes d'initialisation des nœuds**](#troubleshooting-node-initialization-issues) + [**Résolution des problèmes de remplacement et de terminaison inattendus de nœuds**](#troubleshooting-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) + [**Résolution d'autres problèmes connus liés aux nœuds et aux tâches**](#troubleshooting-other-known-node-and-job-issues) ### Journaux clés Le tableau suivant fournit une vue d'ensemble des journaux clés du nœud principal : `/var/log/cfn-init.log` Il s'agit du journal CloudFormation d'initialisation. Il contient toutes les commandes qui ont été exécutées lors de la configuration d'une instance. C'est utile pour résoudre les problèmes d'initialisation. `/var/log/chef-client.log` Il s'agit du journal du client Chef. Il contient toutes les commandes qui ont été exécutées via CHEF/CINC. C'est utile 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 et est utile 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 et est utile 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. C'est utile pour résoudre tout problème 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. Voici les remarques clés concernant les 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 qui ont été exécutées lors de la configuration d'une instance. C'est utile 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 les rares cas où le `clustermgtd` démon du nœud principal est hors ligne. C'est utile 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. C'est utile pour résoudre les problèmes liés à l'initialisation et aux pannes de calcul. ### **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. **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` Vérifiez les `/var/log/chef-client.log` journaux `/var/log/cfn-init.log` et. Ces journaux doivent contenir toutes les actions exécutées lors de la configuration du nœud principal. La plupart des erreurs survenant au cours de l'installation doivent contenir un message d'erreur dans le `/var/log/chef-client.log` journal. Si des scripts de pré-installation ou de post-installation 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. Ainsi, 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 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 devrait 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 le dépannage 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 :** + **Journaux applicables :** + `/var/log/cloud-init-output.log` + `/var/log/slurmd.log` + Si le nœud de calcul est lancé`/var/log/cloud-init-output.log`, vérifiez d'abord, 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 Slurm configuration, il se peut qu'une erreur Slurm connexe 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. ### **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 l'action de remplacement ou de résiliation d'un nœud `clustermgtd` a été entreprise. 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 prendre des mesures pour mettre fin à un nœud s'il `clustermgtd` est déterminé qu'il n'est pas en bon état. 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 à partir d'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. + Après le démarrage du nœud, activez la protection de terminaison à l'aide de cette commande. ``` aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination ``` + Récupérez la sortie de console depuis le nœud à l'aide de cette commande. ``` aws ec2 get-console-output --instance-id i-xyz --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[`scaledown_idletime`](scaling-section.md#scaledown-idletime), 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. ### **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. ## Résolution des problèmes dans les clusters en mode file d'attente unique **Note** À partir de la version 2.11.5, l'utilisation des planificateurs AWS ParallelCluster n'est pas prise en SGE charge. Torque Cette section s'applique aux clusters qui ne disposent pas du mode de file d'attente multiple avec l'une des deux configurations suivantes : + Lancé à l'aide d'une AWS ParallelCluster version antérieure à 2.9.0 SGE et/ou Torque de planificateurs de Slurm tâches. + Lancé à l'aide de AWS ParallelCluster la version 2.9.0 ou ultérieure et/ou de SGE planificateurs de Torque tâches. **Topics** + [Journaux clés](#key-logs-1) + [**Résolution des problèmes d'échec des opérations de lancement et de jointure**](#troubleshooting-failed-launch-and-join-operations) + [Résolution des problèmes de dimensionnement](#troubleshooting-scaling-issues) + [Résolution d'autres problèmes liés au cluster](#troubleshooting-other-cluster-related-issues) ### Journaux clés Les fichiers journaux suivants sont les journaux clés du nœud principal. Pour AWS ParallelCluster la version 2.9.0 ou ultérieure : `/var/log/chef-client.log` Il s'agit du journal du client CINC (chef). Il contient toutes les commandes qui ont été exécutées via CINC. C'est utile pour résoudre les problèmes d'initialisation. Pour toutes les AWS ParallelCluster versions : `/var/log/cfn-init.log` Voici le `cfn-init` journal. Il contient toutes les commandes qui ont été exécutées lors de la configuration d'une instance et est donc utile pour résoudre les problèmes d'initialisation. Pour plus d'informations, consultez [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html). `/var/log/clustermgtd.log` Il s'agit du `clustermgtd` journal destiné aux Slurm planificateurs. `clustermgtd`fonctionne en tant que démon centralisé qui gère la plupart des actions des opérations de cluster. C'est utile pour résoudre tout problème de lancement, de terminaison ou de fonctionnement du cluster. `/var/log/jobwatcher` Il s'agit du `jobwatcher` journal pour SGE et pour les Torque planificateurs. `jobwatcher`surveille la file d'attente du planificateur et met à jour le groupe Auto Scaling. C'est utile pour résoudre les problèmes liés à la mise à l'échelle des nœuds. `/var/log/sqswatcher` Il s'agit du `sqswatcher` journal pour SGE et pour les Torque planificateurs. `sqswatcher`traite l'événement Instance Ready envoyé par une instance de calcul après une initialisation réussie. Il ajoute également des nœuds de calcul à la configuration du planificateur. Ce journal est utile pour résoudre les problèmes liés à l'échec d'un ou de plusieurs nœuds à rejoindre un cluster. Les journaux clés des nœuds de calcul sont les suivants. AWS ParallelCluster version 2.9.0 ou ultérieure `/var/log/cloud-init-output.log` Il s'agit du journal d'initialisation du Cloud. Il contient toutes les commandes qui ont été exécutées lors de la configuration d'une instance. C'est utile pour résoudre les problèmes d'initialisation. AWS ParallelCluster versions antérieures à 2.9.0 `/var/log/cfn-init.log` Il s'agit du journal CloudFormation d'initialisation. Il contient toutes les commandes qui ont été exécutées lors de la configuration d'une instance. C'est utile pour résoudre les problèmes d'initialisation Toutes les versions `/var/log/nodewatcher` Voici le `nodewatcher` journal. `nodewatcher`des démons qui s'exécutent sur chaque nœud de calcul lors de l'utilisation SGE et Torque des planificateurs. Ils réduisent la taille d'un nœud s'il est inactif. Ce journal est utile pour tout problème lié à la réduction des ressources. ### **Résolution des problèmes d'échec des opérations de lancement et de jointure** + **Journaux applicables :** + `/var/log/cfn-init-cmd.log`(nœud principal et nœud de calcul) + `/var/log/sqswatcher`(nœud principal) + Si les nœuds n'ont pas pu être lancés, consultez le `/var/log/cfn-init-cmd.log` journal pour voir le message d'erreur spécifique. Dans la plupart des cas, les échecs de lancement des nœuds sont dus à un échec de configuration. + Si les nœuds de calcul n'ont pas réussi à rejoindre la configuration du planificateur malgré une configuration réussie, consultez le `/var/log/sqswatcher` journal pour voir si l'événement a `sqswatcher` été traité. Dans la plupart des cas, ces problèmes sont dus au fait que l'événement `sqswatcher` n'a pas été traité. ### Résolution des problèmes de dimensionnement + **Journaux applicables :** + `/var/log/jobwatcher`(nœud principal) + `/var/log/nodewatcher`(nœud de calcul) + **Problèmes de mise à l'échelle :** pour le nœud principal, consultez le `/var/log/jobwatcher` journal pour voir si le `jobwatcher` daemon a calculé le nombre approprié de nœuds requis et a mis à jour le groupe Auto Scaling. Notez qu'il `jobwatcher` surveille la file d'attente du planificateur et met à jour le groupe Auto Scaling. + **Problèmes de réduction :** pour les nœuds de calcul, consultez le `/var/log/nodewatcher` journal du nœud problématique pour savoir pourquoi le nœud a été réduit. Notez que les `nodewatcher` démons réduisent la taille d'un nœud de calcul s'il est inactif. ### Résolution d'autres problèmes liés au cluster L'un des problèmes connus est l'échec des notes de calcul aléatoires sur les clusters à grande échelle, en particulier ceux comportant 500 nœuds de calcul ou plus. Ce problème est lié à une limitation de l'architecture de dimensionnement d'un cluster de files d'attente unique. Si vous souhaitez utiliser un cluster à grande échelle, si vous utilisez la AWS ParallelCluster version v2.9.0 ou ultérieure, si vous utilisez et souhaitez éviter ce problèmeSlurm, vous devez effectuer une mise à niveau et passer à un cluster compatible avec le mode de files d'attente multiples. Vous pouvez le faire en courant[`pcluster-config convert`](pcluster-config.md#pcluster-config-convert). Pour les ultra-large-scale clusters, un réglage supplémentaire de votre système peut être nécessaire. Pour plus d'informations, contactez Support. ## 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 sont situées sur la même structure de mise en 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 [`placement_group`](cluster-definition.md#placement-group) paramètre sur `DYNAMIC` et définissez le [`placement`](cluster-definition.md#placement) paramètre sur`compute`. Si vous avez besoin d'un système de fichiers partagé performant, pensez à l'utiliser [FSx pour Lustre](https://aws.amazon.com/fsx/lustre/). Si le nœud principal doit se trouver dans le groupe de placement, utilisez le même type d'instance et le même sous-réseau pour le nœud principal et pour tous les nœuds de calcul. Ce faisant, le [`compute_instance_type`](cluster-definition.md#compute-instance-type) paramètre a la même valeur que le [`master_instance_type`](cluster-definition.md#master-instance-type) paramètre, le [`placement`](cluster-definition.md#placement) paramètre est défini sur et le [`compute_subnet_id`](vpc-section.md#compute-subnet-id) paramètre n'est pas spécifié. `cluster` Avec cette configuration, la valeur du [`master_subnet_id`](vpc-section.md#master-subnet-id) paramètre est utilisée pour les nœuds de calcul. 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 [Groupes de placement, rôles et limites](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) du guide de l'*utilisateur Amazon EC2*. ## Répertoires qui ne peuvent pas être remplacés Les répertoires suivants sont partagés entre les nœuds et ne peuvent pas être remplacés. `/home` Cela inclut le dossier personnel par défaut de l'utilisateur (`/home/ec2_user`sur Amazon LinuxCentOS, `/home/centos` activé et `/home/ubuntu` activéUbuntu). `/opt/intel` Ce répertoire inclut les fichiers Intel MPI, Intel Parallel Studio et les fichiers associés. `/opt/sge` À partir de la version 2.11.5, l'utilisation des planificateurs AWS ParallelCluster n'est pas prise en SGE charge. Torque Ce répertoire inclut Son of Grid Engine et les fichiers associés. (Conditionnel, seulement si [`scheduler`](cluster-definition.md#scheduler)` = sge`.) `/opt/slurm` Ce répertoire inclut Slurm Workload Manager et les fichiers associés. (Conditionnel, seulement si [`scheduler`](cluster-definition.md#scheduler)` = slurm`.) `/opt/torque` À partir de la version 2.11.5, l'utilisation des planificateurs AWS ParallelCluster n'est pas prise en SGE charge. Torque Ce répertoire inclut Torque Resource Manager et les fichiers associés. (Conditionnel, seulement si [`scheduler`](cluster-definition.md#scheduler)` = torque`.) ## Résolution des problèmes dans Amazon DCV **Topics** + [Journaux pour Amazon DCV](#nice-dcv-troubleshooting-logs) + [Mémoire de type d'instance Amazon DCV](#nice-dcv-troubleshooting-memory) + [Problèmes liés à Ubuntu Amazon DCV](#nice-dcv-troubleshooting-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. ### Mémoire de type d'instance Amazon DCV Le type d'instance doit disposer d'au moins 1,7 Gibioctet (GiB) de RAM pour exécuter Amazon DCV. Nanoet les types d'microinstances ne disposent pas de suffisamment de mémoire pour exécuter Amazon DCV. ### Problèmes liés à Ubuntu Amazon DCV Lorsque vous exécutez Gnome Terminal sur une session 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 concerne les clusters avec intégration d'un AWS Batch planificateur. ### Problèmes liés au nœud principal Les problèmes de configuration liés au nœud principal peuvent être résolus de la même manière qu'un cluster de files d'attente unique. Pour de plus amples informations sur ces problèmes, veuillez consulter [Résolution des problèmes dans les clusters en mode file d'attente unique](#troubleshooting-issues-in-single-queue-clusters). ### AWS Batch problèmes de soumission de tâches parallèles sur plusieurs nœuds Si vous rencontrez des problèmes pour soumettre des tâches parallèles sur plusieurs nœuds lorsque vous les utilisez AWS Batch comme planificateur de tâches, vous devez passer à AWS ParallelCluster la version 2.5.0. Si cela n'est pas possible, vous pouvez utiliser la solution décrite dans la rubrique : Appliquer [un correctif automatique à un cluster utilisé pour soumettre des tâches parallèles sur plusieurs nœuds via](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch). AWS Batch ### 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`` commande pour récupérer le résultat de la tâche. Vous pouvez également exécuter la ``awsbstat` -d` commande pour obtenir un lien vers les journaux des tâches stockés par Amazon CloudWatch. ## Résolution des problèmes en cas d'échec de création d'une ressource Cette section concerne les ressources du cluster lorsque leur création échoue. Lorsqu'une ressource ne parvient pas à être créée, ParallelCluster renvoie un message d'erreur comme celui-ci. ``` pcluster create -c config my-cluster Beginning cluster creation for cluster: my-cluster WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). Info: There is a newer version 3.0.3 of AWS ParallelCluster available. Creating stack named: parallelcluster-my-cluster Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::CloudFormation::Stack MasterServerSubstack Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. - AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. - AWS::EC2::Instance MasterServer 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) } ``` Par exemple, si le message d'état s'affiche dans la réponse de commande précédente, vous devez utiliser des types d'instance qui ne dépasseront pas votre limite de vCPU actuelle ou qui ne demanderont pas une capacité de vCPU accrue. Vous pouvez également utiliser la CloudFormation console pour consulter les informations relatives à l'`"Cluster creation failed"`état. 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 parallelcluster-. *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. Exemple de message d' AWS CloudFormation erreur : ``` 2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. ``` ## Résolution des problèmes liés à la taille des politiques IAM Reportez-vous à l'[IAM et aux AWS STS quotas, aux exigences relatives aux noms et aux limites de caractères](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) pour vérifier les quotas sur les politiques gérées associées aux rôles. Si la taille d'une politique gérée dépasse le quota, divisez-la en deux politiques ou plus. Si vous dépassez le quota du nombre de politiques associées à un rôle IAM, créez des rôles supplémentaires et répartissez les politiques entre eux pour atteindre le quota. ## Support supplémentaire Pour une liste des problèmes connus, consultez la page principale du [GitHubWiki](https://github.com/aws/aws-parallelcluster/wiki) ou la page [des problèmes](https://github.com/aws/aws-parallelcluster/issues). Pour les problèmes plus urgents, contactez Support ou ouvrez un [nouveau GitHub numéro](https://github.com/aws/aws-parallelcluster/issues).