View a markdown version of this page

Risolvi i problemi di bootstrap e registrazione dei nodi di calcolo in AWS 2 PEZZI - AWS PEZZI
Come funziona Slurm AWS PEZZIRecupera i log delle istanzeRecupera i gruppi da VPC/Subnet/Security un ID di istanzaProblemi di registrazione dei nodiProblemi di unione al 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 di bootstrap e registrazione dei nodi di calcolo in AWS 2 PEZZI

Quando i nodi di calcolo 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 avvio del nodo di calcolo AWS PCS. Questo argomento descrive le procedure per aiutarvi a risolvere i problemi durante il processo di avvio del nodo PCS. AWS Per ulteriori informazioni sulla risoluzione dei problemi di avvio delle istanze EC2, consulta la sezione 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 AWS PEZZI

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

Elaborazione standard dei lavori di Slurm

Nell'elaborazione standard dei job di Slurm vengono eseguite le seguenti fasi:

  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 lavori sui nodi allocati.

L'elaborazione dei lavori di Slurm è attiva AWS 2 PEZZI

I seguenti passaggi vengono eseguiti nell'elaborazione dei lavori AWS PCS:

  1. Quando si invia un lavoro, lo slurmctld 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 avviare 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 lavori sui nodi allocati.

Recupera i log delle istanze

Il primo passaggio 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

Sostituiscilo us-east-1 con la tua AWS regione e i-1234567890abcdef0 con il tuo ID di istanza.

AWS Systems Manager

Se riesci a connetterti all'istanza utilizzando Systems Manager, puoi visualizzare direttamente il file di log di bootstrap:

  1. Connettiti 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 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 vengono avviati solo dopo il completamento dell'inizializzazione o quando l'esecuzione del bootstrap raggiunge un timeout in caso di errore.

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

Per risolvere i problemi con i nodi di calcolo, potresti dover recuperare informazioni sul VPC, sulla sottorete e sui gruppi di sicurezza associati alle tue istanze. Se non conosci gli ID delle tue istanze, consulta. 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 della 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 seguente comando per recuperare le informazioni su VPC, subnet 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 del nodo è 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 dell'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, vedereCrea un profilo di istanza per AWS 2 PEZZI.

Impossibile connettersi a AWS Endpoint PCS

Se i nodi di elaborazione si trovano in una sottorete privata, assicuratevi di aver configurato gli endpoint VPC per PCS. AWS In alternativa, assicurati che la tua sottorete abbia un percorso verso un gateway NAT per l'accesso a Internet. Per impostazione predefinita, l'agente AWS PCS utilizza l'endpoint dual-stack non FIPS. pcs.region.api.aws Se utilizzi un DNS personalizzato, assicurati che possa risolversi fino all'endpoint. pcs.region.api.aws Per ulteriori informazioni, consulta gli argomenti seguenti:

Configurazione errata AWS Endpoint PCS

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

Per ulteriori informazioni su come configurare gli endpoint dell'interfaccia VPC per AWS PCS, vedere. Accesso AWS Parallel Computing Service utilizzando un endpoint di interfaccia (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 il problema, scegli una delle seguenti opzioni:

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

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

  • Abilita l'assegnazione automatica dell'indirizzo IP pubblico 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.

Multi-NIC istanza in una sottorete pubblica

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

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 indirizzo IPv4 pubblico durante il lancio dell'istanza nella Amazon EC2 User Guide for Linux Instances.

Multi-NIC i tipi di istanza 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 cluster VPC.

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 verranno registrati e il cluster verrà danneggiato.

AWS PCS crea automaticamente un segreto condiviso di 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 2 PEZZI.

Se questo segreto viene eliminato o contrassegnato per l'eliminazione, i nuovi nodi non saranno in grado di unirsi al cluster e il controller o altri daemon del cluster (come slurmd andslurmdbd) potrebbero non essere in grado di ricongiungersi al cluster se riavviati.

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

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

Problemi di unione al cluster Slurm

Una volta completata la 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 join di Slurm 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 effettuare 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 calcolo 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, potrebbero mancare 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 demone, 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, il AWS PCS potrebbe non supportare l'AMI o potrebbero esserci problemi di rete. L'istanza EC2 viene eseguita per circa 30 minuti fino al raggiungimento di quella di Slurm e contrassegna il nodo come ResumeTimeout . 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 visualizzare 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 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 vederla e inviarle lavori, l'istanza viene impostata su dopo qualche tempo e quindi terminata. DOWN

Ciò potrebbe essere causato da gruppi di sicurezza non configurati correttamente. Ad esempio, se la porta 6817 è abilitata slurmd per consentire la comunicazione conslurmctld, 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