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 supporti Slurm e AWS Batch pianificatori, che vengono impostati utilizzando l'impostazione. [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) I seguenti argomenti descriveranno ogni scheduler e come utilizzarli.
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [Utilizzo dello scheduler AWS Batch (`awsbatch`) con AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## Dimensione e aggiornamento della capacità del cluster
La capacità del cluster è definita dal numero di nodi di calcolo scalabili dal cluster. I nodi di calcolo sono supportati da istanze Amazon EC2 definite all'interno delle risorse di calcolo nella `(Scheduling/SlurmQueues/`ComputeResources`)` configurazione e sono organizzati in AWS ParallelCluster `(Scheduling/SlurmQueues)` code che mappano 1:1 alle partizioni. Slurm
[All'interno di una risorsa di elaborazione è possibile configurare il numero minimo di nodi di calcolo (istanze) che devono essere sempre mantenuti in esecuzione nel cluster () e il numero massimo di istanze fino a cui la risorsa di calcolo può scalare (3`MinCount`). `MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
Al momento della creazione del cluster o dopo un aggiornamento del cluster, AWS ParallelCluster avvia tutte le istanze Amazon EC2 configurate per ogni risorsa di calcolo `Scheduling/SlurmQueues/ ComputeResources` () definita `MinCount` nel cluster. ***Le istanze avviate per coprire il numero minimo di nodi per le risorse di calcolo nel cluster sono chiamate nodi statici.*** Una volta avviati, i nodi statici sono pensati per essere persistenti nel cluster e non vengono terminati dal sistema, a meno che non si verifichi un evento o una condizione particolare. Tali eventi includono, ad esempio, il fallimento dei controlli di Slurm integrità di Amazon EC2 e la modifica dello stato del Slurm nodo in DRAIN o DOWN.
***Le istanze Amazon EC2, nell'intervallo da 1 `1` a `‘MaxCount - MinCount’` (`MaxCount `*meno*)` MinCount)`, lanciate su richiesta per far fronte all'aumento del carico del cluster, sono denominate nodi dinamici.*** La loro natura è effimera, vengono avviate per eseguire lavori in sospeso e vengono terminate quando rimangono inattive per un periodo di tempo definito `Scheduling/SlurmSettings/ScaledownIdletime` nella configurazione del cluster (impostazione predefinita: 10 minuti).
I nodi statici e i nodi dinamici sono conformi al seguente schema di denominazione:
+ Nodi statici dove `-st--` ` = 1..ComputeResource/MinCount`
+ Nodi dinamici `-dy--` dove ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Ad esempio, data la seguente AWS ParallelCluster configurazione:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
I seguenti nodi verranno definiti in Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Quando una risorsa di elaborazione lo ha`MinCount == MaxCount`, tutti i nodi di calcolo corrispondenti saranno statici e tutte le istanze verranno avviate al creation/update momento del cluster e mantenute attive e funzionanti. Esempio:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Aggiornamento della capacità del cluster
L'aggiornamento della capacità del cluster include l'aggiunta o la rimozione di code, risorse di elaborazione o la modifica `MinCount/MaxCount` di una risorsa di elaborazione. A partire dalla AWS ParallelCluster versione 3.9.0, la riduzione delle dimensioni di una coda richiede che il parco di elaborazione venga interrotto o [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)impostato su TERMINATE prima dell'aggiornamento del cluster. Non è necessario interrompere la flotta di elaborazione o impostare su TERMINATE quando: [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)
+ Aggiungere nuove code a Scheduling/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Aggiungere nuove risorse di calcolo a una coda `Scheduling/SlurmQueues/ComputeResources`
+ Aumento della potenza `MaxCount` di una risorsa di elaborazione
+ Aumento MinCount di una risorsa di elaborazione e aumento MaxCount della stessa risorsa di elaborazione almeno della stessa quantità
## Considerazioni e limitazioni
Questa sezione ha lo scopo di delineare eventuali fattori, vincoli o limitazioni importanti da tenere in considerazione durante il ridimensionamento della capacità del cluster.
+ Quando si rimuove una coda da `Scheduling/SlurmQueues` tutti i nodi di elaborazione con nome`-*`, sia statici che dinamici, verrà rimossa dalla Slurm configurazione e le istanze Amazon EC2 corrispondenti verranno terminate.
+ Quando si rimuove una risorsa di calcolo `Scheduling/SlurmQueues/ComputeResources` da una coda, tutti i nodi di calcolo con nome`-*--*`, statici e dinamici, verranno rimossi dalla Slurm configurazione e le istanze Amazon EC2 corrispondenti verranno terminate.
Quando si modifica il `MinCount` parametro di una risorsa di calcolo, possiamo distinguere due diversi scenari, se `MaxCount` viene mantenuto uguale a `MinCount` (solo capacità statica) e se `MaxCount` è maggiore `MinCount` di (capacità statica e dinamica mista).
### La capacità cambia solo con nodi statici
+ Se`MinCount == MaxCount`, aumentando `MinCount` (e`MaxCount`), il cluster verrà configurato estendendo il numero di nodi statici al nuovo valore di `MinCount` `-st--` e il sistema continuerà a provare ad avviare istanze Amazon EC2 per soddisfare la nuova capacità statica richiesta.
+ Se`MinCount == MaxCount`, diminuendo `MinCount` (e`MaxCount`) la quantità N, il cluster verrà configurato rimuovendo gli ultimi N nodi statici `-st--...]` e il sistema interromperà le istanze Amazon EC2 corrispondenti.
+ Stato iniziale `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento `-30` su `MinCount` e `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Modifiche di capacità con nodi misti
Se`MinCount < MaxCount`, aumentando `MinCount` di un valore N (supponendo che `MaxCount` venga mantenuto invariato), il cluster verrà configurato estendendo il numero di nodi statici al nuovo valore di `MinCount` (`old_MinCount + N`): `-st--` e il sistema continuerà a provare ad avviare istanze Amazon EC2 per soddisfare la nuova capacità statica richiesta. Inoltre, per rispettare la `MaxCount` capacità della risorsa di elaborazione, la configurazione del cluster viene aggiornata *rimuovendo gli ultimi N nodi dinamici* `-dy--[...]` e il sistema interromperà le istanze Amazon EC2 corrispondenti.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiorna \$130 a `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se`MinCount < MaxCount`, aumentando `MinCount` e `MaxCount` della stessa quantità N, il cluster verrà configurato estendendo il numero di nodi statici al nuovo valore di `MinCount` (`old_MinCount + N`): `-st--` e il sistema continuerà a provare ad avviare istanze Amazon EC2 per soddisfare la nuova capacità statica richiesta. Inoltre, non verrà apportata alcuna modifica al numero di nodi dinamici per rispettare il nuovo
`MaxCount` value.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiorna \$130 a `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se`MinCount < MaxCount`, diminuendo la `MinCount` quantità N (supponendo che `MaxCount` venga mantenuta invariata), il cluster verrà configurato rimuovendo gli ultimi N nodi statici dei nodi statici `-st--[...` e il sistema interromperà le istanze Amazon EC2 corrispondenti. Inoltre, per rispettare la `MaxCount` capacità della risorsa di elaborazione, la configurazione del cluster viene aggiornata estendendo il numero di nodi dinamici per colmare il divario. `MaxCount - new_MinCount: -dy--[1..]` In questo caso, trattandosi di nodi dinamici, non verranno lanciate nuove istanze Amazon EC2 a meno che lo scheduler non abbia lavori in sospeso sui nuovi nodi.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento -30 su `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se`MinCount < MaxCount`, in diminuzione `MinCount` e `MaxCount` della stessa quantità N, il cluster verrà configurato rimuovendo gli ultimi N nodi statici `-st--...]` e il sistema interromperà le istanze Amazon EC2 corrispondenti.
Inoltre, non verrà apportata alcuna modifica al numero di nodi dinamici per rispettare il nuovo valore. `MaxCount`
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento -30 su `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se`MinCount < MaxCount`, diminuendo la `MaxCount` quantità N (supponendo `MinCount` che venga mantenuta invariata), il cluster verrà configurato rimuovendo gli ultimi N nodi dinamici `-dy--]` e il sistema interromperà le istanze Amazon EC2 corrispondenti nel caso in cui fossero in esecuzione. Non è previsto alcun impatto sui nodi statici.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento -30 su `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impatti sui lavori
In tutti i casi in cui i nodi vengono rimossi e le istanze Amazon EC2 terminate, un job sbatch in esecuzione sui nodi rimossi verrà nuovamente messo in coda, a meno che non vi siano altri nodi che soddisfino i requisiti del processo. In quest'ultimo caso, il processo ha esito negativo con lo stato NODE\$1FAIL e scompare dalla coda e deve essere inviato nuovamente manualmente.
Se si prevede di eseguire un aggiornamento per il ridimensionamento del cluster, è possibile impedire l'esecuzione dei lavori nei nodi che verranno rimossi durante l'aggiornamento pianificato. Ciò è possibile impostando i nodi da rimuovere durante la manutenzione. Tieni presente che l'impostazione di un nodo in manutenzione non influirebbe sui lavori che alla fine sono già in esecuzione nel nodo.
Supponiamo che con l'aggiornamento pianificato per il ridimensionamento del cluster si voglia rimuovere il nodo`qeueu-st-computeresource-[9-10`]. È possibile creare una Slurm prenotazione con il seguente comando
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Questo creerà una Slurm prenotazione denominata `maint_for_update` sui nodi`qeueu-st-computeresource-[9-10]`. Dal momento in cui viene creata la prenotazione, non è possibile eseguire altri lavori nei nodi`qeueu-st-computeresource-[9-10]`. Tieni presente che la prenotazione non impedirà l'assegnazione finale dei lavori sui nodi`qeueu-st-computeresource-[9-10]`.
Dopo l'aggiornamento del ridimensionamento del cluster, se la Slurm prenotazione è stata impostata solo sui nodi che sono stati rimossi durante l'aggiornamento del ridimensionamento, la prenotazione di manutenzione verrà automaticamente eliminata. Se invece hai creato una Slurm prenotazione sui nodi che sono ancora presenti dopo l'aggiornamento del ridimensionamento del cluster, potremmo voler rimuovere la prenotazione di manutenzione sui nodi dopo l'esecuzione dell'aggiornamento di ridimensionamento, utilizzando il seguente comando
```
sudo -i scontrol delete ReservationName=maint_for_update
```
[Per ulteriori dettagli sulla Slurm prenotazione, consulta il documento ufficiale di SchedMD qui.](https://slurm.schedmd.com/reservations.html)
## Processo di aggiornamento del cluster in caso di modifiche alla capacità
In caso di modifica della configurazione dello scheduler, durante il processo di aggiornamento del cluster vengono eseguiti i seguenti passaggi:
+ Interrompi AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Genera una configurazione aggiornata Slurm delle partizioni dalla AWS ParallelCluster configurazione
+ Riavvio `slurmctld` (eseguito tramite la ricetta del servizio Chef)
+ Controlla `slurmctld` lo stato `(systemctl is-active --quiet slurmctld.service)`
+ Ricarica la configurazione Slurm `(scontrol reconfigure)`
+ Avvia `clustermgtd (supervisorctl start clustermgtd)`
Per informazioni su Slurm, consulta [https://slurm.schedmd.com](https://slurm.schedmd.com). Per i download, vedi [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags). [Per il codice sorgente, vedi slurm. https://github.com/SchedMD/](https://github.com/SchedMD/slurm)
## Versioni cluster e SLURM supportate
Nella tabella seguente sono elencate le Slurm versioni AWS ParallelCluster e supportate AWS .
| AWS ParallelCluster versione (e) | Versione di Slurm supportata |
| --- | --- |
| 3.13.0 | 24,05,07 |
| 3.12.0 | 23,11,10 |
| 3.11.0 | 23,11,10 |
| 3.9.2, 3.9.3, 3.10.0 | 23,11,7 |
| 3,9,0, 3,9,1 | 23,11,4 |
| 3.8.0 | 23,02,7 |
| 3.7.2 | 23,02,6 |
| 3.7.1 | 23,02,5 |
| 3.7.0 | 23,02,4 |
| 3.6.0, 3.6.1 | 23,02,2 |
| 3,5,0, 3,5,1 | 22,05,8 |
| 3.4.0, 3.4.1 | 22,05-7 |
| 3.3.0, 3.3.1 | 22,05,5 |
| 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21,08,8-2 |
| 3.1.2, 3.1.3 | 21,08,6 |
| 3.1.1 | 21,08,5 |
| 3.0.0 | 20,11,8 |
**Topics**
+ [Dimensione e aggiornamento della capacità del cluster](#cluster-capacity-size-and-update)
+ [Aggiornamento della capacità del cluster](#cluster-capacity-update)
+ [Considerazioni e limitazioni](#considerations-limitations)
+ [Impatti sui lavori](#impacts-on-jobs)
+ [Processo di aggiornamento del cluster in caso di modifiche alla capacità](#cluster-update-process)
+ [Versioni cluster e SLURM supportate](#cluster-slurm-version-table)
+ [Configurazione di più code](configuration-of-multiple-queues-v3.md)
+ [Slurmguida per la modalità a coda multipla](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm modalità protetta dal cluster](slurm-protected-mode-v3.md)
+ [Slurmfailover rapido con capacità insufficiente del cluster](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm pianificazione basata sulla memoria](slurm-mem-based-scheduling-v3.md)
+ [Allocazione di più tipi di istanza con Slurm](slurm-multiple-instance-allocation-v3.md)
+ [Scalabilità del cluster per nodi dinamici](scheduler-node-allocation-v3.md)
+ [Slurmcontabilità con AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm personalizzazione della configurazione](slurm-configuration-settings-v3.md)
+ [Slurm e `prolog` `epilog`](slurm-prolog-epilog-v3.md)
+ [Dimensioni e aggiornamento della capacità del cluster](slurm-cluster-capacity-size-and-update.md)
# Configurazione di più code
Con AWS ParallelCluster la versione 3, è possibile configurare più code impostando `slurm` e specificando più di una coda nel file di [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) configurazione. [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) In questa modalità, coesistono diversi tipi di istanza nei nodi di calcolo specificati nella [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) sezione del file di configurazione. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)con tipi di istanze diversi vengono ridimensionati verso l'alto o verso il basso in base alle esigenze di. [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
Le *code* multiple all'interno di un singolo cluster sono generalmente preferite rispetto a più cluster quando i carichi di lavoro condividono la stessa infrastruttura e le stesse risorse sottostanti (come storage condiviso, rete o nodi di accesso). Se i carichi di lavoro hanno esigenze di elaborazione, archiviazione e rete simili, l'utilizzo di più code all'interno di un singolo cluster è più efficiente perché consente la condivisione delle risorse ed evita inutili duplicazioni. Questo approccio semplifica la gestione e riduce il sovraccarico, pur consentendo una pianificazione efficiente dei lavori e l'allocazione delle risorse. D'altra parte, è necessario utilizzare più *cluster* quando vi sono forti requisiti di sicurezza, dati o isolamento operativo tra i carichi di lavoro. Ad esempio, se è necessario gestire e gestire i carichi di lavoro in modo indipendente, con pianificazioni, cicli di aggiornamento o politiche di accesso diversi, i cluster multipli sono più appropriati.
**Quote di risorse di calcolo e coda dei cluster**
| Risorsa | Quota |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 50 code per cluster |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 50 risorse di elaborazione per coda 50 risorse di elaborazione per cluster |
**Numero di nodi**
Ogni risorsa di calcolo inserita in [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)una coda deve avere un valore univoco [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name), [`InstanceType`[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), e. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)e [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)hanno valori predefiniti che definiscono l'intervallo di istanze di una risorsa di calcolo in [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)una coda. Puoi anche specificare i tuoi valori per e. [`MinCount`[`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) Ogni risorsa di elaborazione in [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)è composta da nodi statici numerati da 1 al valore di [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)e nodi dinamici numerati dal valore di [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)al valore di. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
**Configurazione di esempio**
Di seguito è riportato un esempio di sezione [Scheduling](Scheduling-v3.md) per un file di configurazione del cluster. In questa configurazione ci sono due code denominate `queue1` `queue2` e ciascuna di esse ha un valore specifico [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources). [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**Nomi host**
Le istanze che vengono lanciate nel parco di elaborazione vengono assegnate dinamicamente. I nomi host vengono generati per ogni nodo. Per impostazione predefinita, AWS ParallelCluster utilizzerà il seguente formato del nome host:
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE`è il nome della coda. Ad esempio, se la [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)sezione ha una voce [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name)impostata su «`queue-name`», allora «`$QUEUE`» è «`queue-name`».
+ `$STATDYN`è `st` per nodi statici o `dy` per nodi dinamici.
+ `$COMPUTE_RESOURCE`è la risorsa [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)di [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)calcolo corrispondente a questo nodo.
+ `$NODENUM`è il numero del nodo. `$NODENUM`è compreso tra uno (1) e il valore di [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)per i nodi statici e tra uno (1) e [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)- [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)per i nodi dinamici.
Dal file di configurazione di esempio riportato sopra, un determinato nodo `queue1` e una risorsa di calcolo `c5xlarge` hanno un nome host:. `queue1-dy-c5xlarge-1`
Sia i nomi host che i nomi di dominio completi (FQDN) vengono creati utilizzando le zone ospitate di Amazon Route 53. L'FQDN è`$HOSTNAME.$CLUSTERNAME.pcluster`, dov'è `$CLUSTERNAME` il nome del cluster.
Nota che lo stesso formato verrà utilizzato anche per i nomi dei Slurm nodi.
Gli utenti possono scegliere di utilizzare il EC2 nome host Amazon predefinito dell'istanza che alimenta il nodo di calcolo anziché il formato del nome host predefinito utilizzato da. AWS ParallelCluster Questo può essere fatto impostando il [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)parametro su true. Tuttavia, i nomi dei Slurm nodi continueranno a utilizzare il AWS ParallelCluster formato predefinito.
# Slurmguida per la modalità a coda multipla
Qui puoi scoprire come AWS ParallelCluster e Slurm gestire i nodi di coda (partizione) e come monitorare la coda e lo stato dei nodi.
## Panoramica di
L'architettura di scalabilità si basa sulla [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) e sul Slurm 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). Nell'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, nessuna istanza EC2 esegue il backup del 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` Un nodo passa automaticamente a uno `POWER_UP` stato, quando Slurm assegna un lavoro a un nodo in uno stato. `POWER_SAVING`
In alternativa, puoi trasferire manualmente i nodi allo `POWER_UP` stato come utente `su` root con il comando:
```
$ scontrol update nodename=nodename state=power_up
```
In questa fase, `ResumeProgram` viene richiamato, le istanze EC2 vengono avviate e configurate e il nodo passa allo stato. `POWER_UP`
+ **Un nodo attualmente disponibile per l'uso viene** visualizzato senza un 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 Amazon EC2 sia uguale al numero di nodi disponibili. Nella maggior parte dei casi, i nodi statici sono 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 nello `POWER_DOWN` stato successivo. [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) Al contrario, i nodi statici nella maggior parte dei casi non vengono spenti. Tuttavia, puoi posizionare i nodi nello `POWER_DOWN` stato manualmente come utente `su` root con il comando:
```
$ scontrol update nodename=nodename state=down reason="manual draining"
```
In questo stato, le istanze associate a un nodo vengono terminate e il nodo viene ripristinato allo `POWER_SAVING` stato e può essere utilizzato successivamente. [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)
L'[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)impostazione viene salvata nell'impostazione di Slurm configurazione`SuspendTimeout`.
+ Viene visualizzato **un nodo offline** con un `*` suffisso (ad esempio`down*`) in`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.
Considerate gli stati dei nodi mostrati nell'esempio seguente. `sinfo`
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 idle% gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
I `efa-st-efacompute1-1` nodi `spot-st-spotcompute2-[1-2]` and dispongono già di istanze di backup configurate e sono disponibili per l'uso. I `ondemand-dy-ondemandcompute1-[1-2]` nodi sono nello `POWER_UP` stato attuale e dovrebbero essere disponibili entro pochi minuti. Il `gpu-dy-gpucompute1-1` nodo è nello `POWER_DOWN` stato e passa allo `POWER_SAVING` stato successivo [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)(il valore predefinito è 10 minuti).
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 Amazon EC2. Per impostazione predefinita, il nome del nodo può essere utilizzato per inserire direttamente SSH nell'istanza (ad esempio`ssh efa-st-efacompute1-1`). L'indirizzo IP privato dell'istanza può essere recuperato utilizzando il comando:
```
$ scontrol show nodes nodename
```
Controlla l'indirizzo IP nel `NodeAddr` campo restituito.
Per i nodi che non sono disponibili, il `NodeAddr` campo non deve puntare a un'istanza Amazon 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 `POWER_SAVING` stato passino allo `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 le caratteristiche di un particolare nodo usando il comando:
```
$ scontrol show nodes nodename
```
Nel ritorno, controlla l'`AvailableFeatures`elenco.
Considera lo stato iniziale del cluster, che puoi visualizzare eseguendo il `sinfo` comando.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
Nota che `spot` è la coda predefinita. È indicata dal `*` suffisso.
Invia un lavoro a un nodo statico nella coda predefinita ()`spot`.
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
Invia un lavoro a un nodo dinamico nella `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 nella `ondemand` coda.
```
$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"
```
Invia un lavoro a un nodo GPU nella `gpu` coda.
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
Considerate 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-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1
7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1
8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-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-efacompute1-[2-4]
efa up infinite 1 mix efa-dy-efacompute1-1
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 mix~ gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 1 mix spot-st-spotcompute2-1
spot* up infinite 1 idle spot-st-spotcompute2-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-v3.md#clustermgtd-v3).
## 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 è in uno stato attivo. 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.
## pcluster update-compute-fleet
+ **Arresto del parco di calcolo**: quando viene eseguito il comando seguente, tutte le partizioni passano `INACTIVE` allo stato e i AWS ParallelCluster processi mantengono le partizioni nello stato. `INACTIVE`
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status STOP_REQUESTED
```
+ **Avvio del parco di calcolo**: quando viene eseguito il comando seguente, tutte le partizioni passano inizialmente allo stato. `UP` Tuttavia, AWS ParallelCluster i processi non mantengono la partizione in uno stato. `UP` È 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.
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status START_REQUESTED
```
Quando `update-compute-fleet` viene eseguito, è possibile verificare lo stato del cluster eseguendo il `pcluster describe-compute-fleet` comando e controllando il`Status`. Di seguito sono elencati gli stati possibili:
+ `STOP_REQUESTED`: La richiesta di stop compute fleet viene inviata al cluster.
+ `STOPPING`: Il `pcluster` processo sta attualmente interrompendo la flotta di elaborazione.
+ `STOPPED`: Il `pcluster` processo ha terminato il processo di arresto, tutte le partizioni sono in `INACTIVE` stato attivo e tutte le istanze di calcolo sono terminate.
+ `START_REQUESTED`: La richiesta di avvio della flotta di calcolo 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 sono disponibili dopo alcuni minuti.
+ `PROTECTED`: Questo stato indica che alcune partizioni presentano errori di bootstrap consistenti. Le partizioni interessate sono inattive. Esamina il problema e poi corri `update-compute-fleet` a riattivare la flotta.
## Controllo manuale delle code
In alcuni casi, potresti voler avere un 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 utilizzando il `scontrol` comando.
+ **Accendi i nodi dinamici in `POWER_SAVING` stato**
Esegui il comando come utente `su` root:
```
$ scontrol update nodename=nodename state=power_up
```
Puoi anche inviare un `sleep 1` lavoro segnaposto richiedendo un certo numero di nodi e poi fare affidamento su di esso Slurm per attivare il numero richiesto di nodi.
+ **Spegni prima i nodi dinamici [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)**
Ti consigliamo di impostare i nodi dinamici `DOWN` come utente `su` root con il comando:
```
$ scontrol update nodename=nodename state=down reason="manually draining"
```
AWS ParallelCluster termina e ripristina automaticamente i nodi dinamici disattivati.
In generale, non è consigliabile impostare i nodi in modo che utilizzino `POWER_DOWN` direttamente il comando. `scontrol update nodename=nodename state=power_down` Questo perché gestisce AWS ParallelCluster automaticamente il processo di spegnimento.
+ **Disabilita una coda (partizione) o ferma tutti i nodi statici in una partizione specifica**
Imposta una coda specifica `INACTIVE` come utente `su` root con il comando:
```
$ scontrol update partition=queuename state=inactive
```
Questa operazione interrompe tutte le istanze che eseguono il backup dei nodi nella partizione.
+ **Abilita una coda (partizione)**
Imposta una coda specifica per `UP` un utente `su` root con il comando:
```
$ scontrol update partition=queuename 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-spotcompute1-[1-2]`
+ `ResumeProgram`avvia due istanze Amazon EC2 e assegna gli indirizzi IP e i nomi host privati di, in `ResumeTimeout` attesa (il periodo predefinito è `queue1-dy-spotcompute1-[1-2]` di 30 minuti) prima di reimpostare i nodi.
+ Le istanze vengono configurate e si uniscono al cluster. Un processo inizia a essere eseguito sulle istanze.
+ Il processo viene completato e l'esecuzione si interrompe.
+ Al termine della configurazione `SuspendTime` (che è impostata su [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)), lo scheduler imposta le istanze sullo stato. `POWER_SAVING` Lo scheduler imposta quindi `POWER_DOWN` lo stato e chiama `queue1-dy-spotcompute1-[1-2]` `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, passa `queue1-dy-spotcompute1-[1-2]` allo stato di inattività e reimposta l'indirizzo IP privato e il nome host in modo che sia pronto per l'avvio per i lavori futuri.
**Se qualcosa va storto e un'istanza per un particolare nodo non può essere avviata per qualche motivo, succede quanto segue:**
+ Lo scheduler riceve un lavoro che richiede due nodi.
+ Lo scheduler trasferisce due nodi di cloud bursting `POWER_UP` allo stato e chiama `ResumeProgram` con i nomi dei nodi, (ad esempio). `queue1-dy-spotcompute1-[1-2]`
+ `ResumeProgram`avvia solo una (1) istanza Amazon EC2 e `queue1-dy-spotcompute1-1` configura, con una (1) istanza`queue1-dy-spotcompute1-2`, che non riesce ad avviarsi.
+ `queue1-dy-spotcompute1-1`non è interessato e torna online dopo aver raggiunto lo stato. `POWER_UP`
+ `queue1-dy-spotcompute1-2`passa allo `POWER_DOWN` stato e il processo viene richiesto automaticamente perché Slurm rileva un errore del nodo.
+ `queue1-dy-spotcompute1-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 si ripete 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 è 30 minuti)**: `ResumeTimeout` controlla il tempo di Slurm attesa prima della transizione del nodo allo stato inattivo.
+ Potrebbe essere utile estenderlo `ResumeTimeout` se il processo di pre/post installazione richiede quasi così tanto tempo.
+ `ResumeTimeout`è 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. AWS ParallelCluster i processi sostituiscono un nodo al rilevamento di un'istanza terminata.
+ **`SuspendTimeout`(l'impostazione predefinita è 120 secondi (2 minuti))**: `SuspendTimeout` controlla la velocità con cui i nodi vengono reinseriti nel sistema e sono nuovamente pronti per l'uso.
+ Un valore più corto `SuspendTimeout` indica che i nodi vengono ripristinati più rapidamente e Slurm possono provare ad avviare le istanze più frequentemente.
+ Un valore più lungo `SuspendTimeout` significa che i nodi guasti vengono ripristinati più lentamente. Nel frattempo, Slurm prova a usare altri nodi. Se `SuspendTimeout` dura più di qualche minuto, Slurm prova a scorrere ciclicamente tra tutti i nodi del sistema. Una versione più lunga `SuspendTimeout` potrebbe essere utile per i sistemi su larga scala (oltre 1.000 nodi) per ridurre lo stress Slurm quando si tenta di rimettere spesso in coda i lavori non riusciti.
+ Tieni presente che `SuspendTimeout` non si riferisce al tempo di AWS ParallelCluster attesa per terminare un'istanza 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 `POWER_DOWN` stato e non è disponibile per l'uso da parte dello scheduler.
## Registri per l'architettura
L'elenco seguente contiene i log delle chiavi. Il nome del flusso di log utilizzato con Amazon CloudWatch Logs ha il formato `{hostname}.{instance_id}.{logIdentifier}` *logIdentifier* seguente i nomi di log.
+ `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 avviarsi, accendersi o unirsi al cluster**
+ Nodi dinamici:
+ Controlla il `ResumeProgram` registro per vedere se `ResumeProgram` è stato chiamato con il nodo. In caso contrario, controlla il `slurmctld` registro per determinare se hai Slurm 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 è stata avviata, dovrebbe apparire un messaggio di errore chiaro sul motivo per cui l'istanza non è stata avviata.
+ Se è stata avviata un'istanza, potrebbe essersi 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. Se le istanze non sono state avviate, dovrebbero esserci errori evidenti sul motivo per cui le istanze non sono state avviate.
+ Se è stata avviata un'istanza, c'è qualche problema con 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 e 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 ad Amazon EC2, utilizza strumenti come Amazon CloudWatch o la console Amazon EC2, l'interfaccia a riga di comando o gli SDK per verificare lo stato o i log di quell'istanza. Ad esempio, puoi verificare se l'istanza aveva eventi pianificati o non ha superato i controlli dello stato di integrità di Amazon EC2.
+ 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 ai nodi:
+ 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 valuta 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 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)correttamente, guarda nel `SuspendProgram` registro per vedere se `slurmctld` i processi hanno effettuato chiamate con il nodo specifico come argomento. Note in realtà `SuspendProgram` non esegue alcuna azione specifica. Piuttosto, registra solo quando viene chiamato. Tutte le terminazioni e i `NodeAddr` ripristini delle istanze vengono completati da. `clustermgtd` Slurmtrasferisce i nodi a dopo. `IDLE` `SuspendTimeout`
**Altri problemi:**
+ AWS ParallelCluster non prende decisioni sull'allocazione del lavoro o sulla scalabilità. Tenta solo 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.
# Slurm modalità protetta dal cluster
Quando un cluster viene eseguito con la modalità protetta abilitata, AWS ParallelCluster monitora e tiene traccia degli errori di bootstrap dei nodi di calcolo durante l'avvio dei nodi di calcolo. Lo fa per rilevare se questi errori si verificano continuamente.
Se in una coda (partizione) viene rilevato quanto segue, il cluster entra nello stato protetto:
1. Gli errori consecutivi di bootstrap dei nodi di calcolo si verificano continuamente senza che i nodi di calcolo vengano avviati correttamente.
1. Il numero di errori raggiunge una soglia predefinita.
Dopo che il cluster ha raggiunto lo stato protetto, AWS ParallelCluster disabilita le code con errori pari o superiori alla soglia predefinita.
Slurm la modalità protetta dal cluster è stata aggiunta nella versione 3.0.0. AWS ParallelCluster
È possibile utilizzare la modalità protetta per ridurre il tempo e le risorse impiegate per il ciclo di errore di avvio del nodo di calcolo.
## Parametro della modalità protetta
**`protected_failure_count`**
`protected_failure_count`specifica il numero di errori consecutivi in una coda (partizione) che attivano lo stato di protezione del cluster.
L'impostazione predefinita `protected_failure_count` è 10 e la modalità protetta è abilitata.
Se `protected_failure_count` è maggiore di zero, la modalità protetta è abilitata.
Se `protected_failure_count` è minore o uguale a zero, la modalità protetta è disabilitata.
È possibile modificare il `protected_failure_count` valore aggiungendo il parametro nel file di `clustermgtd` configurazione che si trova `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` in. `HeadNode`
Puoi aggiornare questo parametro in qualsiasi momento e non è necessario interrompere la flotta di elaborazione per farlo. Se un avvio riesce in una coda prima del raggiungimento del numero di errori`protected_failure_count`, il conteggio degli errori viene azzerato.
## Controlla lo stato del cluster in stato protetto
Quando un cluster è in stato protetto, puoi controllare lo stato del parco di elaborazione e gli stati dei nodi.
### Elaborazione dello stato del parco veicoli
Lo stato della flotta di elaborazione si trova `PROTECTED` in un cluster in esecuzione in stato protetto.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### Stato del nodo
Per sapere quali code (partizioni) presentano errori di bootstrap che hanno attivato lo stato protetto, accedi al cluster ed esegui il comando. `sinfo` Le partizioni con errori di bootstrap pari o superiori sono nello stato. `protected_failure_count` `INACTIVE` Le partizioni senza errori di bootstrap pari o superiori `protected_failure_count` sono nello stato e funzionano come previsto. `UP`
`PROTECTED`lo stato non influisce sull'esecuzione dei lavori. Se i job sono in esecuzione su una partizione con errori di bootstrap pari o superiori`protected_failure_count`, la partizione viene impostata `INACTIVE` dopo il completamento dei job in esecuzione.
Considerate gli stati dei nodi mostrati nell'esempio seguente.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
`queue1`La partizione è `INACTIVE` dovuta al fatto che sono stati rilevati 10 errori di bootstrap consecutivi dei nodi di calcolo.
Le istanze relative ai nodi sono state `queue1-dy-c5xlarge-[1-10]` avviate ma non sono riuscite a unirsi al cluster a causa di uno stato non integro.
Lo stato del cluster è protetto.
La partizione `queue2` non è influenzata dagli errori di bootstrap in. `queue1` È nello `UP` stato e può ancora eseguire lavori.
## Come disattivare lo stato protetto
Dopo aver risolto l'errore di bootstrap, puoi eseguire il seguente comando per disattivare lo stato di protezione del cluster.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## Errori di bootstrap che attivano lo stato protetto
Gli errori di bootstrap che attivano lo stato protetto sono suddivisi nei tre tipi seguenti. Per identificare il tipo e il problema, puoi verificare se i log sono stati AWS ParallelCluster generati. Se i log sono stati generati, puoi controllarli per i dettagli degli errori. Per ulteriori informazioni, consulta [Recupero e conservazione dei log](troubleshooting-v3-get-logs.md).
1. **Errore di bootstrap che causa la terminazione automatica di un'istanza**.
Un'istanza ha esito negativo nelle prime fasi del processo di bootstrap, ad esempio un'istanza che si interrompe automaticamente a causa di errori nello script\$1\$1 \$1. [`SlurmQueues`[`CustomActions`[`OnNodeStart`[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
Per i nodi dinamici, cercate errori simili ai seguenti:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
Per i nodi statici, cerca nel `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) errori simili ai seguenti:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **Nodi `resume_timeout` o `node_replacement_timeout` scadenze.**
Un'istanza non può entrare a far parte del cluster all'interno di `resume_timeout` (per nodi dinamici) o `node_replacement_timeout` (per nodi statici). Non si interrompe automaticamente prima del timeout. Ad esempio, la rete non è configurata correttamente per il cluster e il nodo è impostato sullo stato da `DOWN` Slurm dopo la scadenza del timeout.
Per i nodi dinamici, cerca errori simili ai seguenti:
```
Node bootstrap error: Resume timeout expires for node
```
Per i nodi statici, cerca nel `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) errori simili ai seguenti:
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. **I nodi non superano il controllo di integrità**.
Un'istanza dietro il nodo non supera il controllo dello stato di EC2 integrità di Amazon o il controllo dello stato di un evento pianificato e i nodi vengono trattati come nodi di errore di bootstrap. In questo caso, l'istanza si interrompe per un motivo che sfugge al controllo di. AWS ParallelCluster
Cerca nel `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) gli errori simili ai seguenti:
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **I nodi di calcolo falliscono Slurm registrazione**.
La registrazione del `slurmd` demone con Slurm control daemon (`slurmctld`) fallisce e fa sì che lo stato del nodo di calcolo passi allo stato. `INVALID_REG` Configurato in modo errato Slurm i nodi di calcolo possono causare questo errore, ad esempio i nodi calcolati configurati con errori di specificazione dei nodi di [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)calcolo.
Cerca nel file di `slurmctld` log (`/var/log/slurmctld.log`) sul nodo principale o cerca nel file di `slurmd` log (`/var/log/slurmd.log`) del nodo di calcolo fallito gli errori simili ai seguenti:
```
Setting node %s to INVAL with reason: ...
```
## Come eseguire il debug della modalità protetta
Se lo stato del cluster è protetto e se `clustermgtd` i log sono AWS ParallelCluster stati generati da `HeadNode` e i `cloud-init-output` log dai nodi di calcolo problematici, puoi controllare i log per i dettagli sugli errori. Per ulteriori informazioni su come recuperare i log, consulta. [Recupero e conservazione dei log](troubleshooting-v3-get-logs.md)
**`clustermgtd`log (`/var/log/parallelcluster/clustermgtd`) sul nodo principale**
I messaggi di registro mostrano quali partizioni presentano errori di bootstrap e il numero di errori di bootstrap corrispondente.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
Nel `clustermgtd` registro, cerca per trovare quale nodo non è `Found the following bootstrap failure nodes` riuscito a eseguire il bootstrap.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
Nel `clustermgtd` registro, cerca per `Node bootstrap error` trovare il motivo dell'errore.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**`cloud-init-output`log (`/var/log/cloud-init-output.log`) sui nodi di calcolo**
Dopo aver ottenuto l'indirizzo IP privato del nodo di errore di avvio nel `clustermgtd` registro, puoi trovare il registro del nodo di calcolo corrispondente accedendo al nodo di calcolo o seguendo le istruzioni per recuperare i log. [Recupero e conservazione dei log](troubleshooting-v3-get-logs.md) Nella maggior parte dei casi, il `/var/log/cloud-init-output` log del nodo problematico mostra il passaggio che ha causato l'errore di bootstrap del nodo di calcolo.
# Slurmfailover rapido con capacità insufficiente del cluster
A partire dalla AWS ParallelCluster versione 3.2.0, i cluster vengono eseguiti con la modalità di failover rapido con capacità insufficiente abilitata per impostazione predefinita. Ciò riduce al minimo il tempo impiegato per riprovare a mettere in coda un lavoro quando vengono rilevati errori di capacità insufficiente di Amazon EC2. Ciò è particolarmente efficace quando si configura la coda con più risorse di elaborazione che utilizzano tipi di istanze diversi.
**Amazon EC2 ha rilevato errori di capacità insufficienti:**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: attivato se il prezzo della richiesta Spot è inferiore al prezzo minimo di gestione delle richieste Spot richiesto.
+ `Unsupported`: Attivato con l'uso di un tipo di istanza che non è supportato in uno specifico. Regione AWS
In modalità di failure-over rapido con capacità insufficiente, se viene rilevato un errore di capacità insufficiente quando un lavoro viene assegnato a [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources), AWS ParallelCluster effettua le seguenti operazioni:
1. Imposta la risorsa di calcolo su uno stato disabilitato (`DOWN`) per un periodo di tempo predefinito.
1. Viene utilizzato `POWER_DOWN_FORCE` per annullare i job del nodo in errore della risorsa di calcolo e per sospendere il nodo in errore. Imposta il nodo in errore `POWER_DOWN (!)` sullo stato `IDLE` and e quindi su. `POWERING_DOWN (%)`
1. Richiede il lavoro a un'altra risorsa di elaborazione.
I nodi statici e accesi della risorsa di elaborazione disattivata non sono interessati. I lavori possono essere completati su questi nodi.
Questo ciclo si ripete finché il lavoro non viene assegnato correttamente a uno o più nodi di risorse di elaborazione. Per informazioni sugli stati dei nodi, vedere. [Slurmguida per la modalità a coda multipla](multiple-queue-mode-slurm-user-guide-v3.md)
Se non viene trovata alcuna risorsa di elaborazione per eseguire il processo, il processo viene impostato `PENDING` sullo stato fino allo scadere del periodo di tempo predefinito. In questo caso, è possibile modificare il periodo di tempo predefinito come descritto nella sezione seguente.
## Parametro di timeout della capacità insufficiente
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout`specifica il periodo di tempo (in secondi) in cui la risorsa di elaborazione viene mantenuta nello stato disabled (`down`) quando viene rilevato un errore di capacità insufficiente.
Per impostazione predefinita, `insufficient_capacity_timeout` è abilitato.
L'impostazione predefinita `insufficient_capacity_timeout` è 600 secondi (10 minuti).
Se il `insufficient_capacity_timeout` valore è inferiore o uguale a zero, la modalità di failure-over rapido della capacità insufficiente viene disattivata.
È possibile modificare il `insufficient_capacity_timeout` valore aggiungendo il parametro nel file di `clustermgtd` configurazione che si trova in. `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` `HeadNode`
Il parametro può essere aggiornato in qualsiasi momento senza interrompere il parco di elaborazione.
Esempio:
+ `insufficient_capacity_timeout=600`:
Se viene rilevato un errore di capacità insufficiente, la risorsa di calcolo viene impostata su disabled (). `DOWN` Dopo 10 minuti, il relativo nodo guasto viene impostato sullo stato `idle~` (`POWER_SAVING`).
+ `insufficient_capacity_timeout=60`:
Se viene rilevato un errore di capacità insufficiente, la risorsa di calcolo è disattivata (`DOWN`). Dopo 1 minuto, il nodo guasto viene impostato sullo `idle~` stato.
+ `insufficient_capacity_timeout=0`:
La modalità di failure-over rapido della capacità insufficiente è disattivata. La risorsa di calcolo non è disabilitata.
**Nota**
Potrebbe verificarsi un ritardo fino a un minuto tra il momento in cui i nodi si guastano a causa di errori di capacità insufficiente e il momento in cui il daemon di gestione del cluster rileva i guasti dei nodi. Questo perché il daemon di gestione del cluster verifica la presenza di errori di capacità insufficiente dei nodi e imposta lo stato delle risorse di calcolo a intervalli di un minuto. `down`
## Stato rapido della modalità di failover con capacità insufficiente
Quando un cluster è in modalità di failover rapido con capacità insufficiente, è possibile verificarne lo stato e lo stato del nodo.
### Stati dei nodi
Quando un lavoro viene inviato a un nodo dinamico di risorse di calcolo e viene rilevato un errore di capacità insufficiente, il nodo viene posizionato nello `down#` stato corrispondente.
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
Quindi i nodi spenti (nodi in `idle~` stato) vengono impostati `down~` con motivo.
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
Il lavoro viene richiesto ad altre risorse di elaborazione in coda.
I nodi statici delle risorse di elaborazione e i nodi che `UP` non sono interessati dalla modalità di failover rapida con capacità insufficiente.
Considerate gli stati dei nodi mostrati nell'esempio seguente.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Inoltriamo un lavoro a queue1 che richiede un nodo.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
`queue1-dy-c-1-1`Il nodo viene avviato per eseguire il lavoro. Tuttavia, l'istanza non è stata avviata a causa di un errore di capacità insufficiente. `queue1-dy-c-1-1`Il nodo è impostato su`down`. Il nodo dinamico spento all'interno della risorsa di calcolo (`queue2-dy-c-1`) è impostato `down` su.
Puoi controllare il motivo del nodo con`scontrol show nodes`.
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
Il lavoro viene messo in coda su un altro tipo di istanza all'interno delle risorse di calcolo della coda.
Al termine, `insufficient_capacity_timeout` i nodi della risorsa di calcolo vengono ripristinati allo stato. `idle~`
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Dopo che gli `insufficient_capacity_timeout` intervalli e i nodi della risorsa di calcolo sono stati ripristinati `idle~` allo stato, lo Slurm scheduler assegna ai nodi una priorità inferiore. Lo scheduler continua a selezionare nodi da altre risorse di calcolo in coda con pesi più elevati, a meno che non si verifichi una delle seguenti condizioni:
+ I requisiti di invio di un lavoro corrispondono alla risorsa di elaborazione recuperata.
+ Non sono disponibili altre risorse di elaborazione perché sono al massimo della loro capacità.
+ `slurmctld`viene riavviato.
+ La flotta di AWS ParallelCluster elaborazione viene interrotta e avviata a spegnere e accendere tutti i nodi.
### Log correlati
I log relativi agli errori di capacità insufficiente e alla modalità di failover rapido e insufficiente sono disponibili nel Slurm `resume` `clustermgtd` registro e nel nodo principale.
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
Messaggi di errore quando un nodo non viene avviato a causa di una capacità insufficiente.
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
La risorsa di calcolo c-1 nella coda 1 è disabilitata a causa della capacità insufficiente.
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
Dopo la scadenza del timeout di capacità insufficiente, la risorsa di elaborazione viene reimpostata e i nodi all'interno delle risorse di calcolo vengono impostati su. `idle~`
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm pianificazione basata sulla memoria
A partire dalla versione 3.2.0, supporta AWS ParallelCluster Slurm pianificazione basata sulla memoria con il parametro di configurazione [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)cluster.
**Nota**
[A partire dalla AWS ParallelCluster versione 3.7.0, `EnableMemoryBasedScheduling` può essere abilitata se si configurano più tipi di istanza in Istanze.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Per le AWS ParallelCluster versioni da 3.2.0 a 3.6. *x*[, non `EnableMemoryBasedScheduling` può essere abilitato se configuri più tipi di istanza in Istanze.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
**avvertimento**
Quando specifichi più tipi di istanze in un Slurm queue computing resource with `EnableMemoryBasedScheduling` enabled, il `RealMemory` valore è la quantità minima di memoria disponibile per tutti i tipi di istanza. Ciò potrebbe comportare una notevole quantità di memoria inutilizzata se si specificano tipi di istanze con capacità di memoria molto diverse.
Con, il `EnableMemoryBasedScheduling: true` Slurm lo scheduler tiene traccia della quantità di memoria richiesta da ciascun processo su ciascun nodo. Quindi, il Slurm lo scheduler utilizza queste informazioni per pianificare più lavori sullo stesso nodo di elaborazione. La quantità totale di memoria richiesta dai job su un nodo non può essere maggiore della memoria disponibile del nodo. Lo scheduler impedisce a un processo di utilizzare più memoria di quella richiesta al momento dell'invio del lavoro.
Con`EnableMemoryBasedScheduling: false`, i job potrebbero competere per la memoria su un nodo condiviso e causare errori ed `out-of-memory` eventi.
**avvertimento**
Slurm utilizza una notazione di potenza 2 per le sue etichette, ad esempio MB o GB. Leggi queste etichette rispettivamente come MiB e GiB.
## Slurm configurazione e pianificazione basata sulla memoria
Con, `EnableMemoryBasedScheduling: true` Slurm imposta quanto segue Slurm parametri di configurazione:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) nella `slurm.conf`. Questa opzione configura la memoria del nodo come risorsa consumabile in Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)nel Slurm `cgroup.conf`. Con questa opzione, l'accesso di un lavoro alla memoria è limitato alla quantità di memoria richiesta dal lavoro al momento dell'invio.
**Nota**
Diverse altre Slurm i parametri di configurazione possono influire sul comportamento di Slurm scheduler e resource manager quando sono impostate queste due opzioni. Per ulteriori informazioni, consultare la [.Slurm Documentazione](https://slurm.schedmd.com/documentation.html).
## Slurm scheduler e pianificazione basata sulla memoria
**`EnableMemoryBasedScheduling: false`(impostazione predefinita)**
Per impostazione predefinita, `EnableMemoryBasedScheduling` è impostato su false. Quando è falso, Slurm non include la memoria come risorsa nel suo algoritmo di pianificazione e non tiene traccia della memoria utilizzata dai job. Gli utenti possono specificare l'`--mem MEM_PER_NODE`opzione per impostare la quantità minima di memoria per nodo richiesta da un processo. Ciò impone allo scheduler di scegliere nodi con un `RealMemory` valore almeno pari a 1 `MEM_PER_NODE` durante la pianificazione del lavoro.
Ad esempio, supponiamo che un utente invii due lavori con. `--mem=5GB` Se le risorse richieste come CPUs o GPUs sono disponibili, i processi possono essere eseguiti contemporaneamente su un nodo con 8 GiB di memoria. I due processi non sono pianificati su nodi di calcolo con meno di 5 `RealMemory` GiB di.
**avvertimento**
Quando la pianificazione basata sulla memoria è disabilitata, Slurm non tiene traccia della quantità di memoria utilizzata dai job. I lavori eseguiti sullo stesso nodo potrebbero competere per le risorse di memoria e causare il fallimento dell'altro processo.
Quando la pianificazione basata sulla memoria è disabilitata, consigliamo agli utenti di non specificare le [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu)opzioni o. [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu) Queste opzioni potrebbero causare un comportamento diverso da quello descritto nella [Slurm Documentazione](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Quando `EnableMemoryBasedScheduling` è impostato su true, Slurm tiene traccia dell'utilizzo della memoria di ogni processo e impedisce ai lavori di utilizzare più memoria di quella richiesta con le opzioni di `--mem` invio.
Utilizzando l'esempio precedente, un utente invia due lavori con. `--mem=5GB` I processi non possono essere eseguiti contemporaneamente su un nodo con 8 GiB di memoria. Questo perché la quantità totale di memoria richiesta è maggiore della memoria disponibile sul nodo.
Con la pianificazione basata sulla memoria abilitata `--mem-per-cpu` e `--mem-per-gpu` comportati in modo coerente con quanto descritto nella Slurm documentazione. Ad esempio, un lavoro viene inviato con. `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB` In questo caso, Slurm assegna al job un totale di 4 GiB per ogni nodo.
**avvertimento**
Quando la pianificazione basata sulla memoria è abilitata, consigliamo agli utenti di includere una `--mem` specifica quando inviano un lavoro. Con l'impostazione predefinita Slurm configurazione inclusa in AWS ParallelCluster, se non è inclusa alcuna opzione di memoria (`--mem`,`--mem-per-cpu`, o`--mem-per-gpu`), Slurm assegna l'intera memoria dei nodi allocati al job, anche se richiede solo una parte delle altre risorse, ad CPUs esempio o. GPUs Ciò impedisce efficacemente la condivisione dei nodi fino al termine del processo, poiché non è disponibile memoria per altri lavori. Ciò accade perché Slurm imposta la memoria per nodo per il lavoro su [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)quando non vengono fornite specifiche di memoria al momento dell'invio del lavoro. Il valore predefinito per questo parametro è 0 e specifica l'accesso illimitato alla memoria di un nodo.
Se nella stessa coda sono disponibili più tipi di risorse di calcolo con diverse quantità di memoria, a un lavoro inviato senza opzioni di memoria potrebbero essere assegnate quantità di memoria diverse su nodi diversi. Dipende dai nodi che lo scheduler mette a disposizione del job. Gli utenti possono definire un valore personalizzato per le opzioni, ad esempio `DefMemPerNode` o [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), a livello di cluster o partizione in Slurm file di configurazione per prevenire questo comportamento.
## Slurm RealMemory e AWS ParallelCluster SchedulableMemory
Con il plugin Slurm configurazione fornita con AWS ParallelCluster, Slurm interpreta [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)come la quantità di memoria per nodo disponibile per i lavori. A partire dalla versione 3.2.0, per impostazione predefinita, è AWS ParallelCluster `RealMemory` impostato sul 95 percento della memoria elencata in [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types) e restituita dall' EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)Amazon.
Quando la pianificazione basata sulla memoria è disabilitata, Slurm lo scheduler utilizza `RealMemory` per filtrare i nodi quando gli utenti inviano un lavoro con specifiche. `--mem`
Quando la pianificazione basata sulla memoria è abilitata, Slurm lo scheduler interpreta `RealMemory` come la quantità massima di memoria disponibile per i lavori in esecuzione sul nodo di elaborazione.
L'impostazione predefinita potrebbe non essere ottimale per tutti i tipi di istanze:
+ Questa impostazione potrebbe essere superiore alla quantità di memoria a cui i nodi possono effettivamente accedere. Ciò può accadere quando i nodi di calcolo sono tipi di istanze di piccole dimensioni.
+ Questa impostazione potrebbe essere inferiore alla quantità di memoria a cui i nodi possono effettivamente accedere. Ciò può verificarsi quando i nodi di calcolo sono tipi di istanze di grandi dimensioni e può portare a una notevole quantità di memoria inutilizzata.
È possibile utilizzare [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)per ottimizzare il valore di configure by AWS ParallelCluster per i nodi di `RealMemory` calcolo. Per sostituire il valore predefinito, definisci un valore personalizzato `SchedulableMemory` specifico per la configurazione del cluster.
Per verificare la memoria effettiva disponibile di un nodo di calcolo, esegui il `/opt/slurm/sbin/slurmd -C` comando sul nodo. Questo comando restituisce la configurazione hardware del nodo, incluso il [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)valore. Per ulteriori informazioni, consulta [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Assicurati che i processi del sistema operativo del nodo di calcolo dispongano di memoria sufficiente. A tale scopo, limita la memoria disponibile per i job impostando il `SchedulableMemory` valore su un `RealMemory` valore inferiore a quello restituito dal `slurmd -C` comando.
# Allocazione di più tipi di istanza con Slurm
A partire dalla AWS ParallelCluster versione 3.3.0, puoi configurare il cluster per l'allocazione dal set di tipi di istanza definiti di una risorsa di calcolo. L'allocazione può essere basata su strategie a basso costo o sulla capacità ottimale della EC2 flotta Amazon.
Questo set di tipi di istanze definiti deve avere tutti lo stesso numero di v CPUs o, se il multithreading è disabilitato, lo stesso numero di core. Inoltre, questo set di tipi di istanze deve avere lo stesso numero di acceleratori degli stessi produttori. Se [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled)è impostato su`true`, le istanze devono avere il supporto EFA. Per ulteriori informazioni e requisiti, vedere [`Scheduling`](Scheduling-v3.md)//[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)e [`SlurmQueues`[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/. [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Puoi [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)impostarlo su `lowest-price` o in `capacity-optimized` base alla tua [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)configurazione.
In [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances), puoi configurare un set di tipi di istanze.
**Nota**
[A partire dalla AWS ParallelCluster versione 3.7.0, `EnableMemoryBasedScheduling` può essere abilitato se configuri più tipi di istanza in Istanze.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Per le AWS ParallelCluster versioni da 3.2.0 a 3.6. *x*[, non `EnableMemoryBasedScheduling` può essere abilitato se configuri più tipi di istanza in Istanze.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Gli esempi seguenti mostrano come è possibile interrogare i tipi di istanza per vCPUs, il supporto EFA e l'architettura.
Query InstanceTypes con architettura 96 v CPUs e x86\$164.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Query InstanceTypes con 64 core, supporto EFA e architettura arm64.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Il prossimo esempio di frammento di configurazione del cluster mostra come utilizzarli InstanceType e AllocationStrategy proprietà.
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# Scalabilità del cluster per nodi dinamici
ParallelCluster supporta Slurm i metodi per scalare dinamicamente i cluster utilizzando il plug-in power Slurm saver. Per ulteriori informazioni, consulta la [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) e la [SlurmPower Saving Guide](https://slurm.schedmd.com/power_save.html) nella documentazione. Slurm I seguenti argomenti descrivono le Slurm strategie per ogni versione.
**Topics**
+ [Slurmstrategie di allocazione dinamica dei nodi nella versione 3.8.0](scheduler-node-allocation-v3-3.8.0.md)
+ [Slurmstrategie di allocazione dinamica dei nodi nella versione 3.7.x](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [Slurmstrategie di allocazione dinamica dei nodi nella versione 3.6.x e precedenti](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# Slurmstrategie di allocazione dinamica dei nodi nella versione 3.8.0
A partire dalla ParallelCluster versione 3.8.0, ParallelCluster utilizza la scalabilità a **livello di processo o la **scalabilità a livello** di processo come strategia di allocazione dinamica dei nodi predefinita per ParallelCluster scalare il cluster: ridimensiona il cluster in base ai requisiti di ciascun job, al numero di nodi allocati al job e ai nodi che devono essere ripristinati**. ParallelCluster ottiene queste informazioni dalla variabile di ambiente SLURM\$1RESUME\$1FILE.
La scalabilità per i nodi dinamici è un processo in due fasi, che prevede il lancio delle istanze EC2 e l'assegnazione delle istanze Amazon EC2 avviate ai nodi. Slurm **Ciascuno di questi due passaggi può essere eseguito utilizzando una logica o best-effort. **all-or-nothing****
Per il lancio delle istanze Amazon EC2:
+ **all-or-nothing**chiama l'API Amazon EC2 di lancio con un target minimo pari alla capacità target totale
+ **best-effort** chiama il lancio dell'API Amazon EC2 con un target minimo pari a 1 e la capacità target totale è uguale alla capacità richiesta
Per l'assegnazione delle istanze Slurm Amazon EC2 ai nodi:
+ **all-or-nothing**assegna istanze Amazon EC2 Slurm ai nodi solo se è possibile assegnare un'istanza Amazon EC2 a ogni nodo richiesto
+ **best-effort** assegna le istanze di Amazon EC2 Slurm ai nodi anche se tutti i nodi richiesti non sono coperti dalla capacità delle istanze di Amazon EC2
Le possibili combinazioni delle strategie di cui sopra si traducono nelle strategie di lancio. ParallelCluster
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing**ridimensionamento:
Questa strategia prevede l' AWS ParallelCluster avvio di una chiamata API di avvio di Amazon EC2 per ogni job, che richiede che tutte le istanze necessarie per il corretto avvio dei nodi di calcolo richiesti. Ciò garantisce la scalabilità del cluster solo quando è disponibile la capacità richiesta per processo, evitando che le istanze inattive rimangano inattive alla fine del processo di scalabilità.
La strategia utilizza una **all-or-nothing**logica per il lancio delle istanze Amazon EC2 per ogni processo e una **all-or-nothing**logica per l'assegnazione delle istanze Amazon EC2 ai nodi. Slurm
La strategia raggruppa le richieste di lancio in batch, uno per ogni risorsa di calcolo richiesta e fino a 500 nodi ciascuno. Per le richieste che riguardano più risorse di elaborazione o superano i 500 nodi, elabora in sequenza più batch. ParallelCluster
L'errore del batch di una singola risorsa comporta la chiusura di tutta la capacità inutilizzata associata, garantendo che nessuna istanza rimanga inattiva al termine del processo di scalabilità.
Limitazioni
+ Il tempo impiegato per il ridimensionamento è direttamente proporzionale al numero di lavori inviati per esecuzione del programma di curriculum. Slurm
+ L'operazione di scalabilità è limitata dal limite dell'account di RunInstances risorse, impostato a 1000 istanze per impostazione predefinita. Questa limitazione è conforme alle politiche AWS di limitazione delle API EC2, per maggiori dettagli, consulta la documentazione sulla limitazione delle API di [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) EC2
+ Quando invii un lavoro in una risorsa di elaborazione con un singolo tipo di istanza, in una coda che si estende su più zone di disponibilità, la chiamata all'API di avvio **all-or-nothing**EC2 ha successo solo se tutta la capacità può essere fornita in un'unica zona di disponibilità.
+ Quando invii un lavoro in una risorsa di calcolo con più tipi di istanze, in una coda con un'unica zona di disponibilità, la **all-or-nothing**chiamata all'API di avvio di Amazon EC2 ha successo solo se tutta la capacità può essere fornita da un singolo tipo di istanza.
+ **Quando invii un lavoro in una risorsa di calcolo con più tipi di istanze, in una coda che si estende su più zone di disponibilità, la chiamata API di lancio di Amazon EC2 **all-or-nothing**non è supportata ed esegue invece la scalabilità ottimale. ParallelCluster **
**greedy-all-or-nothing**ridimensionamento:
Questa variante della all-or-nothing strategia garantisce comunque la scalabilità del cluster solo quando è disponibile la capacità richiesta per processo, evitando le istanze inattive alla fine del processo di scalabilità, ma implica l'avvio di ParallelCluster una chiamata API di avvio di Amazon EC2 che mira a una capacità target minima di 1, nel tentativo di massimizzare il numero di nodi avviati fino alla capacità richiesta. La strategia utilizza una logica best-effort per il lancio delle istanze EC2 per tutti i job, oltre alla **all-or-nothing**logica per l'assegnazione delle istanze Amazon EC2 ai nodi per ogni job. Slurm
La strategia raggruppa le richieste di lancio in batch, uno per ogni risorsa di calcolo richiesta e fino a 500 nodi ciascuno. Per le richieste che riguardano più risorse di elaborazione o superano i 500 nodi, elabora in sequenza più batch. ParellelCluster
Garantisce che nessuna istanza venga lasciata inattiva alla fine del processo di scalabilità, massimizzando la velocità effettiva a scapito di un temporaneo sovradimensionamento durante il processo di scalabilità.
Limitazioni
+ È possibile un sovradimensionamento temporaneo, che comporta costi aggiuntivi per le istanze che passano allo stato di esecuzione prima del completamento della scalabilità.
+ Si applica lo stesso limite di istanze previsto dalla all-or-nothing strategia, soggetto al limite dell'account di AWS risorse. RunInstances
scalabilità con il **massimo sforzo**:
Questa strategia prevede una chiamata all'API di avvio di Amazon EC2 mirando a una capacità minima di 1 e mirando a raggiungere la capacità totale richiesta al costo di lasciare le istanze inattive dopo l'esecuzione del processo di scalabilità se non tutta la capacità richiesta è disponibile. La strategia utilizza una logica best-effort per il lancio delle istanze Amazon EC2 per tutti i lavori, oltre alla logica best-effort per **l'**assegnazione delle istanze Amazon EC2 ai nodi Slurm per ogni processo.
La strategia raggruppa le richieste di avvio in batch, uno per ogni risorsa di calcolo richiesta e fino a 500 nodi ciascuno. Per le richieste che riguardano più risorse di elaborazione o superano i 500 nodi, elabora in sequenza più batch. ParallelCluster
Questa strategia consente di scalare ben oltre il limite predefinito di 1000 istanze su più esecuzioni di processi di scalabilità, al costo di avere istanze inattive tra i diversi processi di scalabilità.
Limitazioni
+ Possibili istanze inattive in esecuzione alla fine del processo di scalabilità, nel caso in cui non sia possibile allocare tutti i nodi richiesti dai job.
**Di seguito è riportato un esempio che mostra come si comporta il ridimensionamento dei nodi dinamici utilizzando le diverse strategie di lancio. ParallelCluster ** Supponiamo di aver inviato due lavori per la richiesta di 20 nodi ciascuno, per un totale di 40 nodi dello stesso tipo, ma che siano disponibili solo 30 istanze Amazon EC2 per coprire la capacità richiesta su EC2.
**all-or-nothing**ridimensionamento:
+ Per il primo processo, viene chiamata un'API di avvio di ** all-or-nothing**Amazon EC2, che richiede 20 istanze. Una chiamata riuscita dà come risultato il lancio di 20 istanze
+ **all-or-nothing **l'assegnazione delle 20 istanze avviate ai Slurm nodi per il primo processo ha esito positivo
+ Viene chiamata un'altra API di avvio di **all-or-nothing**Amazon EC2, che richiede 20 istanze per il secondo processo. La chiamata non ha esito positivo, poiché è disponibile solo la capacità per altre 10 istanze. Al momento non viene avviata alcuna istanza
**greedy-all-or-nothing**ridimensionamento:
+ Viene **chiamata un'**API di avvio Amazon EC2 che richiede 40 istanze, ovvero la capacità totale richiesta da tutti i processi. Ciò si traduce nel lancio di 30 istanze
+ **all-or-nothing**L'assegnazione di 20 delle istanze avviate ai Slurm nodi per il primo processo ha esito positivo
+ Viene tentata un'altra **all-or-nothing**assegnazione delle istanze avviate rimanenti ai Slurm nodi per il secondo processo, ma poiché ci sono solo 10 istanze disponibili su un totale di 20 richieste dal processo, l'assegnazione non ha esito positivo
+ Le 10 istanze avviate non assegnate vengono terminate
**scalabilità con il massimo sforzo:**
+ Viene **chiamata un'**API di avvio Amazon EC2 che richiede 40 istanze, ovvero la capacità totale richiesta da tutti i processi. Ciò si traduce nel lancio di 30 istanze.
+ L'assegnazione **ottimale** di 20 delle istanze lanciate ai Slurm nodi per il primo processo ha esito positivo.
+ Un'altra **assegnazione** ottimale delle restanti 10 istanze avviate ai Slurm nodi per il secondo processo ha esito positivo, anche se la capacità totale richiesta era di 20. Tuttavia, poiché il processo richiedeva i 20 nodi ed era possibile assegnare istanze Amazon EC2 solo a 10 di essi, il processo non può essere avviato e le istanze vengono lasciate inattive, finché non viene trovata una capacità sufficiente per avviare le 10 istanze mancanti in una chiamata successiva del processo di scalabilità, oppure lo scheduler pianifica il processo su altri nodi di calcolo già in esecuzione.
# Slurmstrategie di allocazione dinamica dei nodi nella versione 3.7.x
ParallelCluster utilizza 2 tipi di strategie di allocazione dinamica dei nodi per scalare il cluster:
+
**Allocazione basata sulle informazioni richieste disponibili sui nodi:**
+ **Ripresa di tutti i nodi o ridimensionamento** **dell'elenco dei nodi:**
ParallelCluster ridimensiona il cluster in base solo ai nomi degli elenchi Slurm di nodi richiesti quando viene eseguito. Slurm `ResumeProgram` Alloca le risorse di calcolo ai nodi solo in base al nome del nodo. L'elenco dei nomi dei nodi può includere più processi.
+ **Curriculum a livello di lavoro** **o scalabilità a livello di lavoro:**
ParallelCluster ridimensiona il cluster in base ai requisiti di ciascun processo, al numero corrente di nodi allocati al processo e ai nodi che devono essere ripristinati. ParallelCluster ottiene queste informazioni dalla variabile di ambiente. `SLURM_RESUME_FILE`
+
**Allocazione con una strategia di lancio di Amazon EC2:**
+ **Scalabilità** al massimo:
ParallelCluster ridimensiona il cluster utilizzando una chiamata API di avvio di Amazon EC2 con la capacità di destinazione minima pari a 1, per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti.
+ **Una scalabilità: ll-or-nothing**
ParallelCluster aumenta la scalabilità del cluster utilizzando una chiamata API di avvio di Amazon EC2 che ha esito positivo solo se vengono lanciate tutte le istanze necessarie per supportare i nodi richiesti. In questo caso, chiama l'API dell'istanza di avvio di Amazon EC2 con la capacità target minima pari alla capacità totale richiesta.
Per impostazione predefinita, ParallelCluster utilizza il ridimensionamento dell'**elenco dei nodi** con una strategia di lancio di **Amazon** EC2 al massimo per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti. Cerca di fornire quanta più capacità possibile per soddisfare il carico di lavoro inviato.
**A partire dalla ParallelCluster versione 3.7.0, ParallelCluster utilizza la scalabilità a **livello di processo con una strategia di lancio **all-or-nothing**EC2 per i lavori** inviati in modalità esclusiva.** Quando invii un lavoro in modalità esclusiva, il lavoro ha accesso esclusivo ai nodi allocati. Per ulteriori informazioni, consulta [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE) nella Slurm documentazione.
Per inviare un'offerta di lavoro in modalità esclusiva:
+ Passa il flag esclusivo quando invii un Slurm lavoro al cluster. Ad esempio, `sbatch ... --exclusive`.
O
+ Invia un lavoro a una coda del cluster che è stata configurata con [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation)set to. `true`
Quando invii un lavoro in modalità esclusiva:
+ ParallelCluster attualmente i batch lanciano richieste per includere fino a 500 nodi. Se un processo richiede più di 500 nodi, ParallelCluster effettua una richiesta di **all-or-nothing**avvio per ogni set di 500 nodi e una richiesta di avvio aggiuntiva per il resto dei nodi.
+ Se l'allocazione dei nodi è in una singola risorsa di elaborazione, ParallelCluster effettua una richiesta di **all-or-nothing**avvio per ogni set di 500 nodi e una richiesta di avvio aggiuntiva per il resto dei nodi. Se una richiesta di avvio fallisce, ParallelCluster termina la capacità inutilizzata creata da tutte le richieste di avvio.
+ Se l'allocazione dei nodi si estende su più risorse di elaborazione, ParallelCluster deve effettuare una richiesta di **all-or-nothing**avvio per ogni risorsa di calcolo. Anche queste richieste vengono raggruppate. Se una richiesta di avvio fallisce per una delle risorse di calcolo, ParallelCluster termina la capacità inutilizzata creata da tutte le richieste di avvio delle risorse di calcolo.
scalabilità a **livello di lavoro con limitazioni note** della strategia di lancio: **all-or-nothing**
+ Quando invii un lavoro in una risorsa di calcolo con un singolo tipo di istanza, in una coda che si estende su più zone di disponibilità, la chiamata all'API di avvio di **all-or-nothing**EC2 ha esito positivo solo se tutta la capacità può essere fornita in un'unica zona di disponibilità.
+ Quando invii un lavoro in una risorsa di calcolo con più tipi di istanze, in una coda con un'unica zona di disponibilità, la **all-or-nothing**chiamata all'API di avvio di Amazon EC2 ha successo solo se tutta la capacità può essere fornita da un singolo tipo di istanza.
+ **Quando invii un lavoro in una risorsa di calcolo con più tipi di istanze, in una coda che si estende su più zone di disponibilità, la chiamata API di lancio di Amazon EC2 **all-or-nothing**non è supportata ed esegue invece la scalabilità ottimale. ParallelCluster**
# Slurmstrategie di allocazione dinamica dei nodi nella versione 3.6.x e precedenti
AWS ParallelCluster utilizza solo un tipo di strategia di allocazione dinamica dei nodi per scalare il cluster:
+ Allocazione basata sulle informazioni richieste disponibili sul nodo:
+ **Ripresa di tutti i nodi** **o ridimensionamento dell'elenco dei nodi**: ParallelCluster ridimensiona il cluster in base solo ai nomi degli elenchi Slurm di nodi richiesti quando viene eseguito. Slurm `ResumeProgram` Alloca le risorse di calcolo ai nodi solo in base al nome del nodo. L'elenco dei nomi dei nodi può includere più processi.
+ Allocazione con una strategia di lancio di Amazon EC2:
+ **Scalabilità** ottimale: aumenta la ParallelCluster scalabilità del cluster utilizzando una chiamata API di avvio di Amazon EC2 con la capacità target minima pari a 1, per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti.
ParallelCluster utilizza il ridimensionamento dell'**elenco dei nodi** con una strategia di lancio di **Amazon** EC2 al massimo per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti. Cerca di fornire quanta più capacità possibile per soddisfare il carico di lavoro inviato.
Limitazioni
+ Possibili istanze inattive in esecuzione al termine del processo di scalabilità, nel caso in cui non sia possibile allocare tutti i nodi richiesti dai job.
# Slurmcontabilità con AWS ParallelCluster
A partire dalla versione 3.3.0, AWS ParallelCluster supporta la Slurm contabilità con il parametro di configurazione del cluster [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database).
A partire dalla versione 3.10.0, AWS ParallelCluster supporta la Slurm contabilità con uno Slurmdbd esterno con il parametro di configurazione del cluster/. [SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings) L'utilizzo di uno Slurmdbd esterno è consigliato se più cluster condividono lo stesso database.
Con la Slurm contabilità, puoi integrare un database contabile esterno per eseguire le seguenti operazioni:
+ Gestisci utenti o gruppi di utenti del cluster e altre entità. Con questa funzionalità, puoi utilizzare le funzionalità più avanzate Slurm di cui dispone, ad esempio, l'applicazione dei limiti delle risorse, la condivisione equa e. QOSs
+ Raccogli e salva i dati del lavoro, come l'utente che ha eseguito il lavoro, la durata del lavoro e le risorse utilizzate. È possibile visualizzare i dati salvati con l'`sacct`utilità.
**Nota**
AWS ParallelCluster supporta la Slurm contabilità per i [Slurmserver di database MySQL supportati](https://slurm.schedmd.com/accounting.html#mysql-configuration).
## Utilizzo della Slurm contabilità tramite external Slurmdbd nella versione 3.10.0 e AWS ParallelCluster successive
Prima di configurare la Slurm contabilità, è necessario disporre di un server di Slurmdbd database esterno esistente, che si connette a un server di database esterno esistente.
Per configurarlo, definisci quanto segue:
+ L'indirizzo del Slurmdbd server esterno in [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host). Il server deve esistere ed essere raggiungibile dal nodo principale.
+ La chiave munge per comunicare con il Slurmdbd server esterno. [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn)
Per seguire un tutorial, consulta[Creazione di un cluster con un cluster esterno Slurmdbd contabilità](external-slurmdb-accounting.md).
**Nota**
L'utente è responsabile della gestione delle entità contabili del Slurm database.
L'architettura della funzionalità di SlurmDB supporto AWS ParallelCluster esterno consente a più cluster di condividere SlurmDB lo stesso database.
![\[\]](http://docs.aws.amazon.com/it_it/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**avvertimento**
Il traffico tra AWS ParallelCluster e l'esterno non SlurmDB è crittografato. Si consiglia di eseguire il cluster e quello esterno SlurmDB in una rete affidabile.
## Utilizzo della Slurm contabilità utilizzando head node Slurmdbd nella AWS ParallelCluster versione 3.3.0 e successive
Prima di configurare la Slurm contabilità, è necessario disporre di un server di database esterno e di un database esistenti che `mysql` utilizzino il protocollo.
Per configurare la Slurm contabilità con AWS ParallelCluster, è necessario definire quanto segue:
+ L'URI per il server di database esterno in [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri). Il server deve esistere ed essere raggiungibile dal nodo principale.
+ Credenziali per accedere al database esterno definite in [Database/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)e [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/. [UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName) AWS ParallelCluster utilizza queste informazioni per configurare la contabilità a Slurm livello e il `slurmdbd` servizio sul nodo principale. `slurmdbd`è il demone che gestisce la comunicazione tra il cluster e il server del database.
Per seguire un tutorial, vedere. [Creazione di un cluster con Slurm contabilità](tutorials_07_slurm-accounting-v3.md)
**Nota**
AWS ParallelCluster esegue un bootstrap di base del database di Slurm contabilità impostando l'utente predefinito del cluster come amministratore del database nel Slurm database. AWS ParallelCluster non aggiunge nessun altro utente al database di contabilità. Il cliente è responsabile della gestione delle entità contabili nel Slurm database.
AWS ParallelCluster configura [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)per garantire che un cluster disponga di un proprio Slurm database sul server del database. Lo stesso server di database può essere utilizzato su più cluster, ma ogni cluster ha il proprio database separato. AWS ParallelCluster utilizza il nome del cluster per definire il nome del database nel [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)parametro del file `slurmdbd` di configurazione. Considerate la situazione seguente. Un database presente sul server di database include un nome di cluster che non corrisponde a un nome di cluster attivo. In questo caso, puoi creare un nuovo cluster con quel nome di cluster da mappare a quel database. Slurmriutilizza il database per il nuovo cluster.
**avvertimento**
Non è consigliabile configurare più di un cluster per utilizzare lo stesso database contemporaneamente. Ciò può causare problemi di prestazioni o persino situazioni di deadlock del database.
Se l'Slurmaccounting è abilitato sul nodo principale di un cluster, consigliamo di utilizzare un tipo di istanza con una CPU potente, più memoria e una maggiore larghezza di banda di rete. Slurmla contabilità può mettere a dura prova il nodo principale del cluster.
Nell'attuale architettura della funzionalità di AWS ParallelCluster Slurm contabilità, ogni cluster ha la propria istanza del `slurmdbd` demone, come illustrato nel seguente diagramma di configurazione.
![\[\]](http://docs.aws.amazon.com/it_it/parallelcluster/latest/ug/images/slurm-acct-arch.png)
Se si aggiungono funzionalità Slurm multi-cluster o federative personalizzate all'ambiente cluster, tutti i cluster devono fare riferimento alla stessa istanza. `slurmdbd` In alternativa, ti consigliamo di abilitare l' AWS ParallelCluster Slurmaccounting su un cluster e di configurare manualmente gli altri cluster per la connessione a `slurmdbd` quelli ospitati sul primo cluster.
Se utilizzi AWS ParallelCluster versioni precedenti alla versione 3.3.0, fai riferimento al metodo alternativo per implementare la Slurm contabilità descritto in questo post del blog [HPC](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/).
## Slurmconsiderazioni contabili
### Database e cluster su diversi VPCs
Per abilitare la Slurm contabilità, è necessario un server di database che funga da backend per le operazioni di lettura e scrittura eseguite dal `slurmdbd` demone. Prima che il cluster venga creato o aggiornato per abilitare la Slurm contabilità, il nodo principale deve essere in grado di raggiungere il server del database.
Se devi implementare il server di database su un VPC diverso da quello utilizzato dal cluster, considera quanto segue:
+ Per abilitare la comunicazione tra il `slurmdbd` lato del cluster e il server del database, è necessario configurare la connettività tra i due. VPCs Per ulteriori informazioni, consulta [VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) nella *Amazon Virtual Private Cloud* User Guide.
+ È necessario creare il gruppo di sicurezza che si desidera collegare al nodo principale sul VPC del cluster. Dopo il peering dei due VPCs gruppi, è disponibile il collegamento incrociato tra i gruppi di sicurezza lato database e lato cluster. Per ulteriori informazioni, consulta [le regole dei gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
### Configurazione della crittografia TLS tra `slurmdbd` e il server del database
Con la configurazione di Slurm contabilità predefinita che AWS ParallelCluster fornisce, `slurmdbd` stabilisce una connessione crittografata TLS al server del database, se il server supporta la crittografia TLS. AWS servizi di database come Amazon RDS e Amazon Aurora supportano la crittografia TLS per impostazione predefinita.
È possibile richiedere connessioni sicure sul lato server impostando il `require_secure_transport` parametro sul server del database. Questo è configurato nel CloudFormation modello fornito.
Seguendo le migliori pratiche di sicurezza, si consiglia di abilitare anche la verifica dell'identità del server sul `slurmdbd` client. A tale scopo, configura [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)in`slurmdbd.conf`. Carica il certificato CA del server nel nodo principale del cluster. Quindi, imposta l'opzione [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) di `StorageParameters` in `slurmdbd.conf` sul percorso del certificato CA del server sul nodo principale. In questo modo si abilita la verifica dell'identità del server sul lato. `slurmdbd` Dopo aver apportato queste modifiche, riavvia il `slurmdbd` servizio per ristabilire la connettività al server del database con la verifica dell'identità abilitata.
### Aggiornamento delle credenziali del database
Per aggiornare i valori di [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)or [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn), devi prima interrompere il parco di elaborazione. Supponiamo che il valore segreto memorizzato nel Gestione dei segreti AWS segreto venga modificato e il relativo ARN non venga modificato. In questa situazione, il cluster non aggiorna automaticamente la password del database con il nuovo valore. Per aggiornare il cluster per il nuovo valore segreto, esegui il comando seguente dal nodo principale.
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**avvertimento**
Per evitare di perdere i dati contabili, si consiglia di modificare la password del database solo quando la flotta di elaborazione viene interrotta.
### Monitoraggio del database
Si consiglia di abilitare le funzionalità di monitoraggio dei servizi di AWS database. Per ulteriori informazioni, consulta la [documentazione sul monitoraggio di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) o [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html).
# Slurm personalizzazione della configurazione
A partire dalla AWS ParallelCluster versione 3.6.0, è possibile personalizzare `slurm.conf` Slurm configurazione in una configurazione di AWS ParallelCluster cluster.
Nella configurazione del cluster, è possibile personalizzare Slurm parametri di configurazione utilizzando le seguenti impostazioni di configurazione del cluster:
+ Personalizzazione Slurm parametri per l'intero cluster utilizzando il parametro [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)o il [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)parametro. AWS ParallelCluster fallisce se si specificano entrambi.
+ Personalizzazione Slurm parametri per una coda utilizzando [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(mappati a Slurm partizioni).
+ Personalizzazione Slurm parametri per una risorsa di calcolo utilizzando [`SlurmQueues`[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(mappati a Slurm nodi).
## Slurm limiti e considerazioni sulla personalizzazione della configurazione durante l'utilizzo AWS ParallelCluster
+ Per `CustomSlurmSettings` e `CustomSlurmSettingsIncludeFile` impostazioni, è possibile specificare e aggiornare solo `slurm.conf` i parametri inclusi nel [Slurm versione ](slurm-workload-manager-v3.md) supportata dalla AWS ParallelCluster versione utilizzata per configurare un cluster.
+ Se si specifica personalizzato Slurm configurazioni in qualsiasi `CustomSlurmSettings` parametro, AWS ParallelCluster esegue controlli di convalida e impedisce l'impostazione o l'aggiornamento Slurm parametri di configurazione che sono in conflitto con AWS ParallelCluster la logica. Il Slurm i parametri di configurazione con cui è noto che sono in conflitto AWS ParallelCluster vengono identificati negli elenchi di rifiuto. Le liste di rifiuto possono cambiare nelle AWS ParallelCluster versioni future se altre Slurm vengono aggiunte funzionalità. Per ulteriori informazioni, consulta [Non inserito nell'elenco Slurm parametri di configurazione per `CustomSlurmSettings`](#slurm-configuration-denylists-v3).
+ AWS ParallelCluster controlla solo se un parametro è in una lista di rifiuto. AWS ParallelCluster non convalida la tua personalizzazione Slurm sintassi o semantica dei parametri di configurazione. Sei responsabile della convalida della tua personalizzazione Slurm parametri di configurazione. Personalizzazione non valida Slurm i parametri di configurazione possono causare Slurm errori dei daemon che possono causare errori di creazione e aggiornamento del cluster.
+ Se si specifica personalizzato Slurm configurazioni in`CustomSlurmSettingsIncludeFile`, AWS ParallelCluster non esegue alcuna convalida.
+ Puoi aggiornare `CustomSlurmSettings` e `CustomSlurmSettingsIncludeFile` senza interrompere e avviare la flotta di elaborazione. In questo caso, AWS ParallelCluster riavvia il `slurmctld` demone ed esegue il comando. `scontrol reconfigure`
Medio Slurm i parametri di configurazione potrebbero richiedere diverse operazioni prima che una modifica venga registrata nell'intero cluster. Ad esempio, potrebbero richiedere il riavvio di tutti i demoni del cluster. L'utente ha la responsabilità di verificare se AWS ParallelCluster le operazioni sono sufficienti per diffondere la personalizzazione Slurm impostazioni dei parametri di configurazione durante gli aggiornamenti. Se ritieni che AWS ParallelCluster le operazioni non siano sufficienti, è tua responsabilità fornire le azioni aggiuntive necessarie per propagare le impostazioni aggiornate, come consigliato nella [Slurm documentazione](https://slurm.schedmd.com/documentation.html).
## Non inserito nell'elenco Slurm parametri di configurazione per `CustomSlurmSettings`
Le tabelle seguenti elencano i parametri con le AWS ParallelCluster versioni che ne negano l'uso, a partire dalla versione 3.6.0. `CustomSlurmSettings`non è supportato per AWS ParallelCluster le versioni precedenti alla versione 3.6.0.
**Parametri negati a livello di cluster:**
| Slurm parametro | Deny-list nelle versioni AWS ParallelCluster |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilogo | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**Parametri negati a livello di cluster quando sono nativi [Slurm l'integrazione contabile](slurm-accounting-v3.md) è configurata nella configurazione del cluster:**
| Slurm parametro | Deny-list nelle versioni AWS ParallelCluster |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**Parametri negati a livello di coda (partizione) per le code gestite da: AWS ParallelCluster**
| Slurm parametro | Negate nelle versioni AWS ParallelCluster |
| --- | --- |
| Nodi | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| Stato | 3.6.0 |
| SuspendTime | 3.6.0 |
**Parametri negati a livello di risorsa di calcolo (nodo) per la risorsa di elaborazione gestita da: AWS ParallelCluster**
| Slurm parametro | Deny-list nella versione e nelle versioni successive AWS ParallelCluster |
| --- | --- |
| CPUs | 3.6.0 |
| Funzionalità | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| Weight | 3.7.0 |
# Slurm e `prolog` `epilog`
A partire dalla AWS ParallelCluster versione 3.6.0, la Slurm configurazione con cui viene distribuita AWS ParallelCluster include i `Prolog` parametri di configurazione e: `Epilog`
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
Per ulteriori informazioni, consulta la Guida [Prolog ed Epilog](https://slurm.schedmd.com/prolog_epilog.html) nella documentazione. Slurm
AWS ParallelCluster include i seguenti script di prolog ed epilog:
+ `90_plcuster_health_check_manager`(nella cartella) `Prolog`
+ `90_pcluster_noop`(nella `Epilog` cartella)
**Nota**
`Prolog`Sia la `Epilog` cartella che la cartella devono contenere almeno un file.
È possibile utilizzare `epilog` script personalizzati `prolog` o personalizzati aggiungendoli alle `Epilog` cartelle `Prolog` e corrispondenti.
**avvertimento**
Slurmesegue tutti gli script nelle cartelle, in ordine alfabetico inverso.
La durata di esecuzione degli `epilog` script `prolog` and influisce sul tempo necessario per eseguire un processo. Aggiorna le impostazioni `BatchStartTimeout` di configurazione quando esegui `prolog` script multipli o di lunga durata. L'impostazione predefinita è 3 minuti.
Se utilizzi `epilog` script `prolog` e personalizzati, individua gli script nelle `Prolog` rispettive `Epilog` cartelle. Si consiglia di conservare lo `90_plcuster_health_check_manager` script che viene eseguito prima di ogni script personalizzato. Per ulteriori informazioni, consulta [Slurm personalizzazione della configurazione](slurm-configuration-settings-v3.md).
# Dimensioni e aggiornamento della capacità del cluster
La capacità del cluster è definita dal numero di nodi di calcolo scalabili dal cluster. I nodi di calcolo sono supportati da EC2 istanze Amazon definite all'interno delle risorse di elaborazione nella AWS ParallelCluster configurazione `(Scheduling/SlurmQueues/ ComputeResources)` e sono organizzati in code `(Scheduling/SlurmQueues)` con mappatura 1:1 a Slurm partizioni.
[All'interno di una risorsa di calcolo è possibile configurare il numero minimo di nodi di calcolo (istanze) che devono essere sempre mantenuti in esecuzione nel cluster (`MinCount`) e il numero massimo di istanze che la risorsa di calcolo può scalare fino a (3). `MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
Al momento della creazione del cluster o dopo un aggiornamento del cluster, AWS ParallelCluster avvia tutte le EC2 istanze Amazon configurate `MinCount` per ogni risorsa di calcolo (`Scheduling/SlurmQueues/ ComputeResources`) definita nel cluster. ***Le istanze avviate per coprire il numero minimo di nodi per le risorse di calcolo nel cluster sono chiamate nodi statici.*** Una volta avviati, i nodi statici sono pensati per essere persistenti nel cluster e non vengono terminati dal sistema, a meno che non si verifichi un evento o una condizione particolare. Tali eventi includono, ad esempio, il fallimento di Slurm o i controlli EC2 sanitari di Amazon e la modifica del Slurm stato del nodo su DRAIN o DOWN.
***Le EC2 istanze Amazon, nell'intervallo da 0 `1` a `‘MaxCount - MinCount’` (`MaxCount `*meno*)` MinCount)`, lanciate su richiesta per gestire l'aumento del carico del cluster, vengono chiamate nodi dinamici.*** La loro natura è effimera, vengono avviate per eseguire lavori in sospeso e vengono terminate quando rimangono inattive per un periodo di tempo definito `Scheduling/SlurmSettings/ScaledownIdletime` nella configurazione del cluster (impostazione predefinita: 10 minuti).
I nodi statici e i nodi dinamici sono conformi al seguente schema di denominazione:
+ Nodi statici dove `-st--` ` = 1..ComputeResource/MinCount`
+ Nodi dinamici `-dy--` dove ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Ad esempio, data la seguente AWS ParallelCluster configurazione:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
I seguenti nodi verranno definiti in Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Quando una risorsa di elaborazione lo ha`MinCount == MaxCount`, tutti i nodi di calcolo corrispondenti saranno statici e tutte le istanze verranno avviate al momento della creazione/aggiornamento del cluster e mantenute attive e funzionanti. Per esempio:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Aggiornamento della capacità del cluster
L'aggiornamento della capacità del cluster include l'aggiunta o la rimozione di code, risorse di elaborazione o la modifica `MinCount/MaxCount` di una risorsa di elaborazione. A partire dalla AWS ParallelCluster versione 3.9.0, la riduzione delle dimensioni di una coda richiede che il parco di elaborazione venga interrotto o [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)impostato su TERMINATE prima dell'aggiornamento del cluster. Non è necessario interrompere la flotta di elaborazione o impostare su TERMINATE quando: [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)
+ Aggiungere nuove code a Scheduling/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Aggiungere nuove risorse di calcolo a una coda `Scheduling/SlurmQueues/ComputeResources`
+ Aumento della potenza `MaxCount` di una risorsa di elaborazione
+ Aumento MinCount di una risorsa di elaborazione e aumento MaxCount della stessa risorsa di elaborazione almeno della stessa quantità
## Considerazioni e limitazioni
Questa sezione ha lo scopo di delineare eventuali fattori, vincoli o limitazioni importanti da tenere in considerazione durante il ridimensionamento della capacità del cluster.
+ Quando si rimuove una coda da `Scheduling/SlurmQueues` tutti i nodi di elaborazione con nome`-*`, sia statici che dinamici, verrà rimossa dal Slurm la configurazione e le EC2 istanze Amazon corrispondenti verranno terminate.
+ Quando si rimuove una risorsa di calcolo `Scheduling/SlurmQueues/ComputeResources` da una coda, tutti i nodi di calcolo con nome`-*--*`, sia statici che dinamici, verranno rimossi dalla Slurm la configurazione e le EC2 istanze Amazon corrispondenti verranno terminate.
Quando si modifica il `MinCount` parametro di una risorsa di calcolo, possiamo distinguere due diversi scenari, se `MaxCount` viene mantenuto uguale a `MinCount` (solo capacità statica) e se `MaxCount` è maggiore di `MinCount` (capacità statica e dinamica mista).
### La capacità cambia solo con nodi statici
+ Se`MinCount == MaxCount`, aumentando `MinCount` (e`MaxCount`), il cluster verrà configurato estendendo il numero di nodi statici al nuovo valore di `MinCount` `-st--` e il sistema continuerà a provare ad avviare EC2 istanze Amazon per soddisfare la nuova capacità statica richiesta.
+ Se`MinCount == MaxCount`, diminuendo `MinCount` (e`MaxCount`) la quantità N, il cluster verrà configurato rimuovendo gli ultimi N nodi statici `-st--...]` e il sistema interromperà le istanze Amazon EC2 corrispondenti.
+ Stato iniziale `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento `-30` su `MinCount` e `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Modifiche di capacità con nodi misti
Se`MinCount < MaxCount`, aumentando `MinCount` di una quantità N (supponendo che `MaxCount` venga mantenuto invariato), il cluster verrà configurato estendendo il numero di nodi statici al nuovo valore di `MinCount` (`old_MinCount + N`): `-st--` e il sistema continuerà a provare ad avviare EC2 istanze Amazon per soddisfare la nuova capacità statica richiesta. Inoltre, per rispettare la `MaxCount` capacità della risorsa di calcolo, la configurazione del cluster viene aggiornata *rimuovendo gli ultimi N nodi dinamici*: `-dy--[...]` e il sistema interromperà le istanze Amazon EC2 corrispondenti.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiorna \$130 a `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se`MinCount < MaxCount`, aumentando `MinCount` e `MaxCount` della stessa quantità N, il cluster verrà configurato estendendo il numero di nodi statici al nuovo valore di `MinCount` (`old_MinCount + N`): `-st--` e il sistema continuerà a provare ad avviare EC2 istanze Amazon per soddisfare la nuova capacità statica richiesta. Inoltre, non verrà apportata alcuna modifica al numero di nodi dinamici per rispettare il nuovo
`MaxCount` value.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiorna \$130 a `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se`MinCount < MaxCount`, diminuendo la `MinCount` quantità N (supponendo che `MaxCount` venga mantenuta invariata), il cluster verrà configurato rimuovendo gli ultimi N nodi statici dei nodi statici `-st--[...` e il sistema chiuderà le istanze Amazon corrispondenti. EC2 Inoltre, per rispettare la `MaxCount` capacità della risorsa di elaborazione, la configurazione del cluster viene aggiornata estendendo il numero di nodi dinamici per colmare il divario. `MaxCount - new_MinCount: -dy--[1..]` In questo caso, trattandosi di nodi dinamici, non verranno lanciate nuove EC2 istanze Amazon a meno che lo scheduler non abbia lavori in sospeso sui nuovi nodi.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento -30 su `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se`MinCount < MaxCount`, in diminuzione `MinCount` e `MaxCount` della stessa quantità N, il cluster verrà configurato rimuovendo gli ultimi N nodi statici `-st--...]` e il sistema interromperà le istanze Amazon EC2 corrispondenti.
Inoltre, non verrà apportata alcuna modifica al numero di nodi dinamici per rispettare il nuovo valore. `MaxCount`
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento -30 su `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se`MinCount < MaxCount`, diminuendo la `MaxCount` quantità N (supponendo che `MinCount` venga mantenuta invariata), il cluster verrà configurato rimuovendo gli ultimi N nodi dinamici `-dy--]` e il sistema interromperà le EC2 istanze Amazon corrispondenti nel caso in cui fossero in esecuzione. Non è previsto alcun impatto sui nodi statici.
+ Stato iniziale: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aggiornamento -30 su `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impatti sui lavori
In tutti i casi in cui i nodi vengono rimossi e EC2 le istanze Amazon terminate, un job sbatch in esecuzione sui nodi rimossi verrà messo nuovamente in coda, a meno che non vi siano altri nodi che soddisfino i requisiti del processo. In quest'ultimo caso, il job fallisce con lo stato NODE\$1FAIL e scompare dalla coda e deve essere inviato nuovamente manualmente.
Se si prevede di eseguire un aggiornamento per il ridimensionamento del cluster, è possibile impedire l'esecuzione dei lavori nei nodi che verranno rimossi durante l'aggiornamento pianificato. Ciò è possibile impostando i nodi da rimuovere durante la manutenzione. Tieni presente che l'impostazione di un nodo in manutenzione non influirebbe sui lavori che alla fine sono già in esecuzione nel nodo.
Supponiamo che con l'aggiornamento pianificato per il ridimensionamento del cluster si voglia rimuovere il nodo`qeueu-st-computeresource-[9-10`]. È possibile creare un Slurm prenotazione con il seguente comando
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Questo creerà un Slurm prenotazione denominata `maint_for_update` sui nodi`qeueu-st-computeresource-[9-10]`. Dal momento in cui viene creata la prenotazione, non è possibile eseguire altri lavori nei nodi`qeueu-st-computeresource-[9-10]`. Tieni presente che la prenotazione non impedirà l'assegnazione finale dei lavori sui nodi`qeueu-st-computeresource-[9-10]`.
Dopo l'aggiornamento del ridimensionamento del cluster, se Slurm la prenotazione è stata impostata solo sui nodi che sono stati rimossi durante l'aggiornamento di ridimensionamento, la prenotazione di manutenzione verrà eliminata automaticamente. Se invece avessi creato un Slurm prenotazione sui nodi che sono ancora presenti dopo l'aggiornamento del ridimensionamento del cluster, potremmo voler rimuovere la prenotazione di manutenzione sui nodi dopo aver eseguito l'aggiornamento di ridimensionamento, utilizzando il seguente comando
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Per ulteriori dettagli su Slurm per prenotare, consulta il documento ufficiale di SchedMD [qui](https://slurm.schedmd.com/reservations.html).
## Processo di aggiornamento del cluster in caso di modifiche alla capacità
In caso di modifica della configurazione dello scheduler, durante il processo di aggiornamento del cluster vengono eseguiti i seguenti passaggi:
+ Interrompi AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Genera aggiornamenti Slurm configurazione delle partizioni dalla AWS ParallelCluster configurazione
+ Riavvio `slurmctld` (eseguito tramite la ricetta del servizio Chef)
+ Controlla `slurmctld` lo stato `(systemctl is-active --quiet slurmctld.service)`
+ Reload (Carica di nuovo) Slurm configurazione `(scontrol reconfigure)`
+ Avvia `clustermgtd (supervisorctl start clustermgtd)`
# Utilizzo dello scheduler AWS Batch (`awsbatch`) con AWS ParallelCluster
**avvertimento**
AWS CodeBuild non è supportato nelle regioni Asia Pacifico (Malesia) (`ap-southeast-5`) e Asia Pacifico (Tailandia) (`ap-southeast-7`). Pertanto, ParallelCluster AWS Batch l'integrazione non è supportata in tali regioni.
AWS ParallelCluster supporta anche AWS Batch gli scheduler. I seguenti argomenti descrivono come utilizzare AWS Batch. 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).
Questa CLI è distribuita come pacchetto separato. Per ulteriori informazioni, consulta [Supporto Scheduler](moving-from-v2-to-v3.md#scheduler_support).
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.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***
Specifica 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.
Quando il [`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType)parametro [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)/[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/è impostato su`SPOT`, i lavori paralleli multinodo *non sono* supportati. Inoltre, nel tuo account deve essere presente un ruolo `AWSServiceRoleForEC2Spot` collegato al servizio. Puoi creare questo ruolo con il seguente comando: AWS CLI
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Per ulteriori informazioni, consulta il [ruolo collegato ai servizi 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 Elastic Compute Cloud User Guide for* Linux Instances.
**-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. Puoi specificare una dipendenza dal `SEQUENTIAL` tipo senza specificare un ID di lavoro per i job 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 lavori separati da spazi da IDs mostrare nell'output. 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***
Specificate l'elenco separato da spazi dei lavori 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