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à.
# Scheduler supportati da AWS ParallelCluster
AWS ParallelCluster supporta diversi scheduler, impostati utilizzando l'[`scheduler`](cluster-definition.md#scheduler)impostazione.
**Nota**
A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso dei SGE nostri scheduler. Torque Puoi continuare a utilizzarli nelle versioni fino alla 2.11.4 inclusa, ma non sono idonei per futuri aggiornamenti o supporto per la risoluzione dei problemi da parte dei team di AWS assistenza e AWS supporto.
**Topics**
+ [Son of Grid Engine](schedulers.sge.md)
+ [Slurm Workload Manager](schedulers.slurm.md)
+ [Torque Resource Manager](schedulers.torque.md)
+ [AWS Batch](awsbatchcli.md)
# Son of Grid Engine (`sge`)
**Nota**
A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso dei nostri scheduler. SGE Torque Puoi continuare a utilizzarli nelle versioni fino alla 2.11.4 inclusa, ma non sono idonei per futuri aggiornamenti o supporto per la risoluzione dei problemi da parte dei team di AWS assistenza e AWS supporto.
AWS ParallelCluster le versioni 2.11.4 e precedenti utilizzano 8.1.9. Son of Grid Engine
# Slurm Workload Manager (`slurm`)
AWS ParallelCluster la versione 2.11.9 utilizza 20.11.9. Slurm Per informazioni su Slurm, consulta [https://slurm.schedmd.com/](https://slurm.schedmd.com/). Per i download, consulta [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags). Per il codice sorgente, consulta [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm).
**Importante**
AWS ParallelCluster viene testato con i parametri Slurm di configurazione, forniti di default. Qualsiasi modifica apportata a questi parametri di Slurm configurazione viene effettuata a proprio rischio. Sono supportati solo se possibile.
| AWS ParallelCluster versione (e) | Versione di Slurm supportata |
| --- | --- |
| 2.11.7, 2.11.8, 2.11.9 | 20,11,9 |
| da 2.11.4 a 2.11.6 | 20.11.8 |
| da 2.11.0 a 2.11.3 | 20.11.7 |
| 2,10,4 | 20,02,7 |
| da 2.9.0 a 2.10.3 | 20.02.4 |
| da 2.6 a 2.8.1 | 19,05,5 |
| 2.5.0, 2.5.1 | 19,05,3-2 |
| da 2.3.1 a 2.4.1 | 18,08,6-2 |
| prima della 2.3.1 | 16.05.3-1 |
# Modalità coda multipla
AWS ParallelCluster la versione 2.9.0 ha introdotto la modalità di coda multipla. La modalità a coda multipla è supportata quando [`scheduler`](cluster-definition.md#scheduler) è impostata `slurm` e l'[`queue_settings`](cluster-definition.md#queue-settings)impostazione è definita. Questa modalità consente la coesistenza di diversi tipi di istanze nei nodi di calcolo. Le risorse di calcolo che contengono i diversi tipi di istanza possono essere ridimensionate verso l'alto o verso il basso in base alle esigenze. [In modalità coda, sono supportate fino a cinque (5) code e ogni [`[queue]`sezione](queue-section.md) può fare riferimento a un massimo di tre (3) sezioni. `[compute_resource]`](compute-resource-section.md) Ciascuna di queste [`[queue]`sezioni](queue-section.md) è una partizione in. Slurm Workload Manager Per ulteriori informazioni, consultare [Slurmguida per la modalità a coda multipla](multiple-queue-mode-slurm-user-guide.md) e [Tutorial sulla modalità coda multipla](tutorial-mqm.md).
Ogni [`[compute_resource]`sezione](compute-resource-section.md) di una coda deve avere un tipo di istanza diverso e ciascuna di queste `[compute_resource]` è ulteriormente suddivisa in nodi statici e dinamici. I nodi statici per ciascuno `[compute_resource]` sono numerati da 1 al valore di. [`min_count`](compute-resource-section.md#compute-resource-min-count) I nodi dinamici per ciascuno `[compute_resource]` sono numerati da uno (1) a ([`max_count`](compute-resource-section.md#compute-resource-max-count)-`min_count`). Ad esempio, se `min_count` è 2 ed `max_count` è 10, i relativi nodi dinamici `[compute_resource]` sono numerati da uno (1) a otto (8). In qualsiasi momento, il numero di nodi dinamici in a può essere compreso tra zero (0) e il numero massimo di nodi dinamici. `[compute_resource]`
Le istanze che vengono lanciate nel parco di elaborazione vengono assegnate dinamicamente. Per facilitare la gestione, vengono generati nomi host per ogni nodo. Il formato del nome host è il seguente:
`$HOSTNAME=$QUEUE-$STATDYN-$INSTANCE_TYPE-$NODENUM`
+ `$QUEUE`è il nome della coda. Ad esempio, se la sezione inizia`[queue queue-name]`, "`$QUEUE`" è "*queue-name*».
+ `$STATDYN`è `st` per nodi statici o `dy` per nodi dinamici.
+ `$INSTANCE_TYPE`è il tipo di istanza per`[compute_resource]`, dall'[`instance_type`](compute-resource-section.md#compute-resource-instance-type)impostazione.
+ `$NODENUM`è il numero del nodo. `$NODENUM`è compreso tra uno (1) e il valore di [`min_count`](compute-resource-section.md#compute-resource-min-count) per i nodi statici e tra uno (1) e ([`max_count`](compute-resource-section.md#compute-resource-max-count)-`min_count`) per i nodi dinamici.
Sia i nomi host che i nomi di dominio completi (FQDN) vengono creati utilizzando zone ospitate di Amazon Route 53. [L'FQDN è`$HOSTNAME.$CLUSTERNAME.pcluster`, dove `$CLUSTERNAME` è il nome della sezione utilizzata per il cluster. `[cluster]`](cluster-definition.md)
Per convertire la configurazione in modalità coda, usa il comando. [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert) Scrive una configurazione aggiornata con una singola [`[queue]`sezione](queue-section.md) denominata`[queue compute]`. Quella coda contiene una singola [`[compute_resource]`sezione](compute-resource-section.md) `[compute_resource default]` denominata. [Le impostazioni `[queue compute]` e `[compute_resource default]` ha migrato dalla sezione specificata`[cluster]`.](cluster-definition.md)
# Slurmguida per la modalità a coda multipla
AWS ParallelCluster la versione 2.9.0 ha introdotto la modalità di coda multipla e una nuova architettura di scalabilità per (). Slurm Workload Manager Slurm
Le sezioni seguenti forniscono una panoramica generale sull'utilizzo di un Slurm cluster con la nuova architettura di scalabilità introdotta.
## Panoramica di
La nuova architettura di scalabilità si basa sulla Slurm [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) e sul plug-in per il risparmio energetico. Per ulteriori informazioni sul plug-in per il risparmio energetico, consulta la Guida al [risparmio Slurm energetico](https://slurm.schedmd.com/power_save.html). Nella nuova architettura, le risorse che possono essere potenzialmente rese disponibili per un cluster sono in genere predefinite nella Slurm configurazione come nodi cloud.
## Ciclo di vita dei nodi cloud
Durante il loro ciclo di vita, i nodi cloud entrano in diversi se non tutti i seguenti stati:`POWER_SAVING`, `POWER_UP` (`pow_up`), () e `ALLOCATED` (`alloc`). `POWER_DOWN` `pow_dn` In alcuni casi, un nodo cloud potrebbe entrare nello `OFFLINE` stato. L'elenco seguente descrive in dettaglio diversi aspetti di questi stati nel ciclo di vita del nodo cloud.
+ Un nodo in uno `POWER_SAVING` stato viene visualizzato con un `~` suffisso (ad esempio`idle~`) in. `sinfo` In questo stato, non esiste alcuna istanza EC2 che supporta il nodo. Tuttavia, Slurm può ancora allocare lavori al nodo.
+ Un nodo in transizione verso uno `POWER_UP` stato viene visualizzato con un `#` suffisso (ad esempio`idle#`) in. `sinfo`
+ Quando Slurm assegna un lavoro a un nodo in uno `POWER_SAVING` stato, il nodo si trasferisce automaticamente in uno stato. `POWER_UP` Altrimenti, i nodi possono essere posizionati manualmente nello `POWER_UP` stato utilizzando il `scontrol update nodename=nodename state=power_up` comando. In questa fase, `ResumeProgram` viene richiamato e le istanze EC2 vengono avviate e configurate per il backup di un nodo. `POWER_UP`
+ Un nodo attualmente disponibile per l'uso viene visualizzato senza alcun suffisso (ad esempio) in. `idle` `sinfo` Dopo che il nodo è stato configurato ed è entrato a far parte del cluster, diventa disponibile per l'esecuzione dei job. In questa fase, il nodo è configurato correttamente e pronto per l'uso. Come regola generale, consigliamo che il numero di istanze in EC2 sia uguale al numero di nodi disponibili. Nella maggior parte dei casi, i nodi statici sono sempre disponibili dopo la creazione del cluster.
+ Un nodo che sta passando a `POWER_DOWN` uno stato viene visualizzato con un `%` suffisso (ad esempio`idle%`) in. `sinfo` I nodi dinamici entrano automaticamente `POWER_DOWN` nello stato dopo. [`scaledown_idletime`](scaling-section.md#scaledown-idletime) Al contrario, i nodi statici nella maggior parte dei casi non vengono spenti. Tuttavia, i nodi possono essere posizionati manualmente nello `POWER_DOWN` stato utilizzando il `scontrol update nodename=nodename state=powering_down` comando. In questo stato, l'istanza associata a un nodo viene terminata e il nodo viene ripristinato allo `POWER_SAVING` stato per un utilizzo futuro successivo[`scaledown_idletime`](scaling-section.md#scaledown-idletime). L'`scaledown-idletime`impostazione viene salvata nella Slurm configurazione come `SuspendTimeout` impostazione.
+ Viene visualizzato un nodo offline con un `*` suffisso (ad esempio`down*`) dentro`sinfo`. Un nodo va offline se il Slurm controller non riesce a contattare il nodo o se i nodi statici sono disabilitati e le istanze di backup vengono terminate.
Consideriamo ora gli stati dei nodi mostrati nell'esempio seguente. `sinfo`
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4]
efa up infinite 1 idle efa-st-c5n18xlarge-1
gpu up infinite 1 idle% gpu-dy-g38xlarge-1
gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10]
ondemand up infinite 2 mix# ondemand-dy-c52xlarge-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot* up infinite 2 idle spot-st-t2large-[1-2]
```
I `efa-st-c5n18xlarge-1` nodi `spot-st-t2large-[1-2]` and dispongono già di istanze di backup configurate e sono disponibili per l'uso. I `ondemand-dy-c52xlarge-[1-2]` nodi sono nello `POWER_UP` stato attuale e dovrebbero essere disponibili entro pochi minuti. Il `gpu-dy-g38xlarge-1` nodo è nello `POWER_DOWN` stato e passerà `POWER_SAVING` allo stato successivo [`scaledown_idletime`](scaling-section.md#scaledown-idletime) (il valore predefinito è 120 secondi).
Tutti gli altri nodi sono in `POWER_SAVING` stato e non sono supportati da istanze EC2.
## Lavorare con un nodo disponibile
Un nodo disponibile è supportato da un'istanza EC2. Per impostazione predefinita, il nome del nodo può essere utilizzato per inserire direttamente SSH nell'istanza (ad esempio`ssh efa-st-c5n18xlarge-1`). L'indirizzo IP privato dell'istanza può essere recuperato utilizzando il `scontrol show nodes nodename` comando e controllando il `NodeAddr` campo. Per i nodi che non sono disponibili, il `NodeAddr` campo non deve puntare a un'istanza EC2 in esecuzione. Piuttosto, dovrebbe essere lo stesso del nome del nodo.
## Job stati e invio
I lavori inviati nella maggior parte dei casi vengono immediatamente assegnati ai nodi del sistema o messi in sospeso se tutti i nodi sono allocati.
Se i nodi allocati per un processo includono nodi in uno `POWER_SAVING` stato, il processo inizia con uno `CF` stato o. `CONFIGURING` A questo punto, il processo attende che i nodi dello stato passino allo `POWER_SAVING` `POWER_UP` stato e diventino disponibili.
Dopo che tutti i nodi allocati per un lavoro sono disponibili, il lavoro entra nello stato `RUNNING` (`R`).
Per impostazione predefinita, tutti i lavori vengono inviati alla coda predefinita (nota come partizione in). Slurm Ciò è indicato da un `*` suffisso dopo il nome della coda. È possibile selezionare una coda utilizzando l'opzione di invio del `-p` lavoro.
Tutti i nodi sono configurati con le seguenti funzionalità, che possono essere utilizzate nei comandi di invio dei lavori:
+ Un tipo di istanza (ad esempio`c5.xlarge`)
+ Un tipo di nodo (questo è `dynamic` o`static`.)
Puoi vedere tutte le funzionalità disponibili per un particolare nodo usando il `scontrol show nodes nodename` comando e controllando l'`AvailableFeatures`elenco.
Un'altra considerazione riguarda i posti di lavoro. Considerate innanzitutto lo stato iniziale del cluster, che potete visualizzare eseguendo il `sinfo` comando.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4]
efa up infinite 1 idle efa-st-c5n18xlarge-1
gpu up infinite 10 idle~ gpu-dy-g38xlarge-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot* up infinite 2 idle spot-st-t2large-[1-2]
```
Nota che `spot` è la coda predefinita. È indicata dal `*` suffisso.
Invia un lavoro a un nodo statico alla coda predefinita ()`spot`.
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
Invia un lavoro a un nodo dinamico della `EFA` coda.
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
Invia un lavoro a otto (8) `c5.2xlarge` nodi e due (2) `t2.xlarge` nodi alla `ondemand` coda.
```
$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"
```
Invia un lavoro a un nodo GPU della `gpu` coda.
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
Consideriamo ora lo stato dei lavori che utilizzano il `squeue` comando.
```
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-g38xlarge-1
7 spot wrap ubuntu R 2:48 1 spot-st-t2large-1
8 efa wrap ubuntu R 0:39 1 efa-dy-c5n18xlarge-1
```
I lavori 7 e 8 (nelle `efa` code `spot` e) sono già in esecuzione (`R`). I lavori 12 e 13 sono ancora in fase di configurazione (`CF`), probabilmente in attesa che le istanze diventino disponibili.
```
# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 3 idle~ efa-dy-c5n18xlarge-[2-4]
efa up infinite 1 mix efa-dy-c5n18xlarge-1
efa up infinite 1 idle efa-st-c5n18xlarge-1
gpu up infinite 1 mix~ gpu-dy-g38xlarge-1
gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10]
ondemand up infinite 10 mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot* up infinite 1 mix spot-st-t2large-1
spot* up infinite 1 idle spot-st-t2large-2
```
## Stato e caratteristiche del nodo
Nella maggior parte dei casi, gli stati dei nodi sono completamente gestiti in AWS ParallelCluster base ai processi specifici del ciclo di vita dei nodi cloud descritti in precedenza in questo argomento.
Tuttavia, sostituisce o termina AWS ParallelCluster anche nodi non integri in `DRAINED` stati `DOWN` e nodi con istanze di backup non integre. Per ulteriori informazioni, consulta [`clustermgtd`](processes.md#clustermgtd).
## Stati di partizione
AWS ParallelCluster supporta i seguenti stati di partizione. Una Slurm partizione è una coda in entrata. AWS ParallelCluster
+ `UP`: indica che la partizione è attiva. Questo è lo stato predefinito di una partizione. In questo stato, tutti i nodi della partizione sono attivi e disponibili per l'uso.
+ `INACTIVE`: indica che la partizione è inattiva. In questo stato, tutte le istanze che supportano i nodi di backup di una partizione inattiva vengono terminate. Non vengono avviate nuove istanze per i nodi in una partizione inattiva.
## avvio e arresto di pcluster
Quando [`pcluster stop`](pcluster.stop.md) viene eseguito, tutte le partizioni vengono posizionate nello `INACTIVE` stato e i AWS ParallelCluster processi mantengono le partizioni nello stato. `INACTIVE`
Quando [`pcluster start`](pcluster.start.md) viene eseguito, tutte le partizioni vengono inizialmente posizionate nello stato. `UP` Tuttavia, AWS ParallelCluster i processi non mantengono la partizione in uno `UP` stato. È necessario modificare manualmente lo stato delle partizioni. Tutti i nodi statici diventano disponibili dopo pochi minuti. Tieni presente che l'impostazione di una partizione su `UP` non attiva alcuna capacità dinamica. Se [`initial_count`](compute-resource-section.md#compute-resource-initial-count) è maggiore di[`max_count`](compute-resource-section.md#compute-resource-max-count), [`initial_count`](compute-resource-section.md#compute-resource-initial-count) potrebbe non essere soddisfatto quando lo stato della partizione viene modificato allo `UP` stato.
Quando [`pcluster start`](pcluster.start.md) e [`pcluster stop`](pcluster.stop.md) sono in esecuzione, è possibile verificare lo stato del cluster eseguendo il [`pcluster status`](pcluster.status.md) comando e controllando. `ComputeFleetStatus` Di seguito sono elencati gli stati possibili:
+ `STOP_REQUESTED`: La [`pcluster stop`](pcluster.stop.md) richiesta viene inviata al cluster.
+ `STOPPING`: il `pcluster` processo sta attualmente arrestando il cluster.
+ `STOPPED`: Il `pcluster` processo ha terminato il processo di arresto, tutte le partizioni sono in `INACTIVE` stato e tutte le istanze di calcolo sono terminate.
+ `START_REQUESTED`: La [`pcluster start`](pcluster.start.md) richiesta viene inviata al cluster.
+ `STARTING`: Il `pcluster` processo sta attualmente avviando il cluster
+ `RUNNING`: Il `pcluster` processo ha completato il processo di avvio, tutte le partizioni sono nello `UP` stato attuale e i nodi statici saranno disponibili dopo alcuni minuti.
## Controllo manuale delle code
In alcuni casi, potresti voler avere un certo controllo manuale sui nodi o sulla coda (nota come partizione inSlurm) in un cluster. È possibile gestire i nodi in un cluster tramite le seguenti procedure comuni.
+ Accendi i nodi dinamici in `POWER_SAVING` stato: esegui il `scontrol update nodename=nodename state=power_up` comando o invia una richiesta di `sleep 1` lavoro segnaposto per un determinato numero di nodi e affidati Slurm a questa opzione per attivare il numero richiesto di nodi.
+ Spegni prima i nodi dinamici[`scaledown_idletime`](scaling-section.md#scaledown-idletime): imposta i nodi dinamici su `DOWN` con il comando. `scontrol update nodename=nodename state=down` AWS ParallelCluster termina e ripristina automaticamente i nodi dinamici disattivati. In generale, non è consigliabile impostare i nodi per utilizzare `POWER_DOWN` direttamente il comando. `scontrol update nodename=nodename state=power_down` Questo perché gestisce AWS ParallelCluster automaticamente il processo di spegnimento. Non è necessario alcun intervento manuale. Pertanto, ti consigliamo di provare a impostare i nodi `DOWN` ogni volta che è possibile.
+ Disabilita una coda (partizione) o ferma tutti i nodi statici in una partizione specifica: imposta la coda in modo `INACTIVE` specifico con il comando. `scontrol update partition=queue name state=inactive` In questo modo si interrompono tutte le istanze che supportano i nodi nella partizione.
+ Abilita una coda (partizione): imposta la coda in modo specifico con il comando. `INACTIVE` `scontrol update partition=queue name state=up`
## Comportamento e regolazioni di ridimensionamento
Ecco un esempio del normale flusso di lavoro di ridimensionamento:
+ Lo scheduler riceve un lavoro che richiede due nodi.
+ Lo scheduler trasferisce due nodi in uno `POWER_UP` stato e chiama `ResumeProgram` con i nomi dei nodi (ad esempio). `queue1-dy-c5xlarge-[1-2]`
+ `ResumeProgram`avvia due istanze EC2 e assegna gli indirizzi IP e i nomi host privati di`queue1-dy-c5xlarge-[1-2]`, aspettando `ResumeTimeout` (il periodo predefinito è 60 minuti (1 ora)) prima di reimpostare i nodi.
+ Le istanze vengono configurate e si uniscono al cluster. Job inizia a essere eseguito su istanze.
+ Job è finito.
+ Al termine della configurazione `SuspendTime` (che è impostata su[`scaledown_idletime`](scaling-section.md#scaledown-idletime)), le istanze vengono inserite `POWER_SAVING` nello stato dallo scheduler. Lo scheduler `queue1-dy-c5xlarge-[1-2]` inserisce `POWER_DOWN` lo stato e chiama `SuspendProgram` con i nomi dei nodi.
+ `SuspendProgram`viene chiamato per due nodi. I nodi rimangono nello `POWER_DOWN` stato, ad esempio, rimanendo `idle%` per a `SuspendTimeout` (il periodo predefinito è 120 secondi (2 minuti)). Dopo aver `clustermgtd` rilevato che i nodi si stanno spegnendo, interrompe le istanze di backup. Quindi, si configura `queue1-dy-c5xlarge-[1-2]` in stato inattivo e reimposta l'indirizzo IP privato e il nome host in modo che possano essere riaccesi per lavori futuri.
Ora, se qualcosa va storto e un'istanza per un particolare nodo non può essere avviata per qualche motivo, succede quanto segue.
+ Scheduler riceve un lavoro che richiede due nodi.
+ Scheduler imposta `POWER_UP` lo stato di due nodi di cloud bursting e chiama `ResumeProgram` con i nomi dei nodi, (ad esempio). `queue1-dy-c5xlarge-[1-2]`
+ `ResumeProgram`avvia solo una (1) istanza EC2 e la configura`queue1-dy-c5xlarge-1`, ma non è riuscito ad avviare un'istanza per. `queue1-dy-c5xlarge-2`
+ `queue1-dy-c5xlarge-1`non sarà interessato e tornerà online dopo aver raggiunto lo stato. `POWER_UP`
+ `queue1-dy-c5xlarge-2`viene inserito in `POWER_DOWN` uno stato e il processo viene richiesto automaticamente perché Slurm rileva un errore del nodo.
+ `queue1-dy-c5xlarge-2`diventa disponibile dopo `SuspendTimeout` (l'impostazione predefinita è 120 secondi (2 minuti)). Nel frattempo, il processo viene richiesto e può iniziare a essere eseguito su un altro nodo.
+ Il processo precedente viene ripetuto finché il processo non può essere eseguito su un nodo disponibile senza che si verifichi un errore.
Esistono due parametri di temporizzazione che possono essere regolati se necessario.
+ `ResumeTimeout`(l'impostazione predefinita è 60 minuti (1 ora)): `ResumeTimeout` controlla il tempo di Slurm attesa prima di disattivare il nodo.
+ Potrebbe essere utile estendere questa impostazione se il processo di pre/post installazione richiede quasi così tanto tempo.
+ Questo è anche il tempo massimo di AWS ParallelCluster attesa prima di sostituire o resettare un nodo in caso di problemi. I nodi di calcolo si interrompono automaticamente se si verifica un errore durante l'avvio o la configurazione. Successivamente, AWS ParallelCluster i processi sostituiscono il nodo anche quando rileva che l'istanza è terminata.
+ `SuspendTimeout`(l'impostazione predefinita è 120 secondi (2 minuti)): `SuspendTimeout` controlla la velocità con cui i nodi vengono reinseriti nel sistema e pronti per l'uso.
+ Un valore più corto `SuspendTimeout` significherebbe che i nodi verranno ripristinati più rapidamente ed Slurm è in grado di provare ad avviare le istanze più frequentemente.
+ Un valore più lungo `SuspendTimeout` rende più lenta la reimpostazione dei nodi guasti. Nel frattempo, prova a Slurm usare altri nodi. Se `SuspendTimeout` dura più di qualche minuto, Slurm prova a scorrere ciclicamente tra tutti i nodi del sistema. Un periodo più lungo `SuspendTimeout` potrebbe essere utile per i sistemi su larga scala (oltre 1.000 nodi) per ridurre lo stress dovuto alla frequente ricoda dei Slurm lavori che falliscono.
+ Tieni presente che `SuspendTimeout` non si riferisce al tempo impiegato per terminare un'istanza AWS ParallelCluster di backup per un nodo. Le istanze di backup per `power down` i nodi vengono immediatamente terminate. Il processo di terminazione di solito termina in pochi minuti. Tuttavia, durante questo periodo, il nodo rimane nello stato di spegnimento e non è disponibile per l'uso nello scheduler.
## Registri per la nuova architettura
L'elenco seguente contiene i log delle chiavi per l'architettura a code multiple. Il nome del flusso di log utilizzato con Amazon CloudWatch Logs ha il formato `{hostname}.{instance_id}.{logIdentifier}` *logIdentifier* seguente i nomi di log. Per ulteriori informazioni, consulta [Integrazione con Amazon CloudWatch Logs](cloudwatch-logs.md).
+ `ResumeProgram`:
`/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`)
+ `SuspendProgram`:
`/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`)
+ `clustermgtd`:
`/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`)
+ `computemgtd`:
`/var/log/parallelcluster/computemgtd.log` (`computemgtd`)
+ `slurmctld`:
`/var/log/slurmctld.log` (`slurmctld`)
+ `slurmd`:
`/var/log/slurmd.log` (`slurmd`)
## Problemi comuni e modalità di debug:
**Nodi che non sono riusciti ad avviare, accendere o unirsi al cluster:**
+ Nodi dinamici:
+ Controlla il `ResumeProgram` registro per vedere se `ResumeProgram` è mai stato chiamato con il nodo. In caso contrario, controlla il `slurmctld` registro per determinare se hai Slurm mai provato a chiamare `ResumeProgram` con il nodo. Tieni presente che autorizzazioni errate `ResumeProgram` potrebbero causare l'interruzione automatica del programma.
+ Se `ResumeProgram` viene chiamato, controlla se è stata lanciata un'istanza per il nodo. Se l'istanza non può essere avviata, dovrebbe apparire un messaggio di errore chiaro sul motivo per cui l'istanza non è stata avviata.
+ Se è stata avviata un'istanza, è possibile che si sia verificato qualche problema durante il processo di bootstrap. Trova l'indirizzo IP privato e l'ID dell'istanza corrispondenti dal `ResumeProgram` registro e guarda i registri di bootstrap corrispondenti per l'istanza specifica in Logs. CloudWatch
+ Nodi statici:
+ Controlla il `clustermgtd` registro per vedere se sono state avviate istanze per il nodo. In caso contrario, dovrebbero esserci errori evidenti sul motivo per cui le istanze non sono state avviate.
+ Se è stata avviata un'istanza, c'è qualche problema durante il processo di bootstrap. Trova l'IP privato e l'ID dell'istanza corrispondenti dal `clustermgtd` registro e guarda i registri di bootstrap corrispondenti per l'istanza specifica in Logs. CloudWatch
**Nodi sostituiti o terminati in modo imprevisto, guasti dei nodi**
+ replaced/terminated Nodi in modo imprevisto
+ Nella maggior parte dei casi, `clustermgtd` gestisce tutte le azioni di manutenzione dei nodi. Per verificare se un nodo è stato `clustermgtd` sostituito o interrotto, controlla il `clustermgtd` registro.
+ Se il nodo è stato `clustermgtd` sostituito o terminato, dovrebbe apparire un messaggio che indica il motivo dell'azione. Se il motivo è legato allo scheduler (ad esempio, il nodo lo era`DOWN`), controlla il `slurmctld` registro per maggiori dettagli. Se il motivo è correlato a EC2, utilizza gli strumenti per controllare lo stato o i log di quell'istanza. Ad esempio, puoi verificare se l'istanza aveva eventi pianificati o se i controlli dello stato di integrità di EC2 non sono stati superati.
+ Se `clustermgtd` non ha terminato il nodo, controlla se ha `computemgtd` terminato il nodo o se EC2 ha terminato l'istanza per recuperare un'istanza Spot.
+ Guasti del nodo
+ Nella maggior parte dei casi, i lavori vengono richiesti automaticamente in caso di errore di un nodo. Esamina nel `slurmctld` registro il motivo per cui un job o un nodo non è riuscito e analizza la situazione da lì.
**Guasto durante la sostituzione o la chiusura delle istanze, errore durante lo spegnimento dei nodi**
+ In generale, `clustermgtd` gestisce tutte le azioni di terminazione previste dell'istanza. Guarda nel `clustermgtd` registro per vedere perché non è riuscito a sostituire o terminare un nodo.
+ Se i nodi dinamici non funzionano correttamente[`scaledown_idletime`](scaling-section.md#scaledown-idletime), guarda nel `SuspendProgram` registro per vedere se un programma utilizza il nodo specifico come argomento. `slurmctld` Note in realtà `SuspendProgram` non esegue alcuna azione specifica. Piuttosto, registra solo quando viene chiamato. La terminazione e il `NodeAddr` ripristino di tutte le istanze vengono completati da. `clustermgtd` Slurminserisce i nodi in `IDLE` after`SuspendTimeout`.
**Altri problemi**
+ AWS ParallelCluster non prende decisioni sull'allocazione del lavoro o sulla scalabilità. Tenta semplicemente di avviare, terminare e mantenere le risorse in base alle Slurm istruzioni fornite.
Per problemi relativi all'allocazione dei lavori, all'allocazione dei nodi e alla decisione sulla scalabilità, consulta il `slurmctld` registro per individuare eventuali errori.
# Torque Resource Manager (`torque`)
**Nota**
A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso dei nostri scheduler. SGE Torque Puoi continuare a utilizzarli nelle versioni fino alla 2.11.4 inclusa, ma non sono idonei per futuri aggiornamenti o supporto per la risoluzione dei problemi da parte dei team di AWS assistenza e AWS supporto.
AWS ParallelCluster le versioni 2.11.4 e precedenti utilizzano la 6.1.2. Torque Resource Manager Per ulteriori informazioni su Torque Resource Manager 6.1.2, consulta [http://docs.adaptivecomputing.com/torque/6-1-2/releaseNotes/torquerelnote.htm](http://docs.adaptivecomputing.com/torque/6-1-2/releaseNotes/torquerelnote.htm). Per la documentazione, consulta [http://docs.adaptivecomputing.com/torque/6-1-2/adminGuide/torque.htm](http://docs.adaptivecomputing.com/torque/6-1-2/adminGuide/torque.htm). Per il codice sorgente, consulta [https://github.com/adaptivecomputing/torque/tree/6.1.2](https://github.com/adaptivecomputing/torque/tree/6.1.2).
AWS ParallelCluster le versioni 2.4.0 e precedenti utilizzano 6.0.2. Torque Resource Manager Per le note di rilascio, consulta [http://docs.adaptivecomputing.com/torque/6-0-2/releaseNotes/torqueReleaseNotes6.0.2.pdf](http://docs.adaptivecomputing.com/torque/6-0-2/releaseNotes/torqueReleaseNotes6.0.2.pdf). Per la documentazione, consulta [http://docs.adaptivecomputing.com/torque/6-0-2/adminGuide/help.htm](http://docs.adaptivecomputing.com/torque/6-0-2/adminGuide/help.htm). Per il codice sorgente, consulta [https://github.com/adaptivecomputing/torque/tree/6.0.2](https://github.com/adaptivecomputing/torque/tree/6.0.2).
# AWS Batch (`awsbatch`)
Per informazioni su AWS Batch, vedere. [AWS Batch](https://aws.amazon.com/batch/) Per la documentazione, consulta la [Guida AWS Batch per l'utente](https://docs.aws.amazon.com/batch/latest/userguide/).
**AWS ParallelCluster Comandi CLI per AWS Batch**
Quando si utilizza lo `awsbatch` scheduler, i comandi AWS ParallelCluster CLI AWS Batch per vengono installati automaticamente nel nodo AWS ParallelCluster principale. La CLI utilizza le operazioni AWS Batch API e consente le seguenti operazioni:
+ Inviare e gestire attività
+ Monitorare attività, code e host
+ Creare una copia speculare dei comandi del pianificatore tradizionali
**Importante**
AWS ParallelCluster non supporta i lavori GPU per. AWS Batch Per ulteriori informazioni, consulta [GPU jobs](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub.md)
+ [`awsbstat`](awsbatchcli.awsbstat.md)
+ [`awsbout`](awsbatchcli_awsbout.md)
+ [`awsbkill`](awsbatchcli_awsbkill.md)
+ [`awsbqueues`](awsbatchcli_awsbqueues.md)
+ [`awsbhosts`](awsbatchcli_awsbhosts.md)
# `awsbsub`
Invia i lavori alla coda dei lavori del cluster.
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**Importante**
AWS ParallelCluster non supporta i lavori GPU per. AWS Batch Per ulteriori informazioni, consulta [GPU jobs](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
## Argomenti posizionali
***command***
Invia il lavoro (il comando specificato deve essere disponibile nelle istanze di calcolo) o il nome del file da trasferire. Consulta anche `--command-file`.
**arguments**
(Facoltativo) Specifica argomenti per il comando o il file di comando.
## Argomenti designati
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
I nomi del processo. Il primo carattere deve essere una lettera o un numero. Il nome del lavoro può contenere lettere (sia maiuscole che minuscole), numeri, trattini e caratteri di sottolineatura e avere una lunghezza massima di 128 caratteri.
**-c *CLUSTER*, --cluster *CLUSTER***
Specifica il cluster da utilizzare.
**-cf, --command-file**
Indica che il comando è un file da trasferire nelle istanze di calcolo.
Impostazione predefinita: False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
Specifica la cartella da utilizzare come directory di lavoro del processo. Se non viene specificata una directory di lavoro, il processo viene eseguito nella `job-` sottocartella della home directory dell'utente. Puoi usare questo parametro o il parametro `--parent-working-dir`.
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
Speciifica la cartella principale della directory di lavoro del lavoro. Se non viene specificata una directory di lavoro principale, per impostazione predefinita è la home directory dell'utente. Una sottocartella denominata `job-` viene creata nella directory di lavoro padre. Puoi usare questo parametro o il parametro `--working-dir`.
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
Specifica il file da trasferire alle istanze di calcolo, nella directory di lavoro del processo. È possibile specificare più parametri di file di input.
**-p *VCPUS*, --vcpus *VCPUS***
Speciifica il numero di v CPUs da riservare per il contenitore. Se usato insieme a`–nodes`, identifica il numero di v CPUs per ogni nodo.
Impostazione predefinita: 1
**-m *MEMORY*, --memory *MEMORY***
Specifica il limite di memoria fisico (in MiB) da fornire per il processo. Se il lavoro tenta di superare il limite di memoria specificato qui, il lavoro viene terminato.
Impostazione predefinita: 128
**-e *ENV*, --env *ENV***
Specifica un elenco separato da virgola di nomi delle variabili di ambiente da esportare nell'ambiente dei processi. Per esportare tutte le variabili di ambiente, specifica “all”. Tieni presente che un elenco di «tutte» le variabili di ambiente non include quelle elencate nel `–env-blacklist` parametro o le variabili che iniziano con il `AWS_*` prefisso `PCLUSTER_*` o.
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
Specifica un elenco separato da virgole di nomi di variabili di ambiente da **non** esportare nell’ambiente dei processi. Per impostazione predefinita, `HOME`, `PWD`, `USER`, `PATH`, `LD_LIBRARY_PATH`, `TERM` e `TERMCAP` non vengono esportate.
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
Speciifica il numero di volte in cui un lavoro deve essere spostato. `RUNNABLE` Puoi specificare da 1 a 10 tentativi. Se il valore dei tentativi è maggiore di 1, il processo viene riprovato se fallisce, finché non passa a uno `RUNNABLE` stato per il numero di volte specificato.
Impostazione predefinita: 1
**-t *TIMEOUT*, --timeout *TIMEOUT***
Speciifica la durata in secondi (misurata in base al `startedAt` timestamp del tentativo di lavoro) dopo la quale AWS Batch termina il lavoro se non è stato completato. Il valore di timeout deve essere almeno di 60 secondi.
**-n *NODES*, --nodes *NODES***
Specifica il numero di nodi da prenotare per il processo. Specificate un valore per questo parametro per abilitare l'invio parallelo multinodo.
I lavori paralleli multinodo non sono supportati quando il [`cluster_type`](cluster-definition.md#cluster-type) parametro è impostato `spot` su.
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
Indica le dimensioni dell’array. Puoi specificare un valore compreso tra 2 e 10.000. Se specifichi proprietà dell'array per un processo, diventa un processo in array.
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
Specifica un elenco separato da punti e virgola di dipendenze per un processo. Un processo può dipendere da un massimo di 20 processi. È possibile specificare una dipendenza dal `SEQUENTIAL` tipo senza specificare un ID di lavoro per i lavori di array. Una dipendenza sequenziale consente a ogni processo in array figlio di terminare sequenzialmente, partendo dall’indice 0. Puoi anche specificare una dipendenza tipo N\$1TO\$1N con un ID processo per processi in array. Una dipendenza N\$1TO\$1N significa che ogni figlio nell'indice di questo processo deve attendere il completamento del figlio nell'indice corrispondente di ciascuna dipendenza prima di iniziare. La sintassi di questo parametro è «jobID=**, type=**;...».
# `awsbstat`
Mostra i processi che vengono inviati nella coda di processi del cluster.
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## Argomenti posizionali
***job\$1ids***
Specifica l'elenco dei job separati da spazi da mostrare nell'output. IDs Se il lavoro è un array di attività, vengono visualizzate tutte le attività figlio. Se è richiesto un singolo processo, viene visualizzato in una versione dettagliata.
## Argomenti designati
**-c *CLUSTER*, --cluster *CLUSTER***
Indica il cluster da utilizzare.
**-s *STATUS*, --status *STATUS***
Specifica un elenco separato da virgole di stati del processo da includere. Lo stato del processo predefinito è "active". I valori accettati sono: `SUBMITTED`, `PENDING`, `RUNNABLE`, `STARTING`, `RUNNING`, `SUCCEEDED`, `FAILED` e `ALL`.
Impostazione predefinita: “`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`”
**-e, --expand-children**
Espande i processi con figli (array e parallelo a più nodi).
Impostazione predefinita: False
**-d, --details**
Mostra i dettagli dei processi.
Impostazione predefinita: False
# `awsbout`
Mostra l'output di un determinato processo.
```
awsbout [ - h ] [ - c CLUSTER ] [ - hd HEAD ] [ - t TAIL ] [ - s ] [ - sp STREAM_PERIOD ] job_id
```
## Argomenti posizionali
***job\$1id***
Specifica l’ID processo.
## Argomenti designati
**-c *CLUSTER*, --cluster *CLUSTER***
Indica il cluster da utilizzare.
**-hd *HEAD*, --head *HEAD***
Ottiene le prime *HEAD* righe dell'output del lavoro.
**-t *TAIL*, --tail *TAIL***
Ottiene le ultime righe dell’output del processo.
**-s, --stream**
Ottiene l'output del processo, quindi attende che venga generato output aggiuntivo. Questo argomento può essere utilizzato insieme a -tail per iniziare dalle ultime righe dell’output del processo.
Impostazione predefinita: False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
Imposta il periodo di streaming.
Impostazione predefinita: 5
# `awsbkill`
Annulla o termina i processi inviati nel cluster.
```
awsbkill [ - h ] [ - c CLUSTER ] [ - r REASON ] job_ids [ job_ids ... ]
```
## Argomenti posizionali
***job\$1ids***
Specifica l'elenco dei processi separati da spazi da annullare o IDs terminare.
## Argomenti designati
**-c *CLUSTER*, --cluster *CLUSTER***
Indica il nome del cluster da utilizzare.
**-r *REASON*, --reason *REASON***
Indica il messaggio da collegare a un processo, spiegando il motivo per annullarlo.
Impostazione predefinita: “Terminated by the user”
# `awsbqueues`
Mostra la coda dei processi associata al cluster.
```
awsbqueues [ - h ] [ - c CLUSTER ] [ - d ] [ job_queues [ job_queues ... ]]
```
## Argomenti posizionali
***job\$1queues***
Specifica l’elenco separato da spazi di nomi delle code da visualizzare. Se è richiesta una singola coda, viene mostrata in una versione dettagliata.
## Argomenti denominati
**-c *CLUSTER*, --cluster *CLUSTER***
Specifica il nome del cluster da utilizzare.
**-d, --details**
Indica se visualizzare i dettagli delle code.
Impostazione predefinita: False
# `awsbhosts`
Mostra gli host che appartengono all'ambiente di calcolo del cluster.
```
awsbhosts [ - h ] [ - c CLUSTER ] [ - d ] [ instance_ids [ instance_ids ... ]]
```
## Argomenti posizionali
***instance\$1ids***
Specifica un elenco di istanze separate da spazi. IDs Se è richiesta un’istanza singola, viene mostrata in una versione dettagliata.
## Argomenti designati
**-c *CLUSTER*, --cluster *CLUSTER***
Specifica il nome del cluster da utilizzare.
**-d, --details**
Indica se mostrare i dettagli degli host.
Impostazione predefinita: False