Précédent : Logiciels Remonter : Projet SOR, Systèmes Objets
Répartis Suivant : Actions industrielles
Résumé : En 1997, nous avons concentré nos efforts sur six axes de recherche: la gestion des références dans les systèmes de grande échelle (§), les entrepôts persistants répartis (§
), la gestion de la réplication (§
), les caches répartis de grande échelle (§
), la gestion de données répliquées sur des machines déconnectées et mobiles (§
), et les systèmes adaptatifs (§
).
Une référence est ce qui permet d'identifier, d'accéder et donc de partager un objet. Mécanisme de base de tout système, les références doivent être performantes et avoir une sémantique bien spécifiée. En particulier, elles doivent permettre le ramassage de miettes, être bien typées, et se comporter proprement en présence de fautes.
Au cours des années passées, nous avons défini et prototypé les Chaînes de Paires Souche-Scion (PSS), un mécanisme de références propre, efficace, tolérant les fautes non byzantines, et permettant le ramassage de miettes. Ce mécanisme représente une avancée dans la gestion des références réparties et le ramassage de miettes dans les systèmes distribués. Les résultats nouveaux cette année sont un algorithme de ramassage de cycles répartis et le portage des chaînes de PSS dans d'autres environnements de programmation que C++.
En 1997, nous avons proposé un algorithme permettant de ramasser de cycles de miettes répartis. L'algorithme [13] développé est basé sur l'algorithme de Hughes, rendu asynchrone et tolérant aux pannes. Il est aussi adapté aux systèmes de grande échelle par l'utilisation de grappes («clusters»). Une preuve manuelle de l'innocuité de l'algorithme a été écrite, et l'algorithme a été mis en oeuvre dans la version Objective-Caml des Chaînes de PSS. L'implémentation fonctionne correctement, mais n'a pas encore été testée à grande échelle.
En plus de la consolidation de version C++ de base, les Chaînes de PSS ont été portées d'autres environnements de programmation: Java, Objective-Caml et Smalltalk. Il faut noter que les délais de portage dans ces différents environnements ont été très variables: Java, cinq semaines; Objective-Caml, deux semaines; et Smalltalk, deux jours. Ceci est à comparer au long délai de développement en C++, environ deux ans.
L'implémentation Smalltalk semble être de loin la plate-forme la plus adaptée pour poursuivre nos expérimentations avec les Chaînes de PSS et les différents algorithmes qui s'y rapportent.
L'implémentation des Chaînes de PSS dans le langage Objective-Caml a permis l'obtention rapide d'un prototype mettant en oeuvre l'ensemble des propriétés des Chaînes de PSS (raccourcissements paresseux, ramasse-miettes distribué, localisations faibles) ainsi que des propriétés plus particulières liées au langage (génération automatique des souches, vérification dynamique des types).
Nous proposons l'abstraction d'Entrepôt
Persistant Réparti (EPR) (en anglais: PDS). Une application
travaille dans l'EPR comme en mémoire normale. Toute donnée
allouée dans l'EPR, et accessible, devient automatiquement
persistante et peut être partagée par tous les processus du
réseau. Le système gère automatiquement et efficacement la mise
en cache sur le site accédant à une donnée, le ramasse-miettes,
le stockage disque, la tolérance aux pannes, et le contrôle de
concurrence. Cette abstraction facilite l'écriture d'applications
réparties, et le portage en environnement réparti d'applications
centralisées. Nous testons cette capacité grâce à des
applications réelles et d'envergure, tel un outil de CAO
coopérative pour l'architecture et le bâtiment (voir §).
Sur chaque machine il existe deux composants: une bibliothèque de niveau utilisateur - «User Level Library» (ULL) - et un «Daemon». L'ULL est liée avec une application et est responsable, entre autres, de la gestion de mémoire. Le «Daemon» est en charge de la communication avec les autres «Daemons», de la gestion de cache et des transactions, etc.
Une première version de la plate-forme (§) a été mise en
oeuvre dans le cadre du projet PerDiS (§
).
Elle exécute les applications écrites en C et C++ sur des
machines Unix. En outre, un environnement de programmation a été
construit, offrant entre autres une implémentation persistante de
la bibliothèque standard C++ STL.
Pour réaliser la persistance par atteignabilité, l'algorithme de ramasse-miettes que nous avons précédemment développé pour le projet Larchant [2] a été amélioré et mis en oeuvre.
Le comportement de quelques applications, dont le banc d'essai de base de données persistantes OO7 en terme de gestion de la mémoire, a été caractérisé. Il s'agit d'instrumenter le graphe des objets présents en mémoire persistante afin d'évaluer les longueurs de référence entre objets, la durée de vie des objets et de quantifier le nombre de cycles ainsi que leur longueur.
Un modèle de cohérence est satisfaisant pour une application si les observations permises par le système de réplication satisfont les propriétés (concernant soit l'ordonnancement des accès, soit l'état des réplicats) sur lesquelles le programmeur d'application a fondé la correction de ses algorithmes. Ces propriétés définissent le contrat de cohérence entre l'application et le système support de la réplication.
Cette reformulation de la problématique de cohérence en réparti permet de préciser la séparation des rôles entre un système de réplication et les applicatifs qui l'utilisent: l'application spécifie les propriétés qu'elle souhaite pour ses observations; le système support de réplication met en oeuvre un protocole d'accès aux réplicats qui garantit effectivement que les observations permises satisfont aux propriétés attendues.
Ceci permet d'isoler une fonction système pour la cohérence, débarrassée des considérations du type de l'objet, du schéma d'accès ou des caractéristiques de l'environnement de l'exécution. L'utilisation de ces aspects pour adapter le protocole de maintien de cohérence n'est pas délaissée: c'est à l'application d'adapter sa demande (c'est-à-dire les propriétés à satisfaire). Ceci permet, au niveau système, de raisonner de façon uniforme aussi bien pour les modèles de cohérence forte, cohérence causale, sérialisabilité que pour les modèles de cohérence faible.
Le problème difficile pour le système est de satisfaire
efficacement les demandes particulières de différentes
applications. La solution actuelle est de demander aux
applications de fournir au système, pour chaque objet répliqué,
un gestionnaire des réplicats garantissant les propriétés
attendues. L'environnement Core (voir §) fournit une
bibliothèque de gestionnaires garantissant les propriétés les
plus couramment demandées par les applications. C'est dans cette
bibliothèque que les applications vont piocher les bons
gestionnaires qu'elles passent ensuite au système. Tous les
gestionnaires offrent une interface générique. Cette généricité
permet aux programmeurs d'applications de pouvoir changer de
gestionnaire aisément si les conditions ayant prévalu au choix
d'un ensemble de propriétés ne sont plus réunies. Un
environnement de programmation d'objets répliqués mettant en
oeuvre ces principes a été développé (cf. §
).
Nous avons construit un système de cache réparti flexible, destiné à améliorer la qualité de service offerte aux applications coopératives au-dessus de la Toile. Le coeur de ce système de cache de grande échelle est composé d'un outil de configuration et d'un protocole de cohérence faible adapté aux spécificités de nombreuses applications coopératives de grande échelle.
Nous avons développé un outil qui permet, grâce à des simulations guidées par des traces, d'évaluer la qualité de service obtenue pour une configuration donnée (c'est-à-dire la rapidité d'accès et la cohérence des données). L'administrateur peut ainsi simuler différentes configurations pour choisir celle qui répond le mieux à ses attentes.
Cette année a été consacrée au développement du système de simulations et à la collecte des traces qui seront utilisées en entrée du simulateur. Nous avons également identifié les principales métriques pertinentes. La phase de mise en place du simulateur et de récolte de données est à présent terminée. Nous commençons les simulations proprement dites. Le cas particulier en cours d'étude est celui de l'INRIA.
La recherche d'un document dans le groupe exploite un répertoire de localisations, répliqué dans chaque cache. Les mises à jour nécessaires pour maintenir les différents réplicats cohérents sont réalisées en tâche de fond. Chaque membre du groupe continue à fonctionner et à servir ses clients, même s'il est isolé du reste du groupe. Cette autonomie permet de tolérer les arrêts volontaires ou involontaires de n'importe lequel des caches.
Le protocole de coopération de Relais exploite les caractéristiques du Web pour garantir des propriétés de cohérence sans payer le coût insupportable de la cohérence forte dans un système de grande échelle
Un premier prototype du système de cache Relais a été réalisé
et déployé dans plusieurs projets à Rocquencourt (cf. §).
A partir des travaux sur les Chaînes de PSS déconnectables, nous avons orienté nos recherches vers le support aux applications. Les environnements mobiles nécessitent en effet des mécanismes système flexibles, permettant aux applications de s'adapter aux variations de l'environnement, et aux utilisateurs de disposer de façon transparente de leur environnement de travail habituel. En outre, les données doivent impérativement rester disponibles, et ce même en présence de déconnexions.
Les résultats de cette étude nous conduisent à fournir des mécanismes système d'accès et de réplication des objets basés sur les Chaînes de PSS. Les applications qui utilisent ces mécanismes sont déchargées de la gestion des problèmes de déconnections, de disponibilité des données, de cohérence et de résolution des conflits dûs à des mises à jour concurrentes.
L'année passée avait vu la création d'un prototype partiel des Chaînes de PSS déconnectables, suivi de mobile et découverte de ressources. Cette année, la mise oeuvre d'un nouveau prototype a débuté, dans un langage de plus haut niveau, Objective-Caml. Ce prototype se verra intégrer les protocoles d'accès et de réplication des objets ou de gestion de la cohérence et de la résolution de conflit.
Les applications de ces mécanismes comprennent un service de caches World-Wide Web coopératifs, un calendrier réparti, et un gestionnaire de courrier électronique réparti que nous détaillons maintenant.
Les utilisateurs d'un système de courrier électronique, qui disposent de plusieurs boîtes aux lettres, éventuellement répliquées, souhaitent voir les modifications apportées sur un site répercutées sur tous les autres. Ceci est aujourd'hui mal supporté, tout particulièrement pour les utilisateurs de machines mobiles.
Le protocole de réconciliation des différents réplicats de boîtes aux lettres tire parti des études sur la cohérence faible. Il tient compte de la sémantique des messages, entre autres pour éviter toute recopie inutile et est basé sur l'échange de séquences de code Java à exécuter à distance. La connexion permanente des clients n'est pas exigée, autorisant ainsi la déconnexion et la mobilité. La réconciliation des mises à jour concurrentes sur des sites distincts est supportée.
Le but de l'action MVV (Machine Virtuelle Virtuelle) est de promouvoir la recherche en système d'exploitation, en langages informatiques et en intéropérabilité (entre les composants logiciels d'un environnement centralisé ou réparti) pour les besoins applicatifs de haut niveau actuels et futurs.
La MVV vise à fournir un environnement d'exécution modulable et spécialisable [14]. L'environnement de base est indépendant des langages de programmation, et supporte l'exécution d'une variété de langages «bytecodés» sous la forme de «MVlets» chargeables dynamiquement. Chaque MVlet définit le jeu d'instruction de la machine virtuelle, les fonctions de bases, le modèle de représentation de la mémoire et des objets, etc. pour un langage de haut niveau particulier.
La MVV fonctionne en transformant dans sa représentation interne de bas niveau tous les éléments spécifiques à un langage. Cette transformation permet dans le même temps d'optimiser le code et de vérifier sa sûreté. Un résultat significatif de cette transformation est que les programmes (ou composants logiciels) écrits dans des langages différents peuvent intéropérer. La compilation des définitions d'une «MVlet» permet de réaliser une machine virtuelle modifiable à la demande pour les besoins des applications embarquées ou réparties.
Des expériences préliminaires ont été conduites pour démontrer la validité de notre approche. Notre prototype de MVV peut exécuter une application numérique «byte-codée» à environ 60% de la vitesse du programme équivalent écrit de manière optimisé en C. Quelques-unes des techniques de MVV ont été appliquées à la machine virtuelle d'Objective Caml. Les gains en performances obtenus varient de 30 à 70 % en fonction des applications tests utilisées.
Nous collaborons avec les projets CRISTAL et COMPOSE et avec le LIP6 de l'Université de Paris 6.