1) aggiornare /etc/slurm/slurm.conf

2) copiarlo su tutti i nodi (tutti!) ssh -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

MODIFICARE LO SCRIPT

lo script di esempio si deve modificare in molte parti:

#!/bin/bash            OBBLIGATORIA
#SBATCH --chdir=/mnt/ssd/puglisi/       OBBLIGATORIA (ma cambiare "puglisi" nel vostro user)
#SBATCH --job-name=test                 OBBLIGATORIA (ma potete  cambiare a piacimento il nome "test")
#SBATCH --output=res.txt                UTILE (e "res.txt" si può cambiare, 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 .     OBBLICATORIA (il vostro programma/simulazione deve essere copiato da dove si trova a dove siete ora)
srun ./disks                            OBBLIGATORIA (esegue la simulazione)
mv * /home/puglisi/prova                IMPORTANTE (copiate i dati che ha generato il vostro programma in una cartella nella home, da modificare a piacere)
cd ..                                   IMPORTANTE (uscite dalla dir)
rmdir nuovadirectory                    IMPORTANTE (cancellate la dir che non serve più)

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 segliete 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 (evitando di sovrascrivere altri dati); infine le ultime due righe servono per 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

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

#!/bin/bash

#SBATCH --chdir=/mnt/ssd/puglisi/

#SBATCH --job-name=test

#SBATCH --output=res.txt

#SBATCH --ntasks=1

mkdir nuovadirectory

cd nuovadirectory

cp /home/nomeutente/eseguibili/eseguibile .

srun ./eseguibile

mv res.txt /home/puglisi/dovevoglio

mv altririsultati.dat /home/puglisi/dovevoglio

cd ..

rmdir nuovadirectory

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, la prima riga e' obbligatoria ma va personalizzata (al posto di puglisi dovete mettere il vostro username); il jobname e' a piacere; l'output e' solo il nome del file in cui viene scritto lo stdout (cioe' tutto quello che nei vostri codici esce da una printf a video, non su file); la riga con ntasks e' opzionale; 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 segliete voi; le righe finali ("mv ....") vanno personalizzate con molta attenzione: e' vostra cura spostare tutto quello che e' stato prodotto dalla simulazioni nella home, in una directory apposita (evitando di sovrascrivere altri dati); infine le ultime due righe servono per 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)

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

-- Andrea Puglisi - 2020-12-01

Comments

<--/commentPlugin-->