Fautes d’origine interne

Une faute est dite interne lorsque la corruption de l’état du composant qu’elle engendre a son origine dans ce composant. Ceci comprend les erreurs de programmation qui peuvent affecter les données internes du système, et les fautes matérielles qui peuvent corrompre la mémoire du système ou une unité d’entrées/sorties. Le modèle de fautes le plus employé pour simuler ces fautes est l’inversion d’un bit.

Un nombre important d’outils ont été développés afin d’automatiser le dérou- lement de campagnes d’injection de fautes utilisant ce modèle de fautes. Deux exemples significatifs sont Xception, développé à l’Université de Coimbra au Por- tugal [Carreira et al. 1998], et MAFALDA, développé au LAAS-CNRS, Toulouse, France [Arlat et al. 2002]. Ces outils fournissent en général un banc de test dans lequel on exécute son système, un certain nombre d’injecteurs permettant de travailler avec différents modèles de faute, un système pour sauvegarder le résultat des expériences, et des outils d’analyse des résultats. Ces outils ont été appliqués à une variété consi- dérable de systèmes cibles :

• les cartes contrôleurs pour des bus de communication : citons par exemple le projet FIT qui a effectué des expériences d’injection de fautes dans des implé- mentations du protocole TDMA TTP/C ;

• des micronoyaux du commerce [Arlat et al. 2002] ;

• des systèmes de gestion de bases de données du commerce [Costa et al. 2000] ; • des applications embarquées sur des satellites (Mars Pathfinder).

Toutefois, il existe très peu d’exemples d’application de ce type d’outil à des inter- giciels de communication. Les deux études les plus proches de notre problématique sont [Chevochot & Puaut 2001], qui cible un support d’exécution distribué pour des applications temps-réel ; et [Chung et al. 1999], qui compare l’impact de fautes telles que l’arrêt de processus et de processus légers sur des applicationsCORBAetDCOM. Les travaux de Chevochaut et Puaut concernent des expériences d’injection de fautes par logiciel visant à estimer la couverture de l’hypothèse de silence sur défaillance d’un

support d’exécution distribué à base de micronoyaux COTS temps-réel. La cible des expériences est un intergiciel spécifique pour la tolérance aux fautes, qui s’exécute sur le micronoyau temps-réel Chorus. Le système est constitué d’un ensemble de machines à base de processeur Pentium, communicant sur un bus ATM et sur un bus Ethernet. L’intergiciel implémente des services de communication de groupe, de synchronisation d’horloge et d’ordonnancement réparti. Les fautes injectées sont des inversions de bits dans la mémoire du micronoyau et de l’intergiciel.

Le système cible ne comporte aucun mécanisme matériel spécifique de détection d’erreur, en dehors de ceux implémentés par le processeur. Le système peut être déployé en présence de divers mécanismes logiciels de détection d’erreur, basés sur la redondance (checksums sur les messages échangés entre nœuds, par exemple), ou des assertions comportementales (telles que la comparaison du flot de contrôle avec un graphe d’appel calculé statiquement). Les auteurs ont mesuré un facteur de couverture de l’hypothèse de silence sur défaillance variant entre 80,6% (dans une configuration sans aucun mécanisme logiciel de détection d’erreur) et 99,1% (avec tous les mécanismes logiciels de détection d’erreur activés).

Cette étude montre que les fautes affectant l’intergiciel de communication sont bien plus graves – vis-à-vis de la propriété de silence sur défaillance – que les fautes affec- tant le micronoyau, car toutes les fautes qui ont provoqué une violation de l’hypothèse de silence sur défaillance ont été injectées dans une zone mémoire correspondant à l’intergiciel, et la majorité d’entre elles ont affecté le protocole de multicast fiable. Ce résultat souligne l’importance de caractériser le comportement d’un intergiciel de communication en présence de fautes.

Le mode de défaillance le plus fréquemment observé a été l’arrêt inopiné de nœuds, sans production de valeurs erronées au niveau applicatif ni de propagations d’erreurs vers les autres nœuds. Le mécanisme de détection d’erreur le plus efficace (mesuré par le taux de « première détection », c’est-à-dire le mécanisme qui a été le premier à détecter une erreur lors d’une expérience), est le mécanisme de protection d’espaces d’adressage fourni par le micronoyau, avec plus de 50% de premières détections. La seconde étude proche de notre problématique est [Chung et al. 1999], qui rapporte des expériences d’injection de fautes ciblant des applicationsCORBA(plus précisément

l’implémentation Orbix) et DCOM, sous le système d’exploitation Windows NT. Les fautes simulées sont le gel et l’arrêt inopiné de processus, de processus légers et de nœuds de calcul.

Les auteurs ont constaté que les modes de défaillance des applicationsDCOMdiffèrent suivant que le client et le serveur s’exécutent sur le même nœud, ou sur des nœuds différents : des codes erreurs différents sont levés au niveau applicatif dans les deux cas. Cela implique que la transparence vis-à-vis de la localisation fournie par cet intergiciel de communication disparaît en présence de fautes. Pour les applications

CORBA, le mode de signalement des défaillances est le même dans les deux cas, avec toutefois une détection plus rapide lorsque les deux objets s’exécutent sur le même nœud.

Pour les deux intergiciels de communication, les auteurs ont observé que la latence de détection de certaines défaillances (par exemple la perte de la connexion réseau sur un nœud) est très importante, allant jusqu’à 8 minutes dans certains cas. Ce délai est dû à ce que l’intergiciel tente un certain nombre de retransmissions lorsqu’une requête échoue, avant de rapporter l’erreur au niveau applicatif, et que le protocole Ethernet utilise un système de binary-backoff8 _{qui peut être lent à détecter les défaillances}9_.

Ces observations ont conduit les auteurs à suggérer la mise en place de mécanismes de chien de garde au niveau applicatif, pour détecter les défaillances de manière « hors- bande ».

Nous ne connaissons pas d’autres travaux portant sur des cibles CORBAqui simulent l’effet d’autres types de fautes internes, telles que des corruptions de la mémoire. Cependant, cette technique a été utilisée intensivement pour la caractérisation d’autres classes d’exécutifs, telles que les systèmes d’exploitation et les exécutifs langages.