View a markdown version of this page

Risolvi i problemi relativi al bootstrap e alla registrazione dei nodi di calcolo in PCS AWS - AWS PC
Come funziona Slurm su PCS AWSRecupera i log delle istanzeRecupera gruppi da VPC/Subnet/Security un ID di istanzaProblemi di registrazione dei nodiProblemi di unione del cluster Slurm

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risolvi i problemi relativi al bootstrap e alla registrazione dei nodi di calcolo in PCS AWS

Quando i nodi di elaborazione non riescono ad avviarsi o a registrarsi correttamente nel cluster AWS PCS, potrebbero verificarsi i seguenti sintomi:

  • I lavori non iniziano

  • Non puoi connetterti alle istanze in AWS Systems Manager

  • Le istanze si sono chiuse in modo imprevisto

  • Le istanze vengono sostituite continuamente

Questi errori possono essere causati da problemi durante l'avvio dell'istanza EC2 o durante il processo di bootstrap del nodo di calcolo AWS PCS. Questo argomento descrive le procedure per aiutarti a risolvere i problemi durante il processo di bootstrap del nodo PCS. AWS Per ulteriori informazioni sulla risoluzione dei problemi di avvio delle istanze EC2, consulta Risoluzione dei problemi di avvio delle istanze Amazon EC2 nella Amazon Elastic Compute Cloud User Guide.

Gli errori di bootstrap si verificano quando un'istanza EC2 viene avviata correttamente, ma fallisce durante il processo di adesione al cluster PCS. AWS Il processo di bootstrap include due fasi principali:

Come funziona Slurm su PCS AWS

Potrebbe aiutarti a confrontare il modo standard di funzionamento di Slurm con il modo in cui Slurm funziona su PCS. AWS

Elaborazione standard dei lavori Slurm

Nell'elaborazione standard dei job Slurm si verificano i seguenti passaggi:

  1. Quando invii un lavoro, lo slurmctld convalida e lo mette in coda.

  2. Quando le risorse diventano disponibili, slurmctld alloca i nodi esistenti.

  3. slurmdi demoni eseguono i job sui nodi allocati.

Elaborazione dei job Slurm su PCS AWS

Nell'elaborazione dei lavori AWS PCS si verificano i seguenti passaggi:

  1. Quando invii un lavoro, slurmctld lo convalida e lo mette in coda.

  2. Quando è necessaria una capacità aggiuntiva, AWS PCS utilizza il modello di avvio per il gruppo di nodi di calcolo per lanciare nuove istanze EC2.

  3. Le nuove istanze vengono avviate nel cluster:

    1. Le istanze vengono registrate con PCS. AWS

    2. Le istanze si uniscono al cluster Slurm.

  4. Quando le risorse sono pronte, slurmctld alloca i nodi (compresi quelli appena avviati).

  5. slurmdi demoni eseguono i job sui nodi allocati.

Recupera i log delle istanze

Il primo passo per risolvere i problemi di bootstrap dei nodi di calcolo consiste nel recuperare i log delle istanze. È possibile utilizzare uno dei seguenti metodi:

AWS CLI

Recupera l'output della console dal nodo di calcolo utilizzando il seguente comando:

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

us-east-1Sostituiscilo con la tua AWS regione e i-1234567890abcdef0 con l'ID dell'istanza.

AWS Systems Manager

Se è possibile connettersi all'istanza utilizzando Systems Manager, è possibile visualizzare direttamente il file di registro di bootstrap:

  1. Connect all'istanza utilizzando Systems Manager. Per ulteriori informazioni, vedere Avvio di una sessione nella Guida per l'utente di Systems Manager.

  2. Visualizza il file di registro di bootstrap:

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

Se si verifica un problema durante la fase di inizializzazione, potrebbe essere necessario attendere circa 20 minuti prima di poterti connettere all'istanza. I servizi Systems Manager e SSH si avviano solo dopo il completamento dell'inizializzazione o quando l'esecuzione del bootstrap raggiunge un timeout in caso di errore.

Recupera gruppi da VPC/Subnet/Security un ID di istanza

Per risolvere i problemi con i nodi di elaborazione, potrebbe essere necessario recuperare informazioni sul VPC, sulla sottorete e sui gruppi di sicurezza associati alle istanze. Se non conosci la tua istanza, consulta. IDs Ricerca di istanze di gruppi di nodi di calcolo in PCS AWS

Console di gestione AWS
Per ottenere VPC, sottorete e gruppi di sicurezza

  1. Aprire la console di Amazon EC2.

  2. Seleziona Instances (Istanze).

  3. Nella tabella Istanze, scegli l'ID dell'istanza.

  4. Trova l'ID VPC e l'ID di sottorete nel riepilogo dell'istanza visualizzato per l'istanza.

  5. Nel riepilogo dell'istanza, scegli la scheda Sicurezza.

  6. Trova i gruppi di sicurezza nella scheda Sicurezza.

AWS CLI

Usa il comando seguente per recuperare le informazioni su VPC, sottorete e gruppo di sicurezza per la tua istanza:

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

Problemi di registrazione dei nodi

La registrazione dei nodi è la prima azione eseguita da un nodo di calcolo durante il bootstrap. Il nodo chiama l'endpoint dell'API AWS PCS per registrarsi con PCS. AWS Gli errori di registrazione in genere mostrano messaggi di errore simili ai seguenti:

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

Profilo di istanza errato

Se il nodo non è in grado di registrarsi a causa di un profilo di istanza errato, verrà visualizzato il seguente errore:

<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: }

Verifica che il profilo di istanza associato al nodo di calcolo disponga dell'pcs:RegisterComputeNodeGroupInstanceautorizzazione. Per ulteriori informazioni su come creare un profilo di istanza valido, consultaCreare un profilo di istanza per AWS PCS.

Impossibile connettersi agli endpoint AWS PCS

Se i nodi di elaborazione si trovano in una sottorete privata, assicurati di aver configurato gli endpoint VPC per AWS PCS o che la sottorete abbia un percorso verso un gateway NAT per l'accesso a Internet. Per ulteriori informazioni, consulta gli argomenti seguenti:

Endpoint PCS non configurato correttamente AWS

Se viene visualizzato un messaggio di errore simile al seguente, verifica la policy associata all'endpoint 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

Per ulteriori informazioni su come configurare gli endpoint dell'interfaccia VPC per AWS PCS, vedere. Accesso AWS Parallel Computing Service tramite un'interfaccia endpoint ()AWS PrivateLink

Istanza in una sottorete pubblica senza IP pubblico

Se nella sottorete non è abilitata l'assegnazione automatica dell'IP pubblico e la configurazione del percorso utilizza un gateway Internet, le istanze non possono comunicare con l'API PCS. AWS

Le istanze in una sottorete con un gateway Internet devono avere un indirizzo IP pubblico. Per risolvere questo problema, scegli una delle seguenti opzioni:

  • Aggiungi un endpoint VPC per AWS PCS al tuo VPC del cluster. Ciò consente alle istanze di comunicare con AWS PCS senza la necessità che un indirizzo IP pubblico passi attraverso il gateway Internet.

  • Utilizza una sottorete privata con un gateway NAT, in modo che non sia richiesto un indirizzo IP pubblico.

  • Abilita l'assegnazione automatica degli indirizzi IP pubblici tramite la sottorete o il modello di avvio in modo che le istanze possano contattare l'API tramite il gateway Internet. Tieni presente che questa opzione non è valida per le istanze di interfaccia multi-rete.

Istanza multi-NIC in una sottorete pubblica

È necessario utilizzare una sottorete privata se si utilizza un tipo di istanza con più interfacce di rete (). NICs

AWS gli indirizzi IP pubblici possono essere assegnati solo alle istanze avviate con un'unica interfaccia di rete. Per ulteriori informazioni sugli indirizzi IP, consulta Assegnare un IPv4 indirizzo pubblico durante il lancio dell'istanza nella Amazon EC2 User Guide for Linux Instances.

I tipi di istanze multi-NIC richiedono un gateway NAT o un proxy interno nella sottorete per accedere all'endpoint PCS. AWS In alternativa, puoi aggiungere un endpoint VPC per AWS PCS al tuo VPC del cluster.

Il segreto del cluster è stato eliminato o contrassegnato per l'eliminazione

Se il segreto condiviso di Slurm in AWS Secrets Manager è stato eliminato o contrassegnato per l'eliminazione, i nodi di calcolo non riusciranno a registrarsi e il cluster verrà danneggiato.

AWS PCS crea automaticamente un segreto condiviso Slurm in AWS Secrets Manager (con il formato del nome:pcs!slurm-secret-<cluster-id>) quando si crea un cluster. Questo segreto è necessario per comunicazioni sicure nel cluster. Per ulteriori informazioni, consulta Utilizzo dei segreti del cluster in AWS PCS.

Se questo segreto viene eliminato o contrassegnato per l'eliminazione, i nuovi nodi non potranno entrare a far parte del cluster e il controller o altri demoni del cluster (come slurmd andslurmdbd) potrebbero non essere in grado di ricongiungersi al cluster se riavviato.

Per risolvere questo problema, puoi ripristinare il segreto eliminato se è ancora all'interno della finestra di ripristino. Per istruzioni dettagliate, consulta Restore an AWS Secrets Manager secret.

Se la finestra di ripristino scade, il segreto non può essere ripristinato e il cluster AWS PCS interessato non può essere ripristinato. È necessario creare un nuovo cluster con la stessa configurazione. AWS PCS crea automaticamente un nuovo segreto dello scheduler.

Problemi di unione del cluster Slurm

Dopo una corretta registrazione del nodo, il nodo di calcolo tenta di unirsi al cluster Slurm. Il slurmd demone sul nodo contatta il controller Slurm per registrarsi nel cluster. Gli errori di Slurm join di solito mostrano messaggi di errore simili ai seguenti:

<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"] ----

Configurazione del gruppo di sicurezza

Verifica che i tuoi gruppi di sicurezza siano configurati correttamente per consentire la comunicazione tra i nodi di calcolo e il controller Slurm. I gruppi di sicurezza devono consentire il seguente traffico:

  • Porta 6817 con slurmd cui comunicare slurmctld

  • Porta 6818 per eseguire il ping slurmctld slurmd

Per ulteriori informazioni sui requisiti dei gruppi di sicurezza, consulta i seguenti argomenti:

Importante

Il gruppo di sicurezza del cluster associato al cluster durante la creazione del cluster deve essere configurato anche nei gruppi di sicurezza del gruppo di nodi di calcolo per consentire ai nodi di elaborazione di comunicare con il controller.

Driver NVIDIA mancanti

Se l'istanza si avvia correttamente ma i processi non vengono avviati e nei log dell'istanza vengono visualizzati messaggi di errore simili ai seguenti, è possibile che manchino i driver NVIDIA:

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

Se ti connetti all'istanza e controlli lo stato del slurmd daemon, potresti visualizzare un errore simile al seguente:

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

Per risolvere questo problema, installa i driver NVIDIA sulla tua AMI personalizzata. Per ulteriori informazioni, consulta Fase 4 — (Facoltativo) Installare driver, librerie e software applicativi aggiuntivi.

ResumeTimeout raggiunto

Se un nodo di calcolo e la relativa istanza EC2 vengono terminati perché il nodo non è integro, AWS PCS potrebbe non supportare l'AMI o potrebbero esserci problemi di rete. L'istanza EC2 viene eseguita per circa 30 minuti fino a raggiungere quella ResumeTimeout di Slurm e contrassegna il nodo come. DOWN

Se l'istanza non si avvia correttamente e non è registrata con AWS PCS (nessuna RegisterComputeNodeGroupInstance chiamata per l'istanza EC2), controlla i log dell'istanza per verificare la presenza di messaggi di errore simili ai seguenti:

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

Questo errore indica che il software di bootstrap AWS PCS non fa parte dell'AMI. Per risolvere questo problema, assicurati che l'AMI personalizzata includa il software di bootstrap AWS PCS. Per ulteriori informazioni, consulta Immagini di macchine Amazon personalizzate (AMIs) per AWS PCS.

Slurmctld non è in grado di eseguire il ping del nodo di calcolo

Se l'istanza esegue correttamente la procedura di bootstrap ed è registrata con AWS PCS, ma non slurmctld è in grado di visualizzarla e di inviarle lavori, l'istanza viene impostata come dopo un certo periodo di tempo e quindi terminata. DOWN

Ciò potrebbe essere causato da gruppi di sicurezza configurati in modo errato. Ad esempio, se la porta 6817 è abilitata slurmd per consentire la comunicazioneslurmctld, ma manca la porta 6818 per consentire slurmctld il ping. slurmd

Verifica che i tuoi gruppi di sicurezza includano tutte le regole richieste, come documentato in. Requisiti e considerazioni sui gruppi di sicurezza