Projet Sirac

previous up next contents
Précédent : Présentation générale et objectifs Remonter : Projet SIRAC, Systèmes Informatiques Répartis Suivant : Grands domaines d'application



Fondements scientifiques

 

Construction d'applications réparties

  Mots-clés : programmation constructive, composants, objets, agents, intégration d'applications, configuration, appel de procédure à distance, code mobile


Résumé : Le thème de la construction d'applications réparties est développé selon deux axes principaux.

1.
Programmation constructive. Étude des méthodes et outils permettant de décrire, de construire, et de faire évoluer des applications réparties organisées comme un ensemble de composants interconnectés. Un accent particulier est mis sur la réutilisation et l'adaptation des applications existantes.
2.
Code mobile. Étude des méthodes et outils permettant d'exploiter les techniques de mobilité du code pour développer des applications réparties sur l'Internet. Le travail porte sur le support d'exécution et sur la protection.

Les classes d'applications visées sont celles présentant des besoins importants de coordination d'activités et de partage d'information.


Une application informatique est dite répartie lorsqu'elle met en jeu des parties qui s'exécutent sur plusieurs machines reliées par un système de communication. Les premières applications réparties ont été développées en utilisant directement les mécanismes de bas niveau fournis par le système de communication, c'est-à-dire essentiellement les messages. À partir de ce stade initial, les efforts ont principalement visé à

Les objectifs c) et d) sont des exigences de génie logiciel qui ne sont pas propres à la programmation répartie, mais qui sont plus difficiles à satisfaire dans ce contexte qu'en milieu centralisé.

Une étape importante pour les objectifs a) et b) a été l'introduction de l'appel de procédure à distance [BN84]. Ce mécanisme permet de réaliser des applications selon le schéma client-serveur, qui reste le plus utilisé pour la structuration des applications réparties. L'étape ultérieure, à partir du milieu des années 1980, a été l'introduction des modèles à objets pour la programmation répartie. Les efforts ont porté d'une part sur le mode d'expression (langages et outils divers pour la programmation à base d'objets répartis), d'autre part sur les mécanismes de base (au niveau du système d'exploitation et des communications) permettant de mettre en oeuvre des objets répartis. Le projet Guide (dont est issu le projet Sirac) a apporté sa contribution à ces efforts : langage [2], support d'exécution ([1], [4]). Une rétrospective de ces contributions est donnée dans [10]. Des approches similaires ont été suivies par la communauté scientifique, parmi lesquelles on peut citer le projet Spring [MGH$^{+}$94]. Ces recherches ont conduit au développement de la norme d'interconnexion Corba dans un premier temps, et à l'émergence du langage Java dans un deuxième temps. Dans ces approches, qualifiées d'intégrées, le système est vu comme le support d'exécution du langage de programmation répartie. L'expérience d'utilisation de ces systèmes a montré que les objectifs a) et b) étaient remplis de façon très satisfaisante pour des applications nouvelles développées en utilisant le modèle d'objets défini par le langage adopté. En revanche, leur utilisation à grande échelle se heurte à quelques obstacles de fond tels que : l'adoption d'un langage nouveau, l'intégration de modules logiciels existants, la nécessité d'installer le support d'exécution sur toutes les machines du système réparti, et l'administration des applications. Ce dernier aspect met en évidence une limitation inhérente aux approches fondées sur les objets et le chargement dynamique de code. En effet, la notion même d'application est difficile à définir précisément car cela requiert d'identifier les objets qui composent une application. La procédure d'installation (on parle aussi de déploiement) de ces objets sur les sites qui composent le système réparti est également un problème difficile.

Ces observations ont conduit la communauté scientifique à aborder la construction des applications réparties d'un point de vue plus macroscopique (programming in the large). Une application est vue comme un assemblage de composants (modules logiciels écrits dans un langage quelconque), dont certains peuvent être des applications existantes. Un formalisme, indépendant des langages de programmation, permet de décrire les modules qui composent une application et les liens entre ces modules. On dénote ces formalismes sous le terme générique de langage de configuration ou encore de langage de description d'architecture. Les travaux précurseurs de cette approche sont issus des projets Conic [KMS89] et Polylith [Pur94]. Les recherches s'orientent aujourd'hui dans deux directions : a) des travaux à caractère fondamental portant sur les modèles de description d'application, avec le souci de fournir un support pour le contrôle de la correction sémantique des applications (modèle d'exécution, compatibilité des types dans les interactions entre modules, etc.); b) des travaux à caractère plus appliqué portant sur les outils de génération de code et d'administration des applications.

La contribution du projet Sirac s'inscrit dans ce dernier courant et concerne, de façon plus générale, des outils de configuration d'applications. Le terme configuration est pris ici dans une double acception : au sens du génie logiciel, il s'agit de définir les modules logiciels qui composent une application et de fournir en résultat le code exécutable de cette application; au sens ``administratif'' du terme, il s'agit de faciliter l'installation des modules sur les sites d'exécution et de contrôler l'évolution ultérieure de la configuration de l'application. Ces outils sont intégrés au sein d'un environnement de développement, Olan [3], dont il existe aujourd'hui une version expérimentale pour des plates-formes Unix (cf [*]).

Une application répartie est un assemblage de composants; le modèle décrit ces composants et les liens existant entre eux. La description d'un composant distingue son interface et son implémentation. L'interface décrit les services fournis par le composant et les conditions requises par son utilisation, et comporte un ensemble d'attributs utilisés pour le contrôle et l'administration du composant. Les composants peuvent être primitifs, encapsulant un module logiciel (par exemple une application existante ou une bibliothèque) écrit dans un langage de programmation quelconque, ou complexes, c'est-à-dire construits comme une hiérarchie de composants interconnectés. La description des liens entre composants repose sur le concept de connecteur, trait d'union entre la description d'un service requis par un composant et celle d'un service fourni par un autre composant. Le protocole de communication, la correspondance des types des paramètres, et les conditions d'exécution (synchronisation, droits d'accès, etc.) sont des éléments attachés à la description d'un connecteur.

En ce qui concerne les perspectives de recherche dans le domaine de la construction d'applications réparties, nous avons privilégié deux directions, que nous résumons brièvement.

1.
Intégration, extension, et configuration d'applications. Il existe des besoins importants pour l'évolution et l'administration des applications existantes. Parmi les problèmes auxquels sont confrontés les concepteurs d'application aujourd'hui, on peut citer : le besoin d'adapter à un environnement réparti une application initialement conçue dans un cadre centralisé; ou encore le besoin d'ajouter de nouvelles fonctions à une application existante sans remettre en cause sa structure globale. On recherche donc des méthodes permettant une évolution incrémentale en vue de réduire les coûts et de maintenir la continuité du service. D'une manière plus précise, la reconfiguration d'une application [rec93] recouvre les aspects suivants : l'introduction de nouveaux composants, la suppression des composants inutilisés, le remplacement de composants existants, la migration vers un autre site de certains composants (régulation de charge ou arrêt du site). Si certaines actions peuvent être effectuées lors de l'arrêt de l'application, il est parfois nécessaire de reconfigurer celle-ci dynamiquement, le service devant être maintenu.

Une méthode pour réaliser l'évolution incrémentale consiste à interposer dans le schéma global de l'application (supposée décrite par un modèle à composants) des entités réactives (``agents'') chargées d'intercepter des événements significatifs (par exemple en analysant le contenu d'un message ou les paramètres d'un appel de fonction) et d'y réagir de manière appropriée. Une expérience préliminaire (cf [*]) menée dans l'environnement Olan a permis de montrer la viabilité de cette démarche.

2.
Applications réparties sur l'Internet. Le potentiel de l'Internet est surtout utilisé pour l'accès à l'information (notamment via le Web), mais relativement peu comme environnement d'exécution d'applications. À côté du modèle client-serveur, le plus largement utilisé, on voit apparaître des travaux explorant d'autres modèles, fondés notamment sur la mobilité du code [Tho97]. Ces modèles bénéficient aujourd'hui d'un regain d'intérêt comme en témoigne le développement du langage Java [AG96]. Leur mise en oeuvre pose de nouveaux problèmes de sécurité et de gestion globale des données et des activités.

Le langage Java possède les propriétés intéressantes des langages de programmation d'applications réparties cités précédemment (séparation type-classe, sous-typage, expression de la synchronisation, liaison dynamique, etc.). Un certain nombre des inconvénients associés à ces langages ont disparu du fait de l'existence d'une machine virtuelle ``normalisée'' [LY96]. C'est pourquoi l'idée d'un système d'exploitation adapté à la gestion d'objets Java a refait surface sous la forme du système JavaOS [Rit97], disponible sur machine nue, et conçu comme un noyau de système pour l'exécution de la machine virtuelle Java. L'expérience récente du projet Guide, dont on rappelle qu'il était fondé sur des principes de structuration et une architecture très proches de Java, nous conduit naturellement à explorer les principes de réalisation d'un système de gestion d'objets Java répartis et partagés (cf [*]). Le bénéfice attendu de ce travail est la possibilité de réaliser, à l'aide du langage Java, des applications mettant en jeu des objets partagés et répartis sans souci de la localisation des objets (transparence de la distribution).

Un fil directeur commun aux deux directions ci-dessus pourrait être la notion d'agent, définie comme entité autonome pouvant réagir à des événements et pouvant éventuellement se déplacer. La mise en oeuvre d'applications à base d'agents suscite un grand intérêt [ic997], et soulève des problèmes d'environnement de programmation, de support d'exécution, et de sécurité.

Support système pour serveurs d'information

  Mots-clés : gestion de mémoire, grappes, clusters, protection, capacités, gestion de caches, mémoire virtuelle répartie


Résumé : Les recherches visent à exploiter le potentiel des grappes de machines (clusters) pour la construction de serveurs d'informations. Trois aspects sont particulièrement explorés.

1.
Gestion des ressources. Étude des politiques de gestion de ressources (notamment de gestion de mémoire) permettant de fournir une interface simple aux applications tout en garantissant des performances acceptables.
2.
Communication à hautes performances. Construction de services système permettant d'exploiter le potentiel des réseaux d'interconnexion à haut débit et faible latence, pour la coordination d'activités et le partage d'information.
3.
Protection. Étude des politiques et mécanismes de protection permettant de gérer des données partagées entre des applications, avec des contraintes de méfiance mutuelle.


Un nombre croissant d'applications font appel à des serveurs devant manipuler des volumes d'information très importants pour fournir des services à un grand nombre de clients. Des exemples en sont les bases et entrepôts de données, les serveurs pour le Web (serveurs primaires et serveurs de caches), les serveurs répartis de fichiers.

Pour répondre à ces besoins, on voit se développer des architectures en grappes (clusters) regroupant un ensemble de serveurs homogènes reliés par un réseau à hautes performances. Les avantages attendus sont les suivants.

Le développement du logiciel de base pour l'exploitation des machines en grappes demeure une tâche difficile. Les recherches actuelles visent à exploiter au mieux les possibilités de la technologie, et notamment les deux avancées suivantes.

Les principales directions de recherches actuellement poursuivies sont indiquées ci-après.

Gestion des caches

Les caches logiciels constituent le moyen privilégié de réduction de la latence pour l'accès à l'information dans un système réparti. Un cache est une zone de mémoire dans laquelle sont conservées les informations ayant fait l'objet d'accès récents. Comme les applications présentent en général la propriété de localité de référence, les informations en cache ont une probabilité élevée d'être réutilisées.

Dans un système de gestion de mémoire pour grappe de machines, chaque machine gère son propre cache, et il se pose alors deux problèmes.

Les problèmes de cohérence de cache ont été beaucoup étudiés dans les travaux sur les multiprocesseurs et sur la mémoire virtuelle répartie. Il est très coûteux de maintenir une cohérence stricte, mais, en fait, de nombreuses applications peuvent se contenter d'une cohérence relâchée, dont il existe plusieurs définitions. Les meilleurs résultats sont obtenus quand on peut relier la définition de la cohérence à celle de la synchronisation pour l'accès aux variables partagées, et, plus généralement, quand on peut prendre en compte les besoins spécifiques d'une application.

En ce qui concerne la gestion de l'information dans les caches, une voie explorée est celle des caches coopératifs [DWAP94]. L'idée consiste à utiliser les informations présentes dans les caches des machines distantes, sachant qu'il peut être plus rapide de charger une information depuis le cache d'une autre machine que depuis le disque local. En poursuivant sur cette voie, on arrive à la notion d'un service de gestion de mémoire gérant globalement l'ensemble des caches comme une ressource unique. Un exemple de tel service est GMS [FMP$^{+}$95].

Une autre voie pour l'amélioration de l'efficacité des caches est celle du préchargement. Néanmoins, cette technique doit être utilisée à bon escient, car les erreurs de préchargement sont très coûteuses. Une idée prometteuse est celle du préchargement sur information [PGG$^{+}$95] : les applications fournissent des informations sur leurs accès aux données (données utilisées, corrélations entre données, durées de vie probable, etc); ces applications sont exploitées pour le préchargement et la conservation en cache des informations.
La contribution du projet Sirac à ces travaux est le mécanisme de cohérence ``sur mesure'' [11] introduit dans la gestion des caches du service de mémoire répartie Arias (voir [*]). Plutôt que d'imposer une politique prédéfinie pour la gestion de la cohérence des caches, il est proposé un ensemble de primitives à partir desquelles on peut construire un protocole spécifique adapté aux besoins d'une application. Initialement introduits pour la gestion de la cohérence, les protocoles spécifiques sont également utiisés pour la gestion des données permanentes. Leur champ d'application pourrait être étendu au préchargement des données et à la gestion coopérative des caches.

Protection

La gestion de données partagées entre plusieurs applications, sur une ou plusieurs machines, pose le problème de leur protection. Ce problème est d'autant plus difficile à résoudre que le degré de couplage entre applications est fort, ce qui est le cas dans les systèmes répartis actuels. Deux exemples de couplage fort sont l'implantation de données dans une mémoire virtuelle partagée répartie, et l'utilisation de programmes exécutables mobiles chargés depuis une machine distante et accédant à des données locales. Dans ces deux cas, le système de protection doit permettre la coopération, tout en répondant à des exigences de méfiance mutuelle (situation où deux entités coopèrent, chacune protégeant ses données contre les erreurs ou malveillances de l'autre).

Des mécanismes à base de capacités logicielles ont été proposés depuis longtemps pour assurer la protection avec méfiance mutuelle. La transmission de capacités entre domaines de protection permet de modifier dynamiquement les droits d'accès. Les capacités ont récemment été réintroduites dans les systèmes répartis (voir par exemple [CLFL94]). L'inconvénient des mécanismes courants est qu'ils obligent les programmes d'applications à manipuler directement les capacités, ce qui rend ces programmes difficilement modifiables et réutilisables.

La contribution de Sirac à ce problème est la proposition d'utiliser des capacités logicielles ``cachées'' [5], c'est-à-dire non visibles dans les programmes des applications. L'association des capacités aux programmes se fait par des annotations ajoutées à un langage de définition d'interfaces. Ce mécanisme a pu être validé par des expériences menées dans trois environnements répartis différents (voir [*], [*]).

Réseaux de stations

Les avantages attendus des grappes de machines nécessitent un mécanisme d'interconnexion à hautes performances. Un débit élevé est nécessaire quand un volume important d'information doit être transféré; une latence faible est nécessaire pour des échanges fréquents de faible volume comme les messages de commande utilisées pour la gestion interne du système.

Plusieurs technologies de réseaux d'interconnexion sont récemment apparues et sont expérimentées. Citons ATM, Myrinet, MemoryChannel. Elles utilisent des techniques de commutation, ce qui assure une bonne capacité de croissance. Le problème principal est la conception et la réalisation d'un service de communication logiciel qui permette, au niveau des applications, d'exploiter aux mieux les performances brutes autorisées par le matériel.

La technologie SCI (Scalable Coherent Interface) repose sur un couplage direct de mémoire à mémoire entre deux machines. Ce dispositif permet à un processeur de lire et d'écrire physiquement dans la mémoire d'un autre processeur sans l'interrompre. Par rapport à d'autres systèmes d'interconnexion, SCI fournit des performances brutes élevées, tant en débit qu'en latence.

Le projet Sirac a récemment lancé une action de recherche visant à explorer le potentiel de SCI pour la réalisation de grappes de serveurs à hautes performances. Le problème posé est celui de la réalisation de services de base pouvant être intégrés à un système d'exploitation, pour réaliser le partage de mémoire et la synchronisation d'activités. Il est prévu d'utiliser des techniques inspirées de celles de GMS (cité plus haut) pour la gestion globale de la mémoire de la grappe. Les classes d'applications visées sont celles qui nécessitent l'accès efficace à de grandes quantités d'information (serveurs Web, systèmes de fichiers). Le plan de travail proposé est indiqué en [*].

Gestion de la mobilité dans l'Internet

  Mots-clés : réseaux sans fil, stations mobiles, IP mobile, qualité de service


Résumé : L'objectif de cet axe de recherche est de développer des protocoles et des services systèmes pour exploiter au mieux les capacités des réseaux sans fil dans le but de fournir l'accès à l'Internet depuis des postes mobiles.


Le développement rapide de la téléphonie mobile présage une nouvelle ère : comme beaucoup l'annoncent déjà, le 21ème siècle sera celui des services mobiles. Il sera bientôt possible, à partir d'une machine portable équipée d'une antenne, de se connecter à l'Internet pour y réserver un billet d'avion, pour lire son courrier électronique, ou pour chercher une information sur le Web, tout en se déplacant à travers le monde. Très probablement, ces connexions n'utiliseront pas un unique réseau homogène, mais plutôt une combinaison de réseaux de différents types (GSM, CDPD LAN sans fil, Metricom, réseaux satellitaires, etc.) constituant globalement un ``réseau mobile virtuel''. Du fait que les différents réseaux physiques sont fondés sur des technologies variées, les caractéristiques (bande passante, délai de transmission, gigue, taux de perte, etc.) de ce réseau virtuel sont très variables. Cette hétérogénéité pose de nouveaux types de problèmes du point de vue des services de communication et des applications.

Dans un contexte de réseaux sans fil, le projet Sirac s'intéresse plus particulièrement à la gestion de la mobilité avec, pour objectif général, l'obtention de la meilleure qualité de service (QoS) possible pour l'utilisateur par l'optimisation des ressources du réseau virtuel en termes de coût et d'efficacité. Sous le terme de station mobile, on désigne une station qui change de point de connexion. Le changement de point de connexion peut prendre plusieurs formes : changement des paramètres réseau, tels que l'adresse ou les tables de routage, changement de la nature de la liaison (GSM, WLAN, satellitaire, fixe, etc.). Ces évolutions doivent se faire avec l'objectif de fournir à l'utilisateur un service aussi continu que possible.

Il y a plusieurs manières d'aborder ce problème selon qu'on privilégie la transparence vis-à-vis des changements de réseau ou l'efficacité globale. Par ailleurs, le support de la mobilité peut être mis en oeuvre à divers niveaux des systèmes de communication : couche réseau (IP), couche transport (TCP, et application. Ces approches ne sont pas exclusives les unes des autres et peuvent être combinées au sein d'une solution globale du problème de la gestion flexible de la mobilité.

Afin d'aborder ces problèmes dans un ordre croissant de complexité, le projet Sirac étudie dans un premier temps des solutions applicables au niveau IP. Le protocole Mobile IP, défini par l'IETF (Internet Engineering Task Force), permet à un utilisateur de rester accessible et connecté à l'Internet quelle que soit sa localisation physique. La solution adoptée dans Mobile IP consiste à définir un lien de poursuite sur le site d'origine, chargé de rediriger les paquets reçus vers le point d'attachement courant de la station mobile. Cette solution simple ne fournit pas la flexibilité requise pour assurer une utilisation optimale des services et ressources disponibles sur une large variété de réseaux sans fil. Deux propriétés nous paraissent importantes pour atteindre l'objectif de flexibilité : d'une part la possibilité de s'adapter aux caractéristiques du réseau utilisé, et d'autre part la capacité d'utiliser plusieurs interfaces de réseau simultanément. Dans sa définition actuelle, Mobile IP ne permet l'utilisation que d'un seul réseau à un instant donné. Cette limitation est trop restrictive dans un environnement où la diversité des services ne fait que croître. Nous pensons qu'un utilisateur mobile devrait pouvoir utiliser différents services et réseaux pour chacun des flots de ses applications, le choix d'un système de communication pouvant être dicté par des considérations de performance ou de coût.

La gestion des stations mobiles dans l'Internet est une problématique relativement récente. Des solutions assez différentes sont explorées par diverses équipes de recherche, principalement aux USA. Le projet Barwan de l'université de Berkeley fonde son approche [SK97]sur le déploiement de stations de base pour le contrôle de la mobilité. C'est une solution que nous avons rejetée car elle n'est pas compatible avec les infrastructures disponibles actuellement en Europe. Le projet MosquitoNet [CB96] de l'université Stanford a développé un système qui permet à une station mobile de choisir l'interface réseau d'émission en un point donné. Ce système constitue le point de départ de notre étude qui vise à l'étendre en donnant la possibilité de gérer simultanément plusieurs interfaces réseau pour différents flots de données. La réalisation de cet objectif requiert, d'une part l'extension des fonctions du protocole Mobile IP, et d'autre part la conception de services systèmes permettant d'identifier les réseaux disponibles, leurs caractéristiques et de sélectionner le ou les réseaux les mieux adaptés aux qualités de services requises par les différentes applications.




previousup next contents Précédent : Présentation générale et objectifs Remonter : Projet SIRAC, Systèmes Informatiques Répartis Suivant : Grands domaines d'application