Gestion de la cohérence des données dans les systèmes distribués

Gestion de la cohérence des données dans les systèmes distribués Étude bibliographique Loïc Cudennec loic.cudennec@ens.insa-rennes.fr Superviseurs : Gabriel Antoniu, Luc Bougé, Sébastien Monnet {Gabriel.Antoniu,Luc.Bouge,Sebastien.Monnet}@irisa.fr INSA, IFSIC, IRISA, Projet Paris Février 2005 Mots clés : cohérence des données, mémoire virtuellement partagée, pair-à-pair, tolérance aux fautes, juxmem. Résumé Ce rapport présente l état de l art dans le domaine du partage de données en environnement distribué. Les concepts de mémoire virtuellement partagée, modèle de cohérence, réseau pair-à-pair et tolérance aux fautes y sont développés afin de comprendre les mécanismes pouvant être mis en jeu sur une architecture de type grille. Le service JuxMem de partage de données pour les grilles est introduit comme une synthèse des notions présentées dans ce rapport. Étude bibliographique, stage M2RI IFSIC, Université de Rennes 1.

Table des matières 1 Introduction 2 2 Systèmes à MVP : accès transparent aux données 3 2.1 Modèles et protocoles de cohérence......................... 3 2.1.1 Modèles de cohérence forte......................... 4 2.1.2 Modèles de cohérence relâchée....................... 4 2.1.3 Modèles pour grappes de grappes..................... 5 2.2 Granularité....................................... 5 2.3 Localisation des données............................... 5 3 Systèmes PàP : dynamicité et passage à l échelle 6 3.1 Généralités....................................... 6 3.2 Architecture générique des systèmes PàP..................... 7 3.3 Localisation et routage................................ 8 3.4 Gestion des données................................. 10 3.5 Gestion de la cohérence............................... 10 4 Systèmes distribués tolérants aux fautes 11 4.1 Classification des fautes............................... 12 4.2 Protocole de communication de groupes...................... 13 4.2.1 Protocole de composition de groupes................... 13 4.2.2 Diffusion atomique.............................. 14 4.2.3 Consensus................................... 14 4.2.4 Détecteurs de fautes............................. 14 5 Synthèse : un service de partage de données pour la grille 15 5.1 Approche : partage transparent des données................... 15 5.2 Architecture de JuxMem............................... 16 6 Conclusion 17

1 Introduction De tout temps l homme a voulu construire l ordinateur le plus puissant du monde. Une méthode simple vouée à la quête de ce Graal consiste à mettre en commun les ressources de sites géographiquement distants. Les systèmes distribués utilisent donc la puissance de calcul et l espace de stockage de plusieurs unités de traitement interconnectées par des réseaux. Leur taille peut aller du plus petit système composé de deux entités aux millions de nœuds que forment le réseau internet. Déployer des applications sur les systèmes distribués n est pas sans poser de nouveaux problèmes autour des méthodes de programmation classiques. L ordinateur tel qu il est défini en 1946 par le mathématicien Von Neumann est principalement composé d une unité de commande ainsi que d une mémoire locale contenant les instructions et les données. Dans ce modèle, le partage de ressources avec un autre ordinateur ne s effectue pas de manière transparente et les instructions d accès aux données distantes ne sont pas les mêmes que pour les données locales. La tâche du programmeur se voit alors complexifiée par la gestion des messages de communication propres aux systèmes répartis. Pour faciliter le développement d applications sur les systèmes distribués, de nombreuses recherches portent sur les mécanismes permettant de donner l illusion au programmeur que plusieurs unités de traitement n en forment qu une : c est le système à image unique. Dans un tel système, le programmeur ne peut plus faire d hypothèses sur l emplacement physique des données qu il manipule. A charge donc au système d effectuer pour lui la localisation et le transfert de la donnée et ce, de manière transparente. Afin d améliorer les performances d accès, les données sont couramment répliquées sur les sites effectuant une lecture ou une écriture. L affaire se complique lorsque deux processus distants, dont au moins un écrivain, veulent accéder à une même donnée. Des scénarios équivalents entraînent souvent la création, à un instant donné, de versions différentes d une donnée sur des sites différents. La question de la cohérence des données est alors soulevée. Les systèmes à mémoire partagée (MVP) s annoncent comme une réponse adaptée à des environnements regroupant quelques dizaines de nœuds. Elles offrent la possibilité de partager des données sur des grappes de calculateurs de manière transparente. A cette échelle, un nombre important de modèles et protocoles de cohérence ont pu être mis en œuvre de telle sorte que les réplicas soient gérés efficacement. Si ce modèle a fait ses preuves à petite échelle, il faut admettre qu il n est pas adapté aux environnements distribués de taille plus conséquente. Le modèle pair-à-pair (PàP), quant à lui, réussi à fédérer des centaines de milliers de nœuds essentiellement pour du partage de données. Les sites participants jouent à la fois les rôles de client et serveur, ce qui se traduit par une décentralisation forte des responsabilités. Malheureusement si le PàP est très bien adapté au passage à l échelle et à la volatilité des nœuds, la plupart des applications actuellement proposées ne traitent que du partage de données non-modifiables. Depuis quelques années déjà, les besoins en puissance de calcul ont poussé les scientifiques à fédérer les ressources de leurs universités respectives au sein du concept de grille. La grille, telle qu elle est définie dans [19], consiste en une infrastructure composée de ressources informatiques hétérogènes interconnectées par un réseau. L idée est de proposer un super-ordinateur en réunissant la puissance de calcul et l espace de stockage de sites géographiquement dispersés. Ces sites peuvent appartenir à des institutions différentes et être connectés ou déconnectés de la grille en fonction des centres d intérêt du moment. La taille d un tel système est de l ordre de la dizaine de milliers de nœuds. Les applications liées au 2

calcul scientifique et, d une manière générale, massivement parallèles, peuvent tirer parti des performances théoriques d un tel environnement. Partager des données dans les infrastructures de type grille n est pas sans rappeller les problèmes déjà rencontrés dans les systèmes à MVP, les systèmes PàP et les systèmes tolérants aux fautes. La section 2 de ce rapport s attache donc à définir les caractéristiques et la gestion de la cohérence dans les systèmes à mémoire virtuellement partagée. La section 3 introduit les propriétés du modèle pair-à-pair. La section 4 donne des éléments de compréhension sur les mécanismes mis en œuvre dans les systèmes tolérants aux fautes. En guise de synthèse, et pour définir le cadre du sujet de stage, la section 5 de ce rapport propose une présentation succincte de JuxMem, un service de partage de données pour les grilles. 2 Systèmes à MVP : accès transparent aux données Les systèmes à MVP 1, historiquement introduits par Kai Li [26] donnent l illusion au programmeur que plusieurs mémoires physiquement distribuées n en forment qu une. Dans ce contexte, les mécanismes d adressage classiques de la mémoire sont conservés et il est du ressort de la MVP d aller chercher les données, qu elles soient situées localement sur le site ou distantes. Il n est alors pas nécessaire d utiliser des primitives de lecture et d écriture spécialisées car la mémoire détecte les accès distants et se charge d effectuer les transferts de données. Les échanges de messages induits par la gestion de la mémoire distribuée entre les différents sites sont masqués par le système à MVP. La transparence de localisation des objets obtenue permet de conserver le modèle classique de programmation par mémoire partagée. 2.1 Modèles et protocoles de cohérence Le partage des données entre plusieurs processus exhibe le problème d ordonnancement des opérations de lecture et d écriture, c est à dire la vision que chaque processus peut avoir de l entrelacement des instructions. Ceci est d autant plus difficile à appréhender que les données peuvent être répliquées sur plusieurs sites. La mise en place d une horloge globale synchronisée sur tous les sites n est pas réalisable et la technique de l horodatage ne permet alors plus d établir une trace d exécution unique. La notion centrale dans un système distribué est le modèle de cohérence utilisé. Un modèle de cohérence s affiche comme un contrat passé entre le système et le programmeur. Il définit les critères déterminant la valeur retournée par une lecture en fonction des écritures précédentes. Il existe plusieurs modèles de cohérence appartenant aux classes de cohérence forte et relachée. Les modèles de cohérence forte ont été introduits les premiers et facilitent la vision des données fournie au programmeur. Ils imposent des contraintes importantes entre la dernière lecture et la prochaine écriture d une donnée. Cette stratégie entraîne l implémentation de protocoles complexes et extrêmement couteux en communications réseau. Afin de gagner en efficacité, plusieurs modèles de cohérence ont donné lieu à différents protocoles de cohérence. 1 Mémoire virtuellement partagée. 3

2.1.1 Modèles de cohérence forte Les modèles de cohérence forte sont caractérisés pas des contraintes fortes entre la dernière écriture et la prochaine lecture. Le modèle strict (atomic consistency) est un modèle idéal où chaque lecture rend la dernière valeur écrite dans la donnée. Dans les systèmes distribués, le protocole associé nécessite l utilisation d une horloge globale, ce qui rend son implémentation impossible. Le modèle séquentiel (sequential consistency (SC)) formalisé par Lamport en 1979 assure que chaque site voit toutes les opérations dans le même ordre. Les premières MVP, comme IVY [25], utilisent ce modèle de cohérence. [34] propose de combiner les modèles strict et séquentiel en offrant deux primitives de lecture en fonction du modèle à utiliser pour la donnée considérée. Le modèle causal (causal consistency) se base sur la relation de causalité introduite dans [23] pour déterminer un ordre entre les écritures. De nombreuses applications tolèrent que deux évènements ne soient pas vus dans le même ordre sur tous les sites. Le modèle causal permet alors de lier certains évènements entre eux par un ordre bien fondé tout en relâchant les contraintes sur les évènements indépendants. 2.1.2 Modèles de cohérence relâchée Les modèles de cohérence relâchée ont été introduits afin de diminuer le nombre d échanges réseau induit par les protocoles de cohérence forte. Ils tirent parti du fait que les applications distribuées imposent déjà un ordre sur les accès mémoire par l utilisation explicite de mécanismes de synchronisation. La technique employée consiste à retarder les mises à jour jusqu aux prochains points de synchronisation, diminuant ainsi le nombre de communications, ce qui améliore les performances générales. La cohérence faible (weak consistency) fait la distinction entre les accès ordinaires à la mémoire et les accès synchronisés. Seuls les accès synchronisés garantissent la cohérence de la mémoire partagée par l utilisation d objets de synchronisation comme les verrous ou les barrières. Ce modèle garantit que la mémoire est cohérente à chacun des points de synchronisation pendant lequels toutes les informations sont mises à jour. La cohérence à la libération (eager release consistency (ERC)) améliore la cohérence faible en ne mettant à jour que les données modifiées entre deux synchronisations. Ce modèle utilise le principe de section critique gérée par un verrou et délimitée par les primitives acquire et release. La cohérence de la mémoire est assurée par la propagation vers les autres sites des modifications effectuées sur la donnée dans la section critique. La particularité de ce modèle est que la mise à jour intervient lors de l appel à la primitive release. Ce protocole génère des communications inutiles vers des sites n effectuant par la suite aucun accès sur les données mises à jour. Le protocole associé est mis en œuvre dans le système à MVP Munin [12]. La cohérence à la libération paresseuse (lazy release consistency (LRC)) est une version plus relachée d ERC qui tente de réduire les communications inutiles de ce dernier. Une liste des données modifiées (write notice (wn)) est envoyée au site effectuant le prochain appel à la primitive acquire. Les modifications ne s appliquent alors que sur 4

ce site et uniquement lors de l accès en lecture ou écriture à une donnée déclarée modifiée dans wn. Le protocole a été proposé avec le système à MVP Treadmarks [3]. Une variante de ce modèle peut-être obtenue en utilisant un nœud de référence chargé de la gestion d un sous-ensemble des données. Cette technique est appellée home-based lazy release consistency (HLRC) [39]. La cohérence à l entrée (entry consistency (EC)) proposée par le système à MVP Midway [10] tente de limiter les effets du faux-partage (section 2.2) apparaissant dans LRC en associant à chaque variable partagée un objet de synchronisation. L établissement de cette relation est laissée à la charge du programmeur. La cohérence de portée (scope consistency (ScC)) [21] reprend le principe de l EC et tente d éviter au programmeur d effectuer lui-même l association entre verrous et données. Cette technique se base sur les instructions de synchronisation déjà présentes dans le programme. Lors de l acquisition d un verrou par un site, seules les modifications effectuées dans les portées correspondant à ce verrou sont visibles. 2.1.3 Modèles pour grappes de grappes L interconnexion de grappes entraîne l utilisation de supports réseaux hétérogènes. Les communications inter-grappes sont par nature plus coûteuses que celles disponibles sur les liens intra-grappes. L objectif principal des protocoles dédiés à ce type d environnement est de diminuer autant que possible les échanges inter-grappes. Le protocole clustered lazy release consistency (CLRC) [9] met en œuvre un système de cache au sein de chaque grappe, limitant ainsi les requêtes sur les liaisons entre grappes. Une autre stratégie est proposée par le protocole hierarchy-aware home-based release consistency (H-HBRC) [6]. Ce protocole minimise le nombre de messages sur les liens lents (intergrappes) et privilégie les requêtes d accès à un verrou en provenance des sites les plus proches en terme de performances réseau (intra-grappes). 2.2 Granularité La granularité est la taille de l unité de partage et constitue un élément déterminant dans un système à MVP. Le coût de l échange réseau incite à envoyer des messages plus gros et donc à augmenter la granularité. Cette stratégie à pour conséquence de révéler le problème du faux-partage lorsque deux sites, dont au moins un écrivain, effectuent des opérations sur deux variables logiquement indépendantes mais physiquement situées sur la même unité de partage. La taille de l unité de partage intervient principalement à deux niveaux : Le niveau MVP intègre habituellement une granularité de l ordre de la page système pour profiter des mécanismes de défaut de page. Cette technique est présente dans des implémentations comme Ivy et Treadmarks. Le niveau programmation permet, souvent grâce à l utilisation d un compilateur spécifique, de choisir la notion d objet comme granularité comme dans Munin. 2.3 Localisation des données Partager des données dans un environnement distribué pose forcément le problème de leur localisation. Des informations, attachées à chaque unité de partage, renseignent sur le 5

propriétaire courant de la donnée (owner), le site ayant la charge de gérer ces informations (manager) ou l ensemble des sites hébergeant une copie de la donnée (copyset). Plusieurs algorithmes sont proposés dans [26] pour localiser les données : Le gestionnaire centralisé est composé d un processus dédié à la gestion du partage et des objets de synchronisation comme les verrous. Les sites désirant accéder à une donnée doivent connaître le propriétaire courant et s adressent donc au gestionnaire pour localiser la copie la plus à jour ou en obtenir la charge. Lors d une écriture, le gestionnaire envoie de plus un message d invalidation aux sites détenant une copie de la donnée et déclarés dans le copyset. Le gestionnaire distribué fixe permet de répartir la charge du gestionnaire centralisé sur plusieurs sites. L ensemble des unités de partage est partionné selon un algorithme adapté aux applications des couches supérieures et la gestion de chaque partition est attribuée à un site jouant le rôle de gestionnaire centralisé pour celle-ci. Le gestionnaire distribué dynamique fait de chaque écrivain le propriétaire et le gestionnaire de la donnée modifiée. Retrouver le site ayant la charge d une donnée n est plus un problème trivial mais peut être résolu par la technique du propriétaire probable. Chaque site détient alors une estimation du propriétaire courant de la donnée et une demande d accès peut transiter de sites en sites jusqu à atteindre le véritable propriétaire. Il est prouvé dans [26] que le propriétaire d une page dans un réseau de sites est toujours retrouvé et ce, au bout d un nombre maximum de messages. Cette classification a été mise en œuvre dans Ivy à la fin des années 80. D autres techniques de localisation des données ont été introduites avec des implémentations du modèle de cohérence relâchée LRC comme Treadmarks. Les sites ne récupèrent alors plus une unité de partage complète mais la liste des différences avec leur copie. Ces informations doivent de plus être collectées à partir de plusieurs sites ayant modifié la donnée considérée. 3 Systèmes PàP : dynamicité et passage à l échelle Les systèmes à MVP ont prouvé leur efficacité à partager des données sur des environnements composés de quelques dizaines de nœuds. Avec la multiplication du matériel informatique interconnecté par des réseaux comme internet, l envie de porter des applications distribuées de partage de données sur plusieurs centaines de milliers de nœuds ouvre la porte à de nouveaux problèmes. Dans ces conditions, l algorithmique mise en œuvre par les MVP montre ses limites d extensibilité. A titre d exemple, l invalidation des toutes les copies d une donnée modifiée n est pas une stratégie raisonnable lorsque le nombre de participants devient trop important. C est en tenant compte de ces nouvelles propriétés que le modèle PàP 2 réussi le pari de passer à l échelle. 3.1 Généralités L augmentation du nombre de participants dans une application distribuée calquée sur le modèle client-serveur influe directement sur les risques de congestion du ou des sites chargés de rendre un service. Les défaillances des serveurs entraînent bien souvent l interruption complète du ou des services supportés. 2 Pair-à-pair. 6

Assurer le passage à l échelle, tel pourrait alors être le leitmotiv des systèmes PàP où le principe de décentralisation est poussé à l extrême. Chaque participant est client et serveur à la fois et n intéragit qu avec un petit groupe de pairs, définissant la notion de connaissance locale du système. Cette politique permet de décentraliser la charge et d utiliser les ressources disponibles sur les sites jusqu alors considérés comme de simples clients. Le même service peut ainsi être rendu par plusieurs nœuds, offrant ainsi des propriétés de tolérance aux fautes. Les contacts entre les sites s établissent au gré des connexions et déconnexions ainsi que des centres d intérêt définis par les applications. Les systèmes PàP sont caractérisés par : la propriété de passage à l échelle qui garantit que les performances du système ne sont pas dramatiquement affectées par l augmentation du nombre de ses participants, l extensibilité qui assure que l ajout de nouvelles ressources améliore l espace de stockage ou la puissance de calcul, l auto-organisation des nœuds pour faire face à la volatilité de l environnement et ainsi proposer des mécanismes de tolérance aux fautes, la transparence de la localisation, masquant aux applications le cheminement physique de la recherche d une donnée sur le réseau. Si il faut reconnaître que les avantages énumérés précédemment sont séduisants, le PàP souffre tout de même de plusieurs défauts inhérents à la dimension du système. A cette échelle il n est désormais plus concevable d utiliser des outils de synchronisation comme les barrières globales, au risque de perdre la propriété de vivacité. La mise en œuvre des systèmes PàP s effectue au dessus de réseaux hétérogènes présentant des performances inégales. Le matériel supportant les nœuds est bien souvent du même acabit que le simple ordinateur personnel et présente un faible MTBF 3. Les procédures de reconfiguration du réseau, et notamment des tables de routage, peuvent dégrader les performances en cas de volatilité trop élevée. Enfin, si la localisation des données s effectue de manière transparente, il ne faut pas oublier que celles-ci transitent bien souvent par des chemins non-sécurisés. La mise en place de protocoles cryptographiques, du chiffrement des données ainsi que de serveurs d authentification va à l encontre des raisons pour lesquelles le PàP s avère performant à grande échelle. 3.2 Architecture générique des systèmes PàP Depuis quelques années déjà les points communs entre les différentes implémentations des systèmes PàP font l objet d une classification au sein d un modèle en couches [15]. La figure 1 présente les quatre couches principales : La localisation et le routage permet d abstraire le support réseau physique, de localiser les données qui y sont stockées et de déterminer les sites vers lesquels un message doit transiter. La gestion des blocs se charge de dupliquer et déplacer les blocs. Le système de fichiers offre une interface standard de gestion des fichiers, découpe les données en blocs pour la couche inférieure et se charge de la mise en place du modèle de cohérence. 3 Mean time between failure. 7

applications système de fichiers et cohérence gestion des blocs de données localisation et routage FIG. 1 La pile des couches dans les réseaux PàP. La couche application est dédiée aux programmes utilisateur. Des systèmes de fichiers PàP comme Ivy [29] et CFS [14] utilisent une table de hachage distribuée (DHash) pour gérer les blocs au dessus du service de localisation Chord [37]. D autres systèmes comme Past [36] et OceanStore [22], respectivement portés au-dessus de Pastry [35] et Tapestry [38], ont fusionné les couches de routage et de gestion des blocs. 3.3 Localisation et routage La couche de routage d un réseau PàP permet d abstraire le support réseau physique et de localiser les données qui y sont stockées. La première technique de routage a été mise en œuvre par Napster [41] sur le principe de la localisation par répertoire centralisé. Un ou plusieurs serveurs sont chargés de mettre en relation les pairs en maintenant à jour une liste des ressources et des sites les hébergeant. Cette architecture souffre des lacunes du modèle client-serveur et la défaillance des quelques sites chargés de gérer les répertoires peut entraîner l écroulement du système. Afin d y remédier, Gnutella [30] a introduit le modèle de routage par répertoire distribué qui supprime la technique du serveur centralisé. Les requêtes cheminent de proches en proches, s inspirant du principe de l inondation en attribuant à chaque pair le rôle de répertoire local. Les requêtes cheminent donc de voisins en voisins jusqu à ce que la ressource soit trouvée ou que le nombre de sauts maximum ait été atteint. Si la décentralisation des responsabilités est ici totale, il faut tout de même remarquer que des ressources risquent de ne pas être visibles de certains pairs trop éloignés. Une approche mixte des deux précédentes techniques est effectuée par Kazaa [40] qui élit des superpairs comme répertoires centralisés, conférant ainsi un aspect hiérarchique au réseau. Les techniques de routage par répertoire souffrent de la multiplication des messages de communication pour atteindre un objet recherché. Le routage par contenu introduit par Plaxton [32] vise à limiter l encombrement du réseau en minimisant le nombre de sauts effectués pour trouver une donnée. Dans ce système, les nœuds et les données sont caractérisés par des identificateurs considérés uniques appartenant au même espace. Cet identificateur est calculé en appliquant une fonction de hachage du type SHA-1 4 qui assure une bonne répartition des clés et minimise ainsi le risque de collisions entre deux objets. Les clés correspondant aux données sont souvent placées sous la responsabilité du nœud ayant l identificateur numériquement le plus proche. Sur chaque nœud se trouve une table de routage permettant d aiguiller les messages vers un 4 Secure hash algorithm. 8

D971F1 D46A1C D467C4 clés : noeuds données D462BA route(d46a1c) D13DA3 65A1FC FIG. 2 Routage par contenu avec Pastry, espace de nommage. site plus proche de leur destination. Ce mécanisme de routage dépendant des clés est dit de key-based routing (KBR). Chord [37], Pastry [35] et Tapestry [38] utilisent une forme de routage hypercube généralisée avec correspondance de préfixe. C est à dire qu à la manière d une recherche par ordre alphabétique dans un dictionnaire, chaque saut effectué par un message le dépose sur un site dont l identificateur partage un préfixe commun de plus en plus long avec l identificateur destinataire et ce, jusqu à atteindre le nœud responsable de l information recherchée. La figure 2 représente l espace de nommage de Pastry dans lequel on effectue le routage d un message d accès à la donnée de clé D46A1C à partir du site 65A1FC. Il est possible qu en fonction de la configuration des tables de routage et de la connaissance locale du système propres à chaque nœud, le message soit acheminé par les sites D13DA3 et D462BA avant d arriver sur le nœud D467C4 responsable de la donnée. Ce mécanisme de routage assure que le nombre de sauts à effectuer pour atteindre une clé est de l ordre de où est le nombre de pairs dans le système et la base choisie pour la représentation des clés. Cependant un tel dispositif peut souffrir de problèmes de performance si aucune considération liée à la localité physique n est prise en compte. Pastry et Tapestry tirent parti de la latence des liens de communication pour construire les tables de routage et privilégier de bonnes performances sur les premiers sauts d un message. Par exemple, la communication entre 65A1FC et D13DA3 sera moins coûteuse que celle établie entre D462BA et D467C4. CAN [33] utilise un routage par progression et un espace cartésien multidimensionnel. La figure 3 représente un espace de nommage de type CAN de dimension dans lequel on effectue le routage d un message d accès à la donnée de coordonnées à partir du site. A chaque étape du routage le message est transmis entre pairs responsables de zones contigües jusqu à atteindre. Les arrivées et départs de nœuds s accompagnent de reconfigurations du partitionnement de l espace de nommage à l aide de 9

(a,b) (u,v) clés : noeuds données (x,y) FIG. 3 Routage par contenu avec CAN, espace de nommage. divisions et fusions de zones. Ce mécanisme de routage assure que le nombre de sauts à effectuer pour atteindre une clé est de l ordre de "!$#&%' où est le nombre de pairs dans le système et la base choisie pour la représentation des clés. 3.4 Gestion des données Le rôle principal de la couche de gestion des données est de fournir aux couches supérieures des accesseurs permettant de placer les données dans le système et de les récupérer en les désignant par la clé associée. Elle se charge également de dupliquer et déplacer les blocs stockés dans le réseau. Les mécanismes de réplication permettent de faire face à la déconnexion soudaine de certains nœuds et améliorent aussi les temps d accès aux données. On peut donc se demander où ces réplicas vont-ils être créés. La table de hachage distribuée DHash utilisée au-dessus de Chord réplique les blocs sur les sites dont les identificateurs succèdent à celui du pair responsable. La réplication des blocs est aussi mise en œuvre par Tapestry qui désigne un ensemble de pairs racine de la donnée et par Past où les blocs sont disséminés sur les voisins directs. Dans le cas d OceanStore, les réplicas sont créés ou placés près des clients en fonction des demandes d accès. Ils sont de plus auto-organisés sous forme d un arbre offrant une infrastructure pour la diffusion des messages. L arbre des réplicas peut aussi absorber une partie des sollicitations avant que le nœud responsable situé à la racine ne soit atteint (section 3.5). OceanStore offre de plus un stockage sécurisé grâce au chiffrement des données et leur signature par clés publiques et privées. 3.5 Gestion de la cohérence La plupart des systèmes PàP sont utilisés pour du stockage de données non-modifiables, éludant ainsi les concurrences d écriture et la mise en place des protocoles de cohérence qui 10

en découlent. Ivy [25], OceanStore [22] et Pastis [31] sont des systèmes pair-à-pair de gestion de fichiers qui donnent la possibilité de modifier les données. Tous partent du principe que la mise à jour d un bloc revient à en insérer un nouveau dans le système. Dans Ivy, chaque écrivain ajoute la nouvelle version d une donnée en déclarant un nouveau bloc aussitôt chainé dans un journal recensant toutes les versions produites par cet utilisateur. Chaque bloc est caractérisé par son numéro de version (localement incrémenté sur le site propriétaire) et le vecteur d horloge 5 du site. Les journaux ne sont accessibles en écriture que pour le propriétaire mais restent lisiblent par tout le monde. On est donc bien en présence d un système à écrivains multiples, mais chacun dans son journal. OceanStore utilise un ensemble de machines dédiées à la gestion des mises à jour des fichiers dénommé Inner Ring. Celui-ci satisfait les requêtes des clients et décide de l ordre des mises à jour en utilisant un protocole de type consensus byzantin 6. Le système de réplicas met en jeu deux types de copies : 1) des copies primaires du fichier sont placées sur l Inner Ring et représentent la version la plus récente disponible sur le système et 2) des copies secondaires, caractérisées par un numéro de version et disséminées sur les sites participant à Oceanstore. Le protocole de mise à jour est expliqué dans la figure 4. Dans le cas de la concurrence des écritures et si le consensus échoue, les modifications peuvent être annulées. Le protocole de cohérence autorise par ailleurs la mise à jour des données sur les copies secondaires sans aucune concertation. Pastis manipule des données dont la structure est fortement inspirée par le système de fichiers Unix (UFS). Deux modèles de cohérence sont envisagés : 1) le close-to-open s apparente à l ERC (section 2.1.2) en ne propageant les modifications sur le réseau que lors de la fermeture du fichier et 2) le très relâché read-your-writes qui ne garantit à un site que de voir ses propres modifications. Lors de l apparition d un conflit en écriture, c est le dernier écrivain qui voit ses modifications prises en compte. L estampillage des écritures s effectue grâce aux horloges locales des sites faiblement synchronisées par un serveur de temps NTP. 4 Systèmes distribués tolérants aux fautes Les systèmes distribués permettent de rendre des services nécessitant des capacités de calcul ou de stockage importantes grâce à l interconnection de plusieurs unités de traitement. Le comportement erroné de l une d entre elles ne doit pas entraîner l interruption du service rendu par le système global. Ceci est d autant plus vrai pour des applications critiques 7 et plus généralement les systèmes où l on ne peut compter sur une intervention humaine immédiate. Tolérer les fautes est donc une vertue que se doivent de posséder les bons systèmes distribués. Cet aspect est particulièrement important dans les systèmes de partage de données. Cette section présente donc les notions de base des systèmes tolérants aux fautes. Elle s attache à caractériser les différents types de fautes et à présenter le protocole de communication de groupe. 5 Le vecteur d horloge défini par Mattern [27] et Fidge [16] est local à chaque site et se compose de la connaissance des numéros de version de autres sites. 6 Le consensus byzantin permet à plusieurs sites de décider d une même valeur et ce, en dépit de quelques sites malicieux désireux de semer la confusion dans le protocole. 7 Une application est dite critique dès lors que des vies humaines sont mises en jeu. 11

! Loïc Cudennec FIG. 4 Les mises à jour dans OceanStore. (a) Le fichier de mises à jour est envoyé par le client ( vers une copie primaire ainsi qu à un ensemble de réplicas connus et choisis aléatoirement. (b) Pendant qu un consensus sur l ordre des mises à jour est réalisé par les copies primaires, les copies secondaires poursuivent la dissémination des mises à jour et décident ou non de les appliquer localement. (c) Lorsque le consensus est établi, le résultat de la mise à jour est propagé le long de l arbre de diffusion. comportements byzantins faute erreur défaillance occurence ou activation propagation crashs omissions (a) (b) FIG. 5 Fautes, erreurs et défaillances. 4.1 Classification des fautes Un système est défaillant lorsque les sorties ne sont plus conformes à la spécification initiale. Les fautes sont définies comme les causes d une erreur. Une erreur est attachée à un état du système et sa propagation peut entraîner la défaillance (figure 5(a)). L occurence d une faute peut être : 1) transitoire, apparaître, disparaître et ne plus jamais se reproduire, 2) intermittente et reproductible dans un contexte donné et 3) persistante, apparaître jusqu à la réparation du système. Si l on se place au niveau des systèmes distribués, la défaillance d une machine peut-être interprétée par l ensemble du réseau de différentes manières (figure 5(b)) : un crash ou panne franche (fail-stop) se caractérise par l arrêt complet de l activité de la machine. Cet état est perçu sur les autres sites par l absence de messages attendus à partir d un instant donné et ce, jusqu à l éventuelle terminaison de l application. une omission correspond au fait qu un site ne recoive ou ne réponde pas à un message. Le site n est pas crashé car l activité reprend au bout d un temps fini. Une omission est 12

accompagnée de la perte d un ou plusieurs messages, généralement occasionnée par le débordement d un tampon. un comportement byzantin fait référence à l existence de sites malicieux dont le but est de semer la confusion dans le réseau. Ce problème a été formalisé par Lamport dans [24]. Toute la difficulté réside dans l appréciation du comportement d un site, à partir d un autre site, pour en déduire si il a commis une faute. Des facteurs extérieurs comme la lenteur soudaine d une machine ou l écroulement des performances réseau peuvent retarder des messages et induire en erreur le jugement porté sur un site. Dans un environnement de type grille de calculateurs, les sites participant au maillage sont gérés par des institutions de confiance et ne sont pas sujets au comportement byzantin. La suite de ce rapport ne considère donc que les fautes de crash et d omission. 4.2 Protocole de communication de groupes La tolérance aux fautes peut se mettre en œuvre aussi bien au niveau du matériel 8 que du logiciel. La technique principale reste la réplication des ressources afin de pallier à la disparition inopinée de certaines d entre elles. Pour des raisons de coût et de portabilité, de nombreux travaux [11, 20, 28, 8] se sont focalisés sur la couche applicative en cherchant à organiser les réplicas. La création de groupes de nœuds ayant des objectifs ou des fonctions en commun est une solution très utilisée en tolérance aux fautes depuis le système Isis [11]. L objectif de cette section est de montrer comment il est possible d abstraire plusieurs réplicas disséminés sur des sites différents en une entité avec laquelle on peut interragir. Cette transparence est assurée par deux principales techniques de réplication : la réplication avec copie primaire (primary-backup) met en jeu deux types de réplicas : un réplica primaire et plusieurs réplicas de sauvegarde. Le réplica primaire sert d interface en lecture et écriture avec les clients et se charge de répercuter les modifications sur les réplicas de sauvegarde. L ordre des mises à jour des sauvegardes est le même sur tous les sites car directement dépendant des accès séquentiels sur le réplica primaire. Une version améliorée de ce dispositif est par exemple utilisée dans le système de fichiers distribué OceanStore [22]. Un point faible de cette technique est de centraliser les lectures et écritures sur une seul site. la réplication active élimine l aspect centralisé introduit précédemment et attribue le même rôle à tous les réplicas. Les primitives d accès du client sont modifiées pour adresser non plus un réplica mais l ensemble des sites. La réplication active nécessite que les prédicats non crashés recoivent les opérations de mise à jour dans le même ordre. Assurer la transparence avec la réplication active nécessite la synchronisation des réplicas afin de déterminer un ordre d application des mises à jour. Les protocoles de communication de groupes s affichent comme des outils permettant la diffusion et la livraison de messages correctement ordonnés. 4.2.1 Protocole de composition de groupes Gérer un groupe de nœuds demande la mise en place d un protocole permettant de construire la liste des membres de ce groupe. Cette liste est définie par le concept de vue 8 par la réplication des composants notamment. 13

et est locale à chacun de ses participants. Elle varie au gré des arrivées et départs, qu ils soient annoncés ou non. Le protocole de composition de groupes intervient alors pour établir une cohérence entre les vues des membres. Il doit de plus garantir entre deux points de synchronisation que les messages reçus par ses membres soient délivrés à l application dans le même ordre. Cette propriété est garantie par la primitive de diffusion atomique. 4.2.2 Diffusion atomique Le modèle asynchrone permet de ne faire aucune hypothèse sur le temps de transmission des messages et facilite la prise en compte de surcharges réseaux et processeurs. Dans ce contexte, délivrer de manière ordonnée des messages sur plusieurs sites susceptibles de crasher implique l utilisation de techniques particulières. La diffusion fiable uniforme (uniform reliable broadcast (URB)) effectue la livraison d un message sur tous les sites corrects 9 ou ne le délivre pas du tout. L URB offre les propriétés suivantes : sureté : validité : si un processus délivre un message alors il existe un processus qui a diffusé ce message. alors tous les pro- intégrité : un message est délivré au plus une fois. vivacité (terminaison) : pout tout message ), si un processus délivre ) cessus corrects délivrent ). La diffusion atomique (atomic broadcast) est obtenue en ajoutant à l URB la propriété des messages ordonnés. Obtenir cette propriété supplémentaire demande aux participants de se concerter et donc d établir un consensus. 4.2.3 Consensus Le protocole du consensus permet à un ensemble de nœuds de décider d une valeur commune. Pour ce faire, chaque site propose une valeur et le protocole garantit que 1) tous les nœuds corrects décident une valeur, 2) la valeur décidée est une valeur proposée par un nœud participant au consensus et 3) tous les nœuds corrects décident la même valeur. Dans le cadre de la diffusion atomique, le consensus est alors utilisé pour décider d un ordre d arrivée des messages. Cependant, Fisher, Lynch et Paterson démontrent avec [17] que dans le contexte asynchrone, dès lors qu un crash se produit, il n existe pas de protocole pouvant résoudre le consensus. Le problème reste entier. 4.2.4 Détecteurs de fautes Les détecteurs de fautes apportent des éléments supplémentaires aux environnements asynchrones avec crash. Ils sont introduits par Chandra et Toueg dans [13] pour résoudre le problème du consensus. Les détecteurs de fautes ne contredisent pas le théorème [17] car leur implémentation nécessite l utilisation de quelques hypothèses de synchronisme 10. Cet article prouve de plus que le consensus et la diffusion atomique sont deux problèmes réductibles l un dans l autre. Un détecteur de fautes est un module installé sur chaque nœud 9 Un processus est correct si il ne crashe pas avant la terminaison de l application. 10 Heartbeat et timeout. 14

du réseau et dont le rôle est de surveiller un sous-ensemble des sites participants à l application. Il maintient à jour une liste des sites suspectés d avoir crashé. Certains sites peuvent être suspectés à tort et toujours fonctionner. Il existe plusieurs classes de détecteurs de fautes caractérisées par les propriétés de complétude et de précision. Ainsi la classe *,+ est-elle définie comme suit : complétude (completeness) : Il existe un temps - après lequel tous les processus crashés sont suspectés par au moins un processus correct. précision (accuracy) : Il existe un temps -/. après lequel au moins un processus correct n est suspecté par aucun des processus corrects. Il est démontré dans [13] que les détecteurs de fautes appartenant à la classe *,+ apportent suffisamment d informations à propos des fautes pour résoudre le problème du consensus. 5 Synthèse : un service de partage de données pour la grille La gestion des données sur la grille est l un des grands sujets de réflexion en informatique qui soit donné à la communauté scientifique. Malgré cet engouement, aucune solution sophistiquée n a été jusqu à aujourd hui proposée. L approche la plus répandue pour partager des données sur une grille consiste à transférer explicitement celles-ci entre le client et les serveurs de calcul. A titre d exemple, la plate-forme Globus [18] utilise le protocole GridFTP [2] qui requiert des informations explicites sur la localisation et le transfert des données. Il faut de plus remarquer que dans ces systèmes, les problèmes de cohérence des données sont laissés sous l entière responsabilité de l utilisateur. La gestion explicite de la localisation des données par le programmeur s annonce comme une limitation de l utilisation efficace des grilles. La mise en place de services de partage des données offrant des accès transparents est une étape ineluctable pour ce type d environnement. Ces services prennent principalement en charge la localisation et le transfert des données. Des stratégies adaptées de réplication sont alors associées à des protocoles de cohérence pour assurer les propriétés de persistance et de cohérence des données. Ces mécanismes fonctionnent sur des grilles dynamiques et supportent donc la volatilité caractérisée par des connexions et déconnexions de nœuds. 5.1 Approche : partage transparent des données Le problème de partager des données modifiables dans les environnements distribués a été largement étudié ces quinzes dernières années à travers le concept des systèmes à MVP (section 2). Les MVP apportent la transparence au niveau de la gestion des données, proposent l implémentation de nombreux modèles de cohérence ainsi que des mécanismes de tolérance aux fautes (section 4). Cependant, pour des raisons de performances, leur déploiement n est réalisable qu à petite échelle, sur des configurations de quelques dizaines de nœuds. Le modèle PàP (section 3) quant à lui a prouvé son efficacité à passer à l échelle en réussissant à rassembler sur le réseau internet, essentiellement pour du partage de données, plusieurs centaines de milliers de nœuds. Le PàP est caractérisé par un très bon comportement face à la volatilité, offrant les propriétés de persistance des données et de tolérance aux fautes. Cependant, la plupart des systèmes PàP portent sur la gestion de données nonmodifiables. 15

groupe de données groupe A groupe B Client Fournisseur Gestionnaire FIG. 6 JuxMem : architecture. JuxMem [4, 5, 7, 8] est un service de partage de données pour la grille dont la particularité est d être défini comme un système hybride inspiré des modèles MVP et PàP. A la MVP, JuxMem emprunte la possibilité de modifier les données et d intégrer des modèles de cohérence, au PàP, la gestion de réseaux dynamiques. Mais JuxMem est avant tout une plateforme générique sur laquelle divers protocoles de cohérence et stratégies de tolérance aux fautes peuvent être implémentés. L aspect dynamique de JuxMem est assuré par l utilisation de la plate-forme générique JXTA [1] qui fournit les blocs de base pour l intégration de services pait-à-pair (arrivée d un nœud, découverte, formation de groupe...etc). 5.2 Architecture de JuxMem L architecture de JuxMem reflète l architecture matérielle de la grille, à savoir un modèle hiérarchique composé de grappes de calculateurs interconnectées par des réseaux. La figure 6 met en valeur les différents rôles attribués dans JuxMem. Les ensembles 0 et 1 peuvent correspondre à des sites placés sur deux grappes physiques distantes, ce sont des cluster groups. Chaque cluster group est composé de nœuds spécialisés dans le stockage de données : les fournisseurs. Dans chaque cluster group se trouve un nœud chargé de gérer la mémoire mise à la disposition de la grille : le gestionnaire. Enfin, tout nœud utilisant le service de localisation et d accès aux données joue le rôle de client. Il est biensûr possible pour un site de cumuler plusieurs rôles. Le système associe à chaque bloc de données stocké un groupe de données. Ce groupe est formé d un ensemble de fournisseurs hébergeant une copie du bloc. Les fournisseurs peuvent appartenir à plusieurs cluster group, ce qui facilite la dissémination des blocs sur plusieurs grappes. La réplication est introduite dans JuxMem à des fins de disponibilité et de persistance des données. Ces données étant modifiables, des protocoles sont mis en œuvre pour assurer la cohérence des copies. La difficulté provient de la volatilité et des défaillances pouvant toucher les nœuds. Certains systèmes à MVP gèrent un ensemble de réplicas pour la persistance et l amélioration des performances. JuxMem a choisi de dissocier les deux rôles. Cette stratégie permet de 1) simplifier les protocoles de cohérence et les stratégies de tolérance aux fautes, 2) obtenir un schéma de conception plus clair et 3) expérimenter différentes combi- 16

naisons de protocoles de cohérence avec des stratégies de tolérance aux fautes. Un prototype de JuxMem proposant ces fonctionnalités a déjà été implémenté au sein du projet Paris. 6 Conclusion Le partage de données modifiables sur les environnements de type grille fait appel aux travaux réalisés depuis plusieurs dizaines d années dans les systèmes à mémoires virtuellement partagées, les systèmes pair-à-pair et les systèmes tolérants aux fautes. JuxMem introduit le concept de service de partage de données comme une approche hybride réunifiant les paradigmes de la MVP et du PàP. L objectif est ici de profiter des accès transparents aux données et de pouvoir les modifier tout en s adaptant à de grands environnements dynamiques. Les MVP proposent un modèle de partage des données modifiables. La transparence est assurée par le système qui se charge de localiser et copier localement les données distantes. Plusieurs protocoles de cohérence assurent la gestion des réplicas ainsi créés. Malheureusement ces systèmes s avèrent inefficaces lorsque portés sur plus d une centaine de noeuds. Le PàP quant à lui réussi le pari de fédérer plusieurs centaines de milliers de nœuds interconnectés par le réseau internet. La dynamicité inhérente à ce réseau montre la capacité du système à tolérer les fautes. Cependant, à cette échelle, les applications déployées ne traitent que du partage de données non-modifiables. Choisir le modèle de cohérence régissant la stratégie de gestion des réplicas est donc un point déterminant dans la réussite d un service de partage des données pour la grille. Le protocole qui en découle doit afficher de bonnes performances en terme de communications réseaux et ainsi assurer le passage à l échelle. Il doit de plus garantir des mises à jour rapides et pertinentes des données pour offrir un modèle de programmation simple. Car l objectif est bien là : permettre la programmation des grilles selon les techniques de programmation les plus classiques qui soient. Un premier protocole a été proposé par Jean-François Deverge lors d un stage effectué en 2004 dans l équipe Paris. De nouveaux protocoles peuvent être trouvés en expérimentant par exemple des techniques plus paresseuses de gestion de la cohérence des réplicas que celles utilisées jusqu à présent. Proposer des protocoles ayant la faculté de s adapter aux besoins des applications est une autre piste à considérer. C est à cette tâche que ce stage est dédié. La mise en œuvre et l évaluation des performances s effectueront au sein de la plate-forme JuxMem. 17

Références [1] The JXTA project (juxtaposed). http://www.jxta.org. [2] Bill Allcock, Joe Bester, John Bresnahan, Ann L. Chervenak, Ian Foster, Carl Kesselman, Sam Meder, Veronika Nefedova, Darcy Quesnel, and Steven Tuecke. Data management and transfer in high-performance computational grid environments. Parallel Comput., 28(5):749 771, 2002. [3] Cristiana Amza, Alan L. Cox, Sandhya Dwarkadas, Pete Keleher, Honghui Lu, Ramakrishnan Rajamony, Weimin Yu, and Willy Zwaenepoel. TreadMarks: Shared memory computing on networks of workstations. IEEE Computer, 29(2):18 28, February 1996. [4] Gabriel Antoniu, Luc Bougé, and Mathieu Jan. JuxMem: An adaptive supportive platform for data sharing on the grid. In Proceedings Workshop on Adaptive Grid Middleware (AGRIDM 2003), pages 49 59, New Orleans, Louisiana, September 2003. Held in conjunction with PACT 2003. Extended version to appear in Kluwer Journal of Supercomputing. [5] Gabriel Antoniu, Luc Bougé, and Mathieu Jan. JuxMem: Weaving together the P2P and DSM paradigms to enable a Grid Data-sharing Service. Kluwer Journal of Supercomputing, 2005. To appear. Preliminary electronic version available at URL http: //www.inria.fr/rrrt/rr-5082.html. [6] Gabriel Antoniu, Luc Bougé, and Sébastien Lacour. Making a DSM consistency protocol hierarchy-aware: An efficient synchronization scheme. In 3rd IEEE/ACM International Conference on Cluster Computing an the Grid (CCGrid 2003), pages 516 523, Tokyo, Japan, May 2003. IEEE. [7] Gabriel Antoniu, Jean-François Deverge, and Sébastien Monnet. Building fault-tolerant consistency protocols for an adaptive grid data-sharing service. In Proc. ACM Workshop on Adaptive Grid Middleware (AGridM 2004), Antibes Juan-les-Pins, France, September 2004. To appear. [8] Gabriel Antoniu, Jean-François Deverge, and Sébastien Monnet. How to bring together fault tolerance and data consistency to enable grid data sharing. Technical Report PI 1685, IRISA/INRIA, University of Rennes 1, jan. 2005. [9] L. Arantes and P. Sens. CLRC : Une mémoire partagée répartie pour des grappes de stations inter-connectées. In Actes de la 2ème Conférence Française sur les Systèmes d Exploitation, pages 8 15, Apr. 2001. [10] Brian N. Bershad, Mattew J. Zekauskas, and Wayne A. Sawdon. The Midway distributed shared memory system. In Proceedings of the 38th IEEE International Computer Conference (COMPCON Spring 93), pages 528 537, Los Alamitos, CA, February 1993. [11] Kenneth P. Birman. The process group approach to reliable distributed computing. Commun. ACM, 36(12):37 53, 1993. [12] John B. Carter, John K. Bennett, and Willy Zwaenepoel. Implementation and performance of Munin. In 13th ACM Symposium on Operating Systems Principles (SOSP), pages 152 164, Pacific Grove, CA, October 1991. 18

[13] Tushar Deepak Chandra and Sam Toueg. Unreliable failure detectors for reliable distributed systems. J. ACM, 43(2):225 267, 1996. [14] Frank Dabek, Frans Kaashoek, David Karger, Robert Morris, and Ion Stoica. Wide-area cooperative storage with CFS. In 18th ACM Symposium on Operating Systems Principles (SOSP 01), pages 202 215, Chateau Lake Louise, Banff, Alberta, Canada, October 2001. [15] Frank Dabek, Ben Y. Zhao, Peter Druschel, John Kubiatowicz, and Ion Stoica. Towards a common api for structured peer-to-peer overlays. In IPTPS, pages 33 44, 2003. [16] Colin Fidge. Logical time in distributed computing systems. Computer, 24(8):28 33, 1991. [17] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. J. ACM, 32(2):374 382, 1985. [18] Ian Foster and Carl Kesselman. Globus: A Metacomputing Infrastructure Toolkit. The International Journal of Supercomputer Applications and High Performance Computing, 11(2):115 128, 1997. [19] Ian Foster, Carl Kesselman, and Steven Tuecke. The anatomy of the grid: Enabling scalable virtual organizations. Supercomputer Applications, 15(3):200 222, March 2001. [20] Rachid Guerraoui and André Schiper. Software-based replication for fault tolerance. IEEE Computer, 30(4):68 74, 1997. [21] Liviu Iftode, Jaswinder Pal Singh, and Kai Li. Scope consistency: A bridge between release consistency and entry consistency. In Proceedings of the 8th ACM Annual Symposium on Parallel Algorithms and Architectures (SPAA), pages 277 287, Padova, Italy, June 1996. [22] John Kubiatowicz, David Bindel, Yan Chen, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westly Weimer, Christopher Wells, and Ben Zhao. OceanStore: An architecture for global-scale persistent storage. In 9th International Conference on Architecture Support for Programming Languages and Operating Systems (ASPLOS 2000), number 2218 in Lecture Notes in Computer Science, pages 190 201, Cambridge, MA, November 2000. Springer-Verlag. [23] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):558 565, 1978. [24] Leslie Lamport, Robert E. Shostak, and Marshall C. Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382 401, 1982. [25] Kai Li. Ivy: A shared virtual memory system for parallel computing. In ICPP (2), pages 94 101, 1988. [26] Kai Li and Paul Hudak. Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems, 7(4):321 359, November 1989. 19