TntCluster < TNTgroup

Tags: view all tags
---+ Brevi istruzioni cluster tnt (nato nel 2020 con i fondi PRIN CO-NEST)

---+++ ACCESSO

ssh -X utente@pgls_login.artov.rm.cnr.it 

---+++ HOME DIRECTORY 

la home di ogni utente si trova in un grande disco esterno da 5Tb (totali); la home e' il luogo dove tenere i vostri dati (backup) e tutti gli script ed eseguibili che si vogliono conservare; la home NON e' il posto dove le simulazioni scrivono durante l'esecuzione

---+++ 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 perche' questi verrebbero eseguiti dal nodo di login che ha pochissime risorse; 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 seguono)

-------------------------------------------------------------------------------------------

<verbatim>
#!/bin/bash
#SBATCH --chdir=/mnt/ssd/puglisi/
#SBATCH --job-name=test
#SBATCH --error=slurm-%A.err
#SBATCH --output=slurm-%A.out
#SBATCH --ntasks=1

mkdir nuovadirectory
cd nuovadirectory

cp /home/puglisi/eseguibili/disks .
srun ./disks
mv * /home/puglisi/risultati
cd ..

rm -fr nuovadirectory
mv "slurm-"$SLURM_JOB_ID".out" /home/puglisi/risultati
mv "slurm-"$SLURM_JOB_ID".err" /home/puglisi/risultati

</verbatim>

---------------------------------------------------------------------------

*2)*  eseguire lo script con il comando

sbatch submit.sh

*3)*  controllare l'esecuzione del job con il comando

squeue

---++++ MODIFICARE LO SCRIPT

lo script di esempio si deve modificare in molte parti:

<verbatim>
#!/bin/bash				             OBBLIGATORIA
#SBATCH --chdir=/mnt/ssd/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 /home/puglisi/eseguibili/disks .       OBBLIGATORIA (il vostro programma/simulazione deve essere copiato da dove si trova a dove siete ora)
srun ./disks                                          OBBLIGATORIA (esegue la simulazione)
mv * /home/puglisi/risultati                   IMPORTANTE (spostate i dati che ha generato il vostro programma in una cartella nella home, da modificare a piacere)
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" /home/puglisi/risultati       UTILE (se volete ritrovare anche il file con lo stdout lo copiate nel posto dove tenete i risultati)
mv "slurm-"$SLURM_JOB_ID".err" /home/puglisi/risultati       UTILE (se volete ritrovare anche il file con lo stderr lo copiate nel posto dove tenete i risultati)
</verbatim>

le righe mkdir e cd vanno modificate con un nome di directory specifico (temporaneo) per quella simulazione (per evitare che diverse simulazioni scrivano sulle stesse directory); l'eseguibile ovviamente lo scegliete voi; le righe finali ("mv ....") vanno personalizzate con molta attenzione: e' vostra cura spostare tutto quello che e' stato prodotto dalla simulazioni e che ritenete necessario conservare dalla dir dove ha girato alla home, in una directory apposita (vostra cura evitare di sovrascrivere altri vostri dati); è anche importante cancellare la directory temporanea dove ha girato la simulazione: facendo in questo modo tutto quel che non viene spostato (con i comandi "mv...") viene perso; ovviamente potete anche non mettere questi comandi alla fine, ma questo significa accumulare dati nei dischi dei nodi rischiando di finire lo spazio (nei nodi lo spazio e' molto minore); gli amministratori periodicamente libereranno spazio nei dischi dei nodi

*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 N sta runnando il processo che vi interessa e poi andando su /mnt/ssd_nodeN/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


-- %USERSIG{AndreaPuglisi - 2020-12-01}%

---++ Comments

%COMMENT%
Topic revision: r6 - 2022-11-15 - AndreaPuglisi