De la classification au modèle

Figure 7 - Principe de création du modèle

Il faut donc partir d’un ensemble de type de fautes afin de pouvoir choisir les mécanismes que nous souhaitons mettre en place. De ces mécanismes on déduit un ensemble de paramètres applicatifs essentiels au fonctionnement des mécanismes. Le modèle est quant à lui battit à partir du modèle de fautes et des paramètres applicatifs.

2.3.1- Le modèle de fautes

L’approche vue précédemment permet de mieux comprendre les choix de modélisation qui ont été fait dans ce travail. Les deux types de paramètres du modèle ayant été identifiés il faut à présent bâtir concrètement un modèle avec lequel nous pourrons représenter les applications et les mécanismes de tolérance aux fautes.

Pour cette étude nous nous concentrerons sur trois types de faute : -les fautes par crash.

-les fautes en valeurs. -les fautes par omission.

Partons d’un ensemble de trois mécanismes de tolérance aux fautes. Ces mécanismes sont génériques mais représentatifs des principales techniques de tolérance aux fautes. Les deux premiers ont déjà été abordés précédemment, il s’agit des mécanismes implémentant

31 les stratégies de redondance chaude et froide, respectivement LFR et PBR. Le troisième mécanisme est appelé mécanisme de redondance temporelle ou TR pour Time Redundancy. TR permet de tolérer les fautes en valeurs (appelées également fautes transitoires) en exécutant deux fois la même application puis en comparant les résultats. En cas d’égalité la réponse est validée, en cas de désaccord plusieurs stratégies sont possibles (une troisième itération, un reset de l’application, un abandon de la requête,…).

On considère donc que ce mécanisme permet de tolérer les fautes en valeurs. De plus, puisqu’il nécessite d’exécuter deux fois une requête on considère qu’il est capable de tolérer les fautes par omission. En effet, si un des deux résultats est omis alors le mécanisme détecte qu’aucune comparaison ne peut être effectuée et qu’il y pas par conséquent une faute.

Nous limiterons notre étude à ces trois types de fautes. Cependant, lors d’une application sur cas d’étude il faudra extraire d’une analyse de sûreté de fonctionnement l’ensemble de toutes les fautes que peut subir une application. Une fois ceci fait nous pouvons passer à la recherche des caractéristiques applicatives qui seront pertinentes pour notre modèle à partir des mécanismes de tolérance aux fautes disponibles.

2.3.2 Les caractéristiques applicatives

Il nous faut à présent extraire de l’ensemble des FTMs toutes les caractéristiques applicatives qui sont nécessaires dans la formulation des hypothèses relatives à la mise en place de ces FTMs.

Commençons par l’étude du mécanisme LFR. L’analyse que nous avons conduite dans la section précédente nous a permis de déterminer que si l’on veut protéger une application avec ce mécanisme il faut à minima que l’application soit déterministe. On note également que pour détecter le crash d’une application il faut que celle-ci soit silencieuse sur défaillance. En effet, en cas de crash, si l’application continue de fournir des preuves de vie rien ne permet de vérifier qu’elle a crashé.

En toute rigueur tout mécanisme qui ne considère que le crash dans son modèle de fautes impose l’hypothèse d’une auto testabilité parfaite du composant applicatif, c’est-à-dire une couverture de 100% des mécanismes de détection internes à ce composant. On peut représenter le mécanisme LFR de la manière suivante :

32

Figure 8 - Modèle de redondance semi-active (Leader Follower Replication)

La copie Leader reçoit l’entrée et la transmet au Follower. Les deux envoient ensuite cette requête aux composants applicatifs qui se chargent de l’exécution (ici en parallèle) avant de retourner une valeur de sortie. Seule la copie leader transmet une réponse au client tant qu’il fonctionne. En cas de défaillance c’est au follower de s’en charger.

Concernant le mécanisme PBR, il nécessite l’accès à l’état de l’application afin de pouvoir capturer des états de reprise du composant (notion de checkpoint). Bien entendu, comme pour LFR, l’application associée à ce mécanisme doit être silencieuse sur défaillance pour les même raisons que celles évoquées précédemment pour tout mécanisme duplex tolérant le crash. Le fonctionnement est similaire au mécanisme LFR si ce n’est que la copie dite secondaire se contente de sauvegarder les états de la copie primaire comme on peut le voir sur la figure suivante :

Figure 9 - Modèle de redondance passive (Primary Backup Replication)

Le mécanisme TR fonctionne par comparaison de résultats. Or, pour que les deux résultats successifs du traitement d’une même requête soient égaux l’application se doit d’être déterministe. De plus, lorsque l’application exécute une requête, le résultat peut dépendre de l’état de l’application. Dans ce cas, il nous faut être capable de réinitialiser l’état de l’application afin que les deux exécutions se déroulent dans le même contexte (même état, même entrée). Dans le cas de l’utilisation de TR, il n’y a qu’une seule copie qui effectue deux fois les requêtes d’entrée :

33

Figure 10 - Modèle de redondance temporelle (Time Redundancy)

Cette analyse permet de déterminer trois caractéristiques applicatives sur lesquelles reposent les hypothèses décrites précédemment pour l’ensemble des mécanismes considérés dans l’exemple :

-Le déterminisme. -L’accès à l’état.

-La capacité de l’application à demeurer silencieuse sur défaillance.

En conclusion nous avons extrait six paramètres pour établir le modèle : trois caractéristiques applicatives et trois types de fautes. La méthode vue dans cette partie permet donc d’énoncer un ensemble de paramètres à partir de l’ensemble des FTMs disponible. Le modèle obtenu dépend donc de l’ensemble des mécanismes de tolérance aux fautes disponibles. Une extension de cet ensemble peut conduire à l’énoncé de nouveaux paramètres

La partie suivante sera dédiée à la représentation de ces paramètres et à l’instanciation des composants fonctionnels dans le modèle ainsi qu’à la définition des propriétés qui caractérisent les interactions entre fonctionnel et non fonctionnel.