Accueil > Archive

Manuel utilisation Grid5000

- Configuration

Grid5000 est composé de clusters répartis sur 9 sites : Bordeaux, Grenoble, Lille, Lyon, Nancy, Orsay, Rennes, Sophia et Toulouse. Le cluster toulousain (GridMip), est composé d’une machine appelée la frontale, et de 57 noeuds bi-processeurs, des AMD Opteron à 2.2Ghz avec 2Go de RAM.

Le home de l’utilisateur est placé dans /home/toulouse/login. Ce home est monté par NFS sur la frontale et tous les noeuds du cluster. C’est-à-dire que sur chacun des noeuds, les données du home seront accessibles, comme si elles étaient physiquement sur les noeuds. Vous n’avez donc pas de transfert à faire pour calculer sur le site de Toulouse. Par contre, si vous souhaitez faire des calculs multi-site, il faudra penser à copier vos données sur les frontales des autres sites.

Pour copier des données de votre machine locale vers le site de Toulouse, vous devez utiliser la commande scp.

Terminal

[itouche@local ]$ scp nomFichier login@acces.toulouse.grid5000.fr :/home/toulouse/login

- Connexion à la grille

  • Depuis Linux

Pour se connecter à la grille, on utlise une connexion ssh. Il suffit donc de taper depuis n’importe quel terminal :

Terminal

[itouche@local ]$ ssh login@acces.toulouse.grid5000.fr
> passwd :


avec login votre nom d’utilisateur sur Grid5000. Une connexion sera intialisée vers la frontale du cluster de Toulouse et validée si vous fournissez le bon mot de passe.

Si vous avez besoin d’exécuter une application nécessitant une interface graphique, il faut utiliser l’option -X de ssh :

Terminal
[itouche@local ]$ ssh -X login@acces.toulouse.grid5000.fr 
> passwd :  

  • Depuis Windows

Pour se connecter, il faut avoir un client ssh. Pour cela il faut avoir installé un logiciel comme Ssh Secure Shell (http://www.ssh.com/support/downloads/secureshellwks/non-commercial.html) ou Putty (http://www.clubic.com/telecharger-fiche10874-putty.html).

La connexion sera validée à partir d’un login, d’un mot de passe et du nom de l’hôte : acces.toulouse.grid5000.fr, à paramétrer dans le logiciel.

Si vous avez besoin d’exécuter une application nécessitant une interface graphique, il faut avoir installé en plus un serveur X. Ceci permet à une application graphique distante de s’afficher sur votre écran local. Vous pouvez télécharger par exemple Xming ( http://sourceforge.net/project/showfiles.php?group_id=156984&package_id=175377&release_id=471893 ). Une fois qu’il est démarré (en double-cliquant simplement dessus), il faut encore activer l’option autorisant le "X11 forwarding" dans le client ssh. Par exemple, dans Ssh Secure Shell, editer le profil, puis dans l’onglet Tunelling, cocher la case "TunnelX11 connections".

- Etat de la grille

Pour effectuer un calcul sur la grille, il est indispensable de réserver les noeuds de calcul que l’on veut utiliser. Afin de décider plus facilement combien de noeuds prendre et pour combien de temps, il peut être utile de regarder l’état de la grille.

Pour le faire graphiquement, il suffit d’accéder à la page internet suivante : https://helpdesk.grid5000.fr/oar/Toulouse/DrawOARGantt.pl. Attention, son accès est réservé aux personnes ayant un compte sur Grid5000.

Chaque ligne représente l’activité sur un noeud, et on peut regarder verticalement ce qu’il se passe à un temps donné.

Pour le faire depuis le terminal, la commande oarstat liste toutes les réservations.

Terminal
[itouche@cict-254 ]$ oarstat 
Job id           Name             User             Time Use S Queue

---------------- ---------------- -------- - -----
67820 /bin/sleep 61200 deploy 2007-01- W deplo
67959 /bin/sleep 17280 dloureiro 2007-01- W defau
68601 ./lance 12 11706 cmijoule 2007-02- W defau
68264 /home/grenoble/v vberten 2007-02- R defau


La commande oarnodes permet de lister l’état de chacun des noeuds.

Terminal
[itouche@cict-254 ]$ oarnodes
node-1.toulouse.grid5000.fr
     nextFinaudDecision = NO
     weight = 1
     finaudDecision = NO
     nextState = UnChanged
     pcpus = 1
     hostname = node-1.toulouse.grid5000.fr
     state = job
     jobs = 0/68269.oarserver
     properties = deploy=YES,besteffort=YES,expiryDate=0000-00-00 00:00:00,hostname=node-1.toulouse.grid500
0.fr,desktopComputing=NO

node-10.toulouse.grid5000.fr
nextFinaudDecision = NO
weight = 0
finaudDecision = NO
nextState = UnChanged
pcpus = 1
hostname = node-10.toulouse.grid5000.fr
state = free
properties = deploy=YES,besteffort=YES,expiryDate=0000-00-00 00:00:00,hostname=node-10.toulou
se.grid5000.fr,desktopComputing=NO


Pour savoir simplement combien de noeuds sont libres actuellement, on peut utiliser la commande oarnodes |grep -c free

Terminal
[itouche@cict-254 ]$ oarnodes | grep -c free
40

- Réservation de noeuds

Pour réserver les noeuds de la grille, on utilise le logiciel OAR. Il y a deux sortes de réservations possibles : les réservations en mode \textbfintéractif et les reservations en mode \textbfpassif.

  • Interactif

Ce type de réservations permet de se connecter à un ou plusieurs noeuds par ssh, et de travailler dessus comme sur une machine distante quelconque. Ceci est utile pour les compilations de code, ou pour faire des tests sur des scripts de lancement. Pour cela, la commande de base est oarsub -I.

Terminal
[itouche@cict-254 ]$ oarsub -I
Host:Port = cict-254.toulouse.grid5000.fr:40906 
 IdJob = 68903 
Interactive mode : waiting 
[itouche@node-41 ]$ 

Il suffit de faire exit pour quitter les noeuds et ainsi annuler la fin de la réservation.

  • Passif

Les réservations en mode passif sont les plus courantes. Il s’agit en fait de réserver les noeuds, et de mettre un script en file d’attente. Le script sera alors lancé automatiquement le moment venu. La commande de base sera alors oarsub monScript.

Terminal

[itouche@cict-254 ]$ oarsub "./monScript"
 IdJob = 68905

OAR retroune un identifiant qui permettra de savoir où en est le job, et de l’annuler au besoin.

  • Options

On dispose ensuite de plusieurs options permettant de choisir les caractéristiques de notre réservation :

  • -l nodes=2,walltime=3 : pour définir une réservation sur 2 noeuds, pendant 3 heures.
    • On peut aussi définir le temps de réservation sous le format : walltime=HH:MM:SS.
    • Si on ne spécifie pas walltime=N, par défaut, ce sera 1 heure.
    • Si on ne spécifie pas nodes=N, par défaut, ce sera 1 noeud.
  • -r "2007-01-24 10:00:00" : pour définir la date et l’heure à laquelle on souhaite que le job démarre.
    • Cette commande générera une réponse de OAR : OK si c’est bon et KO sinon.
    • Si on ne définit pas cette option, le job sera soumis le plus tôt possible.
  • -p "hostname=’nomCompletDuNoeud’" : permet de réserver un noeud particulier.
    • Si on ne définit pas cette option, c’est OAR qui choisira les noeuds.

Pour plus de détails sur les options, vous pouvez consulter la page de grid5000 sur OAR :
https://www.grid5000.fr/mediawiki/index.php/OAR.

- Détails sur les jobs

  • Variables d’environnement

Une fois la réservation faite, lors de l’exécution d’un job, OAR génère plusieurs variables d’environnement comme $OAR_FILE_NODES qui contient le nom du fichier contenant la liste des noeuds, ou $OAR_JOB_ID qui contient l’identifiant. Attention, ces variables ne sont définies que sur le noeud de connexion, à savoir le premier de la liste.

Terminal
[itouche@cict-254 ]$ oarsub -I -l nodes=4
Host:Port = cict-254.toulouse.grid5000.fr:41981 
 IdJob = 68907 
Interactive mode : waiting 
[itouche@node-15 ]$ env | grep OAR
OAR_JOBID=68907
OAR_NODENUM=4
OAR_USER=itouche
OAR_WORKDIR=/home/toulouse/itouche
OAR_NB_NODES=4
OAR_FILE_NODES=/tmp/OAR_68907
OAR_NODEFILE=/tmp/OAR_68907
OAR_NODECOUNT=4
OAR_O_WORKDIR=/home/toulouse/itouche
[itouche@node-15 ]$ cat $OAR_FILE_NODES 
node-15.toulouse.grid5000.fr
node-29.toulouse.grid5000.fr
node-41.toulouse.grid5000.fr
node-46.toulouse.grid5000.fr
[itouche@node-15 ]$ echo $OAR_JOBID
68907
[itouche@node-15 ]$ echo $OAR_NB_NODES
4

  • Etat du job

La commande oarstat permet de lister tous les jobs lancés par OAR. On peut aussi utiliser cette commande avec l’option -j suivi de l’identifiant d’un job particulier pour en connaître les caractéristiques. Pour avoir des informations encore plus détaillées, on utilise l’option -f

Terminal
[itouche@cict-254 ]$ oarstat
Job id           Name             User             Time Use S Queue

---------------- ---------------- -------- - -----
67820 /bin/sleep 61200 deploy 2007-01- W deplo
68601 ./lance 12 11706 cmijoule 2007-02- W defau
68703 /bin/sleep 28800 msanchon 2007-02- R deplo
68855 /home/grenoble/v vberten 2007-02- R defau
68898 ./lance 1 117084 nreuge 2007-02- R defau

Terminal
[itouche@cict-254 ]$ oarstat -j 68898
Job Id : 68898
     queueName = default
     reservation = None
     submissionTime = 2007-02-07 13:03:37
     accounted = NO
     bpid = 
     state = Running
     user = nreuge
     weight = 1
     startTime = 2007-02-07 13:03:38
     nbNodes = 1
     command = ./lance 1 1170849804609 7
     checkpoint = 0
     jobType = PASSIVE
     message = 
     properties = 
     maxTime = 07:00:00
     idFile = 
     autoCheckpointed = NO
     stopTime = 0000-00-00 00:00:00
     launchingDirectory = /home/toulouse/nreuge/interface_web/mfix/job/1170849804609/run
     infoType = cict-254.toulouse.grid5000.fr :

Terminal
[itouche@cict-254 ]$ oarstat -fj 68898
Job Id : 68898.oar
    Job_Name = 68898
    Job_Owner = nreuge
    job_state = R
    comment = Job state : Running
    exec_host = node-53.toulouse.grid5000.fr
    queue = default
    nbNodes = 1
    weight = 1
    command = ./lance 1 1170849804609 7
    launchingDirectory = /home/toulouse/nreuge/interface_web/mfix/job/1170849804609/run
    jobType = PASSIVE
    properties = 
    reservation = None
    walltime = 07:00:00
    submissionTime = 2007-02-07 13:03:37
    startTime = 2007-02-07 13:03:38
    scheduledStart = 2007-02-07 13:03:38
    events = 

  • Annulation

Pour annuler un job, on utlise la commande oardel suivi de l’identifiant du job.

Terminal
[itouche@cict-254 ]$ oarsub "./script"
IdJob = 68911 
[itouche@cict-254 ]$ oardel 68911
Deleting the job = 68911 ...REGISTERED.
The job(s) [ 68911 ] will be deleted in a near futur.

- Utilisation

Les grilles de calculs sont particulièrement appréciables pour deux types d’applications : les applications parallèles et multi-parmètriques.

  • Parallèle

Les applications parallèles sont celles qui utilisent plusieurs noeuds en même temps pour un même calcul. Chaque noeud traite une partie du problème et il communique avec les autres noeuds pour échanger des informations et continuer sa tâche.

    • Mono-site

Si on travaille sur un site, il faut se connecter à ce site et réserver autant de noeuds que l’on souhaite utiliser pour le calcul. On lance ensuite l’application parallèle sur le noeud principal. Dans le cas d’une application parallélisée avec MPI :

Terminal
[itouche@cict-254 ]$ oarsub -l nodes=4 "./script"
IdJob = 68917 

Script
# !/bin/bash
cd chemin
mpirun -np 4 -machinefile=$OAR_FILE_NODES ./executableParallele

    • Multi-site

Si on veut travailler sur plusieurs sites, la première chose à faire sera de copier les données sur tous les sites. De plus, il faudra que ces données soient stockées dans la home, suivant la même arborescence sur chacun des sites.

Ensuite, il faudra faire la réservation à l’aide de oargridsub. On utilisera le mode passif, ce qui permettra de lancer un script sur chacun des sites réservés. On dispose des options suivantes :

  • -d "chemin" : pour définir le répertoire dans lequel on travaille. Attention, il doit exister sur tous les sites.
  • -p "commande" : pour définir la commande que l’on va lancer. Attention, le script ou la commande doit être disponible sur chaque site. (Par contre, si c’est un script, il n’a pas besoin d’avoir les mêmes instructions à l’intérieur !)
  • -w HH:MM:SS : pour définir le temps de réservation.

Il faut ensuite définir les ressources demandées sous la forme site1:nodes=N1, site2:nodes=N2 ...

Terminal
[itouche@cict-254 ]$  oargridsub -d "/home/toulouse/itouche/" -p "./multiLance" -w 01:00:00 toulouse:nodes=2,
 bordeaux:nodes=2 
toulouse:nodes=2, bordeaux:nodes=2
[OAR_GRIDSUB] Reservation success on bordeaux : batchId = 33508, nbNodes = 2, weight = 0, properties = "",
 queue = default
[OAR_GRIDSUB] Reservation success on toulouse : batchId = 68922, nbNodes = 2, weight = 0, properties = "",
 queue = default
[OAR_GRIDSUB] Grid reservation id = 8099

OAR fera une réservation sur chacun des sites et retournera l’identifiant correspondant. Si l’une des réservations échoue, elles seront toutes annulées et la réservation globale aura échoué. Si elles sont toutes faites avec succès, OAR définira un identifiant de la réservation globale.

Le problème est maintenant le suivant : comment lancer un calcul parallèle ? Si sur chaque site, nous écrivons un même script que celui que nous avons écrit en mono-site :

Script
# !/bin/bash
cd chemin
mpirun -np 4 -machinefile=$OAR_FILE_NODES ./executableParallele

Que va-t-il se passer ? Sur chaque site, OAR va lancer un calcul parallèle, sur ses propres noeuds... Ce qui reviendrait à faire deux calculs parallèles mono-site... Or ce n’est pas ce que l’on cherche à faire...

Il faut écrire des scripts différents sur chaque site. Il faut qu’un seul des sites ait un script qui lance le calcul parallèle. Par contre, il faut que, dans la commande mpirun, la variable, qui définit les noeuds à utiliser, prenne bien en compte les noeuds de tous les sites...

On définit donc un site principal qui lancera le calcul parallèle. Tous les autres sites devront écrire la liste des noeuds qu’ils ont à leur disposition dans un fichier qui sera récupéré par le site principal.

Il faut ensuite remarquer autre chose : si un site finit d’exécuter son script, alors sa réservation s’arrête et il rend ses noeuds à la communauté. Donc, pour ne pas que tous les sites (sauf le site principal qui lance le calcul parallèle) s’arrête avant la fin du calcul, il faut les obliger à faire quelque chose... Pour cela, on met dans leur script un sleep, qui va durer tout le temps de la réservation.

Et enfin, dernière remarque... La fin d’une réservation sur un site n’engendre pas la fin des réservations sur les autres sites. Il faudra donc, lorsque le calcul parallèle sera terminé, arrêter toutes les réservations, sinon les noeuds seront inutilement retenus à cause du sleep jusqu’à la fin de la réservation. Pour cela, on utilisera la commande oargriddel qui s’applique à l’identifiant de la soumission globale. Et pour que le site principal connaisse cet identifiant, on aura préalablement redirigé la commande oargridsub dans un fichier jobid.

Finalement, voilà ce qu’il se passe :

Terminal
[itouche@cict-254 ]$  oargridsub -d "/home/toulouse/itouche/" -p "./multiLance" -w 01:00:00 toulouse:nodes=2, 
bordeaux:nodes=2 > jobid

Le fichier jobid contient les éléments suivants :

jobid

toulouse:nodes=2, bordeaux:nodes=2
[OAR_GRIDSUB] Reservation success on bordeaux : batchId = 33508, nbNodes = 2, weight = 0, properties = "", 
queue = default
[OAR_GRIDSUB] Reservation success on toulouse : batchId = 68922, nbNodes = 2, weight = 0, properties = "", 
queue = default
[OAR_GRIDSUB] Grid reservation id = 8099

On définit Toulouse comme site principal, son script est le suivant :

multiLance Maître

# !/bin/bash

# on crée le fichier machine
cat $OAR_FILE_NODES > machine

# on récupère le fichier machine de bordeaux
scp bordeaux :/home/toulouse/itouche/machine ./machine_tmp
# et on complète le notre
cat machine_tmp >> machine

# on récupère l’identifant global dans le fichier jobid et on l’écrit dans un fichier jobidGlobal
gawk ’BEGINFS=" = "
$1=="[OAR_GRIDSUB] Grid reservation id" print $2
END{}’ jobid > jobidGlobal

# on lance le calcul parallèle sur tous les noeuds à l’aide du fichier machine
mpirun -machinefile machine -np 4 ./executableParallele

# une fois le calcul fini, on tue la réservation globale (et donc les réservations de chaque site)
read i < jobidGlobal
oargriddel $i

Sur les autres sites, le script est le suivant :

multiLance Esclave
# !/bin/bash

cat $OAR_FILE_NODES > machine

/bin/sleep 3600

  • Multi-paramètrique

Les applications multi-paramètriques sont des applications pour lesquelles on effectue plusieurs fois le même calul mais avec des paramètres d’entrée différents. Pour ces applications, il vaut mieux faire N réservations, puisque les calculs sont indépendants les uns des autres. Ainsi, on arrivera plus facilement à trouver les ressources nécessaires, et si un calcul est fini plus tôt que les autres, on peut rendre les ressources non utilisées à la communauté.

Pour éviter de lancer les N réservations à la main, on peut écrire un script permettant de faire ce travail. Par exemple, voici un script de lancement de 10 exécutions d’un exécutable , avec une réservation de 3h...

Script
# !/bin/bash

wt=3 # temps de la réservation
imax=10 # nombre d’exécutions

cd /home/toulouse/LOGIN/REP

i=1
while [ $i -le $imax ] ; do
mkdir $i
cp EXE $i
cd $i
oarsub -l walltime=$wt ./executableMultiParametrique
cd ..
i=$[$i+1]
done

echo "lancement terminé"