Rapport de projet de fin d’étude Etude de la … · Rapport de projet de fin d’étude ......

Rapport de projet de fin d’etude

Etude de la technologie JavaSpace sur un cluster de PCsSupelec - Option IIC

Professeurs Encadrants : Stephane Vialle et Virginie Galtier12 Avril 2006

par Farid Rahba et Renaud Boutet

Resume : Dans ce projet, nous etudions les performances de la technologieJavaSpace dans les calculs paralleles. Nous disposons pour ce faire d’un clusterde 32 PCs sur lequel nous deployons la simulation des trajectoires de N planetes(plus connu sous le nom de probleme des N corps). Nous nous interessons auxperformances de ce systeme quant aux accelerations obtenues, et nous essayonsde mettre en place une gestion efficace des pannes.

Table des matieres

1 Introduction 2

2 Presentation du probleme des N-Corps 4

3 Algorithmes sequentiels mis en œuvre 63.1 Algorithme de reference . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.2 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Algorithme optimise . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.2 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Premiers pas avec JavaSpace 144.1 Principes generaux . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Comment lance-t-on un JavaSpace ? . . . . . . . . . . . . . . . . . 16

5 Quelques remarques pour une mise en place efficace de benchs 175.1 Mesure des performances . . . . . . . . . . . . . . . . . . . . . . . 175.2 Mise en place des benchs . . . . . . . . . . . . . . . . . . . . . . . 185.3 Automatisation des connexions . . . . . . . . . . . . . . . . . . . 19

6 Parallelisation de l’algorithme de reference 216.1 Introduction au probleme de parallelisation . . . . . . . . . . . . . 216.2 Algorithme avec centralisateur . . . . . . . . . . . . . . . . . . . . 22

6.2.1 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . 226.2.2 Deploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2.3 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Deuxieme parallelisation de l’algorithme de reference 287.1 Nouveau transit de donnees . . . . . . . . . . . . . . . . . . . . . 287.2 Travailleur a recouvrement de donnees . . . . . . . . . . . . . . . 297.3 Introduction d’une information de commande . . . . . . . . . . . 29

7.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3.2 Interets majeurs . . . . . . . . . . . . . . . . . . . . . . . . 30

ii TABLE DES MATIERES

7.4 Recapitulation du fonctionnement de l’algorithme . . . . . . . . . 307.5 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.6 Version sans recouvrement . . . . . . . . . . . . . . . . . . . . . . 40

8 Tolerance aux pannes 428.1 Introduction du probleme . . . . . . . . . . . . . . . . . . . . . . 428.2 Gestion des pannes des travailleurs . . . . . . . . . . . . . . . . . 42

8.2.1 Mise en place d’un systeme d’annonce des travailleurs . . . 428.2.2 Detection de la panne . . . . . . . . . . . . . . . . . . . . 438.2.3 Gestion des pannes . . . . . . . . . . . . . . . . . . . . . . 448.2.4 Recapitulatif et schemas de principe . . . . . . . . . . . . 458.2.5 Performances obtenues . . . . . . . . . . . . . . . . . . . . 49

9 Conclusion 50

A Automatisation des connexions 51

Bibliographie 54

Table des figures

3.1 Diagramme UML de l’algorithme sequentiel . . . . . . . . . . . . . . . . 8

3.2 Trajectoires de 16 planetes en interaction gravitationnelle . . . . . . . . . 9

3.3 Evolution des performances de l’algorithme sequentiel de reference en fonctiondu nombre de planetes . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Evolution des performances de l’algorithme sequentiel optimise en fonction dunombre de planetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5 Comparaison des deux algorithmes sequentiels . . . . . . . . . . . . . . . 13

4.1 Les differentes operations sur un JavaSpace . . . . . . . . . . . . . . . . 15

6.1 Deploiement sur le cluster de 32 PCs . . . . . . . . . . . . . . . . . . . 23

6.2 Temps d’execution en fonction du nombre de planetes et du nombre de pro-cesseurs pour la version 1 de l’algorithme parallelise . . . . . . . . . . . . 24

6.3 Temps d’execution en fonction du nombre de planetes pour differentes confi-gurations du nombre de processeurs et pour la version 1 de l’algorithme pa-rallelise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.4 Temps d’execution en fonction du nombre de processeurs pour differentesconfigurations du nombre de planetes et pour la version 1 de l’algorithmeparallelise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.5 Courbes de speed-up pour differentes configurations du nombre de processeurspour la version 1 de l’algorithme parallelise . . . . . . . . . . . . . . . . 27

7.1 Etape 1 de l’algorithme parallelise version 2 . . . . . . . . . . . . . . . . 31




7.5 Temps d’execution en fonction du nombre de planetes et du nombre de pro-cesseurs pour la version 2 de l’algorithme parallelise . . . . . . . . . . . . 35

7.6 Temps d’execution en fonction du nombre de planetes pour differentes confi-gurations du nombre de processeurs et pour la version 2 de l’algorithme pa-rallelise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

iv TABLE DES FIGURES

7.7 Temps d’execution en fonction du nombre de processeurs pour differentesconfigurations du nombre de planetes et pour la version 2 de l’algorithmeparallelise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.8 Courbes de speed-up pour differentes configurations du nombre de processeurspour la version 2 de l’algorithme parallelise . . . . . . . . . . . . . . . . 37

7.9 Temps d’execution en fonction du nombre de processeurs pour la version 2 del’algorithme et pour 7000 planetes . . . . . . . . . . . . . . . . . . . . 38

7.10 Speed-up en fonction du nombre de processeurs pour la version 2 de l’algo-rithme et pour 7000 planetes . . . . . . . . . . . . . . . . . . . . . . . 38

7.11 Efficacite en fonction du nombre de processeurs pour la version 2 de l’algo-rithme et pour 7000 planetes . . . . . . . . . . . . . . . . . . . . . . . 39

7.12 Extensibilite pour la deuxieme parallelisation de l’algorithme de reference . 407.13 Gain moyen de la version sans recouvrement Calculs/Communications par

rapport a la version avec recouvrement en fonction du nombre de processeurs 41

8.1 Calcul des periodes d’annonces et de verifications (gestion des pannes) . . . 448.2 Gestion des pannes, initialisation des travailleurs . . . . . . . . . . . . . . 468.3 Gestion des pannes, initialisation du client . . . . . . . . . . . . . . . . . 468.4 Gestion des pannes, annonces de presence . . . . . . . . . . . . . . . . . 478.5 Gestion des pannes, absence d’une annonce 1 . . . . . . . . . . . . . . . 478.6 Gestion des pannes, absence d’une annonce 2 . . . . . . . . . . . . . . . 48

Liste des tableaux

6.1 Bilan des communications en un cycle pour la version 1 de l’algorithme parallelise 25

7.1 Bilan des communications en un cycle pour la version 2 de l’algorithme parallelise 29

Liste des Algorithmes

1 Algorithme sequentiel de reference . . . . . . . . . . . . . . . . . . 72 Algorithme sequentiel optimise . . . . . . . . . . . . . . . . . . . . 11

Chapitre 1

Introduction

Les clusters de PCs constituent aujourd’hui une solution economique et ex-tensible aux problemes de calcul intensif. La methode native et non triviale deprogrammation d’un cluster de PCs est la creation de processus communiquantpar envois de mesages a travers le cluster. La programmation par partage dememoire est souvent plus simple a exploiter, mais necessite une memoire par-tagee alors que les clusters n’offrent qu’une memoire distribuee.

Une solution hybride consiste a installer une memoire partagee virtuelle (ouDSM : Distributed Shared Memory) au-dessus de l’architecture native du clus-ter pour emuler une machine parallele a memoire partagee. Des solutions 100%materielles existent jusqu’a 512 processeurs et se revelent performantes mais trescheres. A l’oppose, des solutions purement logicielles sont bon marche et sup-portent l’ensemble des operations standards sur une memoire partagee, mais ellesrestent peu performantes et limitees a 32 processeurs. Une variante consiste a uti-liser une DSM au-dessus d’un ensemble de JVM, et a offrir aux utilisateurs un en-semble plus limite de mecanismes d’acces a la memoire partagee. Les JavaSpacesconstituent une technologie appreciee dans le monde industriel, car beneficiant dela portablilite Java et d’une grande simplicite de partage de donnees (on pourrase reporter a [5]).

Cependant, les JavaSpaces ne resolvent pas tous les problemes poses parl’utilisation d’un cluster de PCs. Par exemple, la tolerance aux pannes etle respect des contraintes de temps restent de reels problemes, car tous lescomposants d’un systeme distribue sont rarement operationnels en meme temps.Ainsi, nous avons cherche dans ce projet a explorer cette technologie afin derepondre aux questions suivantes :

– Comment assurer la tolerance aux pannes (si une machine disparaıt subi-tement du cluster) ?

– Comment eventuellement tirer profit de l’arrivee d’une nouvelle machinedans le cluster en cours d’experience ?

– Cette technologie permet-elle d’obtenir des accelerations convenables et de

3

passer a l’echelle ?– ...

Pour mener a bien ces investigations, nous avons developpe une applicationsupport generant de gros calculs et de nombreux acces aux donnees stockeesen memoire : le probleme des N-Corps. On simule alors le mouvement de Nplanetes, en attractions mutuelles, sur notre cluster de 32 PCs a travers desJavaSpaces.

Ce document presente de maniere detaillee les algorithmes, les procedures misen place pour le calcul parallele, ainsi que les resultats obtenus suite aux differentsbancs d’essais. Il s’organise de la maniere suivante : le chapitre 2 est consacre a lapresentation du probleme des N-Corps ; le chapitre 3 detaille les deux algorithmessequentiels mis en place ; le chapitre 4 presente les differentes techniques utiliseespour facilement gerer un cluster de PCs et mettre en place les mesures, et enfinles chapitres suivants exposent les differentes versions de parallelisation mises enœuvre.

Chapitre 2

Presentation du probleme desN-Corps

Il s’agit d’un probleme classique sur lequel se sont penches de nombreux phy-siciens et mathematiciens. Il consiste a resoudre les equations du mouvement deN corps interagissant gravitationnellement, connaissant leurs masses ainsi queleurs positions et vitesses initiales.

Une application celebre concerne l’evolution du systeme solaire grace al’etude du mouvement des planetes.

Si il a tant attire l’attention des scientifiques, c’est sans aucun doute du a sadifficulte. Certes, pour N = 2 et N = 3, le probleme est resoluble analytiquement,mais au-dela, cela devient impossible. Comment faire ?

Comme souvent, on se contente de solutions approchees, deux approches sontutilisees :

– la theorie des perturbations, qui permet de faire des calculs analytiquesapproches sous la forme de developpements en serie.

– l’analyse numerique.

C’est cette derniere approche qui nous interesse ici, car elle met en oeuvredes methodes numeriques que l’on peut facilement automatiser et ainsi mettre aprofit les ordinateurs.

L’idee est relativement simple : elle consiste a discretiser les equations de laphysique. Decrivons un peu cette demarche.

Nous partons de la celebre relation fondamentale de la dynamique :

m−→a =−→F

5

ou m designe la masse,−→a l’acceleration et−→F l’ensemble des forces qui

s’appliquent sur un objet.

On considere des lors N planetes de masse mi, de position pi. La force gravi-tationnelle qu’exerce la planete j sur la planete i est donnee par :

−→F j→i = Gmimj

pj − pi

‖ pj − pi ‖3

ou G designe la constante gravitationnelle, ‖ pj − pi ‖ represente la distanceentre les planetes i et j.

En combinant les deux equations precedentes, on obtient :

d2pi

dt2= G×

∑1≤j≤N

j 6=i

mjpj − pi

‖ pj − pi ‖3

On a obtenu ainsi un systeme d’equations differentielles non-lineaires,insoluble de maniere analytique. On va discretiser cette equation en essayant decalculer les positions pi aux instants n∆t . On designe alors par pn

i la position dela planete i a l’instant n.

On approche l’expressiond2pi

dt2 parpn+1

i +pn−1i −2pn

i

∆t2. Notre systeme d’equations

devient :

pn+1i = 2pn

i + ∆t2G∑

1≤j≤Nj 6=i

mj

pnj − pn

i

‖ pnj − pn

i ‖3− pn−1

i

On peut ainsi calculer la position de la planete i a l’instant n+1 en connais-sant les positions de toutes les planetes aux instants n et n-1.L’algorithme est alors simple : connaissant les positions et vitesses initiales des Nplanetes, on calcule toutes les positions etape apres etape (c’est-a-dire a l’instant∆t, puis 2∆t, puis 3∆t...).Remarque : pour calculer les positions des planetes a l’instant ∆t, il fautconnaıtre les positions des planetes a l’instant −∆t . Pour cela, on utilise l’ap-proximation :

p−1i = p0

i −∆tvi (vi est la vitesse initiale de la planete i)

Chapitre 3

Algorithmes sequentiels mis enœuvre

3.1 Algorithme de reference

3.1.1 Implantation

Dans un premier temps, nous avons cherche a coder le probleme de manieresimple, c’est a dire en respectant les equations discretes prealablement trouvees.L’algorithme qui en decoule est presente ci-apres (Algorithme (1)).Il est a remarquer que cet algorithme est en O(n2) : en effet, pour chaque planeteil faut calculer (n − 1) interactions, ce qui fait au total n(n − 1) interactions.Cet algorithme est naıf dans le sens ou nous calculons 2 fois la meme interaction(sachant que l’interaction d’un planete p sur une planete q est la meme que celle

exercee par q sur p selon le principe d’interaction−→F p→q = −

−→F q→p).

Nous avons utilise le langage Java (en vue de l’utilisation future des JavaS-paces). D’un point de vue objet, nous avons defini les classes suivantes :

– la classe Planete : on y consigne les informations suivantes : la vitesse ini-tiale, la masse, son nom ainsi que sa position aux instants n∆t et (n−1)∆t.

– la classe Univers : on y trouve la constante gravitationnelle G, l’intervallede discretisation ∆t, son nom ainsi que le tableau des objets Planete quiconstituent cet univers. La methode c positions() permet le calcul des po-sitions de l’ensemble des planetes de l’univers a l’instant (n + 1)∆t (lespositions aux instants n∆t et (n − 1)∆t etant consignees dans les objetsPlanete).

– la classe Scrib : permet l’ecriture des positions dans un fichier texte.– la classe Main : elle permet d’effectuer le calcul pour un nombre de planetes

et un nombre de cycles donnes en argument.

3.1 Algorithme de reference 7

Algorithme 1 : Algorithme sequentiel de reference

Donnees : le nombre de cycles nb cycles et le nombre de planetesnb planetes

Creation d’un univers Univers de nb planetes planetes : on equirepartitles planetes sur une sphere ou sur un cercle ; on choisit des vitessesinitiales tangantielles et de meme norme.pour i← 1 a nb cycles faire

pour chaque planete courante dans Univers faireinitialisation t Resultat [] ; /* tableau de taille nb planetesqui va permettre de calculer les positions a

l’instant i∆t pour l’ensemble des planetes */

pi−1courant ← position de planete courante a l’instant (i− 1)∆t

j ← 0pour chaque planete influence dans Univers tel queplanete influence 6= planete courante faire

distance ← distance entre planete courante etplanete influencemasse ← Masse de planete influencepi−1

influence ← position de planete influence a l’instant (i− 1)∆t

composante influence ← pi−1influence−pi−1

courant

distance

t Resultat [ j ] ← t Resultat [ j ]+ masse ×composante influence


t Resultat [ j ] ← (∆t)2G× t Resultat[j] + 2× pi−1courant − pi−2

courant

j ++Mise a jour de la position de planete courante

8 Algorithmes sequentiels mis en œuvre

Le diagramme 3.1 permet de visualiser l’organisation de ces classes.

Fig. 3.1 – Diagramme UML de l’algorithme sequentiel

C’est dans la methode main() de la classe Main que se trouve la boucle decycles qui permet de calculer les positions instant apres instant. Les arguments apasser sont dans l’ordre : le nombre de planetes, le nombre de cycles et Oui/Nonsi on veut ecrire les resultats des trajectoires. Lorsque le calcul est termine, nousimprimons sur la console le temps total d’execution, le nombre de planetes, lenombre de cycles et le nombre de processeurs (ici 1).

Ainsi, si on veut lancer un calcul, on cree une instance de la classe Univers.Cet univers sera compose d’un ensemble d’objets Planete, qui possedent commeattribut la position a l’instant courant et a l’instant precedent. La classe Universpossede quant a elle une methode qui calcule les positions de toutes les planetesen remettant a jour les attributs correspondants.

L’unique instance de la classe Scrib ecrit, si elle en a l’ordre, toutes les positions

3.1 Algorithme de reference 9

des n planetes dans n fichiers .txt correspondants.

3.1.2 Resultats

La premiere etape afin de tester notre programme est de visualiser les tra-jectoires des planetes. Voici par exemple le comportement de 16 planetes uni-formement reparties sur un cercle, de meme masse et de vitesse initiale de memenorme et tangente au cercle1 (figure 3.2) : Ici, les tests

sont faitsen 2D avecdes planetesequirepartiessur un cerclemais parla suite, lesplanetes serontequirepartiessur une sphere.

Fig. 3.2 – Trajectoires de 16 planetes en interaction gravitationnelle

On remarque l’invariance par rotation des trajectoires, les planetes sont toutesattirees par le centre du cercle qui constitue le centre de gravite du systeme.

Nous supposons maintenant que l’algorithme fonctionne correctement etnous ne nous interesserons plus a la visualisation des trajectoires des planetes.Nous ferons juste des comparaisons de valeurs par rapport a cet algorithme dereference afin de verifier la validite des programmes futurs.

Nous allons maintenant nous interesser aux temps d’execution de l’algorithme.Les courbes suivantes presentent les premiers resultats en fonction du nombre deplanetes :

1Ici, nous visualisons les resultats a l’aide du logiciel GnuPlot.


Fig. 3.3 – Evolution des performances de l’algorithme sequentiel de reference en fonction dunombre de planetes

On remarque bien le caractere en O(n2) de l’algorithme sur la premierecourbe, les points representent les mesures reelles et la courbe l’approximationen moindres carres d’un polynome de degre 2. Celle-ci sera utilisee dans toutesnos etudes car elle permet de realiser de bonnes previsions concernant le tempsd’execution du programme.

La deuxieme courbe permet de confirmer la linearite de l’algorithme lorsquel’on represente le temps par cycle et par planete.

3.2 Algorithme optimise

3.2.1 Implantation

L’optimisation de l’algorithme consiste a ne pas realiser deux fois le memecalcul d’interaction entre planetes. Pour ce faire, nous realisons une double boucleen « triangle », la boucle externe se fera sur la collection de planetes et la boucleinterne sur les planetes d’indice superieur a l’entite courante. Au lieu des n(n−1)

calculs d’interaction precedents, il n’y en a plus que n(n−1)2

. L’algorithme estpresente ci-apres (Algorithme (2)).

3.2 Algorithme optimise 11

Algorithme 2 : Algorithme sequentiel optimise

Donnees : le nombre de cycles nb cycles et le nombre de planetesnb planetes

Creation d’un univers Univers de nb planetes planetes : on equirepartitles planetes sur une sphere ou sur un cercle ; on choisit des vitessesinitiales tangantielles et de meme norme.pour i← 1 a nb cycles faire

pour pi← 1 a nb planetes faireinitialisation t Resultat [] ; /* tableau de taille nb planetesqui va permettre de calculer les positions a

l’instant i∆t pour l’ensemble des planetes */

planete courante ← piieme planetemasse courante ← Masse de planete courantepi−1

courant ← position de planete courante a l’instant (i− 1)∆tpour pj ← pi + 1 a nb planetes faire

planete influence ← pjieme planetedistance ← distance entre planete courante etplanete influencemasse influence ← Masse de planete influencepi−1

influence ← position de planete influence a l’instant (i− 1)∆t

composante influence ← pi−1influence−pi−1

courant

distance

t Resultat [ pi ] ← t Resultat [ pi ]+ masse influence ×composante influencet Resultat [ pj ] ← t Resultat [ pj ]− masse courante ×composante influence

/* on retranche le resultat par le principe

d’interaction : Fi→j = −Fj→i */


t Resultat [ j ] ← (∆t)2G× t Resultat[j] + 2× pi−1courant − pi−2

courant

Mise a jour de la position de planete courante


3.2.2 Resultats

Les performances de cette version sont les suivantes :

Fig. 3.4 – Evolution des performances de l’algorithme sequentiel optimise en fonction dunombre de planetes

Les calculs se font encore bien sur en O(n2), cependant la difference de per-formance est notable. En effet, comparons les performances des deux versions,un indicateur interessant est celui du rapport entre les temps par cycle pour unnombre de planetes donne (ou speed-up)(figure 3.5).

La seconde version est donc environ deux fois plus rapide que la premiere.Cela etait previsible puisqu’il y a n(n − 1) calculs d’interaction pour la version

de reference et n(n−1)2

calculs pour la version optimisee.

Il paraıt alors evident qu’il faille adapter l’algorithme optimise aux calculsparalleles. Cependant , deux facteurs nous incitent a commencer par paralleliserla version naıve en premier lieu :

1. l’experience montre qu’il est assez complexe de paralleliser un algorithmeoptimise. On peut entrevoir les difficultes concernant notre probleme. Eneffet, imaginons que le processeur p s’occupe de la planete 1 et le processeurq s’occupe de la planete 2. Le processeur q devra attendre que p ait fini lecalcul de l’interaction entre 1 et 2 avant de continuer ses calculs.

3.2 Algorithme optimise 13

Fig. 3.5 – Comparaison des deux algorithmes sequentiels

2. Outre la complexite de la parallelisation, l’exemple precedent montre unautre aspect : paralleliser notre algorithme optimise implique egalementl’augmentation du nombre de communications. On gagne en temps CPUmais on perd toute notre avance dans l’attente des transferts.

Resume du chapitre Nous avons dans un premier temps implante en Javadeux versions du probleme des N-Corps pour le calcul des trajectoires de planetes.Les deux algorithmes suivent le schema numerique expose au chapitre precedentavec une optimisation sur le second. Les deux ont fourni des resultats previsibles :l’evolution en fonction du nombre de planetes suit une loi parabolique et l’onatteint des temps consequents (plusieurs heures) des lors que l’on traite plusieursmilliers de planetes. Si les deux versions presentent des differences notoires, c’estla version naıve qui sera utilisee pour la parallelisation. Pour faute de temps, nousn’avons pu paralleliser la version optimise, mais il serait interessant d’etudier lesperformances que l’on obtient.

Chapitre 4

Premiers pas avec JavaSpace

Dans ce chapitre, nous evoquons les principes de la technologie JavaSpaceainsi que la mise en place concrete de cette technologie.

4.1 Principes generaux

JavaSpace est une technologie basee sur la methode Linda. Elle propose unespace de stockage permettant le partage d’objets Java. Il s’agit d’un servicepropose au sein de l’architecture Jini de Sun Microsystems. Jini est un systemedistribue permettant la communication de differents materiels au sein d’unreseau local afin d’offrir des services reseaux a des applications. Toutefois, cettearchitecture est limitee a des reseaux locaux et utilise un gestionnaire centralisepour repertorier les differents services disponibles. Le service JavaSpace repose,pour les communications, sur la technologie RMI de Java.

Comment se fait ce partage d’objets Java ?

Avant de decrire les operations permettant de gerer notre espace de memoirepartagee, il faut definir la notion d’entree (Entry en anglais). Il s’agit sim-plement d’objets types que l’on depose dans l’espace. Concretement, lorsquel’on veut deposer un objet dans l’espace, il suffit que la classe qu’il representesoit serialisable et implemente l’interface net.jini.core.entry.Entry. Detaillonsmaintenant les operations que l’on peut effectuer sur notre espace :

– l’operation write permet d’enregistrer une nouvelle entree dans un JavaS-pace.

– pour rechercher une entree contenue dans un JavaSpace, on utilise desentrees modeles (template) en remplissant tout ou partie des champs cor-respondant exactement a celles des entrees recherchees. Il y a deux typesde recherche d’entree : read et take. L’operation read renvoit une copie de

4.1 Principes generaux 15

l’entree qui correspond a une entree modele demandee, ou une indicationsi aucune entree ne correspond. L’operation take fait la meme chose maisretire l’entree du JavaSpace.

– L’operation notify permet d’etre informe lorsqu’une entree, correspondanta un certain modele, est enregistree dans le JavaSpace.

Toutes les operations qui modifient un JavaSpace sont realisees de facon tran-sactionnelle. Ainsi, apres une operation write reussie, on est assure que l’objetse trouve bien dans le JavaSpace. De meme, apres une operation take reussie, onest assure que l’objet a ete retire du JavaSpace.

Le schema (4.1) permet de visualiser ces operations :

Fig. 4.1 – Les differentes operations sur un JavaSpace

Enfin, il existe plusieurs modes d’utilisation d’un JavaSpace (et plusgeneralement des services Jini) :

– un mode transient : les donnees, objets stockes ne sont valides et accessiblesque lorsque les services sont en etat de marche. Si l’un des services tombeen panne, les donnees sont perdues a jamais.

– un mode persistant : ici au contraire les donnees sont ecrites sur le disqueet on peut les recuperer apres une panne.

On peut egalement rendre ce dernier mode activable ou non-activable. L’ac-tivation, basee sur Java RMI permet par exemple de relancer automatiquementun service en cas de panne de celui-ci.

Pour plus d’informations sur les JavaSpace et plus generalement sur Jini, onpourra se reporter a [1].

16 Premiers pas avec JavaSpace

4.2 Comment lance-t-on un JavaSpace ?

On decrit ici brievement comment lancer les services JavaSpace pour avoirun espace pret a l’emploi.

Apres avoir installe la technolgie Jini (dans la cas present, le Jini TechologyStarter Kit v2.1 disponible sur le site http ://starterkit.jini.org), il s’agit princi-palement de lancer 4 services :

1. Un RMI activation daemon sur chaque hote hebergeant un service. Ceservice permet de gerer le mode activable : c’est un processus qui s’assureque les services activables sont disponibles si besoin est.

2. Un serveur web pour le chargement dynamique de classes.

3. Un look-up service Jini (l’implementation Sun s’appelle ”reggie”) : c’est unservice central de l’infrastructure Jini qui permet de localiser les servicesJini.

4. Un javaspace (l’implementation Sun s’appelle ”outrigger”).

Pour un exemple detaille d’utilisation du JavaSpace, on pourra se reporter a [2].

Chapitre 5

Quelques remarques pour unemise en place efficace de benchs

Une fois notre algorithme sequentiel parallelise, l’objectif principal est la me-sure de ses performances. En effet nous voulons par exemple savoir si notre al-gorithme passe a l’echelle. Pour ce faire, il faut mesurer les temps d’executiondu programme dans un ensemble de configurations possibles : en fonction de lataille du probleme (nombre de planetes), du nombre de processeurs, du nombrede cycles. Il est des lors tres interessant d’automatiser ces mesures, c’est a direde mettre en place des benchs (ou bancs d’essais) afin de recuperer les resultatsconsignes dans un fichier texte par exemple. Nous avons du repondre aux ques-tions suivantes :

– Comment mesure-t-on les performances de l’algorithme (quel temps mesure-t-on) ?

– Comment mettre en place des benchs ?– Comment automatiser les connexions au travers du cluster ?

5.1 Mesure des performances

Il existe de nombreuses techniques pour mesurer le temps et on peut mesurerdifferents types de temps : le temps total, le temps CPU, le temps de la bouclede calcul uniquement ... Nous utilisons dans nos programmes les lignes de codesuivantes :

1 long wctAvant = System.currentTimeMillis (); /*

heure au debut de l’execution */

2 .... Calculs ......

3 long wctApres = System.currentTimeMillis (); /*

Heure a la fin de lexecution */

4

18 Quelques remarques pour une mise en place efficace de benchs

5 long duree = wctApres - wctAvant; /*temps d’

execution */

Il s’agit d’un temps de type wallclocktime : on mesure le temps total du pointde vue utilisateur. Nous avons choisi ce temps1 car il permet de mesurer a la foisles temps de calcul et de communication.

5.2 Mise en place des benchs

Pour evaluer la performance d’une parallelisation, il est necessaire de faire unebatterie de calculs dans differentes configurations. Il devient des lors interessantd’automatiser la mise en place de ces calculs. Par exemple, on lance un calcul lesoir et on revient recuperer l’ensemble des resultats le lendemain matin.

Pour ce faire, on ecrit un script en langage bashshell. Prenons un exemple descript utilise :

1 rm -f resall.txt

2

3 for ((I=12;I<46;I++)); do

4

5 /usr/java/jdk1 .5.0 _06/bin/java -Djava.security.

policy =/tmp/Projet_Boutet_Rahba/Config/jsk -all.

policy -classpath /usr/java/Jini2_1/lib/jini -ext.

jar:/tmp/Projet_Boutet_Rahba/CodePlanetes/

Client 193.48.224.86\$((\$I*\$I)) 30 3 "non">&

res1.txt

6

7 cat res1.txt >> resall.txt;

8

9 done

Ici, la ligne

/usr/java/jdk1.5.0_06/bin/java -Djava.security.policy=

/tmp/Projet_Boutet_Rahba/Config/jsk-all.policy-classpath /usr/java/Jini2_1/

lib/jini-ext.jar :/tmp/Projet_Boutet_Rahba/CodePlanetes/

Client 193.48.224.86\$((\$I*\$I)) 30 3 "non"

permet d’effectuer le calcul parallele pour I2 planetes, 30 cycles et 3 processeurs.et on copie le resultat (c’est a dire le temps d’execution) grace a

>& res1.txt

1ce principe de mesure est egalement utilise pour les mesures de l’algorithme sequentiel.

5.3 Automatisation des connexions 19

La ligne

cat res1.txt >> resall.txt ;

permet de recuperer les resultats pour differentes valeurs de I dans le fichierresall.txt.

Pour rendre notre script executable, il suffit de changer ses proprietes enutilisant la commande linux chmod. Une fois cela fait, on lance les calculs entapant dans une fenetre de commande :

./<nom du script>

En sortie, on recupere un fichier texte de la forme suivante2 :

1 #Nbre Planetes = 100 Nbre Cycles = 50 Ecriture

fichiers = non

2 #TempsReelCalcul ,Temps par cycle ,NbrePl ,NbreCycles

,NbProcs

3 687 13.0 100 50 1


fichiers = non


,NbProcs

6 5618 112.0 300 50 1


fichiers = non


,NbProcs

9 16486 329.0 500 50 1


fichiers = non


,NbProcs

12 33186 663.0 700 50 1

5.3 Automatisation des connexions

Pour lancer un calcul parallele, il faut lancer les differents services JavaSpaceainsi que les PCs sur lesquels se feront les calculs. Cela devient vite fastidieux,car a chaque fois que l’on se connecte sur un PC, il y a une authentification.

2le temps est mesure en millisecondes

20 Quelques remarques pour une mise en place efficace de benchs

Nous avons fait en sorte qu’il n’y ait plus aucune authentification. Pour plus derenseignements, on pourra se reporter a l’annexe.

Chapitre 6

Parallelisation de l’algorithme dereference

6.1 Introduction au probleme de parallelisation

Les deux objectifs principaux a atteindre pour un bon algorithme parallelesont les suivants :

– Un nombre de communications minimum :Les communications permettent de faire circuler les resultats d’un proces-seur a un autre. Si le nombre de communications est important, nous ris-quons l’engorgement du reseau.Il faut donc ne declencher que les communications strictement necessaireset si possible etaler les communications dans le temps (tres difficile).

– Une utilisation des CPU a quasi 100% du temps :Le manque d’informations est forcement bloquant car sans elles, le CPUne peut pas travailler. Ainsi, a chaque moment ou le CPU attend nousperdons forcement de la performance en terme de speed-up.

Pour eviter ces ecueils, les solutions suivantes sont envisageables :

– faire du load balancing : on essaie d’equilibrer les charges de chaque proces-seur.

– acheminer les donnees avant d’en avoir besoin : on a par exemple recoursau recouvrement calculs/communications.

Par la suite, nous vous presentons differentes versions de parallelisation de laplus simple, naıve, a la plus elaboree, permettant la gestions des pannes. Nousutilisons frequemment quelques termes pour l’ensemble des versions :

– client : proceseur qui gere le contenu du JavaSpace et distribue le travailau differents travailleurs (on ne parle pas du PC sur lequel est l’outrigger).

22 Parallelisation de l’algorithme de reference

– travailleur : processeur qui effecute des calculs.

6.2 Algorithme avec centralisateur

6.2.1 Implantation

Afin de realiser les premiers tests nous avons cherche a coder de la manierela plus simple possible. Nous utilisons donc un PC en tant que synchroniseur oucentralisateur, il est charge de recuperer toutes les informations, de les rearrangerpuis de les remettre dans le JavaSpace afin que les travailleurs puissent aborderle cycle suivant.

Le parc de travailleurs, au nombre de P, represente les machines de calcul.Un travailleur ecoute si une tache correspondant a son attente (c’est-a-dire a sonmodele ou template ) se trouve sur le JavaSpace. Si oui, il la recupere, execute letravail et la repose sur le JavaSpace.

Le centralisateur aura ainsi pour role de creer p taches que devront effectuerles p travailleurs ou processeurs.

Chaque tache est constituee de la liste des N planetes et de deux indices(debut et fin) pour la boucle de calcul. Chaque machine devra alors calculer lespositions des N/p planetes correspondant aux indices debut et fin.

6.2.2 Deploiement

Nous decrivons ici comment nous avons deploye les divers services JavaS-paces, les travailleurs et le client sur le cluster de 32 PCs.

Nous pouvons remarquer que les travailleurs et le client necessitent chacun unPC. Il reste donc a savoir comment repartir les services JavaSpace. Apres plusieurstests de performance, nous avons remarque que les differences sont faibles selonque l’on concentre tous les services sur un seul PC ou contraire lorsqu’on lesrepartit. Nous avons utilise pour tous nos benchs le diagramme de deploiementrepresente en figure 6.1. Les 32 PCs a notre disposition sont nommes sh01, sh02,sh03, ..., sh32. Il s’agit de Shuttle Pentium 4 3 GHz avec 1GO de RAM.

6.2 Algorithme avec centralisateur 23

Fig. 6.1 – Deploiement sur le cluster de 32 PCs


6.2.3 Resultats

Etudions maintenant les performances obtenues, nous avons pour ce faireutilise le logiciel Matlab.Le bench sur lequel se basent nos resultats est le suivant :

1 Pour I de 0 a 9 faire

2 Pour J de 0 a 10+2*I

3 Calcul parallelise pour 100+200*J planetes , 50

cycles et 2+3*I processeurs

4 Fin Pour

5 Fin Pour

Autrement dit, nous effectuons les calculs pour 2,5,8,...,26,29 processeurset un nombre de planetes de plus en plus important avec le nombre de processeurs.

Une premiere maniere de visualiser est de representer le temps d’executionen fonction du nombre de planetes et du nombre de processeurs. On obtientainsi la surface1 suivante (figure 6.2) :

Fig. 6.2 – Temps d’execution en fonction du nombre de planetes et du nombre de processeurspour la version 1 de l’algorithme parallelise

Cependant, cette representation n’est pas tres pratique afin d’analyser lesresultats. Nous allons maintentant etudier differentes coupes de cette surface.Tout d’abord, on peut verifier que les calculs sont toujours en O(n2) pour les

1On parle de surface ”semi-reelle” car nous l’avons completee grace a une approximationpolynomiale de degre 2 pour chaque configuration du nombre de processeurs. Les points reelssont delimites par la ligne rouge.


differentes configurations du nombre de processeurs (figure 6.3).Lorsque l’on represente le temps d’execution en fonction du nombre de proces-seurs pour un nombre de planetes donne, on obtient dans l’ideal une hyperbole.Cependant, dans la realite, plus le nombre de processeurs est important, plusl’effet des communications se fait ressentir. Le resultat obtenu est represente enfigure 6.4.Pour un nombre de processeurs inferieur a 10, on obtient bien un comportementhyperbolique. Cependant, ce n’est plus le cas au-dela. Faisons alors un bilan descommunications : (tableau 6.1)

Nb de planetes envoyees Nb de planetes recues Nb de connexionsClient NP NP 2P

1 Travailleur N N 2Total 2NP 2NP 4P

Tab. 6.1 – Bilan des communications en un cycle pour la version 1 de l’algorithme parallelise

On remarque ainsi que le client doit envoyer et recevoir NP planetes, ce quifait un transit total de 2NP planetes ; des lors, l’impact des communications sefait ressentir au fur et a mesure que l’on augmente le nombre de processeurs(par contre cette augmentation ne se fait pas ressentir au niveau du travailleur).En outre, pendant que le client met plus de temps pour recuperer et envoyer lesplanetes, les travailleurs ne peuvent pas travailler. On peut resumer de la manieresuivante : pour un nombre de planetes donne, plus on augmente le nombre deprocesseurs, plus le client doit gerer des communications et consequemment, plusles travailleurs sont oisifs.


Fig. 6.3 – Temps d’execution en fonction du nombre de planetes pour differentes configura-tions du nombre de processeurs et pour la version 1 de l’algorithme parallelise

Fig. 6.4 – Temps d’execution en fonction du nombre de processeurs pour differentes configu-rations du nombre de planetes et pour la version 1 de l’algorithme parallelise


Analysons maintenant les courbes de speed-up (figure 6.5) :

Fig. 6.5 – Courbes de speed-up pour differentes configurations du nombre de processeurspour la version 1 de l’algorithme parallelise

Cette courbe est obtenue de la maniere suivante :

On note T (N, P ) le temps d’execution de notre algorithme parallelise. Nouschoisissons comme reference T (N, 1). Le speed-up S(N, P ) est alors donne par :

S(N, P ) =T (N, 1)

T (N, P )

Nous aurions pu egalement choisir le temps mis par l’algorithme sequentielcomme reference, mais nous avons remarque que celui-ci etait tres peu differentde T (N, 1).

Ainsi, pour 2 et 4 processeurs, on obtient bien le speed-up desire, mais pour17 processeurs, on atteint a peine un speed-up de 8 pour 6000 planetes. Pireencore, pour 29 processeurs, le speed-up atteint est de 4 ! L’algorithme ne permetdonc pas d’obtenir des accelerations convenables. Ici encore, on ressent l’effet descommunications grandissantes avec le nombre de proceseurs.

Chapitre 7

Deuxieme parallelisation del’algorithme de reference

7.1 Nouveau transit de donnees

Ayant accumule un peu d’experience, nous sommes alors en mesure deconcevoir un programme parallelise economisant un peu plus les communications.

En effet, l’un des ecueils de l’algorithme precedent est le surcout engendre parla mauvaise gestion des informations. En effet, un travailleur prend l’ensembledes N planetes, traite le resultat et renvoie le meme groupe dans le JavaSpace.Le client se charge alors de recuperer toutes les informations pour les classer afinde reemettre P groupes de N planetes.

Dans la nouvelle version, le client n’est plus utilise comme synchronisateur, ilest simplement charge de collecter les informations jugees inutiles dans le JavaS-pace. Le principe du nouvel algorithme est alors le suivant : sur le JavaSpace estpresente la liste des N planetes. Chaque travailleur (ou processeur) est charge ducalcul pour N/P planetes. Pour ce faire, chaque travailleur vient lire les donneesdirectement sur le JavaSpace. Une fois le calcul fait pour un groupe de N/Pplanetes, le travailleur depose le groupe de planetes sur le JavaSpace. Une foisque tous les travailleurs ont fini cette tache, le client ”fait le menage” en retirantles donnees obsoletes.

De la meme maniere que precedemment, essayons d’evaluer les communica-tions pour cette version (tableau 7.1) :

On voit nettement l’amelioration : du point de vue Client, au lieu du transit de2NP planetes, il n’a plus que N planetes transitees. Du cote Travailleur, on passede 2N a N planetes transitees. On augmente les chances de passage a l’echelle(on espere obtenir des hyperboles !).Cependant, il a plus de connexions declenchees dans cette version : on atteint

7.2 Travailleur a recouvrement de donnees 29

Nb de planetes envoyees Nb de planetes recues Nb de connexionsClient 0 N P

1 Travailleur N/P (P − 1)N/P P − 1Total N NP P 2

Tab. 7.1 – Bilan des communications en un cycle pour la version 2 de l’algorithme parallelise

P 2 connexions au total, autrement dit, pour 29 processeurs, 841 connexions parcycle. On espere que cela n’aura pas trop de consequences sur les performancesdu systeme.

Cote calculs, les travailleurs ont toujours N/P trajectoires a leur charge maisn’ont plus en leur possession la totalite des planetes.

7.2 Travailleur a recouvrement de donnees

Nous avons cherche au maximum a ne pas perdre de temps CPU. Pour cefaire, les travailleurs calculeront en meme temps qu’ils recupereront les donnees.

Le thread collectant les informations se charge de recuperer des groupes deN/P planetes et les place dans une liste que le thread de calcul peut consulter.Il se met en veille s’il a recupere P − 1 paquets de N/P planetes.

Le thread de calcul peut alors directement enchaıner d’une boucle de N/Pinteractions a une autre. On ”recouvre” le temps de communication.

7.3 Introduction d’une information de com-

mande

7.3.1 Principe

Nous avons pense a mettre en œuvre un transit d’informations entre le clientet les travailleurs autre que les donnees de calculs. Il s’agit d’informations decommande concernant le probleme a traiter comme le nombre de travailleurs encontact, le nombre de cycles a realiser et le numero de paquet a traiter a chaquecycle.

Cette implantation etait necessaire car auparavant les taches que le clientdeposait contenait toutes ces informations. Maintenant, le client ne fournit queles donnees a l’initialisation et se contente de recuperer les fruits du calcul, iln’est plus l’administrateur du calcul.

30 Deuxieme parallelisation de l’algorithme de reference

Il est important de comprendre que cette information de commande n’estutilisee que lors des initialisations ou des reallocations de taches. En d’autrestermes le client affecte a un travailleur cible d’effectuer un calcul sur un certaingroupe de planetes, pour un nombre de cycles donne en precisant le nombre deses partenaires.

7.3.2 Interets majeurs

– Le travailleur connaıt les informations du probleme lorsqu’il ramassela commande dans le JavaSpace. Ainsi un travailleur peut etre utilisedynamiquement, il n’est plus la peine de le relancer si le probleme changeses parametres (nombre de cycles, nombres de processeurs, ...).

– Il est possible d’entrevoir une gestion aisee des pannes. En effet, si le clientdetecte qu’une machine ne rend pas ses informations alors il envoie denouvelles commandes. Ces commandes realloueront dynamiquement lestaches de calcul aux machines restantes.

– Une troisieme utilisation est egalement possible : la gestion optimale d’unparc de machines. Si une machine tombe en panne, nous gerons cette si-tuation comme decrit precedemment. Si une machine se rajoute au reseau,elle se signale au client qui emet de nouvelles commandes afin de prendreen compte la nouvelle machine. Ainsi chaque machine est utilisee des sonentree.

7.4 Recapitulation du fonctionnement de l’algo-

rithme

Les schemas suivants permettent de recapituler les differentes etapes de l’al-gorithme, dans le cas de deux processeurs :

Etape 1 : Initialisation Le client met en place les fichiers de commande, lesgroupes de planetes et les depose dans le JavaSpace (figure 7.1).

Etape 2 : Les travailleurs recuperent (grace a take ) leur fichier de commande :ils connaissent desormais le nombre de processeurs, le nombre de cycles, ainsi queleur numero (figure 7.2).

Etape 3 : Les travailleurs recuperent le groupe de planetes correspondant aleur numero. Ils peuvent alors commencer a calculer pendant que le recolteurrecupere les autres groupes de planetes (figure 7.3).

7.4 Recapitulation du fonctionnement de l’algorithme 31

Etape 4 : Le cycle se termine alors : les travailleurs deposent leur resultat,puis commencent a calculer sur le groupe correspondant a leur numero et qui aete calcule au cycle precedent. Pendant ce temps, le client fait le menage dans leJavaSpace (figure 7.4).

Le processus se deroule ainsi cycle apres cycle. A la fin du dernier cycle, il ya un vidage complet de l’espace.

Fig. 7.1 – Etape 1 de l’algorithme parallelise version 2

7.4 Recapitulation du fonctionnement de l’algorithme 33


7.5 Resultats 35

7.5 Resultats

Etudions maintenant les performances obtenues, nous utilisons toujours lelogiciel Matlab.Nos resultats sont bases sur le meme type de bench que precedemment.

En premier lieu, on peut visualiser la surface qui represente le tempsd’execution en fonction du nombre de planetes et du nombre de processeurs (fi-gure 7.5) :

Fig. 7.5 – Temps d’execution en fonction du nombre de planetes et du nombre de processeurspour la version 2 de l’algorithme parallelise

On remarque une zone de ”turbulences” pour peu de planetes et ungrand nombre de processeurs. Cela est surement la consequence du nombre deconnexions : il y a P 2 connexions par cycle donc elles se font d’autant plus res-sentir que le temps d’un cycle de calcul est faible (moins il y a de planetes, plus cetemps est faible). On peut toujours verifier le caractere en O(n2) de l’algorithme(figure 7.6).

Lorsque l’on represente le temps d’execution en fonction du nombre deprocesseurs pour un nombre de planetes donne, on obtient cette fois ci unehyperbole. Le resultat est represente en figure 7.7.


Fig. 7.6 – Temps d’execution en fonction du nombre de planetes pour differentes configura-tions du nombre de processeurs et pour la version 2 de l’algorithme parallelise

Fig. 7.7 – Temps d’execution en fonction du nombre de processeurs pour differentes configu-rations du nombre de planetes et pour la version 2 de l’algorithme parallelise

7.5 Resultats 37

Analysons maintenant les courbes de speed-up : (figure 6.5)

Fig. 7.8 – Courbes de speed-up pour differentes configurations du nombre de processeurspour la version 2 de l’algorithme parallelise

On remarque une amelioration des resultats : pour 17 processeurs, on arrivea atteindre un speed-up de 15 (alors que auparavant on atteignait a peine unspeed-up de 4) et pour 29 processeurs, on atteint un speed-up de 20.

Nous essayons maintentant d’analyser les resultats asymptotiques, c’est a direpour un grand nombre de planetes (7000) et pour un nombre de processeursvariant entre 1 et 29. Tout d’abord, le temps d’execution en fonction du nombrede processeurs est represente en figure 7.9.

On remarque que des que le nombre de processeurs est important (au dela de5), notre algorithme ne suit pas tout a fait l’hyperbole de reference, mais l’effetdes communications se fait moins ressentir. Les figures 7.10 et 7.11 permettentd’observer les speed-up et l’efficacite. Ces figures confirment bien que le systemepermet d’obtenir des accelerations convenables, avec une efficacite de 76 % pour29 processeurs. On imagine bien cependant que pour un grand nombre de proces-seurs, le seed-up atteindra une valeur asymptotique maximale (c’est ce que l’onpeut entrevoir sur la courbe 7.10).


Fig. 7.9 – Temps d’execution en fonction du nombre de processeurs pour la version 2 del’algorithme et pour 7000 planetes

Fig. 7.10 – Speed-up en fonction du nombre de processeurs pour la version 2 de l’algorithmeet pour 7000 planetes

7.5 Resultats 39

Fig. 7.11 – Efficacite en fonction du nombre de processeurs pour la version 2 de l’algorithmeet pour 7000 planetes


Un autre resultat interessant est celui de l’extensibilite. On essaie de repondrea la question suivante : lorsqu’on augmente la taille du probleme (le nombre deplanetes), quel nombre de processeurs permet d’aboutir a un temps minimal ?Pour ce faire, on trace la courbe d’extensibilite : il s’agit du temps d’executionminimal parmi les configurations du nombre de processeurs possibles en fonctiondu nombre de planetes. Si cette courbe est constante, cela signifie que lorsqu’onaugmente la taille du probleme, on saura garder le meme temps d’execution parplanete avec notre systeme. On obtient la courbe representee en figure 7.12.

Fig. 7.12 – Extensibilite pour la deuxieme parallelisation de l’algorithme de reference

Les resultats sont tout a fait satisfaisants : on arrive a maintenir un tempsconstant. Ce temps vaut environ 0.3 ms.

7.6 Version sans recouvrement

On s’interesse ici aux resultats obtenus sans recouvrement calculs/communi-cations, c’est a dire lorsque le travailleur recupere un groupe de planetes, calculesur ce groupe de planetes, puis recupere un autre groupe de planetes et ainsi desuite.

7.6 Version sans recouvrement 41

On represente sur la figure 7.13 le gain moyen obtenu de la versionavec recouvrement par rapport a celle sans recouvrement en fonction dunombre de processeurs. Ce gain est obtenu avec la formule suivante : G =Temps sans recouvrememt−Temps avec recouvrement

Temps sans recouvrement. On remarque ainsi que l’on peut ob-

tenir des gains tout a fait interessants (jusqu’a plus de 26% pour 29 processeurs).Cela est tout a fait encourageant et montre que le recouvrement calculs/commu-nications est efficace.

Fig. 7.13 – Gain moyen de la version sans recouvrement Calculs/Communications par rapporta la version avec recouvrement en fonction du nombre de processeurs

Chapitre 8

Tolerance aux pannes

8.1 Introduction du probleme

Nous avons maintenant un algorithme parallele fiable qui se prete a la gestiondes pannes.

Plusieurs types de pannes ont ete identifiees :

– Panne du client : critique et difficilement gerable car le client recupere tousles resultats intermediaires.

– Panne d’un travailleur : principal objectif et pannes les plus courantes etantdonne du nombre de machines en jeu.

– Panne du serveur : critique, pas de solutions a ce jour.– Panne du JavaSpace : critique, gerable par l’utilisation du demon RMI et

de la persistance.– Panne du lookup : non critique pares la phase de connexion au JavaSpace.

Une grande partie de ce chapitre est donc consacre a la gestion des pannesde travailleurs, probleme algorithmiquement difficile a mettre en place et quinecessite d’etre robuste.

8.2 Gestion des pannes des travailleurs

8.2.1 Mise en place d’un systeme d’annonce des tra-vailleurs

Notre gestion de ce type de panne est basee sur un systeme d’annonceperiodique des travailleurs. Une annonce est constituee de plusieurs champs :

– du nom du travailleur comme identifiant general.

8.2 Gestion des pannes des travailleurs 43

– du numero du travailleur comme identifiant en relation avec le travail encours.

– d’une valeur booleenne travail fini indiquant si l’annonce est finale, c’est adire si le travailleur vient de finir sa tache.

– d’une valeur booleenne travail en cours indiquant si le travailleur ayantposte l’annonce est en cours de travail.

Les deux valeurs booleennes peuvent paraıtre redondantes mais sont cependantnecessaires pour gerer certaines situations.

Maintenant, lorsque l’on demarre un travailleur pour le rendre disponible a latache il poste une annonce portant son nom et ayant les deux valeurs booleennesfausses.

Lorsque tous les travailleurs disponibles ont ete demarres, on peut alors lancerle client. Ce dernier aura pour parametres, comme precedemment, un nombre deplanetes, un nombre de cycles et un nombre de travailleurs. Lors de l’initialisation,il se chargera de recuperer autant d’annonces qu’il lui en faut. Le client connaıtalors les travailleurs qui accompliront la tache et affecte, de facon ciblee, unemacro tache a chacun d’eux, nous avons d’ailleurs ajoute un champ comportantle nom du travailleur dans le fichier de commande.

En cas de defaut de travailleurs, le client se contente alors de ce qu’il a adisposition. Il annonce alors que l’on tourne en sous regime.

Il y a donc deux actions distinctes a realiser, celle de la detection qui consistea affirmer de la facon la plus sur possible qu’il y a bien une panne et celle dela gestion qui consiste a avertir les travailleurs afin qu’ils se re-initialisent et leclient peut alors reattribuer le travail. C’est ce que nous allons detailler dans lesdeux prochains paragraphes.

8.2.2 Detection de la panne

Passe la phase d’initialisation, le travailleur se met alors a emettreperiodiquement des annonces afin de signaler sa presence.

De son cote, le client verifie periodiquement son parc de travailleurs. Si uneannonce vient a manquer, le client considere le travailleur en question commeetant en panne.

Il est evident ici que cette periodicite risque d’engendrer de fausses pannes,en effet, si une annonce met trop de temps a traverser le JavaSpace le clientconsidere le travailleur reellement actif comme en panne. Cette eventualite estbien sur inadmissible.

Une question se pose alors concernant ces deux periodes, en effet, sans tempsde communication elles pourraient etre egales. Cependant, la realite n’est pas si

44 Tolerance aux pannes

avantageuse, nous pouvons alors modeliser le probleme de la maniere suivante :(figure 8.1)

Fig. 8.1 – Calcul des periodes d’annonces et de verifications (gestion des pannes)

Dans le programme, vu que l’incertitude est difficilement mesurable, nousavons pris une periode travailleur egale a 500 ms et une periode client egale a3000 ms. Aucune fausse panne n’a ete signalee a ce jour avec cette configuration.

Avec ce reglage, les pannes sont detectees avec une certaine incertitude allantde 3000 ms a 6000 ms ce qui reste acceptable au vu de la quantite de calculs aeffectuer. Il est a noter qu’il faudra rajouter a ce temps celui de la gestion de lapanne, c’est-a-dire, le temps entre la detection et la remise en route des calculssur une nouvelle configuration.

8.2.3 Gestion des pannes

Comme nous l’avons evoque precedemment, cette partie consiste a reinitialiserles travailleurs restants puis a reinitialiser le client. Nous allons detailler ici lafacon dont notre programme fonctionne.

Lorsque le client s’apercoit de la panne, il se charge d’envoyer des fichiers decommande cibles ayant le booleen panne fixe a true. Chacun des threads chargesde la gestion des pannes cote travailleurs se rend alors compte de la panne.

A ce moment, le thread d’annonce avertit les deux autres threads (Calculateuret Recolteur) de la panne puis s’eteint. Toute la complexite de la gestion se trouvea ce niveau ; il faut dans l’ordre :

– En parallele, lancer la reinitialisation du Calculateur et du Recolteur quietaient tous les deux en cours de travail. Il faut ainsi placer des tests desorties de boucle a des endroits strategiques en pensant bien a ne pas tropinfluer sur les lourdes boucles de calcul.

– Remettre a un etat coherent les variables de stockage et de synchronisation.– Attendre que chacun des threads ait fini son initialisation.


– Annoncer la disponibilite du travailleur sur le JavaSpace.– Attendre la nouvelle commande.

La mise en place d’un tel systeme a demande un grand nombre de remanie-ments , notamment l’intervention de nouvelles variables et structures de synchro-nisation.

8.2.4 Recapitulatif et schemas de principe

Dans les schemas suivants nous allons considerer que les threads Annonceursur les travailleurs et le thread GestionnairesPannes sur le client, constituant lesentites de gestion des pannes.

La suite correspond a un exemple ou deux travailleurs sont disponibles sur leJavaSpace, le client en demande en demande egalement 2.

Etape 1 : Les travailleurs doivent etre lances en premier afin qu’ils postentleurs annonces de disponibilite avant que le client effectue le compte. A ce mo-ment, aucun travail n’a ete declenche, les threads de calcul et de recuperation desinformations sont en attente. On peut maintenant ajouter le client (figure 8.2).

Etape 2 : Initialisation du client Le client recupere autant d’annonces dedisponibilite qu’il en a besoin, en cas de manque, il se contentera de ce qu’il a etpartitionnera le travail en consequence (figure 8.3).

Etape i : Annonces de presence : A chaque cycle, les travailleurs annoncentleur presence, il n’y a donc pas de problemes quant au travail a realiser. Le clientse charge tout simplement de verifier chacune des annonces (figure 8.4).

Cas de presence de panne : En cas de panne d’un travailleur, l’annoncecorrespondante va manquer sur le JavaSpace. Le client se rend alors compte de lapanne et va emettre une commande de reinitialisation aux travailleurs restants.Le client va attendre la reinitialisation du travailleur pour se relancer lui-meme(l’ordre des operations est note par les etiquettes comportant un numero)(figures8.5 et 8.6).

A ce moment, le systeme se relance de facon normale sauf que les groupes deplanetes fournies seront les plus recentes connues, nous ne perdons pas les calculsprecedents.


Fig. 8.2 – Gestion des pannes, initialisation des travailleurs

Fig. 8.3 – Gestion des pannes, initialisation du client


Fig. 8.4 – Gestion des pannes, annonces de presence

Fig. 8.5 – Gestion des pannes, absence d’une annonce 1


Fig. 8.6 – Gestion des pannes, absence d’une annonce 2


8.2.5 Performances obtenues

Nous avons refait un bench complet de cette version de l’algorithme et il estapparu qu’il n’y a aucune difference notable de performance avec la version sansgestion des pannes.

Lorsqu’une panne est declenchee, le client renvoie le temps de gestion de lapanne apres detection, on remarque qu’elle fluctue autour de 2 secondes.

Le temps total de gestion de pannes se chiffre alors de 4.5 secondes a 8.5secondes.

Les premiers tests ont engendre quelques problemes, il apparaissait que pourun nombre de planetes consequent, de fausses pannes etaient declenchees. Nousen avons alors deduit que les threads de gestion des pannes ne devaient pasrespecter leur periode respective. Ce probleme a pu etre gere par la mise enplace de priorites. Voici celles que nous avons choisies :

Client– DeposeurRecolteur, priorite = 1– GestionnairePannes, priorite = 10

Travailleur– Calculateur, priorite = 1– Recolteur, priorite = 2– Annonceur, priorite = 10

Les priorites absolues ont ete donnees aux threads de gestion des pannes,en effet, comme le respect du timing est prioritaire ici et sachant qu’ils sont ensommeil une grande partie du temps de calcul cette decision n’influe pas sur lesperformances du systeme.Cote travailleur, une priorite a ete accordee au Recolteur sur le Calculateur carce dernier a besoin d’avoir les informations necessaires a chaque fin de boucle.Si l’acces a l’information ne se fait qu’a la fin de chaque boucle de calcul deN/P interactions il n’y a en effet plus de recouvrement d’informations car leCalculateur se mettra alors en attente.

Chapitre 9

Conclusion

Ce projet nous a permis d’explorer la technologie JavaSpace appliquee a uncluster de 32 Pc’s. Grace a notre probleme support exigeant en calculs et encommunications, nous avons mis en evidence les caracteristiques suivantes deJavaSpace :

– Cette technologie permet une programmation parallele relativement simple.En effet, les primitives de gestion de l’espace sont faciles d’utilisation.

– Une gestion efficace des pannes des postes de calcul est faisable avec desperformances tout a fait acceptables : une panne engendre une perte deseulement quelques secondes dans le temps total d’execution.

– De meme que l’on peut gerer les pannes de postes de calcul, on peutegalement prendre en compte l’arrivee de nouveaux Pc’s en cours de calcul

– L’effort de mettre en place un recouvrement calculs/communications n’estpas vain : on atteint un gain en performance tres interessant : en moyenne25 % pour 29 processeurs.

– Pour notre probleme, le systeme passe assez bien a l’echelle : on atteintune efficacite de 76% pour 25 processeurs.

Cependant, des questions restent en suspens. En effet, il faudrait etudier unegestion des pannes generalisee (c’est a dire que l’on envisage egalement les pannesdes services ou du client) ; il pourrait etre egalement interessant de paralleliserla version optimisee de l’algorithme sequentiel. Enfin, une derniere notion esta noter : le systeme passe bien a l’echelle pour notre probleme en particulier,mais il faudrait etudier le cas d’autres types de problemes : produit de matrices,relaxation de Jacobi, ...

Annexe A

Automatisation des connexions

Pour lancer un calcul parallele, il faut lancer les differents services JavaSpaceainsi que les PCs sur lesquels se feront les calculs. Cela devient vite fastidieux,car a chaque fois que l’on se connecte sur un PC, il y a une authentification.Nous avons fait en sorte qu’il n’y ait plus aucune authentification. Nous avons enpremier lieu essaye de faire en sorte que le password ne soit plus demande pourobtenir une connexion directe.

Par exemple, pour se connecter a l’ordinateur sh16, on tape la ligne de com-mande suivante :

ssh sh16

Ensuite nous est demande le login et le mot de passe.

Ainsi, les communications et les echanges se font par ssh (Secure Shell) : c’estun protocole qui permet a des utilisateurs d’acceder a des machines distantesgrace a des communications chiffrees (appelee Tunnel).Deux methodes d’authentification sont possibles :

– la methode la plus connue est le traditionnel mot de passe. Le client envoieun nom d’utilisateur et un mot de passe au serveur au travers de la com-munication securise et le serveur verifie si l’utilisateur concerne a acces ala machine et si le mot de passe fourni est valide (c’est cette methode quenous voulons eviter)

– une methode moins connue mais plus souple est l’utilisation de cles pu-bliques. Si l’authentification par cle est choisie par le client, le serveur vacreer un challenge et donner un acces au client si ce dernier parvient adechiffrer le challenge avec sa cle privee

C’est cette derniere methode que nous avons mis en place.

Ssh s’appuie sur des algorithmes a paire de clefs, ce qui signifie que l’ondispose d’une clef publique, disponible pour tout un chacun et une clef privee dont

52 Automatisation des connexions

on garde jalousement l’entree. Ce systeme va nous permettre de nous identifieraupres des hotes que nous desirons contacter. Il nous faut au prealable creer letrousseau.Pour cela, on utilise la ligne de commande suivante :

ssh-keygen -t rsa

On a ainsi cree une paire de clefs basee sur l’algorithme d’encryptage rsa.

Pour etre reconnu d’un hote, il suffit de copier la clef publique dans le fichierauthorized keys du repertoire .ssh. sur l’hote. Maintenant, lorsque l’on entre laligne de commande :

ssh sh16

la connexion se fait automatiquement, sans authentification !Une fois cela acquis, pour automatiser la mise en place des services JavaSpace etdes stations de calcul, il suffit d’ecrire un script shell. Nous donnons ci-apres parexemple le script qui permet de lancer les services JavaSpace :

53

1 # Lancement des services

2

3 # Serveur

4 ssh sh09 - f /usr/java/jdk1 .5.0 _06/bin/java -jar

/usr/java/Jini2_ 1/lib/tools.jar -port 8085 -

dir /usr/java/Jini2_1/lib -dl

5 sleep 3s

6 # Rmid

7 ssh sh09 - f /usr/java/jdk1 .5.0 _06/bin/rmid -J-

Djava.security.policy =/tmp/Projet_Boutet_Rahba/

Config/jsk -all.policy

8 echo rmid lance

9 sleep 3s

10

11 # Reggie

12 ssh sh10 - f /usr/java/jdk1 .5.0 _06/bin/java -jar -


Config/jsk -all.policy /usr/java/Jini2\_ 1/lib/

start.jar /tmp/Projet_Boutet_Rahba/Config/start -

reggie

13 sleep 1s

14

15 # Outrigger

16 ssh sh10 - f /usr/java/jdk1 .5.0 _06/bin/java -jar -


Config/jsk -all.policy /usr/java/Jini2_1/lib/

start.jar /tmp/Projet_Boutet_Rahba/Config/start -

outrigger

17 sleep 3s

Bibliographie

[1] W. Keith Edwards. Core Jini. Prentice Hall, 2000.

[2] Virginie Galtier. Notice JavaSpace sur le Cluster. Supelec, 2006.

[3] James Gosling, Ken Arnold, and David Holmes. The Java Programming Lan-guage. Addison-Wesley Professional, 2000.

[4] Kathy Sierra and Bert Bates. Java Tete la premiere. O’Reilly, 2004.

[5] Stephane Vialle. Cours de parallelisme et Grid, Option IIC. Supelec, 2006.

Rapport de projet de fin d’étude Etude de la … · Rapport de projet de fin d’étude ......

Documents

Transcript of Rapport de projet de fin d’étude Etude de la … · Rapport de projet de fin d’étude ......