Brevi istruzioni cluster tnt (nato nel 2020 con i fondi PRIN CO-NEST)

Revisione di Marzo 2026 dopo riformattazione delle macchine (in seguito ad attacco hacker di fine 2025)

ACCESSO

a quel punto ci si trova nel nodo di login collegato a 3 server ognuno dei quali ha 128 cpu, per lanciare simulazioni si deve usare il programma "slurm" secondo le istruzioni che seguono

HOME E STORAGE DATI

attenzione: sono cambiate diverse cose, leggete bene

- la home del nodo di login non e' piu' il luogo dove tenere i dati; la sala macchine ci ha concesso uno storage di soli 500Gb che trovate seguendo il path /mnt/data/nomeutente/

- MA (importante) questo nuovo storage e' molto piu' piccolo che in passato, e soprattutto e' piu' piccolo del disco ssd da 1.5Tb che c'e' su ognuno dei 3 nodi, che e' montato (sui nodi) come /home/nomeutente e si puo' vedere dal nodo di login seguendo il path /mnt/ssd1/nomeutente (ssd1 oppure ssd2 oppure ssd3 per i 3 nodi)

- il mio consiglio quindi e' di mettere dentro /mnt/data/nomeutente tutto quel che serve ad eseguire le simulazioni (sorgenti, eseguibili etc.), per questo ho fatto in modo che questo path sia visibile da tutti i nodi, e di eseguire le simulazioni, scrivere i dati e - almeno temporaneamente - tenere i dati sempre sui dischi ssd montati come /home sui nodi;

- anche quei 3 dischi da 1.5Tb si riempiranno presto, quindi vi chiedo di farci aattenzione e periodicamente traslocare i dati su nostri dischi locali fuori dal cluster (anche io faro' dei controlli periodici e se i dischi si stanno riempiendo vi avvertiro')

- il vantaggio di questa soluzione e' che non e' piu' necessario spostare i dati alla fine di ogni simulazione; lo svantaggio e' che i dati creati da una simulazione saranno in uno dei /mnt/ssd$i/nomeutente e non potete saperlo dall'inizio (perche' e' il sistema di code a scegliere il nodo su cui girare); una soluzione per quest'ultimo problema e' spostare comunque i dati alla fine del job (mettendo le necessarie istruzioni alla fine dello script) in una cartella decisa da voi in uno dei 3 dischi, ma in questo caso bisogna coordinarsi tra noi per essere sicuri di non mettere tutti i dati su un disco solo

ESECUZIONE DI UN JOB

i programmi vanno lanciati usando il sistema di code che si occupa di allocare ogni programma sul nodo piu' libero; si prega di non lanciare programmi direttamente da terminale (a parte eccezioni per brevissime prove), perche' questi verrebbero eseguiti dal nodo di login che ha risorse limitate; il modo per eseguire un job tramite sistema di code e' il seguente

1) scrivere uno script di esecuzione, si consiglia di farlo in bash, chiamandolo (ad esempio) submit.sh; qui c'e' un esempio funzionante che vi suggeriamo di seguire (adattandolo un poco con le istruzioni che vedete nei commenti)

#!/bin/bash                         OBBLIGATORIA
#SBATCH --chdir=/home/puglisi/     OBBLIGATORIA (ma cambiare "puglisi" nel vostro user)
#SBATCH --job-name=test                  OBBLIGATORIA (ma ovviamente conviene cambiare il nome "test")
#SBATCH --error=slurm-%A.err          UTILE (in questo file viene scritto stderr)
#SBATCH --output=slurm-%A.out       UTILE (in questo file viene scritto stdout)
#SBATCH --ntasks=1                          UTILE (in particolare se volete occupare più processori ad es. per cose in parallelo)

mkdir nuovadirectory             IMPORTANTE (ogni simulazione dovrebbe girare in una dir diversa per non rischiare che si sovrapponga ad altre)
cd nuovadirectory                                IMPORTANTE (se create una dir ci dovete entrare)
cp /mnt/data/puglisi/eseguibili/bg .       OBBLIGATORIA (il vostro programma/simulazione deve essere in una subdir di /mnt/data/puglisi e va copiato a dove siete ora)
srun ./bg                                          OBBLIGATORIA (esegue la simulazione)

se si vuole mettere i dati in una directory decisa da voi dovete aggiungere le seguenti righe personalizzate con molta attenzione


mkdir /mnt/ssd1/puglisi/nuovirisultati            questo se si sceglie di mettere i dati dentro SSD1
mv * /mnt/ssd1/puglisi/nuovirisultati/ 
cd .. IMPORTANTE (uscite dalla dir se ci eravate entrati)
rm -fr nuovadirectory IMPORTANTE (cancellate la dir che non serve più)
mv "slurm-"$SLURM_JOB_ID".out" /mnt/ssd1/puglisi/nuovirisultati/ UTILE (se volete ritrovare anche il file con lo stdout lo copiate nel posto dove tenete i risultati)
mv "slurm-"$SLURM_JOB_ID".err" /mnt/ssd1/puglisi/rnuoviisultati/ UTILE (se volete ritrovare anche il file con lo stderr lo copiate nel posto dove tenete i risultati)

2) eseguire lo script con il comando

sbatch submit.sh

3) controllare l'esecuzione del job con il comando

squeue

GUIDA VELOCE DEI COMANDI DI SLURM: https://slurm.schedmd.com/pdfs/summary.pdf

ALTRA DOCUMENTAZIONE PER IL SISTEMA DI CODE: il sistema di code si chiama "slurm" ed e' molto ben documentato (ed e' pieno di opzioni), si veda https://slurm.schedmd.com/documentation.html

si puo' trovare anche un tutorial veloce e ben fatto qui: https://support.ceci-hpc.be/doc/_contents/QuickStart/SubmittingJobs/SlurmTutorial.html

esiste anche una guida "tedesca" con una sintesi della documentazione e molti dettagli utili (ma e' piu' per amministratori che altro): https://wiki.fysik.dtu.dk/niflheim/Slurm_configuration

ACCEDERE AI FILE SUI NODI LOCALI: durante l'esecuzione, ogni utente puo' vedere i file che vengono generati durante la simulazione controllando (tramite comando squeue) quale nodo $i sta runnando il processo che vi interessa e poi andando su /mnt/ssd$i/nomeutente

RIPRISTINO DEI NODI DOPO CAMBIO STRUTTURA:

1) aggiornare /etc/slurm/slurm.conf

2) copiarlo su tutti i nodi (tutti!) scp -p /etc/slurm/slurm.conf node1:/etc/slurm/slurm.conf …

3) riavviare i demoni sui nodi (tutti!) ssh node1 systemctl restart slurmd ….

4) riavviare il demone di controllo in locale

systemctl restart slurmctld

5) rimettere in up tutti i nodi (tutti!) (perchè di default il sistema torna allo status precedente che era down)

scontrol update NodeName =node1 State=RESUME … ..

6) controllare che non ci sia niente down

sinfo —a

-- Andrea Puglisi - 2020-12-01