Adaptation en ligne de mécanismes de tolérance aux fautes par une approche à composants ouverts

SURETE DE FONCTIONNEMENT ET TOLERANCE AUX FAUTES

 Ces travaux s’intéressent aux systèmes informatiques. Bien que la sûreté de fonctionnement ne soit pas spécifique à ce domaine, nous nous focaliserons à son application aux systèmes informatiques. La sûreté de fonctionnement des systèmes vise à pouvoir placer une confiance justifiée dans le service qu’ils délivrent . La sûreté de fonctionnement s’intéresse entre autre à améliorer la survivance des systèmes, c’est-à-dire leur capacité à continuer de fonctionner pendant et après une perturbation rencontrée durant leur vie opérationnelle. Cette perturbation peut provenir de l’environnement du système (ce qui lui est extérieur) ou du système lui-même (ressources, fautes, ce qui lui est propre). De manière générale, nous ne distinguerons pas ces deux sources de perturbation et nous parlerons du contexte opérationnel du système. La sûreté de fonctionnement met à disposition quatre moyens pour assurer cette confiance : − La prévention des fautes est intégrée au développement du système. L’objectif est d’éviter l’introduction de fautes de développement tant au niveau logiciel qu’au niveau matériel. − La suppression des fautes consiste à vérifier la présence de fautes lors du processus de développement et à réaliser de la maintenance corrective et préventive sur le système en cours d’utilisation. − L’estimation des fautes est réalisée par une évaluation du comportement du système en présence de faute. − La tolérance aux fautes est intégrée au système et agit en ligne en détectant et corrigeant les erreurs du système. L’adaptation est un processus qui a lieu pendant le fonctionnement du système. Pour améliorer la sûreté de fonctionnement du système, nous proposons d’appliquer cette technologie à l’unique moyen que la sûreté de fonctionnement met en place durant la vie opérationnelle du système : la tolérance aux fautes. Nous proposons ici de détailler ce qu’est la tolérance aux fautes afin d’appréhender ce qui peut être adapté. 

 Chaîne de causalité fautes, erreurs et défaillances 

Un système défaille lorsque le service qu’il délivre diffère du service attendu. La tolérance aux fautes cherche à éviter ces défaillances, ou au moins, à prévenir les plus catastrophiques. Ainsi, on préfèrera arrêter un train sur les rails, retardant ainsi l’arrivée des passagers, que leur faire risquer une collision. Pour empêcher l’occurrence de défaillances, la sûreté de fonctionnement s’intéresse à leurs causes. Elle introduit deux notions : les fautes et les erreurs. Une faute est la cause d’une défaillance. La notion de faute est très subjective. Ainsi, si un système soumis à des perturbations magnétiques défaille, la faute est-elle d’origine matérielle dans le sens où le matériel n’a pas toléré les perturbations, ou d’origine conceptuelle, dans le sens où le concepteur du système n’a pas dimensionné le blindage correctement ? L’activation d’une faute du système provoque la propagation d’erreurs dans le système. Une défaillance a lieu lorsqu’une erreur est observable à la frontière du système. Faute, erreur et défaillance forment donc une chaîne de causalité. Dans un souci de gestion de la complexité, les systèmes sont souvent appréhendés comme une composition de sous-systèmes appelés composants. Ainsi, un système est le résultat de la composition de plusieurs composants qui sont eux-mêmes des systèmes. Ainsi, pour un certain niveau d’abstraction (celui du système considéré), les composants sont les entités élémentaires. Leur défaillance est alors une source d’erreur pour le système, dans le sens où elle peut occasionner un comportement anormal du système : il s’agit donc d’une faute pour le système. La chaîne faute, erreur, défaillance devient alors récursive. La tolérance aux fautes a pour objectif d’empêcher la défaillance du système, ou du moins maîtriser ses conséquences. Dans ce but, la tolérance aux fautes cherche à casser la chaîne de causalité, afin de protéger l’utilisateur final du système d’une défaillance. Cette protection peut prendre plusieurs formes selon que l’on cherche à masquer la faute à l’utilisateur, ou le protéger en plaçant le système dans un état sûr (train à l’arrêt par exemple). Pour réaliser cette protection, la tolérance aux fautes utilise un certain nombre de moyens (cf. section I.2.3) implémentés sous la forme de mécanismes de tolérance aux fautes (section I.2.4). Une stratégie de tolérance aux fautes est une combinaison de ces moyens permettant de couvrir le modèle de fautes souhaité, avec les performances (temps de recouvrement, indisponibilité) et les propriétés (disponibilité, fiabilité, robustesse, testabilité, maintenabilité, etc.) désirées. 

 Modèles de fautes

 Le modèle de fautes d’un système définit la nature des fautes présentes dans le système. Il s’agit d’une étape préliminaire à la définition des mécanismes de tolérance aux fautes à mettre en place dans le système. En effet, la tolérance aux fautes devra permettre de tolérer les fautes définies dans le modèle de fautes en utilisant de la redondance et de la diversité (cf. I.2.3). Ainsi, si une faute présente dans le système n’est pas définie dans le modèle de faute, la tolérance aux fautes ne permettra pas de la tolérer. La notion de faute est alors récursive : la définition d’un modèle de faute qui diffère de la réalité est une faute de conception de la tolérance aux fautes du système. L’exemple emblématique est celui d’Ariane 5. Les fautes peuvent être classées selon différents critères : le moment où elles apparaissent dans le cycle de vie du système (faute de conception, faute opérationnelle), leur origine par rapport aux frontières du système (faute interne, faute externe), leur origine phénoménologique (faute naturelle, faute humaine), de leur dimension (faute logicielle, faute matérielle), de leur objectif (faute malicieuse, faute non-malicieuse), de leur intention (faute intentionnelle, faute non-intentionnelle), de la compétence des utilisateurs (faute d’incompétence, faute accidentelle) ou de leur persistance (faute persistante, faute transitoire). Chacune de ces classes de fautes nécessite l’introduction de moyens palliatifs appropriés. Par exemple, les fautes d’incompétence peuvent être évitées par une formation adéquate des utilisateurs, mais aussi une conception ergonomique et des vérifications de la cohérence des ordres des utilisateurs. Dans un système compositionnel, les fautes considérées sont les défaillances des composants. Ces défaillances peuvent être classées en quatre modes : − La défaillance par crash : le composant cesse toute interaction avec les autres composants du système. La notion d’interaction dépend du modèle de système considéré (appel de procédure, envoi de message, écriture dans une mémoire partagée) ; − La défaillance temporelle : le composant interagit avec les autres composants du système en dehors des fenêtres temporelles attendues. Cela concerne aussi bien des interactions qui ont lieu trop tard (échéance manquée) ou trop tôt. La défaillance par crash est une 18 défaillance temporelle, dans le sens où toutes les interactions seront réalisées trop tard (jamais en l’occurrence). − La défaillance en valeur : le composant interagit avec les autres composants du système en utilisant des valeurs incorrectes. − La défaillance byzantine : le composant défaille de manière arbitraire. Ce mode de défaillance regroupe la défaillance par crash, la défaillance temporelle, la défaillance en valeur, et toute combinaison de ces modes de défaillance (valeur erronée trop tard par exemple). Lorsqu’un composant ne défaille que par crash, il est dit « à silence sur défaillance ». Cette hypothèse est l’une des plus fréquemment admise. Toutefois, elle n’est que rarement vérifiée.

 Redondance et diversité

La tolérance aux fautes repose principalement sur deux principes : la redondance et la diversité. La redondance consiste à multiplier les sources d’informations du système. Elle peut être de plusieurs natures : redondance des données (code correcteur d’erreur, enregistrement sur plusieurs supports) et redondance d’exécution (exécution multiple, plusieurs instances du même service). La diversité consiste à s’assurer de l’indépendance des défaillances des services redondées. La diversité joue un rôle essentiel pour tolérer les fautes de mode commun qui existent lors de l’utilisation de répliques identiques. La réplication active est un exemple typique de l’utilisation de la redondance pour masquer les défaillances en valeurs. Plusieurs instances déterministes du même service (plus de trois) évoluent en parallèle. Les mêmes entrées leur sont fournis, et les mêmes résultats sont attendus. Ainsi, il est possible de masquer une faute transitoire de ce service amenant à une défaillance en valeur en comparant les résultats de chacune de ces instances. Si toutes les instances fournissent le même résultat, il n’y a pas de faute transitoire. Si une minorité d’instances diffèrent de la majorité, elles ont alors défailli. Toutefois, la réplication active ne suffit pas si le modèle de faute considère les fautes persistantes, car dans ce cas, même la majorité des répliques peuvent avoir tort. Ainsi, l’utilisation de la diversification   permet de se prémunir des fautes de mode commun. En introduisant une diversité dans la réplication active, la stratégie de tolérance aux fautes permet de masquer les fautes transitoires mais aussi les fautes logicielles persistantes d’origine conceptuelle amenant à une défaillance en valeur. Redondance et diversité ne se limitent pas uniquement au logiciel. Ces deux principes s’appliquent à l’intégralité du système, matériel inclus.