Résolution des problèmes de dimensionnement

• /var/log/cfn-init.log- C'est le journal 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- Il s'agit du journal du client Chef. Il contient toutes les commandes qui ont été exécutées 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 de nœuds dynamiques.

• /var/log/parallelcluster/slurm_suspend.log- Voici le SuspendProgram journal. Il est appelé lorsque les instances sont terminées pour les 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 consulter le clustermgtd journal.

• /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 opérationnelles du cluster. Utilisez-le 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 dimensionnement. 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 aux tâches et tout problème de lancement et de résiliation lié au planificateur.

• /var/log/parallelcluster/compute_console_output- Ce journal enregistre la sortie de console d'un sous-ensemble d'exemples de nœuds de calcul statiques qui se sont arrêtés de manière 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.

• /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. 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 rare où le clustermgtd démon du nœud principal serait hors ligne. Utilisez-le pour résoudre les problèmes de résiliation imprévus.

• /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 panne de calcul.

Selon votre cas d'utilisation, envisagez d'utiliser l'une des méthodes suivantes pour éviter de recevoir ce type de messages d'erreur :

• Désactivez le groupe de placement s'il est activé. Pour de plus amples informations, veuillez consulter Groupes de placement et problèmes de lancement d'instance.

• Réservez de la capacité pour les instances et lancez-les avec ODCR (On-Demand Capacity Reservations). Pour de plus amples informations, veuillez consulter Instances de lancement avec réservations On-Demand de capacité (ODCR).

• Configurez plusieurs ressources de calcul avec différents types d'instances. Si votre charge de travail ne nécessite pas un type d'instance spécifique, vous pouvez tirer parti d'un basculement rapide en cas d'insuffisance de capacité en utilisant plusieurs ressources de calcul. Pour de plus amples informations, veuillez consulter Slurmbasculement rapide d'une 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.

• /var/log/cfn-init.log

• /var/log/chef-client.log

• /var/log/parallelcluster/clustermgtd

• /var/log/parallelcluster/slurm_resume.log

• /var/log/slurmctld.log

• 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 des journaux de configuration similaires à ceux du nœud principal. /var/log/chef-client.log La plupart des erreurs qui se produisent lors de l'installation doivent comporter 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 se sont correctement exécutés.

• Si vous utilisez une AMI personnalisée dont la Slurm configuration est modifiée, il se peut qu'une Slurm erreur associée empêche le nœud de calcul de rejoindre le cluster. Pour les erreurs liées au planificateur, consultez le journal. /var/log/slurmd.log

• Recherchez le nom de votre nœud de calcul dans le ResumeProgram journal (/var/log/parallelcluster/slurm_resume.log) pour voir s'il ResumeProgram a déjà été appelé avec ce 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é d'appeler ResumeProgram avec le nœud).

• Notez que des autorisations incorrectes 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 possède l'autorisation 744 (rwxr--r--).

• S'ResumeProgramil est appelé, vérifiez si une instance est lancée pour le nœud. Si aucune instance n'a été lancée, vous pouvez voir un message d'erreur décrivant l'échec du lancement.

• Si l'instance est lancée, il se peut qu'un problème soit survenu lors du processus de configuration. L'adresse IP privée et l'ID d'instance correspondants devraient apparaître dans le ResumeProgram journal. De plus, vous pouvez consulter les journaux de configuration correspondants pour l'instance spécifique. Pour plus d'informations sur la résolution d'une erreur de configuration avec un nœud de calcul, consultez la section suivante.

• 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 détaillant l'échec du lancement devrait apparaître.

• Si l'instance est lancée, un problème survient lors du processus de configuration. L'adresse IP privée et l'ID d'instance correspondants devraient apparaître dans le ResumeProgram journal. De plus, vous pouvez consulter les journaux de configuration correspondants pour l'instance spécifique.

• Si c'est la première fois que vous utilisez Spot Instances et que la tâche reste dans un 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é à un 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 Utilisation de instances Spot le Guide de l' AWS ParallelCluster utilisateur et le Service-linked rôle des demandes d'instance Spot dans le Guide de l'utilisateur Amazon EC2.

• Journaux applicables :

  • /var/log/parallelcluster/clustermgtd(nœud principal)

  • /var/log/slurmctld.log(nœud principal)

  • /var/log/parallelcluster/computemgtd(nœud de calcul)

• Consultez le clustermgtd journal (/var/log/parallelcluster/clustermgtd) pour voir si un nœud a été clustermgtd remplacé ou supprimé. Notez qu'il clustermgtd gère toutes les actions de maintenance normales des nœuds.

• En cas de clustermgtd remplacement ou d'arrêt du nœud, un message doit apparaître pour expliquer pourquoi cette action a été effectuée sur le nœud. Si la raison est liée au planificateur (par exemple, parce que le nœud est activéDOWN), consultez le slurmctld journal pour plus d'informations. Si la raison est liée à Amazon EC2, un message d'information détaillant le problème lié à Amazon EC2 nécessitant le remplacement devrait apparaître.

• Si vous clustermgtd n'avez pas résilié le nœud, vérifiez d'abord s'il s'agissait d'une résiliation prévue par Amazon EC2, plus précisément d'une résiliation ponctuelle. computemgtd, qui s'exécute sur un nœud de calcul, peut également mettre fin à un nœud s'il clustermgtd est déterminé comme étant défectueux. Vérifiez computemgtd log (/var/log/parallelcluster/computemgtd) pour voir si le computemgtd nœud a été arrêté.

• 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 slurm_resume 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, il est possible que le nœud échoue 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 tâche pour Slurm faire démarrer 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 fermé.

    $ 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 la parallelcluster:cluster-name balise.

    $ 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

• 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 terminaison 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 de défaillance d'un nœud dynamiqueSlurmSettingsPropriétés, consultez le SuspendProgram journal pour voir s'il SuspendProgram a été appelé par slurmctld avec le nœud en question comme argument. Notez qu'SuspendProgramil n'effectue aucune action. Au contraire, il ne se connecte que lorsqu'il est appelé. L'arrêt et la NodeAddr réinitialisation de toutes les instances sont effectués parclustermgtd. Slurmremet SuspendTimeout automatiquement les nœuds dans leur POWER_SAVING état d'origine.

• 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 activé. 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 d'amorçage.