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

Dimension: px
Commencer à balayer dès la page:

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

Transcription

1 Gestion de la cohérence des données dans les systèmes distribués Étude bibliographique Loïc Cudennec Superviseurs : Gabriel Antoniu, Luc Bougé, Sébastien Monnet 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.

2 Table des matières 1 Introduction 2 2 Systèmes à MVP : accès transparent aux données Modèles et protocoles de cohérence Modèles de cohérence forte Modèles de cohérence relâchée Modèles pour grappes de grappes Granularité Localisation des données Systèmes PàP : dynamicité et passage à l échelle Généralités Architecture générique des systèmes PàP Localisation et routage Gestion des données Gestion de la cohérence Systèmes distribués tolérants aux fautes Classification des fautes Protocole de communication de groupes Protocole de composition de groupes Diffusion atomique Consensus Détecteurs de fautes Synthèse : un service de partage de données pour la grille Approche : partage transparent des données Architecture de JuxMem Conclusion 17

3 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

4 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

5 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 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

6 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 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

7 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

8 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

9 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

10 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

11 (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

12 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

13 ! 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

14 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 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

15 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 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 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 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

16 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

17 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

18 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

19 Références [1] The JXTA project (juxtaposed). [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): , [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 [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 Held in conjunction with PACT 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, 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 , Tokyo, Japan, May 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 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 [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 [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 , Los Alamitos, CA, February [11] Kenneth P. Birman. The process group approach to reliable distributed computing. Commun. ACM, 36(12):37 53, [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 , Pacific Grove, CA, October

20 [13] Tushar Deepak Chandra and Sam Toueg. Unreliable failure detectors for reliable distributed systems. J. ACM, 43(2): , [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 , Chateau Lake Louise, Banff, Alberta, Canada, October [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, [16] Colin Fidge. Logical time in distributed computing systems. Computer, 24(8):28 33, [17] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. J. ACM, 32(2): , [18] Ian Foster and Carl Kesselman. Globus: A Metacomputing Infrastructure Toolkit. The International Journal of Supercomputer Applications and High Performance Computing, 11(2): , [19] Ian Foster, Carl Kesselman, and Steven Tuecke. The anatomy of the grid: Enabling scalable virtual organizations. Supercomputer Applications, 15(3): , March [20] Rachid Guerraoui and André Schiper. Software-based replication for fault tolerance. IEEE Computer, 30(4):68 74, [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 , Padova, Italy, June [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 , Cambridge, MA, November Springer-Verlag. [23] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7): , [24] Leslie Lamport, Robert E. Shostak, and Marshall C. Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3): , [25] Kai Li. Ivy: A shared virtual memory system for parallel computing. In ICPP (2), pages , [26] Kai Li and Paul Hudak. Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems, 7(4): , November

Revue d article : Dynamic Replica Placement for Scalable Content Delivery

Revue d article : Dynamic Replica Placement for Scalable Content Delivery Revue d article : Dynamic Replica Placement for Scalable Content Delivery Marc Riner - INSA Lyon - DEA DISIC Introduction Cet article [1] présente une technique innovante de placement de réplicats et de

Plus en détail

Architecture d un service de partage de données modifiables sur une infrastructure pair-à-pair

Architecture d un service de partage de données modifiables sur une infrastructure pair-à-pair Architecture d un service de partage de données modifiables sur une infrastructure pair-à-pair Mathieu Jan Mathieu.Jan@irisa.fr Superviseurs : Gabriel Antoniu, Luc Bougé, Thierry Priol {Gabriel.Antoniu,Luc.Bouge,Thierry.Priol}@irisa.fr

Plus en détail

Cohérence et volatilité dans un service de partage de données dans les grilles de calcul

Cohérence et volatilité dans un service de partage de données dans les grilles de calcul RENPAR 16 Le roisic, Presqu île de Guérande, France, 5 au 8 avril 2005 ohérence et volatilité dans un service de partage de données dans les grilles de calcul Jean-François Deverge et Sébastien Monnet

Plus en détail

Robin Favre Fabien Touvat. Polytech Grenoble RICM 3 ème Année Vendredi 21 Novembre 2008 Etude d Approfondissement Réseau

Robin Favre Fabien Touvat. Polytech Grenoble RICM 3 ème Année Vendredi 21 Novembre 2008 Etude d Approfondissement Réseau Robin Favre Fabien Touvat Polytech Grenoble RICM 3 ème Année Vendredi 21 Novembre 2008 Etude d Approfondissement Réseau Plan I. Système distribué A. Définition B. Exemples II. III. Stockage distribué A.

Plus en détail

Services et protocoles pour l'exécution fiable d'applications distribuées dans les grilles de calcul

Services et protocoles pour l'exécution fiable d'applications distribuées dans les grilles de calcul Services et protocoles pour l'exécution fiable d'applications distribuées dans les grilles de calcul Thomas Ropars Équipe-projet PARIS 1 Les applications de calcul scientifique Objectifs : Simuler des

Plus en détail

Il existe actuellement plusieurs méthodes pour accéder à un serveur de contenu proche du client.

Il existe actuellement plusieurs méthodes pour accéder à un serveur de contenu proche du client. Yan Chen, Randy H. Katz, John D. Kubiatowicz. Dynamic Replica Placement for Scalable Content Delivery. In Peer-to-Peer Systems: First International Workshop, IPTPS 2002. Le domaine abordé par l article

Plus en détail

Tolérance aux pannes dans les grilles de calcul

Tolérance aux pannes dans les grilles de calcul Tolérance aux pannes dans les grilles de calcul Bakhta Meroufel 1, Ghalem Belalem 2, Nadia Hadi 3 1 bmeroufel@yahoo.fr, 2 ghalem1dz@univ-oran.dz, 3 yhana9@yahoo.fr Département d Informatique Faculté des

Plus en détail

Systèmes et algorithmes répartis

Systèmes et algorithmes répartis Systèmes et algorithmes répartis Tolérance aux fautes Philippe Quéinnec Département Informatique et Mathématiques Appliquées ENSEEIHT 4 novembre 2014 Systèmes et algorithmes répartis V 1 / 45 plan 1 Sûreté

Plus en détail

Réplication adaptative sur les réseaux P2P

Réplication adaptative sur les réseaux P2P Réplication adaptative sur les réseaux pair à pair 10 mars 2006 1 Introduction 2 Réseaux pair à pair et tables de hachage distribuées 3 Le protocole app-cache 4 Le protocole LAR 5 Tests de performance

Plus en détail

Conception des systèmes répartis

Conception des systèmes répartis Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan

Plus en détail

Conception d Applications Réparties

Conception d Applications Réparties Jean-François Roos LIFL - équipe GOAL- bâtiment M3 Extension - bureau 206 -Jean-Francois.Roos@lifl.fr 1 Objectifs du Cours Appréhender la conception d applications réparties motivations et concepts architectures

Plus en détail

Modélisation conceptuelle des Systèmes Distribués

Modélisation conceptuelle des Systèmes Distribués Modélisation conceptuelle des Systèmes Distribués Eric Cariou Master Technologies de l'internet 1 ère année Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Systèmes

Plus en détail

Objectifs du cours Modèles et Approches Formels de Systèmes Distribués

Objectifs du cours Modèles et Approches Formels de Systèmes Distribués Objectifs du cours Modèles et Approches Formels de Systèmes Distribués Mohamed Mosbah LaBRI ENSEIRB - Université Bordeaux 1 mosbah@labri.fr dept-info.labri.fr/~mosbah/mafsd.html Connaître les caractéristiques

Plus en détail

Architecture des calculateurs

Architecture des calculateurs Chapitre 1 Architecture des calculateurs 1.1 Introduction Ce paragraphe n a pas la prétention de présenter un cours d informatique. D une manière générale, seuls les caractéristiques architecturales qui

Plus en détail

Supervision des réseaux et services pair à pair

Supervision des réseaux et services pair à pair Supervision des réseaux et services pair à pair Présentation des travaux de Thèse Guillaume Doyen LORIA - Université Henri Poincaré pour l obtention du Doctorat en Informatique de l université Henri Poincaré

Plus en détail

Rapport d activité. Mathieu Souchaud Juin 2007

Rapport d activité. Mathieu Souchaud Juin 2007 Rapport d activité Mathieu Souchaud Juin 2007 Ce document fait la synthèse des réalisations accomplies durant les sept premiers mois de ma mission (de novembre 2006 à juin 2007) au sein de l équipe ScAlApplix

Plus en détail

Sauvegarde collaborative entre pairs Ludovic Courtès LAAS-CNRS

Sauvegarde collaborative entre pairs Ludovic Courtès LAAS-CNRS Sauvegarde collaborative entre pairs 1 Sauvegarde collaborative entre pairs Ludovic Courtès LAAS-CNRS Sauvegarde collaborative entre pairs 2 Introduction Pourquoi pair à pair? Utilisation de ressources

Plus en détail

L UNIVERSITÉ DE RENNES 1. Monsieur Sébastien Monnet

L UNIVERSITÉ DE RENNES 1. Monsieur Sébastien Monnet Numéro d ordre : 3462 THÈSE présentée devant L UNIVERSITÉ DE RENNES 1 pour obtenir le grade de DOCTEUR DE L UNIVERSITÉ DE RENNES 1 Mention INFORMATIQUE PAR Monsieur Sébastien Monnet Équipe d accueil :

Plus en détail

Sauvegarde coopérative entre pairs pour dispositifs mobiles

Sauvegarde coopérative entre pairs pour dispositifs mobiles Sauvegarde coopérative entre pairs pour dispositifs mobiles 1 Sauvegarde coopérative entre pairs pour dispositifs mobiles Ludovic Courtès, Marc-Olivier Killijian, David Powell, Matthieu Roy Sauvegarde

Plus en détail

Maîtrise Polyvalente. Internet et Multimédia. Cours 9 : Localisation des médias

Maîtrise Polyvalente. Internet et Multimédia. Cours 9 : Localisation des médias à l Université Pierre et Marie Curie, le 26 avril 2004 Maîtrise Polyvalente Internet et Multimédia Cours 9 : Localisation des médias Timur FRIEDMAN Copyright 2004 by Timur Friedman 1 Deux problèmes de

Plus en détail

Les conteneurs : une approche générique pour la conception d un système à image unique

Les conteneurs : une approche générique pour la conception d un système à image unique RENPAR 14 / ASF / SYMPA Hamamet, Tunisie, 10 13 avril 2002 Les conteneurs : une approche générique pour la conception d un système à image unique Renaud Lottiaux, projet PARIS IRISA/INRIA, Campus universitaire

Plus en détail

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec.

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec. 3A-IIC - Parallélisme & Grid Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Principes et Objectifs Evolution Leçons du passé Composition d une Grille Exemple d utilisation

Plus en détail

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle Besoin de concevoir des systèmes massivement répartis. Évaluation de systèmes répartis à large échelle Sergey Legtchenko Motivation : LIP6-INRIA Tolérance aux pannes Stockage de données critiques Coût

Plus en détail

Stratégie de réplication résistante au churn pour les tables de hachage distribuées en pair-à-pair

Stratégie de réplication résistante au churn pour les tables de hachage distribuées en pair-à-pair Stratégie de réplication résistante au churn pour les tables de hachage distribuées en pair-à-pair Sergey Legtchenko LIP6/Université Pierre et Marie Curie/CNRS/INRIA sergey.legtchenko@systeme.lip6.fr Résumé

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

Tolérance aux pannes

Tolérance aux pannes Tolérance aux pannes Arnaud Labourel Université de Provence 15 mars 2012 Arnaud Labourel (Université de Provence) Tolérance aux pannes 15 mars 2012 1 / 55 Présentation Tolérances aux pannes Pannes Définition

Plus en détail

Gestion de données à large échelle. Anne Doucet LIP6 Université Paris 6

Gestion de données à large échelle. Anne Doucet LIP6 Université Paris 6 Gestion de données à large échelle Anne Doucet LIP6 Université Paris 6 1 Plan Contexte Les réseaux P2P Non structurés Structurés Hybrides Localisation efficace et Interrogation complète et exacte des données.

Plus en détail

Exécution des applications réparties

Exécution des applications réparties Exécution des applications réparties Programmation des Applications Réparties Olivier Flauzac URCA Master STIC-Informatique première année Olivier Flauzac (URCA) PAR : Exécution des applications réparties

Plus en détail

L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i n f r a m e, un b e s o i n c r u c i a l

L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i n f r a m e, un b e s o i n c r u c i a l Siège social : 5 Speen Street Framingham, MA 01701, É.-U. T.508.872.8200 F.508.935.4015 www.idc.com L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i

Plus en détail

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE I N T E RS Y S T E M S INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE David Kaaret InterSystems Corporation INTERSySTEMS CAChé CoMME ALTERNATIvE AUx BASES de données RéSIdENTES

Plus en détail

DUT Informatique - Module M-4102C Modélisation et construction des applications

DUT Informatique - Module M-4102C Modélisation et construction des applications DUT Informatique - Module M-4102C Modélisation et construction des applications réparties Applications réparties (distributed systems) J. Christian Attiogbé Fevrier 2015 J. Christian Attiogbé (Fevrier

Plus en détail

Université de Technologies de Troyes. Distribution des données et des métadonnées médicales dans un environnement de grille

Université de Technologies de Troyes. Distribution des données et des métadonnées médicales dans un environnement de grille Université de Technologies de Troyes Ecole Doctorale SSTO DEA Réseaux Avancés de Connaissances et Organisations (RACOR) Rapport de Stage de DEA Distribution des données et des métadonnées médicales dans

Plus en détail

P U B L I C A T I O N I N T E R N E 1662. CONCEPTION ET MISE EN œuvre D UN SYSTÈME D ENTRÉES/SORTIES PERFORMANT POUR GRAPPE

P U B L I C A T I O N I N T E R N E 1662. CONCEPTION ET MISE EN œuvre D UN SYSTÈME D ENTRÉES/SORTIES PERFORMANT POUR GRAPPE I R I P U B L I C A T I O N I N T E R N E 1662 N o S INSTITUT DE RECHERCHE EN INFORMATIQUE ET SYSTÈMES ALÉATOIRES A CONCEPTION ET MISE EN œuvre D UN SYSTÈME D ENTRÉES/SORTIES PERFORMANT POUR GRAPPE GAËL

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBLITÉ CONTINUE ET MOBILITÉ DES DONNÉES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 46 NFP111 Systèmes et Applications Réparties Cours 2 - Les appels de procédure distants (Partie 1) Claude Duvallet Université du Havre UFR Sciences et Techniques

Plus en détail

WHITE PAPER. Quels avantages la déduplication offre-t-elle aux entreprises? Livre blanc Acronis

WHITE PAPER. Quels avantages la déduplication offre-t-elle aux entreprises? Livre blanc Acronis Quels avantages la déduplication offre-t-elle aux entreprises? Livre blanc Acronis Copyright Acronis, Inc. 2000 2009 Table des matières Résumé... 3 Qu est-ce que la déduplication?... 4 Déduplication au

Plus en détail

ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES. Cours Administration des Bases de données M Salhi

ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES. Cours Administration des Bases de données M Salhi ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES Cours Administration des Bases de données M Salhi Architectures des Système de base de données Systèmes centralisés et client-serveur Server System Architectures

Plus en détail

Messagerie sécurisée, fiable et économique

Messagerie sécurisée, fiable et économique rie Services de messagerie SWIFT rie sécurisée, fiable et économique Un ensemble complet de services de messagerie est la plateforme de messagerie de SWIFT basée sur un protocole Internet avancé. Elle

Plus en détail

Gestion répartie de données - 1

Gestion répartie de données - 1 Gestion répartie de données - 1 Sacha Krakowiak Université Joseph Fourier Projet Sardes (INRIA et IMAG-LSR) http://sardes.inrialpes.fr/~krakowia Gestion répartie de données Plan de la présentation Introduction

Plus en détail

Plan. Cours 4 : Méthodes d accès aux données. Architecture système. Objectifs des SGBD (rappel)

Plan. Cours 4 : Méthodes d accès aux données. Architecture système. Objectifs des SGBD (rappel) UPMC - UFR 99 Licence d informatique 205/206 Module 3I009 Cours 4 : Méthodes d accès aux données Plan Fonctions et structure des SGBD Structures physiques Stockage des données Organisation de fichiers

Plus en détail

Introduction aux applications réparties

Introduction aux applications réparties Introduction aux applications réparties Noël De Palma Projet SARDES INRIA Rhône-Alpes http://sardes.inrialpes.fr/~depalma Noel.depalma@inrialpes.fr Applications réparties Def : Application s exécutant

Plus en détail

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration Julien MATHEVET Alexandre BOISSY GSID 4 Rapport Load Balancing et migration Printemps 2001 SOMMAIRE INTRODUCTION... 3 SYNTHESE CONCERNANT LE LOAD BALANCING ET LA MIGRATION... 4 POURQUOI FAIRE DU LOAD BALANCING?...

Plus en détail

Chapitre 2: Couche Application I

Chapitre 2: Couche Application I Chapitre 2: Couche Application I Roch Glitho, PhD Associate Professor and Canada Research Chair My URL - http://users.encs.concordia.ca/~glitho/ Couche Application I (Infrastructures d application) Application

Plus en détail

Introduction aux systèmes répartis

Introduction aux systèmes répartis Introduction aux systèmes répartis Grappes de stations Applications réparties à grande échelle Systèmes multicalculateurs (1) Recherche de puissance par assemblage de calculateurs standard Liaison par

Plus en détail

Données Réparties. Thibault BERNARD. thibault.bernard@univ-reims.fr

Données Réparties. Thibault BERNARD. thibault.bernard@univ-reims.fr Données Réparties Thibault BERNARD thibault.bernard@univ-reims.fr Sommaire Introduction Gestion de la concurrence Reprise après panne Gestion des données dupliquées Sommaire Introduction Gestion de la

Plus en détail

Contributions à l expérimentation sur les systèmes distribués de grande taille

Contributions à l expérimentation sur les systèmes distribués de grande taille Contributions à l expérimentation sur les systèmes distribués de grande taille Lucas Nussbaum Soutenance de thèse 4 décembre 2008 Lucas Nussbaum Expérimentation sur les systèmes distribués 1 / 49 Contexte

Plus en détail

Cours Bases de données

Cours Bases de données Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Transparents Disponibles

Plus en détail

SURETE DE FONCTIONNEMENT ET REPRISE APRES PANNE

SURETE DE FONCTIONNEMENT ET REPRISE APRES PANNE Université des sciences et de la Technologie Houari Boumediene USTHB Alger Département d Informatique ARCHITECTURE ET ADMINISTRATION DES BASES DE DONNÉES 2013-2014 RESPONSABLES M. KAMEL BOUKHALFA (SII)

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBILITE CONTINUE ET MOBILITE DES DONNEES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

Plus en détail

Introduction : Caractéristiques du RAID : La redondance et la parité : Les différents types de systèmes RAID :

Introduction : Caractéristiques du RAID : La redondance et la parité : Les différents types de systèmes RAID : Introduction : La technologie RAID (regroupement redondant de disques indépendants) permet de constituer une unité de stockage à partir de plusieurs disques durs. Cette unitée,appelée grappe, a une tolérance

Plus en détail

Présentation du module Base de données spatio-temporelles

Présentation du module Base de données spatio-temporelles Présentation du module Base de données spatio-temporelles S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Partie 1 : Notion de bases de données (12,5h ) Enjeux et principes

Plus en détail

Multi-processeurs, multi-cœurs, cohérence mémoire et cache

Multi-processeurs, multi-cœurs, cohérence mémoire et cache Multi-processeurs, multi-cœurs, cohérence mémoire et cache Intervenant : Thomas Robert Institut Mines-Télécom Parallélisme inter instructions n Exécution : une séquence d instructions appliquées à un 1

Plus en détail

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA Plan Les Protocoles de Télécommunications Evolution Internet Cours de DEA Isabelle CHRISMENT ichris@loria.fr Introduction Routage dans l Internet IPv6 Communication de groupes et l Internet x sans fils,

Plus en détail

Programmation paresseuse et causale des architectures orientées services

Programmation paresseuse et causale des architectures orientées services LABORATOIRE D INFORMATIQUE DE NANTES-ATLANTIQUE UMR 6241 ÉCOLE DOCTORALE STIM, N. 503 «Sciences et technologies de l information et des mathématiques» Sujet de thèse pour 2016 Programmation paresseuse

Plus en détail

Vers l'orchestration de grilles de PC par les mécanismes de publicationsouscription

Vers l'orchestration de grilles de PC par les mécanismes de publicationsouscription Vers l'orchestration de grilles de PC par les mécanismes de publicationsouscription Présentée par Leila Abidi Sous la direction de Mohamed Jemni & Christophe Cérin Plan Contexte Problématique Objectifs

Plus en détail

Influence De La Taille Du Jeton Sur Les Performances De L algorithme D'exclusion Mutuelle De Ricart - Agrawala

Influence De La Taille Du Jeton Sur Les Performances De L algorithme D'exclusion Mutuelle De Ricart - Agrawala Influence De La Taille Du Jeton Sur Les Performances De L algorithme D'exclusion Mutuelle De Ricart - Agrawala Sarah Benkouider, Souhila Labgaa 2, Mohamed Yagoubi 3 Université Amar Telidji Département

Plus en détail

Sauvegarde collaborative en pair-à-pair

Sauvegarde collaborative en pair-à-pair Sauvegarde collaborative en pair-à-pair Fabrice Le Fessant Fabrice.Le_Fessant@inria.fr ASAP Team INRIA Saclay Île de France Octobre 2008 Fabrice Le Fessant () Backup en pair-à-pair Rennes 2008 1 / 21 Plan

Plus en détail

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Contenu de ce cours : 1. Stockage de données. Supports, fonctionnement d un disque, technologie RAID 2. Organisation

Plus en détail

Virtualisation et. performances de disque. Virtualisation et performances de disque 1

Virtualisation et. performances de disque. Virtualisation et performances de disque 1 Virtualisation et performances de disque 1 Introduction : Comme les technologies de virtualisation peuvent avoir des applications spécifiques mais différentes, ce livre blanc débute par une série de définitions.

Plus en détail

Les transactions étendues et quelques Frameworks qui les supportent.

Les transactions étendues et quelques Frameworks qui les supportent. Les transactions étendues et quelques Frameworks qui les supportent. Christophe Ponsen cponsen@info.fundp.ac.be Institut d Informatique, Université de Namur Résumé Les transactions étendues posent de nombreux

Plus en détail

Réplication des données

Réplication des données Réplication des données Christelle Pierkot FMIN 306 : Gestion de données distribuées Année 2009-2010 Echange d information distribuée Grâce à un serveur central Une seule copie cohérente Accès à distance

Plus en détail

10 tâches d administration simplifiées grâce à Windows Server 2008 R2. 1. Migration des systèmes virtuels sans interruption de service

10 tâches d administration simplifiées grâce à Windows Server 2008 R2. 1. Migration des systèmes virtuels sans interruption de service 10 tâches d administration simplifiées grâce à Windows Server 2008 R2 Faire plus avec moins. C est l obsession depuis plusieurs années de tous les administrateurs de serveurs mais cette quête prend encore

Plus en détail

JUXMEM : un service de partage transparent de données pour grilles de calcul fondé sur une approche pair-à-pair

JUXMEM : un service de partage transparent de données pour grilles de calcul fondé sur une approche pair-à-pair JUXMEM : un service de partage transparent de données pour grilles de calcul fondé sur une approche pair-à-pair Mathieu Jan To cite this version: Mathieu Jan. JUXMEM : un service de partage transparent

Plus en détail

Apports des architectures pair-à-pair pour les réseaux ad hoc

Apports des architectures pair-à-pair pour les réseaux ad hoc Apports des architectures pair-à-pair pour les réseaux ad hoc Tuan Dung NGUYEN Thèse co-encadrée ENST Bretagne INT (début : 15 octobre 2005) Directeur de thèse : Guy BERNARD - INT Co-encadrants : Siegfried

Plus en détail

GRID : Overview ANR-05-CIGC «GCPMF» 8 juin 2006 Stéphane Vialle

GRID : Overview ANR-05-CIGC «GCPMF» 8 juin 2006 Stéphane Vialle GRID : Overview ANR-05-CIGC «GCPMF» 8 juin 2006 Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Grid : Overview 1. Définition et composition 2. Exemple de Middleware 3. Interconnexion

Plus en détail

DSM-PM2 : une plate-forme portable pour l implémentation de protocoles de cohérence MVP multithread. Gabriel Antoniu LIP, ENS-Lyon

DSM-PM2 : une plate-forme portable pour l implémentation de protocoles de cohérence MVP multithread. Gabriel Antoniu LIP, ENS-Lyon DSM-PM2 : une plate-forme portable pour l implémentation de protocoles de cohérence MVP multithread Gabriel Antoniu LIP, ENS-Lyon Contexte : PM2 Environnement de programmation multithread distribué Développé

Plus en détail

Technologie de déduplication de Barracuda Backup. Livre blanc

Technologie de déduplication de Barracuda Backup. Livre blanc Technologie de déduplication de Barracuda Backup Livre blanc Résumé Les technologies de protection des données jouent un rôle essentiel au sein des entreprises et ce, quelle que soit leur taille. Toutefois,

Plus en détail

LA GESTION DE FICHIERS

LA GESTION DE FICHIERS CHAPITRE 6 : LA GESTION DE FICHIERS Objectifs spécifiques Connaître la notion de fichier, ses caractéristiques Connaître la notion de répertoires et partitions Connaître les différentes stratégies d allocation

Plus en détail

Service de Déploiement Windows (WDS)

Service de Déploiement Windows (WDS) Service de Déploiement Windows (WDS) 7 décembre 2012 Dans ce document, vous trouverez une description détaillée des étapes à suivre pour installer les différents rôles sur votre poste Windows Server. Ce

Plus en détail

Master Informatique. Master Informatique 1ère année 1 er sem. Anonymat : Numéro à coller. Examen Réparti 2 : ARES 2010-2011

Master Informatique. Master Informatique 1ère année 1 er sem. Anonymat : Numéro à coller. Examen Réparti 2 : ARES 2010-2011 Master Informatique ère année er sem. Anonymat : Numéro à coller Master Informatique ère année er sem. Examen Réparti : ARES 0- Durée totale: h00 Autorisé: Une feuille A4 manuscrite Non autorisés: Autres

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

L évolution vers la virtualisation

L évolution vers la virtualisation L évolution vers la virtualisation Dépassez vos attentes en matière de solutions TI. L évolution vers la virtualisation En 2009, la majorité des entreprises québécoises ne s interrogent plus sur la pertinence

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

Gestion de Répliques dans les Grilles de Données

Gestion de Répliques dans les Grilles de Données Gestion de Répliques dans les Grilles de Données Mohamed Redha Djebbara*, Hafida Belbachir** *Ecole Supérieur d Informatique ESI (ex INI) Oued Semar Alger m_djebbara@esi.dz **Lab LSSD Université des Sciences

Plus en détail

Algorithmique distribuée d exclusion mutuelle : vers une gestion efficace des ressources

Algorithmique distribuée d exclusion mutuelle : vers une gestion efficace des ressources Algorithmique distribuée d exclusion mutuelle : vers une gestion efficace des ressources Jonathan Lejeune LIP6-UPMC/CNRS, Inria 19 septembre 2014 Directeur : Pierre Sens Encadrants : Luciana Arantes et

Plus en détail

Introduction à l'algorithmique Distribuée. Accord & coordination : consensus & transaction

Introduction à l'algorithmique Distribuée. Accord & coordination : consensus & transaction Introduction à l'algorithmique Distribuée Accord & coordination : consensus & transaction Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Accord

Plus en détail

Le modèle client-serveur

Le modèle client-serveur Le modèle client-serveur Olivier Aubert 1/24 Sources http://www.info.uqam.ca/~obaid/inf4481/a01/plan.htm 2/24 Historique architecture centralisée terminaux passifs (un seul OS, systèmes propriétaires)

Plus en détail

Architecture de join.me

Architecture de join.me Présentation technique de l architecture sécurisée et fiable de join.me 1 Introduction 2 Présentation de l architecture 3 Sécurité des données 4 Sécurité des sessions et du site web 5 Présentation de l

Plus en détail

Réseaux grande distance

Réseaux grande distance Chapitre 5 Réseaux grande distance 5.1 Définition Les réseaux à grande distance (WAN) reposent sur une infrastructure très étendue, nécessitant des investissements très lourds. Contrairement aux réseaux

Plus en détail

Cible de sécurité CSPN

Cible de sécurité CSPN Cible de sécurité CSPN ClearBUS Application cliente pour la communication sécurisée Version 1.12 Le 25/11/2011 Identifiant : CBUS-CS-1.12-20111125 contact@clearbus.fr tel : +33(0)485.029.634 Version 1.12

Plus en détail

ViSaGe. Virtualisation du Stockage dans les Grilles. Informatiques. RenPar 16, 6-8 Avril 2005 Thiebolt François thiebolt@irit.fr

ViSaGe. Virtualisation du Stockage dans les Grilles. Informatiques. RenPar 16, 6-8 Avril 2005 Thiebolt François thiebolt@irit.fr 1 ViSaGe Virtualisation du Stockage dans les Grilles Informatiques RenPar 16, 6-8 Avril 2005 Thiebolt François thiebolt@irit.fr IRIT Projet RNTL labellisé pré-compétitif Solution ViSaGe ViSaGe Accès transparent

Plus en détail

Évolution de la puissance des machines. Système pour architectures multicœurs. Évolution de la puissance des machines

Évolution de la puissance des machines. Système pour architectures multicœurs. Évolution de la puissance des machines Évolution de la puissance des machines Accélération Système pour architectures multicœurs Évolution Traditionnelle des mono-processeurs CSC5001 : Systèmes Hautes Performances Architecte de Services informatiques

Plus en détail

Clusters for Application Service Providers. T. Monteil, J.M. Garcia P. Pascal, S. Richard

Clusters for Application Service Providers. T. Monteil, J.M. Garcia P. Pascal, S. Richard Clusters for Application Service Providers (www.laas.fr/casp) T. Monteil, J.M. Garcia P. Pascal, S. Richard 1 Généralités Le monde du calcul dans un environnement ASP Les ASP : Application Service Provider

Plus en détail

Serveurs de noms Protocoles HTTP et FTP

Serveurs de noms Protocoles HTTP et FTP Nils Schaefer Théorie des réseaux (EC3a) Serveurs de noms Protocoles HTTP et FTP Théorie des réseaux (EC3a) Séance 7 Pourquoi DNS? Internet est une structure hiérarchique et arborescente de réseaux et

Plus en détail

Multi-processeurs, multi-cœurs et cohérence mémoire et cache

Multi-processeurs, multi-cœurs et cohérence mémoire et cache Multi-processeurs, multi-cœurs et cohérence mémoire et cache Intervenant : Thomas Robert Institut Mines-Télécom Rappel système d exploitation & Parallélisme L unité d exécution pour un système d exploitation

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

Chapitre 5. Communication interprocessus. 5.1 Introduction

Chapitre 5. Communication interprocessus. 5.1 Introduction Communication interprocessus 5.1 Introduction Dans une activité parallèle (ou pseudo parallèle), un ensemble de processus séquentiels s exécutent en parallèle. Cette exécution résulte deux types de relations

Plus en détail

EXIN Cloud Computing Foundation

EXIN Cloud Computing Foundation Exemple d examen EXIN Cloud Computing Foundation Édition Septembre 2012 Droits d auteur 2012 EXIN Tous droits réservés. Aucune partie de cette publication ne saurait être publiée, reproduite, copiée, entreposée

Plus en détail

Cluster High Availability. Holger Hennig, HA-Cluster Specialist

Cluster High Availability. Holger Hennig, HA-Cluster Specialist Cluster High Availability Holger Hennig, HA-Cluster Specialist TABLE DES MATIÈRES 1. RÉSUMÉ...3 2. INTRODUCTION...4 2.1 GÉNÉRALITÉS...4 2.2 LE CONCEPT DES CLUSTERS HA...4 2.3 AVANTAGES D UNE SOLUTION DE

Plus en détail

Les systèmes RAID Architecture des ordinateurs

Les systèmes RAID Architecture des ordinateurs METAIS Cédric 2 ème année Informatique et réseaux Les systèmes RAID Architecture des ordinateurs Cédric METAIS ISMRa - 1 - LES DIFFERENTS SYSTEMES RAID SOMMAIRE INTRODUCTION I LES DIFFERENTS RAID I.1 Le

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

Plus en détail

Localisation des médias Systèmes Pair-à-pair

Localisation des médias Systèmes Pair-à-pair Localisation des médias Systèmes Pair-à-pair Partie 3 Deux problèmes de localisation Où placer le média? les CDNs Comment trouver le média? les DHTs 1 Où placer le média? Gros fichiers et forte demande

Plus en détail

COMMENT FONCTIONNENT LES SWITCHS ET ROUTEURS?

COMMENT FONCTIONNENT LES SWITCHS ET ROUTEURS? COMMENT FONCTIONNENT LES SWITCHS ET ROUTEURS? Mewtow 29 octobre 2015 Table des matières 1 Introduction 5 2 Switchs 7 2.1 Micro-architecture des switchs........................... 7 2.1.1 Switching..................................

Plus en détail

NOTIONS DE RESEAUX INFORMATIQUES

NOTIONS DE RESEAUX INFORMATIQUES NOTIONS DE RESEAUX INFORMATIQUES GENERALITES Définition d'un réseau Un réseau informatique est un ensemble d'équipements reliés entre eux afin de partager des données, des ressources et d'échanger des

Plus en détail

Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization)

Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization) Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization) Préparé par : Zeus Kerravala Les cinq raisons majeures pour déployer SDN et NFV NetworkWorld,

Plus en détail

Stockage : capacité, performances

Stockage : capacité, performances Stockage : capacité, performances Intervenant :Thomas Robert C234-4 thomas.robert@telecom-paristech.fr Transparents : Thomas Robert Institut Mines-Télécom Lectures possibles Chapitre 7.2 de : http://ceit.aut.ac.ir/~amirkhani/

Plus en détail

Rapidité, économies et sécurité accrues : comment améliorer la souplesse, le coût total de possession (TCO) et la sécurité grâce à une planification

Rapidité, économies et sécurité accrues : comment améliorer la souplesse, le coût total de possession (TCO) et la sécurité grâce à une planification Rapidité, économies et sécurité accrues : comment améliorer la souplesse, le coût total de possession (TCO) et la sécurité grâce à une planification des tâches sans agent Livre blanc rédigé pour BMC Software

Plus en détail

L'architecture Mesh. frati@nyx.unice.fr

L'architecture Mesh. frati@nyx.unice.fr L'architecture Mesh frati@nyx.unice.fr On connaissait déjà le mode sans infrastructure : le mode Ad-Hoc mode habituel pour connecter deux ordinateurs entre eux (d égal à égal) permettant des partages de

Plus en détail