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 tâches Slurm. Pour plus d'informations sur la configuration de plusieurs files d'attente, consultezConfiguration de plusieurs files d'attente.

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 commande et en filtrant à l'private-dns-nameaide 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 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 avec Amazon CloudWatch Logs avec Amazon Logs et Tableau de CloudWatch bord Amazon.

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 AWS CloudFormation d'initialisation. Il contient toutes les commandes qui ont été 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- Ceci est 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- C'est 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- C'est 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 contrôle Slurm. AWS ParallelCluster ne prend pas de décisions de mise à l'échelle. Au contraire, il tente uniquement de lancer des ressources pour satisfaire aux exigences du Slurm. 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 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. Il contient toutes les commandes qui ont été exécutées lors de la configuration d'une instance. Utilisez-le pour résoudre les problèmes d'initialisation.

• /var/log/parallelcluster/computemgtd- C'est 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 calcul de Slurm. 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 plus d’informations, consultez Problèmes liés aux groupes de placement et au lancement d'instances.

• Réservez de la capacité pour les instances et lancez-les avec ODCR (On-Demand Capacity Reservations). Pour plus d’informations, consultez Lancez les instances à la demande (Réservations de capacité à la demande).

• 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 plus d’informations, consultez Slurmbasculement rapide de la capacité insuffisante du cluster.

• 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 et 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/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//SlurmQueuesNetworking/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.

Rubriques

• Nœud principal
• Nœuds de calcul

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. (S'il ResumeProgram n'a jamais été appelé, vous pouvez consulter le slurmctld journal (/var/log/slurmctld.log) pour déterminer si Slurm a 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'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 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 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 de l' AWS ParallelCluster utilisateur et le rôle lié au service pour les demandes d'instance Spot 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 dedansDOWN), 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 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 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-1234567890abcdef0 --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-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 dynamiqueSlurmSettingsPropriétés, 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 automatiquement les nœuds dans leur POWER_SAVING état initial. SuspendTimeout

• Si les nœuds de calcul échouent continuellement en raison d'échecs d'amorçage, vérifiez s'ils sont lancés avec Slurmmode protégé du cluster 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 Slurmmode protégé du cluster 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, les ressources sont AWS ParallelCluster uniquement lancées, résiliées ou maintenues conformément aux instructions de Slurm. Pour ces problèmes, consultez le slurmctld journal pour les résoudre.