View a markdown version of this page

Slurm guida per la modalità di coda multipla - AWS ParallelCluster
Panoramica diCiclo di vita dei nodi cloudLavorare con un nodo disponibileStati e invio del lavoroStato e caratteristiche del nodoStati delle partizioniavvio e arresto di pclusterControllo manuale delle codeComportamento e regolazioni del ridimensionamentoRegistri per la nuova architetturaProblemi comuni e modalità di debug:

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

Slurm guida per la modalità di coda multipla

AWS ParallelCluster la versione 2.9.0 ha introdotto la modalità a coda multipla e una nuova architettura di ridimensionamento per (). Slurm Workload Manager Slurm

Le sezioni seguenti forniscono una panoramica generale sull'utilizzo di un Slurm cluster con l'architettura di scalabilità appena introdotta.

Panoramica di

La nuova architettura di scalabilità si basa sulla Slurm Cloud Scheduling Guide e sul plug-in per il risparmio energetico. Per ulteriori informazioni sul plug-in per il risparmio energetico, consulta la Slurm Power Saving Guide. Nella nuova architettura, le risorse che possono essere potenzialmente rese disponibili per un cluster sono in genere predefinite nella Slurm configurazione come nodi cloud.

Ciclo di vita dei nodi cloud

Durante il loro ciclo di vita, i nodi cloud entrano in diversi se non tutti i seguenti stati:POWER_SAVING, POWER_UP (pow_up), () e ALLOCATED (alloc). POWER_DOWN pow_dn In alcuni casi, un nodo cloud potrebbe entrare nello OFFLINE stato. L'elenco seguente descrive in dettaglio diversi aspetti di questi stati nel ciclo di vita dei nodi cloud.

  • Un nodo in uno POWER_SAVING stato viene visualizzato con un ~ suffisso (ad esempioidle~) in. sinfo In questo stato, non esiste alcuna istanza EC2 a supporto del 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

  • Quando Slurm assegna un job a un nodo in uno POWER_SAVING stato, il nodo passa automaticamente a uno stato. POWER_UP Altrimenti, i nodi possono essere inseriti nello POWER_UP stato manualmente utilizzando il scontrol update nodename=nodename state=power_up comando. In questa fase, ResumeProgram viene richiamato e le istanze EC2 vengono avviate e configurate per eseguire il backup di un nodo. POWER_UP

  • Un nodo attualmente disponibile per l'uso viene visualizzato senza alcun suffisso (ad esempio) in. idle sinfo Dopo che il nodo è stato configurato 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 in EC2 sia uguale al numero di nodi disponibili. Nella maggior parte dei casi, i nodi statici sono sempre disponibili dopo la creazione del cluster.

  • Un nodo che sta passando a POWER_DOWN uno stato viene visualizzato con un % suffisso (ad esempioidle%) in. sinfo I nodi dinamici entrano automaticamente POWER_DOWN nello stato successivo. scaledown_idletime Al contrario, i nodi statici nella maggior parte dei casi non sono spenti. Tuttavia, i nodi possono essere inseriti nello POWER_DOWN stato manualmente utilizzando il scontrol update nodename=nodename state=powering_down comando. In questo stato, l'istanza associata a un nodo viene terminata e il nodo viene ripristinato allo POWER_SAVING stato per un successivo scaledown_idletime utilizzo futuro. L'scaledown-idletimeimpostazione viene salvata nella Slurm configurazione come SuspendTimeout impostazione.

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

Consideriamo ora gli stati dei nodi mostrati nell'esempio seguente. sinfo

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1  idle% gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite      2   mix# ondemand-dy-c52xlarge-[1-2]
ondemand     up   infinite     18  idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

I efa-st-c5n18xlarge-1 nodi spot-st-t2large-[1-2] e hanno già delle istanze di backup configurate e sono disponibili per l'uso. I ondemand-dy-c52xlarge-[1-2] nodi sono nello POWER_UP stato e dovrebbero essere disponibili entro pochi minuti. Il gpu-dy-g38xlarge-1 nodo è nello POWER_DOWN stato e passerà allo POWER_SAVING stato dopo scaledown_idletime (il valore predefinito è 120 secondi).

Tutti gli altri nodi sono in POWER_SAVING stato e non sono supportati da istanze EC2.

Lavorare con un nodo disponibile

Un nodo disponibile è supportato da un'istanza EC2. Per impostazione predefinita, il nome del nodo può essere utilizzato per accedere direttamente SSH all'istanza (ad esempiossh efa-st-c5n18xlarge-1). L'indirizzo IP privato dell'istanza può essere recuperato utilizzando il scontrol show nodes nodename comando e controllando il NodeAddr campo. Per i nodi che non sono disponibili, il NodeAddr campo non deve puntare a un'istanza EC2 in esecuzione. Piuttosto, dovrebbe essere lo stesso del nome del nodo.

Stati e invio del lavoro

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 job includono nodi in uno POWER_SAVING stato, il job inizia con uno CF stato, o. CONFIGURING A questo punto, il job attende che i nodi nello stato passino allo POWER_SAVING POWER_UP stato e diventino disponibili.

Dopo che tutti i nodi allocati per un job sono disponibili, il job passa allo 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 lavoro. -p

Tutti i nodi sono configurati con le seguenti funzionalità, che possono essere utilizzate nei comandi di invio dei lavori:

  • Un tipo di istanza (ad esempioc5.xlarge)

  • Un tipo di nodo (questo è uno dynamic ostatic.)

È possibile visualizzare tutte le funzionalità disponibili per un particolare nodo utilizzando il scontrol show nodes nodename comando e controllando l'AvailableFeatureselenco.

Un'altra considerazione riguarda i posti di lavoro. Considerate innanzitutto lo stato iniziale del cluster, che potete visualizzare eseguendo il sinfo comando.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite     10  idle~ gpu-dy-g38xlarge-[1-10]
ondemand     up   infinite     20  idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Nota che spot è la coda predefinita. È indicata dal suffisso. *

Invia un lavoro a un nodo statico alla coda predefinita (). spot

$ sbatch --wrap "sleep 300" -N 1 -C static

Invia un lavoro a un nodo dinamico della EFA coda.

$ sbatch --wrap "sleep 300" -p efa -C dynamic

Invia un lavoro a otto (8) c5.2xlarge nodi e due (2) t2.xlarge nodi alla ondemand coda.

$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"

Invia un lavoro a un nodo GPU alla coda. gpu

$ sbatch --wrap "sleep 300" -p gpu -G 1

Considerate ora lo stato dei lavori utilizzando il comando. squeue

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                12  ondemand     wrap   ubuntu CF       0:36     10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
                13       gpu     wrap   ubuntu CF       0:05      1 gpu-dy-g38xlarge-1
                 7      spot     wrap   ubuntu  R       2:48      1 spot-st-t2large-1
                 8       efa     wrap   ubuntu  R       0:39      1 efa-dy-c5n18xlarge-1

I job 7 e 8 (nelle efa code spot e) sono già in esecuzione (R). I job 12 e 13 sono ancora in fase di configurazione (CF), probabilmente in attesa che le istanze diventino disponibili.

# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      3  idle~ efa-dy-c5n18xlarge-[2-4]
efa          up   infinite      1    mix efa-dy-c5n18xlarge-1
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1   mix~ gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite     10   mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand     up   infinite     10  idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      1    mix spot-st-t2large-1
spot*        up   infinite      1   idle spot-st-t2large-2

Stato e caratteristiche del nodo

Nella maggior parte dei casi, gli stati dei nodi sono completamente gestiti in AWS ParallelCluster base ai processi specifici del ciclo di vita dei nodi cloud descritti in precedenza in questo argomento.

Tuttavia, sostituisce o interrompe AWS ParallelCluster anche i nodi non integri DOWN e i nodi con istanze di DRAINED supporto non integre. Per ulteriori informazioni, consulta clustermgtd.

Stati delle partizioni

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

avvio e arresto di pcluster

Quando pcluster stop viene eseguito, tutte le partizioni vengono inserite nello INACTIVE stato e i AWS ParallelCluster processi mantengono le partizioni nello stato. INACTIVE

Quando pcluster start viene eseguito, tutte le partizioni vengono inizialmente collocate nello stato. UP Tuttavia, AWS ParallelCluster i processi non mantengono la partizione in uno UP stato. È 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. Se initial_count è maggiore dimax_count, initial_count potrebbe non essere soddisfatto quando lo stato della partizione viene modificato. UP

Quando pcluster start e pcluster stop sono in esecuzione, è possibile verificare lo stato del cluster eseguendo il pcluster status comando e selezionando. ComputeFleetStatus Di seguito sono elencati gli stati possibili:

  • STOP_REQUESTED: la pcluster stop richiesta viene inviata al cluster.

  • STOPPING: il pcluster processo sta attualmente arrestando il cluster.

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

  • START_REQUESTED: la pcluster start richiesta 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 in UP stato e i nodi statici saranno disponibili dopo alcuni minuti.

Controllo manuale delle code

In alcuni casi, potrebbe essere necessario avere un controllo manuale sui nodi o sulla coda (nota come partizione inSlurm) di un cluster. È possibile gestire i nodi in un cluster tramite le seguenti procedure comuni.

  • Accendi i nodi dinamici in POWER_SAVING stato: esegui il scontrol update nodename=nodename state=power_up comando o invia un sleep 1 job segnaposto che richiede un determinato numero di nodi e fai affidamento su di esso Slurm per alimentare il numero richiesto di nodi.

  • Spegni prima i nodi dinamiciscaledown_idletime: imposta i nodi dinamici su DOWN con il comando. scontrol update nodename=nodename state=down 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. Non è necessario alcun intervento manuale. Pertanto, ti consigliamo di provare a impostare i nodi su DOWN quando possibile.

  • Disabilita una coda (partizione) o interrompi tutti i nodi statici in una partizione specifica: imposta in modo specifico la coda con il comando. INACTIVE scontrol update partition=queue name state=inactive In questo modo si interrompono tutte le istanze che supportano i nodi nella partizione.

  • Abilita una coda (partizione): imposta una coda specifica con il comando. INACTIVE scontrol update partition=queue name state=up

Comportamento e regolazioni del ridimensionamento

Ecco un esempio del normale flusso di lavoro di ridimensionamento:

  • Lo scheduler riceve un lavoro che richiede due nodi.

  • Lo scheduler trasferisce due nodi in uno POWER_UP stato e chiama ResumeProgram con i nomi dei nodi (ad esempio). queue1-dy-c5xlarge-[1-2]

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

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

  • Il lavoro è terminato.

  • Al termine della configurazione SuspendTime (che è impostata suscaledown_idletime), le istanze vengono impostate POWER_SAVING nello stato dallo scheduler. Lo Scheduler imposta lo queue1-dy-c5xlarge-[1-2] POWER_DOWN stato e chiama 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, si configura queue1-dy-c5xlarge-[1-2] in stato di inattività e reimposta l'indirizzo IP privato e il nome host in modo che possano essere nuovamente accesi per lavori futuri.

Ora, se le cose vanno male e un'istanza per un particolare nodo non può essere avviata per qualche motivo, accade quanto segue.

  • Scheduler riceve un lavoro che richiede due nodi.

  • Scheduler imposta POWER_UP lo stato di due nodi cloud bursting e chiama ResumeProgram con i nomi dei nodi (ad esempio). queue1-dy-c5xlarge-[1-2]

  • ResumeProgramavvia solo una (1) istanza EC2 e si configuraqueue1-dy-c5xlarge-1, ma non è riuscito ad avviare un'istanza per. queue1-dy-c5xlarge-2

  • queue1-dy-c5xlarge-1non sarà interessato e sarà online dopo aver raggiunto lo stato. POWER_UP

  • queue1-dy-c5xlarge-2viene inserito nello POWER_DOWN stato e il lavoro viene messo in coda automaticamente perché Slurm rileva un errore del nodo.

  • queue1-dy-c5xlarge-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 viene ripetuto finché il lavoro non può essere eseguito su un nodo disponibile senza che si verifichi un errore.

Sono disponibili due parametri di temporizzazione che possono essere regolati se necessario.

  • ResumeTimeout(l'impostazione predefinita è 60 minuti (1 ora)): ResumeTimeout controlla il tempo di Slurm attesa prima di mettere il nodo in stato inattivo.

    • Potrebbe essere utile estenderlo se il processo di pre/post installazione richiede quasi così tanto tempo.

    • Questo è anche il tempo massimo di AWS ParallelCluster attesa prima di sostituire o 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. Successivamente, AWS ParallelCluster i processi sostituiscono il nodo anche quando rileva che l'istanza è terminata.

  • SuspendTimeout(l'impostazione predefinita è 120 secondi (2 minuti)): SuspendTimeout controlla la velocità con cui i nodi vengono reinseriti nel sistema e pronti per l'uso.

    • Un valore più breve SuspendTimeout significherebbe che i nodi verranno ripristinati più rapidamente ed Slurm è in grado di provare ad avviare le istanze più frequentemente.

    • Una lunghezza SuspendTimeout fa sì che i nodi falliti si reimpostino più lentamente. Nel frattempo, si sforza di Slurm utilizzare altri nodi. Se SuspendTimeout sono trascorsi più di qualche minuto, Slurm prova a 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 dovuto al frequente riaccodamento dei lavori non riusciti. Slurm

    • Nota 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 viene in genere completato in pochi minuti. Tuttavia, durante questo periodo, il nodo rimane spento e non è disponibile per l'uso nello scheduler.

Registri per la nuova architettura

L'elenco seguente contiene i log chiave per l'architettura a coda multipla. Il nome del flusso di log utilizzato con Amazon CloudWatch Logs ha il formato{hostname}.{instance_id}.{logIdentifier}, logIdentifier seguito dai nomi dei log. Per ulteriori informazioni, consulta Integrazione con Amazon CloudWatch Logs.

  • ResumeProgram:

    /var/log/parallelcluster/slurm_resume.log (slurm_resume)

  • SuspendProgram:

    /var/log/parallelcluster/slurm_suspend.log (slurm_suspend)

  • clustermgtd:

    /var/log/parallelcluster/clustermgtd.log (clustermgtd)

  • computemgtd:

    /var/log/parallelcluster/computemgtd.log (computemgtd)

  • slurmctld:

    /var/log/slurmctld.log (slurmctld)

  • slurmd:

    /var/log/slurmd.log (slurmd)

Problemi comuni e modalità di debug:

Nodi che non sono riusciti ad avviare, accendere o unirsi al cluster:

  • Nodi dinamici:

    • Controlla il ResumeProgram registro per vedere se ResumeProgram è mai stato chiamato con il nodo. In caso contrario, controlla il slurmctld registro per determinare se hai Slurm mai provato a chiamare ResumeProgram con il nodo. Tieni presente che 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 può essere 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. In caso contrario, dovrebbero esserci chiari errori sul motivo per cui le istanze non sono state avviate.

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

Nodi sostituiti o terminati in modo imprevisto, errori dei nodi

  • 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 a EC2, utilizza gli strumenti per controllare lo stato o i log relativi a quell'istanza. Ad esempio, puoi verificare se l'istanza ha avuto eventi pianificati o se i controlli sullo stato di salute di EC2 non sono riusciti.

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

  • Errori del nodo

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

Errore durante la sostituzione o la chiusura delle istanze, errore durante lo spegnimento dei nodi

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

  • Per i nodi dinamici che non funzionanoscaledown_idletime, guarda nel SuspendProgram registro per vedere se un programma utilizza slurmctld 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 daclustermgtd. Slurminserisce i nodi in IDLE afterSuspendTimeout.

Altri problemi

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

    Per problemi riguardanti l'allocazione dei lavori, l'allocazione dei nodi e le decisioni sulla scalabilità, consulta il slurmctld registro per individuare eventuali errori.