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à.
# AWS ParallelCluster risoluzione dei problemi
La AWS ParallelCluster comunità mantiene una pagina Wiki che fornisce molti suggerimenti per la risoluzione dei problemi sul [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/). Per un elenco dei problemi noti, vedi [Problemi noti](https://github.com/aws/aws-parallelcluster/wiki#known-issues-).
**Topics**
+ [
## Recupero e conservazione dei log
](#retrieving-and-preserve-logs)
+ [
## Risoluzione dei problemi di distribuzione dello stack
](#troubleshooting-stack-creation-failures)
+ [
## Risoluzione dei problemi nei cluster con modalità di coda multipla
](#multiple-queue-mode)
+ [
## Risoluzione dei problemi nei cluster in modalità coda singola
](#troubleshooting-issues-in-single-queue-clusters)
+ [
## Gruppi di collocamento e problemi relativi al lancio delle istanze
](#placement-groups-and-instance-launch-issues)
+ [
## Directory che non possono essere sostituite
](#directories-cannot-be-replaced)
+ [
## Risoluzione dei problemi in Amazon DCV
](#nice-dcv-troubleshooting)
+ [
## Risoluzione dei problemi nei cluster con integrazione AWS Batch
](#clusters-with-aws-batch-integration)
+ [
## Risoluzione dei problemi quando una risorsa non riesce a creare
](#troubleshooting-resource-fails-to-create)
+ [
## Risoluzione dei problemi relativi alle dimensioni delle policy IAM
](#troubleshooting-policy-size-issues)
+ [
## Supporto aggiuntivo
](#getting-support)
## Recupero e conservazione dei log
I log sono una risorsa utile per la risoluzione dei problemi. Prima di poter utilizzare i log per risolvere i problemi relativi alle AWS ParallelCluster risorse, è necessario creare un archivio di log del cluster. Segui i passaggi descritti nell'argomento [Creazione di un archivio dei log di un cluster](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) sul [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/) per avviare questo processo.
Se uno dei cluster in esecuzione presenta problemi, è necessario collocarlo in uno `STOPPED` stato eseguendo il ``pcluster stop` ` comando prima di iniziare la risoluzione dei problemi. In questo modo si evita di incorrere in costi imprevisti.
Se `pcluster` smette di funzionare o se desideri eliminare un cluster preservandone i log, esegui il comando. ``pcluster delete` —keep-logs ` L'esecuzione di questo comando elimina il cluster ma mantiene il gruppo di log archiviato in Amazon. CloudWatch Per ulteriori informazioni su questo comando, consulta la [`pcluster delete`](pcluster.delete.md) documentazione.
## Risoluzione dei problemi di distribuzione dello stack
Se il cluster non viene creato e ripristina la creazione dello stack, puoi consultare i seguenti file di registro per diagnosticare il problema. Vuoi cercare l'output di `ROLLBACK_IN_PROGRESS` in questi log. Il messaggio di errore dovrebbe essere simile al seguente:
```
$ pcluster create mycluster
Creating stack named: parallelcluster-mycluster
Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS
Cluster creation failed. Failed events:
- AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081
```
Per diagnosticare il problema, crea nuovamente il cluster utilizzando[`pcluster create`](pluster.create.md), incluso il `--norollback` flag. Quindi, inserisci SSH nel cluster:
```
$ pcluster create mycluster --norollback
...
$ pcluster ssh mycluster
```
Dopo aver effettuato l'accesso al nodo principale, dovresti trovare tre file di registro principali che puoi utilizzare per individuare l'errore.
+ `/var/log/cfn-init.log`è il registro dello script. `cfn-init` Per prima cosa controlla questo registro. È probabile che venga visualizzato un errore come `Command chef failed` in questo registro. Guarda le righe immediatamente precedenti a questa riga per ulteriori dettagli relativi al messaggio di errore. Per ulteriori informazioni, vedere [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html).
+ `/var/log/cloud-init.log`[è il log per cloud-init.](https://cloudinit.readthedocs.io/) Se non vedi nulla`cfn-init.log`, prova a controllare successivamente questo registro.
+ `/var/log/cloud-init-output.log`è l'output dei comandi eseguiti da [cloud-init](https://cloudinit.readthedocs.io/). Questo include l'output di. `cfn-init` Nella maggior parte dei casi, non è necessario consultare questo registro per risolvere questo tipo di problema.
## Risoluzione dei problemi nei cluster con modalità di coda multipla
Questa sezione è rilevante per i cluster che sono stati installati utilizzando la AWS ParallelCluster versione 2.9.0 e successive con il job scheduler. Slurm Per ulteriori informazioni sulla modalità a coda multipla, vedere. [Modalità coda multipla](queue-mode.md)
**Topics**
+ [
### Registri delle chiavi
](#key-logs)
+ [
### **Risoluzione dei problemi di inizializzazione dei nodi**
](#troubleshooting-node-initialization-issues)
+ [
### **Risoluzione dei problemi di sostituzioni e terminazioni impreviste dei nodi**
](#troubleshooting-unexpected-node-replacements-and-terminations)
+ [
### **Sostituzione, interruzione o spegnimento delle istanze e dei nodi problematici**
](#replacing-terminating-or-powering-down-problematic-instances-and-nodes)
+ [
### **Risoluzione di altri problemi noti relativi a nodi e processi**
](#troubleshooting-other-known-node-and-job-issues)
### Registri delle chiavi
La tabella seguente fornisce una panoramica dei log delle chiavi per il nodo principale:
`/var/log/cfn-init.log`
Questo è il log di CloudFormation inizializzazione. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione.
`/var/log/chef-client.log`
Questo è il registro del client Chef. Contiene tutti i comandi che sono stati eseguiti tramite Chef/CINC. È utile per la risoluzione dei problemi di inizializzazione.
`/var/log/parallelcluster/slurm_resume.log`
Questo è un `ResumeProgram` registro. Avvia istanze per nodi dinamici ed è utile per la risoluzione dei 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 ed è utile per la risoluzione dei problemi di terminazione dei nodi dinamici. Quando si controlla questo registro, è necessario controllare anche il registro. `clustermgtd`
`/var/log/parallelcluster/clustermgtd`
Questo è il `clustermgtd` registro. Funziona come il demone centralizzato che gestisce la maggior parte delle azioni operative del cluster. È utile per risolvere qualsiasi problema di avvio, chiusura o funzionamento del cluster.
`/var/log/slurmctld.log`
Questo è il registro del demone Slurm di controllo. AWS ParallelCluster non prende decisioni di scalabilità. Piuttosto, tenta solo di avviare risorse per soddisfare i Slurm requisiti. È utile per problemi di scalabilità e allocazione, problemi relativi al lavoro e qualsiasi problema relativo all'avvio e alla cessazione della pianificazione.
Queste sono le note chiave per i nodi Compute:
`/var/log/cloud-init-output.log`
Questo è il log [cloud-init](https://cloudinit.readthedocs.io/). Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione.
`/var/log/parallelcluster/computemgtd`
Questo è il `computemgtd` registro. Viene eseguito su ogni nodo di elaborazione per monitorare il nodo nel raro caso in cui il `clustermgtd` demone sul nodo principale sia offline. È utile per la risoluzione di problemi di terminazione imprevisti.
`/var/log/slurmd.log`
Questo è il registro del demone di Slurm calcolo. È utile per la risoluzione dei problemi relativi all'inizializzazione e agli errori di calcolo.
### **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 entrare a far parte di un cluster.
**Nodo principale:**
Registri 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`
Controlla i `/var/log/chef-client.log` registri `/var/log/cfn-init.log` e. Questi registri dovrebbero contenere tutte le azioni eseguite durante la configurazione del nodo principale. La maggior parte degli errori che si verificano durante l'installazione dovrebbe contenere un messaggio di errore nel `/var/log/chef-client.log` registro. Se nella configurazione del cluster sono specificati script di preinstallazione o post-installazione, 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 poter entrare a far parte del cluster. Pertanto, se i nodi di elaborazione 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 dinamici:**
+ Cerca in `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 autorizzazioni errate per `ResumeProgram` potrebbero causare `ResumeProgram` un errore silenzioso. Se utilizzi un'AMI personalizzata con modifiche alla `ResumeProgram` configurazione, verifica che sia di proprietà dell'`slurm`utente e disponga dell'autorizzazione `744` (`rwxr--r--`). `ResumeProgram`
+ Se `ResumeProgram` viene chiamato, controlla se è stata avviata un'istanza per il nodo. Se non è stata avviata alcuna istanza, dovrebbe essere visualizzato un messaggio di errore che descrive l'errore di avvio.
+ Se l'istanza viene avviata, potrebbe essersi verificato un problema durante il processo di configurazione. Dovresti vedere l'indirizzo IP privato e l'ID dell'istanza corrispondenti dal `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 lanciate istanze per il nodo. Se non sono state avviate, dovrebbe apparire un messaggio di errore chiaro che descrive 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 dal `ResumeProgram` registro. Inoltre, puoi consultare i registri di configurazione corrispondenti per l'istanza specifica.
+ **Nodi di calcolo:**
+ **Registri applicabili:**
+ `/var/log/cloud-init-output.log`
+ `/var/log/slurmd.log`
+ Se viene avviato il nodo di calcolo`/var/log/cloud-init-output.log`, verifica innanzitutto che dovrebbe contenere i log di configurazione simili al `/var/log/chef-client.log` registro sul nodo principale. La maggior parte degli errori che si verificano durante l'installazione dovrebbero contenere messaggi di errore nel registro. `/var/log/cloud-init-output.log` Se nella configurazione del cluster sono specificati script di preinstallazione o post-installazione, verificate 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 entrare a far parte del cluster. Per gli errori relativi allo scheduler, controlla il `/var/log/slurmd.log` registro.
### **Risoluzione dei problemi di sostituzioni e terminazioni 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.
+ **Registri 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 il `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) per vedere se è `clustermgtd` stata intrapresa l'azione necessaria per sostituire o terminare un nodo. Nota che `clustermgtd` gestisce tutte le normali azioni di manutenzione del nodo.
+ Se il nodo `clustermgtd` viene sostituito o terminato, dovrebbe esserci un messaggio che spiega in dettaglio il motivo per cui è stata intrapresa questa azione sul nodo. Se il motivo è correlato allo scheduler (ad esempio, perché il nodo è attivo`DOWN`), controlla il `slurmctld` log in per ulteriori informazioni. Se il motivo è correlato ad Amazon EC2, dovrebbe esserci un messaggio informativo che descriva in dettaglio il problema relativo ad Amazon EC2 che ha richiesto la sostituzione.
+ Se `clustermgtd` non hai terminato il nodo, verifica innanzitutto se si trattava di una terminazione prevista da parte di Amazon EC2, in particolare di una terminazione spot. `computemgtd`, in esecuzione su un nodo di elaborazione, può anche intraprendere un'azione per terminare un nodo se viene considerato non integro. `clustermgtd` Controlla `computemgtd` log (`/var/log/parallelcluster/computemgtd`) per vedere se il nodo è `computemgtd` terminato.
+ **Nodi falliti**
+ Controlla `slurmctld` log (`/var/log/slurmctld.log`) per vedere perché un job o un nodo non sono riusciti. Tieni presente che i lavori vengono automaticamente messi in coda 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 consentire la creazione Slurm di un nuovo nodo.
+ Dopo l'avvio del nodo, abilita la protezione dalla terminazione usando questo comando.
```
aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination
```
+ Recupera l'output della console dal nodo con questo comando.
```
aws ec2 get-console-output --instance-id i-xyz --output text
```
### **Sostituzione, interruzione o spegnimento delle istanze e dei nodi problematici**
+ **Registri 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 previste dell'istanza. Controlla il `clustermgtd` registro per vedere perché non è riuscito a sostituire o terminare un nodo.
+ Se i nodi dinamici non funzionano [`scaledown_idletime`](scaling-section.md#scaledown-idletime) correttamente, controlla il `SuspendProgram` registro per vedere se `SuspendProgram` è stato chiamato usando `slurmctld` il nodo specifico come argomento. Nota che in realtà `SuspendProgram` non esegue alcuna azione. Piuttosto, registra solo quando viene chiamato. La terminazione e il `NodeAddr` ripristino di tutte le istanze vengono eseguiti da. `clustermgtd` Slurmriporta `SuspendTimeout` automaticamente i nodi in uno `POWER_SAVING` stato.
### **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 lavori o a prendere decisioni sulla scalabilità. Con questo tipo di problema, avvia, termina o gestisce le risorse AWS ParallelCluster solo in base alle istruzioni. Slurm Per questi problemi, consulta il `slurmctld` registro per risolverli.
## Risoluzione dei problemi nei cluster in modalità coda singola
**Nota**
A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso dei nostri scheduler. SGE Torque
Questa sezione si applica ai cluster che non dispongono di una modalità di coda multipla con una delle due configurazioni seguenti:
+ Avviato utilizzando una AWS ParallelCluster versione precedente alla 2.9.0 eSGE, Torque o Job Scheduler. Slurm
+ Lanciato utilizzando la AWS ParallelCluster versione 2.9.0 o successiva e/o Job Scheduler. SGE Torque
**Topics**
+ [
### Registri chiave
](#key-logs-1)
+ [
### **Risoluzione dei problemi relativi alle operazioni di avvio e unione non riuscite**
](#troubleshooting-failed-launch-and-join-operations)
+ [
### Risoluzione dei problemi di scalabilità
](#troubleshooting-scaling-issues)
+ [
### Risoluzione di altri problemi relativi ai cluster
](#troubleshooting-other-cluster-related-issues)
### Registri chiave
I seguenti file di registro sono i registri delle chiavi per il nodo principale.
Per la AWS ParallelCluster versione 2.9.0 o successiva:
`/var/log/chef-client.log`
Questo è il registro del client CINC (chef). Contiene tutti i comandi che sono stati eseguiti tramite CINC. È utile per la risoluzione dei problemi di inizializzazione.
Per tutte le AWS ParallelCluster versioni:
`/var/log/cfn-init.log`
Questo è il `cfn-init` registro. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza ed è quindi utile per la risoluzione dei problemi di inizializzazione. Per ulteriori informazioni, vedere [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html).
`/var/log/clustermgtd.log`
Questo è il `clustermgtd` registro per gli scheduler. Slurm `clustermgtd`viene eseguito come demone centralizzato che gestisce la maggior parte delle azioni operative del cluster. È utile per risolvere qualsiasi problema di avvio, chiusura o funzionamento del cluster.
`/var/log/jobwatcher`
Questo è il `jobwatcher` registro SGE e gli Torque scheduler. `jobwatcher`monitora la coda dello scheduler e aggiorna l'Auto Scaling Group. È utile per la risoluzione di problemi relativi al ridimensionamento dei nodi.
`/var/log/sqswatcher`
Questo è il `sqswatcher` registro per SGE gli Torque scheduler. `sqswatcher`elabora l'evento Instance Ready inviato da un'istanza di calcolo dopo l'inizializzazione riuscita. Aggiunge inoltre nodi di calcolo alla configurazione dello scheduler. Questo registro è utile per risolvere il motivo per cui uno o più nodi non sono riusciti a entrare a far parte di un cluster.
Di seguito sono riportati i log chiave per i nodi di calcolo.
AWS ParallelCluster versione 2.9.0 o successiva
`/var/log/cloud-init-output.log`
Questo è il log di avvio di Cloud. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione.
AWS ParallelCluster versioni precedenti alla 2.9.0
`/var/log/cfn-init.log`
Questo è il registro di inizializzazione CloudFormation . Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione
Tutte le versioni
`/var/log/nodewatcher`
Questo è il `nodewatcher` registro. `nodewatcher`demoni che vengono eseguiti su ogni nodo di elaborazione quando si utilizzano SGE gli scheduler. Torque Ridimensionano un nodo se è inattivo. Questo registro è utile per qualsiasi problema relativo al ridimensionamento delle risorse.
### **Risoluzione dei problemi relativi alle operazioni di avvio e unione non riuscite**
+ **Registri applicabili:**
+ `/var/log/cfn-init-cmd.log`(nodo principale e nodo di elaborazione)
+ `/var/log/sqswatcher`(nodo principale)
+ Se i nodi non sono stati avviati, controlla il `/var/log/cfn-init-cmd.log` registro per visualizzare il messaggio di errore specifico. Nella maggior parte dei casi, gli errori di avvio dei nodi sono dovuti a un errore di configurazione.
+ Se i nodi di calcolo non sono riusciti a partecipare alla configurazione dello scheduler nonostante la corretta configurazione, controlla il `/var/log/sqswatcher` registro per vedere se l'evento è stato `sqswatcher` elaborato. Nella maggior parte dei casi questi problemi sono dovuti al fatto che `sqswatcher` l'evento non è stato elaborato.
### Risoluzione dei problemi di scalabilità
+ **Registri applicabili:**
+ `/var/log/jobwatcher`(nodo principale)
+ `/var/log/nodewatcher`(nodo di calcolo)
+ **Problemi di scalabilità verso l'alto:** per il nodo principale, controlla il `/var/log/jobwatcher` registro per vedere se il `jobwatcher` demone ha calcolato il numero corretto di nodi richiesti e ha aggiornato il gruppo Auto Scaling. Si noti che `jobwatcher` monitora la coda dello scheduler e aggiorna l'Auto Scaling Group.
+ **Problemi di ridimensionamento:** per i nodi di elaborazione, controlla il `/var/log/nodewatcher` registro sul nodo problematico per scoprire perché il nodo è stato ridimensionato. Nota che `nodewatcher` i demoni ridimensionano un nodo di calcolo se è inattivo.
### Risoluzione di altri problemi relativi ai cluster
Un problema noto è rappresentato dagli errori casuali delle note di calcolo su cluster di grandi dimensioni, in particolare quelli con 500 o più nodi di elaborazione. Questo problema è correlato a una limitazione dell'architettura di scalabilità del cluster a coda singola. Se si desidera utilizzare un cluster su larga scala, si utilizza la AWS ParallelCluster versione v2.9.0 o successiva, si utilizza e si desidera evitare questo problemaSlurm, è consigliabile eseguire l'aggiornamento e passare a un cluster che supporta la modalità di coda multipla. È possibile farlo eseguendo. [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert)
Per ultra-large-scale i cluster, potrebbe essere necessaria un'ulteriore ottimizzazione del sistema. Per ulteriori informazioni, contattare. Supporto
## Gruppi di collocamento e problemi relativi al lancio delle istanze
*Per ottenere la latenza tra i nodi più bassa, utilizzate un gruppo di posizionamento.* Un gruppo di posizionamento garantisce che le istanze si trovino sulla stessa dorsale di rete. Se non ci sono abbastanza istanze disponibili quando viene effettuata una richiesta, viene restituito un `InsufficientInstanceCapacity` errore. Per ridurre la possibilità di ricevere questo errore quando si utilizzano i gruppi di posizionamento dei cluster, imposta il [`placement_group`](cluster-definition.md#placement-group) parametro su `DYNAMIC` e imposta il [`placement`](cluster-definition.md#placement) parametro su. `compute`
[Se avete bisogno di un filesystem condiviso ad alte prestazioni, prendete in considerazione l'utilizzo FSx di for Lustre.](https://aws.amazon.com/fsx/lustre/)
Se il nodo principale deve appartenere al gruppo di posizionamento, utilizzate lo stesso tipo di istanza e la stessa sottorete sia per la testa che per tutti i nodi di calcolo. In questo modo, il [`compute_instance_type`](cluster-definition.md#compute-instance-type) parametro ha lo stesso valore del [`master_instance_type`](cluster-definition.md#master-instance-type) parametro, il [`placement`](cluster-definition.md#placement) parametro viene impostato su e il [`compute_subnet_id`](vpc-section.md#compute-subnet-id) parametro non viene specificato. `cluster` Con questa configurazione, il valore del [`master_subnet_id`](vpc-section.md#master-subnet-id) parametro viene utilizzato per i nodi di calcolo.
Per ulteriori informazioni, consulta [Risoluzione dei problemi di avvio delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) e [Ruoli e limitazioni dei gruppi di collocamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) nella Guida per l'utente di *Amazon EC2*
## Directory che non possono essere sostituite
Le seguenti directory sono condivise tra i nodi e non possono essere sostituite.
`/home`
Ciò include la cartella home dell'utente predefinita (`/home/ec2_user`su Amazon LinuxCentOS, `/home/centos` on e `/home/ubuntu` onUbuntu).
`/opt/intel`
Questo include Intel MPI, Intel Parallel Studio e file correlati.
`/opt/sge`
A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso di SGE o Torque scheduler.
Questo include Son of Grid Engine e file correlati. (Condizionale, solo se [`scheduler`](cluster-definition.md#scheduler)` = sge`.)
`/opt/slurm`
Questo include Slurm Workload Manager e file correlati. (Condizionale, solo se [`scheduler`](cluster-definition.md#scheduler)` = slurm`.)
`/opt/torque`
A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso di o scheduler. SGE Torque
Questo include Torque Resource Manager e file correlati. (Condizionale, solo se [`scheduler`](cluster-definition.md#scheduler)` = torque`.)
## Risoluzione dei problemi in Amazon DCV
**Topics**
+ [
### Registri per Amazon DCV
](#nice-dcv-troubleshooting-logs)
+ [
### Memoria di tipo di istanza Amazon DCV
](#nice-dcv-troubleshooting-memory)
+ [
### Problemi con Ubuntu Amazon DCV
](#nice-dcv-troubleshooting-modules)
### Registri per Amazon DCV
I log di Amazon DCV vengono scritti nei file della `/var/log/dcv/` directory. La revisione di questi registri può aiutare a risolvere i problemi.
### Memoria di tipo di istanza Amazon DCV
Il tipo di istanza deve avere almeno 1,7 gibibyte (GiB) di RAM per eseguire Amazon DCV. Nanoe i tipi di micro istanza non dispongono di memoria sufficiente per eseguire Amazon DCV.
### Problemi con Ubuntu Amazon DCV
Quando esegui Gnome Terminal su una sessione DCV su Ubuntu, potresti non avere automaticamente accesso all'ambiente utente disponibile tramite la AWS ParallelCluster shell di accesso. L'ambiente utente fornisce moduli di ambiente come openmpi o intelmpi e altre impostazioni utente.
Le impostazioni predefinite di Gnome Terminal impediscono alla shell di avviarsi come shell di accesso. Ciò significa che i profili della shell non vengono generati automaticamente e l'ambiente AWS ParallelCluster utente non viene caricato.
Per creare correttamente il profilo della shell e accedere all'ambiente AWS ParallelCluster utente, effettuate una delle seguenti operazioni:
+
**Modificate le impostazioni predefinite del terminale:**
1. Scegli il menu **Modifica** nel terminale Gnome.
1. Seleziona **Preferenze**, quindi **Profili**.
1. Scegli **Comando** e seleziona **Esegui comando come shell di accesso**.
1. Apri un nuovo terminale.
+ **Usa la riga di comando per trovare i profili disponibili:**
```
$ source /etc/profile && source $HOME/.bashrc
```
## Risoluzione dei problemi nei cluster con integrazione AWS Batch
Questa sezione è pertinente ai cluster con integrazione di AWS Batch scheduler.
### Problemi relativi al nodo principale
I problemi di configurazione relativi al nodo principale possono essere risolti allo stesso modo del cluster a coda singola. Per ulteriori informazioni su questi problemi, consulta [Risoluzione dei problemi nei cluster in modalità coda singola](#troubleshooting-issues-in-single-queue-clusters).
### AWS Batch problemi di invio di lavori paralleli a più nodi
In caso di problemi nell'invio di lavori paralleli multinodo quando si utilizza AWS Batch come pianificatore di processi, è necessario eseguire l'aggiornamento alla AWS ParallelCluster versione 2.5.0. Se ciò non è possibile, puoi utilizzare la soluzione alternativa descritta in dettaglio nell'argomento: [applicare patch automatiche a un cluster utilizzato per inviare lavori paralleli a più nodi tramite](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch). AWS Batch
### Problemi di calcolo
AWS Batch gestisce gli aspetti di scalabilità e calcolo dei tuoi servizi. Se riscontri problemi relativi all'elaborazione, consulta la documentazione AWS Batch [sulla risoluzione dei problemi per ricevere assistenza](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html).
### Errori del processo
Se un processo fallisce, puoi eseguire il ``awsbout`` comando per recuperare l'output del processo. Puoi anche eseguire il ``awsbstat` -d` comando per ottenere un collegamento ai log dei lavori archiviati da Amazon CloudWatch.
## Risoluzione dei problemi quando una risorsa non riesce a creare
Questa sezione è rilevante per le risorse del cluster in caso di mancata creazione.
Quando una risorsa non riesce a creare, ParallelCluster restituisce un messaggio di errore come il seguente.
```
pcluster create -c config my-cluster
Beginning cluster creation for cluster: my-cluster
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the
Internet (e.g. a NAT Gateway and a valid route table).
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet
(e.g. a NAT Gateway and a valid route table).
Info: There is a newer version 3.0.3 of AWS ParallelCluster available.
Creating stack named: parallelcluster-my-cluster
Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS
Cluster creation failed. Failed events:
- AWS::CloudFormation::Stack MasterServerSubstack Embedded stack
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789
was not successfully created:
The following resource(s) failed to create: [MasterServer].
- AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer].
- AWS::EC2::Instance MasterServer You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the
specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.
(Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null)
}
```
Ad esempio, se viene visualizzato il messaggio di stato mostrato nella risposta al comando precedente, è necessario utilizzare tipi di istanza che non superino il limite di vCPU corrente o richiedano una maggiore capacità di vCPU.
Puoi anche utilizzare la CloudFormation console per visualizzare le informazioni sullo `"Cluster creation failed"` stato.
Visualizza i messaggi di CloudFormation errore dalla console.
1. Accedi a Console di gestione AWS e vai a [https://console.aws.amazon.com/cloudformazione.](https://console.aws.amazon.com/cloudformation/)
1. Seleziona lo stack denominato parallelcluster-. *cluster\$1name*
1. Scegli la scheda **Eventi**.
1. **Controlla lo **stato** della risorsa che non è stata creata scorrendo l'elenco degli eventi delle risorse per ID logico.** Se la creazione di una sottoattività non è riuscita, procedi a ritroso per trovare l'evento relativo alla risorsa non riuscita.
1. Un esempio di AWS CloudFormation messaggio di errore:
```
2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789
was not successfully created: The following resource(s) failed to create: [MasterServer].
```
## Risoluzione dei problemi relativi alle dimensioni delle policy IAM
Fai riferimento a [IAM e alle AWS STS quote, ai requisiti dei nomi e ai limiti di caratteri](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) per verificare le quote sulle politiche gestite associate ai ruoli. Se la dimensione di una policy gestita supera la quota, suddividi la policy in due o più policy. Se superi la quota del numero di policy associate a un ruolo IAM, crea ruoli aggiuntivi e distribuisci le policy tra di essi per soddisfare la quota.
## Supporto aggiuntivo
Per un elenco dei problemi noti, consulta la pagina [GitHubWiki](https://github.com/aws/aws-parallelcluster/wiki) principale o la pagina [dei problemi](https://github.com/aws/aws-parallelcluster/issues). Per problemi più urgenti, contatta Supporto o apri un [nuovo GitHub problema](https://github.com/aws/aws-parallelcluster/issues).