Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


devel:cluster

This is an old revision of the document!


Utilisation du cluster "fabulous"

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

Généralités

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 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” 2×4 coeurs.

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 (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).

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.

L'OS installé est 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).

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.

Configuration de votre compte

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:

# sge : gestionnaire de queue
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 intel-tbb
#module load intel-cl-st/compiler/64/12.0/084
#module load intel-cl-st/mkl/64/10.3/084
 
# nouveau svn
module load subversion/1.8.9
 
# new intel-cluster-studio
. /cm/shared/apps/ics/2013sp1/ics/2013.1.046/ictvars.sh

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

Compiler Metafor

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'
 c/ SVN repository                      : 'svn+ssh://clifton.ltas.ulg.ac.be/home/metafor/SVN'
 d/ SVN branch                          : 'trunk'
 e/ build options                       : 'fabulous.cmake'
 f/ debug mode                          : False
 j/ nb of task launched in parallel     : '1'
 k/ nb of threads by task               : '8'
 m/ Run Method                          : 'sge'
 n/ SGE queue                           : 'lomem.q'
 o/ SGE run on local disk               : True
 p/ additional SGE args                 : ''

 1/ source                              : 'checkout'
 2/ compile                             : True
 3/ battery                             : False
 4/ installer                           : False

 G/ GO
 S/ SAVE
 Q/ QUIT

Your choice?

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). Lancez la compilation par “G” (en interactif ou SGE, le cluster n'a pas de queue batch) et attendez le mail de fin.

Lancer des calculs

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

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

Ensuite créez un répertoire vide et allez dedans. Tapez “launch.py”:

 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'
 e/ algorithm                           : 'meta'
 j/ nb of task launched in parallel     : '1'
 k/ nb of threads by task               : '1'
 m/ Run Method                          : 'sge'
 n/ SGE queue                           : 'lomem.q'
 o/ SGE run on local disk               : True
 p/ additional SGE args                 : ''
 u/ ftp transfert                       : False

 G/ GO
 S/ SAVE
 Q/ QUIT

Your choice?

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

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.
Conclusion : ne demandez pas plus d'1 tâche à la fois par launch.py
   j/ nb of task launched in parallel     : '1' 

(⇒ splittez vos tests dans plusieurs répértoires et faites plusieurs commandes launch …)

Une fois que le job est lancé, il est possible de voir le statut de la queue et du job en faisant:

qstat -f

Voilà ce que ça peut donner:

boman@fabulous:~/dev >qstat -f
queuename                      qtype resv/used/tot. load_avg arch          states
---------------------------------------------------------------------------------
all.q@node001.cm.cluster       BIP   0/5/12         4.86     lx26-amd64
     72 0.58500 fullblade7 boman        r     05/17/2011 12:23:32     5
---------------------------------------------------------------------------------
all.q@node002.cm.cluster       BIP   0/0/12         0.00     lx26-amd64
---------------------------------------------------------------------------------
all.q@node003.cm.cluster       BIP   0/1/12         1.00     lx26-amd64
     69 0.50500 barbara04f boman        r     05/17/2011 11:24:17     1
---------------------------------------------------------------------------------
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

############################################################################
 - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
     79 0.00000 dev.batter boman        qw    05/17/2011 16:45:02    12

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

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

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

En savoir plus

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

devel/cluster.1459344184.txt.gz · Last modified: 2016/04/14 10:13 (external edit)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki