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.

Résoudre les problèmes d'amorçage et d'enregistrement des nœuds de calcul dans les PCS AWS

Lorsque les nœuds de calcul ne démarrent pas ou ne s'enregistrent pas correctement auprès de votre cluster AWS PCS, vous pouvez rencontrer les symptômes suivants :

Ces défaillances peuvent être causées par des problèmes lors du lancement de l'instance EC2 ou lors du processus de démarrage du nœud de calcul AWS PCS. Cette rubrique décrit les procédures destinées à vous aider à résoudre les problèmes lors du processus de démarrage du nœud AWS PCS. Pour plus d'informations sur la résolution des problèmes de lancement d'instance EC2, consultez la section Résolution des problèmes de lancement d'instance Amazon EC2 dans le guide de l'utilisateur d'Amazon Elastic Compute Cloud.

Les échecs de Bootstrap se produisent lorsqu'une instance EC2 est lancée avec succès mais échoue pendant le processus d'adhésion au cluster AWS PCS. Le processus de bootstrap comprend deux phases principales :

Comment fonctionne Slurm sur PC AWS

Cela peut vous aider à comparer le mode de fonctionnement standard de Slurm à celui de Slurm sur PC. AWS

Traitement standard des tâches avec Slurm

Les étapes suivantes se produisent dans le cadre du traitement standard des tâches Slurm :

Traitement des tâches Slurm sur PCS AWS

Les étapes suivantes se produisent dans le cadre du traitement des tâches AWS PCS :

Récupérez les journaux d'instance

Pour résoudre les problèmes d'amorçage des nœuds de calcul, la première étape consiste à récupérer les journaux de l'instance. Vous pouvez choisir l’une des méthodes suivantes :

AWS CLI

Récupérez la sortie de console depuis le nœud de calcul à l'aide de la commande suivante :

aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text

Remplacez us-east-1 par votre AWS région et i-1234567890abcdef0 par l'ID de votre instance.

AWS Systems Manager

Si vous pouvez vous connecter à l'instance à l'aide de Systems Manager, vous pouvez consulter directement le fichier journal du bootstrap :

1. Connectez-vous à l'instance à l'aide de Systems Manager. Pour plus d'informations, reportez-vous à la section Démarrage d'une session dans le Guide de l'utilisateur de Systems Manager.

2. Consultez le fichier journal du bootstrap :

   sudo cat /var/log/amazon/pcs/bootstrap.log

Note

En cas de problème pendant la phase d'initialisation, vous devrez peut-être attendre environ 20 minutes avant de pouvoir vous connecter à l'instance. Systems Manager et les services SSH ne démarrent qu'une fois l'initialisation terminée ou lorsque l'exécution du bootstrap atteint un délai d'expiration en cas d'échec.

Récupérer VPC/Subnet/Security des groupes à partir d'un ID d'instance

Pour résoudre les problèmes liés à vos nœuds de calcul, vous devrez peut-être récupérer des informations sur le VPC, le sous-réseau et les groupes de sécurité associés à vos instances. Si vous ne connaissez pas votre instance IDs, consultezRecherche d'instances de groupes de nœuds de calcul dans AWS PCS.

AWS Management Console

Pour obtenir un VPC, un sous-réseau et des groupes de sécurité

1. Ouvrez la console Amazon EC2.

2. Choisissez Instances.

3. Dans le tableau Instances, choisissez l'ID de l'instance.

4. Trouvez l'ID VPC et l'ID de sous-réseau dans le résumé de l'instance affiché pour l'instance.

5. Dans le résumé de l'instance, choisissez l'onglet Sécurité.

6. Trouvez les groupes de sécurité dans l'onglet Sécurité.

AWS CLI

Utilisez la commande suivante pour récupérer les informations relatives au VPC, au sous-réseau et au groupe de sécurité pour votre instance :

aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,VpcId:VpcId,SubnetId:SubnetId,SecurityGroups:SecurityGroups[*].GroupId}' --output table

Problèmes d'enregistrement des nœuds

L'enregistrement d'un nœud est la première action exécutée par un nœud de calcul pendant le bootstrap. Le nœud appelle le point de terminaison de l'API AWS PCS pour s'enregistrer auprès du AWS PCS. Les échecs d'enregistrement affichent généralement des messages d'erreur similaires aux suivants :

<13>Nov 13 16:23:50 user-data: [2025-11-13T16:23:50.510+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registering node to cluster <clusterId>
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.193+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is [specific error message]
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.194+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retrying in 31 seconds...
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
...
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.195+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registration timeout (600 seconds) reached. Exiting.
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.200+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: ERROR: Error: (2) occurred on line 1 when running /opt/aws/pcs/bin/pcs_bootstrap_init.sh. Shutting down instance.

Mauvais profil d'instance

Si le nœud ne parvient pas à s'enregistrer en raison d'un mauvais profil d'instance, le message d'erreur suivant s'affichera :

<13>Nov 13 18:43:08 user-data: [2025-11-13T18:43:08.268+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is {
<13>Nov 13 18:43:08 user-data:   "__type": "com.amazon.coral.service#AccessDeniedException",
<13>Nov 13 18:43:08 user-data:   "Message": "User: arn:aws:sts::<accountId>:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access",
<13>Nov 13 18:43:08 user-data:   "nodeID": null
<13>Nov 13 18:43:08 user-data: }

Vérifiez que le profil d'instance associé au nœud de calcul dispose de l'pcs:RegisterComputeNodeGroupInstanceautorisation. Pour plus d'informations sur la création d'un profil d'instance valide, consultezCréation d'un profil d'instance pour AWS PCS.

Impossible de se connecter aux points de terminaison AWS PCS

Si vos nœuds de calcul se trouvent dans un sous-réseau privé, assurez-vous que vous avez configuré des points de terminaison VPC AWS pour les PC ou que votre sous-réseau dispose d'une route vers une passerelle NAT pour accéder à Internet. Pour plus d’informations, consultez les ressources suivantes :

Point de terminaison AWS PCS mal configuré

Si un message d'erreur similaire au suivant s'affiche, vérifiez la politique associée à votre point de terminaison AWS VPC PCS :

com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access

Pour plus d'informations sur la configuration des points de terminaison d'interface VPC pour AWS PCS, consultez. Accès AWS Parallel Computing Service via un point de terminaison d'interface (AWS PrivateLink)

Instance dans un sous-réseau public sans adresse IP publique

Si l'attribution automatique d'adresses IP publiques n'est pas activée dans votre sous-réseau et que la configuration de votre route utilise une passerelle Internet, les instances ne peuvent pas communiquer avec l'API AWS PCS.

Les instances d'un sous-réseau doté d'une passerelle Internet doivent avoir une adresse IP publique. Pour résoudre ce problème, choisissez l'une des options suivantes :

Instance multi-NIC dans un sous-réseau public

Vous devez utiliser un sous-réseau privé si vous utilisez un type d'instance doté de plusieurs interfaces réseau (NICs).

AWS les adresses IP publiques ne peuvent être attribuées qu'aux instances lancées avec une seule interface réseau. Pour plus d'informations sur les adresses IP, consultez la section Attribuer une IPv4 adresse publique lors du lancement de l'instance dans le Guide de l'utilisateur Amazon EC2 pour les instances Linux.

Les types d'instances multi-NIC nécessitent une passerelle NAT ou un proxy interne dans le sous-réseau pour accéder au point de terminaison AWS PCS. Vous pouvez également ajouter un point de terminaison VPC pour AWS PCS à votre VPC de cluster.

Problèmes de jointure au cluster Slurm

Une fois l'enregistrement du nœud réussi, le nœud de calcul tente de rejoindre le cluster Slurm. Le slurmd démon du nœud contacte le contrôleur Slurm pour s'enregistrer auprès du cluster. Les échecs de jointure Slurm affichent généralement des messages d'erreur similaires aux suivants :

<13>Nov  5 17:20:29 user-data: [2024-11-05T17:20:28+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[slurmd] (aws-pcs-slurm::finalize_slurm line 18) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'  
<13>Nov  5 17:20:29 user-data: ---- Begin output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----  
<13>Nov  5 17:20:29 user-data: STDOUT:   
<13>Nov  5 17:20:29 user-data: STDERR: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Nov  5 17:20:29 user-data: ---- End output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----

Configuration du groupe de sécurité

Vérifiez que vos groupes de sécurité sont correctement configurés pour permettre la communication entre les nœuds de calcul et le contrôleur Slurm. Les groupes de sécurité doivent autoriser le trafic suivant :

Pour plus d'informations sur les exigences relatives aux groupes de sécurité, consultez les rubriques suivantes :

Pilotes NVIDIA manquants

Si l'instance démarre correctement mais que les tâches ne démarrent pas et que des messages d'erreur similaires aux suivants s'affichent dans les journaux de votre instance, il se peut que des pilotes NVIDIA soient manquants :

<13>Dec  2 13:52:00 user-data: [2024-12-02T13:52:00.094+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_config_always.sh: INFO: nvidia-smi not found!  
...  
<13>Dec  2 13:54:10 user-data: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Dec  2 13:54:12 user-data: [2024-12-02T13:54:12.718+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_finalize.sh: INFO: systemctl could not start slurmd!

Si vous vous connectez à l'instance et vérifiez l'état du slurmd démon, une erreur similaire à la suivante peut s'afficher :

$ systemctl status slurmd  
...  
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory

Pour résoudre ce problème, installez les pilotes NVIDIA sur votre AMI personnalisée. Pour de plus amples informations, veuillez consulter Étape 4 — (Facultatif) Installation de pilotes, de bibliothèques et de logiciels d'application supplémentaires.

ResumeTimeoutatteint

Si un nœud de calcul et son instance EC2 sont interrompus en raison d'un dysfonctionnement du nœud, il est possible que le AWS PCS ne prenne pas en charge l'AMI ou qu'il y ait des problèmes de réseau. L'instance EC2 s'exécute pendant environ 30 minutes jusqu'à ce que Slurm ResumeTimeout soit atteint et marque le nœud comme. DOWN

Si l'instance ne démarre pas correctement et n'est pas enregistrée auprès de AWS PCS (aucun RegisterComputeNodeGroupInstance appel pour l'instance EC2), consultez les journaux de votre instance pour détecter les messages d'erreur similaires aux suivants :

/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory

Cette erreur indique que le logiciel de démarrage du AWS PCS ne fait pas partie de l'AMI. Pour résoudre ce problème, assurez-vous que votre AMI personnalisée inclut le logiciel de démarrage AWS PCS. Pour de plus amples informations, veuillez consulter Images Amazon Machine personnalisées (AMIs) pour AWS PC.

Slurmctld ne parvient pas à envoyer un ping au nœud de calcul

Si l'instance exécute correctement la procédure d'amorçage et qu'elle est enregistrée auprès de AWS PCS, mais qu'elle n'slurmctldest pas en mesure de la voir et de lui soumettre des tâches, l'instance est définie sur DOWN après un certain temps, puis résiliée.

Cela peut être dû à des groupes de sécurité mal configurés. Par exemple, si le port 6817 est activé pour permettre de slurmd communiquer avecslurmctld, mais que le port 6818 est absent slurmctld pour autoriser le ping. slurmd

Vérifiez que vos groupes de sécurité incluent toutes les règles requises, comme indiqué dansExigences et considérations relatives aux groupes de sécurité.