Précédent : Mise au point des applications Remonter : Applications Suivant : Travail coopératif assisté par ordinateur

Applications tolérantes aux défaillances

 

Participants : Michel Hurfin, Michel Raynal

Mots-clés : diffusion fiable, consensus, replication, Corba

L'algorithmique répartie s'est rapidement imposée dans beaucoup de secteurs industriels (domaine bancaire, domaine financier, domaine médical, domaine des télécommunications, vente par correspondance, réservation de billets, contrôle des processus industriels, travail coopératif, téléconférence). Le développement de nouvelles technologies réseaux ne fera qu'accélérer cette tendance. Parallèlement, les attentes des utilisateurs ont également évolué. Notamment, les applications de demain devront, d'une part, pouvoir s'exécuter sur des réseaux composés de calculateurs hétérogènes en nombre variable et d'autre part, satisfaire à la fois des contraintes de sûreté et des contraintes temporelles. Dans le projet, un nouvel axe de recherche est consacré à la conception et au développement d'un ensemble de services permettant de répondre efficacement à ces nouvelles exigences. Pour atteindre cet objectif, nous nous appuyerons sur trois concepts dont l'intérêt n'est plus à démontrer : le concept d'objet, le concept de groupe et la notion de temps réel.

L'intérêt du concept d'objet est largement reconnu lorsqu'il s'agit de résoudre les problèmes d'interopérabilité et de portabilité dans un environnement hétérogène. Une application peut être vue comme un ensemble d'entités réutilisables qui collaborent et peuvent être accédées, dynamiquement ou non, au travers d'interfaces clairement définies et exposées, et cela indépendamment de leur localisation au sein du réseau ainsi que du langage de programmation dans lequel elles ont été écrites. Pour que les interactions entre les applications soient envisageables, il est nécessaire qu'elles partagent un modèle et une architecture communs. La reconnaissance quasi générale des travaux de l'Object Management Group (OMG ) et l'adoption par les acteurs du monde industriel de sa norme Corba (Common Object Request Broker Architecture ) font de Corba un standard de facto à côté du standard MS (COM). Bien que cela ne soit pas sa fonction première, Corba peut également être vu comme un vernis linguistique qui permet d'intégrer des technologies diverses et complémentaires au sein d'une architecture commune (mécanisme de transaction, mécanisme d'authentification, mécanisme de mémoire stable).

L'absence de services de communication de groupe dans la spécification actuelle de la norme Corba est souvent perçue comme un manque regrettable. L'intérêt du concept de groupe n'est pas uniquement lié au fait qu'il permet de désigner un ensemble de processus par un nom unique ou une adresse commune. A condition de pouvoir coordonner l'activité des différents processus qui composent le groupe, ce concept permet également d'augmenter les performances et la disponibilité. Mais plus que tout, le concept de groupe se révèle être une excellente technologie de middleware pour mettre en oeuvre divers mécanismes de tolérance aux défaillances. Afin de pouvoir définir des objets tolérants aux défaillances, nous nous proposons d'enrichir les services communs d'objets (Common Object Services ) offerts dans Corba en spécifiant, dans le langage de description d'interfaces (IDL ), des services de duplication. Une technique classique pour assurer un service fiable consiste en effet à dupliquer l'état du serveur sur différents processeurs du réseau. Nous plaçant dans l'hypothèse de défaillances de sites indépendantes, une requête destinée à un objet tolérant aux défaillances sera traitée si au moins une des copies n'est pas défaillante. La cohérence des informations dupliquées peut être maintenue de différentes manières ; les deux principales méthodes étant connues sous les noms de primary-backup et de active replication.

Bien que cela puisse paraître paradoxal, spécifier des contraintes temporelles et en garantir le respect sont devenus des nécessités même dans le cas de systèmes répartis asynchrones. La notion de temps réel mou (soft real-time) est plus particulièrement adaptée à ce type de systèmes. Les contraintes temporelles qui sont fixées ne sont pas critiques dans le sens où leur non respect n'engendre pas de préjudices irrémédiables mais uniquement une dégradation des performances. Lorsque des contraintes temporelles sont spécifiées, un processus doit signaler au plus tôt tout non respect éventuel d'une contrainte temporelle afin qu'une nouvelle stratégie puisse être adoptée.

Dans le cadre de ce travail, nous considérons des systèmes asynchrones. Outre le fait que nous souhaitons prendre en compte des contraintes temporelles, l'originalité de notre démarche réside dans le fait que nous spécifions et développons les services de duplication en nous appuyant sur des services de communication de groupe et en exploitant pour cela les derniers résultats de recherche. Le premier de ces résultats est la notion classe de détecteur de défaillances non fiables, introduite par Chandra et Toueg. Dans un environnement asynchrone, ce concept permet de caractériser les conditions minimales devant être satisfaites pour que le problème du consensus puisse être résolu. Le second résultat sur lequel nos travaux vont reposer est la notion de consensus générique introduite par Schiper et Guerraoui. Ce concept complète les travaux de Chandra et Toueg en mettant en évidence le lien qui existe entre le problème abstrait du consensus et différents problèmes d'accord que l'on rencontre lors du développement d'applications complexes (élection, diffusion ordonnée, validation atomique non-bloquante, etc.).

Cette action venant de débuter, nous ne nous sommes intéressé jusqu'à ce jour qu'à la mise en oeuvre des services de bases (communication point à point et diffusion fiables, détecteurs de défaillances). Dans le cadre de ce travail, des contacts ont été établis avec l'Université de Bologne (Ö. Babaog lu), l'école Polytechnique de Lausanne (A. Schiper), la société Alcatel Alsthom Recherche et la société Chorus Systèmes. Un projet de collaboration avec l'Université de Florianapolis au Brésil a également été défini.

Précédent : Mise au point des applications Suivant : Travail coopératif assisté par ordinateur Remonter : Applications