Notions de Sûreté de Fonctionnement
Avant d’aborder l’analyse de l’architecture des systèmes à base d’intergiciel de communication, nous allons rappeler la terminologie que nous utilisons dans la suite du document pour décrire les notions fondamentales de sûreté de fonctionnement. Cette terminologie et ces concepts sont empruntés à [Laprie 1995].
La sûreté de fonctionnement d’un système est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans la qualité du service qu’il leur délivre. L’objectif ultime des recherches dans le domaine est de pouvoir spécifier, concevoir, réaliser et exploiter des systèmes où la faute est naturelle, prévue et tolérable.
Une défaillance du système survient lorsque le service délivré dévie de l’accomplissement de la fonction du système, c’est-à-dire de ce à quoi le système est destiné. Une erreur est la partie de l’état du système qui est susceptible d’entraîner une défaillance, c’est-à-dire qu’une défaillance se produit lorsque l’erreur atteint l’interface du service fourni, et le modifie. Une faute est la cause adjugée ou supposée d’une erreur. Notons que dans les systèmes auxquels nous nous intéressons, qui sont formés par l’interaction de plusieurs sous-systèmes, les notions de faute, d’erreur et de défaillance sont récursives: la défaillance d’un sous-système devient une faute pour le système global. Pour que le système soit digne de confiance, et que cette faute ne se propage pas jusqu’au service délivré aux utilisateurs, on cherche à éliminer les canaux de propagation d’erreur afin de briser cette chaîne causale. L’un des apports de nos travaux est de proposer des mécanismes permettant d’évaluer la probabilité que la défaillance d’un composant particulier, l’intergiciel, se propage au reste du système.
Un système ne défaille pas toujours de la même manière, ce qui conduit à la notion de mode de défaillance, que l’on peut caractériser suivant trois points de vue: le domaine de la défaillance, la perception des défaillances par les utilisateurs du système, et les conséquences des défaillances sur l’environnement du système.
Systèmes à base d’intergiciel de communication
Dans cette section, nous détaillons les types de systèmes répartis auxquels nous nous intéressons. Nous commençons par décrire le modèle de programmation offert par un système réparti, et le modèle à objets sur lequel nous nous appuyons. Nous analysons ensuite l’architecture d’un système à base d’intergiciel de communication suivant plusieurs points de vue, ce qui nous permet d’identifier les types de faute qui peuvent affecter ces systèmes. Nous regroupons ces fautes en classes, suivant leur nature et la couche du système où elles apparaissent. Nous analysons de quelle façons les erreurs engendrées par ces fautes peuvent se propager dans le système, et quelles sont les défaillances qui peuvent en résulter.
Modèle de programmation et transparence de la répartition : Un réseau d’ordinateurs est un ensemble d’ordinateurs indépendants appelés nœuds, inter-connectés par des lignes de communication. Un système réparti à base d’intergiciel de communication offre un modèle de programmation qui permet d’utiliser un réseau d’ordinateurs comme un ordinateur unique, sans se soucier de la répartition des tâches sur les différents nœuds. La localisation des nœuds de calcul est masquée, ou rendue «transparente». Nous appelons la couche de logiciel qui implémente cette abstraction un intergiciel de communication.
On distingue plusieurs types de transparence dans les systèmes répartis: d’accès lorsque l’accès à une ressource se fait par une interface unique, que cette ressource soit locale ou distante; de localisation qui exprime la possibilité d’accéder à une ressource sans en connaître la localisation; à la réplication lorsque le service repose sur des exemplaires multiples de res sources, sans que leur multiplicité soit explicitée; à la concurrence lorsque plusieurs accès concurrents à la même ressource sont autorisés, sans que ces accès interfèrent entre eux; à la mobilité qui permet la migration d’objets sans affecter le déroulement des opérations en cours; à la défaillance lorsque la défaillance d’un objet ou d’un nœud peut être masquée aux utilisateurs en attendant le recouvrement de l’erreur correspondant .
Notons que la notion de transparence possède un sens particulier en informatique, puisque son dual est l’opacité. On dit qu’une fonctionnalité est « transparente » lorsque le programmeur n’a pas besoin de la prendre explicitement en compte pour en bénéficier. Cette transparence provient du masquage de la complexité sous-jacente, par un mécanisme dont l’implémentation est opaque. Un intergiciel de communication a donc pour rôle de rendre transparente la localisation des objets; on peut aussi dire qu’il est chargé de maintenir une illusion de localité, ou une abstraction dans laquelle la distance entre les nœuds est nulle.
Propagation d’erreur dans un système à base d’intergiciel
Lorsqu’une erreur qui survient dans un sous-système entraîne une corruption dans un autre sous-système, on parle de propagation d’erreur. Le support pour cette propagation est dit canal de propagation d’erreur, et peut être un élément physique partagé par les deux sous-systèmes, ou une interaction entre eux. Le domaine de la tolérance aux fautes consiste à trouver des mécanismes de: détection d’erreur, qui permettent d’identifier le plus vite possible un état erroné. Un checksum intégré à un message est un exemple de mécanisme de détection d’erreur: il permet au récepteur de détecter que le message a été corrompu au cours de la transmission. recouvrement d’erreur, qui consiste à ramener le système vers un état sûr et sans erreur. Le fait de demander la retransmission d’un message corrompu est une stratégie de recouvrement d’erreur.
confinement d’erreur, qui consistent à empêcher la propagation d’une erreur depuis le sous-système où elle s’est produite.
Considérons les différentes stratégies architecturales, que nous avons présentées dans la section précédente, selon deux points de vue: quels sont les canaux de propagation d’erreur induits par l’architecture, pour des erreurs qui se propagent entre l’intergiciel et l’application, ou entre l’intergiciel et le système d’exploitation.
dans un contexte d’évaluation du COTS, quels sont les problèmes posés par l’architecture en ce qui concerne l’« analysabilité » du composant (détection de zones de code mort, de fonctionnalités cachées). D’autre part, quelle est la facilité pour mettre en œuvre des mécanismes d’encapsulation pour améliorer le confinement et augmenter la robustesse du COTS, ou pour limiter l’accès aux fonctionnalités non utilisées de ce composant. La stratégie résidante noyau protège le courtier de programmes applicatifs défaillants: le courtier s’exécute dans un contexte privilégié qui n’est pas accessible aux applica tions. Cependant, le service courtier constitue un canal de propagation d’erreur pour tous les objets localisés sur ce nœud. Dans un contexte d’évaluation de logiciel COTS, le fait de s’exécuter à un niveau de privilège élevé pose des problèmes quant aux possibilités d’analyse de l’intergiciel.
Types d’intergiciels visés
Notre approche de caractérisation peut s’appliquer à différentes catégories d’intergiciels orientés communication: des logiciels conformes à la plate-forme CORBA, tels que les implantations TAO, ORBacus, omniORB et les courtiers intégrés aux machines virtuelles Java. Nous pouvons caractériser la fonctionnalité de courtier fournie par une de ces implantations, ainsi que ses services (tels que la désignation et la diffusion d’événements). Dans une moindre mesure, il peut être intéressant d’étudier la robustesse de leurs outils de développement, en particulier le compilateur IDL et le référentiel d’interfaces.
la plate-forme DCOM de Microsoft. Cet intergiciel de communication supporte la communication à base d’invocation de méthode entre objets répartis hétéro gènes. Il s’appuie sur la définition d’un format binaire pour les interfaces des objets, inspiré du mécanisme de v tables utilisé par les compilateurs C++ pour la résolution de la liaison dynamique.
les fonctionnalités orientées communication des exécutifs de certains langages de programmation: le support RMI (Remote Method Invocation, mécanisme d’invocation de méthode à distance) fourni par les machines virtuelles Java. Ce mécanisme ne supporte par l’hétérogénéité, puisque seuls des objets implantés en langage Java peuvent interagir. Par contre, il permet l’interopérabilité entre des ob jets Java s’exécutant sur des machines virtuelles de fournisseurs différents. la CLR (Common Language Runtime, ou support d’exécution commun) de la plate-forme .NET de Microsoft. Le mécanisme .NET Remoting autorise les appels de procédure à distance, avec divers formats d’emballage et mécanismes de transport.
Techniques de caractérisation de la Sûreté de Fonctionnement
Il existe deux grandes catégories de techniques pour l’évaluation de la sûreté de fonctionnement de systèmes informatiques: les techniques à base de modèles, et les techniques à base de mesures. La modélisation permet aux concepteurs d’obtenir des prévisions sur les attributs de sûreté de fonctionnement d’un système en se basant sur des mesures probabilistes du comportement de ses sous-systèmes. Ces résultats sont utiles pendant les phases de conception du système, puisqu’elles permettent l’évaluation de mesures pertinentes de la sûreté de fonctionnement avant même que le système ne soit construit.
Cependant, les techniques de modélisation ne peuvent que prédire la sûreté de fonctionnement d’un système. Une fois qu’il a été développé et déployé, les techniques basées sur les mesures peuvent être employées afin d’obtenir des informations plus précises. Il existe deux familles de techniques orientées mesure permettant d’obtenir des informations sur la sûreté de fonctionnement d’un système: l’observation de systèmes opérationnels, et l’injection de faute.
Table des matières
Introduction Générale
1 Problématique
1.1 Contexte des travaux
1.2 Notions de Sûreté de Fonctionnement
1.3 Systèmes à base d’intergiciel de communication
1.3.1 Modèle de programmation et transparence de la répartition
1.3.2 Le modèle à objets
1.3.3 Le modèle d’interaction
1.3.4 Le point de vue traitement
1.3.5 Le point de vue ingénierie
1.3.6 Le point de vue technologique.
1.3.7 Stratégies d’implantation d’un intergiciel de communication
1.3.8 Propagation d’erreur dans un système à base d’intergiciel
1.3.9 Types d’intergiciels visés
1.4 Techniques de caractérisation de la Sûreté de Fonctionnement
1.4.1 Observation de systèmes opérationnels
1.4.2 L’injection de fautes
1.5 État de l’art en caractérisation d’intergiciel
1.5.1 Fautes d’origine interne
1.5.2 Fautes d’origine externe
1.6 Obstacles à la caractérisation d’intergiciel
1.6.1 Transparence, interception et isolation
1.7 Récapitulatif
2 Méthodologie
2.1 Préliminaires à la caractérisation
2.1.1 Définition du système cible
2.1.2 Un modèle de fautes pour les systèmes CORBA
2.1.3 Modes de défaillance d’un intergiciel de communication
2.1.4 Définition du profil applicatif
2.2 Techniques d’injection de fautes pour cibler l’intergiciel
2.2.1 Corruption de l’espace d’adressage
2.2.2 Techniques de mutation de code
2.2.3 Techniques de corruption à l’API
2.2.4 Technique d’injection dans l’exécutif
2.2.5 Techniques de corruption de messages
2.3 Récapitulatif
3 Résultats Expérimentaux
3.1 Cibles et contexte expérimental
3.1.1 Configuration du banc de test
3.1.2 Événements significatifs lors d’une expérience
3.2 Impact de corruptions IIOP sur le service de désignation
3.2.1 Configuration expérimentale
3.2.2 Distribution des manifestations de fautes
3.2.3 Analyse des diagnostics d’erreur
3.2.4 Latence de détection d’erreur
3.2.5 Modèle de faute «double zéro»
3.2.6 Impact de fautes multiples
3.3 Impact de corruptions IIOP sur le service de diffusion d’événements
3.3.1 Configuration expérimentale
3.3.2 Résultats
3.4 Impact de fautes GIOP sur des instances de service synthétique
3.4.1 Configuration Expérimentale
3.4.2 Résultats
3.5 Évaluation de la propagation d’erreur depuis l’exécutif
3.5.1 Configuration Expérimentale
3.5.2 Sensibilité des courtiers CORBA au comportement de l’exécutif
3.5.3 Résultats pour d’autres logiciels de communication
3.5.4 Résultats pour des logiciels grand public
3.6 Expériences de mutation de code
3.6.1 Compilateurs IDL et interfaces mutées
3.7 Récapitulatif
4 Analyse comparative
4.1 Comparatif des techniques d’injection de fautes
4.2 Impact de la version du composant
4.3 Analyse a posteriori des fautes du logiciel
4.3.1 Fautes liées à l’allocation mémoire
4.4 Influence de l’architecture du courtier
4.4.1 Architecture orientée dæmon
4.4.2 Influence du support exécutif
4.5 Vers une méthode d’étalonnage d’intergiciels de communication
4.5.1 Comparaison de courtiers CORBA sur étagère
4.5.2 Extension à d’autres intergiciels de communication
4.6 Intergiciels et malveillances
4.7 Mécanismes d’encapsulation pour un intergiciel
4.7.1 Contrôler l’interaction entre l’application et l’intergiciel
4.7.2 Contrôler l’interaction intergiciel/système d’exploitation
4.7.3 Contrôler l’interaction entre l’intergiciel et les objets distants
4.8 Récapitulatif
5 Conclusions et perspectives
5.1 Remarques pour les intégrateurs d’intergiciel
5.1.1 Guider le choix d’un intergiciel candidat
5.1.2 Mécanismes de détection et de confinement d’erreur préconisés
5.2 Remarques pour les développeurs d’intergiciel
5.3 Perspectives des travaux
A Construction d’interfaces synthétiques
A.1 Difficultés de la technique
B Mise en œuvre des saboteurs
B.1 Défauts de ce mode d’interception
Bibliographie
