Fondements scientifiques

Le partage de l'information en réparti

Résumé : Une des fonctions principales d'un système informatique est le partage de l'information entre utilisateurs et entre programmes. Or, les ordinateurs d'un système réparti ne partagent pas de mémoire. Ils peuvent communiquer par messages, mais ceux-ci sont coûteux et d'utilisation complexe. La réplication des données s'impose donc, mais celle-ci pose des problèmes fondamentaux. Ajouté à la difficulté inhérente au parallélisme, tout cela rend fort difficile l'écriture de programmes répartis. La recherche des solutions efficaces aux problèmes liés au partage d'information, notamment dans les systèmes de grande échelle, est au centre des activités du projet SOR.

La réplication de données et la cohérence

Considérons des objets, désignés par des références, et accédés par invocation de leurs méthodes. On peut rendre une référence à un objet distant, et l'appel de ses méthodes, indifférenciables du cas local grâce à un objet d'indirection, dit souche ou mandataire [6]. Ce schéma dit d'invocation distante permet bien le partage transparent des objets; c'est celui qui est utilisé dans Corba [DHH $^{+}$ 91] et Java RMI [WRW96].

Mais l'invocation distante est coûteuse, et ne passe pas à l'échelle si l'objet partagé constitue un goulot d'étranglement. De plus, si ce schéma simplifie la communication, il ne résout pas les problèmes plus profonds de la répartition: parallélisme, défaillances, coûts, etc.

Le coût de l'accès distant et la présence de ressources matérielles abondantes condui-sent naturellement à gérer des copies, ou réplicats, de la donnée distante. La réplication augmente la disponibilité des données. Lorsque les données sont accédées en lecture, elle élimine les goulots d'étranglement. Si une donnée répliquée est modifiée, les autres réplicats deviennent incohérents, et il faut propager la mise à jour. La réplication à grande échelle rencontre une contradiction majeure: assurer la cohérence des réplicats tout en conservant des performances acceptables. Un protocole de cohérence fort [LH89] est simple mais ne passe pas à l'échelle, d'où des recherches actives sur des cohérences affaiblies [KCZ92,GC89,BZ91,GL91]. Il y a lieu de rechercher un compromis entre contraintes de cohérence, tolérance aux fautes et performances. Malheureusement, aucun compromis ne satisfait les attentes de toutes les applications.

Nos recherches dans ce domaine concernent d'une part, les moyens offerts aux programmeurs pour exprimer les compromis qui répondent le mieux à leurs attentes et d'autre part, des modèles de cohérence faible pour nos applications cibles (voir § et §).

Persistance et ramasse-miettes

La réplication facilite le partage des données entre programmes s'exécutant en parallèle. Si ceux-ci ne s'exécutent pas en même temps, il y a besoin de données «persistantes», conservées par une exécution en vue d'utilisation ultérieure par une autre. La persistance est le complément indispensable du partage de données, aussi bien pour les tâches quotidiennes comme le traitement de texte, que pour des applications émergentes telles le travail coopératif. Le meilleur modèle est la «persistance par atteignabilité», où un objet est persistant si et seulement si il est atteignable depuis une racine. Ce modèle exige un ramasse-miettes.

Pourtant, l'importance de la persistance est généralement négligée par la communauté des systèmes répartis. Les programmeurs ont l'habitude de la gérer manuellement (grâce aux systèmes de fichiers ou aux bases de données) et les algorithmes de ramasse-miettes répartis sont mal connus. Pour le projet SOR il s'agit d'un axe central (§) dans lequel nous avons une avance certaine [1,4,5].

La grande échelle

Les problèmes ci-dessus se compliquent encore dans les systèmes de grande échelle, se caractérisant soit par une grande dispersion géographique, soit par un grand nombre d'objets. Un algorithme satisfaisant sur réseau local fonctionnera souvent mal à grande échelle. De plus, un tel système est foncièrement hétérogène: considérons la variation de vitesse de communication, de capacité mémoire et de puissance d'UC entre un téléphone portable branché sur Internet par GSM et un gros serveur sur réseau ATM. Les politiques d'administration et de protection induisent des discontinuités dans le réseau. Clairement donc, les solutions système ne peuvent pas être les mêmes partout. Le programmeur d'application exige néanmoins une apparence d'uniformité, ce qu'on appelle la transparence. Une des forces du projet SOR est la réconciliation entre transparence et adaptabilité [3] (voir §

Notes:

...distante: Si le système crée automatiquement des réplicats distants au fur et à mesure des accès, dans une mémoire tampon invisible, on appelle cela un cache. Si toute la mémoire est gérée de cette façon, on parle d'une mémoire répartie virtuellement partagée ou MRVP.

Précédent : Présentation générale et objectifs Remonter : Projet SOR, Systèmes Objets Répartis Suivant : Grands domaines d'application