Vue d'ensemble

Finalement, il s'avère que FreePastry est généralement capable de gérer la défaillance

de processus participants en se restructurant pour que la table de hachage distribuée soit

toujours maintenue malgré la dynamicité induite. Cependant, avec notre conguration, il

semble y avoir un point de rupture où le nombre de processus défaillant possible est trop

grand pour que FreePastry puisse le gérer. Nous envisageons approfondir cette hypothèse

en utilisant un plus grand nombre de machines.

7.4.7 Conclusion

Nous avons étendu la platforme FAIL-FCI pour permettre le support d'applications

distribuées Java de la même façon que les applications natives l'étaient. Ainsi, notre nouvel

outil permet d'injecter des fautes dans les applications eectives, suivant les scénarios,

sans avoir à modier le code source du programme Java ou de la machine virtuelle Java.

En tant que preuve de faisabilité, nous avons utilisé une application distribuée Java

disponible (FreePastry) et utilisé FAIL pour spécier un scénario de fautes générique

qui était alors automatiquement géré par l'infrastructure FAIL-FCI. Les résultats que

nous avons obtenus montrent que la périodicité et la probabilité des fautes sont peu

importantes, i.e. le réseau FreePastry est capable de se reconstruire dans tous les cas,

mais que leur nombre compte (quand le nombre de n÷uds potenciellement défaillant

augmente, le réseau peut être partitionné en plusieurs réseaux). D'autres études sont

nécessaires, utilisant des scénarios de fautes plus complexes et d'autre types d'applications

distribuées Java.

7.5 Conclusion du chapitre

Les tests d'injection de fautes dans XtremWeb, MPICH-V et FreePastry ont été

présentés dans ce chapitre.

Pour XtremWeb, les tests d'injection de fautes quantitatives et qualitatives qui ont

été réalisés montre que sa version C++ soure d'un problème de gestion de ressources,

au niveau du dispatcher quand des workers sont victimes de défaillances, entraînant sa

propre défaillance. On peut aussi déduire de l'expérimentation que XtremWeb devrait

implémenter un mécanisme pour faire attention aux défaillances des workers quand une

tâche est soumise car lorsque des fautes apparaissent juste après la réception d'une tâche,

les performances sont plus mauvaises que lorsqu'elles apparaissent juste après la n d'un

calcul (même si dans ce cas le worker a perdu du temps à exécuter du calcul inutilement).

Pour MPICH-V, des tests d'injection de fautes ont été eectués an de déterminer

l'impact de la fréquence des fautes, de l'echelle et de l'injection de fautes simultanées sur

les performances de celui-ci. On a pu ainsi constater une grande variance dépendante du

moment de l'injection de fautes comparé à la dernière vague de checkpoint. Nous avons

pu également découvrir un bogue. Grâce à la puissance d'expressivité de FAIL et à une

série de tests visant à découvrir la conguration du système qui menait à l'apparition

de ce bogue, nous avons pu le localiser précisément, ce qui a permis la correction de ce

bogue dans une nouvelle version de MPICH-Vcl.

parition de fautes sont peu importantes par rapport à la maintenance du réseau logique,

i.e. le réseau FreePastry est capable de se reconstruire dans tous les cas, mais que l'échelle

compte. En eet, quand le nombre de n÷uds potentiellement défaillants augmente, le

réseau peut être partitionné en plusieurs réseaux.

Ces tests nous montre que FAIL-FCI est adapté à l'étude d'applications distribuées

et qu'il comble les nombreux inconvénients des autres approches présentées dans le

chapitre 2. En eet, dans les tests eectués sur MPICH-V, des scénarios de fautes

com-plexes ont pu être spéciés an d'exhiber la conguration du système qui menait à

l'ap-parition du bogue qui a été découvert et dans tous les tests, l'aspect aléatoire de l'injection

des fautes a été utilisé. De plus, du fait de la faible intrusion de l'injecteur de fautes, des

résultats relativement précis sur les performances de ces applications ont pu être obtenus.

Ensuite, grâce à son principe de fonctionnement, ces tests ont pu être réalisés sans

mod-ier le code source de ces trois applications. Et enn, l'intégration de ces applications a

été faite, malgrés leur architectures très diérentes, grâce au fonctionnement générique

de notre injecteur de fautes.

Stress d'Applications

8.1 Introduction

Les sections 7.2.4 et 7.2.5 ont montré comment utiliser FAIL-FCI pour obtenir une vue

de la résistance aux fautes de XtremWeb en utilisant une approche uniée pour l'analyse

quantitative et qualitative. Nous allons maintenant montrer que le même outil peut être

conguré pour gérer également des expériences de stress d'une application.

En fait, nous avons vu, lors d'une collaboration avec les chercheurs de l'Université

de Coimbra (Portugal), que pour stresser une application on utilise un programme dédié

et spécique. En eet, dans [43] nous avons utilisé l'outil de test pour les services de

grilles QUAKE pour stresser l'intergiciel OGSA-DAI. Ces tests sont présentés dans la

section 8.2. Tout d'abord nous présentons OGSA-DAI, puis l'outil QUAKE et enn nous

présentons les résultats que nous avons obtenus.

Or, les mécanismes mis en ÷uvre pour ces tests semblaient être pilotables par

FAIL-FCI. Nous avons donc eectué des tests de stress de XtremWeb en utilisant FAIL-FAIL-FCI.

Ces tests sont présentés dans la section 8.3. Ce que l'on entend par expérience de

stress dans ce cas, c'est tester les performances quand le dispatcher doit gérer un

nombre croissant de connexions de workers. En eet, cela permet de mesurer le surcoût

de la gestion des workers par le dispatcher pour diérents taux de connexions. Quand

le nombre de workers disponibles augmente, la puissance de calcul augmente également,

mais le dispatcher doit gérer plus de connexions et les performances globales ne sont pas

nécessairement meilleures.

8.2 Utilisation d'une application dédiée