Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools

You are here: metafor.ltas.ulg.ac.be » Doc Développeur » Utilisation du cluster "fabulous"
Trace: • Utilisation du cluster "fabulous"
devel:cluster

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
devel:cluster [2016/03/30 15:23] – external edit 127.0.0.1devel:cluster [2017/06/28 16:14] (current) – papeleux
Line 4: Line 4:
  
 Cette page a pour but de donner les infos minimales pour utiliser le cluster "fabulous". Il est fortement conseillé de lire également {{:doc:devel:cluster-user-manual.pdf|la doc}}. Cette page a pour but de donner les infos minimales pour utiliser le cluster "fabulous". Il est fortement conseillé de lire également {{:doc:devel:cluster-user-manual.pdf|la doc}}.
 +
 ===== Généralités ===== ===== Généralités =====
  
Line 13: Line 14:
 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''). 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 __12 PCs de calcul__ (12 "noeuds" nommés de ''node001'' à ''node012'') 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" 2x4 coeurs.+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" 2x4 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.
  
-Coté disque, on est à l'aise (''/home'' de ~5To partagé en NFS). Il y a aussi du disque sur les noeuds mais on ne l'utilise pas encore. On utilise SFTP ([[http://www.filezilla.fr/|Filezilla]] par exemple) pour effectuer les transferts de fichiers et backupifier ses trucs (le port 21 vers l'extérieur est en cours d'ouverture).+On utilise SFTP ([[http://www.filezilla.fr/|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 4x12=48Go de RAM, pour un total de 576Go si on somme les 12 noeuds. En RAM, chaque coeur dispose de 4Go. Autrement dit, chaque noeud possède 4x12=48Go de RAM, pour un total de 576Go si on somme les 12 noeuds.
Line 21: Line 24:
 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. 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.
  
-L'OS installé est [[http://www.scientificlinux.org/|Scientific Linux]] ("SL" pour les connaisseurs). C'est une version qui date de Mathusalem mais ça devrait suffire. Ça ressemble à une RedHat. En fait, il s'agit d'une "RedHat Enterprise" recompilée par des scientifiques (...ouille).+Le cluster ayant été réinstallé récement (05/2017) suite à un crash disk, l'OS installé est [[http://www.scientificlinux.org/|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 le ''/home'' de chaque utilisateur. Pour l'administration, ça simplifie évidemment la gestion au quotidien.+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.
  
  
Line 57: Line 60:
 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: 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:
 <file module.profile> <file module.profile>
-# sge : gestionnaire de queue +module load slurm
-module load sge +
-# applications nécessaires à la compilation - run metafor +
-module load cmake samcef swig python qt vtk +
-module load isosurf gmsh tetgen triangle matlab +
-module load gcc+
  
-# old intel-cluster-studio +module load git subversion 
-#module load intel-tbb +module load gcc cmake swig 
-#module load intel-cl-st/compiler/64/12.0/084 +module load python qt vtk parasolid mumps 
-#module load intel-cl-st/mkl/64/10.3/084+#module load gmm trilinos
  
-# nouveau svn +module load samcef gmsh  
-module load subversion/1.8.9+module load isosurf tetgen triangle 
 +module load matlab scilab
  
-# new intel-cluster-studio +# intel community  
-. /cm/shared/apps/ics/2013sp1/ics/2013.1.046/ictvars.sh+#. /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)
 </file> </file>
  
Line 89: Line 100:
 Actions: Actions:
  a/ e-mail address (reports)            : 'papeleux'  a/ e-mail address (reports)            : 'papeleux'
- c/ SVN repository                      : 'svn+ssh://clifton.ltas.ulg.ac.be/home/metafor/SVN' + b/ archive name                        : '~/dev.zip' 
- d/ SVN branch                          : 'trunk' + c/ build options                       : 'fabulous.cmake' 
- e/ build options                       : 'fabulous.cmake' + d/ debug mode                          : False 
- f/ debug mode                          : False + h/ nice value                          : '0' 
- j/ nb of task launched in parallel     : '1' + j/ nb of task launched in parallel     : '8' 
- k/ nb of threads by task               : '8' + k/ nb of threads by task               : '1' 
- m/ Run Method                          : 'sge' + m/ Run Method                          : 'interactive'
- n/ SGE queue                           : 'lomem.q' +
- o/ SGE run on local disk               : True +
- p/ additional SGE args                 : ''+
  
- 1/ source                              : 'checkout'+ 1/ source                              : 'zip'
  2/ compile                             : True  2/ compile                             : True
- 3/ battery                             : False + 3/ battery                             : True
- 4/ installer                           : False+
  
  G/ GO  G/ GO
Line 111: Line 118:
 Your choice? Your choice?
 </code> </code>
-La configuration fabulous.cmake contient toutes les informations pour compiler par défaut avec le compilateur intel (le gcc étant trop vieux pour compiler Metafor). +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''.  
-Lancez la compilation par "''G''" (en interactif ou SGE, le cluster n'a pas de queue batch)  et attendez le mail de fin.+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.
  
 +===== Lancer des calculs =====
  
 +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 [[https://en.wikipedia.org/wiki/Oracle_Grid_Engine|SGE - Sun Grid Engine]] (devenu obsolète suite au rachat par Oracle) est remplacé depuis la réinstallation du cluster par [[https://slurm.schedmd.com/|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.
  
-===== Lancer des calculs =====+<note warning> ATTENTION : Actuellement, "''launch.py''" est limité à l'exécution de calculs sur 1 seul noeud à la fois (plusieurs calculs simultanés sont possibles, mais en restant sur 1 seul noeud)... 
 +</note>
  
-Pour lancer un calcul sur les noeuds, il ne faut pas vous connecter sur les noeuds. L'idée est d'utiliser le système de queues batch fourni avec le cluster (SGE - Sun Grid Engine) à partir du "master node". +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''": 
- +<code>   
-Encore une fois, il est possible de faire ça manuellement ou grâce aux scripts de Metafor (dans ce cas-ci, c'est "''launch.py''"). Tout comme comp.py, il se trouve dans votre répertoire  "''~/bin''". +Actions: 
- + b/ exec name                           : '../Metafor/Metafor' 
-Ensuite créez un répertoire vide et allez dedans. Tapez "''launch.py''": + c/ test filename                       : './banc18ER/casingRotAnalysis/WingletBlade/Coarse3250Eas.py'
-<code> Actions: +
- a/ e-mail address (reports)            : 'papeleux' +
- b/ exec name                           : '../oo_metaB/bin/Metafor' +
- c/ test name                           : 'apps.qs.cont2'+
  d/ logfile (no ext)                    : 'out'  d/ logfile (no ext)                    : 'out'
  e/ algorithm                           : 'meta'  e/ algorithm                           : 'meta'
 + g/ Run multiple test on dir            : False
  j/ nb of task launched in parallel     : '1'  j/ nb of task launched in parallel     : '1'
- k/ nb of threads by task               : '1' + k/ nb of threads by task               : '12' 
- m/ Run Method                          : 'sge' + m/ Run Method                          : 'slurm' 
- n/ SGE queue                           : 'lomem.q' + n/ Queue name                          : 'defq' 
- o/ SGE run on local disk               : True + o/ Metafor run on node local disk      : True 
- p/ additional SGE args                 : ''+ p/ Total Memory (Mb)                   : '5000' 
 + q/ Time (d-hh:mm:ss)                   : '0-1:00:00'
  u/ ftp transfert                       : False  u/ ftp transfert                       : False
  
Line 142: Line 152:
  Q/ QUIT  Q/ QUIT
  
-Your choice?+ 
 </code> </code>
-Choisissez la méthode de run "m" jusqu'à ce que ce soit "''sge''" 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/ SGE run on local disk               : True''"). Sauf utilisation particulière ne supportant pas ce mécanisme, 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). 
  
-<note warning> +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 : A ce jour, la configuration des queues via SGE ou le script de lancement des calculs généré par launch.py permet de lancer plusieures tâches en même temps, MAIS seul 1 job tournera effectivement.\\ +(ATTENTION le produit (nbTests * nbThreads) ne peut dépasser le nombre de coeurs sur 1 noeud soit 12). 
-Conclusion : ne demandez pas plus d'1 tâche à la fois par ''launch.py'' \\ + 
-<code> +Choisissez la méthode de run "m" jusqu'à ce que ce soit "''slurm''" qui soit affiché (voir ci dessus). 
-   j/ nb of task launched in parallel     : '1'  +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). 
-</code> + 
-(=> splittez vos tests dans plusieurs répértoires et faites plusieurs commandes launch ...) +Soyez attentif aux paramètres de mémoire ( "''p/ Total Memory (Mb)                   : '1000' ''") 
-</note>+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é, il est possible de voir le statut de la queue et du job en faisant: +Une fois que le job est lancé, ("''G''") les messages suivant sont affichés 
-  qstat -f +
-Voilà ce que ça peut donner:+
 <code> <code>
-boman@fabulous:~/dev >qstat -f +Your choice? go in slurm 
-queuename                      qtype resv/used/tot. load_avg arch          states +sending job 'Tests.banc18ER.casingRotAnalysis.WingletBlade.Coarse3250Eas' to Slurm 
---------------------------------------------------------------------------------- +Submitted batch job 451 
-all.q@node001.cm.cluster       BIP   0/5/12         4.86     lx26-amd64 +Submission SUCCESSFUL! 
-     72 0.58500 fullblade7 boman        r     05/17/2011 12:23:32     5 +        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 
-all.q@node002.cm.cluster       BIP   0/0/12         0.00     lx26-amd64 +        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 
-all.q@node003.cm.cluster       BIP   0/1/12         1.00     lx26-amd64 +        use ' sacct --format=JobID,NTasks,NCPUS,CPUTime,Elapsed,MaxRSS,MaxVMSize -j 451 ' to get information about your finished job (adapt format to your needs) 
-     69 0.50500 barbara04f boman        r     05/17/2011 11:24:17     1 +</code>        
---------------------------------------------------------------------------------- +
-all.q@node004.cm.cluster       BIP   0/4/12         3.92     lx26-amd64 +
-     73 0.56500 fullblade7 boman        r     05/17/2011 12:23:47     4 +
---------------------------------------------------------------------------------- +
-all.q@node005.cm.cluster       BIP   0/3/12         2.90     lx26-amd64 +
-     74 0.54500 fullblade7 boman        r     05/17/2011 12:24:02     3 +
---------------------------------------------------------------------------------- +
-all.q@node006.cm.cluster       BIP   0/0/12         0.00     lx26-amd64 +
---------------------------------------------------------------------------------- +
-all.q@node007.cm.cluster       BIP   0/1/12         1.00     lx26-amd64 +
-     76 0.50500 fullblade7 boman        r     05/17/2011 12:24:32     1 +
---------------------------------------------------------------------------------- +
-all.q@node008.cm.cluster       BIP   0/0/12         0.02     lx26-amd64 +
---------------------------------------------------------------------------------- +
-all.q@node009.cm.cluster       BIP   0/0/12         0.25     lx26-amd64 +
---------------------------------------------------------------------------------- +
-all.q@node010.cm.cluster       BIP   0/2/12         2.01     lx26-amd64 +
-     75 0.52500 fullblade7 boman        r     05/17/2011 12:24:17     2 +
---------------------------------------------------------------------------------- +
-all.q@node011.cm.cluster       BIP   0/6/12         5.68     lx26-amd64 +
-     71 0.60500 fullblade7 boman        r     05/17/2011 12:17:47     6 +
---------------------------------------------------------------------------------- +
-all.q@node012.cm.cluster       BIP   0/0/12         0.15     lx26-amd64+
  
-############################################################################ +squeue donne des informations sur les jobs dans les queues :  
- - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS +pour mon job en particulier : 
-############################################################################ +<code>         
-     79 0.00000 dev.batter boman        qw    05/17/2011 16:45:02    12+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     
 +</code>         
 +ou pour tous les jobs :  
 +<code>         
 +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 
 +</code>     
 + 
 +Les outputs de sprio (actuellement pas de calcul de priorité des jobs => premier arrivé, premier servis) 
 +<code> 
 +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
 </code> </code>
  
-Pour voir tous les jobs gérés par SGE pour tous les utilisateurs: 
-  qstat -u '*' 
-Pour supprimer son job avant la fin, il suffit de repérer son numéro par "''qstat''" et de faire 
-  qdel [numero] 
-Des mails sont envoyés par SGE 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 numéro sge du process 'sgePid': +pour plus d'info sur les commandes Slurm, lire [[devel:slurm|]] (basé sur NIC4 dont la config de slurm est plus aboutie).
  
-  qDelxxxx.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)+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/...)   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'')   rmNodeResultsxxxx.py : nettoye le disque du noeud de calcul des fichiers du process xxxx (''rm -rf /local/$USER_pxxxx'')
Line 216: Line 223:
 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 ... 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 ...
  
-Pour plus d'infos sur SGE: [[http://wikis.sun.com/display/gridengine62u5/Home|Doc Oracle de SGE]]+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: [[http://wikis.sun.com/display/gridengine62u5/Home|Doc Oracle de SGE]]
 ===== En savoir plus ===== ===== En savoir plus =====
  
devel/cluster.1459344184.txt.gz · Last modified: (external edit)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki