AWS ParallelCluster résolution des problèmes - AWS ParallelCluster
Récupération et conservation des journauxRésolution des problèmes de déploiement des pilesRésolution des problèmes dans plusieurs clusters en mode file d'attenteRésolution des problèmes dans les clusters en mode file d'attente uniqueProblèmes liés aux groupes de placement et au lancement d'instancesRépertoires qui ne peuvent pas être remplacésRésolution des problèmes sur Amazon DCVRésolution des problèmes dans les clusters avec AWS Batch intégrationRésolution des problèmes en cas d'échec de création d'une ressourceRésolution des problèmes liés à la taille des IAM politiquesSupport supplémentaire

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. Pour obtenir la liste des problèmes connus, consultez la section Problèmes connus.

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 sur le AWS ParallelCluster GitHub 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 <cluster_name> 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 <cluster_name> 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 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 utilisantpcluster create, y compris le --norollback drapeau. Ensuite, SSH dans le cluster :

$ 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.logest 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.

  • /var/log/cloud-init.logest le journal de cloud-init. Si rien ne s'y trouvecfn-init.log, essayez ensuite de consulter ce journal.

  • /var/log/cloud-init-output.logest le résultat des commandes exécutées par cloud-init. Cela inclut la sortie decfn-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 AWS ParallelCluster la version 2.9.0 ou ultérieure avec Slurm planificateur de tâches. Pour plus d'informations sur le mode de file d'attente multiple, consultezMode de file d'attente multiple.

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 AWS 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 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

C'est le Slurm journal du démon de contrôle. AWS ParallelCluster ne prend pas de décisions de mise à l'échelle. Au contraire, il tente uniquement de lancer des ressources pour satisfaire 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. 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

C'est le Slurm journal des démons de 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 log (/var/log/slurmctld.log) pour déterminer si Slurm J'ai déjà essayé d'appeler ResumeProgram avec le nœud.)

  • Notez que des autorisations incorrectes pour ResumeProgram peuvent ResumeProgram entraîner un échec silencieux. Si vous utilisez une option personnalisée AMI avec modification lors de la ResumeProgram configuration, vérifiez qu'elle ResumeProgram appartient à l'slurmutilisateur 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 option personnalisée AMI modifiée pour Slurm configuration, alors il pourrait y avoir un Slurm erreur associée qui 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 dedansDOWN), consultez le slurmctld journal pour plus d'informations. Si la raison est EC2 liée à Amazon, il doit y avoir un message informatif détaillant le problème EC2 lié à Amazon 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 AmazonEC2, 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 ne fonctionne pas correctement. 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 que vous clustermgtd signalez 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 :

      • Soumettre une offre d'emploi à louer Slurm créez 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 dynamiquescaledown_idletime, consultez le SuspendProgram journal pour voir s'SuspendProgramil a été appelé slurmctld avec le nœud spécifique comme argument. Notez qu'SuspendProgramaucune 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 parclustermgtd. Slurm remet 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 seuls le lancement, la résiliation ou la maintenance des ressources conformément à 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, AWS ParallelCluster ne prend pas en charge l'utilisation de SGE or Torque planificateurs.

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 et SGE, Torque, ou Slurm planificateurs de tâches.

  • Lancé avec AWS ParallelCluster la version 2.9.0 ou ultérieure et SGE or Torque planificateurs de tâches.

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éesCINC. 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.

/var/log/clustermgtd.log

Il s'agit du clustermgtd journal de Slurm planificateurs. clustermgtdfonctionne 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 de SGE and Torque planificateurs. jobwatchersurveille 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 de SGE and Torque planificateurs. sqswatchertraite 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. nodewatcherdémons qui s'exécutent sur chaque nœud de calcul lors de l'utilisation SGE and Torque 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.

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 AWS ParallelCluster la version v2.9.0 ou ultérieure, utilisez Slurm, et pour éviter ce problème, vous devez effectuer une mise à niveau et passer à un cluster compatible avec le mode de files d'attente multiples. Vous pouvez le faire en courantpcluster-config convert.

Pour les clusters à très grande échelle, 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 paramètre sur DYNAMIC et définissez le placement paramètre surcompute.

Si vous avez besoin d'un système de fichiers partagé performant, pensez à l'utiliser FSxpour 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 paramètre a la même valeur que le master_instance_type paramètre, le placement paramètre est défini sur et le compute_subnet_id paramètre n'est pas spécifié. cluster Avec cette configuration, la valeur du 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 liés au lancement des instances et Groupes de placement, rôles et limites dans le Guide de EC2 l'utilisateur Amazon

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_usersur Amazon Linux, /home/centos sur CentOS, et ainsi de /home/ubuntu suite Ubuntu).

/opt/intel

Cela inclut IntelMPI, Intel Parallel Studio et les fichiers connexes.

/opt/sge
Note

À partir de la version 2.11.5, AWS ParallelCluster ne prend pas en charge l'utilisation de SGE or Torque planificateurs.

Cela inclut Son of Grid Engine et les fichiers associés. (Conditionnel, seulement si scheduler = sge.)

/opt/slurm

Cela inclut Slurm Workload Manager et les fichiers associés. (Conditionnel, seulement si scheduler = slurm.)

/opt/torque
Note

À partir de la version 2.11.5, AWS ParallelCluster ne prend pas en charge l'utilisation de SGE or Torque planificateurs.

Cela inclut Torque Resource Manager et les fichiers associés. (Conditionnel, seulement si scheduler = torque.)

Résolution des problèmes sur Amazon DCV

Logs 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'DCVinstance Amazon

Le type d'instance doit avoir au moins 1,7 Gibioctet (GiB) pour RAM exécuter Amazon. DCV Nano and micro les types d'instance ne disposent pas de suffisamment de mémoire pour exécuter AmazonDCV.

DCVProblèmes liés à Ubuntu Amazon

Lorsque vous exécutez Gnome Terminal sur une DCV session sur Ubuntu, il se peut que vous n'ayez pas automatiquement accès à l'environnement utilisateur mis à AWS ParallelCluster disposition 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.

    2. Sélectionnez Préférences, puis Profils.

    3. Choisissez Command, puis sélectionnez Exécuter la commande en tant que shell de connexion.

    4. 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.

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 faisable, 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. 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 pour obtenir de l'aide.

Échecs au travail

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 vous voyez le message d'état affiché dans la réponse de commande précédente, vous devez utiliser des types d'instance qui ne dépasseront pas votre CPU limite de v actuelle ou ne demanderont pas de CPU capacité v supplémentaire.

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.

  2. Sélectionnez la pile nommée parallelcluster-cluster_name.

  3. Choisissez l'onglet Événements.

  4. 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é.

  5. 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 IAM politiques

Référez-vous aux IAM AWS STS quotas, aux exigences relatives aux noms et aux limites de caractères 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 IAM rôle, 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 ou la page des problèmes. Pour les problèmes plus urgents, contactez Support ou ouvrez un nouveau GitHub numéro.