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 AWS PIÈCES

Lorsque les nœuds de calcul ne parviennent pas à démarrer ou à s'enregistrer 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 d'amorçage 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 d'amorçage du nœud AWS PCS. Pour plus d'informations sur la résolution des problèmes liés au lancement d'une instance EC2, consultez Résoudre les problèmes liés au lancement d'une instance Amazon EC2 dans le guide de l'utilisateur Amazon Elastic Compute Cloud.

Les échecs d'amorçage 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 AWS PIÈCES

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

Traitement des tâches Slurm standard

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

Traitement des tâches Slurm sur AWS PIÈCES

Le traitement des tâches AWS PCS comporte les étapes suivantes :

Récupérer les journaux d'instance

La première étape pour résoudre les problèmes d'amorçage des nœuds de calcul 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

us-east-1Remplacez-le 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 d'amorçage :

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

2. Consultez le fichier journal d'amorçage :

   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. Les services Systems Manager et 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.

Extraire 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 les ID de votre instance, consultezRecherche d'instances de groupes de nœuds de calcul dans AWS PCS.

Console de gestion AWS

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. Recherchez l'ID VPC et l'ID de sous-réseau dans le résumé de l'instance affiché.

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 des nœuds 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 de 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 peut pas s'enregistrer en raison d'un profil d'instance incorrect, l'erreur suivante 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 est pcs:RegisterComputeNodeGroupInstance autorisé. Pour plus d'informations sur la création d'un profil d'instance valide, consultezCréez un profil d'instance pour AWS PIÈCES.

Impossible de se connecter à AWS Points de terminaison PCS

Si vos nœuds de calcul se trouvent dans un sous-réseau privé, assurez-vous d'avoir configuré des points de terminaison VPC pour PCS. AWS Vous pouvez également vous assurer que votre sous-réseau possède une route vers une passerelle NAT pour accéder à Internet. Par défaut, l'agent AWS PCS utilise le point de terminaison non FIPS à double pile. pcs.region.api.aws Si vous utilisez un DNS personnalisé, assurez-vous qu'il peut être résolu pcs.region.api.aws jusqu'au point de terminaison. Pour plus d’informations, consultez les ressources suivantes :

Mal configuré AWS terminal PCS

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

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 de l'interface VPC pour AWS PCS, consultez. Accès AWS Parallel Computing Service en utilisant 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 pour votre sous-réseau et que la configuration de votre itinéraire 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 disposer d'une adresse IP publique. Pour résoudre ce problème, choisissez l'une des options suivantes :

Multi-NIC instance 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 (NIC).

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 adresse IPv4 publique lors du lancement de l'instance dans le Guide de l'utilisateur Amazon EC2 pour les instances Linux.

Multi-NIC les types d'instance 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.

Le secret du cluster a été supprimé ou marqué pour suppression

Si le secret partagé Slurm dans AWS Secrets Manager a été supprimé ou marqué pour suppression, les nœuds de calcul ne pourront pas s'enregistrer et votre cluster sera endommagé.

AWS PCS crée automatiquement un secret partagé Slurm dans AWS Secrets Manager (avec le format de nom :pcs!slurm-secret-<cluster-id>) lorsque vous créez un cluster. Ce secret est requis pour sécuriser les communications dans le cluster. Pour de plus amples informations, veuillez consulter Utilisation des secrets de cluster dans AWS PIÈCES.

Si ce secret est supprimé ou marqué pour suppression, les nouveaux nœuds ne pourront pas rejoindre le cluster et le contrôleur ou d'autres démons du cluster (tels que slurmd etslurmdbd) pourraient ne pas être en mesure de rejoindre le cluster en cas de redémarrage.

Pour résoudre ce problème, vous pouvez restaurer le secret supprimé s'il se trouve toujours dans la fenêtre de restauration. Pour obtenir des instructions détaillées, voir Restaurer un secret de AWS Secrets Manager.

Si la fenêtre de restauration expire, le secret ne peut pas être restauré et le cluster AWS PCS concerné ne peut pas être restauré. Vous devez créer un nouveau cluster avec la même configuration. AWS PCS crée automatiquement un nouveau secret de planificateur.

Problèmes de connexion 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 ne soient pas disponibles :

<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 que vous 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.

ResumeTimeout atteint

Si un nœud de calcul et son instance EC2 sont interrompus parce que le nœud est défectueux, il se peut 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), vérifiez que les journaux de votre instance ne contiennent pas de 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 d'amorçage 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 d'amorçage AWS PCS. Pour de plus amples informations, veuillez consulter Images Amazon Machine personnalisées (AMIs) pour AWS PC.

Slurmctld ne parvient pas à envoyer une requête ping au nœud de calcul

Si l'instance exécute correctement la procédure d'amorçage et est enregistrée auprès de AWS PCS, mais qu'elle slurmctld est incapable de la voir et de lui soumettre des tâches, l'instance est configurée sur « DOWN Après un certain temps », puis arrêté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é.