Principe de fonctionnement

Notre solution est contituée de deux principaux composants :

Le premier composant est FAIL (pour FAult Injection Language) qui est un

lan-gage qui permet de décrire facilement des scénarios de fautes (voir chapitre

précédent). Le langage FAIL est un langage abstrait de haut niveau permettant

de dénir des scénarios de fautes grâce à des machines à états qui modélisent les

occurences de fautes. Il décrit également l'association entre ces machines à états et

un ordinateur (ou un groupe d'ordinateur) du réseau.

Le second composant est FCI (pour FAIL Cluster Implementation) qui est une

plat-forme distribuée d'injection de fautes congurée à partir d'un scénario de fautes

décrit dans le langage FAIL.

Ces deux composants sont développés dans le cadre du projet GriD eXplorer qui a

pour but l'émulation de réseaux à grande échelle sur des clusters ou des grilles plus petites.

Décomposition de la plate-forme FCI. La plate-forme FCI (voir gure 5.1) est

décomposée de la manière suivante :

Le compilateur de FCI : Le scénario écrit en FAIL doit être enregistré dans un

chier portant l'extention . Il doit alors être précompilé par le compilateur de

FCI qui génère alors du code C++ ainsi que des chiers de conguration par défaut.

Un chier .cpp et un chier .h sont générés pour chaque automate déni

dans le scénario. Ces chiers contiennent la dénition d'une classe correspondant à

chaque automate. Un chier .cpp et un chier .h sont générés pour chaque

déclaration de machine et de groupe. Ces chiers contiennent la dénition d'une

classe correspondant à l'injecteur de fautes.

La bibliothèque de FCI : Toutes les classes générées lors de la compilation du

scé-nario de fautes dérivent de classes principales contenues dans la bibliothèque FAILD.

Cette bibliothèque contient également les classes modules qui sont des outils

four-nissant chacune des fonctions du langage FAIL.

Les chiers générés et la bibliothèque FAILD sont alors copiés sur les diérentes

machines du réseau suivant les chiers de conguration dénis par l'utilisateur et ensuite

compilés localement pour générer un programme exécutable faild (le code source

des chiers générés par le compilateur et de la bibliothèque FCI est compilé sur chaque

machine pour permettre le support des clusters hétérogènes). C'est l'exécution de ce

programme sur chacune des machines qui créera les démons FCI.

Les démons FCI. Quand l'expérience débute, l'application distribuée testée est

exé-cutée à travers les démons FCI installés sur tous les ordinateurs pour leur permettre de

l'instrumenter et de la contrôler suivant le scénario de fautes déni. Le démon FCI associé

à un ordinateur particulier consiste en :

1. une machine à états implantant le scénario de fautes,

2. un module pour communiquer avec les autres démons (i.e. pour injecter des fautes

basées sur l'état global du système),

3. un module pour gérer le temps (i.e. pour permettre l'injection de fautes à un instant

donné),

4. un module pour l'instrumentation de l'application testée (en contrôlant un débogueur),

5. et un module pour gérer les événements (pour déclencher les fautes).

L'utilisation d'un débogueur. FCI est un injecteur de fautes de type

Debugger-based car l'injection de fautes et l'instrumentation de l'application testée sont faites

grâce à l'utilisation d'un débogueur logiciel. Ceci permet de ne pas avoir à modier

le code source de l'application testée tout en ayant la possibilité d'injecter des fautes

arbitraires (modication du program counter ou des variables locales pour simuler une

attaque de type buer overow , etc). Comme le débogueur parallèle Mantis [54], FCI

communique avec le débogueur à travers des tubes unix. Mais contrairement à Mantis,

les communications avec le débogueur doivent être minimisées pour permettre un faible

surcoût de la plate-forme d'injection de fautes (dans notre approche, le débogueur est

utilisé uniquement pour déclencher et injecter les fautes). L'application testée peut ainsi

être interrompue quand elle appelle une fonction particulière ou avant d'exécuter une

ligne particulière de son code source. Son exécution peut être reprise suivant le scénario

de fautes considéré. L'implantation actuelle de FCI intègre le support de deux débogueurs

diérents : gdb, l'environment de debogage séquenciel de la fondation Free Software pour

la prise en charge de programmes natifs et jdb, le débogueur Java pour la prise en charge

de programmes Java.

Comparatif avec les autres approches. Du point de vue de l'utilisateur, il est

su-isant d'écrire un scénario de fautes FAIL pour dénir une expérience. Le code source des

démons d'injection de fautes est automatiquement généré. Ces démons communiquent

entre eux explicitement suivant le scénario de fautes déni par l'utilisateur. Ceci permet

l'injection de fautes basée sur l'état global du système ou sur un mécanisme plus complexe

impliquant plusieurs machines (i.e. une injection de fautes en cascade).

De plus, l'architecture complètement distribuée des démons FCI facilite le passage

à l'échelle de l'outil, ce qui est nécessaire dans le contexte de l'émulation de systèmes

distribués à grande échelle.

L'utilisation d'un débogueur pour le déclenchement des fautes permet également de

limiter l'intrusion de l'injecteur de fautes pendant l'expérience. En eet, le débogueur

place des points d'arrêt correspondant au scénario de fautes déni par l'utilisateur et

exécute alors l'application testée. Tant qu'aucun point d'arrêt n'est atteint, l'application

s'exécute normalement et le débogueur reste inactif.

Grande expressivité non oui non oui

Langage de haut niveau non non oui oui

Pas de modication du code source oui non non oui

Passage à l'échelle oui non oui oui

Scénario probabiliste oui oui non oui

Injection selon un état global non oui oui oui

Fig. 5.2 Comparatif des systèmes d'injection de fautes

Les diérences essentielles entre notre approche et les travaux précédents sont

ré-sumées dans la gure 5.2.