Modes de défaillance d’un intergiciel de communication

Dans cette section, nous détaillons les types des défaillances qui peuvent affecter un intergiciel, et analysons l’impact de ces défaillances sur le système distribué qui s’appuie sur cet intergiciel. Notre analyse se limite aux défaillances qui sont imputables à l’intergiciel, ou dont les effets peuvent être amplifiés par l’intergiciel.

Rappelons que dans les systèmes que nous considérons, la défaillance d’un composant devient une faute dans le système global. L’impact de ces défaillances dépend donc des mécanismes de détection d’erreur et de recouvrement mis en place dans le système final. Nous classifions les défaillances en fonction de l’élément de l’intergiciel qui les engendre : outils de développement, courtier, et servicesCORBA.

Défaillances des outils de développement

Citons quelques exemples de défaillances dues aux outils de développement associés à l’intergiciel de communication :

• le compilateur IDL ne compile pas une description d’interface alors qu’elle est correcte ;

• le compilateur IDL compile une description d’interface alors qu’elle est invalide ; • le code généré par le compilateur IDL (les souches et les squelettes) est invalide. Dans les cas d’erreurs de syntaxe, l’erreur sera détectée par le compilateur du langage de programmation. Des corruptions plus subtiles peuvent provoquer un comportement erroné à l’exécution.

• les fichiers d’en-tête du courtier sont erronés : ils ne correspondent pas à la bibliothèque partagée où réside le coeur du courtier, ou ne correspondent pas au code généré par le compilateur IDL.

L’essentiel de ces défaillances devrait être détectées lors des phases de développement ou d’intégration du système. Nous considérons que les défaillances détectées avant la phase d’intégration sont moins graves qu’une défaillance qui surviendrait plus tard dans le cycle de vie, en phase opérationnelle. Nous avons donc peu travaillé sur la caractérisation de ces outils de développement.

Défaillances du courtier

Énumérons les fonctionnalités d’un courtierCORBAqui peuvent défaillir :

• transmission de la requête : le courtier est responsable de l’acheminement de la requête depuis le client vers le servant, ainsi que de la transmission du ré- sultat de la requête (à l’exception des opérations oneway). La transmission de la requête peut défaillir soit côté client, soit côté serveur. La défaillance peut être par omission (la requête n’est pas transmise au servant), par duplication (la même requête est transmise plusieurs fois), par fabrication (le servant reçoit des requêtes qui n’ont été émises par aucun client), ou par erreur de routage (la requête ou sa réponse est transmise au mauvais servant).

Nous distinguerons dans la suite deux types d’erreurs de transmission : le refus de transmission (qui peut être détecté immédiatement par le client), et le gel de la transmission (la réponse à la requête n’arrive pas au bout d’un temps prédéterminé, bien plus long que le temps de transmission normal).

• intégrité de la requête : le courtier corrompt les données qu’il transmet.

• mauvais signalement des exceptions : lors d’une invocation de méthode CORBA, le courtier côté serveur doit informer le courtier côté client qu’une exception s’est produite lors du traitement de la requête, en lui renvoyant un message GIOP avec un type particulier. Le courtier côté client doit signaler à l’application qu’une exception s’est produite, en respectant la manière dont sont définies les exceptions par la projection langage. Si ce signalement est incorrect, soit par omission, soit parce qu’un courtier a signalé une exception qui n’a pas réellement eu lieu, soit parce que le type d’exception signalé ne correspond pas à celui qui a été signalé par le servant, les mécanismes de tolérance aux fautes du système ne seront pas activés correctement.

Défaillances de services CORBA

Examinons maintenant l’impact des défaillances qui touchent les principaux services

CORBA: la désignation, la diffusion d’événements, et le référentiel d’interfaces.

Le service de désignation constitue un point dur (ou « single point of failure ») du système : la défaillance de ce service peut avoir des effets catastrophiques pour un système réparti, puisque les objets ne peuvent plus obtenir les références des services qu’ils souhaitent invoquer.

L’impact de la défaillance de ce service dépend considérablement du rôle qu’il joue dans le système, qui peut y faire très peu appel ou en dépendre beaucoup. Il est possible de se passer d’un service de désignation, en allouant les références objet sta- tiquement ; ce choix est fait dans certaines applications embarquées, où les ressources disponibles sont limitées, et où la configuration du système évolue peu dans le temps. D’autres systèmes plus dynamiques font très largement appel au service de désignation pour accroître la souplesse du système.

Les fournisseurs utilisent des techniques variées pour rendre leur service de désigna- tion tolérant aux fautes. La plupart des implantations prennent en charge la persis- tance des couples nom–référence, en sauvegardant régulièrement l’état du service sur un support stable. Certaines implantations permettent l’utilisation d’une configuration

primary–backup, où la défaillance du serveur primaire est masquée par un bascule-

ment automatique vers le serveur secondaire.

Les modes de défaillance de ce service sont les suivants :

• l’arrêt inopiné du service : le ou les processus hébergeant le service s’arrêtent. Ce mode de défaillance peut être testé localement au nœud, en examinant la table des processus du nœud, ou à distance, en cherchant à établir une connexion réseau au service. Lorsque le service s’est arrêté, la tentative de connexion réseau sera immédiatement refusée par le nœud distant.

• le gel du service : un gel diffère d’un arrêt inopiné en ce que le nœud distant accepte la connexion réseau au service, mais qu’il ne répond pas dans un laps de temps prédéfini qui est largement supérieur au temps de service normal. • la corruption de données : le service oublie des enregistrements de noms, ou

renvoie des réponses incorrectes à des demandes de résolution de nom.

Nous distinguerons dans la suite deux types de gels de service, en fonction du nombre de clients affectés. Un gel total implique que tous les clients du service sont bloqués indéfiniment en attendant la réponse du service. Un gel partiel implique qu’un seul client est bloqué, alors que d’autres clients perçoivent un service normal pendant la même période.

Le service de diffusion d’événements fournit un mécanisme de communication de type producteur-consommateur (ou publish-subscribe), qui complète la commu- nication classique de type requête-réponse. Il fournit une abstraction de canal d’événements, auquel des producteurs et des consommateurs d’événements peuvent s’inscrire ; le canal est responsable de la propagation des événements entre les produc- teurs et les consommateurs. Ce mécanisme permet de réduire le degré de couplage entre les objets dans le système, puisqu’un producteur n’a pas besoin de se préoccuper du nombre de consommateurs qui sont intéressés par ses événements, et un consom- mateur n’a pas besoin de savoir qui est à l’origine d’un événement qu’il reçoit. Les conséquences de la défaillance du service de diffusion dépendent évidemment de la criticité des informations qu’il transporte, mais en général ce service, lorsqu’il est déployé, est un point dur du système. Même une dégradation de sa qualité de service peut nuire à la sûreté de fonctionnement. Les types de défaillances envisageables pour ce service sont :

• l’arrêt inopiné ou le gel du service ; • la perte ou la duplication d’événements ; • la corruption d’événements ;

• une dégradation forte de la qualité de service fourni (temps de diffusion qui augmente fortement).

Le référentiel d’interfaces fournit des méta-informations sur des interfaces. Il permet à des clients de connaître l’ensemble des opérations offertes par une interface, ainsi que le nombre et le type de ces arguments. Cette information est surtout utile aux clients qui souhaitent utiliser le mécanisme d’invocation dynamique de CORBA (le

Dynamic Invocation Interface, ou DII), qui permet de s’affranchir de l’utilisation de

souches.

Les modes de défaillance du référentiel d’interfaces sont semblables à ceux des autres services. L’impact de sa défaillance est considérable pour les clients qui exploitent le DII (puisqu’ils ne pourront plus construire des requêtes dynamiquement), mais ne devrait pas avoir d’impact sur les clients et les serveurs qui utilisent les souches et squelettes.

La dernière classe de défaillances qui peut affecter les systèmes à base d’intergiciel a trait à la gestion des configurations. Dans un système réparti à longue durée de vie, il peut être nécessaire de procéder à des mises à jour de sous-systèmes, et parfois d’ajouter des fonctionnalités à un système en cours d’opération. Cette activité de main- tenance introduit un risque d’incohérence dans un système où certains clients utilisent des informations périmées concernant l’interface des serveurs. Ce problème relève davantage de l’administration de systèmes répartis que de la sûreté de fonctionnement des implantations d’intergiciel ; il ne sera donc pas traité dans cette thèse.