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:

- 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

ACCESSO

HOME E STORAGE DATI

ESECUZIONE DI UN JOB

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

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

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-->