Utilisation du cluster "fabulous"

Cette page a pour but de donner les infos minimales pour utiliser le cluster “fabulous”. Il est fortement conseillé de lire également la doc.

La machine s'appelle fabulous.ltas.ulg.ac.be. Elle est située physiquement à Montéfiore dans une salle gérée par le SeGI qui abritait nic2 (alias “nicdouille” ou “nic is down”).

Son IP est 139.165.41.12. On s'y connecte exclusivement par ssh. Seul le câble 121 (LTAS au B52) est autorisé à s'y connecter, mis à part quelques exceptions. Utilisez donc:

ssh fabulous

De l'extérieur de l'ULg (de chez vous par exemple), il est donc nécessaire de passer par une de nos machines (par un double ssh ou un “remote desktop” sur votre PC puis ssh).

Le cluster est l'équivalent de 14 PCs de calcul (14 “noeuds” nommés de node001 à node014) et un PC maitre (le “master node” nommé fabulous). Chaque noeud de calcul possède 2 CPUs (ou 2 “sockets”) et chaque CPU possède 6 coeurs. On a donc en tout 144 coeurs de calcul. Le master node qui ne sert qu'à éditer / compiler / configurer et gérer le système n'a “que” 2×4 coeurs.

Coté disque, actuellement, chaque utilisateur a accès à son homeDir (/home/$USER) sur le disque système (2To en raid 1 : mirroring) servant à tout ce qui doit être conservé (compilation, résultats post-traités, …) ainsi que d'un répertoire sur le disque scratch1 (/scratch1/$USER) à utiliser en priorité pour l'exécution des simulations. Ces deux espaces disques sont partagés en NFS, ils sont donc visibles des noeuds. Il y a aussi un disque sur chaque noeuds de calcul qui est utilisé durant les simulations (voir options de launch.py). Les données des disques locaux sont automatiquement rapatriés en fin de simulation.

On utilise SFTP (Filezilla par exemple) pour effectuer les transferts de fichiers et backupifier ses trucs.

En RAM, chaque coeur dispose de 4Go. Autrement dit, chaque noeud possède 4×12=48Go de RAM, pour un total de 576Go si on somme les 12 noeuds.

Seul le “master node” a un accès direct à internet. C'est sur lui qu'on se connecte quand on veut travailler. Normalement, il n'est jamais utile de se connecter sur les noeuds, même pour lancer un calcul. Pour l'utilisateur lambda, le cluster est très semblable à une seule machine. Seule la manière de lancer des jobs diffère.

Le cluster ayant été réinstallé récement (05/2017) suite à un crash disk, l'OS installé est Scientific Linux 6 (“SL6” : cad une RedHat Enterprise recompilée par le Cern), le système n'est pas à jour, mais c'est le système le plus récent accessibles avec la licence dont on disposait (un update viendra peut être durant 2017).

La plupart des applications et des libs sont installées sur /cm/shared/apps. Cet emplacement est partagé par NFS et donc visible à partir de tous les noeuds, tout comme les /home et /scratch1 de chaque utilisateur. Pour l'administration, ça simplifie évidemment la gestion au quotidien.

Passons aux choses sérieuses: vous avez fait “ssh fabulous” et vous êtes sur la machine. Pour pouvoir travailler avec Metafor, il faut configurer votre compte.

Avant toute chose, modifiez votre mot de passe:

passwd

Choisissez quelque chose de pas trop simple à deviner.

Une première étape: la config ssh. L’idéal est de pouvoir se connecter sans mot de passe de/à fabulous, grâce à la clef privée que vous avez certainement déjà sur les stations et sur votre PC. Le cluster a déjà créé automatiquement une paire de clefs privée/publique dans votre “.ssh” pour pouvoir se connecter aux noeuds facilement. En ce qui me concerne, j'ai profité de cette occasion pour uniformiser toutes mes clefs sur toutes les machines.

Étape suivante: configurer l'accès à votre compte. Le système de gestion des comptes station défini ici est valide aussi pour Fabulous.

Fabulous et les modules: Le cluster a été conçu pour gérer des tas d'applications et des tas d'utilisateurs. Bien entendu, il faut pouvoir installer plusieurs versions de chaque application et les faire cohabiter pour satisfaire tout le monde. Le cluster propose dans ce but un système de “modules” qui vont permettre de changer facilement son environnement (PATH par exemple) et de passer d'une version à l'autre. En faisant:

boman@fabulous:~ >module list
Currently Loaded Modulefiles:
1) cmake/2.8.4                        9) tetgen/1.4.3
2) samcef/14.0/i8                    10) triangle/1.6
3) swig/2.0.3                        11) gcc/4.3.4
4) python/2.7.1                      12) intel-cl-st/compiler/64/12.0/084
5) qt/4.7.3/gcc                      13) intel-cl-st/mkl/64/10.3/084
6) vtk/5.6.1/gcc                     14) sge/6.2u5
7) isosurf/1.5                       15) matlab/R2009a
8) gmsh/2.5.0

on voit les modules qui sont actuellement chargés sur mon compte. La liste de tous les modules disponibles s'obtient par:

module avail 

On peut modifier la liste des modules chargés par:

module add [nom du module]
module rm [nom du module]

Tout ça pour dire que si on veut travailler avec Metafor, il faut charger au démarrage les modules dont il dépend. Ceci est fait dans le fichier ~/bin/cfg/fabulous/modules.profile chargé au démarrage de votre session via le .bash_profile. Ca donne cela:

module load slurm
 
module load git subversion
module load gcc cmake swig
module load python qt vtk parasolid mumps
#module load gmm trilinos
 
module load samcef gmsh 
module load isosurf tetgen triangle
module load matlab scilab
 
# intel community 
#. /cm/shared/apps/intel-community/2017.2/bin/compilervars.sh intel64
. /cm/shared/apps/intel-community/2017.2/mkl/bin/mklvars.sh intel64
. /cm/shared/apps/intel-community/2017.2/tbb/bin/tbbvars.sh intel64
 
# sinon cmake prend /usr/bin/cc meme si gcc est dans le PATH!
export CC=gcc
export CXX=g++
export FC=gfortran
 
#icc
#export CC=$(which icc)
#export CXX=$(which icpc)
#export FC=$(which ifort)

Notez que sauf application particulière vous n'avez pas besoin de modifier les modules chargés.

Compiler Metafor se fait sur le “master node” (c'est à dire sur fabulous). La procédure peut être faite manuellement ou à l'aide de mon script comp.py qui a été adapté pour l'occasion. “comp.py ” est contenu dans le répertoire “~/bin” que vous avez récupéré lors de la configuration de votre compte.

Lancez “comp.py” à partir d'un répertoire vide préalablement créé:

Actions:
 a/ e-mail address (reports)            : 'papeleux'
 b/ archive name                        : '~/dev.zip'
 c/ build options                       : 'fabulous.cmake'
 d/ debug mode                          : False
 h/ nice value                          : '0'
 j/ nb of task launched in parallel     : '8'
 k/ nb of threads by task               : '1'
 m/ Run Method                          : 'interactive'

 1/ source                              : 'zip'
 2/ compile                             : True
 3/ battery                             : True

 G/ GO
 S/ SAVE
 Q/ QUIT

Your choice?

La configuration fabulous.cmake contient toutes les informations pour compiler par défaut avec le gcc 6.3 recompilé et installé dans /cm/shared/apps/gcc/6.3.0. Configurez l'accès aux sources (checkout, zip, présent) et le mode de compilation : INTERACTIF uniquement (pas de queue at/batch ni de possibilité de compiler sur les noeuds par slurm). Lancez la compilation par “G” et attendez la fin.

Pour lancer un calcul sur les noeuds, il ne faut pas vous connecter sur les noeuds. A partir du Master Node, les tests sont mis en attente dans un système de queues et sont executés en fonction de la disponibilité des ressources (noeuds, mémoire,…). Auparavant, les queues étaient gérées via SGE - Sun Grid Engine (devenu obsolète suite au rachat par Oracle) est remplacé depuis la réinstallation du cluster par Slurm. Notez que la configuration par défaut de Slurm n'ayant pas encore été adaptée à notre utilisation du cluster, elle évoluera certainement.

L'utilitaire “launch.py” (se trouvant, si vous avez bien configuré votre compte, tout comme “comp.py” dans votre “~/bin”) est écrit spécialement pour lancer un ou plusieurs tests Metafor sur les noeuds à travers Slurm.

Une fois organisé un répertoire (BaseDir) contenant l'arborescence des tests et utilitaires à faire tourner et dans lequel les résultats seront écrits (dans le workspace), tapez “launch.py”:

  
Actions:
 b/ exec name                           : '../Metafor/Metafor'
 c/ test filename                       : './banc18ER/casingRotAnalysis/WingletBlade/Coarse3250Eas.py'
 d/ logfile (no ext)                    : 'out'
 e/ algorithm                           : 'meta'
 g/ Run multiple test on dir            : False
 j/ nb of task launched in parallel     : '1'
 k/ nb of threads by task               : '12'
 m/ Run Method                          : 'slurm'
 n/ Queue name                          : 'defq'
 o/ Metafor run on node local disk      : True
 p/ Total Memory (Mb)                   : '5000'
 q/ Time (d-hh:mm:ss)                   : '0-1:00:00'
 u/ ftp transfert                       : False

 G/ GO
 S/ SAVE
 Q/ QUIT

Configurez les chemins vers l'executable Metafor, le test (ou le répertoire contenant les tests si “Run multiple test on dir” = True), le nombre de tests devant s'executer en même temps et le nombre de threads par test (ATTENTION le produit (nbTests * nbThreads) ne peut dépasser le nombre de coeurs sur 1 noeud soit 12).

Choisissez la méthode de run “m” jusqu'à ce que ce soit “slurm” qui soit affiché (voir ci dessus). Metafor est capable d'utiliser le disque de chaque noeud comme répertoire de travail et de copier automatiquement les résultats une fois les simulations terminées (“o/ Metafor run on node local disk : True”). Sauf utilisation particulière ne supportant pas ce mécanisme (restart), utilisez toujours cette option (ca réduit le trafic sur le réseau interne au cluster et limite le risque de corruption des fichiers ouverts à travers le NFS).

Soyez attentif aux paramètres de mémoire ( “p/ Total Memory (Mb) : '1000' ”) et de temps de calcul demandés (“q/ Time (d-hh:mm:ss) : '0-1:00:00' ”), tout dépassement entrainant l'arrêt instantanné des simulations (et pensez aux programmes annexes : un appel à Matlab en post-traitement pouvant faire croitre de manière importante la mémoire…). D'autre part, Slurm peut calculer une priorité de lancement des jobs en fonction des ressources demandées ⇒ une sur-estimation excessive des ressources pourrait induire un temps d'attente important avant lancement du job (si tous les noeuds sont occupés et que de plus petit jobs sont dans la queue).

Une fois que le job est lancé, (“G”) les messages suivant sont affichés

Your choice? go in slurm
sending job 'Tests.banc18ER.casingRotAnalysis.WingletBlade.Coarse3250Eas' to Slurm
Submitted batch job 451
Submission SUCCESSFUL!
        use ' squeue -l -j 451 ' to check the status of the SLURM scheduling queue of your job
        use ' sprio -l -j 451 ' to check the factor priority of your job
        use ' sstat  -a --format=JobID,NTasks,MaxRSS,MaxVMSize -j 451 ' to get information about your running job (adapt format to your needs)
        use ' scancel 451 ' to kill your job
        use ' sacct --format=JobID,NTasks,NCPUS,CPUTime,Elapsed,MaxRSS,MaxVMSize -j 451 ' to get information about your finished job (adapt format to your needs)

squeue donne des informations sur les jobs dans les queues : pour mon job en particulier :

        
squeue -al -j 451
Wed Jun 28 16:08:43 2017
  JOBID PARTITION     NAME     USER    STATE       TIME TIMELIMIT  NODES NODELIST(REASON)
    451      defq  metafor papeleux  RUNNING       2:58   1:00:00      1 node002    

ou pour tous les jobs :

        
squeue -l 
Wed Jun 28 16:05:54 2017
  JOBID PARTITION     NAME     USER    STATE       TIME TIMELIMIT  NODES NODELIST(REASON)
    418      defq  metafor wautelet  RUNNING 16-15:42:29 20-00:00:00      1 node001
    451      defq  metafor papeleux  RUNNING       0:09   1:00:00      1 node002

Les outputs de sprio (actuellement pas de calcul de priorité des jobs ⇒ premier arrivé, premier servis)

sprio -l
You are not running a supported priority plugin
(priority/basic).
Only 'priority/multifactor' is supported.
sstat  -a --format=JobID,NTasks,MaxRSS,MaxVMSize -j 451
       JobID   NTasks     MaxRSS  MaxVMSize
------------ -------- ---------- ----------
sstat: WARNING: We will use a much slower algorithm with proctrack/pgid, use Proctracktype=proctrack/linuxproc or Proctracktype=proctrack/rms with Job accounting gather LINUX plugin
451.0               1    269096K   2142528K

pour plus d'info sur les commandes Slurm, lire Mémo SLURM (basé sur NIC4 dont la config de slurm est plus aboutie).

Des mails sont envoyés par Slurm pour signaler le démarrage, le kill ou la fin du job.

Au lancement de jobs à travers “launch.py”, une série de scripts de gestion sont générés associés au pid dans la queue slurm :

sCancelxxxx.py : permet de killer un job (Attention, cette commande ne gère pas la copie et suppression des fichiers temporaires de calcul sur le disque du noeud de calcul)
cpNodeResultsxxxx.py : copie les fichiers du disque du noeud de calcul (''/local/$USER_pxxxx'') vers le disque courant (/home/$USERS/...)
rmNodeResultsxxxx.py : nettoye le disque du noeud de calcul des fichiers du process xxxx (''rm -rf /local/$USER_pxxxx'')

Vous êtes donc priés de nettoyer les disques locaux si vous supprimez des jobs en cours de calcul.

Nb : le script cleanLocalHdd.py (inclus dans le répository ~/bin) vous permet de voir si vous avez des fichiers trainant sur vos disques locaux et de les nettoyer . Tapez “cleanLocalHdd.py –help” pour plus d'info …

Nb2 : Les noeuds de calcul n'ayant pas accès à internet, il n'est pas possible pour eux d'acquérir des licences réseau (type FlexLm ou RLM). Tenez en compte, par exemple pour Samcef en baconnant vos tests préalablement et en copiant le fichier *.fdb à coté du *.dat (Metafor lisant directement le fdb).

Pour plus d'infos sur SGE: Doc Oracle de SGE

La doc utilisateur du cluster est dispo dans /cm/shared/docs/cm/. Pour que personne ne puisse dire que c'est trop dur de la télécharger, la voici en ligne.

— Romain BOMAN 2011/05/17 14:43