Slurm guida per la modalità a coda multipla

• Un nodo in uno POWER_SAVING stato viene visualizzato con un ~ suffisso (ad esempioidle~) in. sinfo In questo stato, nessuna istanza EC2 supporta il nodo. Tuttavia, Slurm può ancora allocare lavori al nodo.

• Un nodo che passa a POWER_UP uno stato viene visualizzato con un # suffisso (ad esempioidle#) in. sinfo Un nodo passa automaticamente a POWER_UP uno stato, quando Slurm alloca un lavoro a un nodo in uno stato. POWER_SAVING

  In alternativa, puoi trasferire i nodi allo POWER_UP stato manualmente 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 e si è unito al 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 esempioidle%) in. sinfo I nodi dinamici entrano automaticamente nello POWER_DOWN stato successivo. ScaledownIdletime Al contrario, i nodi statici nella maggior parte dei casi non sono spenti. Tuttavia, puoi inserire 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 riportato POWER_SAVING allo stato e disponibile per l'uso successivo. ScaledownIdletime

  L'ScaledownIdletimeimpostazione viene salvata nell'impostazione di Slurm configurazioneSuspendTimeout.

• Un nodo offline viene visualizzato con un * suffisso (ad esempiodown*) insinfo. 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 supporto vengono terminate.

• Un tipo di istanza (ad esempioc5.xlarge)

• Un tipo di nodo (può essere uno dynamic ostatic.)

• UP: indica che la partizione è attiva. Questo è lo stato predefinito di una partizione. In questo stato, tutti i nodi della partizione sono attivi e disponibili all'uso.

• INACTIVE: indica che la partizione è in stato inattivo. In questo stato, tutte le istanze che supportano i nodi di backup di una partizione inattiva vengono terminate. Le nuove istanze non vengono avviate per i nodi in una partizione inattiva.

• Arresto del parco di calcolo: quando viene eseguito il seguente comando, tutte le partizioni passano allo stato e AWS ParallelCluster i processi mantengono le partizioni INACTIVE 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, inizialmente tutte le partizioni passano allo stato. UP Tuttavia, AWS ParallelCluster i processi non mantengono la partizione in uno stato. UP È necessario modificare manualmente gli stati delle partizioni. Tutti i nodi statici diventano disponibili dopo pochi minuti. Nota 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

• STOP_REQUESTED: la richiesta di stop compute fleet viene inviata al cluster.

• STOPPING: il pcluster processo sta attualmente arrestando il parco di computer.

• STOPPED: il pcluster processo ha terminato il processo di arresto, tutte le partizioni sono in INACTIVE stato e tutte le istanze di calcolo sono terminate.

• START_REQUESTED: la 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 terminato il processo di avvio, tutte le partizioni sono nello UP stato e i nodi statici sono disponibili dopo pochi minuti.

• PROTECTED: questo stato indica che alcune partizioni presentano errori di bootstrap costanti. Le partizioni interessate sono inattive. Esamina il problema e poi corri update-compute-fleet a riattivare il parco veicoli.

• 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 job segnaposto che richiede un certo numero di nodi e quindi fare affidamento su di esso Slurm per aumentare il numero richiesto di nodi.

• Spegnete prima i nodi dinamici 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 reimposta 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 arresta tutti i nodi statici in una partizione specifica

  Imposta una coda specifica INACTIVE come utente root con il comando: su

  $ scontrol update partition=queuename state=inactive

  In questo modo si interrompono tutte le istanze che supportano i nodi nella partizione.

• Abilita una coda (partizione)

  Imposta una coda specifica per un utente su root con il UP comando:

  $ scontrol update partition=queuename state=up

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]

• ResumeProgramAvvia due istanze Amazon EC2 e assegna gli indirizzi IP e i nomi host privati diqueue1-dy-spotcompute1-[1-2], in attesa ResumeTimeout (il periodo predefinito è 30 minuti) prima di reimpostare i nodi.

• Le istanze vengono configurate e si uniscono al cluster. Un job inizia a essere eseguito sulle istanze.

• Il job viene completato e l'esecuzione viene interrotta.

• Al termine della configurazione SuspendTime (che è impostata su 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.

• SuspendProgramviene chiamato per due nodi. I nodi rimangono nello POWER_DOWN stato, ad esempio, rimanendo idle% per un SuspendTimeout (il periodo predefinito è 120 secondi (2 minuti)). Dopo aver clustermgtd rilevato che i nodi si stanno spegnendo, termina 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'accensione per lavori futuri.

Se le cose vanno male e un'istanza per un particolare nodo non può essere avviata per qualche motivo, si verifica quanto segue:

• Lo scheduler riceve un job che richiede due nodi.

• Lo scheduler trasferisce due nodi cloud bursting POWER_UP allo stato e chiama ResumeProgram con i nomi dei nodi (ad esempio). queue1-dy-spotcompute1-[1-2]

• ResumeProgramavvia solo una (1) istanza Amazon EC2 e la configuraqueue1-dy-spotcompute1-1, con una (1) istanza, che non riesce ad avviarsi. queue1-dy-spotcompute1-2

• queue1-dy-spotcompute1-1non è interessato e torna online dopo aver raggiunto lo stato. POWER_UP

• queue1-dy-spotcompute1-2passa allo POWER_DOWN stato e il lavoro viene richiesto automaticamente perché Slurm rileva un errore del nodo.

• queue1-dy-spotcompute1-2diventa disponibile dopo SuspendTimeout (l'impostazione predefinita è 120 secondi (2 minuti)). Nel frattempo, il lavoro viene messo in coda e può iniziare a essere eseguito su un altro nodo.

• Il processo precedente si ripete finché il job 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 di passare il 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 reimpostare 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ù breve SuspendTimeout significa 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 tenta di utilizzare altri nodi. Se SuspendTimeout sono trascorsi più di qualche minuto, Slurm tenta di scorrere tutti i nodi del sistema. Una soluzione più lunga SuspendTimeout potrebbe essere utile per i sistemi su larga scala (oltre 1.000 nodi) per ridurre lo stress causato dal tentativo di riaccodare frequentemente i lavori non riusciti. Slurm

  • Nota che SuspendTimeout non si riferisce al tempo di AWS ParallelCluster attesa necessario 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 viene in genere completato in pochi minuti. Tuttavia, durante questo periodo, il nodo rimane nello POWER_DOWN stato e non è disponibile per l'uso dello scheduler.

• 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)

• 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 l'attivazione di autorizzazioni errate ResumeProgram potrebbe causare un errore invisibile.

  • Se ResumeProgram viene chiamato, controlla se è stata avviata un'istanza per il nodo. Se l'istanza non è stata avviata, dovrebbe essere visualizzato un chiaro messaggio di errore che indica il motivo per cui l'istanza non è stata avviata.

  • Se è stata avviata un'istanza, potrebbe esserci stato qualche problema durante il processo di bootstrap. Trova l'indirizzo IP privato e l'ID dell'istanza corrispondenti nel ResumeProgram log e guarda i log di bootstrap corrispondenti per l'istanza specifica in CloudWatch Logs.

• Nodi statici:

  • Controlla il clustermgtd registro per vedere se sono state avviate istanze per il nodo. Se le istanze non vengono avviate, dovrebbero esserci chiari errori 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 nel clustermgtd log e guarda i log di bootstrap corrispondenti per l'istanza specifica in CloudWatch Logs.

• replaced/terminated Nodi inaspettatamente:

  • Nella maggior parte dei casi, clustermgtd gestisce tutte le azioni di manutenzione dei nodi. Per verificare se un nodo è stato clustermgtd sostituito o terminato, controlla il clustermgtd registro.

  • Se il nodo clustermgtd viene sostituito o terminato, dovrebbe essere visualizzato un messaggio che indica il motivo dell'azione. Se il motivo è correlato allo scheduler (ad esempio, il nodo eraDOWN), controlla nel slurmctld registro per maggiori dettagli. Se il motivo è correlato ad Amazon EC2, utilizza strumenti come Amazon CloudWatch o la console, l'interfaccia a riga di comando o gli SDK di Amazon EC2 per controllare lo stato o i log di quell'istanza. Ad esempio, puoi verificare se l'istanza ha avuto eventi pianificati o non ha superato i controlli sullo stato di salute di Amazon EC2.

  • Se clustermgtd non ha terminato il nodo, controlla se il nodo è computemgtd stato terminato o se EC2 ha terminato l'istanza per recuperare un'istanza Spot.

• Errori del nodo:

  • Nella maggior parte dei casi, i lavori vengono richiesti automaticamente in caso di errore di un nodo. Esamina il slurmctld registro per vedere perché un job o un nodo non è riuscito e valuta la situazione da lì.

• In generale, clustermgtd gestisce tutte le azioni di terminazione delle istanze previste. Esamina il clustermgtd registro per capire perché non è riuscito a sostituire o terminare un nodo.

• Se i nodi dinamici non ScaledownIdletime funzionano, 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. La chiusura e il NodeAddr ripristino di tutte le istanze vengono completati da. clustermgtd Slurmpassa i nodi a dopo. IDLE SuspendTimeout

• AWS ParallelCluster non prende decisioni sull'allocazione delle mansioni o sulla scalabilità. Cerca solo di avviare, terminare e mantenere le risorse secondo Slurm le sue istruzioni.

  Per problemi relativi all'allocazione dei lavori, all'allocazione dei nodi e alle decisioni di scalabilità, consulta il slurmctld registro per eventuali errori.