Running Jobs¶

Il nostro sistema HPC è condiviso tra molti ricercatori e SSC gestisce l'uso dei sistemi tramite jobs. I jobs sono semplicemente un'assegnazione di risorse che possono essere utilizzate per eseguire processi. SSC utilizza un programma chiamato Slurm, il Simple Linux Utility for Resource Management, per creare e gestire i jobs.

Per eseguire un programma su un cluster, è necessario richiedere risorse a Slurm per generare un job. Le risorse vengono richieste da un nodo di accesso. Successivamente, fornisci comandi per eseguire il tuo programma su quelle risorse richieste (nodi di calcolo).

Richiedere core e nodi¶

Quando esegui jobs con Slurm, devi essere esplicito nella richiesta di core CPU e nodi. Le tre opzioni --nodes o -N, --ntasks o -n e --cpus-per-task o -c possono risultare un po' confuse all'inizio, ma sono necessarie per comprendere come eseguire applicazioni che utilizzano più di una CPU.

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

L'utilizzo di queste opzioni dipenderà dal tipo di parallelismo che stai usando, cioè parallelismo distribuito o in memoria condivisa. Ecco alcune semplici linee guida da seguire:

• --ntasks=#: Numero di "compiti" (utilizzare con il parallelismo distribuito).

• --ntasks-per-node=#: Numero di "compiti" per nodo (utilizzare con il parallelismo distribuito).

• --cpus-per-task=#: Numero di CPU allocate a ciascun compito (utilizzare con il parallelismo in memoria condivisa).

Se un'applicazione è in grado di utilizzare più core, di solito lo fa generando thread e condividendo memoria (multi-threaded) o avviando interi nuovi processi (multi-process). In questo caso, utilizza --cpus-per-task per garantire che le CPU che ti aspetti che il tuo programma utilizzi siano tutte accessibili.

Alcune applicazioni sono scritte per utilizzare lo standard Message Passing Interface (MPI) per essere eseguite su molti nodi di calcolo. Ciò consente a tali applicazioni di scalare il calcolo in un modo non limitato dal numero di core su un singolo nodo. MPI traduce ciò che Slurm chiama compiti in lavoratori o processi separati. Per avere il controllo su come Slurm distribuisce il tuo lavoro, puoi aggiungere i flag --nodes e --ntasks-per-node. Nota che le seguenti condizioni devono essere vere:

ntasks-per-node * nodes >= ntasks

Alcuni programmi MPI sono anche multi-threaded, quindi ciascun processo può utilizzare più CPU. Solo queste applicazioni possono utilizzare --ntasks e --cpus-per-task per eseguire più rapidamente.

Ad esempio, supponiamo che tu abbia bisogno di 16 core, qui ci sono alcuni possibili scenari:

• vuoi un processo che possa utilizzare 16 core per il multi-threading: --ntasks=1 --cpus-per-task=16

• vuoi 4 processi che possano utilizzare 4 core ciascuno per il multi-threading: --ntasks=4 --cpus-per-task=4

• utilizzi MPI e non ti interessa dove siano distribuiti quei core: --ntasks=16

• vuoi avviare 16 processi indipendenti (senza comunicazione): --ntasks=16

• vuoi 16 core distribuiti su nodi distinti: --ntasks=16 --ntasks-per-node=1 oppure --ntasks=16 --nodes=16

• vuoi 16 core distribuiti su nodi distinti e senza interferenze da altri jobs: --ntasks=16 --nodes=16 --exclusive

• vuoi 16 processi distribuiti su 8 nodi in modo da avere due processi per nodo: --ntasks=16 --ntasks-per-node=2

• vuoi 16 processi che rimangano sullo stesso nodo: --ntasks=16 --ntasks-per-node=16

Applicazioni all'interno dei Jobs¶

Ci sono due tipi di jobs: interattivi e in batch. I jobs interattivi ti permettono di digitare comandi mentre il lavoro è in esecuzione. I jobs in batch sono un insieme autonomo di comandi in uno script che viene inviato al cluster per l'esecuzione su un nodo di calcolo.

Sottomissione di Jobs Interattivi¶

I jobs interattivi di Slurm consentono agli utenti di interagire con le applicazioni sul nodo di calcolo. Con un lavoro interattivo, richiederai tempo e risorse. Una volta disponibili, sarai connesso al nodo assegnato e il lavoro terminerà quando esci o quando viene raggiunto il limite di tempo richiesto. Questo è diverso rispetto a un lavoro in batch, dove invii il tuo lavoro per l'esecuzione senza interazione da parte dell'utente.

Per inviare un lavoro interattivo alla partizione generale di calcolo per un singolo processo con 32 core Intel e 50 GB di memoria per 5 ore e 20 minuti, utilizza il comando salloc e le opzioni appropriate come mostrato qui:

salloc --qos=general-compute --partition=defq-noprio  \

--job-name "InteractiveJob" --cpus-per-task=32 \

--ntasks=1 --mem=50G -C INTEL --time=05:20:00

Per completare/finalizzare questo lavoro, digiteremmo exit nella riga di comando.

Sottomissione di Job Batch¶

I jobs in batch sono il tipo di lavoro più comune sui sistemi HPC. I jobs in batch sono provisioni di risorse che eseguono applicazioni su nodi di calcolo e non richiedono supervisione o interazione. I jobs in batch sono comunemente utilizzati per applicazioni che vengono eseguite per lunghi periodi di tempo e non richiedono input manuale da parte dell'utente.

Di seguito è riportata una spiegazione delle opzioni SBATCH utilizzate nei nostri campioni. Queste sono direttive di Slurm e dovrebbero essere comprese prima di inviare un lavoro. Per ulteriori informazioni sulle direttive di Slurm, sulle partizioni e sul QOS, vedi qui.

#!/bin/bash -l

#

# How long the job will run once it begins. If the job runs longer than what is

# defined here, it will be cancelled by Slurm.

# If you make the expected time too long, it will

# take longer for the job to start.

# Format:  dd:hh:mm:ss



#SBATCH --time=00:01:00



#  Define how many nodes you need. We ask for 1 node



#SBATCH --nodes=1



# You can define the number of Cores with --cpus-per-task



#SBATCH --cpus-per-task=32



# How much memory do you need.

# This will define memory (in GB) this job requires.



#SBATCH --mem=20G



# Give your job a name, so you can recognize it in the queue



#SBATCH --job-name="example-debug-job"



# Tell slurm the name of the file to write to



#SBATCH --output=example-debug-job.out



# Tell slurm where to send emails about this job



#SBATCH --mail-user=myemailaddress@institution.edu



# Tell slurm the types of emails to send.

# Options: NONE, BEGIN, END, FAIL, ALL



#SBATCH --mail-type=end



# Tell Slurm which cluster, partition and qos to use to schedule this job.



#SBATCH --partition=debug

#SBATCH --qos=debug

#SBATCH --cluster=zeus

Di seguito ci sono diversi script di esempio che possono essere inviati a Slurm utilizzando il comando sbatch. Gli script in batch devono essere inviati da un nodo di accesso e i comandi all'interno dello script verranno eseguiti su un nodo di calcolo. Utilizziamo alcune delle direttive di Slurm descritte sopra.

Per inviare alla partizione di debug del cluster Zeus, lo script Slurm sarebbe simile a questo:

#!/bin/bash -l

#

#SBATCH --time=00:01:00

#SBATCH --nodes=1

#SBATCH --ntasks-per-node=1

#SBATCH --mem=10000

#SBATCH --job-name="example-debug-job"

#SBATCH --output=example-debug-job.out

#SBATCH --mail-user=myemailaddress@uniroma1.it

#SBATCH --mail-type=end

#SBATCH --partition=debug

#SBATCH --qos=debug

#SBATCH --cluster=zeus



#Let's start some work

echo "Hello world from debug node: "`/usr/bin/uname -n`

#Let's finish some work

Per inviare alla partizione defq-noprio di calcolo del cluster Zeus, lo script Slurm sarebbe simile a questo:

#!/bin/bash -l

#

#SBATCH --time=00:01:00

#SBATCH --nodes=1

#SBATCH --ntasks-per-node=1

#SBATCH --mem=10000

#SBATCH --job-name="example-general-compute-job"

#SBATCH --output=example-general-compute-job.out

#SBATCH --mail-user=myemailaddress@uniroma1.it

#SBATCH --mail-type=end

#SBATCH --partition=defq-noprio

#SBATCH --qos=general-compute

#SBATCH --cluster=zeus



#Let's start some work

echo "Hello world from general-compute node: "`/usr/bin/uname -n`

#Let's finish some work

Job Arrays¶

Un array di jobs è un gruppo di jobs quasi identici inviati con 1 script SLURM. Utilizza la direttiva Slurm --array=<indexes> all'interno del tuo script in batch. Vedi la documentazione di Slurm per ulteriori informazioni.

Questo esempio invia 16 jobs:

#SBATCH <array flag>

--array=1-16

Questo esempio invia 16 jobs, con un limite di 4 jobs in esecuzione simultaneamente:

#SBATCH --array=0-15%4

Job Array Job Number: %A - job array master job ID

Job Array Index Number: %a - individual job index number

Comandi Slurm Utili¶

sbatch¶

Per inviare uno script in batch a Slurm per l'elaborazione:

sbatch slurm.script

Per ulteriori informazioni, visita la documentazione di Slurm su sbatch.

squeue¶

Per vedere tutti i jobs sul cluster:

squeue -M all -u $LOGNAME

Per ulteriori informazioni, visita la documentazione di Slurm su sbatch.

scancel¶

Per cancellare un job sottomesso:

scancel <job_id>

Per ulteriori informazioni, visita la documentazione di Slurm su sbatch.

Per ulteriori comandi di Slurm, visita il manuale dei comandi di Slurm.

Directories, Partitions & QoS di Slurm¶

Slurm consente l'uso di flag per specificare le risorse necessarie per un lavoro. Di seguito è riportata una tabella che descrive alcuni dei flag di risorse più comuni di Slurm, seguita da tabelle che descrivono le partizioni disponibili e le opzioni di Qualità del Servizio (QoS).

Queste sono le partizioni disponibili sul cluster Zeus:

Partizioni riservate¶

I PI che hanno contribuito all'acquisto di nuovo hardware hanno accesso a code riservate illimitate per il loro gruppo. Per avere più informazioni contatta l'assistenza SSC.

Queste allocazioni vengono aggiunte al progetto ColdFront del PI e sono attive per un periodo di 5 anni. Le allocazioni non possono essere rinnovate. I membri del gruppo devono utilizzare la partizione riservata per sfruttare la priorità.

Nel momento in cui i nodi delle partizioni riservate non sono in uso, le risorse verranno rese disponibili da Slurm per l'intera platea di utilizzatori del cluster Zeus.

Costi (SU)¶

Ogni partizione ha un suo specifico costo in Crediti (SU o Service Unit) per l'utilizzo delle risorse (cpu, ram, gpu). I crediti SU vengono assegnati su ColdFront per ogni Progetto, in base alle valutazioni del comitato SSC, e servono per avviare jobs sull'infrastruttura HPC. Una volta terminati i crediti non è più possibile sottomettere nuovi job.

I costi per ogni partizione sono i seguenti:

Una volta scelta la partizione, la formula per calcolare i crediti consumati è la seguente:

Crediti consumati = (CPU_Alloc * CPU(SU) + Mem_Alloc * RAM(SU) + GPU_Alloc * GPU(SU)) * Job_Time

dove:

• CPU_Alloc: Numero di CPU allocate.

• Mem_Alloc: Quantità di memoria allocata in GB.

• GPU_Alloc: Numero di GPU allocate.

• Job_Time: Tempo di esecuzione del job (in ore).

Ad esempio, per la partizione "defq-noprio", la formula è:

  Crediti consumati = (CPU_Alloc * 1.0 + Mem_Alloc * 0.25 + GPU_Alloc * 4.0) * Job_Time

Controllare i crediti (SU) residui¶

Per controllare i crediti residui è disponibile il comando scredits

usage: scredits [-h] [-v] [-V] [-d] [-a ACCOUNT]

Retrieve and display Slurm usage data.

options:
  -h, --help            show this help message and exit
  -v, --verbose         Print debug messages
  -V, --version         Print program version
  -d, --detailed        Show detailed account and user association
  -a ACCOUNT, --account ACCOUNT
                        Account name to filter results

Output di esempio:

[test@localhost ~]$ scredits

Last credits reset: 09/07/2024 00:01
Next credits reset: 31/07/2024 23:59

Account         | Allocation(SU)  | Remaining(SU)   | Used(SU)   | Used(%) |
-----------------------------------------------------------------------------
test_account    | 1000.0          | 1000.0          | 0          | 0.0

E' inoltre possibile controllare l'utilizzo di crediti per singolo utente

[test@localhost ~]$ scredits -d -a test_account

Last credits reset: 09/07/2024 00:01
Next credits reset: 31/07/2024 23:59

------------------------------------------------------------------------------------------
Account              | User            | Consumed (SU)   | % SU Usage      | Used Resources
------------------------------------------------------------------------------------------
test_account         |                 |                 |                 |
                     | test_account    | 0               | 0.00%           | cpu=0, mem=0, gpu=0
                     | test_account2   | 0               | 0.00%           | cpu=0, mem=0, gpu=0
                     |                 |                 |                 |
                     | Total:          | 0/1000          | 0.00%           | cpu=0, mem=0, gpu=0
------------------------------------------------------------------------------------------

Caratteristiche dei Nodi¶

Gli utenti non devono specificare molte informazioni se non si preoccupano di dove venga eseguito il loro lavoro o su quale hardware. Slurm utilizza le informazioni predefinite dal tuo account, dal cluster e dalla partizione per eseguire un lavoro. Se hai bisogno di più rispetto al predefinito, puoi specificare i requisiti hardware utilizzando la direttiva --constraint di Slurm in uno script batch o utilizzando il campo Caratteristiche del Nodo nei moduli delle app OnDemand. Puoi specificare il tipo di CPU come INTEL o AMD o modelli di CPU più specifici. I tipi di GPU possono essere specificati con A100. Per specificare più di una caratteristica, usa il simbolo & tra di esse (ad esempio, --constraint=INTEL&IB richiederà nodi con CPU Intel e la rete ad alta velocità Infiniband).

Il modo migliore per vedere tutte le caratteristiche di Slurm offerte e ciò che è attualmente disponibile è eseguire il comando snodes nel terminale su uno dei server di accesso al cluster.

Priorità del Job¶

Fattori che Determinano la Priorità del Job:

Età - la quantità di tempo che il job ha atteso nella coda

Dimensione del Job - numero di nodi richiesti dal job

Partizione - priorità per una determinata partizione

Fairshare - contributo alla priorità basato sulle risorse di calcolo utilizzate dai membri di un gruppo di ricerca negli ultimi 30 giorni. Maggiore è il numero di job eseguiti nel cluster, minore sarà la priorità. Minore è il numero di job eseguiti, maggiore sarà la priorità.

TRES - Ogni tipo di TRES ha il proprio fattore di priorità per un job, che rappresenta la quantità di tipo TRES richiesta/allocata in una determinata partizione. Maggiore è la quantità di un certo tipo di TRES richiesta/allocata per un job, maggiore sarà la priorità del job stesso. SSC pesa le richieste di memoria e GPU e fornisce una priorità leggermente superiore per queste per consentire una corretta pianificazione dei nostri nodi eterogenei.

Consulta la documentazione di Slurm per ulteriori dettagli sui Calcoli di Priorità Multifattore di SLURM e su Fairshare.

Job Priority Formula:

Job_priority =

(PriorityWeightAge) * (age_factor) +

(PriorityWeightFairshare) * (fair-share_factor) +

(PriorityWeightJobSize) * (job_size_factor) +

(PriorityWeightPartition) * (partition_factor) +

(PriorityWeightQOS) * (QOS_factor)

Pesi assegnati ai Priority Factors di Zeus cluster:

PriorityFlags=NO_NORMAL_PART
PriorityType=priority/multifactor
PriorityFavorSmall=YES
PriorityMaxAge=1-0
PriorityWeightAge=500
PriorityWeightTRES=CPU=1000,Mem=2000,GRES/gpu=3000
PriorityWeightPartition=2000

Per visualizzare il Fairshare:

sshare <flag>

--accounts=group_name

--all --accounts=[YourSlurmAccount]  (Shows fairshare for members of the group)

Mostra Job Priority:

sprio <flag>

-j jobid

-u [CCRusername]

Monitoraggio dei Jobs¶

Monitoraggio dei Job Attivi tramite OnDemand¶

SSC offre una vista dettagliata su ciò che sta accadendo sul(nel) nodo(i) in cui il tuo job è in esecuzione. Puoi visualizzare i grafici da OnDemand, ma NON è necessario inviare i job da OnDemand. Anche i job inviati dalla linea di comando utilizzando 'sbatch' sono disponibili nella tua lista di Job Attivi.

In OnDemand, fai clic sulla freccia accanto a uno dei tuoi job attuali e in basso vedrai due grafici per ciascun nodo su cui il tuo job è in esecuzione. Un grafico mostra le metriche della CPU e l'altro l'utilizzo della memoria (RAM).

Slurm Accounting¶

Le informazioni sull'account Slurm sono disponibili e utili a seconda delle informazioni che stai cercando riguardo ai tuoi job.

Mostra le informazioni sull'account del job per un job specifico:

Se il job è attualmente in esecuzione, otterrai informazioni sul nodo. Se è completato, non riceverai queste informazioni.

sacct -j jobid --format=User,JobID,Jobname,partition,state,time,start,end,elapsed,nnodes,ncpus,nodelist

o slist jobid

Mostra tutte le informazioni sui job a partire da una data specifica per un utente specifico:

sacct -S start-date -u username

Metriche OnDemand¶

Per metriche sulle prestazioni dei job e sull'uso dei nodi dopo il completamento del tuo job, utilizza il portale XDMoD. I dati sui job sono solitamente disponibili 24 ore dopo il completamento di un job. Ulteriori dettagli su XDMoD.