Analyse

La plate-forme logicielle JUXMEM est un prototype de recherche en cours de mise en œuvre, une thèse étant en cours sur l’évolution de J^UXM^EM. Grâce à notre architecture logi-cielle, cette plate-forme permet la mise en place aisée de nouveaux protocoles de cohérence et de nouveaux mécanismes de tolérance aux fautes. Elle peut donc être utilisée comme une plate-forme expérimentale pour tester de nouveaux mécanismes et les comparer entre eux.

Dans ce chapitre nous avons donné un aperçu de la mise en œuvre de l’architecture en couches et de la manière dont il est possible de mettre en œuvre de nouveaux protocoles de cohérence et de nouveaux mécanismes de tolérance aux fautes. En utilisant l’implémentation actuelle, il est possible pour une application de choisir différents protocoles de cohérences pour des données différentes, la cohérence à l’entrée ou la cohérence à l’entrée étendue par exemple. Dans le chapitre suivant, nous montrons une évaluation comparative de ces deux protocoles dans le cas particulier de la visualisation d’une donnée partagée.

La description des mécanismes de diffusion utilisés pour la réplication des copies de ré-férence met en évidence le coût, en terme de latence, que peuvent avoir de tels mécanismes.

Les mécanismes de tolérance aux fautes risquent donc de ralentir l’application. Cependant, en présence de fautes, ces mécanismes lui permettent de continuer son exécution. Il semble important de trouver le bon compromis entre le coût des mécanismes utilisés et le risque d’apparition de fautes durant l’exécution de l’application. C’est pourquoi notre prototype permet de choisir les mécanismes utilisés ainsi que le degré de réplication. Le chapitre sui-vant apporte un début de réponse à la recherche de ce compromis en donnant une évaluation du coût des mécanismes de tolérance aux fautes de la plate-forme J^UXM^EM.

119

Chapitre 9

Évaluation

Sommaire

9.1 Méthodologie d’expérimentation . . . 120 9.1.1 Expérimentations sur architectures réelles . . . 120 9.1.2 Injection de fautes de type panne franche . . . 121 9.2 Expérimentations avec JUXMEM . . . 121 9.2.1 Coût dû à la réplication . . . 122 9.2.2 Bénéfice de l’approche hiérarchique . . . 126 9.2.3 Évaluations multi-protocole . . . 129 9.2.4 Impact des fautes sur les performances . . . 130 9.3 Discussion . . . 132

Nos approches pour la gestion conjointe de la tolérance aux fautes et de la cohérence des données au sein des grilles de calcul présentées dans ce manuscrit ont fait l’objet d’une mise en œuvre dont un aperçu est donné au chapitre 8.

Dans ce chapitre, nous donnons une évaluation de cette mise en œuvre. Dans un premier temps nous discutons de notre méthodologie d’expérimentation. En effet, l’évaluation de systèmes tolérants aux fautes pose certains problèmes, comme la difficulté d’effectuer des mesures reproductibles en présence de fautes.

Nous présentons dans la section 9.2 une évaluation de notre contribution au sein de la plate-forme J^UXM^EM. Nous mesurons notamment le coût engendré par les mécanismes de tolérance aux fautes en absence de fautes, mais aussi le gain réalisé grâce à notre approche hiérarchique pour la mise en place de protocoles de cohérence tolérants aux fautes. Une évaluation comparative de deux protocoles de cohérence illustre l’intérêt d’une plate-forme multi-protocole. Enfin, nous mesurons le surcoût engendré en cas d’occurrences de fautes.

9.1 Méthodologie d’expérimentation

Il existe de multiples méthodes permettant d’évaluer des systèmes : les preuves for-melles, les simulations et enfin les expérimentations. Ces méthodes ne présentent pas toutes les mêmes avantages et inconvénients.

Preuves formelles et simulations. Ces deux méthodes présentent l’inconvénient d’évaluer unmodèledu système etnon le système lui-même¹. Les modèles de systèmes sont une simpli-fication des systèmes réels et leur évaluation ne donne qu’une idée du comportement du système réel. En revanche, les preuves formelles permettent souvent de prendre en compte tous les cas, ce qui est rarement le cas pour les simulations ou les expérimentations sur les systèmes réels. Les simulations quant à elles présentent l’avantage non négligeable de pou-voir être réalisées assez rapidement.

9.1.1 Expérimentations sur architectures réelles

Les expérimentations de systèmes sur des architectures réelles permettent d’évaluer le comportement du système dans des conditions réelles. De plus, elles permettent aux dé-veloppeurs de mettre au point les systèmes et de les optimiser. Ce type d’évaluation est néanmoins plus difficile et plus long à mettre en œuvre. Dans le cas des expérimentations sur des plates-formes distribuées telles que les grilles de calcul, il est généralement néces-saire d’utiliser des outils de réservation de ressources (nœuds), de déployer le système sur les nœuds obtenus, de lancer le système et enfin de récupérer les résultats répartissur l’en-semble des nœuds utilisés. Dans ce contexte, expérimenter des mécanismes de tolérance aux fautes ajoute à la difficulté : il devient alors nécessaire de pouvoir contrôler les fautes afin d’évaluer les mécanismes mis en place pour y faire face. Nous avons expérimenté notre ser-vice de partage de données pour la grille J^UXM^EM sur la plate-forme Grid’5000 [113, 26].

Pour ce faire, nous avons utilisé des prototypes de recherche pour les réservations de nœuds (OAR [121] et OARGRID [122]) ainsi que pour le déploiement (ADAGE [74]).

OAR et OARGRID. OAR est un outil de gestion de ressources fondé sur MySQL [120]. Il permet de réserver des nœuds et de lancer des exécutions au sein d’une grappe. Cet outil est présent sur chacune des grappes de Grid’5000. OARGRID utilise OAR sur plusieurs grappes afin d’offrir une gestion de ressources au niveau de la grille.

ADAGE est un outil de déploiement générique d’applications distribuées et/ou parallèles s’exécutant sur les grilles de calcul. ADAGE dispose d’un greffon (en anglaisplugin) pour le déploiement d’applications basées sur JXTA [64].

Nous avons mis en œuvre un outil d’injection de fautes permettant d’évaluer la réaction aux fautes de notre mise en œuvre. Cet outil est présenté à la section suivante.

1Même si certains simulateurs permettent d’exécuter le code du système à expérimenter, l’architecture maté-rielle utilisée est modélisée et simulée.