CRESCO: Descrizione del
Cluster CRESCO8 di Portici
SOMMARIO:
- Caratteristiche del Cluster
- Nodi di front-end
- Accesso
- File System
- Compilatori e librerie numeriche
- Uso di Modules
- Flavour MPI presenti
- Vtune Profiler
- GPU Intel
- Come sottomettere un job
1. Caratteristiche del cluster
Il cluster CRESCO8 di Portici è un sistema di calcolo costituito da
793 nodi di calcolo, divisi in tre partizioni:
- 760 nodi CPU, ognuno con 2 socket da 64 core Intel(R) Xeon(R) Platinum 8592+ con frequenza di clock variabile tra 1.9GHz e 3.8GHz e 512 GB di RAM.
- 17 nodi GPU, ognuno con 2 socket da 64 core Intel(R) Xeon(R) Platinum 8592+ con frequenza di clock variabile tra 1.9GHz e 3.8GHz, 512 GB di RAM e 4 GPU Intel(R) Data Center GPU Max 1550 (Ponte Vecchio), ognuna con 128 Xe core e 128 GB di memoria HBM2e suddivisi su due unità di calcolo (tiles).
- 15 nodi HBM, ognuno con 2 socket da 56 core Intel(R) Xeon(R) CPU Max 9480 con frequenza di clock variabile tra 1.9GHz e 3.5GHz, 1024 GB di RAM e 128 GB di memoria HBM.
In aggiunta, ogni nodo ha:
- Una interfaccia Mellanox-NDR da 200Gb/s
- Una interfaccia GbE da 25Gb/s
- Supporto BMC/IPMI e software per la gestione remota della
console
Si hanno quindi a disposizione un totale di 101136 core e 68 GPU (136 GPU tiles) connessi tra loro da una
rete a larga banda e bassa latenza basata su Mellanox-NDR a 200 Gb/s.
L'architettura di un nodo CPU di CRESCO8 è riconducibile al seguente
schema:
[sommario]
2. Nodi di front-end
L'utilizzo del cluster avviene facendo il login su uno dei nodi di
front-end. I nodi di front-end servono semplicemente per il lancio
delle applicazioni tramite SLURM, per editare i propri script di
lancio o per le compilazioni. I nodi di calcolo sono raggiungibili
solo tramite SLURM.
Per il cluster CRESCO8 si hanno a disposizione i front-end:
- cresco8x001.portici.enea.it
- cresco8x002.portici.enea.it (anche per job interattivi)
- cresco8-gpu01.portici.enea.it (nodo con gpu intel)
[sommario]
3. Accesso
Per accedere al sistema tramite "SSH" è sufficiente collegarsi
direttamente ad uno dei nodi di front-end indicati in precedenza se
il proprio PC è collegato alla LAN di uno dei Centri ENEA.
Dall'esterno collegarsi invece ad uno dei nodi di front-end di
ENEAGRID (meglio se uno di Portici) elencati QUI, e poi ai front-end di CRESCO8.
L'accesso ai front-end di ENEAGRID può avvenire anche via web dalla
pagina di
CRESCO (www.cresco.enea.it) mediante l'interfaccia legacy FARO/THINLINC o la nuova interfaccia basata su OpenOnDemand.
Il servizio di trasferimento dati da e verso gli storage LUSTRE e AFS, basato su due server di I/O, in modalità round-robin è accessibile attraverso l'alias cresco-io.portici.enea.it (alias di cresco-io1/cresco-io2), anche da rete esterna all’ENEA.
Analogamente a cresco-scp.portici.enea.it per il mondo CRESCO6/GPFS/AFS, tale servizio permette di eseguire operazioni di trasferimento dati esclusivamente attraverso i comandi:
scp
sftp
rsync
rclone
[sommario]
4. File system
I file system disponibili su CRESCO8 sono:
-
AFS il file system geograficamente distribuito comune a
tutta ENEAGRID.
Informazioni sulla struttura comune della HOME per tutti gli
utenti di ENEAGRID/CRESCO si trovano nella sezione "File
space and user HOME directory" consultabile qui.
Informazioni di base su AFS per gli utenti di ENEAGRID/CRESCO si
trovano qui.
5. Compilatori e librerie numeriche
Nella tabella seguente sono riportati i compilatori e le librerie
numeriche presenti su CRESCO8.
|
GNU (11.4.1) |
Intel (OneAPI2023.2) |
Intel (OneAPI2025.1) |
| PATH compilatori |
/usr/bin |
/opt/intel/oneapi2023.2/compiler/2023.2.0/linux/bin/intel64 |
/opt/intel/oneapi2025.1/compiler/2025.1/bin/ |
PATH
Librerie numeriche |
BLAS/LAPACK/ATLAS
/usr/lib64
/usr/lib/atlas-sse*
/usr/lib64/atlas
/usr/lib64/atlas-sse* |
Intel MKL
/opt/intel/oneapi2023.2/mkl/2023.2.0/lib/intel64
*icc e icpc sono deprecati
|
Intel MKL
/opt/intel/oneapi2025.1/mkl/2025.1/lib
*non ha più icc e icpc
|
6. Uso di Modules.
Sul cluster CRESCO8 l'inizializzazione dell'ambiente per il singolo
utente viene effettuata grazie al software Modules.
Per i dettagli sull'implementazione, sulle scelte fatte e sull'uso
del software è possibile consultare la relativa
documentazione.
Per listare l'elenco degli ambienti disponili si potrà utilizzare il
comando:
- module avail (questo comando elenca, tra gli altri, i
moduli disponibili per gli ambienti paralleli)
La flavour parallela impostata di default per tutti gli utenti è:
- mpi_flavour/openmpi_intel-4.1.7
Se l'utente vuole scegliere una diversa flavour dovrà utilizzare il
comando:
- module switch flavour_attuale flavour_desiderata
Ad esempio se si vuole scegliere la libreria OpenMPI compilata con
GCC si dovrà dare il comando:
- module switch mpi_flavour/openmpi_gcc-4.1.7
A questo punto l'ambiente risulta impostato coerentemente con la
scelta della nuova flavour.
N.B. Per gli utenti che chiamano bash o ksh, affinché Modules riesca
ad impostare correttamente l'ambiente, è necessario
creare nella propria HOME AFS i file .bashrc o .kshrc (oppure
modificarli se giá esistenti) inserendo in testa ad essi delle
opportune righe di codice.
Per il file .bashrc:
if [ -f /usr/share/Modules/init/bash ]
then
. /usr/share/Modules/init/bash
fi
Per il file .kshrc:
if [ -f /usr/share/Modules/init/ksh ]
then
. /usr/share/Modules/init/ksh
fi
[sommario]
7. Flavour MPI presenti.
Le flavour MPI presenti, distinte per compilatore, sono elencate
nella seguente tabella:
|
GNU (version 11.4.1) |
Intel (version OneAPI2023.2) |
Intel (version OneAPI2025.1) |
| OpenMPI |
openmpi_gcc-4.1.7
|
openmpi_intel-4.1.7
|
Nessuna flavour
|
| Intel MPI |
Nessuna flavour |
IntelMPI |
IntelMPI |
[sommario]
8. Vtune Profiler
Per tutti i compilatori Intel si ha a disposizione lo strumento Vtune Amplifier.
Per poter avviare l'applicazione si possono usare i comandi:
amplxe-gui (interfaccia grafica)
amplxe-cl (riga di comando)
Una guida rapida per lo strumento in questione si trova al seguente
link.
[sommario]
9. GPU Intel
Su ognuno dei nodi della partizione accelerata di CRESCO8 sono presenti 4 GPU Intel(R) Data Center GPU Max 1550 (Ponte Vecchio), ognuna con 128 Xe core e 128 GB di memoria HBM2e suddivisi su due unità di calcolo (tiles), che a tutti gli effetti possono essere viste come 8 GPU indipendenti.
Queste GPU supportano l'esecuzione di codici OpenCL e SYCL (NB: NON supportano codice CUDA/ROCm delle GPU NVidia e AMD).
Per visualizzare la lista e monitorare l'utilizzo e i consumi delle GPU di un nodo è possibile usare l'utility xpu-smi. Una guida rapida per lo strumento in questione si trova al seguente
link.
Di seguito alcuni link utili per la programmazione e l'esecuzione di codici che utilizzano le GPU Intel:
[sommario]
10. Come sottomettere un job
Lo scheduler che gestisce le risorse di CRESCO8 e che permette la sottomissione di job batch è SLURM.
Sotto vengono riportate le partizioni SLURM definite per CRESCO8 e vengono proposti alcuni esempi di wrapper di sottomissione per job seriali e job paralleli validi sia per OpenMPI che per IntelMPI. Vengono proposti, altresì, esempi di sottomissione per job ibridi (MPI+openMP).
Partizioni definite su CRESCO8:
- cresco8_cpu - Partizione principale con 754 nodi di calcolo CPU. Sulla partizione si possono sottomettere sia job seriali che paralleli che abbiano un tempo massimo di RUNNING pari a 24 ore.
- cresco8_cpu_dbg - Partizione di debug con 4 nodi di calcolo CPU. Sulla partizione si possono sottomettere sia job seriali che paralleli che abbiano un tempo massimo di RUNNING pari a 1 ora.
- cresco8_hbm - Partizione con 14 nodi di calcolo CPU-HBM con memoria ad alta banda. Sulla partizione si possono sottomettere sia job seriali che paralleli che abbiano un tempo massimo di RUNNING pari a 24 ore.
- cresco8_hbm_dbg - Partizione di debug con 2 nodi di calcolo CPU-HBM con memoria ad alta banda. Sulla partizione si possono sottomettere sia job seriali che paralleli che abbiano un tempo massimo di RUNNING pari a 1 ora.
- cresco8_gpu - Partizione accelerata con 14 nodi di calcolo con GPU Intel. Sulla partizione si possono sottomettere sia job seriali che paralleli che abbiano un tempo massimo di RUNNING pari a 24 ore.
- cresco8_gpu_dbg - Partizione di debug con 4 nodi di calcolo con GPU Intel. Sulla partizione si possono sottomettere sia job seriali che paralleli che abbiano un tempo massimo di RUNNING pari a 1 ora.
Sulla partizione cresco8_cpu sono state definite delle "quality of service" che consentono agli utenti un utilizzo di risorse massimo di 250 nodi di calcolo. La priorità dei job è gestita da un meccanismo di "fairshare" che la abbassa ai job degli utenti che hanno già utilizzato intensamente il sistema.
Di seguito vengono riportati degli esempi di script di sottomissione
per job seriali, job parallei e job ibridi.
•
Esempio per job seriali (nell'esempio riportato il job occuperà un solo core su un nodo)
#!/bin/sh
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --partition=cresco8_cpu
#SBATCH --job-name=serialJOB
#SBATCH --err=%j.err
#SBATCH --out=%j.out
/path/to/exe
|
•
Esempio per job MPI (nell'esempio riportato il job occuperà 20 nodi di CRESCO8 lanciando 128 processi MPI per nodo)
#!/bin/bash
#SBATCH --nodes=20
#SBATCH --ntasks-per-node=128
#SBATCH --partition=cresco8_cpu
#SBATCH --job-name=jobMPI
#SBATCH --err=%j.err
#SBATCH --out=%j.out
mpirun /path/to/exe
|
• Esempio per job ibridi (nell'esempio riportato il job occuperà 20 nodi lanciando due processi MPI per nodo, uno per socket ed ognuno dei 2 processi MPI aprirà 64 threads)
#!/bin/bash
#SBATCH --nodes=20
#SBATCH --ntasks-per-node=2
#SBATCH --cpus-per-task=64
#SBATCH --ntasks-per-socket=1
#SBATCH --partition=cresco8_cpu
#SBATCH --job-name=jobMPI
#SBATCH --err=%j.err
#SBATCH --out=%j.out
export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK}
mpirun --bind-to none /path/to/exe
|
• Esempio per job che utilizzano GPU (nell'esempio riportato il job occuperà 4 nodi lanciando 8 processi MPI per nodo, uno per ogni GPU tile e ognuno dei processi MPI aprirà 16 threads)
#!/bin/bash
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --cpus-per-task=16
#SBATCH --partition=cresco8_gpu
#SBATCH --job-name=jobMPI_GPU
#SBATCH --gres=gpu:8
#SBATCH --err=%j.err
#SBATCH --out=%j.out
export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK}
mpirun /path/to/exe
|
• Esempio per job con pinning esplicito delle GPU ai processi MPI (ogni processo MPI vede una GPU tile, fino a 8 processi per nodo)
#!/bin/bash
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --cpus-per-task=16
#SBATCH --partition=cresco8_gpu
#SBATCH --job-name=jobMPI_GPU_pinning
#SBATCH --gres=gpu:8
#SBATCH --err=%j.err
#SBATCH --out=%j.out
export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK}
mpirun bash -c 'ZE_AFFINITY_MASK=$((PMI_RANK%SLURM_NTASKS_PER_NODE)) /path/to/exe'
|
• Esempio di sottomissione per tutte le tipologie di job:
sbatch script_di_sottomissione
• Gestione del token AFS nei job batch:
Per usufruire del filesystem AFS durante l'esecuzione dei job batch, il token viene generato sui nodi remoti dai demoni di SLURM grazie all'integrazione con AUKS ed all'utilizzo all'interno di AUKS di un "helper script" (eventuale link alla documentazione di AUKS).
AUKS si occupa della generazione del ticket Kerberos sui nodi remoti prelevando le credenziali dell'utente dalla cache dei nodi di login e l'helper script a suo corredo, attraverso una chiamata ad aklog, genera sul ticket Kerberos il relativo token AFS.
Per proteggere il token generato sui nodi remoti si consiglia l'esecuzione degli script di sottomissione all'interno di una pagsh.
Il token generato all'interno di una pagsh, difatti, è "visibile/utilizzabile" dai soli processi figli della pagsh stessa.
Agendo in tal modo si proteggono e distinguono i token generati su un dato nodo di calcolo da più job di uno stesso utente.
Un eventuale comando di unlog eseguito per un dato job distruggerebbe il token generato solo per quel job, se invece il token non fosse protetto in una pagsh il comando di unlog priverebbe di autorizzazione tutti i job dello stesso utente in esecuzione sullo stesso nodo.
Per far questo, negli esempi sopra riportati, va sostituita la riga #!/bin/bash con la riga #!/usr/bin/pagsh ed aggiunto il comando aklog a valle delle direttive #SBATCH.
A titolo di esempio viene riportato lo script di sottomissione per job ibridi che diventerebbe:
#!/usr/bin/pagsh
#SBATCH --nodes=20
#SBATCH --ntasks-per-node=2
#SBATCH --cpus-per-task=64
#SBATCH --ntasks-per-socket=1
#SBATCH --partition=cresco8_cpu
#SBATCH --job-name=jobMPI
#SBATCH --err=%j.err
#SBATCH --out=%j.out
aklog
export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK}
mpirun --bind-to none /path/to/exe
|
• Esempi di sessioni interattive:
Sessione Console:
$ srun --account=enea --nodes=1 --ntasks-per-node=2 -p cresco8_cpu --pty /bin/bash
Sessione Grafica (NB! aggiungere la flag " X" al comando ssh per entrare nel frontend):
$ srun --x11 --account=enea --nodes=1 --ntasks-per-node=2 -p cresco8_cpu octave
• COMANDI UTILI:
squeue #mostra la lista di job al momento in coda nel cluster
scancel #cancella il job <job_id> dalla coda di sottomissione
sattach <job_id>.0 #mostra l'output del job <job_id> in tempo reale
sacct #mostra lista dei job recenti dell'utente
scontrol show job <job_id> #mostra info dettagliate sul job <job_id>
sinfo #mostra info sul numero e lo stato dei nodi del cluster
• LINK UTILI:
[sommario]