Un modèle de fautes pour les systèmes CORBA

Un modèle de fautes est une abstraction des différentes classes de fautes qui peuvent affecter un système. Dans le cadre d’une expérience d’injection de fautes, il s’agit de modéliser les perturbations qu’on va introduire artificiellement dans le système. La représentativité des fautes simulées est une question importante lors de la définition d’une campagne d’injection de fautes. On cherche à injecter des fautes dont l’effet est similaire (au niveau des erreurs qui sont produites [Jarboui 2003]) à celui des fautes réelles, qui sont subies par les systèmes en phase opérationnelle. Un pré-requis à la comparaison des effets des fautes injectées et des fautes réelles est de disposer d’une base de fautes réelles, obtenue à partir de campagnes d’observation de systèmes déployés. Ce type d’étude fournit des statistiques sur les types de défaillances subies par une classe de système, ainsi que leur fréquence d’occurrence, et des hypothèses sur les fautes qui les ont provoquées.

Ce type d’analyse a été mené depuis de nombreuses années pour cer- taines classes de système, en particulier pour les mainframes (les « gros sys- tèmes ») [Sullivan & Chillarege 1991]. En revanche, nous ne connaissons aucune étude de ce type concernant les systèmes à base d’intergiciel. Ceci peut s’expliquer par le fait que – contrairement aux mainframes, qui sont déployés en industrie depuis plus de 30 ans – les systèmes basés sur un intergiciel de communication n’ont été déployés à grande échelle que récemment. En conséquence, nous ne pouvons déter- miner les classes de fautes qui affectent ces systèmes que par une analyse structurelle, en étudiant l’architecture d’un système type, en identifiant les points où les fautes peuvent survenir, et en étudiant les canaux potentiels de propagation d’erreur. Nous avons présenté notre analyse structurelle au §1.3.8.

Dans la suite, nous nous intéressons aux fautes qui affectent l’intergiciel même ou dont les effets peuvent être amplifiés par l’intergiciel ; nous ne cherchons pas à lis- ter de manière exhaustive toutes les fautes qui peuvent toucher un système distri- bué, et encore moins à étudier leur effet. Ces fautes peuvent être classifiées comme suit [Marsden et al. 2002a] :

• les fautes physiques, affectant des éléments matériels du système, tels que la mémoire, les registres du microprocesseur, le fonctionnement des unités d’entrées/sorties. Par exemple, un rayon cosmique peut provoquer l’inversion d’un ou de plusieurs bits en mémoire.

• les fautes de communication, comme la perte, la duplication, le ré- ordonnancement ou la corruption de messages. Cette classe de fautes est gé- néralement supposée ne pouvant pas affecter des intergiciels qui se basent sur un protocole de transport fiable (ce qui est le cas de IIOP dansCORBA). Toutefois, des recherches récentes, présentées au §2.2.5, indiquent que ces fautes méritent d’être étudiées.

• les fautes du logiciel (qu’elles soient de conception ou de programmation), au ni- veau de l’application, de l’intergiciel ou du système d’exploitation. Par exemple, une application peut transmettre une référence objet invalide à l’intergiciel en paramètre d’une opération, ou l’intergiciel peut emballer de manière incorrecte certains types de données vers le CDR, ou omettre de vérifier certains codes d’erreur renvoyés par le système d’exploitation.

• les fautes relatives à la gestion des ressources : l’effet de « vieillissement » du logiciel engendre des effets tels que des fuites de mémoire (ce qui est particuliè- rement fréquent dans les applicationsCORBA), des effets de fragmentation de la mémoire, de saturation du stockage local, de non-libération de ressources telles que des descripteurs de fichier.

Les fautes physiques et les fautes de communication sont généralement transitoires, et elles sont très rares ; ces fautes ne peuvent que difficilement être révélées par le test fonctionnel du système. Les fautes du logiciel, quant à elles, sont plus aptes à être détectées lors des phases de test (avant la mise en opération du système), mais certaines fautes sont très difficiles à révéler. En effet, le déclenchement de la faute peut

être dû à un événement qui a lieu très rarement, ou bien suite à un enchaînement non déterministe d’événements.

Pour chaque classe de fautes, nous décrivons au §2.2des techniques d’injection par logiciel qui permettent de simuler l’effet de ce type de fautes sur des systèmes à base d’intergiciel.

Les techniques d’injection de fautes par logiciel peuvent être classifiées selon l’étape où les fautes sont injectées :

• injection à la compilation : les instructions du logiciel sont modifiées avant l’exécution de l’image binaire. La faute est insérée dans le code source ou dans le code assembleur du programme. Cette méthode d’injection ne nécessite pas de logiciel d’injection supplémentaire pendant l’exécution, et ne cause aucune perturbation dans le système cible pendant l’exécution. Toutefois, elle est difficile à appliquer à une cible dont on ne possède pas le code source3_{, et ne peut donc}

pas être appliquée à tous les scénarios d’utilisation de logiciels COTS.

• injection à l’exécution : au cours de l’exécution du système, un mécanisme dédié est utilisé pour déclencher l’injection de la faute. Ce déclenchement peut être basé sur un temporisateur, qui s’active un certain temps après le début de l’expérience. Alternativement, le déclenchement peut être spatial, attendant que le programme ait exécuté une instruction ou lu une donnée se trouvant à une adresse mémoire prédéterminée. Le déclenchement peut attendre l’occurrence d’un événement significatif, comme la réception d’un message depuis un nœud donné.

• injection hybride : cette approche est utilisée pour injecter lors de la compilation des fautes qui se comportent à l’exécution comme des fautes transitoires. Le principe consiste à ajouter lors de la compilation un injecteur minimal, dont le rôle à l’exécution sera d’autoriser ou non l’injection de la faute.

Le degré d’intrusivité du mécanisme employé pour insérer les fautes dans le système au cours d’une expérience doit être réduit au minimum, afin qu’une exécution en présence de faute soit comparable à une exécution nominale.

3_{Il est possible de procéder à la modification de l’image binaire pour émuler certaines fautes simples}

(par exemple effectuer des inversions de bit, ou modifier le sens d’une instruction de branchement), mais il est difficile d’insérer des fautes plus subtiles (forcer le déroutement d’un message, par exemple).