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

ssh -X utente@150.146.131.189

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); la soluzione che abbiamo trovato e' il "mergerfs" che e' un filesystem che fonde i 3 dischi in un path unico: quindi dal nodo di login, se guardate dentro /mnt/nodedata/nomeutente trovate una fusione delle directory /mnt/ssd$i/nomeutente e quindi tutti i dati creati da tutte le vostre simulazioni

- nb: questo mergerfs non puo' fare l'impossibile, cioe' non puo' permettervi di vedere file che hanno stesso identico nome e posizione su due ssd$i diversi, deve fare una scelta e mostrarvi solo uno dei 3 possibili: quel che ho capito e' che - con la configurazione che ho scelto - al momento lui sceglie i file che si trovano nel filesystem con piu' spazio, queste vale in lettura e in scrittura; per evitare di incasinarvi vi consiglio di evitare - al momento di lanciare job - di creare cartelle con lo stesso nome nella stessa posizione

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)

come vedete non sono piu' necessari i comandi finali per spostare indietro i dati: come gia' detto sopra, i dati conviene lasciarli sui dischi dei nodi su cui hanno girato e periodicamente pulire tutto spostando su vostri pc locali

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

SUGGERIMENTI PER SEMPLIFICARE L'ACCESSO DA REMOTO (idee da Andrea Baldassarri)

1) da casa si può usare questa sintassi per fare in un colpo solo doppio accesso (all'ip intermedio abilitato per l'accesso - che chiamo "ponte" - e poi subito al nodo di login del cluster)

ssh -XJ cognome@ponte cognome@150.146.131.189

con questo comando vi verrà chiesta prima la password per il ponte e poi la password per il cluster

2) si può evitare di digitare entrambe le password usando il sistema a chiave crittografica, nel seguente modo

sul computer di casa eseguire il comando

ssh-keygen

che genera una chiave pubblica (un file .pub in genere nella cartella .ssh, ad esempio sul mac mi ha creato .ssh/id_ed25519.pub), poi copiare con scp questo file nella home del ponte, poi entrare nel ponte e usare di nuovo scp per copiare il file .pub nel nodo di login del cluster, infine entrare nel cluster e dare il comando

cat id_ed25519.pub >> .ssh/authorized_keys

fatto questo il passaggio ssh casa->ponte->cluster spiegato al punto 1 si effettua senza password

3) Se al comando ssh aggiungi anche alla fine "-t byobu", troverai anche il terminale avanzato (puoi aprirti vari tab, che ritrovi tra un collegamento e l’altro), consigliatissimo, trovate qui un tour musicale che vi spiega le cose molto utili che si possono fare con questo terminale https://www.byobu.org/

4) Utile per spostare file avanti e indietro: scp funziona come ssh e quindi si può usare l'opzione -J per saltare il ponte; per rsync invece bisogna usare

rsync -avz -e “ssh -J utente@ip-intermedio” directory cognome@cluster:destinazione/

(SOLO PER GLI AMMINISTRATORI): 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

Comments