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à. # 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.