Bucher Thomas Rapport ST 402003

11, rue de lUniversit
67000 Strasbourg
ST40 Stage professionnel

Dveloppement dun environnement de

distribution de tches
7KRPDV%8&+(5 GI03
Automne 2003
6XLYHXUVHQHQWUHSULVH Franois BONNAREL et Pierre FERNIQUE
6XLYHXU87%0 Jaafar GABER

5HPHUFLHPHQWV
Tout dabord, je tiens remercier Jean-Marie HAMEURY, le directeur de
lObservatoire, ainsi que Franoise GENOVA, la directrice du CDS, pour mavoir permis de
joindre leur personnel durant ces quelques mois.
Ensuite, je remercie Franois BONNAREL et Pierre FERNIQUE, mes tuteurs, pour
toutes les informations quils mont apportes, pour les conseils quils mont donns, pour
leur suivi, leur patience et leur intrt port sur le travail que jai ralis.
Dautre part, je suis reconnaissant envers Thomas KELLER et Jean-Yves
HANGOUET, les administrateurs, pour le temps quils ont consacr maider lors de problmes rseau et dadministration.
Je remercie aussi Andr SCHAAFF, membre de lquipe ViZieR, pour stre impliqu
dans la correction des diffrentes documentations et pour sa participation aux tests de mon
systme, de mme que Christophe PICHON et Anas OBERTO pour leur collaboration commune linterfaage de mon systme avec leurs applications.
Par ailleurs, je tire mon chapeau Marc WENGER, pour avoir rpondu posment
plusieurs de mes questions concernant diffrents langages et concepts informatiques.
Enfin, je remercie tout le reste de lquipe pour son accueil chaleureux et sa bonne
humeur gnrale, ainsi que Benot pour avoir partag avec moi pendant 6 mois ses repas du
midi et ses pauses caf.
Automne 2003
Rapport de stage professionnel
6RPPDLUH
Sommaire .............................................................................................................................. 1
Introduction ........................................................................................................................... 3
1
Prsentation du lieu d accueil......................................................................................... 4
1.1 L Observatoire Astronomique de Strasbourg ............................................................................. 4

1.2 Les thmes de recherche l Observatoire .................................................................................. 4
1.3 Le Centre de Donnes astronomiques de Strasbourg.................................................................. 5
Prsentation du sujet ...................................................................................................... 7
2.1 Contexte ...................................................................................................................................... 7

2.2 Sujet propos............................................................................................................................... 8
2.3 Existant et exprience de l quipe .............................................................................................. 8
2.4 Droulement du stage ................................................................................................................. 9
2.4.1 Planning prvisionnel......................................................................................................... 9
2.4.2 Planning rel .................................................................................................................... 10
Recherche de technologies ddies au clustering.......................................................... 11
3.1 Qu est-ce que le clustering ?..................................................................................................... 11

3.2 Plateformes ddies au clustering............................................................................................. 12
3.3 API particulires au calcul parallle ......................................................................................... 12
3.3.1 LAM/MPI ............................................................................................................................ 13
3.3.2 PVM..................................................................................................................................... 14
3.4 Logiciels de distribution de tches............................................................................................ 15
3.4.1 OpenPBS.......................................................................................................................... 15
3.4.2 Platform LSF.................................................................................................................... 16
3.4.3 Queue ............................................................................................................................... 16
3.4.4 OpenMosix....................................................................................................................... 16
Analyse comparative des technologies ......................................................................... 17
4.1 Choix de la plateforme utilise ................................................................................................. 17

4.2 Choix d un logiciel existant ...................................................................................................... 17
4.3 Utilisation d une API pour la ralisation .................................................................................. 18
Dveloppement ............................................................................................................ 20
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
Structure de l environnement de distribution............................................................................ 20

Choix du langage ...................................................................................................................... 21
Nommage.................................................................................................................................. 22
Communication inter-dmons................................................................................................... 22
Structure des dmons ................................................................................................................ 23
Transfert des fichiers ................................................................................................................ 24
Description des tches .............................................................................................................. 24
Gestion des erreurs.................................................................................................................... 26
Gestion des utilisateurs / scurit.............................................................................................. 27
Purification du code .................................................................................................................. 27
Affichage des informations....................................................................................................... 27
Auto-configuration.................................................................................................................... 29
Documentation.......................................................................................................................... 29
Quelques statistiques................................................................................................................. 30
Autres utilitaires........................................................................................................................ 30
Exploitation et volutions............................................................................................. 32
BUCHER Thomas - GI03 - UTBM
Automne 2003
6.1 Mises en exploitation actuelles ................................................................................................. 32

6.1.1 Marsiaa............................................................................................................................. 32
6.1.2 Composition RGB............................................................................................................ 33
6.1.3 Dcompressions ............................................................................................................... 33
6.1.4 Rechantillonage.............................................................................................................. 34
6.1.5 Mosaquage ...................................................................................................................... 34
6.1.6 Dbruitage et dconvolution ............................................................................................ 34
6.2 volutions venir ..................................................................................................................... 34
6.2.1 Portage vers Windows ..................................................................................................... 34
6.2.2 Communication en UDP .................................................................................................. 35
6.2.3 Augmentation de la taille du cluster ................................................................................ 35
6.2.4 Personnalisation d un CD de Knoppix............................................................................. 35
Bilan ............................................................................................................................ 36
Conclusion........................................................................................................................... 37
Bibliographie....................................................................................................................... 38
Automne 2003
,QWURGXFWLRQ
Au terme de deux semestres d tudes en cycle d ingnieur l UTBM (Universit
Technologique de Belfort-Montbliard) s inscrit un stage professionnel d environ 6 mois.
Cette tape nous permet, tudiants, de mieux apprcier le milieu professionnel en plein milieu
de notre cursus.
Ayant dj ralis un stage dans un laboratoire universitaire, je n ai pas hsit choisir
de nouveau le mme environnement. En effet, les laboratoires universitaires ont l avantage de
donner de la libert dans les choix de l tudiant, tout en proposant un environnement forte
dominante intellectuelle : ce mlange permet l panouissement de l tudiant ainsi qu une
formation accrue.
L Observatoire Astronomique de Strasbourg, ainsi que le sujet de stage propos m ont
permis de raliser du dbut la fin un projet intressant, correspondant mes ambitions dans
le monde informatique.
Je commencerai tout d abord par dcrire le lieu d accueil et le contexte du sujet, ensuite j expliquerai le sujet ainsi que les objectifs plus en dtails, puis je montrerai ce que j ai
ralis et enfin je synthtiserai le travail effectu et conclurai.

Automne 2003
3UpVHQWDWLRQGXOLHXGDFFXHLO

/2EVHUYDWRLUH$VWURQRPLTXHGH6WUDVERXUJ
L Observatoire astronomique de Strasbourg est un Observatoire des sciences de

l Univers, et une unit mixte de recherche de l Universit Louis Pasteur et du CNRS.
En tout, 70 personnes y travaillent dans les secteurs de la recherche, de l enseignement
universitaire et de la diffusion des donnes astrophysiques auprs des astronomes professionnels du monde entier par l intermdiaire du Centre de Donnes astronomiques de Strasbourg
(CDS).
Le plantarium, composante de l Observatoire, est charg de la diffusion des connaissances auprs du grand public. Il propose :
- un spectacle disposant d un environnement immersif plongeant le spectateur sous un
ciel simul,
- une crypte aux toiles, lieu de dcouvertes et d activits ludiques sur le thme gnral
de l espace et de l astronomie, et
- la visite de la grande coupole et de sa lunette astronomique.
L Observatoire a t inaugur en 1881 dans le cadre de la nouvelle universit de
Strasbourg en application de l dit de l empereur Guillaume I du 28 avril 1872. Sa grande
coupole abrite une lunette quatoriale, dote d un objectif de 49cm de diamtre et de 7m de
focale. Cet instrument, qui tait la pointe de la technologie la fin du XIXe sicle, n est plus
utilis par des astronomes professionnels, mais reste un important objet patrimonial.
/HVWKqPHVGHUHFKHUFKHjO2EVHUYDWRLUH
Les quipes de recherche de l Observatoire suivent quatre thmes dominants :

LAstrophysique des Hautes nergies
Les astres effondrs, comme les trous noirs ou certaines toiles trs denses (toiles
neutrons, naines blanches) sont le sige de phnomnes qui comptent parmi les plus violents de l Univers. Les conditions physiques qui y rgnent sont inatteignables sur Terre.
L quipe Hautes nergies s intresse aux phnomnes de capture de la matire, et de son
jection sous forme de jets par ces astres compacts.
-
Le Traitement massif de donnes

Les chercheurs de l Observatoire s appuient sur les comptences des personnels du
CDS et sur les donnes auxquelles le centre donne accs pour comprendre, partir de trs
grands relevs du ciel, la structure de l Univers qui nous entoure. Le CDS mne galement des activits de recherche technologique sur de nouvelles mthodes d analyse,
d organisation, de traitement et de diffusion de grandes masses de donnes, qui peuvent
tre rparties sur plusieurs sites diffrents.
-
Galaxies
Les chercheurs de l Observatoire tudient l volution des galaxies en analysant les populations d toiles qui les constituent. La comprhension des mouvements qui animent les
-
Automne 2003
toiles de notre galaxie, la Voie Lacte, dus l attraction gravitationnelle, permet de retrouver la trace des petites galaxies qui ont form notre galaxie en s agglutinant. Elle permet aussi de mettre en vidence l existence de matire noire , qui reprsente l essentiel
de la masse de l Univers.
Physique Stellaire
Les toiles sont acteurs de l volution des galaxies auxquelles elles appartiennent. Les
recherches de cette quipe s appuient sur l observation et la modlisation des rayonnements mis. Le but est de comprendre les processus physiques qui gouvernent la structure
et l volution des toiles, ainsi que leurs liens avec le milieu interstellaire. L tude des
toiles doubles permet d aborder le mcanisme de leur formation et se prolonge dans le
domaine des plantes extra solaires.
-
/H&HQWUHGH'RQQpHVDVWURQRPLTXHVGH6WUDVERXUJ
Ce service a t cr en 1972 sous le nom de Centre de Donnes Stellaires, et est gr

actuellement par un personnel compos de 10 chercheurs, 8 ingnieurs, 5 techniciens et plusieurs collaborateurs contrat temporaire.
Le rle du CDS est d archiver une masse considrable de donnes d observations astronomiques, de les organiser, de les hirarchiser et d tablir des liens avec des services distants. C est une importante valeur ajoute que le CDS apporte ces donnes d observations.
Ainsi, ce service est utilis quotidiennement par les astronomes du monde entier pour
leur travail de recherche. Par ailleurs, les grandes agences qui grent les moyens
d observation astronomique au sol ou dans l espace (l Observatoire europen austral,
l Agence spatiale europenne, le CNES, la NASA, etc.) s en servent galement pour prparer
les futures missions et identifier les sources observes par les tlescopes.
De plus, le CDS a sign des accords d changes internationaux avec plusieurs organismes :
- la NASA (Etats-Unis),
- le National Astronomical Observatory (Japon),
- l Acadmie des Sciences de Russie,
- le rseau PPARC Starlink au Royaume-Uni,
- l Observatoire de Beijing (Chine),
- l Universit de Porto Allegre (Bresil),
- l Universit de La Plata (Argentine) et
- l InterUniversity Center for Astronomy and Astrophysics (Inde).
Le CDS joue et a jou un rle dans d importantes missions astronomiques spatiales,
contribuant aux catalogues d toiles guides (EXOSTAT, IRAS, Hipparcos, HST, ISO, SAX),
aidant identifier les sources observes (Hipparcos, Tycho, ROSAT, SIGMA) ou en organisant l accs aux archives. Le CDS contribue aussi au XMM Survey Science Center, sous la
responsabilit de l quipe Hautes nergies de l Observatoire de Strasbourg.
Automne 2003
Les 3 services majeurs proposs par le CDS sont les suivants :

SIMBAD
C est une base de donnes de rfrence pour l identification et la bibliographie de plus
de 3 millions d objets astronomiques. La mise en place d une version accessible sur le
web permet de dvelopper progressivement les liens avec d autres services, journaux en
lignes, archives d observatoires, images, etc. SIMBAD est utilise dans pratiquement tous
les grands systmes d accs aux archives et dans le service bibliographique ADS (Astrophysics Data System), comme serveur d identification. Il est ainsi possible de retrouver,
partir d un nom d objet, toute la bibliographie de celui-ci. La base reoit prs de 15000
requtes par jour.
-
VIZIER
Ce service permet d effectuer des recherches dans plus de 4000 catalogues et tables
publis, dont certains comportent plusieurs centaines de millions d entres. Ces catalogues
contiennent tous les objets astronomiques rpertoris dans le ciel. Le nombre de requtes
est du mme ordre que pour SIMBAD.
-
ALADIN
Aladin est l atlas interactif du ciel. Il permet de visualiser n importe quelle partie du
ciel sous forme d images astronomiques ; d origines, de longueurs d ondes et de rsolutions diverses. Outre la simple visualisation d images, ce service permet de superposer ces
images de rfrence du ciel avec le contenu des bases de donnes du CDS ou d autres centres. D autre part, il propose d autres fonctionnalits techniques permettant d extraire de
faons varies l informations contenue dans les images (courbes de niveaux, dtection
d objets, etc.). Le serveur accuse environ 2000 requtes par jour.
-
Le CDS s engage aujourd hui dans le projet d Observatoire virtuel international, dont
il est un acteur majeur. L objectif est de donner un nouvel essor la recherche astronomique
europenne en fdrant les observations de grands observatoires au sol et dans l espace qui
sont stockes sous forme numrique dans des banques de donnes diverses. L Observatoire
virtuel permettra de reconstruire le ciel toutes les longueurs d onde et construira une base de
travail fantastique pour les chercheurs.
Automne 2003

3UpVHQWDWLRQGXVXMHW
&RQWH[WH
De manire simplifie, Aladin possde une banque de plusieurs millions d images

astronomiques (gre par le SGBD Objectivity Systme de Gestion de Base de Donnes
objet), stocke sur une baie RAID 7 d environ 4To branche en Firewire.
Firewire
Requtes
Objectivity
CGI
Aladin
Rsultats
Internet
Figure 1. Structure du service Aladin
Le rle principal du serveur est de reconstruire la vole des images pour des rgions
du ciel, processus qui suit les tapes suivantes :
- analyse de la requte,
- rcupration des images recouvrant la rgion demande,
- dcompression ventuelle de ces images,
- extraction des portions concernes,
- prtraitements ventuels (rchantillonnage, ajustement de la dynamique, etc.)
- concatnation des diffrentes portions pour cre l image finale,
- post-traitements ventuels (dconvolution, extraction d objets, combinaison avec
d autres images),
- codage de l image finale dans le format requis,
- compression de l image finale si ncessaire.
La manire la plus courante d interroger Aladin est d utiliser son interface HTML
(disponible sur http://aladin.u-strasbg.fr/AladinPreviewer) ou alors d utiliser AladinJava, une
application graphique crite en Java, proposant de nombreuses fonctionnalits lies tous les
services du CDS.
Avec le nombre croissant de requtes qu Aladin doit traiter quotidiennement, la machine serveur se trouve souvent surcharge, et les utilisateurs sont alors confronts des
temps d attente qui peuvent tre parfois relativement longs (selon les traitements demands).
L quipe Aladin a donc dcid d amliorer les performances du serveur, et trois solutions se
prsentaient alors :
- Trouver un moyen pour acclrer un code dj optimis : cette solution implique une
refonte du serveur, chose non envisage pour l instant.
- Investir dans une machine plus puissante que l actuelle (Sun quadri-processeur) : cette
solution est trs coteuse, donc utilise que si ncessaire.

-
Automne 2003
Mettre en place une ferme de machines (de simples PC), moins coteuse qu un seul
gros serveur, qui dchargeront Aladin de certains traitements.
Ce projet d volution a t initi pas deux personnes qui seront alors mes tuteurs :
- Pierre FERNIQUE : ingnieur de recherche, responsable des outils graphiques associs au projet Aladin, et
- Franois BONNAREL : ingnieur de recherche, responsable du projet Aladin et particulirement de la base d images.
6XMHWSURSRVp
Aprs limination de la solution d optimisation et de l achat d un nouveau serveur coteux, la solution de la ferme (cluster) de calcul a t retenue et a donn lieu au sujet de stage
qui m a t propos :
Mettre en uvre un cluster de calcul pour le serveur dimages Aladin. tude de
faisabilit, valuation des solutions logicielles, tude et programmation dun gestionnaire de tches adquat (MPI), mise en place dune plate-forme prototype et
tudes de performances.
Par ailleurs, l utilisation de fermes de calcul est trs la mode dans le monde scientifique, car peu chre et relativement performante. D autre part, le concept de ferme de calcul
s intgre particulirement dans le projet AVO (Astronomical Virtual Observatory) ainsi que
dans GLOBUS, le projet de grille de calcul internationale.
J aurai alors ma disposition 3 nouveaux PCs, des Athlons XP 2400+ (en botier industriel 19 ), dots de 512Mo de RAM, 80Go de disque dur et d une carte rseau 100Mbs.
Ce ne sera qu titre d essais, et d autres machines pourraient tre achetes par la suite si les
rsultats s avrent concluants.
Typiquement, une tche pouvant tre acclre via un cluster est le mosaquage. Le
ciel est dcoup en une multitude d images ; ce sont ces images que contient la base de donnes d Aladin. Lorsqu un utilisateur demande une rgion du ciel autour d un point prcis,
alors le serveur rcupre les 4 images qui entourent ce point. Chaque image sera dcompresse individuellement (4 traitements pouvant donc tre faits en parallle), puis elles seront
ressoudes et l image rsultante sera de nouveau compresse. Dans ce cas, on tire parti du
fait que 4 traitements peuvent tre faits en parallle, sur 4 machines diffrentes, alors que sur
Aladin ils seront soit squentiels, soit concurrents en terme de ressources.
([LVWDQWHWH[SpULHQFHGHOpTXLSH
L ide d utiliser un cluster de calcul n est pas nouvelle au CDS. L quipe de VizieR a
dj install une grappe de 6 PC sous CLIC, une distribution Linux spcialise dans le clustering . Cette ferme aurait du servir dcharger le serveur VizieR, et augmenter sa capacit
de stockage en rpartissant de gros catalogues astronomiques sur chaque machine. Ainsi, chaque machine est spcialise dans la recherche sur un catalogue prcis. Les traitements auraient
d tre faits en parallle, grce une technologie nomme MPI (Message Passing Interface)
qui sera explique par la suite.
8
Automne 2003
Ce systme a t mis au point par un stagiaire, qui a fait une tude de faisabilit et dvelopp un prototype. Malheureusement, il s est avr que les performances du prototype
n atteignaient pas celles qui taient attendues.
'pURXOHPHQWGXVWDJH
Dterminer un planning n est pas choses aise, lorsque que l on ne connat pas encore
les technologies que nous serons amens utiliser. Dans certaines entreprises, un cahier des
charges strict est donn au stagiaire, qui devra alors le suivre la lettre. Cela lui permet de ne
pas s garer , mais lui enlve aussi une certaine autonomie. Dans mon cas, on m a simplement donn le sujet, avec les 3 tapes majeures raliser : tude et analyse, prototypage,
dveloppement final.
3ODQQLQJSUpYLVLRQQHO
Des 3 tapes principales de mon stage, j ai pu dduire un planning prvisionnel grossier, dcoup en semaines sur un total de 24 semaines.
Dure
1re
semaine
Ralisations
familiarisation avec l environnement
familiarisation avec les technologies existantes
2me 5me
semaine
analyse des diffrentes possibilits

tude des technologies possibles
essais avec ces technologies
6me 10me
semaine
dveloppement d un prototype
essais avec ce prototype
dcision de rester sur ce choix
11me 20me
semaine
dveloppement d une version finale

essais et tests de charge
correction des bugs
21me 24me
semaine
rdaction des documentations

corrections et mises au point de la version finale
rdaction du rapport de stage
Automne 2003
3ODQQLQJUpHO
Il va de soi que le planning rel ne correspond pas exactement au planning prvisionnel,
tant donn que je n avais pas de contrainte sur mon organisation ; l essentiel dans un laboratoire de recherche, c est que le travail soit fait. Ainsi, mon stage c est droul plus ou moins
de la manire suivante :
Dure
1re
semaine
2me 3me
semaine
10
Ralisations
familiarisation avec l environnement
familiarisation avec les technologies existantes
tude de la distribution CLIC

tude des logiciels de distribution de tches (OpenPBS, LFS,
Queue) + essais avec OpenPBS
analyse de technologies ddies au clustering (MPI, PVM)
4me
semaine
ralisation de quelques essais avec MPI

ralisation de quelques essais avec OpenPBS
5me
semaine
installation matrielle du cluster prototype sous Linux

dcision de dvelopper notre propre environnement de distribution de tches
6me 10me
semaine
dveloppement du prototype
ralisation de quelques essais concluants
11me 18me
semaine
application du prototype un cas rel : Marsiaa

rajout de fonctionnalits au prototype et fiabilisation vers
une version exploitable !
finalisation et fiabilisation d une grande partie du systme
19me 20me
semaine
interfaage de l environnement avec un service d Aladin

interfaage de l environnement avec des requtes de VizieR
migration vers un mode d installation GNU facilit
d installation sur toute plateforme Linux/Unix
21me 24me
semaine
rdaction des documentations (Utilisateur, Administrateur,

CDS)
corrections et mises au point de la version finale
ajout de la fonctionnalit d items composs
passage un mode toujours connect des excuteurs et du
serveur
rdaction du rapport de stage
Automne 2003

5HFKHUFKHGHWHFKQRORJLHVGpGLpHVDXFOXVWHULQJ
Avant de se lancer dans la ralisation d un systme permettant de distribuer des tches

sur un rseau, il est utile de se renseigner sur l tat de l art dans le domaine. Pour cela, il faut
prendre en compte 3 composantes : les plateformes ddies au calcul distribu, les langages et
spcifications ddies la distribution, et enfin les logiciels qui, concrtement, servent faire
de la distribution de tches. Si un logiciel correspondait exactement aux besoins du CDS,
alors je n aurais pas le raliser, mais simplement l installer et le rendre exploitable de manire optimale. Nous verrons par la suite que ce ne sera pas le cas.
4XHVWFHTXHOHFOXVWHULQJ"
Strictement parlant, le clustering est la division d une tche complexe en plusieurs
petites tches tournant paralllement sur une grappe de machines (appele aussi ferme ou
cluster). Par abus de langage, on utilise souvent ce mot aussi pour parler de distribution de
tches sur plusieurs machines.
Le calcul en parallle permet d excuter une tche, dcoupe en morceaux, plus rapidement, car plusieurs ordinateurs contribuent la ralisation d une mme tche. On cherche
alors acclrer l excution d une seule tche, tel un trs gros calcul scientifique par exemple.
A contrario, il y a la distribution de tche qui consiste envoyer plusieurs tches sur
plusieurs machines diffrentes. Ceci n acclra pas le traitement d une seule tche, mais soulagera le serveur dans le cas de plusieurs tches simultanes.
Pour lancer une tche en plusieurs sous-tches s excutant en parallle, il faut qu elle
soit prvue pour, c'
est--dire crite de manire telle que plusieurs processus contribuent sa
ralisation en mme temps. Dans le cadre de mon stage, le serveur Aladin n est pas prvu
pour tre paralllis, donc on ne fera que de la distribution. Cependant, la possibilit de lancer
une tche paralllise via le systme doit rester envisageable.
Il existe en tout 4 types de clusters, selon la ou les ressources partages par les applications. Chaque cluster possde un rle diffrent, dont est plus approprie un certain type de
situation :
- Les clusters de calcul scientifique (HPC, High Performance Computing). Il s agit
d un cluster o les nuds cumulent leur puissance de calcul pour rivaliser avec les
performances d un supercalculateur. Le but d un cluster de calcul est de faire cooprer
les ordinateurs entre eux au sein d un rseau en partageant les processeurs et la mmoire. On amliore ainsi le temps de calcul par rapport des programmes qui exploiteraient localement le processeur et la mmoire d une seule et mme machine.
-
Les clusters haute disponibilit (HA, High Avaibility). Ici on cherche obtenir de
la fiabilit par une redondance de machines, chacune pouvant prendre le relais de
l autre en cas de panne. Dans ce cas, le fonctionnement du cluster et l assurance contre
les pertes de donnes sont garantis au maximum.
11
Automne 2003
Les clusters de stockage : on cherche grouper les espaces disques de plusieurs machines pour stocker d normes fichiers ne pouvant pas tenir sur un disque (ou plusieurs) d une mme machine.
Les clusters de rpartition de charge : ils sont frquemment utiliss par les serveurs
Web par exemple, en faisant traiter une requte d un internaute par la machine la
moins charge l instant donn. La rpartitions de charge est gre par un algorithme
de load-balancing plus ou moins complexe qui peut prvoir la charge des machines
selon un certain nombre de paramtres.
Dans le cadre du stage, nous aurons faire la fois un cluster de calcul (permettant
de faire tourner certaines applications crites en MPI), un cluster de stockage (pour les gros
catalogues de VizieR) et surtout un cluster de rpartition de charge (pour soulager le serveur
Aladin).
3ODWHIRUPHVGpGLpHVDXFOXVWHULQJ
Outre les supercalculateurs, peu de plateformes sont vraiment ddies au calcul parallle. En effet, pour effectuer du calcul parallle, il faut une machine possdant plusieurs processeurs. Actuellement, les PCs sont monoprocesseurs, parfois biprocesseurs. C est pourquoi,
la mise en rseau de plusieurs PCs, donc de plusieurs processeurs, permet de simuler une
machine multiprocesseur, avec l inconvnient des temps de transferts de donnes sur le rseau.
CLIC (distribution Linux base sur une Mandrake 9.1) propose de nombreux outils
facilitant la mise en place d une grappe de PCs, pouvant ainsi se comporter comme un gros
calculateur. Comme l quipe VizieR connaissait dj cette technologie, on m a tout de suite
aiguill dessus. J ai donc tudi les possibilits de CLIC, et particip une rinstallation
complte de la ferme de VizieR.
L avantage mis en avant par CLIC rside en sa facilit et sa rapidit tre dploy sur
un grand nombre de machines : il suffit d installer et configurer un nud matre (le Golden
Node), et tous les nuds esclaves sont dupliqus partir de celui-ci. Cette installation automatise est mise en uvre grce des cartes rseau compatibles avec le protocole PXE (Preboot Execution Environnement), et ne fonctionne qu avec ce protocole.
$3,SDUWLFXOLqUHVDXFDOFXOSDUDOOqOH
L criture d un programme paralllis n est pas chose aise car la communication
interprocessus est parfois complique, et souvent dpendante de la plateforme. De plus, si on
fait migrer une application parallle prvue pour une machine vers un cluster, il faut rcrire
la communication interprocessus pour pouvoir communiquer via le rseau.
La complexit de cette communication a pouss les dveloppeurs raliser des API
(Application Programming Interface) permettant de rendre transparente la communication
interprocessus, que les processus soient sur une machine ou disperss sur un rseau. De plus,
ces API sont portables, donc permettent d crire simplement des applications portables sans
se soucier de la plateforme cible.
12
Automne 2003
/$003,
LAM / MPI est l implmentation de MPI propose dans la distribution CLIC. MPI
(Message Passing Interface) est comme son nom l indique une interface de passage de message. MPI a t cre alors que la plupart des constructeurs ralisaient des API dpendantes
de leurs systmes. MPI avait alors pour but de permettre la ralisation d applications multi
processus portables sur toutes ces machines. Ainsi, le programmeur n a plus se soucier de la
plateforme cible pour la cration de son application, MPI assure qu elle sera portable. Les
bibliothques proposent un large ventail de fonctionnalits, dont suivent les principales :
- un grand nombre de routines de communication point point (bibliothque la plus riche ce jour),
- un grand nombre de routines de communication collective, pour la communication entre groupes de processus,
- un contexte de communication qui permet de dvelopper des bibliothques de calcul
parallle fiables,
- la possibilit de spcifier diffrentes topologies de communication,
- la possibilit de crer des types de donnes drivs dcrivant des messages contenant
des donnes non contigus.
Les programmes crits avec MPI sont donc portables (peuvent tre compils sur toute
plateforme possdant une implmentation de MPI), mais ne sont pas forcment interoprables
(par exemple, un programme crit avec LAM/MPI et tournant sous Linux ne peut pas forcment communiquer avec un programme crit avec MPICH une autre implmentation d MPI
- tournant sous Solaris). Actuellement, MPI est disponible pour les langages C, C++ et Fortran.
Concrtement, on lance une application MPI via la commande mpirun.
% mpirun np 6 app
Cette commande va crer un environnement MPI et y lancera (dans cet exemple) 6 instances
de l application app, identifies par les numros 1 6. Ces processus pourront alors dialoguer
trs simplement, via les routines de communications MPI. Comme le montre la figure cidessous, les processus peuvent tre lancs sur plusieurs machines diffrentes travers le rseau, mais ceci n entravera d aucune manire leur communication.
13
Automne 2003
Organisation physique des processus

5
Grappe de PCs
Organisation virtuelle des processus
1
2
3
4
390
Figure 2. Cration d'

un environnement MPI
PVM (Parallel Virtual Machine) n est pas seulement une API ; c est un kit intgr
d outils et de bibliothques qui mulent une structure de calcul flexible et htrogne, base
sur des ordinateurs interconnects d architectures varies. L objectif principal de PVM est de
permettre d utiliser un grand nombre d ordinateurs diffrents qui travailleront en coopration
pour faire du calcul parallle ou concurrent. PVM dispose entre autre des fonctionnalits suivantes :
-
Un pool d htes configurable : les applications sont excutes sur un ensemble de machines slectionnes par l utilisateur au lancement du programme. Les machines monoprocesseur et multiprocesseur (dont les architectures mmoire partage et mmoire distribue) peuvent faire partie de ce pool au mme moment. Ce pool peut tre
modifi tout instant, mme lors de l excution de la tche.
Un accs transparent au matriel de la machine virtuelle: par exemple, un processus de

la machine A peut utiliser le lecteur CD de la machine B comme si il tait local.
Une architecture gnrale de la machine ressemblant un systme Unix, c'

est--dire
que l architecture est multi processus et multi utilisateurs.
Un modle de passage de message explicite : chaque processus communique et utilise

les routines fournies par PVM.
L htrognit : PVM supporte l htrognit en terme de rseaux, de machines et

d applications. PVM permet aussi d changer des donnes de types dpendant de la
machine de manire portable, ce qui confre aux application une forte interoprabilit.
La gestion des machines multiprocesseurs : PVM utilise les routines natives des architectures multiprocesseurs pour garder leur avantage en terme de performance.
La machine virtuelle est cre par un dmon install sur chaque machine, qui gre les droits
utilisateurs ainsi que les applications lances. Les langages supports par PVM sont le C, le
C++ et le Fortran.
14
Automne 2003
Une seule machine virtuelle
Routeur
Grappe 1
Supercalculateur
vectoriel
Grappe 2
MPP
(Massive Parallel
Processor)
Grappe 3
Figure 3. Architectures htrognes
/RJLFLHOVGHGLVWULEXWLRQGHWkFKHV
Outre l utilisation d API permettant le calcul parallle rparti de manire transparente
sur le rseau, il est aussi possible de rpartir des tches sur un rseau grce un simple gestionnaire. Le l utilisation gnral de ce genre d utilitaires est de leur soumettre une tche
effectuer, et celle-ci sera excute sur une machine adquate. Trois logiciels correspondants
aux besoins d Aladin ont t tudis, OpenPBS, LSF et Queue, ainsi qu un environnement de
rpartition de charge automatique : OpenMosix.
2SHQ3%6
OpenPBS est la version originale du Portable Batch System. C est un systme de
queues flexible, dvelopp par la NASA dans le dbut des annes 1990, permettant de faire
du traitement diffr (batch). Il fonctionne dans un environnement rseau multi plateformes
(Unix/Linux). Voici quelques-unes des fonctionnalits de ce systme :
- Une interface utilisateur graphique, permettant de soumettre des tches et de suivre
leur droulement. Une interface en lignes de commande est aussi disponible.
- La gestion des priorits entre les diffrentes tches.
- La gestion des dpendances entre les tches : ordre d excution, synchronisations et
excutions conditionnelles sont possibles.
- Le transfert automatique des fichiers spcifis par l utilisateur.
- La gestion d une ou plusieurs queues d excution.
- La possibilit d utiliser diffrents algorithmes d ordonnancement, tels que le first-in,
first-out (par dfaut), ou bien le first-in, last-out, etc.
15
Automne 2003
3ODWIRUP/6)
Platform LSF est un logiciel permettant la gestion et l acclration des traitements de
tches, pour les applications gourmandes en calcul et/ou en donnes. De la mme manire
qu OpenPBS, Platform LSF permet d ordonnancer les tches et de garantir leur compltion, le
tout fonctionnant dans un environnement IT virtuel. Platform LSF est bas sur l architecture
VEM (Virtual Execution Machine), conue pour fonctionner avec le projet Globus (mise en
commun et partage de ressources informatiques l chelle internationale).
4XHXH
Queue est un systme de balance de charge qui permet aux utilisateurs de contrler
leurs tches distantes de manire intuitive et transparente. Ce contrle est fait l aide d un
shell local. Queue peut tre utilis comme un remplacement local rsh vers les machines d un
cluster homogne administr de manire unifie. Un dmon permet l utilisateur de contrler
la tche qu il a lance comme si elle s excutait sur sa machine. De plus, Queue supporte aussi les traditionnels balances de charge et distribution de traitements, paramtrs selon un certain nombre de critres tels que la limite de temps d excution, la limite de stockage, un seuil
de charge CPU, etc.
2SHQ0RVL[
OpenMosix est une extension de noyaux Linux, qui transforme un rseau de simples
ordinateurs en un superordinateur pour applications Linux. Une fois qu openMosix est install, les n uds du cluster communiquent entre eux et le cluster s adapte de lui-mme la
charge de travail. Ainsi, lorsqu un processus tourne sur un n ud surcharg, il peut tre dlocalis automatiquement vers un autre n ud plus adapt. OpenMosix effectue cette optimisation d allocation de ressources continuellement, sans intervention quelconque de la part de
l utilisateur.
Ainsi, openMosix cre une plateforme de clustering rentable, rapide et fiable, qui peut
tre agrandie et adapte souhait. Avec openMosix Auto Discovery, de nouveaux n uds
peuvent tre ajout alors que le cluster fonctionne dj, et ils seront automatiquement reconnus et utiliss. Le cluster se comporte tel un SMP (Symmetric Multi-Processor), mais cette
solution peut tout fait tre applique un millier de n uds qui eux-mmes peuvent tre des
SMPs.
De plus, les applications destines fonctionner sous openMosix n ont pas tre spcialement programmes pour, contrairement celles de PVM par exemple. Comme toutes les
extensions openMosix sont intgres au noyaux, toute application Linux bnficie automatiquement et de manire transparente du concept de calcul distribu d openMosix. En effet,
l utilisateur n a pas soumettre une tche au cluster ; le simple fait de lancer une application fera qu elle sera prise en charge automatiquement par le cluster.
16
Automne 2003

$QDO\VHFRPSDUDWLYHGHVWHFKQRORJLHV
Maintenant que nous avons dcrit les diffrentes technologies disponibles, passons
leur critique, en montrant leurs avantages et leurs inconvnients dans le cadre du sujet propos. L analyse de chaque technologie aboutit un choix quant son utilisation ; c est le moment dcisif partir duquel on va se lancer dans l laboration d un projet prototype, c est
pourquoi ces choix doivent tre faits de manire objective aprs une analyse approfondie.
&KRL[GHODSODWHIRUPHXWLOLVpH
CLIC semblait tre une distribution prometteuse pour l laboration d un cluster de
manire aise. Malheureusement, une exprience ngative nous en a prouv le contraire. En
effet, le cluster de l quipe VizieR avait subit un dysfonctionnement qui faisait que le cluster
complet devait tre rinstall. J ai particip cette rinstallation durant la troisime semaine
de mon stage, et pendant deux jours l quipe a essay, en vain, d utiliser le mode automatique
d installation. A priori, celui-ci n a pas fonctionn suite des problmes DHCP. Ainsi, CLIC
perd tout son avantage de simplicit, et devient une simple distribution proposant des packages ddis au clustering. De plus, CLIC connat aussi des problmes de drivers qui doivent
tre outrepasss de manire manuelle et complexe. Enfin, pour que l installation automatique
fonctionne, les machines cibles doivent tre matriellement identiques (disques de mme capacit, mmoire de mme taille, etc.) : c est un contrainte trs forte dans le cas d un cluster,
car, dans ce cas, il doit tre strictement homogne.
Cette exprience infructueuse m a montr qu il ne valait mieux pas se concentrer sur
une plateforme en particulier. Sachant que le rseau du CDS est relativement htrogne
(Unix, Linux et Windows), j ai dcid de me diriger vers une solution portable (au moins
Unix et Linux) afin de pouvoir utiliser le maximum de machines mises disposition.
De plus, outre de dsir d utilisation optimale des ressources du CDS, je suis contraint
de prvoir le serveur Aladin comme machine faisant partie du cluster. En effet, le code du
serveur Aladin n est actuellement prvu que pour Unix (Solaris) ; son portage vers un Linux
n est actuellement pas l ordre du jour, et ce serait beaucoup trop long pour que je puisse
l utiliser temps pendant mon stage. C est pourquoi j ai t oblig de tenir compte d au
moins une machine Unix dans la structure du cluster mettre en oeuvre.
&KRL[GXQORJLFLHOH[LVWDQW
Tout d abord, on peut exclure Platform LSF de la liste des logiciels envisageables,
puisque celui-ci est payant. Le CDS souhaite plutt accder des solutions gratuites, afin de
tester les possibilits d un cluster dans notre contexte. Aprs, si les performances du prototype
sont convaincantes, il serait toujours possible d investir dans un systme encore plus performant.
Ensuite, tudions le cas de Queue. Ce systme se prte bien au contexte, mais possde
nanmoins un dsavantage : il ne fonctionne que sur un cluster homogne. En effet, il n est
pas possible de mlanger la fois des machines sous Unix et des machines sous Linux dans le
mme cluster. Cette limitation va l encontre de la contrainte d htrognit impose par le
code non portable d Aladin.
17
Automne 2003
OpenMosix semble trs intressant, de par la transparence qu il propose. De manire

simple, il suffirait d installer openMosix sur toutes les machines du cluster, et de faire tourner
simplement les tches depuis n importe quel n ud, et celles-ci seraient automatiquement dlocalises afin de prserver un quilibre des charges CPU.
Cependant, la rgulation de charge ralise par openMosix n est effective que pour les
processus actifs depuis un certain temps (une minute par exemple) ; or les tches lances par
Aladin seront plus courtes pour la plupart, donc ne seront jamais dportes de la machine
Aladin vers d autres machines moins charges.
De plus, tant donn qu openMosix est une extension du noyau Linux, il n est pas
possible de l utiliser avec le code d Aladin.
On se rend alors compte que l htrognit (donc la portabilit des applications) est
une contrainte forte, qui risque de poser de nombreux problmes. On arrive alors la dernire
solution logicielle : OpenPBS. Celle-ci est entirement portable donc colle parfaitement notre besoin d htrognit. J ai donc dcid d installer OpenPBS sur les machines du cluster
afin de tester ses fonctionnalits et ses performances. Les fonctionnalits correspondent bien
aux besoins d Aladin : on peut soumettre des tches un dmon serveur (pbs_server), qui se
charge de la faire effectuer l une des machines excutrices (chacune contrle par un dmon
pbs_mom).
L ensemble des ressources est monitor par un dmon nomm pbs_mon. De plus, au
niveau du serveur, il est possible de mettre en place de queues d excution permettant
d ordonnancer les tches, selon leur priorit ou leur destination par exemple. Plusieurs instances de serveurs peuvent exister, et le passage d une queue une autre peut se faire d un serveur un autre. Ainsi, on peut mettre en place une architecture complexe, dploye par
exemple sur plusieurs centaines de machines... Mais dans notre cas, tant donn le nombre
limit de machines du cluster, une simple queue en FIFO (first-in, first-out) et un seul serveur
suffiraient.
Les fonctionnalits d OpenPBS sont intressantes, mais les performances ne sont pas
au rendez-vous. En effet, les requtes provenant d Aladin sont des services rendus des utilisateurs en mode interactif, c est pourquoi le temps de rponse est trs important. Le problme
est qu OpenPBS est un gestionnaire de batch (traitement par lot ou traitement diffr), et
n assure en aucun cas le traitement instantan des tches demandes. Ainsi, une tche devant
tre excute en moins de 10 secondes par Aladin, sera excute en 1 minute par OpenPBS.
En effet, ce logiciel est prvu pour des longues tches, et ne se soucie pas du temps minime
qu il prend pour les mettre en place. Apparemment, la gestion des queues ainsi que les mises
jour des charges CPU ne sont pas frquentes, mais cadences par une horloge priode assez longue. Ces temps de latence ne sont pas tolrables pour Aladin, donc la solution OpenPBS est mise l cart.
tant donn qu aucune des solutions logicielles tudies n est adapte au cas Aladin, il
ne me reste plus qu dvelopper moi-mme un environnement de distribution de tches, destin un rseau htrogne.
8WLOLVDWLRQGXQH$3,SRXUODUpDOLVDWLRQ
LAM / MPI est l API fournie par dfaut dans CLIC, et ds mon arrive on m a fait
comprendre que je serai trs certainement confront MPI pour mes dveloppements. Aprs
quelques jours de lecture et de tests, il s est avr que MPI est une API ddie surtout au calcul parallle, et non la distribution de tches. En effet, en environnement MPI est trs stati18
Automne 2003
que ; il est relativement difficile d y insrer un nouveau processus dynamiquement. MPI n est
pas du tout adapte pour la distribution de tches comme on souhaite le faire avec Aladin. En
terme de cluster, MPI est tout fait adapte pour un cluster de calcul, et non pas pour un cluster de rpartition de charge, d autant plus que MPI ne propose pas de systme intgr de
load-balancing .
En fait, j ai concrtement exclu MPI aprs avoir fait des tests non concluants. En effet,
j avais alors dj labor la structure du futur gestionnaire de tches, et un algorithme en particulier ne pouvait tre conu en MPI ; tant donn que l organisation des processus est statique en MPI, il n est pas possible de dupliquer un processus (un serveur par exemple), et
d insrer ce processus fils dans l environnement MPI. Au contraire, ce duplicata partage avec
son pre tous les moyens de communication et gnre ainsi des perturbations nfastes.
Ainsi, MPI ne sera pas utilise pour programmer le gestionnaire de tches, mais pourra
nanmoins servir crire des applications de calcul qui seront lances par le gestionnaire.
PVM permet d implmenter l algorithme qui n tait pas implmentable avec MPI,
mais possde un inconvnient majeur : des performances moindres. En effet, de par la gestion
d une multitude d architectures pour pouvoir transformer une topologie matriellement htrogne en une et une seule machine virtuelle, PVM connat une perte de performance non
ngligeable lors des communications interprocessus. Or, la moindre seconde de gagne est
importante pour rendre les services d Aladin plus rapides.
Dans les deux cas (MPI et PVM), l API est destine faciliter majoritairement le
dveloppement d applications de calcul parallle, surtout celles qui communiquent beaucoup.
La cration d un gestionnaire de tche, comme nous le verrons, n a rien voir avec le calcul
parallle. En effet, nous verrons que la structure du gestionnaire tient en 3 dmons, qui
n effectuent jamais de calcul, mais s occupent juste de grer soit un client, soit une tche.
De plus, l indpendance vis--vis d une API permet de distribuer une application sur
toute machine sans installation supplmentaire ; un plus lorsque qu on a faire avec un cluster htrogne, ne disposant pas forcment de toutes les bibliothques dont nous avons besoin.
19

Automne 2003
'pYHORSSHPHQW
Une fois la phase d analyse des technologies disponibles finie, il est possible de commencer concevoir le prototype de gestionnaire de tches. Comme conclu, tout le projet sera
recr partir de zro. Ceci n est pas tellement drangeant dans le sens o le laboratoire prfre matriser totalement les outils qu il utilise. De plus, fabriquer un outil du dbut jusqu la
fin permet de coller au mieux aux besoins du moment, alors qu un outil extrieur fera certaines choses, mais pas forcment tout ce que l on voudrait. Enfin, matriser un outil, connatre son code, permet aussi de pouvoir le maintenir de manire aise ; la maintenance de logiciels extrieurs n est pas toujours simple, surtout si ceux-ci ne possdent pas ou plus de support technique.
6WUXFWXUHGHOHQYLURQQHPHQWGHGLVWULEXWLRQ
Pour rsumer, nous avons besoin d un gestionnaire de tches, qui reoit des requtes
provenant du client (Aladin), qui excute les tches demandes (en les distribuant sur le cluster) et qui renvoie enfin les rsultats au client. Le schma global est reprsent par la figure cidessous. Aladin reoit une requte (1), excute ce qu il peut et demande au gestionnaire
d excuter certaines tches (2). Le gestionnaire rpartit alors ces tches vers les machines du
cluster (3) qui vont les excuter, puis renvoyer les rsultats au gestionnaire (4). Enfin, ce dernier renvoie les rsultats Aladin (5), qui les exploite pour pouvoir finir de rpondre au client
(6). Le gestionnaire sera un programme install soit sur la machine Aladin, soit sur une autre
machine afin de bien sparer le rle de chaque lment du rseau.
3
Gestionnaire
4
3
Aladin
Rseau CDS
Utilisateurs via
Internet
BDD
Figure 4. Schma global de l'

interaction Aladin - Gestionnaire
Sachant que le cluster sera htrogne, certaines machines ne seront srement pas capables d effectuer certaines tches. Ainsi, il est intressant de mettre en place un systme de
disponibilit d items . Le gestionnaire ne distribuera les tches (ncessitant certains items)
qu en fonction des items proposs par les machines excutrices.
20
Automne 2003
De plus, il faut mettre en place un systme de rpartition de charge, afin de ne pas distribuer les tches toujours aux mmes n uds du cluster. Nous avons donc besoin d un moniteur, qui va grer une table contenant les informations de chaque machine du cluster ; ces informations pourront tre la charge CPU actuelle, les items proposs, le nombre de tches
excutes, etc.
Enfin, limiter le systme un seul gestionnaire n est pas trs pertinent. En effet, il serait intressant que plusieurs gestionnaires puissent fonctionner pour le mme cluster, en tirant parti d un seul moniteur. Ainsi, il pourrait y avoir un gestionnaire spcialis dans les requtes provenant d Aladin, et un autre pour celles provenant de VizieR (volution que nous
verrons plus tard). Le client devient alors n importe qui, pas seulement le serveur Aladin, et
les requtes seront envoyes partir d une interface de soumission (le submitter). On obtient
une architecture comme illustre ci-dessous (les diffrents serveurs possibles et la pluralit de
clients ne sont pas reprsents):
Excuteur
Moniteur
Excuteur
Serveur
Client
Excuteur
Figure 5. Structure gnrale de l'

environnement de distribution
Lorsque le client soumet une tche au serveur, celui-ci demande au moniteur l adresse
d un excuteur (ou plusieurs, selon le nombre de tches). Le serveur ordonne alors cet excuteur d effectuer la tche donne, attend les rsultats et les renvoie au client. On voit que le
moniteur garde une connexion active avec tous les excuteurs, afin de garder une table de
leurs informations, mise jour frquemment.
&KRL[GXODQJDJH
Il existe trois langages possibles pour la ralisation d un tel projet : le C, le C++ et le
Java. D autres langages, tels que le Fortran ou le Perl ne sont pas envisageables, de part leur
faible performance ou leurs routines inadaptes.
Le Java est un langage trs pratique pour dvelopper rapidement des logiciels fiables.
Cependant, rares sont les serveurs crits en Java, car ce langage n est pas aussi performant
que C ou C++. De plus, ce langage ncessite l installation d un JRE (Java Runtime Environnement) pour pouvoir fonctionner, qui peut tre gourmand en ressources et engendre, selon
les machines, des problmes d administration supplmentaires.
21
Automne 2003
Le C++ est un langage objet trs performant. Cependant, un programme crit en C++
pose plus de problmes de portabilit que le C standard, de par les librairies plus spcifiques
qu il utilise ou certaines variantes selon les architectures.
Le C est le langage de prdilection des serveurs. En effet, ce langage est le plus performant car un des plus proches du systme (hormis l assembleur). Il ne propose cependant
pas le concept objet, trs pratique pour bien structurer son programme et le rendre volutif.
L criture d une application en ANSI C permet d assurer qu il pourra tre compil sur
toutes les plateformes supportant le C. De plus, je me rendrai plus tard compte que l ANSI C
est ncessaire pour pouvoir purifier mon code (grce au logiciel Purify), c'
est--dire le dbuguer dans les moindres dtails afin de le rendre le plus fiable que possible.
1RPPDJH
Afin de ne pas avoir toujours appeler mon projet Environnement de Distribution de
Tches sur un Rseau , j ai dcid de le nommer Ali - raccourci d Alinda, premire machine sur laquelle j ai travaill, et nom bien en phase avec la nomenclature Mille et Une
Nuits chre au CDS. Ainsi, je pourrai appeler les diffrents lments de l environnement de
cette manire : Sali pour le serveur (Server Ali), Mali pour le moniteur (Monitor Ali), Wali
pour l excuteur (Worker Ali) et Cali pour le client. Ces dnominations permettent de diffrencier un serveur d un autre ; en effet, parler du serveur n est pas toujours parlant puisqu une multitude d applications nommes serveur existent.
Cependant, par souci de comprhension dans ce document, je continuerai d appeler les
diffrents lments d Ali par leur fonction dans le systme.
&RPPXQLFDWLRQLQWHUGpPRQV
Il est vident que la communication entre les diffrentes composantes d Ali est une
partie importante du projet. Cette communication doit donc tre fiable, et simple afin de pouvoir la maintenir plus aisment.
Pour ce qui est de la fiabilit, j ai dcid d utiliser le protocole TCP/IP pour toutes les
communications ; ce protocole garantit la squence des donnes envoyes et leur intgrit.
Ainsi, toutes les communications sont faites en mode connect, c'
est--dire que deux lments
communicants tablissent une liaison statique avant de communiquer ; une fois le ou les messages transmis via cette liaison, elle peut tre ferme.
Afin de faciliter la communication inter dmons, j ai cr une surcouche aux fonctions
standards d envoi de donnes. Ainsi, j ai cr une structure de message contenant le code du
message, le type de donnes envoyes, la longueur des donnes et les donnes elles-mmes.
Cette structure est passe en paramtre deux principales fonctions de communication :
get_message et put_message, qui respectivement envoient et rceptionnent un message
via une socket (liaison de communication). Ainsi, ces deux fonctions s occupent de rendre
transparents les problmes de portabilit, les erreurs de protocole de communication, etc. Le
dveloppeur n a qu remplir sa structure message, sans se soucier du reste.
De plus, toutes les communications inter-dmons sont rgies par des protocoles de
communication stricts. Chaque message envoy est identifi par un code et un type. Les pro-
22
Automne 2003
tocoles de communication spcifient quels codes et quels types doivent tre envoys / reus,
ce qui permet de dtecter une erreur ds qu elle intervient. Tout processus ne respectant pas le
protocole sera ignor (par exemple, un dmon externe Ali qui essayer de se connecter au
serveur par mgarde).
6WUXFWXUHGHVGpPRQV
Chaque dmon est constitu d un processus pre qui coute sur un port donn ; c est
sur ce port que les autres dmons pourront le contacter. En rgle gnrale, lorsqu une
connexion arrive sur le port, le processus pre se duplique en un fils qui va s occuper de cette
connexion (Figure 6, partie de gauche). Le pre reste alors disponible pour l attente d autres
connexions. Ce procd est utilis par le serveur et l excuteur ; le moniteur ne se duplique
pas, car le traitement de ses requtes est tellement rapide qu une duplication est superflue.
pre
Attente de connexion
Attente de connexion
Duplication (fork)
Traitement de la requte
fils
Traitement de la requte
Finalisation
Figure 6. Structure algorithmique gnrale d'

un dmon
Cependant, conjointement au processus pre du moniteur, un thread tourne en parallle ; ce thread est charg de la mise jour des informations sur les excuteurs. Il tourne en
parallle afin que le service de demande de meilleur excuteur soit toujours disponible,
mme lors des mises jour.
Note : les algorithmes plus complets des dmons se trouvent dans le Guide Administrateur,
plac en annexe.
L utilisation de la duplication de processus n est pas forcment inhrente la cration
d un serveur ou d un dmon. En effet, il est aussi possible de simplement crer des threads
qui auront le mme rle que les processus fils. Ces threads sont plus lgers que les processus,
car il n y a pas cration d un nouveau contexte de processus : ils partagent tous la mme zone
mmoire, les mme descripteurs de fichiers, etc.
Cependant, bon nombre de fonctions standards du C ne sont par rentrantes, c'
est-dire qu elles ne peuvent tre utilises que par un seul thread la fois. Or, Ali est crit majoritairement avec des fonctions non rentrantes (hsearch() par exemple), ce qui rend impossible
23
Automne 2003
l utilisation des threads de par les conflits mmoire que cela engendrerait. C est pourquoi tous
les dmons font de la duplication en processus fils au lieu de la cration de threads.
Une autre possibilit serait l utilisation d une bibliothque GNU, la glibc, qui rglerait
les problmes de fonctions non rentrantes. De plus, cette bibliothque propose un bon nombre de fonctions trs utiles, telles que les listes, les tables de hachage, etc. Mais mon souci de
portabilit et de simplicit l installation me force programmer indpendamment de toute
autre bibliothque que celles qui sont standards.
7UDQVIHUWGHVILFKLHUV
La plupart des requtes qui sont faites au serveur impliquent des transferts de fichiers.
Par exemple, une tche qui consiste en la compression d un fichier requiert le transfert de
deux fichiers : le fichier compresser (en entre) et le fichier compress (en sortie). C est
pourquoi il faut un moyen fiable pour transfrer les fichiers, d autant plus que se sera souvent
l tape qui prend le plus de temps dans l excution d une tche.
Plusieurs possibilits s offrent nous pour transfrer un fichier d une machine une
autre : l utilisation d une partition NFS (Network File System), l utilisation des commandes
de copie distance (rcp/scp) ou alors la rcriture d un transfert de fichiers fait directement
par les dmons.
Les partitions NFS sont un trs bon moyen pour partager des fichiers entre plusieurs
machines sur un rseau. Cependant, l administration d un tel systme s avre parfois compliqu, et si un dysfonctionnement intervenait, alors tout l environnement Ali serait hors service.
Ainsi, l usage de partitions NFS n est pas recommand dans ce contexte l.
Les commandes rcp/scp semblent tre de bons candidats pour le transfert de fichiers ;
leur utilisation est simple, puisqu il suffit de spcifier le fichier de dpart et celui de destination. Or, la commande rcp n est plus installe sur les rseaux fiables, car elle prsente de larges failles de scurit. Il faut utiliser la place la commande scp, version scurise de rcp.
Cependant, qui dit scurit dit cryptage des donnes ; ce cryptage est long et coteux lors du
transfert des fichiers comme on l a dj dit, la moindre seconde de gagne lors de
l excution d une tche est un plus pour le service.
Ainsi, j ai intgr l envoi des fichiers la bibliothque de communication ; un fichier
est dsormais considr comme un type de donnes contenues par un message. Tous les fichiers transfrs passent donc par les dmons , ce qui permet une matrise complte de ces
transferts.
'HVFULSWLRQGHVWkFKHV
Une requte doit pouvoir dcrire, de manire plus ou moins prcise, le besoin de
l utilisateur, c'
est--dire la ou les taches qu il dsire excuter, et comment il souhaite le faire.
L architecture d Ali implique que ces tches doivent pouvoir tre lances en arrire plan ; elle
ne doivent pas tre interactives (c'
est--dire requrir l intervention d un utilisateur, comme par
exemple les diteurs de texte), et n acceptent en entre et en sortie que des fichiers. La requte
sera gnralement stocke dans un fichier, ou dans un buffer (tampon mmoire), avant d tre
soumise au serveur via l interface de soumission. Voici un exemple de fichier de requte :
24
Automne 2003

H[HPSOHUHT)LFKLHUGHUHTXrWHH[HPSOH
&HILFKLHUGHUHTXrWHGRQQHODGHVFULSWLRQGXQHWDFKHTXLFRPSUHVVHGHX[
ILFKLHUVILFKHWILFKHWOHVDUFKLYHSDUODVXLWHGDQVILFKWDU
/HVGHX[FRPSUHVVLRQVVRQWLQGpSHQGDQWHVFHTXLHVWORJLTXHDORUVTXH
ODUFKLYDJHHVWGpSHQGDQWGHVGHX[SUpFpGHQWHVWDFKHV

+($'(5
),),/(6ILFKILFK
)2),/(6ILFKWDU
6(3$5$725

&RPSUHVVLRQGXSUHPLHUILFKLHU
,'
&0'J]LSILFK
,),/(6ILFK
2),/(6ILFKJ]
/),/(6
5(48,5(J]LS
'(36
&267
7,0(287
5(75,(6

&RPSUHVVLRQGXVHFRQGILFKLHU
,'
&0'J]LSILFK]LS
,),/(6ILFK
2),/(6ILFKJ]
/),/(6
5(48,5(J]LS
'(36
&267
7,0(287
5(75,(6

$UFKLYDJHGHVGHX[ILFKLHUVFRPSUHVVHV
,'
&0'WDUFIILFKWDUILFKJ]ILFKJ]
,),/(6ILFKJ]ILFKJ]
2),/(6ILFKWDU
/),/(6
5(48,5(WDU
'(36
&267
7,0(287
5(75,(6

)LQGXILFKLHUGHUHTXHWH

25
Automne 2003
Ce fichier est compos de commentaires et de paragraphes constitus de balises. Le

premier paragraphe est une entte qui indique quels sont les fichiers qui seront envoys au
serveur (les fichiers d entre primaire, FIFILES) et quels sont les fichiers qui sont attendus en
sortie (les fichiers de sortie finaux, FOFILES). Chaque paragraphe suivant dcrit une tche
effectuer.
Chaque paragraphe de tche est dcompos en balises, chacune reprsentant un
paramtre. ID est l identificateur de la tche dans la requte et CMD la commande excuter.
Les IFILES, OFILES et LFILES sont respectivement les fichiers en entre de la tche,
fichiers en sortie et fichiers lis. Les fichiers lis sont spciaux, car ce sont des fichiers grs
comme des flux, ce qui permet de faire de l acquisition de donnes la vole. Comme
prcdemment, je vous renvoie au Guide Utilisateur, disponible en annexe, pour plus de
dtails. La balise REQUIRE est trs importante, car c est elle qui va permettre l identification
du ou des excuteurs propices l excution de la tche donne. En effet, les applications peuvent tre htrognes sur le cluster ; par exemple, toutes les machines ne possdent pas forcment l application Marsiaa. L insertion d un %REQUIRE Marsiaa dans la description de la tche permet donc de dire : ne slectionner que les excuteurs
disposant de Marsiaa .
La balise DEPS est aussi essentielle la bonne structuration d une requte. En effet,
cette balise permet de grer les dpendances entre les diffrentes tches ; ces dpendances
peuvent tre soit verticales (3 dpend de 2 qui dpend de 1), soit horizontales (4 dpend de 1,
2 et 3). L intrt des dpendances est de pouvoir demander effectuer des tches en parallle,
puis de les synchroniser avec une tche qui ncessite les rsultats de ces dernires. Par exemple, le mosaquage d Aladin lance 4 tches de dcompression en parallle, puis une tche qui
soude les 4 images dcompresses ; on a donc faire une dpendance horizontale.
Les balises COST, TIMEOUT et RETRIES sont des paramtres qui permettent de
configurer la tche. Le cot est utilis par le serveur pour ses estimations lors de la balance de
charge ; il doit tre reprsentatif de la lourdeur de la tche. TIMEOUT permet de dfinir
un temps limite d excution, aprs lequel la tche est considre comme choue. Enfin,
RETRIES permet de dfinir un nombre de tentatives supplmentaires que la tche peut effectuer lors d un chec.
Le format d un fichier de requte est conforme au Parfile, format frquemment utilis
au sein du CDS. De plus, la structure d une requte est trs simple d utilisation, contrairement
, par exemple, celle d OpenPBS. En effet, pour une requte de 4 tches destines OpenPBS, il faut crire un lourd fichier de description assez illisible, en plus de 4 fichiers de scripts
qui vont dcrire chaque tche ; pour Ali, un seul fichier de requte suffit.
*HVWLRQGHVHUUHXUV
Afin que l utilisateur ne soit pas perdu lors d une erreur provenant de lui-mme, ou
d Ali (un logiciel n est jamais l abri d une faille), toutes les erreurs sont remonte via une
pile, l instar de ce que fait Java automatiquement. En effet, pour chaque fonction sortant en
erreur, j ajoute un message explicatif une liste d erreurs. Ainsi, la sortie en erreur peut se
propager sur plusieurs niveaux de fonctions, toujours en ajoutant un message explicatif. Ainsi,
si une erreur arrive, la requte est annule et l utilisateur est notifi de la cause de cette annulation. Les erreurs typiques sont la malformation de la requte, un dysfonctionnement rpt
d une des tches, un problme rseau, etc.
26
Automne 2003
Cette affichage de la pile d erreurs permet de dboguer beaucoup plus facilement

l application, si par exemple celle-ci connatra plus tard (lorsque je ne serai plus l) une erreur
que je n ai pas rencontre et donc pas traite.
*HVWLRQGHVXWLOLVDWHXUVVpFXULWp
Concrtement, l environnement Ali ne gre pas les utilisateurs. En effet, la gestion
scurise des utilisateurs est une chose complique, surtout si on porte l environnement sur
diffrentes plateformes. De plus, il n est pas utile de se lancer dans le dveloppement d une
pseudo gestion des utilisateurs, si celle-ci prsente la moindre faille de scurit. Donc, les
tches ne sont pas associes des utilisateurs, mais seulement des postes clients (identifis
par leur adresse IP).
Ainsi, le serveur et les excuteurs sont dots d une liste d adresses IP autorises. Si un
client se connectant n est pas prsent dans cette liste, alors il sera notifi de sa connexion non
autorise et sera ignor. Il est donc du devoir de l administrateur d Ali de n autoriser que des
machines fiables, c'
est--dire o seuls des utilisateurs dignes de confiance peuvent se connecter.
Cependant, contrairement OpenPBS, tous les lments d Ali tournent sous un
compte utilisateur (non root), ce qui permet de restreindre l accs au sein de la machine hte.
Ainsi, sur un excuteur, un pirate ne pourrait pirater que les tches tournant simultanment,
mais pas la machine elle-mme.
D autre part, Ali peut trs bien tre utilis travers Internet ; il n est pas limit un
usage en rseau local. Il faut tout simplement ouvrir les ports utiliss par les dmons au niveau du pare-feu, afin que les utilisateurs puissent se connecter. Une fois encore, il faut faire
attention aux adresses IP que l on autorise.
3XULILFDWLRQGXFRGH
Une notion trs importante lors de la conception d un logiciel crit en C est la purification du code. Le C est un langage trs proche du systme, et la gestion de la mmoire est faite
entirement par le dveloppeur. Cette libert, permettant au dveloppeur d crire des programmes optimiss, contribue trs souvent l apparition d erreurs graves (pointeur en dehors
d un tableau, lecture de donnes non initialises, criture sur un bloc mmoire non autorise,
etc.) ; ces erreurs sont souvent vicieuses et difficiles dboguer. Afin de purifier le code de
toutes ces erreurs assez typiques, j ai t amen utiliser le logiciel Purify, qui indique au
dveloppeur chaque opration non autorise que le programme fait. Cette purification contribue grandement la fiabilisation de mon systme.
L inconvnient du logiciel Purify, c est qu il n accepte d analyser que du code crit en
C ANSI ; il n est dont pas possible d utiliser la syntaxe de commentaire // assez pratique
pour commenter une seule ligne, et beaucoup de fonctions courantes ne sont pas reconnues
tant donn qu elles ne sont pas vraiment conformes au C ANSI.
$IILFKDJHGHVLQIRUPDWLRQV
Chaque lment d Ali gnre un certain nombre d informations qu il affiche l cran.
Cet affichage n est bien sr pas obligatoire et peut tre simplement redirig vers un fichier ou
27
Automne 2003
/dev/null par l administrateur lors du lancement. Cependant, il reste trs utile pour garder une
trace de ce qui se fait un moment donn.
Le moniteur affiche simplement la liste des excuteurs qu il
connat, c'
est--dire qui sont dans la liste des excuteurs au
dmarrage du moniteur, ou alors qui se sont notifis en cours de
route. De base, le moniteur affiche simplement l tat de l excuteur
- actif (vert) ou non (rouge) -, sa charge, son nom et le nombre de
tches qu il a effectues. Cet affichage est personnalisable, pour
ainsi montrer plus d informations permettant de voir plus en dtail
l tat du cluster.
Le serveur propose un affichage linaire du droulement du
traitement de la requte. Chaque tape est chronomtre et permet
ainsi au programmeur et l administrateur de dterminer quelles
parties il faudrait potentiellement acclrer. Ainsi, si le temps de
transfert des fichiers de rsultats est la plus longue des tapes, on
peut se demander comment faire pour la rendre plus rapide.
L affichage d un excuteur se prsente de la mme manire
que celui du serveur. Chaque tape est aussi chronomtre pour
mieux rendre compte de la rpartition des dures.
La coloration du texte en C (sous Unix/Linux) est une
Figure 7. Moniteur
fonctionnalit que j ai dcouverte durant ce stage, et s avre trs
utile lorsqu on a une multitude de donnes afficher Ainsi, on
peut choisir diffrentes couleurs pour diffrents types d informations : jaune pour les temps,
vert pour les warnings , rouge pour les erreurs, bleu pour le dboguage, etc.
Figure 8. Affichage du serveur
28
Automne 2003
Figure 9. Affichage d un excuteur.
$XWRFRQILJXUDWLRQ
Je me suis lanc dans la gestion de l auto-configuration une fois Ali dvelopp. En
effet, l installation de l environnement tait un peu rbarbative, selon les plateformes, car parfois le compilateur n tait pas reconnu, ou mal install, etc. De plus, il fallait compiler la
main, et deviner d o provenaient les erreurs si jamais certaines bibliothques n taient pas
installes.
Trois outils sont indispensables pour la gnration d un package installable simplement : autoconf, automake et autoheader. Autoconf permet, partir d un modle, de crer un
excutable : configure. Celui-ci vrifie si toutes les bibliothques, compilateurs, variables
(etc.) ncessaires au package sont prsents. Ainsi, l utilisateur est notifi de l absence d un de
ces lments, et doit se charger de son installation. Automake permet de gnrer un fichier
Makefile automatiquement partir d un modle ; ce fichier sera configur par configure, afin
de coller l architecture actuelle. Enfin, autoheader est un outils qui permet de dtecter quelles sont les bibliothques et fichiers d entte qui risquent de poser problme dans le package.
Il gnre un fichier config.h qui permet alors de rendre le code portable, en activant ou pas des
parcelles de code selon l architecture. Finalement, pour installer mon package, l utilisateur ou
l administrateur n aura taper que quelques instructions :
WDU[]YIDOLWDUJ]
FGDOL
FRQILJXUH
PDNH
PDNHLQVWDOO
'RFXPHQWDWLRQ
Dans un projet de cette envergure, un minimum de documentation est ncessaire ;
d une part pour permettre l quipe Aladin de maintenir Ali, d autre part pour expliquer
l utilisateur comment l utiliser. J ai donc ralis un Guide Utilisateur, qui comme son nom
l indique, est destin l utilisateur de l environnement : il lui explique comment Ali fonctionne, comment crer une requte, comment la soumettre, etc. Et j ai aussi crit un Guide
Administrateur, expliquant le fonctionnement d Ali dans le dtail (pour une maintenance et
une volution future), comment l installer, le configurer, etc.
29
Automne 2003
Tout comme pour l installation du package, j ai essay de raliser une documentation

propre, en s inspirant de documentations professionnelles, comme celle d OpenPBS. Ainsi,
j ai crit ce document en LaTeX, langage que j ai appris dcouvrir et qui est trs utilis dans
le milieu des sciences pour son srieux et sa mise en forme sobre (aussi pour la facilit diter des quations, mais cette fonction ne m est pas utile ici). De plus, j ai fait relire les documents plusieurs personnes (dont mes tuteurs), afin de tenir compte d un maximum de remarques pour coller au mieux aux besoins du lecteur. Enfin, j ai crit un mini guide CDS,
indiquant l quipe quels sont les dtails de l installation actuelle du cluster.
Les Guide Utilisateur et le Guide Administrateur sont disponibles en annexe pour
donner plus de dtails sur le fonctionnement d Ali et ses utilisations.
4XHOTXHVVWDWLVWLTXHV
titre purement informatif, Ali se rsume en 10000 lignes de code, 400h de programmation, 40 pages de documentation et peu prs 100 pauses caf.
$XWUHVXWLOLWDLUHV
Outre tout le systme de distribution de tche, j ai dvelopp quelques autres utilitaires
en rapport avec Ali. Ainsi, j ai ralis une interface HTML pour le moniteur (Figure 10),
permettant n importe qui de connatre l tat du cluster un moment donn. Ce moniteur
affiche les informations nominatives des machines (nom rseau et adresse IP), les charges
CPU et rseau, ainsi que la liste des items proposs par les excuteurs. De plus, la charge
CPU est affiche de manire graphique afin d obtenir rapidement un aperu de la charge du
cluster.
Figure 10. Interface HTML pour le moniteur.
30
Automne 2003
L intrt de ce moniteur HTML est qu il est accessible depuis partout, aucun droit
n est ncessaire pour visualiser l tat du cluster. tant donn qu un moniteur est unique au
sein d un mme cluster, cette interface tait utile lorsque je travaillais en collaboration avec
l quipe VizieR, puisqu on pouvait alors voir o allaient les tches, sans ncessairement tre
le lanceur du dmon moniteur .
J ai aussi mis au point un utilitaire Java (Figure 11) permettant de crer des requtes
graphiquement, pour un utilisateur envoyant ses requtes en mode manuel . Cependant, la
plupart des utilisateurs d Ali seront des applications gnrant de manire automatise le
contenu de la requte, donc ne ncessiteront pas cet utilitaire. Il reste cependant disponible
pour ceux qui ne connaissent pas bien la syntaxe du fichier de requte ou qui ne connaissent
pas les options de soumission.
Figure 11. Interface de cration de requtes
31

Automne 2003
([SORLWDWLRQHWpYROXWLRQV
0LVHVHQH[SORLWDWLRQDFWXHOOHV
Actuellement, dj deux services en version d exploitation sont interfacs avec Ali :

Marsiaa et la composition RGB d Aladin. Dans les deux cas, nous avons prvu un mode
roue de secours , c'
est--dire une excution du service en local si jamais Ali n est pas disponible ou si une erreur intervient. Ce mode de secours permet de mettre en exploitation Ali,
mme si il est encore en phase de dveloppement.
Comme nous l avons vu, mis par les temps de calcul des tches, il faut aussi prendre
en compte les temps de transfert des fichiers d entre et de sortie. Par exemple, une tche qui
traite un fichier de 10 Mo, et qui s excute en une seconde sur Aladin n est pas une bonne
candidate, car il faudrait ajouter au temps d excution le cot de transfert des 10 Mo (en plus
du fichier de sortie). Chacun des candidats suivants a t choisi en fonction du rapport temps
de transfert de fichiers / dure des calculs, afin qu il soit vraiment utile de les faire passer par
Ali.
0DUVLDD
Marsiaa est une application qui permet d effectuer de la segmentation d images astronomiques grce une approche utilisant un modle Markovien. La segmentation permet
d identifier des zones, selon le rayonnement des objets astronomiques sur plusieurs bandes
(diffrentes longueurs d onde), comme le montrent les images ci-dessous.
Figure 12. Segmentation de deux images de Hubble prises 606 et 814 nm
L interfaage avec Ali se fait partir d une CGI (un service externe Aladin, mais qui
pourrait y tre intgr), qui invoque le submitter pour envoyer la requte et rcuprer les rsultats. Le gain en temps pour une requte unique est de l ordre de 20%, et augmente considrablement si plusieurs utilisateurs demandent une segmentation en mme temps. En effet, si
plusieurs requtes arrivent simultanment, chacune sera traite sur une machine diffrente, et
l excution du tout sera donc plus rapide que si chaque requte tait traite sur la mme machine.
32
Automne 2003
&RPSRVLWLRQ5*%
AladinJava propose une fonctionnalit qui consiste en la fusion de 3 images de la
mme partie du ciel, mais des longueurs d onde diffrentes, en une seule image colore.
Cette colorisation permet, d une part d avoir des images visuellement plus belles (destines
au grand public), mais aussi de permettre aux astronomes de visualiser simplement quelles
sont les diffrences entres les diffrentes longueurs d ondes (chacune reprsente par une
composante RGB). Dans l exemple ci-dessous, on peut aisment voir que la Nbuleuse du
Crabe est domine par des gaz rayonnant dans le rouge (mission de rayons infrarouge),
rayonne un peu moins dans le bleu et beaucoup moins dans le vert (Rayons X).
Figure 13. Composition RGB
La composition RGB peut tre effectue en mode non interactif par AladinJava, car
celui-ci possde un mode script qui accepte une srie de commandes excuter. Ainsi, la
CGI de visualisation de compositions RGB gnre un script, qu elle donne en paramtre dans
la requte Ali. AladinJava, alors install sur le cluster, va excuter ce script et renvoyer
l image rsultante au serveur Ali, qui la renvoie au client (la CGI de visualisation). Le gain en
temps de traitement est de l ordre de 25% pour une requte unique, et soulage largement le
serveur Aladin lors de plusieurs requtes simultanes. Pour les curieux, ce service de compositions RGB est disponible l adresse suivante : http://aladin.u-strasbg.fr/AladinPreview .
'pFRPSUHVVLRQV
Actuellement, le serveur Aladin n utilise Ali que pour effectuer des dcompressions
d images astronomiques. Selon le nombre de requtes parvenant au serveur, les dcompressions peuvent devenir gourmandes, c est pourquoi il est intressant de les faire faire par le
33
Automne 2003
cluster. Cependant, pour une requte isole, il n est pas vraiment pertinent de l excuter via
Ali, car le temps de transfert des donnes est plus long que le temps de traitement de ces donnes.
5pHFKDQWLOORQDJH
Les images contenues dans la base de donnes d Aladin sont de natures trs htrogne (rsolutions diffrentes, angles de prise de vue diffrents, balance des gris non identiques, etc.), c est pourquoi il n est pas possible de simplement les souder ensemble pour crer
une plus grande image. Ainsi, il faut les rechantillonner, c'
est--dire les ramener un mme
format (leur donner les mmes proprits) ; ce processus prend du temps, peut tre effectu indpendamment pour chaque image, donc peut passer par Ali.
0RVDwTXDJH
Le mosaquage est l opration qui consiste dterminer les images entourant un
point ou un objet demand dans le ciel, les dcompresser, les rechantillonner, les souder
et renvoyer l image rsultante au client. Ce n est donc pas une opration lmentaire, mais
elle peut ainsi constituer une requte contenant beaucoup de tches effectuer c est cette
opration qui terme devrait tre entirement ralise par Ali.
'pEUXLWDJHHWGpFRQYROXWLRQ
D autres traitements d image pouvant tre assurs par le cluster sont le dbruitage et la
dconvolution. Le dbruitage permet de nettoyer une image astronomique de toutes les interfrences qui font apparatre des pixels non informatifs. Ce dbruitage peut tre fait sur une
image dcoupe, donc peut tre paralllis pour augmenter les performances. Pour l instant,
l utilisation du dbruitage n est pas utilisable depuis Aladin, mais peut s effectuer la main,
via Ali.
La dconvolution a pour but de dformer une image, afin de coller au mieux la ralit. En effet, pour des raisons lectroniques, mtorologiques et physiques, les capteurs des
tlescopes dforment l image relle. Grce un modle de dformation , la dconvolution
permet de retrouver l image originale des observations. La dconvolution est gourmande en
ressources et non autonome (elle doit tre paramtre pour chaque image de manire manuelle), c est pourquoi elle n est pas encore intgre Aladin.
eYROXWLRQVjYHQLU
3RUWDJHYHUV:LQGRZV
Le portage des dmons d Ali vers une plateforme Windows est une possibilit envisager. En effet, il se peut que certaines applications de traitement soient crites exclusivement
pour Windows, au quel cas il faudrait installer des machines sous Windows dans le cluster.
34
Automne 2003
De plus, ce serait vraiment une bonne exprience d htrognit pour l environnement, et

augmenterait son volutivit.
&RPPXQLFDWLRQHQ8'3
Pour l instant, toutes les communications sont faites grce au protocole TCP/IP.
grande chelle, ce protocole peut-tre coteux en ressources systme et rseau. Ainsi, pour les
messages de petite taille (tels que les mises jour de la charge CPU des excuteurs, les ordres
d annulation, etc.), il serait intressant d utiliser UDP ; ce protocole ne ncessite pas de
connexion active pour envoyer / recevoir des messages. Cependant, il n assure ni intgrit, ni
rception des messages, c est pourquoi il ne doit tre utilis que pour des messages dont on
peut tolrer une perte (si la charge CPU d un excuteur n est pas mises jour 1 fois sur 100,
ce n est pas trs grave).
$XJPHQWDWLRQGHODWDLOOHGXFOXVWHU
Les 3 machines qui m ont t mises disposition ne sont que des machines test, afin
de voir si un cluster utilisant mon environnement de distribution est viable ou pas. Finalement, les rsultats sont assez concluants, c est pourquoi le CDS prvoit d augmenter la taille
du cluster, un nombre de machines pour l instant indtermin.
3HUVRQQDOLVDWLRQGXQ&'GH.QRSSL[
Knoppix est une distribution Linux auto-bootable sur CD, qui ne s installe pas statiquement ; en fait, le noyau Linux se charge directement en mmoire partir du CD, trs rapidement, et reconnat la plupart des configurations matrielles. Cette distribution est donc trs
apprcie pour faire des dmonstrations de Linux, rapidement et efficacement.
L intrt de Knoppix est que l on peut personnaliser le CD notre guise, en modifiant
son image et en la regravant. Ainsi, il serait possible de mettre en place Ali sur le CD, afin
qu il s installe directement sur la machine lors du dmarrage de celle-ci. De cette manire, on
pourrait crer un cluster de 100 machines en 2 minutes, pour le simple cot des 100 CD (un
par machine) ; le rseau est automatiquement configur via DHCP, donc les excuteurs
n auraient pas de mal se connecter au moniteur par dfaut. Il serait aussi possible
d envisager une image de Knoppix installe sur un serveur principal, et de crer une disquette
de boot afin que la machine aille chercher Knoppix directement sur le serveur ; ceci viterait
de graver un CD par machine, surtout si ce CD est vou tre modifi souvent.
35

Automne 2003
%LODQ
Pour commencer, il faut bien videmment se poser la question : Est-ce que le sujet a
t ralis dans son intgralit . La rponse, je pense, est oui ; une analyse a t faite et il
en a t conclu qu il serait intressant de dvelopper notre propre environnement de distribution de tches. Cet environnement a t dvelopp, est fonctionnel et dj mis en exploitation ; ainsi, les objectifs principaux du stage ont t atteints.
Cependant, ce stage s inscrit dans un contexte beaucoup plus global : une grille internationale qui permettrait de partager les ressources de milliers d ordinateurs, supercalculateurs, serveurs de stockage, etc. Avant d en arriver l, on peut dj penser raliser des applications optimises pour les clusters : au lieu de faire de la simple distribution de tches, qui
n acclre pas vraiment une requte isole, il serait bon d crire les applications pour qu elles
puissent tirer parti d un grand nombre d ordinateurs (par exemple en faisant du code parallle
crit avec MPI). Pour l instant, cette solution n est pas l ordre du jour mais Marsiaa, par
exemple, est dj sur la liste des applications qui seront paralllises plus tard.
D autre part, au fur et mesure que le projet avanait, il s est avr qu Ali n tait pas
simplement compatible avec les besoins du CDS. Cet environnement se rapproche beaucoup
(conceptuellement, srement moins en terne de fiabilit) des solutions professionnelles telles
que OpenPBS. L installation d Ali sur bon nombre de machines sur Internet pourrait former
une mini grille de calcul, entre diffrents laboratoires par exemple. Pour l instant, les performances rseau d Internet sont pnalisantes cause du temps de transfert des donnes, mais
cette pnalit diminue de plus en plus avec la gnralisation des connexions haut dbit. Cependant, pour des tches vraiment axes sur du calcul et ne ncessitant que peu de donnes
(dcryptage d un code, rsolution d quation, rendu d images 3D complexes), les performances d Ali sont non ngligeables.
Enfin, avec la mise en place du systme de disponibilit d items, Ali peut trs bien
servir de serveur d applications. Ainsi, une personne ne possdant pas le compilateur LaTeX
peut trs bien demander Ali de compiler ses sources pour elle. Il suffit de crer une tche
ncessitant l item LaTeX , d y joindre les fichiers sources, et 2 secondes plus tard le rsultat, un .dvi, est l. Les utilisateurs n ont donc plus besoin de possder tous les packages, tous
les logiciels ou toutes les librairies pour la conversion, l dition ou la compilation de fichiers ;
Ali le fait pour eux. Il suffit simplement de connatre le nom de l item voulu, et d une bonne
configuration faite par l administrateur. Cependant, ce serveur d applications se limite aux
applications non interactives et non graphiques peut-tre qu une volution est venir ?
36
Automne 2003
&RQFOXVLRQ
Pour finir, ce stage m a permis de mener du dbut jusqu la fin un projet qui m a
beaucoup appris. Le rseau est un domaine informatique en volution constante, qui mrite
d tre tudi et exploit. La ralisation d un environnement de distribution de tches (sur un
rseau) est une exprience trs bnfique pour, la fois, apprendre programmer des applications rseau, tenir compte des diffrentes plateformes disponibles et faire de la gestion de processus. L architecture d un tel environnement nous fait trouver des petites astuces, auxquelles
on n aurait jamais pens auparavant, et qui nous serviront trs certainement pour la suite de
notre cursus professionnel.
De plus, c est dans une bonne ambiance que ce stage s est ralis, ce qui contribue
beaucoup la satisfaction personnelle de cette exprience professionnelle. Je n hsiterai donc
pas de nouveau postuler pour un stage dans un laboratoire de recherche, et c est aussi pourquoi j ai dj demand travailler au CDS cet t.
37
Automne 2003
%LEOLRJUDSKLH
Documents crits :
Sbastien NICAISSE, Analyse et mise en uvre d un cluster dans le domaine astronomique , Rapport de stage, 2003.
Maurice Libes, Utilisation d un cluster de calcul openMosix et dploiement l aide de
LTSP .
Emmanuel Jeannot, Calcul distribu : une introduction .
G.A. Geist, J.A. Kohl, P.M. Papadopoulos, PVM and MPI : a Comparison of Features, Arcticle,1996.
A. Prieto, The Lightweight Protocol CLIC : Performance of an MPI implementation on
CLIC.
Albeaus Bayucan, Casimir Lesiak, etc., Portable Batch System : Internal Design Specification, Documentation, 1999.
William Gropp, Ewing Lusk, Installtion and User Guide of MPICH, a portable implementation of MPI, Documentation.
The LAM/MPI Team, The LAM/MPI Installation Guide Version 7.0, Documentation,
2003.
The LAM/MPI Team, The LAM/MPI User Guide Version 7.0, Documentation, 2003.
Sites Internet :
Site du CDS :
http://cdsweb.u-strasbg.fr/
Site de LAM/MPI :
http://www.lam-mpi.org/
Site de PVM :
http://www.csm.ornl.gov/pvm/pvm_home.html
Site du projet openMosix :
http://openmosix.sourceforge.net/
Site d OpenPBS :
http://www.openpbs.org/
Lien vers le projet GNU Queue :
http://sourceforge.net/projects/queue/
Aide pour LaTeX :
http://www.tldp.org//TeTeX-HOWTO-4.html
38

Bucher Thomas Rapport ST 402003

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bucher Thomas Rapport ST 402003

Enviado por

Direitos autorais:

Formatos disponíveis

11, rue de lUniversit

ST40 Stage professionnel

Dveloppement dun environnement de

Rapport de stage professionnel

Prsentation du lieu d accueil......................................................................................... 4

1.1 L Observatoire Astronomique de Strasbourg ............................................................................. 4

Prsentation du sujet ...................................................................................................... 7

2.1 Contexte ...................................................................................................................................... 7

Recherche de technologies ddies au clustering.......................................................... 11

3.1 Qu est-ce que le clustering ?..................................................................................................... 11

Analyse comparative des technologies ......................................................................... 17

4.1 Choix de la plateforme utilise ................................................................................................. 17

Structure de l environnement de distribution............................................................................ 20

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

6.1 Mises en exploitation actuelles ................................................................................................. 32

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

L Observatoire astronomique de Strasbourg est un Observatoire des sciences de

Les quipes de recherche de l Observatoire suivent quatre thmes dominants :

Le Traitement massif de donnes

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

Ce service a t cr en 1972 sous le nom de Centre de Donnes Stellaires, et est gr

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

Les 3 services majeurs proposs par le CDS sont les suivants :

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

De manire simplifie, Aladin possde une banque de plusieurs millions d images

Figure 1. Structure du service Aladin

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

analyse des diffrentes possibilits

dveloppement d une version finale

rdaction des documentations

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

tude de la distribution CLIC

ralisation de quelques essais avec MPI

installation matrielle du cluster prototype sous Linux

application du prototype un cas rel : Marsiaa

interfaage de l environnement avec un service d Aladin

rdaction des documentations (Utilisateur, Administrateur,

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

Avant de se lancer dans la ralisation d un systme permettant de distribuer des tches

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

BUCHER Thomas - GI03 - UTBM

Rapport de stage professionnel

Organisation physique des processus

Organisation virtuelle des processus

Figure 2. Cration d'

Un accs transparent au matriel de la machine virtuelle: par exemple, un processus de

Une architecture gnrale de la machine ressemblant un systme Unix, c'

Un modle de passage de message explicite : chaque processus communique et utilise