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

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

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

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

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

Un service hiérarchique distribué de partage de données pour grille

Un service hiérarchique distribué de partage de données pour grille Fribourg, Suisse, du 11 au 1 février 008 Un service hiérarchique distribué de partage de données pour grille Loïc Cudennec IRISA, INRIA Rennes, Campus universitaire de Beaulieu, 504 RENNES - France loic.cudennec@irisa.fr

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

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

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

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

Introduction aux systèmes d exploitation

Introduction aux systèmes d exploitation Introduction aux systèmes d exploitation Le système d exploitation est un ensemble de logiciels qui pilotent la partie matérielle d un ordinateur. Les principales ressources gérées par un système d exploitation

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

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

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

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

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

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

Cours CCNA 1. Exercices

Cours CCNA 1. Exercices Cours CCNA 1 TD3 Exercices Exercice 1 Enumérez les sept étapes du processus consistant à convertir les communications de l utilisateur en données. 1. L utilisateur entre les données via une interface matérielle.

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

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

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

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

Alcatel-Lucent VitalQIP Appliance Manager

Alcatel-Lucent VitalQIP Appliance Manager Alcatel-Lucent Appliance Manager Solution complète de gestion des adresses IP et de bout en bout basée sur des appliances Rationalisez vos processus de gestion et réduisez vos coûts d administration avec

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

Concours interne d ingénieur des systèmes d information et de communication. «Session 2010» Meilleure copie "étude de cas architecture et systèmes"

Concours interne d ingénieur des systèmes d information et de communication. «Session 2010» Meilleure copie étude de cas architecture et systèmes Concours interne d ingénieur des systèmes d information et de communication «Session 2010» Meilleure copie "étude de cas architecture et systèmes" Note obtenue : 14,75/20 HEBERGE-TOUT Le 25 mars 2010 A

Plus en détail

WAN (Wide Area Network) : réseau à l échelle d un pays, généralement celui des opérateurs. Le plus connu des WAN est Internet.

WAN (Wide Area Network) : réseau à l échelle d un pays, généralement celui des opérateurs. Le plus connu des WAN est Internet. 1 Définition Réseau (informatique) : ensemble d ordinateurs et de terminaux interconnectés pour échanger des informations numériques. Un réseau est un ensemble d'objets interconnectés les uns avec les

Plus en détail

Projet OpNet. Spécialité Réseaux 2003/2004 Yannick GRENZINGER Loic JAQUEMET

Projet OpNet. Spécialité Réseaux 2003/2004 Yannick GRENZINGER Loic JAQUEMET Projet OpNet Spécialité Réseaux 2003/2004 Yannick GRENZINGER Loic JAQUEMET 1Présentation...3 1.1Le besoin de mobilité...3 1.2Le protocole IP Mobile...4 1.3Opnet...5 1.4Le projet...6 2La réalisation du

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

MEAD : temps réel et tolérance aux pannes pour CORBA

MEAD : temps réel et tolérance aux pannes pour CORBA MEAD : un intergiciel temps-réel et tolérant aux pannes pour CORBA Master 2 Informatique Recherche Université de Marne-la-Vallée Vendredi 3 mars 2006 Plan 1 Introduction 2 Solutions existantes 3 Concilier

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

Fiche technique WS2012

Fiche technique WS2012 Le 18/03/013 OBJECTIF VIRTUALISATION mathieuc@exakis.com EXAKIS NANTES Identification du document Titre Projet Date de création Date de modification Fiche technique Objectif 18/03/2013 26/03/2013 WS2012

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

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

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

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

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

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système Présentation Diapo01 Je m appelle Michel Canneddu. Je développe avec 4D depuis 1987 et j exerce en tant qu indépendant depuis 1990. Avant de commencer, je tiens à remercier mes parrains Jean-Pierre MILLIET,

Plus en détail

Historique. Évolution des systèmes d exploitation (à travers les âges)

Historique. Évolution des systèmes d exploitation (à travers les âges) Historique Évolution des systèmes d exploitation (à travers les âges) Historique L histoire des systèmes d exploitation permet de dégager des concepts de base que l on retrouve dans les systèmes actuels

Plus en détail

CREER ET FORMATER UNE PARTITION DE DISQUE DUR 1 QUE SONT LES PARTITIONS ET LES LECTEURS LOGIQUES? 6

CREER ET FORMATER UNE PARTITION DE DISQUE DUR 1 QUE SONT LES PARTITIONS ET LES LECTEURS LOGIQUES? 6 Table des matières. CREER ET FORMATER UNE PARTITION DE DISQUE DUR 1 QUE SONT LES PARTITIONS ET LES LECTEURS LOGIQUES? 6 QUE SONT LES DISQUES DE BASE ET LES DISQUES DYNAMIQUES? 6 FORMATAGE DES DISQUES ET

Plus en détail

Chap. III : Le système d exploitation

Chap. III : Le système d exploitation UMR 7030 - Université Paris 13 - Institut Galilée Cours Architecture et Système Le système d exploitation (ou O.S. de l anglais Operating System ) d un ordinateur est le programme qui permet d accéder

Plus en détail

Architecture serveur de pages (2) Bilan architecture serveur de pages. Architecture multi-serveur. Pertes de mise à jour

Architecture serveur de pages (2) Bilan architecture serveur de pages. Architecture multi-serveur. Pertes de mise à jour Introduction Chapitre 5. Implémentation des SGBDO 1 architectures client/serveur 2 concurrence, pannes 3 Quelques SGBDRO 4 Quelques SGBDOO années 80 : serveur : BD client : applications et langages appel

Plus en détail

Chapitre V : La gestion de la mémoire. Hiérarchie de mémoires Objectifs Méthodes d'allocation Simulation de mémoire virtuelle Le mapping

Chapitre V : La gestion de la mémoire. Hiérarchie de mémoires Objectifs Méthodes d'allocation Simulation de mémoire virtuelle Le mapping Chapitre V : La gestion de la mémoire Hiérarchie de mémoires Objectifs Méthodes d'allocation Simulation de mémoire virtuelle Le mapping Introduction Plusieurs dizaines de processus doivent se partager

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

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

HAUTE DISPONIBILITE & CONTINUITÉ DE SERVICE MULTI PLATES FORMES. Simple & Performant. www.quick software line.com

HAUTE DISPONIBILITE & CONTINUITÉ DE SERVICE MULTI PLATES FORMES. Simple & Performant. www.quick software line.com HAUTE DISPONIBILITE & CONTINUITÉ DE SERVICE MULTI PLATES FORMES Haute disponibilité pour Serveurs Ouverts (Windows, UNIX, AIX, Linux, VMware (Windows, UNIX, AIX, Linux, VMware ) Généralités Quelques définitions

Plus en détail

Internet. PC / Réseau

Internet. PC / Réseau Internet PC / Réseau Objectif Cette présentation reprend les notions de base : Objectif, environnement de l Internet Connexion, fournisseurs d accès Services Web, consultation, protocoles Modèle en couches,

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

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS Une collaboration entre homme et machine LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS 2 A PROPOS Les hommes

Plus en détail

Cours CCNA 1. Exercices

Cours CCNA 1. Exercices Cours CCNA 1 TD1 Exercices Exercice 1 : Décrivez les facteurs internes qui ont un impact sur les communications réseau. Les facteurs internes ayant un impact sur les communications sont liés à la nature

Plus en détail

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Oussama ELKACHOINDI Wajdi MEHENNI RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Sommaire I. Préliminaire : Notice d exécution et mode opératoire...4 II. Architecture globale de l application...5

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

Archives et factures électroniques

Archives et factures électroniques Archives et factures électroniques Edito En 2001, le Conseil de l Union Européenne a publié la Directive 2001/115/CE relative à la facturation. Son objectif était de simplifier, de moderniser et d harmoniser

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

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

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

Dépannage du réseau (S4/C8) Documenter le réseau

Dépannage du réseau (S4/C8) Documenter le réseau Dépannage du réseau (S4/C8) b Documenter le réseau Pour corriger et diagnostiquer des problèmes réseau efficacement, un ingénieur réseau doit savoir comment le réseau a été conçu et connaitre les performances

Plus en détail

VMware vsphere 5 Maîtrisez l exploitation de votre infrastructure virtuelle

VMware vsphere 5 Maîtrisez l exploitation de votre infrastructure virtuelle 212 VMware vsphere 5 Maîtrisez l exploitation de votre infrastructure virtuelle Quoi qu'il en soit, gardez à l esprit que nous n avons pas voulu favoriser une technologie en particulier. Cependant, nous

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

Laboratoire PRiSM, CNRS UMR 8144 Université de Versailles St-Quentin

Laboratoire PRiSM, CNRS UMR 8144 Université de Versailles St-Quentin Horodatage Sécurisé J.M. Fourneau Laboratoire PRiSM, CNRS UMR 8144 Université de Versailles St-Quentin M2 ASS-ACSIS 2008, Université de Versailles St Quentin [1/25] Horodatage Sécurisé Le service d horodatage

Plus en détail

Portage de l architecture sécurisée CryptoPage sur un microprocesseur x86

Portage de l architecture sécurisée CryptoPage sur un microprocesseur x86 Portage de l architecture sécurisée CryptoPage sur un microprocesseur x86 Guillaume Duc Ronan Keryell Département Informatique École Nationale Supérieure des Télécommunications de Bretagne Symposium en

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

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

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 4: l approche processus et le management du système d informations

Plus en détail

La sécurité informatique

La sécurité informatique 1 La sécurité informatique 2 Sécurité des systèmes d information Yves Denneulin (ISI) et Sébastien Viardot(SIF) Cadre du cours Informatique civile (avec différences si publiques) Technologies répandues

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

Concept des VLAN Introduction au VLAN virtuel

Concept des VLAN Introduction au VLAN virtuel Les VLAN Sommaire 1.Concept des VLAN 1.1.Introduction au VLAN virtuel 1.2.Domaines de broadcast avec VLAN et routeurs 1.3.Fonctionnement d un VLAN 1.4.Avantages des LAN virtuels (VLAN) 1.5.Types de VLAN

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

Introduction. La gestion des qualités de services dans Internet. La garantie de QoS. Exemple

Introduction. La gestion des qualités de services dans Internet. La garantie de QoS. Exemple Introduction Aujourd hui les applications (en particulier multimédia) nécessitent des qualités de service de natures très différentes La gestion des qualités de services dans Internet Exemples: Transfert

Plus en détail

Objectifs du cours. Master mention Informatique M1. Construction d Applications Réparties. Sommaire. Organisation.

Objectifs du cours. Master mention Informatique M1. Construction d Applications Réparties. Sommaire. Organisation. Master mention Informatique M1 Construction d s Réparties Lionel Seinturier USTL-LIFL Équipe GOAL/Projet INRIA Jacquard Lionel.Seinturier@lifl.fr 2006/2007 1 Objectifs du cours Appréhender la conception

Plus en détail

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

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

Le Pair-à-pair et les Nouvelles Applications de l Internet. Christian Huitema Architecte Windows Networking & Communications Microsoft Corporation

Le Pair-à-pair et les Nouvelles Applications de l Internet. Christian Huitema Architecte Windows Networking & Communications Microsoft Corporation Le Pair-à-pair et les Nouvelles Applications de l Internet Christian Huitema Architecte Windows Networking & Communications Microsoft Corporation Welcome to 3 Degrees, P2P & IPv6 26 juin 2003 2 Pair-a-pair

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

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

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

Utilisation de l application. Introduction à asa-control. Connexion à l application. Plus facile que tu ne le penses.

Utilisation de l application. Introduction à asa-control. Connexion à l application. Plus facile que tu ne le penses. asa-control Introduction à asa-control Utilisation de l application Plus facile que tu ne le penses. Tu travailles avec la souris et effectues toujours les mêmes étapes. Connexion à l application Choisis

Plus en détail

Les Virtual LAN. F. Nolot. Master 1 STIC-Informatique 1

Les Virtual LAN. F. Nolot. Master 1 STIC-Informatique 1 Les Virtual LAN Master 1 STIC-Informatique 1 Les Virtual LAN Introduction Master 1 STIC-Informatique 2 Les Réseaux Locaux Virtuels (VLAN) Avantages des LAN Communication rapide, broadcasts Problèmes des

Plus en détail

Découverte et investigation des menaces avancées INFRASTRUCTURE

Découverte et investigation des menaces avancées INFRASTRUCTURE Découverte et investigation des menaces avancées INFRASTRUCTURE AVANTAGES CLÉS Infrastructure RSA Security Analytics Collecte distribuée grâce à une architecture modulaire Solution basée sur les métadonnées

Plus en détail

Systèmes d Information Avancés (et répartis)

Systèmes d Information Avancés (et répartis) Systèmes d Information Avancés (et répartis) Université Lyon 1 MIAGE L. Médini, mars 2005 Plan des cours Protocole HTTP et programmation serveur Architectures réparties Objets distribués Introduction aux

Plus en détail

Module 7 : Crashs d Excel

Module 7 : Crashs d Excel Module 7 : Crashs d Excel 7.0 Introduction La plupart des utilisateurs d Excel ont probablement été confrontés à des ralentissements ou à un blocage, accompagné du redoutable message «Microsoft Excel a

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

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

Réplication de données de classe entreprise pour environnements distribués et reprise sur sinistre

Réplication de données de classe entreprise pour environnements distribués et reprise sur sinistre Réplication de données de classe entreprise pour environnements distribués et reprise sur sinistre La tendance actuelle vers une conception distribuée de l entreprise, avec des agences, des centres de

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 09 : CC : Cloud Computing Sommaire Introduction... 2 Définition... 2 Les différentes

Plus en détail

LA GESTION D ASTREINTE White Paper

LA GESTION D ASTREINTE White Paper LA GESTION D ASTREINTE White Paper GENERALITES SUR LA GESTION D ASTREINTE :... 2 POURQUOI METTRE EN PLACE UNE GESTION D ASTREINTE AUTOMATISEE?... 2 LA TRANSMISSION DE L INFORMATION, LE NERF DE LA GESTION

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

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Notions de base sur les réseaux Chapitre 6 01 Regardez le schéma d adressage IP illustré. Quel préfixe réseau y est adapté? /24 /16 /20 /27 /25 /28 02 Parmi

Plus en détail

Le filtrage de niveau IP

Le filtrage de niveau IP 2ème année 2008-2009 Le filtrage de niveau IP Novembre 2008 Objectifs Filtrage : Le filtrage permet de choisir un comportement à adopter vis à vis des différents paquets émis ou reçus par une station.

Plus en détail

Pair-à-Pair: Architectures et Services

Pair-à-Pair: Architectures et Services Pair-à-Pair: Architectures et Services Fabrice Le Fessant Fabrice.Le_Fessant@inria.fr Équipe ASAP (Réseaux très large échelle) INRIA Saclay Île de France Octobre 2008 Fabrice Le Fessant () Architectures

Plus en détail

ITIL V2 Processus : La Gestion des Configurations

ITIL V2 Processus : La Gestion des Configurations ITIL V2 Processus : La Gestion des Configurations Auteur: Fabian PIAU, Master 2 MIAGE, Nantes La Gestion des Configurations est un processus issu d ITIL version 2 qui aide au soutien du service («Service

Plus en détail

Systèmes de fichiers distribués : comparaison de GlusterFS, MooseFS et Ceph avec déploiement sur la grille de calcul Grid 5000.

Systèmes de fichiers distribués : comparaison de GlusterFS, MooseFS et Ceph avec déploiement sur la grille de calcul Grid 5000. : comparaison de, et avec déploiement sur la grille de calcul Grid 5000. JF. Garcia, F. Lévigne, M. Douheret, V. Claudel 30 mars 2011 1/34 Table des Matières 1 2 3 4 5 6 7 1/34 Présentation du sujet Présentation

Plus en détail

Systèmes d'exploitation Chapitre 3: Gestion de fichiers

Systèmes d'exploitation Chapitre 3: Gestion de fichiers Université Cadi Ayyad Faculté Polydisciplinaire de Safi Département sciences mathématiques et informatique Systèmes d'exploitation Chapitre 3: Gestion de fichiers Le stockage fiable, rapide de grandes

Plus en détail

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+ Guide de formation avec exercices pratiques Configuration et dépannage de PC Préparation à la certification A+ Sophie Lange Troisième édition : couvre Windows 2000, Windows XP et Windows Vista Les Guides

Plus en détail

Administration via l'explorateur WebSphere MQ

Administration via l'explorateur WebSphere MQ Ce document présente l utilisation de l Explorateur WebSphere MQ, et en particulier sa capacité à administrer des Queue Manager distants. Il aborde également les problèmes de sécurité liés à l administration

Plus en détail

Base de données. Objectifs du cours 2014-05-20 COURS 01 INTRODUCTION AUX BASES DE DONNÉES

Base de données. Objectifs du cours 2014-05-20 COURS 01 INTRODUCTION AUX BASES DE DONNÉES 1 Base de données COURS 01 INTRODUCTION AUX BASES DE DONNÉES Objectifs du cours 2 Introduction aux bases de données relationnelles (BDR). Trois volets seront couverts : la modélisation; le langage d exploitation;

Plus en détail

UFR de Mathématiques et Informatique Année 2009/2010. Réseaux Locaux TP 04 : ICMP, ARP, IP

UFR de Mathématiques et Informatique Année 2009/2010. Réseaux Locaux TP 04 : ICMP, ARP, IP Université de Strasbourg Licence Pro ARS UFR de Mathématiques et Informatique Année 2009/2010 1 Adressage IP 1.1 Limites du nombre d adresses IP 1.1.1 Adresses de réseaux valides Réseaux Locaux TP 04 :

Plus en détail

Bases de données réparties

Bases de données réparties Bases de données réparties J. Akoka - I. Wattiau 1 Contexte Technologique : des solutions de communication efficace entre les machines des SGBD assurent la transparence des données réparties standardisation

Plus en détail