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à.
# Risoluzione dei problemi di scalabilità
Questa sezione è rilevante per i cluster installati utilizzando la AWS ParallelCluster versione 3.0.0 e successive con il job scheduler. Slurm Per ulteriori informazioni sulla configurazione di più code, vedere. [Configurazione di più code](configuration-of-multiple-queues-v3.md)
Se uno dei cluster in esecuzione presenta problemi, imposta il cluster in uno `STOPPED` stato eseguendo il comando seguente prima di iniziare la risoluzione dei problemi. In questo modo si evitano costi imprevisti.
```
$ pcluster update-compute-fleet --cluster-name {{mycluster}} \
--status STOP_REQUESTED
```
È possibile elencare i flussi di log disponibili dai nodi del cluster utilizzando il [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) comando e filtrando utilizzando uno `private-dns-name` dei nodi in errore o il nodo principale:
```
$ pcluster list-cluster-log-streams --cluster-name {{mycluster}} --region {{eu-west-1}} \
--filters 'Name=private-dns-name,Values=ip-10-0-0-101'
```
Quindi, puoi recuperare il contenuto del flusso di log per analizzarlo utilizzando il [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) comando e passando il `--log-stream-name` corrispondente a uno dei log chiave menzionati nella sezione seguente:
```
$ pcluster get-cluster-log-events --cluster-name {{mycluster}} \
--region {{eu-west-1}} --log-stream-name {{ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init}}
```
AWS ParallelCluster crea flussi di CloudWatch log del cluster in gruppi di log. È possibile visualizzare questi log nella CloudWatch console ** Custom Dashboards ** o nei gruppi di ** log. ** Per ulteriori informazioni, consulta [Integrazione con Amazon CloudWatch Logs](cloudwatch-logs-v3.md) e [CloudWatch Pannello di controllo Amazon](cloudwatch-dashboard-v3.md).
**Topics**
+ [Log chiave per il debug](#troubleshooting-v3-key-logs)
+ [`InsufficientInstanceCapacity`Viene visualizzato un errore in `slurm_resume.log` quando non riesco a eseguire un lavoro, o in `clustermgtd.log` quando non riesco a creare un cluster](#compute-node-initialization-ice-failure-v3-c2)
+ [Risoluzione dei problemi di inizializzazione dei nodi](#troubleshooting-v3-node-init)
+ [**Risoluzione dei problemi relativi alle sostituzioni e alle chiusure impreviste dei nodi**](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [**Sostituzione, chiusura o spegnimento di istanze e nodi problematici**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [Coda (partizione) Stato inattivo ``](#troubleshooting-v3-queues)
+ [Risoluzione di altri problemi noti relativi a nodi e processi](#troubleshooting-v3-other-node-job-issues)
## Log chiave per il debug
La tabella seguente fornisce una panoramica dei log chiave per il nodo principale:
+ `/var/log/cfn-init.log`- Questo è il registro CloudFormation di avvio. Contiene tutti i comandi eseguiti durante la configurazione di un'istanza. Usalo per risolvere i problemi di inizializzazione.
+ `/var/log/chef-client.log`- Questo è il registro del client Chef. Contiene tutti i comandi eseguiti Chef/CINC. Usalo per risolvere i problemi di inizializzazione.
+ `/var/log/parallelcluster/slurm_resume.log`- Questo è un registro. `ResumeProgram` Avvia istanze per nodi dinamici. Usalo per risolvere i problemi di avvio dei nodi dinamici.
+ `/var/log/parallelcluster/slurm_suspend.log`- Questo è il registro. `SuspendProgram` Viene chiamato quando le istanze vengono terminate per i nodi dinamici. Usalo per risolvere i problemi di terminazione dei nodi dinamici. Quando controlli questo registro, dovresti controllare anche il registro. `clustermgtd`
+ `/var/log/parallelcluster/clustermgtd`- Questo è il `clustermgtd` registro. Viene eseguito come demone centralizzato che gestisce la maggior parte delle azioni operative del cluster. Usalo per risolvere eventuali problemi di avvio, chiusura o funzionamento del cluster.
+ `/var/log/slurmctld.log`- Questo è il registro del demone di Slurm controllo. AWS ParallelCluster non prende decisioni di scalabilità. Piuttosto, tenta solo di lanciare risorse per soddisfare i Slurm requisiti. È utile per problemi di scalabilità e allocazione, problemi relativi al lavoro e qualsiasi problema di avvio e chiusura legato allo scheduler.
+ `/var/log/parallelcluster/compute_console_output`- Questo registro registra l'output della console di un esempio di sottoinsieme di nodi di calcolo statici che sono terminati inaspettatamente. Utilizza questo registro se i nodi di calcolo statici terminano e i log dei nodi di calcolo non sono disponibili in. CloudWatch Il `compute_console_output log` contenuto che ricevi è lo stesso quando usi la console Amazon EC2 o AWS CLI per recuperare l'output della console di istanza.
Questi sono i log chiave per i nodi di calcolo:
+ `/var/log/cloud-init-output.log`- Questo è il registro di inizializzazione del [ cloud](https://cloudinit.readthedocs.io/). Contiene tutti i comandi eseguiti durante la configurazione di un'istanza. Usalo per risolvere i problemi di inizializzazione.
+ `/var/log/parallelcluster/computemgtd`- Questo è il registro. `computemgtd` Viene eseguito su ogni nodo di calcolo per monitorare il nodo nel raro caso in cui il `clustermgtd` demone sul nodo principale sia offline. Usalo per risolvere problemi di terminazione imprevisti.
+ `/var/log/slurmd.log`- Questo è il log del demone di Slurm calcolo. Utilizzatelo per risolvere i problemi di inizializzazione e di errore di calcolo.
## `InsufficientInstanceCapacity`Viene visualizzato un errore in `slurm_resume.log` quando non riesco a eseguire un lavoro, o in `clustermgtd.log` quando non riesco a creare un cluster
Se il cluster utilizza uno Slurm scheduler, si verifica un problema di capacità insufficiente. Se non ci sono abbastanza istanze disponibili quando viene effettuata una richiesta di avvio dell'istanza, viene restituito un `InsufficientInstanceCapacity` errore.
Per quanto riguarda la capacità statica delle istanze, puoi trovare l'errore nel `clustermgtd` registro all'indirizzo`/var/log/parallelcluster/clustermgtd`.
Per la capacità dinamica delle istanze, è possibile trovare l'errore nel `ResumeProgram` registro all'indirizzo`/var/log/parallelcluster/slurm_resume.log`.
Il messaggio è simile all'esempio seguente:
```
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...
```
In base al tuo caso d'uso, valuta l'utilizzo di uno dei seguenti metodi per evitare di ricevere questi tipi di messaggi di errore:
+ Disabilita il gruppo di posizionamento se è abilitato. Per ulteriori informazioni, consulta [Gruppi di collocamento e problemi di avvio delle istanze](troubleshooting-v3-placemment-groups.md).
+ Riserva la capacità per le istanze e avviale con ODCR (On-Demand Capacity Reservations). Per ulteriori informazioni, consulta [Avvia istanze con On-Demand Capacity Reservations (ODCR)](launch-instances-odcr-v3.md).
+ Configura più risorse di elaborazione con diversi tipi di istanze. Se il carico di lavoro non richiede un tipo di istanza specifico, puoi sfruttare il failover rapido e insufficiente di capacità con più risorse di calcolo. Per ulteriori informazioni, consulta [Slurmfailover rapido con capacità insufficiente del cluster](slurm-short-capacity-fail-mode-v3.md).
+ Configura più tipi di istanze nella stessa risorsa di calcolo e sfrutta l'allocazione di più tipi di istanze. Per ulteriori informazioni sulla configurazione di più istanze, vedere [Allocazione di più tipi di istanza con Slurm](slurm-multiple-instance-allocation-v3.md) e///. [`Scheduling`](Scheduling-v3.md) [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
+ Sposta la coda in una zona di disponibilità diversa modificando l'ID della subnet nella configurazione del cluster///. [`Scheduling`](Scheduling-v3.md) [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) [`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)
+ Se il carico di lavoro non è strettamente collegato, distribuisci la coda tra diverse zone di disponibilità. Per ulteriori informazioni sulla configurazione di più sottoreti, consulta///. [`Scheduling`](Scheduling-v3.md) [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) [`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)
## Risoluzione dei problemi di inizializzazione dei nodi
Questa sezione illustra come risolvere i problemi di inizializzazione dei nodi. Ciò include i problemi in cui il nodo non riesce ad avviarsi, accendersi o unirsi a un cluster.
**Topics**
+ [Nodo principale](#troubleshooting-v3-node-init.head-node)
+ [Nodi di calcolo](#troubleshooting-v3-node-init.compute-node)
### Nodo principale
Log applicabili:
+ `/var/log/cfn-init.log`
+ `/var/log/chef-client.log`
+ `/var/log/parallelcluster/clustermgtd`
+ `/var/log/parallelcluster/slurm_resume.log`
+ `/var/log/slurmctld.log`
Controllate i `/var/log/chef-client.log` log `/var/log/cfn-init.log` e o i flussi di log corrispondenti. Questi registri contengono tutte le azioni eseguite durante la configurazione del nodo principale. La maggior parte degli errori che si verificano durante l'installazione dovrebbe contenere messaggi di errore nel `/var/log/chef-client.log` registro. Se `OnNodeStart` nella configurazione del cluster sono specificati i nostri `OnNodeConfigured` script, ricontrolla che lo script venga eseguito correttamente tramite i messaggi di registro.
Quando viene creato un cluster, il nodo principale deve attendere che i nodi di calcolo si uniscano al cluster prima di potersi unire al cluster. Per questo motivo, se i nodi di calcolo non riescono a unirsi al cluster, anche il nodo principale fallisce. È possibile seguire una di queste serie di procedure, a seconda del tipo di note di calcolo utilizzate, per risolvere questo tipo di problema:
### Nodi di calcolo
+ Registri applicabili:
+ `/var/log/cloud-init-output.log`
+ `/var/log/slurmd.log`
+ Se viene avviato un nodo di calcolo`/var/log/cloud-init-output.log`, verifica innanzitutto che contenga i log di configurazione simili a quelli del nodo principale. `/var/log/chef-client.log` La maggior parte degli errori che si verificano durante l'installazione dovrebbe contenere messaggi di errore nel `/var/log/cloud-init-output.log` registro. Se gli script di preinstallazione o post-installazione sono specificati nella configurazione del cluster, verifica che siano stati eseguiti correttamente.
+ Se utilizzi un'AMI personalizzata con modifiche alla Slurm configurazione, potrebbe esserci un errore Slurm correlato che impedisce al nodo di calcolo di unirsi al cluster. Per gli errori relativi allo scheduler, controlla il registro. `/var/log/slurmd.log`
**Nodi di calcolo dinamici: **
+ Cerca nel `ResumeProgram` log (`/var/log/parallelcluster/slurm_resume.log`) il nome del tuo nodo di calcolo per vedere se `ResumeProgram` è mai stato chiamato con il nodo. (Se `ResumeProgram` non è mai stato chiamato, puoi controllare `slurmctld` log (`/var/log/slurmctld.log`) per determinare se hai Slurm mai provato a chiamare `ResumeProgram` con il nodo).
+ Tieni presente che le autorizzazioni errate `ResumeProgram` potrebbero causare `ResumeProgram` il fallimento silenzioso. Se stai utilizzando un'AMI personalizzata con modifiche alla `ResumeProgram` configurazione, verifica che `ResumeProgram` sia di proprietà `slurm` dell'utente e disponga dell'autorizzazione `744` (`rwxr--r--`).
+ Se `ResumeProgram` viene chiamato, controlla se viene avviata un'istanza per il nodo. Se non è stata avviata alcuna istanza, è possibile visualizzare un messaggio di errore che descrive l'errore di avvio.
+ Se l'istanza viene avviata, potrebbe esserci stato un problema durante il processo di configurazione. Dovresti vedere l'indirizzo IP privato e l'ID dell'istanza corrispondenti nel `ResumeProgram` registro. Inoltre, puoi consultare i registri di configurazione corrispondenti per l'istanza specifica. Per ulteriori informazioni sulla risoluzione di un errore di configurazione con un nodo di calcolo, consulta la sezione successiva.
**Nodi di calcolo statici: **
+ Controlla il registro `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) per vedere se sono state avviate istanze per il nodo. Se non sono state avviate, dovrebbe apparire un chiaro messaggio di errore che indichi in dettaglio l'errore di avvio.
+ Se l'istanza viene avviata, c'è qualche problema durante il processo di configurazione. Dovresti vedere l'indirizzo IP privato e l'ID dell'istanza corrispondenti nel `ResumeProgram` registro. Inoltre, puoi consultare i registri di configurazione corrispondenti per l'istanza specifica.
**Nodi di calcolo supportati da istanze Spot: **
+ Se è la prima volta che utilizzi le istanze Spot e il processo rimane in un PD (stato in sospeso), ricontrolla il file. `/var/log/parallelcluster/slurm_resume.log` Probabilmente troverai un errore come il seguente:
```
2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for Amazon EC2 Spot Instances.
```
Quando usi le istanze Spot, nel tuo account deve esistere un ruolo `AWSServiceRoleForEC2Spot` collegato al servizio. Per creare questo ruolo nel tuo account utilizzando il AWS CLI, esegui il seguente comando:
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Per ulteriori informazioni, consulta [Utilizzo di Istanze spot](spot-v3.md) la Guida per l' AWS ParallelCluster utente e il [ Service-linked ruolo per le richieste di istanze Spot ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) nella * Amazon EC2 User Guide*.
## **Risoluzione dei problemi relativi alle sostituzioni e alle chiusure impreviste dei nodi**
Questa sezione continua a esplorare come risolvere i problemi relativi ai nodi, in particolare quando un nodo viene sostituito o terminato in modo imprevisto.
+ **Log applicabili: **
+ `/var/log/parallelcluster/clustermgtd`(nodo principale)
+ `/var/log/slurmctld.log`(nodo principale)
+ `/var/log/parallelcluster/computemgtd`(nodo di calcolo)
**Nodi sostituiti o terminati in modo imprevisto **
+ Controlla nel `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) per vedere se un nodo è `clustermgtd` stato sostituito o terminato. Nota che `clustermgtd` gestisce tutte le normali azioni di manutenzione del nodo.
+ Se il nodo `clustermgtd` viene sostituito o terminato, dovrebbe essere visualizzato un messaggio che specifica il motivo per cui questa azione è stata eseguita sul nodo. Se il motivo è correlato allo scheduler (ad esempio, perché il nodo è attivo`DOWN`), archivia il `slurmctld` log per ulteriori informazioni. Se il motivo è correlato ad Amazon EC2, dovrebbe essere visualizzato un messaggio informativo che descriva in dettaglio il problema relativo ad Amazon EC2 che ha richiesto la sostituzione.
+ Se il nodo `clustermgtd` non è stato chiuso, controlla innanzitutto se si trattava di una chiusura prevista da parte di Amazon EC2, più specificamente una terminazione istantanea. `computemgtd`, in esecuzione su un nodo di calcolo, può anche terminare un nodo se viene ritenuto non integro. `clustermgtd` Controlla `computemgtd` log (`/var/log/parallelcluster/computemgtd`) per vedere se il nodo è stato `computemgtd` terminato.
**Nodi non riusciti **
+ Effettua il check-in in `slurmctld` log (`/var/log/slurmctld.log`) per vedere perché un job o un nodo non è riuscito. Nota che i lavori vengono automaticamente ricollegati in caso di errore di un nodo.
+ Se `slurm_resume` segnala che il nodo è stato avviato e dopo alcuni minuti `clustermgtd` segnala che non esiste un'istanza corrispondente in Amazon EC2 per quel nodo, il nodo potrebbe fallire durante la configurazione. Per recuperare il log da un compute (`/var/log/cloud-init-output.log`), procedi nel seguente modo:
+ Invia un lavoro per far partire Slurm un nuovo nodo.
+ Attendi l'avvio del nodo di calcolo.
+ Modifica il comportamento di spegnimento avviato dall'istanza in modo che un nodo di calcolo in errore venga arrestato anziché terminato.
```
$ aws ec2 modify-instance-attribute \
--instance-id {{i-1234567890abcdef0}} \
--instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"
```
+ Abilita la protezione da cessazione.
```
$ aws ec2 modify-instance-attribute \
--instance-id {{i-1234567890abcdef0}} \
--disable-api-termination
```
+ Contrassegna il nodo in modo che sia facilmente identificabile.
```
$ aws ec2 create-tags \
--resources {{i-1234567890abcdef0}} \
--tags Key=Name,Value=QUARANTINED-Compute
```
+ Scollegare il nodo dal cluster modificando il tag. `parallelcluster:cluster-name`
```
$ aws ec2 create-tags \
--resources {{i-1234567890abcdef0}} \
--tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName
```
+ Recupera l'output della console dal nodo con questo comando.
```
$ aws ec2 get-console-output --instance-id {{i-1234567890abcdef0}} --output text
```
## **Sostituzione, chiusura o spegnimento di istanze e nodi problematici**
+ **Log applicabili: **
+ `/var/log/parallelcluster/clustermgtd`(nodo principale)
+ `/var/log/parallelcluster/slurm_suspend.log`(nodo principale)
+ Nella maggior parte dei casi, `clustermgtd` gestisce tutte le azioni di terminazione dell'istanza previste. Controlla nel `clustermgtd` registro il motivo per cui non è riuscito a sostituire o terminare un nodo.
+ Se i nodi dinamici non funzionano[`SlurmSettings`Proprietà](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties), controlla nel `SuspendProgram` log se `SuspendProgram` è stato chiamato `slurmctld` con il nodo specifico come argomento. Nota che in realtà `SuspendProgram` non esegue alcuna azione. Piuttosto, registra solo quando viene chiamato. La chiusura e il `NodeAddr` ripristino di tutte le istanze vengono eseguiti da`clustermgtd`. Slurmriporta `SuspendTimeout` automaticamente i nodi in uno `POWER_SAVING` stato successivo.
+ Se i nodi di calcolo falliscono continuamente a causa di errori di bootstrap, verifica se vengono avviati con l'opzione abilitata. [Slurm modalità protetta dal cluster](slurm-protected-mode-v3.md) Se la modalità protetta non è abilitata, modifica le impostazioni della modalità protetta per abilitare la modalità protetta. Risolvete i problemi e correggete lo script di bootstrap.
## Coda (partizione) Stato inattivo ``
Se si esegue l'esecuzione `sinfo` e l'output mostra le code con `AVAIL` lo stato disattivato`inact`, è possibile che il cluster sia stato [Slurm modalità protetta dal cluster](slurm-protected-mode-v3.md) abilitato e che la coda sia stata impostata sullo stato per un periodo di tempo predefinito. `INACTIVE`
## Risoluzione di altri problemi noti relativi a nodi e processi
Un altro tipo di problema noto è che AWS ParallelCluster potrebbe non riuscire ad allocare i job o a prendere decisioni di scalabilità. Con questo tipo di problema, le risorse vengono avviate, terminate o gestite AWS ParallelCluster solo in base alle istruzioni. Slurm Per questi problemi, consulta il `slurmctld` registro per risolverli.