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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) *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:
+ **Registrazione del nodo**: l'istanza EC2 richiama l'azione dell'API [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS per registrarsi al servizio AWS PCS. I guasti possono verificarsi a causa di problemi quali:
+ Permissions
+ [Profilo di istanza errato](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
+ Rete
+ [Impossibile connettersi agli endpoint AWS PCS](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
+ [Endpoint PCS non configurato correttamente AWS](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
+ [Istanza in una sottorete pubblica senza IP pubblico](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
+ [Istanza multi-NIC in una sottorete pubblica](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
+ Segreto del cluster
+ [Il segreto del cluster è stato eliminato o contrassegnato per l'eliminazione](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Integrazione Slurm: l'**istanza viene eseguita `slurmd` e si unisce al cluster Slurm. I guasti possono verificarsi a causa di problemi nei seguenti casi:
+ Permissions
+ [Configurazione del gruppo di sicurezza](#troubleshooting-compute-node-bootstrap-security-groups)
+ [Slurmctld non è in grado di eseguire il ping del nodo di calcolo](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
+ Configurazione AMI personalizzata
+ [Driver NVIDIA mancanti](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
+ [ResumeTimeout raggiunto](#troubleshooting-compute-node-bootstrap-resume-timeout)
## 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.
1. Quando le risorse diventano disponibili, `slurmctld` alloca i nodi esistenti.
1. `slurmd`i 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.
1. **Quando è necessaria una capacità aggiuntiva, AWS PCS utilizza il modello di avvio per il gruppo di nodi di calcolo per lanciare nuove istanze EC2.**
1. **Le nuove istanze vengono avviate nel cluster:**
1. **Le istanze vengono registrate con PCS. AWS **
1. **Le istanze si uniscono al cluster Slurm.**
1. Quando le risorse sono pronte, `slurmctld` alloca i nodi (compresi quelli appena avviati).
1. `slurmd`i 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-1*Sostituiscilo 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](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) nella *Guida per l'utente di Systems Manager*.
1. 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](working-with_compute-instances.md)
------
#### [ Console di gestione AWS ]
**Per ottenere VPC, sottorete e gruppi di sicurezza**
1. Aprire la [console di Amazon EC2](https://console.aws.amazon.com/ec2).
1. Seleziona **Instances (Istanze)**.
1. Nella tabella **Istanze**, scegli l'ID dell'istanza.
1. Trova l'ID **VPC e l'ID** di **sottorete** nel riepilogo dell'istanza visualizzato per l'istanza.
1. Nel riepilogo dell'istanza, scegli la scheda **Sicurezza**.
1. 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
<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:::assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ 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:RegisterComputeNodeGroupInstance`autorizzazione. Per ulteriori informazioni su come creare un profilo di istanza valido, consulta[Creare un profilo di istanza per AWS PCS](getting-started_create-cng_instance-profile.md).
### 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:
+ [Accedi a un AWS servizio utilizzando un endpoint VPC di interfaccia nella guida](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) *Amazon Virtual Private Cloud*. AWS PrivateLink
+ [Endpoint e quote di servizio per PCS AWS](service-endpoints-quotas.md).
+ [Connetti il tuo VPC ad altre reti nella Guida](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) per l'utente di *Amazon Virtual Private Cloud*
+ [AWS Rete PCS](working-with_networking.md)
### 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// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ 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](vpc-interface-endpoints.md)
### 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) 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-`) 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](working-with_clusters_secrets.md).
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` and`slurmdbd`) 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](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html).
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:
+ [Creare gruppi di sicurezza per AWS PCS](getting-started_create-sg.md)
+ [Crea modelli di lancio per AWS PCS](getting-started_create-cng_launch-templates.md)
+ [Requisiti e considerazioni sui gruppi di sicurezza](working-with_networking_sg.md#working-with_networking_sg-requirements)
**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](working-with_ami_custom_install-software.md).
### 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](working-with_ami_custom.md).
### 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 comunicazione`slurmctld`, 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](working-with_networking_sg.md#working-with_networking_sg-requirements)