Le scénario FAIL

Un scénario possible correspondant, utilisant le language FAIL, est décrit dans la

gure 8.15 (avec x= 1 et y= 10%) :

Nous avons exécuté ces tests en faisant varier x de 1 à 9 secondes (avec une

incré-mentation de 2 secondes), et en faisant varier y de 10% à 100% dans la conguaration

Cluster, en faisant varier x de1 à 2 secondes (avec une incrémentation de 2 secondes),

et en faisant varier y de10% à 100% dans la conguration GrideXplorer.

8.3.2 Résultats obtenus

Les résultats obtenus concernant le temps d'exécution global sont résumés dans la

gure 8.16 et la gure 8.17. Nous n'avons pas collecté d'informations sur les défaillances

du dispatcher, car nous n'en avons observé aucune.

Fig. 8.14 Latence avec OGSA-DAI(service Web étendu à la session)

On s'attendait à ce que la courbe ait la forme d'un U au moins pour le test avec

x = 1 (avec l'ajout d'un worker toutes les secondes) : si quelques workers arrivent au

même moment, les performances sont mauvaises ; si plusieurs workers arrivent au même

instant, le dispatcher peut les gérer et les performances sont meilleures ; si trop de

work-ers arrivent au même instant, le dispatcher pourrait être surchargé et les performances

globales pourraient être plus mauvaises qu'avec moins de workers. Dans la conguration

Cluster, toutes les courbes sont décroissantes, ce qui signie que plus il y a de workers

disponibles, plus la complétion du calcul est rapide. Cela signie aussi que la version C++

de XtremWeb peut gérer ecacement l'arrivée simultanée de 30 nouveaux workers (ce

qui est le cas quandy = 100%). Au contraire, la conguration GrideXplorer montre que

plus il y a de workers arrivant simultanément dans le système, plus le temps nécessaire

pour compléter le calcul est long. Ainsi, avec 160 workers, dont la majorité arrive

simul-tanément, le dispatcher XtremWeb est clairement stressé mais la dégradation observée

évolue faiblement.

spyfunc main ;

Daemon ADV1 {

node 1 : before(main) -> continue, !go(G1), goto 2 ;

node 2 : }

Daemon ADV2 {

node 1 : before(main) -> stop, goto 2 ;

node 2 : ?go -> stop, goto 3 ;

node 3 : always int x = FAIL_RANDOM(1,100) ;

always time_g timer = 1 ;

timer && x <= 10 -> continue, goto 4 ;

timer && x > 10 -> stop, goto 3 ;

node 4 : }

Fig. 8.15 Scénario de fautes pour le stress d'application.

8.4 Conclusion du chapitre

Dans ce chapitre, nous avons présenté les résultats que nous avons obtenus sur le

stress de OGSA-DAI en utilisant l'outil de test pour les services de grilles QUAKE et les

résultats de stress de XtremWeb en utilisant FAIL-FCI comme outil de stress.

Les résultats obtenus sur OGSA-DAI montrent que celui-ci est très stable grâce à sa

conguration par défaut qui dénit une étendue du service Web à l'application. Dans

ce cas, OGSA-DAI ne déclenche pas les fuites de mémoire de Axis1.2.1. Si l'étendue est

congurée à la session, OGSA-DAI déclenchera les sévères fuites de mémoire de Axis1.2.1

et la abilité résultante sera a prendre largement en considération.

Ainsi, nous avons prouvé qu'avoir un outil de test pour les services Web et les

appli-cation pour le grilles est crucial pour la communauté. En utilisant l'outil QUAKE nous

avons été capable de détecter et de comprendre les raisons de la stabilité de OGSA-DAI

mais aussi des potentielles fuites de mémoire de Axis qui pourraient le faire passer pour un

intergiciel très instable si elles sont déclenchées. Une bonne nouvelle pour la communauté

est le fait que Axis 2 a déjà été implanté et cette nouvelle version corrige la plupart des

problèmes des versions précédentes. Cependant, il y a encore de nombreuses applications

(comme OGSA-DAI) qui utilisent les version 1.2 ou 1.3 de Axis et qui pourraient alors

Fig. 8.16 Test de stress : cluster avec 30 workers

potentiellement sourir de sérieuses fuites mémoires si elles utilisent des services Web

étendus aux sessions.

Or, puisque les mécanismes mis en ÷uvre pour les tests eectués sur OGSA-DAI

semblent être pilotables par FAIL-FCI pour les application distribuées en générale, Il

s'avère donc intéressant d'utiliser FAIL-FCI pour le stress d'applications distribuées et de

disposer ainsi d'un unique outil permettant l'injection de fautes et le stress d'applications

distribuées. Nous avons donc eectué des tests de stress de XtremWeb en utilisant

FAIL-FCI.

Ce que l'on entend par expérience de stress dans le cas de XtremWeb, 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 worker disponible

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.

Fig. 8.17 Test de stress : GriDeXplorer avec 160 workers

simultanée de 30 nouveaux workers. Au contraire, avec 160 workers, dont la majorité

arrive simultanément, le dispatcher XtremWeb est clairement stressé, i.e. plus il y a de

workers arrivant simultanément dans le système et plus le temps nécessaire pour compléter

le calcul est long, mais la dégradation observée évolue faiblement.

Simulation d'Utilisateurs dans un

Réseau

9.1 Introduction

De nos jours, les systèmes distribués à grande échelle sont de plus en plus utilisés

en raison de leur ecacité. Les Desktop grids, introduits précédemment, utilisent les

cycles oisifs des ordinateurs de bureau pour eectuer du calcul à grande échelle et du

stockage de données pour un coût relativement faible. Mais à cause de l'échelle de ce

type de systèmes et de la nature des n÷uds participants, les diérents hôtes sont très

volatiles [61]. Et même si ces types de systèmes sont très utilisés, la volatilité des hôtes

dans les grilles d'ordinateurs de bureau commence juste à être conprise [51].

La caractérisation de la volatilité des n÷uds est essentielle pour créer des modèles et

des simulations précis de ces plates-formes. Quelques travaux ont été faits en rassemblant

des traces de disponibilité à partir de grilles d'ordinateurs de bureau réels et en les

utilisant pour caractériser la volatilité de chaque système [50]. Ces traces sont utiles pour

la simulation guidée par traces et la construction de modèles prédicatifs, génératifs ou

explicatifs. Ils ont également permis d'obtenir des statistiques sur les hôtes qui reètent

leur volatilité.

Ensuite arrive le problème de l'extraction d'un modèle à partir de ces traces. Plus

récemment, les systèmes pair à pair ont utilisé des distributions statistiques comme

fonde-ment de leurs hypothèses sur la disponibilité des n÷uds et quelques études sur

l'adéqua-tion de plusieurs distribul'adéqua-tions statistiques potentielles ont été faites [58, 82, 83]. Elles ont

permis le développement d'une méthode automatique pour la modélisation de la

disponi-bilité de ressources distribuées au sein d'une entreprise et dans le monde. Les modèles de

disponibilité des machines sont basés sur la correspondance d'une distribution statistique

aux données observées. Ceci est fait automatiquement par l'estimation des paramètres

nécessaires à une distribution à partir d'un ensemble de mesures de disponibilité donné.

Nos travaux dans le domaine contribuent à aller un pas plus loin en donnant la

pos-sibilité d'émuler un environnement volatil proche de la réalité à partir d'une distribution

statistique. Nous montrons ainsi comment utiliser notre injecteur de fautes pour

exé-cuter une application distribuée dans un cluster ou une grille où le comportement des

diérents n÷uds (i.e la volatilité) suit une distribution prédénie. Cette procédure est

automatique, reproductible et permet de voir le comportement d'une application dans un

environnement plus proche de la réalité.

Combiné aux travaux précédemment cités, cela permet d'avoir un outil complètement

automatique qui extrait la disponibilité à partir de traces réelles, génère la distribution

statistique correspondante et la reproduit sur un système. Ainsi, le comportement de

l'application réelle peut être testé avant l'étape de production. Cela permet également de

vérier l'ecacité d'une application et de la congurer de manière optimale selon le type

de système visé.

Dans la section 9.2, nous introduisons les travaux précédents qui ont été faits sur

l'extraction d'une distribution à partir des traces et nous expliquons le choix de la

distri-bution de Weibull. Dans la section 9.3, nous présentons la distridistri-bution choisie. Dans la

section 9.4, nous expliquons l'incorporation de cette distribution dans notre outil

FAIL-FCI. Finalement, dans la section 9.5, nous présentons les expérimentations que nous avons

faites sur XtremWeb, l'intégration dans FCI du mécanisme d'émulation de prise en main

de la machine par un utilisateur lambda et les résultats obtenus en utilisant cette

distri-bution sur diérentes congurations pour analyser l'exactitude du comportement induit

des n÷uds comparé à la distribution utilisée ainsi que l'ecacité de XtremWeb dans ces

diérentes congurations.

Dans le document INJECTION DE FAUTES DANS LES SYSTEMES DISTRIBUES (Page 172-179)