Gestion de données dans les NES

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

Download "Gestion de données dans les NES"

Transcription

1 Gestion de données dans les NES E. Caron, F. Desprez, A. Vernois B. Del-Fabbro LIP/ENS-Lyon LIFC Introduction Les problèmes de très grande taille issus de la simulation numérique peuvent désormais être résolus via Internet grâce aux environnements de type Grilles [6]. De nombreuses approches coexistent qui ont chacune leurs avantages et leurs inconvénients. Par ailleurs, l approche ASP (Application Service Provider) permet d accéder à des applications à distance grâce à des intergiciels adaptés. Dans ce paradigme, un client peut demander l exécution de requêtes à un agent chargé de trouver le serveur le plus adapté en terme de performance ou de fonctionnalité. Les requêtes peuvent alors être exécutées par des serveurs séquentiels ou parallèles. Ce paradigme est proche du modèle RPC (Remote Procedure Call ou appel de procédure à distance). L approche GridRPC [8] est la forme grille du RPC Unix classique. On appelle généralement ces environnements qui les réalisent des serveurs de calculs ou NES (Network Enabled Servers). Plusieurs outils offrant cette fonctionnalité comme NetSolve, NINF 2, DIET 3, NEOS 4, ou RCS [2] sont déjà disponibles. Le GridRPC implique que les données sont envoyées du client vers le serveur qui réalise le calcul et le résultat revient du serveur vers le client. Si des dépendances existent entre les requêtes, des transferts de données inutiles sont effectués et ce coût prohibitif diminue l intérêt d une telle approche. Il convient donc de gérer au mieux ces dépendances en laissant tant que possible les données sur les serveurs sur lesquels elles ont été utilisées (ou calculées). Ceci nécessite une gestion de données efficace et surtout extensible vu le nombre de serveurs et de clients généralement traités par ce type d environnement. Cet article présente donc l architecture de plusieurs NES (NetSolve, Ninf et DIET) ainsi que les problèmes de gestion de données qui leurs sont propres. Dans une première section, nous présentons l API GridRPC proposée dans le cadre du Global Grid Forum pour permettre de gérer la persistance des données au niveau du client. Dans une seconde section, nous présentons l architecture des trois environnements de type NES disponibles actuellement et qui implémentent le standard GridRPC. Enfin, dans la troisième section et avant une conclusion et une description de nos travaux futurs, nous présentons les solutions choisies par Ninf, NetSolve et DIET pour gérer les données. 2 L approche GRID-RPC et la gestion de la persistance Dans le cadre du Global Grid Forum, les chercheurs des projets NetSolve, Ninf et DIET ont proposé une interface standard pour l API client. Cette API permettra d avoir une bonne portabilité entre les différents systèmes. Nous allons nous focaliser sur la partie gestion de données de cette interface qui est en cours de discussion au sein du GGF. L interface générale pour les demandes d exécution de requêtes peut être trouvée sur le site du GGF. Un aspect naturellement important de la définition d une telle interface est la définition

2 de la possibilité de laisser les données calculées sur les serveurs afin de réduire le coût des communications. Il va de soit que ceci doit être le plus transparent possible pour les clients finaux mais un ordonnanceur intelligent devra être capable de dire au système si telle donnée doit être laissée ou pas sur tel ou tel serveur en fonction des dépendances entre les requêtes. Cette proposition part du postulat que chaque donnée doit être identifiée au sein de la plate-forme. Nous définissons donc le data handle (DH) comme étant une référence à une donnée qui peut être stockée à n importe quel endroit. Ainsi, cette définition du data handle permet de gérer la lecture et l écriture des données sans avoir à se préoccuper d où elles proviennent ni d où elles seront stockées. L opération de création du data handle est réalisée par la fonction create(data handle t *dh); Une fois que la référence à la donnée est créée, il est possible de lier ou pas cette référence à une donnée. Si on lie la donnée, elle peut être soit présente chez le client, soit présente sur un serveur de dépôt. Sinon cela signifie que la donnée est déjà présente dans la plate-forme. L opération de liaison d une donnée à une référence permet aussi de préciser si la donnée doit être conservée ou non. Cette opération est réalisée par la fonction bind(data handle t dh, data loc t loc, data site t site); data loc t loc : permet de connaître la localisation de la donnée (machine locale ou serveur de dépôt), data site t site : la localisation de la machine où l on veut stocker la donnée, sachant que si cette valeur est nulle la donnée sera stockée sur le dernier serveur d exécution l ayant utilisé. Ainsi, du coté du serveur de calcul, si le data handle contient un site identique au loc, la donnée doit être retournée au client ou au serveur de stockage référencé. En revanche, si le data handle contient un site différent du loc, la donnée sera déplacée du loc vers le site référencé par site. La Figure montre un exemple d utilisation de l interface de gestion de données dans l API GridRPC. Dans cette figure, un client exécute un premier calcul sur un serveur capable d exécuter le service demandé et un second calcul sur un autre serveur plus performant. Pour ce second calcul, le client n a pas à renvoyer sa donnée puisqu elle se trouve déjà sur le réseau. CLIENT SERVICE A SERVICE B create input data create input_dh bind input_dh to input data create output_dh call(input_dh, output_dh) Note : output_dh is unbound read input_dh create output2_dh bind output2_dh to client data sent return bound output_dh call(output_dh, output2_dh) EXECUTE SERVICE create output data bind out. data to output_dh (output data still available on this server) read output_dh data sent write data on output2_dh EXECUTE SERVICE Fig. Exemple d utilisation de l API GridRPC avec gestion de données intégrée. 3 Architecture de trois environnements de type NES 3. Ninf et NetSolve NetSolve est un NES développé au laboratoire ICL de l Université du Tennessee. Ninf quant à lui est développé au Tokyo Institute of Technology. Ces deux NES sont très similaires dans leur conception. Ils sont

3 basés tous deux sur trois composants principaux : les clients, l agent et les serveurs de calcul. Clients : Ils sont construits en utilisant des bibliothèques qui offrent une API (basée sur le GridRPC) permettant d accéder aux ressources de calculs gérées par l agent. Actuellement, il est possible d interfacer NetSolve dans du code C, FORTRAN, Matlab et Mathematica et Ninf avec du C, du FORTRAN et du Java. Agent : Composant central qui maintient à jour les informations concernant les serveurs, leurs possibilités ainsi que les statistiques d utilisation. C est lui qui reçoit les requêtes des clients et alloue au mieux les ressources de calcul des serveurs à ces requêtes pour que celles-ci soient exécutées le plus rapidement possible. Serveurs : Les serveurs de calcul sont la puissance de traitement de NetSolve ou de Ninf. Ils sont gérés par l agent et sont en mesure de résoudre un certain nombre de problèmes. La liste des problèmes qu un serveur sait résoudre est maintenue par l agent. Les communications entre les composants se font via un protocole de communication spécifique au niveau applicatif construit au dessus de TCP/IP. 3.2 DIET Client Fig. 2 Vue générale de DIET. Dans cette section, nous donnons des détails sur l architecture de DIET et nous présentons les différents composants impliqués dans sa hiérarchie. Dans [8], les auteurs donnent un état de l art des environnements basés sur des NES qui permettent d accéder à des serveurs de calcul via le réseau. Si l on rentre dans les détails, de tels environnements sont composés de cinq types de composants différents : les clients qui soumettent les problèmes aux serveurs, les serveurs qui résolvent les problèmes soumis par les clients, des moniteurs qui récupèrent des informations sur l état des ressources de calcul et les stockent dans une base de données qui contient aussi des informations concernant les ressources matérielles et logicielles, et enfin un ordonnanceur (appelé agent dans notre architecture) qui choisit un serveur approprié en fonction du problème soumis et des informations contenues dans la base de données. Les projets NetSolve ou Ninf suivent cette approche. Malheureusement, il n est possible de lancer qu un seul agent chargé de l ordonnancement pour un groupe de serveurs de calculs donnés 5. Cela crée un goulot d étranglement des performances empêchant le déploiement de NetSolve pour de grands groupes de serveurs, et rend le système peu résistant aux erreurs. En effet, la mort du processus agent rend inutilisable la plate-forme toute entière. Pour résoudre ces problèmes, DIET se propose de répartir le travail de l agent selon une nouvelle organisation. Il est ainsi remplacé par un ensemble d agents organisés selon deux approches : une approche multi-agents de type pair-à-pair améliorant la robustesse du système associé et une approche hiérarchique favorisant l efficacité de l ordonnancement. Cette répartition du rôle de l agent offre divers avantages. Tout d abord, on a une meilleure répartition de la charge entre les différents agents et une plus grande stabilité du système (si un des éléments venait à s arrêter, les autres éléments pourraient se réorganiser pour le remplacer). Enfin, on obtient également une gestion simplifiée en cas de passage à l échelle (l administration de chaque groupe de serveurs et des agents associés peut être déléguée) Les composants de DIET Un client est une application qui utilise DIET pour résoudre des problèmes. Plusieurs types de clients doivent être capables de se connecter à DIET. Un problème peut être soumis depuis une page web, un environnement de résolution de problèmes tel que Scilab [4] ou Matlab ou depuis un programme compilé. Un Master Agent () est directement relié aux clients. Il reçoit des requêtes de calcul des clients et choisit un (ou plusieurs) s qui sont capables de résoudre le problème en un temps raisonnable. Un possède les mêmes informations qu un, mais il a une vue globale (et de haut niveau) de tous les problèmes qui peuvent être résolus et de toutes les données qui sont distribuées dans tous ses sous-arbres. 5 A part pour une version de Ninf qui possède plusieurs agents (Metaserver) mais ceux-ci ont une connaissance globale de tout l environnement grâce à des diffusions des informations.

4 Un Leader Agent () compose un niveau hiérarchique dans les agents DIET. Il peut être le lien entre un Master Agent et un, entre un autre et un ou entre deux s. Son but est de diffuser les requêtes et les informations entre les s et les s. Il tient à jour une liste des requêtes en cours de traitement et, pour chacun de ses sous-arbres, le nombre de serveurs pouvant résoudre un problème donné, ainsi que des informations à propos des données. Un Server Daemon () est le point d entrée d un serveur de calcul. Il se trouve sous la responsabilité d un. Il tient à jour une liste des données disponibles sur un serveur (éventuellement avec leur distribution et le moyen d y accéder), une liste des problèmes qui peuvent y être résolus, et toutes les informations concernant sa charge. Sur une machine parallèle, un sera donc installé sur le frontal de cette machine. La plate-forme cible actuelle de DIET est le réseau rapide connectant les grappes et les machines parallèles des différentes unités de recherche de l INRIA (projet RNRT VTHD 6 ). Cette architecture est donc fortement hiérarchique puisque le réseau VTHD connecte les UR INRIA entre elles, qui elles-mêmes possèdent dans leurs réseaux propres des grappes de machines connectées par des réseaux plus ou moins rapides. Les machines d où sont lancées les calculs sont soit directement connectées au réseau VTHD ou simplement connectées par les réseaux internes des laboratoires ayant accès à cette plate-forme Mode de fonctionnement Un nouveau client de DIET doit d abord contacter un Master Agent (le plus approprié : en distance réseau par exemple) et lui soumettre un problème. Pour choisir le serveur le plus approprié pour résoudre ce problème, le Master Agent propage une requête dans ses sous-arbres 7 afin de trouver à la fois les données impliquées (parfois issues de calculs précédents et donc déjà présentes sur certains serveurs lorsque la persistance est activée) et les serveurs capables de résoudre l opération demandée. Lorsque la requête arrive au niveau des s, ces derniers interrogent les capables de résoudre le problème afin de récupérer l évaluation des temps de calcul et de communication via notre outil de prédiction de performance FAST [9]. Si le serveur, dispose d une donnée utile au calcul il en informe également le. Les choix d ordonnancement se font alors à chaque niveau de l arbre lors de la remontée de la réponse au. Lors de cette remontée, notons que les agents attendent les réponses de leurs fils pendant un certain laps de temps au delà duquel elles sont ignorées. Cet état de fait ne permet pas de tirer des conséquences quant à une panne éventuelle d un agent qui ne répond pas ou pas assez vite. Lorsque la réponse revient au Master Agent, il renvoie l adresse du serveur choisi au client (il est également possible de renvoyer une liste bornée des meilleurs serveurs au client). Le envoie ensuite l ordre de migrer les données. Le transfert des données s effectue alors en deux phases pouvant être exécutées en parallèle : transfert des données issues du client et éventuellement le transfert des données persistantes localisées sur un autre serveur. Une fois les données récupérées la résolution du calcul peut être effectuée. Les résultats pourront être renvoyés au client. Pour des questions de performances, DIET essaye autant que possible de laisser les données sur place. 4 Gestion de données dans les NES 4. NetSolve et Ninf Plusieurs approches ont été utilisées pour la gestion de données dans NetSolve. Dans un premier temps, en collaboration avec E. Jeannot, nous avons intégré un certain nombre de fonctions permettant de laisser les données sur place puis de les déplacer [7]. Ces fonctions, appelables depuis le client permettaient d envoyer une ou plusieurs données depuis un serveur vers un client ou de redistribuer les données entre des serveurs séquentiels. Dans le cas d une séquence de requêtes [3] (comprises entre deux appels de fonctions spéciales), les données en entrées seront toutes envoyées au serveur qui effectuera la première requête. Ensuite, ne seront 6 http ://www.vthd.org 7 Une extension dans le cadre du multi- est possible en diffusant les requêtes de calcul aux autres s et en les traitant comme des s

5 transférées aux serveurs qui auront la charge des requêtes suivantes, que les données dont ils auront besoin, sans repasser par le client. Cette technique permet d éviter des transferts redondant d une même donnée entre le client et le système. Dans la même optique, l utilisateur pourra préciser que certaines données de sortie des requêtes ne sont que des données intermédiaires. Dans ce cas, celles-ci ne seront pas rapatriées sur le client en fin de séquence. Dans une dernière version de NetSolve, les données utilisées peuvent soit être locales au client (sur disque ou en mémoire), soit être présentes dans une infrastructure de stockage distribué (Distributed Storage Infrastructure ou DSI). Pour pouvoir être utilisée dans NetSolve, une donnée présente dans une DSI aura dû y être insérée via l API fournie. Cette API est prévue pour pouvoir accéder à différents DSI de la même façon, même si, actuellement, seul IBP (Internet Backplane Protocol ou IBP) est supporté. Pour une donnée DSI, c est à l utilisateur (client) qu incombe la tâche de connaître et choisir le serveur qui va héberger sa donnée. Dans tous les cas, la localité des données n est pas prise en compte dans le choix du serveur qui exécutera la requête. NetSolve maintient une table d allocation des fichiers qui recense le statut de tous les fichiers présents dans les DSI, ce qui impose l utilisation de l API NetSolve pour gérer les données distantes. Lors de la réception d une requête, le serveur NetSolve récupère les informations concernant les données en entrées et regarde dans sa table d allocation s il y est fait référence. Si c est le cas, alors il s agit d une donnée présente dans un DSI, sinon, la donnée est supposée locale au client et devra être récupérée par le serveur en charge de l exécution de la requête. Ninf ne possède pas de mécanisme sophistiqué de gestion de données. Il utilise juste une technique de gestion des séquences de requêtes comme NetSolve. 4.2 L approche DIET La gestion des données dans DIET a été pensée de manière modulaire. Cette particularité permet d envisager de connecter plusieurs types de systèmes de gestion de données. Dans cette section nous allons décrire deux infrastructures ayant des fonctionnalités complémentaires et pouvant être utilisées dans une même plate-forme. Le DTM (Data Tree Manager) pour une gestion des données adaptée à l architecture de DIET et JUXMEM pour une gestion de données de très grande taille Gestion des données dans un environnement hiérarchique : DTM L idée de gérer des données sur une plate-forme hiérarchique est soumise à deux contraintes fortes. Être capable de définir quelles sont les données que l on veut conserver dans la plate-forme, et être capable d identifier de manière unique cette donnée en son sein. Nous avons donc défini le mode de persistance et l identifiant de la donnée. Le mode de persistance Afin de rendre la plate-forme persistante, il a été défini une API cliente permettant au client de soumettre les données avec certaines caractéristiques. Lors de la première émission de la donnée, le client (ou un proxy intelligent ) fournit la donnée, son rôle (in, in out, out) au sein de l infrastructure ainsi que son mode (volatile, sticky, sticky return pour la session courante et persistent, persistent return valide entre session). Une donnée volatile ne sera pas conservée sur le serveur après son utilisation, elle sera détruite, Une donnée sticky est conservée sur le serveur mais non déplaçable. Ce mode est utile dans le cas de données de très grande taille pour lesquelles le coût de déplacement est trop pénalisant, Une donnée sticky return est une donnée sticky pour laquelle l utilisateur désire obtenir une copie, Une donnée persistent est conservée dans l infrastructure pendant une session ou à travers plusieurs sessions, elle est déplaçable et susceptible d être copiée, Une donnée persistent return est une donnée persistent pour laquelle l utilisateur désire obtenir une copie (c est le mode le plus adapté pour les données in out). La gestion de la persistance que nous proposons est à mettre en corrélation avec la proposition de standard faite dans le cadre du GridRPC Working Group du GGF. Notre DTM gère de manière explicite le mode de persistance des données alors qu il est implicitement déterminé dans l API GridRPC proposée. Cette différence s explique par la standardisation et le fait que les autres plates-formes Ninf, NetSolve ne gèrent

6 pas explicitement ce mode. Cependant, à partir de la définition et de l utilisation des fonctions de l API, nous constatons une relation directe avec le GridRPC. En effet, les modes volatile, sticky, sticky return persistent, persistent return sont gérés par l utilisation de la méthode bind(). Architecture L idée est donc que l architecture DIET puisse conserver les données éventuellement réutilisables et les déplacer d un serveur à un autre suivant les besoins de calcul. De plus, afin de ne pas alourdir la gestion des calculs en entrelaçant des messages liés aux calculs et des messages liés à la gestion des données, le choix a été fait de dissocier la partie calcul de la partie gestion des données en agrégeant deux objets : le DataManager et le LocManager respectivement liés aux et /, comme présenté figure 3. F(B,C)=D Cli idb, DataMgr2 ida, DataMgr LocMgr2 DataMgr A LocMgr 2 3 F() ida, LocMgr2 idb, LocMgr2 DataMgr2 B F() DataMgr3 Fig. 3 Les Objets DataManager et LocManager La structure des objets LocManager (respectivement Data- Manager) est initialisée parallèlement à celle des objets et (respectivement des ). Les fonctionnalités des objets DataManager et LocManager sont les suivantes : L objet LocManager est situé sur chaque agent avec lequel il communique localement. L objet LocManager gère une liste de références aux données présentes dans sa branche (couple identifiant donnée/possesseur). Sur l exemple présenté en Figure 3, l objet LocMgr2 possède les couples ((ida,datamrg),(idb,datamrg2)) et l objet LocMgr possède les couples ((ida,locmrg2),(idb,locmgr2)). Ainsi, la hiérarchie des objets LocManager permet de connaître la localisation d une donnée. Les objets DataManager ayant uniquement la connaissance des données qu ils possèdent localement. L objet DataManager est situé sur chaque avec lequel il communique localement. Il contient la liste des données de mode sticky, sticky return, persistent ou persistent return. Il est par ailleurs chargé des opérations de déplacement ou de copie de données et également de fournir les données nécessaires au serveur pour ses calculs. Enfin, il informe son objet LocManager père, de mises à jour (ajout, suppression) concernant sa liste de données. La mise à jour des branches concernées au sein de l architecture se faisant hiérarchiquement. Qui plus est, afin de gérer simplement, dans un premier temps, la cohérence des données, si une donnée est copiée d un serveur à un autre, la copie obtenue est de type volatile et par conséquent détruite après son utilisation. Ceci implique que la hiérarchie n est pas informée de l existence et de la localisation de cette copie. Exemple Considérons l architecture DIET présentée Figure 3. Supposons qu un client cli sollicite le produit matriciel D = B C. Supposons de plus que seuls les serveurs et 2 offrent le service de produit matriciel. Soient X = tpscalc 2 + tpscomm C et Y = tpscalc + i=b,c tpscom i où tpscalc i représente le temps de calcul du produit matriciel sur un serveur i (pour i =, 2) et tpscomm i représente le temps de communication d une donnée i (pour i = B, C). Ces temps proviennent d estimations fournies par le service de prédiction de performances [9]. Deux cas sont alors possibles : Le Cas : X < Y. Dans ce cas le serveur 2 est choisi. Le client envoie la donnée C et l identifiant de la donnée B car celle-ci est déjà présente au sein de l infrastructure. L objet DataMgr2 met à jour sa liste de données avec la donnée C et propage cette mise à jour sur sa branche père. Le serveur demande ensuite à l objet DataMgr2 de lui fournir les données B et C puis calcule le produit B C. Si la donnée D est de type persistent ou persistent return, elle est conservée sur le 2 et DataMgr2 propage cette mise à jour sur sa branche père (une copie est également retournée au client). Si D est de type sticky, elle est enregistrée sur l objet DataMgr2 qui ne propage pas cette mise à jour. Si D est de type volatile, D est retourné au client puis immédiatement détruite sur le serveur. Le Cas 2 : X > Y. Dans ce cas le serveur est choisi. Le client envoie la donnée C et l identifiant 2 LocMgr3

7 de B (car B est présente au sein de l architecture). L objet DataMgr met à jour sa liste de données avec la donnée C et propage cette mise à jour sur sa branche père. Le serveur demande ensuite à l objet DataMgr de lui fournir les données B et C. B n étant pas présente localement, l objet DataMgr interroge sa hiérarchie. Une fois l objet DataManager gérant B trouvé (ici DataMgr2), celui-ci transmet la donnée à l objet requérant (ici DataMgr). L ensemble des branches, pour lesquelles la localisation de la donnée est connue, est mise à jour. Le serveur peut maintenant calculer le produit B C. Si la donnée D est de type persistent ou persistent return, elle est émise au client, conservée sur l objet DataMgr qui propage cette mise à jour sur sa branche père. Résultats expérimentaux Afin de valider notre modèle, nous avons mené deux séries de tests sur une plate-forme composée d un client distant, d un Master Agent, de deux Leader Agents et de quatre s. Le client et le Master Agent sont connectés via un réseau de débit 6Mbits/s alors que le réseau local a un débit de 00Mbits/s. Nous avons ainsi une arborescence - locale, un serveur étant plus proche d un autre serveur que du client. La plate-forme est composée de serveurs (de 0.5 Ghz à.8 Ghz) hétérogènes, fonctionnant sous Linux. Dans la première série de tests, un client soumet un produit de matrices selon les trois scénarios suivants : les données ne sont pas persistantes et sont présentes uniquement chez le client (without persistency), les données sont persistantes et sont présentes sur le serveur choisi pour réaliser le calcul (local data), les données sont présentes et stockées quelque part sur la plate-forme mais pas sur le serveur choisi pour le calcul (data inside the platform) without persistency local data data inside the platform without persistency first call further calls Computation time (s) Computation time (s) Matrix size (MO) (a) C = A B Matrix size (MO) (b) C = A B, D = E + C, A = t A. Fig. 4 Comparaison données persistantes avec données non persistantes Les résultats présentés Figure 4(a) confirment la faisabilité de notre approche. Logiquement, nous notons que la meilleure solution apparaît lorsque la donnée est proche du serveur choisi pour les calculs. Quand les données sont présentes dans l infrastructure mais pas sur le serveur choisi, les temps d exécution sont toujours meilleurs que lorsque la donnée est émise par le client. En considérant la bande passante des réseaux locaux et distants, il est aisé de conclure que plus les données sont près des serveurs, plus les temps de calculs sont bons. Quel est le coût de l ajout de notre service à la plate-forme DIET? CORBA permet la non recopie de données mémoire, nous pouvons donc récupérer des valeurs sans faire de copie. De plus, nous soulignons que la mise à jour de la hiérarchie est réalisée de manière asynchrone, son coût est donc faible et n influe pas sur le temps de calcul global. La deuxième expérience 8 (Figure 4(b)) est une séquence d appels à l intérieur d une session : C = A B puis D = C + E puis A = t A, A, B, C, D, E étant des matrices. Là encore trois scénarios sont étudiés : 8 Les temps de calcul des différentes courbes doivent être comparées dans la même figure car les conditions d expérimentations ont changé.

8 données non persistantes Chaque donnée est envoyée chaque fois que cela est nécessaire (par exemple la matrice A est transmise deux fois), données persistantes (premier appel) Chaque donnée est envoyée uniquement au premier appel, pour les autres appels seul son identifiant est envoyé. Dans ce cas, A, B et C sont définies comme étant persistantes. C doit être persistante parce qu elle est utilisée dans le deuxième appel. D peut être non persistante parce qu elle n est pas utilisée ailleurs. Dans ce cas, A, B, E sont émises une fois, C n est pas émise, données persistantes (appels suivants) seulement les identifiants des données sont émis car les données sont déjà présentes dans l infrastructure. Les résultats de cette série de tests sont exposés Figure 4(b). Comme nous l avons déjà expliqué, si nous pouvons éviter les transmissions multiples d une même donnée, le temps de calcul global est égal à la sommation des temps de transfert de la donnée (en entrée depuis le client vers le serveur, en sortie depuis le serveur vers le client) avec le temps d exécution du problème. Logiquement encore, le dernier scénario apparaît comme étant le meilleur et confirme la faisabilité et le faible coût de notre approche dans le cas de séquence d appels Gestion des données de grande taille dans un environnement pair-à-pair : JUXMEM JUXMEM [] (Juxtaposed Memory) est une architecture pair-à-pair de service de partage de données en mémoire. Pour DIET, cette architecture se présente comme un système de gestion de données à la fois alternatif à DTM et complémentaire. En effet, il peut être intégré afin d offrir une solution adaptée à la gestion des données de grande taille. Dans cette section, nous allons décrire l architecture que propose JUXMEM, puis nous proposerons deux types d intégrations à DIET, une version en mode partagé et une version en mode concurrent. L architecture de JUXMEM Les données stockées dans la plate-forme pair-à-pair JUXMEM sont partagées et modifiables. Le système offre la persistance ainsi que la localisation transparente des données, il assure la cohérence et prend en compte la volatilité de la plate-forme. Tout comme DIET, l architecture mise en place se base sur un modèle hiérarchique afin de tirer partie de la plate-forme sous-jacente. Il existe trois types de pairs, les pairs fournisseurs (PF) qui stockent les données, les pairs gestionnaires () qui gèrent l espace mémoire, les pairs clients (PC) qui représentent l interface d accès au service. L infrastructure pair-à-pair permet à chaque nœud de fournir et d utiliser un service. La structure hiérarchique est mise en place par la gestion de groupes. En effet, un groupe a pour objectif de rassembler un ensemble de pairs. Il existe trois types de groupe. Le groupe juxmem contenant l ensemble des pairs et deux sous-groupes : le groupe cluster et le groupe data. Le premier regroupe un ensemble de pairs fournisseurs, en général appartenant à la même grappe mais il peut également s agir d une fédération de grappes. Le second groupe fédère les pairs fournisseurs partageant un même bloc de données. DIET et JUXMEM sont deux outils utilisant les ressources de la grille, l un pour les calculs l autre pour la gestion des données. Cependant leur mécanisme d allocation mémoire est distinct. Une première approche consiste à faire cohabiter les deux systèmes, cette solution implique alors des recopies mémoires entre les deux systèmes. Lors du calcul DIET nécessite d avoir une localité des données, contrainte qui n affecte pas JUXMEM, la distribution des données n est donc pas équivalente. Inévitablement une recopie mémoire des données, et donc une consommation mémoire importante est à prendre en compte dans la mise en place de cette cohabitation. Dans cette optique, nous donnons ici deux types de cohabitation : le mode partagé et le mode concurrent. Cohabitation DIET/JUXMEM : mode partagé La première solution évoquée part du principe que la grille offre un grand nombre de ressources, ces ressources sont alors attribuées soit à un composant DIET (Figure 5 cadre du haut) soit à un composant JUXMEM (Figure 5 cadre du bas). La Figure 5, montre un exemple de cette cohabitation. La Figure 5(a) montre les liens de communications de l architecture DIET et la Figure 5(b) illustre les liens représentant la dépendance entre les pairs gestionnaires et les pairs clients-fournisseurs dans JUXMEM (il ne s agit pas des liens réseaux puisque chaque 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 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

1.1 Remote Procedure Call (RPC)

1.1 Remote Procedure Call (RPC) 1.1 Remote Procedure Call (RPC) Le modèle Client-Serveur est un modèle simple à utiliser pour la structuration des systèmes répartis. Mais ce modèle s appuie sur des communications de type entrée/sortie

Plus en détail

CORBA haute performance

CORBA haute performance CORBA haute performance «CORBA à 730Mb/s!» Alexandre DENIS PARIS/IRISA, Rennes Alexandre.Denis@irisa.fr Plan Motivations : concept de grille de calcul CORBA : concepts fondamentaux Vers un ORB haute performance

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

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

Contribution à la gestion des données dans les grilles de calcul à la demande : de la conception à la normalisation

Contribution à la gestion des données dans les grilles de calcul à la demande : de la conception à la normalisation N d ordre 1106 THÈSE présentée à L U.F.R. DES SCIENCES ET TECHNIQUES DE L UNIVERSITÉ DE FRANCHE-COMTÉ pour obtenir le GRADE DE DOCTEUR DE L UNIVERSITÉ DE FRANCHE-COMTÉ Spécialité : Automatique et Informatique

Plus en détail

Une approche hiérarchique des serveurs de calcul

Une approche hiérarchique des serveurs de calcul Une approche hiérarchique des serveurs de calcul Eddy Caron Frédéric Desprez Eric Fleury Frédéric Lombard Jean-Marc Nicod Martin Quinson Frédéric Suter * LIP - ENS Lyon (UMR CNRS-INRIA 5668), 46 allée

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

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

Sauvegarde et restauration en environnement VMware avec Avamar 6.0

Sauvegarde et restauration en environnement VMware avec Avamar 6.0 Livre blanc Sauvegarde et restauration en environnement VMware avec Avamar 6.0 Analyse détaillée Résumé Dans les entreprises, les environnements virtuels sont de plus en plus déployés dans le cloud. La

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

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

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

PaCO++ André Ribes Réunion Hydrogrid Rennes 15/09/03

PaCO++ André Ribes Réunion Hydrogrid Rennes 15/09/03 PaCO++ André Ribes Réunion Hydrogrid Rennes 15/09/03 Plan Contexte Problèmes CORBA PaCO++ Conclusion / perspectives Contexte : couplage de code Structural Mechanics Optics Thermal Dynamics Satellite design

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 38 NFP111 Systèmes et Applications Réparties Cours 11 - Les Enterprise Java Beans (Introduction aux Enterprise Claude Duvallet Université du Havre UFR Sciences

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

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

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

Grille de calcul et physique des particules

Grille de calcul et physique des particules Grille de calcul et physique des particules Vincent Garonne CPPM, Marseille Contenu de la présentation Etat de l art : Grille de calcul Domaine d application : La physique des particules et LHCb Quelques

Plus en détail

JACE : un environnement d exécution distribué pour le calcul itératif asynchrone

JACE : un environnement d exécution distribué pour le calcul itératif asynchrone N d ordre 1121 Année 2005 THÈSE Présentée à Université de Franche-Comté UFR Sciences et Techniques Laboratoire d Informatique de l université Franche-Comté Pour obtenir le GRADE DE DOCTEUR DE L UNIVERSITÉ

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

Analyse de la démographie des objets dans les systèmes Java temps-réel

Analyse de la démographie des objets dans les systèmes Java temps-réel Analyse de la démographie des objets dans les systèmes Java temps-réel Nicolas BERTHIER Laboratoire VERIMAG Responsables du stage : Christophe RIPPERT et Guillaume SALAGNAC le 29 septembre 26 1 Introduction

Plus en détail

Les serveurs applicatifs et les architectures Java

Les serveurs applicatifs et les architectures Java 03 Lucas Part 02 Page 179 Lundi, 20. août 2001 2:58 14 Chapitre 15 Les serveurs applicatifs et les architectures Java Nous avons vu jusqu ici, dans les chapitres précédents, que les utilisateurs accèdent

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

Mise en œuvre des serveurs d application

Mise en œuvre des serveurs d application Nancy-Université Mise en œuvre des serveurs d application UE 203d Master 1 IST-IE Printemps 2008 Master 1 IST-IE : Mise en œuvre des serveurs d application 1/54 Ces transparents, ainsi que les énoncés

Plus en détail

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle 1 Principes 2 Architecture 3 4 Aperçu d utilisation

Plus en détail

Comment reproduire les résultats de l article : POP-Java : Parallélisme et distribution orienté objet

Comment reproduire les résultats de l article : POP-Java : Parallélisme et distribution orienté objet Comment reproduire les résultats de l article : POP-Java : Parallélisme et distribution orienté objet Beat Wolf 1, Pierre Kuonen 1, Thomas Dandekar 2 1 icosys, Haute École Spécialisée de Suisse occidentale,

Plus en détail

Chapitre I : Protocoles client serveur et architectures distribuées

Chapitre I : Protocoles client serveur et architectures distribuées Licence Pro Réseaux Télécom Systèmes Internet et Intranet pour l entreprise Chapitre I : Protocoles client serveur et architectures distribuées Département IEM / UB Eric.Leclercq@u-bourgogne.fr Bureau

Plus en détail

ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE

ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE Mémoires 2010-2011 www.euranova.eu MÉMOIRES ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE Contexte : Aujourd hui la plupart des serveurs d application JEE utilise des niveaux de cache L1

Plus en détail

Rapport projet TOP Test automatique de la plate-forme Grid 5000

Rapport projet TOP Test automatique de la plate-forme Grid 5000 Rapport projet TOP Test automatique de la plate-forme Grid 5000 Arthur Garnier Encadré par Lucas Nussbaum 1 er Juin 2015 Table des matières 1 Contexte 2 2 Description du problème 3 3 Présentation du travail

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

Chapitre I : Protocoles client serveur et architectures distribuées

Chapitre I : Protocoles client serveur et architectures distribuées Chapitre I : Protocoles client serveur et architectures distribuées Eric Leclercq & Marinette Savonnet Département IEM / UB Eric.Leclercq@u-bourgogne.fr Bureau G212 Aile des Sciences de l Ingénieur Mise-à-jour

Plus en détail

ACCESSNET -T IP Technique système TETRA d Hytera. www.hytera.de

ACCESSNET -T IP Technique système TETRA d Hytera. www.hytera.de Technique système TETRA d Hytera est la solution complète et performante pour toutes les applications de la téléphonie mobile professionnelle. www.hytera.de Bref aperçu Pour une communication TETRA professionnelle

Plus en détail

DataSheet Amélioration du Retour sur Investissement

DataSheet Amélioration du Retour sur Investissement G E S T I O N D U S T O C K A G E E N E N V I R O N N E M E N T O U V E R T DataSheet Amélioration du Retour sur Investissement Réduction du Coût Total d Exploitation Gestion, Virtualisation et Contrôle

Plus en détail

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP PREMIER MINISTRE Secrétariat général de la défense nationale Direction centrale de la sécurité des systèmes d information Sous-direction scientifique et technique Laboratoire Technologies de l Information

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

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

Mobile OGSI.NET: Grid Computing on Mobile Devices

Mobile OGSI.NET: Grid Computing on Mobile Devices Mobile OGSI.NET: Grid Computing on Mobile Devices David C.Chu Université de Californie, Berkeley Marty Humphrey Université de Virginie Publié en Novembre 2004 lors de la 5ième conférence IEEE/ACM International

Plus en détail

Prise en compte des ressources dans les composants logiciels parallèles

Prise en compte des ressources dans les composants logiciels parallèles Prise en compte des ressources dans les composants logiciels parallèles Aperçus de l action RASC et du projet Concerto F. Guidec Frederic.Guidec@univ-ubs.fr Action RASC Plan de cet exposé Contexte Motivations

Plus en détail

Contrôle d Accès dans un Système à Agents Mobiles sur Java

Contrôle d Accès dans un Système à Agents Mobiles sur Java Contrôle d Accès dans un Système à Agents Mobiles sur Java D. Hagimont, L. Ismail Projet SIRAC (IMAG-INRIA) INRIA, 655 av. de l Europe, 38330 Montbonnot Saint-Martin, France Internet: {Daniel.Hagimont,

Plus en détail

Spécification du profil UML d assemblage cible EJB (version 1)

Spécification du profil UML d assemblage cible EJB (version 1) Spécification du profil UML d assemblage cible EJB (version 1) Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti) Référence : Livrable 2.2 Date : 31 mai 2002

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

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

Net Integrator Système de Sauvegarde Vue d ensemble

Net Integrator Système de Sauvegarde Vue d ensemble Net Integration Technologies, Inc. http://www.net-itech.com Julius Network Solutions http://www.julius.fr Net Integrator Système de Sauvegarde Vue d ensemble Version 1.00 TABLE DES MATIÈRES 1 INTRODUCTION...

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

Projet ViSaGe : implémentation de l administration et du monitoring de ViSaGe (Virtualisation du Stockage appliquée aux Grilles informatiques)

Projet ViSaGe : implémentation de l administration et du monitoring de ViSaGe (Virtualisation du Stockage appliquée aux Grilles informatiques) RenPar 18/ SympA 2008 / CFSE 6 / JC 2008 Fribourg en Suisse, 11 au 13 février 2008 Projet ViSaGe : implémentation de l administration et du monitoring de ViSaGe (Virtualisation du Stockage appliquée aux

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

ETUDE DE CAS SESSION 2000 OPTION ARLE BAREME ET CORRIGE ETABLIS PAR LA COMMISSION NATIONALE D HARMONISATION DU 31 MAI 2000

ETUDE DE CAS SESSION 2000 OPTION ARLE BAREME ET CORRIGE ETABLIS PAR LA COMMISSION NATIONALE D HARMONISATION DU 31 MAI 2000 BTS INFORMATIQUE DE GESTION SESSION 2000 ETUDE DE CAS SESSION 2000 OPTION ARLE BAREME ET CORRIGE ETABLIS PAR LA COMMISSION NATIONALE D HARMONISATION DU 31 MAI 2000 Durée : 5 heures Coefficient : 5 CAS

Plus en détail

Architecture logicielle des ordinateurs

Architecture logicielle des ordinateurs Architecture logicielle des ordinateurs Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 des ordinateurs Objectifs du cours Notions générales sur le fonctionnement matériel (un peu) et logiciel

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

Système d exploitation

Système d exploitation Chapitre 2 Système d exploitation 2.1 Définition et rôle Un ordinateur serait bien difficile à utiliser sans interface entre le matériel et l utilisateur. Une machine peut exécuter des programmes, mais

Plus en détail

«clustering» et «load balancing» avec Zope et ZEO

«clustering» et «load balancing» avec Zope et ZEO IN53 Printemps 2003 «clustering» et «load balancing» avec Zope et ZEO Professeur : M. Mignot Etudiants : Boureliou Sylvain et Meyer Pierre Sommaire Introduction...3 1. Présentation générale de ZEO...4

Plus en détail

CORBA. (Common Request Broker Architecture)

CORBA. (Common Request Broker Architecture) CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,

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

NSY107 - Intégration des systèmes client-serveur

NSY107 - Intégration des systèmes client-serveur NSY107 - Intégration des systèmes client-serveur Cours du 13/05/2006 (4 heures) Emmanuel DESVIGNE Document sous licence libre (FDL) Plan du cours Introduction Historique Les différentes

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

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 16 NFP111 Systèmes et Applications Réparties Cours 10 - Les Enterprise Java Beans ( aux serveurs ) Claude Duvallet Université du Havre UFR Sciences et Techniques

Plus en détail

NFS Maestro 8.0. Nouvelles fonctionnalités

NFS Maestro 8.0. Nouvelles fonctionnalités NFS Maestro 8.0 Nouvelles fonctionnalités Copyright Hummingbird 2002 Page 1 of 10 Sommaire Sommaire... 2 Généralités... 3 Conformité à la section 508 de la Rehabilitation Act des Etats-Unis... 3 Certification

Plus en détail

Les serveurs d applications :une introduction

Les serveurs d applications :une introduction Les serveurs d applications : une introduction Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX Claude.Duvallet@gmail.com Octobre 2006 Plan de la présentation

Plus en détail

Le Ro le Hyper V Troisie me Partie Haute disponibilite des machines virtuelles

Le Ro le Hyper V Troisie me Partie Haute disponibilite des machines virtuelles Le Ro le Hyper V Troisie me Partie Haute disponibilite des machines virtuelles Microsoft France Division DPE Table des matières Présentation... 2 Objectifs... 2 Pré requis... 2 Quelles sont les principales

Plus en détail

Présentation générale des Web Services

Présentation générale des Web Services Présentation générale des Web Services Vue Globale Type d'architecture reposant sur les standards de l'internet Alternative aux architectures classiques : Client/serveur n/tiers Orientée services permettant

Plus en détail

ComputeMode : transformer une

ComputeMode : transformer une ComputeMode : transformer une salle de PC Windows en cluster Linux Philippe Augerat CASCIMODOT 19 novembre 2004 la société ICATIS! SAS créée le 28 janvier 2004 avec un capital de 37 Ke! Issue du Laboratoire

Plus en détail

Eric Bertrand ebertrand@ixis-cib.com. 08/11/06 Maître de conférence 1

Eric Bertrand ebertrand@ixis-cib.com. 08/11/06 Maître de conférence 1 Calcul parallèle des options MC. Eric Bertrand ebertrand@ixis-cib.com 1 Plan Contexte du calcul parallèle Qualités requises Architecture Outillage Problèmes rencontrés perspectives 2 Contexte du calcul

Plus en détail

Le Network File System de Sun (NFS)

Le Network File System de Sun (NFS) 1 sur 5 Le Network File System de Sun (NFS) Le Network File System de Sun (NFS) Architecture Protocoles Mounting Automounting vs Static mounting Directory et accès aux fichiers Problèmes Implémentation

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

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

Intégration d un poste Linux dans un domaine W2K

Intégration d un poste Linux dans un domaine W2K Intégration d un poste Linux dans un domaine W2K Pascal Gachet EIVD pascal.gachet@eivd.ch mai 2003 Intégration d un poste Linux dans un domaine W2K 2 Table des matières Introduction... 2 Terminologie...

Plus en détail

Cours Administration BD

Cours Administration BD Faculté des Sciences de Gabès Cours Administration BD Chapitre 2 : Architecture Oracle Faîçal Felhi felhi_fayssal@yahoo.fr 1 Processus serveur 1 Mémoire PGA Architecture SGBD Oracle Processus serveur 2

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

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

INSTALLATION AUTOMATISEE DE (W7) VIA (WDS) SUR WINDOWS 2008 SERVEUR 2014. Notre futur c est aujourd hui Page 1

INSTALLATION AUTOMATISEE DE (W7) VIA (WDS) SUR WINDOWS 2008 SERVEUR 2014. Notre futur c est aujourd hui Page 1 Notre futur c est aujourd hui Page 1 Notre futur c est aujourd hui Page 2 Notre futur c est aujourd hui Page 3 Le schéma ci-dessus présente le contexte technique au cours de la réalisation des opérations

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

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

Séminaire Aristote : présentation du logiciel ComputeMode. Philippe Augerat

Séminaire Aristote : présentation du logiciel ComputeMode. Philippe Augerat Séminaire Aristote : présentation du logiciel ComputeMode Philippe Augerat 16 septembre 2004 la société ICATIS! SAS créée le 28 janvier 2004 avec un capital de 37 k euros! Issue du Laboratoire Informatique

Plus en détail

La tête dans les nuages

La tête dans les nuages 19 novembre 2010 La tête dans les nuages Démystifier le "Cloud Computing" Jean Bernard, Directeur, Gestion des services Radialpoint SafeCare Inc. Au sujet de Radialpoint Radialpoint offre des solutions

Plus en détail

Déploiement générique d applications sur plates-formes hétérogènes distribuées

Déploiement générique d applications sur plates-formes hétérogènes distribuées RenPar 8 / SympA 8 / CFSE 6 Fribourg, Suisse, du au 3 février 8 Déploiement générique d applications sur plates-formes hétérogènes distribuées Benjamin Depardon (Benjamin.Depardon@ens-lyon.fr) Université

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

Administration des services dans le projet Safari

Administration des services dans le projet Safari Administration des services dans le projet Safari Atelier de travail OSGi CNAM Paris 5 septembre 2006 Abdelkrim Hebbar Bruno Mongazon D1-19/09/06 Projet Safari Résulte de la fusion de plusieurs propositions

Plus en détail

Chapitre VII : Principes des réseaux. Structure des réseaux Types de réseaux La communication Les protocoles de communication

Chapitre VII : Principes des réseaux. Structure des réseaux Types de réseaux La communication Les protocoles de communication Chapitre VII : Principes des réseaux Structure des réseaux Types de réseaux La communication Les protocoles de communication Introduction Un système réparti est une collection de processeurs (ou machines)

Plus en détail

Réponse à la campagne Postes d accueil 2006 Consolidation des Standards implémentés dans ProActive : OSGi, JMX, Fractal GCM

Réponse à la campagne Postes d accueil 2006 Consolidation des Standards implémentés dans ProActive : OSGi, JMX, Fractal GCM Réponse à la campagne Postes d accueil 2006 Consolidation des Standards implémentés dans ProActive : OSGi, JMX, Fractal GCM Projet OASIS, INRIA Sophia-Antipolis Février 2006 Le logiciel ProActive est diffusé

Plus en détail

Partie Réseaux TD 1 : Théorie des réseaux

Partie Réseaux TD 1 : Théorie des réseaux Partie Réseaux TD 1 : Théorie des réseaux 1 Les réseaux 1.1 Qu est-ce qu un réseau? Un réseau est un ensemble d ordinateurs pouvant communiquer entre eux. 1.1.1 Types de réseaux Il y a deux types de réseaux

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

Pour les entreprises de taille moyenne. Descriptif Produit Oracle Real Application Clusters (RAC)

Pour les entreprises de taille moyenne. Descriptif Produit Oracle Real Application Clusters (RAC) Pour les entreprises de taille moyenne Descriptif Produit Oracle Real Application Clusters (RAC) POURQUOI VOTRE ENTREPRISE A BESOIN DE CLUSTERISER LES SERVEURS La continuité opérationnelle est cruciale

Plus en détail

Tout pour monter son site Web. IUFM de Bourgogne

Tout pour monter son site Web. IUFM de Bourgogne Tout pour monter son site Web IUFM de Bourgogne Pourquoi utiliser les technologies Web? Visible par toutes les plates-formes (PC, Mac, Unix ) Technologies simples et descriptives Contenu principalement

Plus en détail

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C#

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# CHAPITRE 1 Introduction aux web services Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# NetBeans JavaScript Eclipse Objective C Xcode PHP HTML Objectifs du chapitre : Ce

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

Master UPMC Sciences et technologies, mention informatique Spécialité Systèmes et Applications

Master UPMC Sciences et technologies, mention informatique Spécialité Systèmes et Applications Master UPMC Sciences et technologies, mention informatique Spécialité Systèmes et Applications Réparties Réalisation Assistée d Applications Réparties Projet - écriture d un générateur de code Encadreur

Plus en détail

Groupe Eyrolles, 2004 ISBN : 2-212-11504-0

Groupe Eyrolles, 2004 ISBN : 2-212-11504-0 Groupe Eyrolles, 2004 ISBN : 2-212-11504-0 Table des matières Avant-propos................................................ 1 Quel est l objectif de cet ouvrage?............................. 4 La structure

Plus en détail

BD réparties. Bases de Données Réparties. SGBD réparti. Paramètres à considérer

BD réparties. Bases de Données Réparties. SGBD réparti. Paramètres à considérer Bases de Données Réparties Définition Architectures Outils d interface SGBD Réplication SGBD répartis hétérogènes BD réparties Principe : BD locales, accès locaux rapides accès aux autres SGBD du réseau

Plus en détail

Evaluation des performances de programmes parallèles haut niveau à base de squelettes

Evaluation des performances de programmes parallèles haut niveau à base de squelettes Evaluation des performances de programmes parallèles haut niveau à base de squelettes Enhancing the Performance Predictability of Grid Applications with Patterns and Process Algebras A. Benoit, M. Cole,

Plus en détail

Sauvegarde et Restauration d un environnement SAS

Sauvegarde et Restauration d un environnement SAS Sauvegarde et Restauration d un environnement SAS 1 INTRODUCTION 3 1.1 OBJECTIFS 3 1.2 PERIMETRE 3 2 LA SAUVEGARDE 4 2.1 QUELQUES REGLES D ORGANISATION 4 2.2 DEFINIR LES BESOINS 5 2.3 LA SAUVEGARDE, ETAPE

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

Programmation d applications distribuées

Programmation d applications distribuées Programmation d applications distribuées François Charoy Université Henri Poincaré 8 octobre 2007 Première partie I Développement d applications distribuées Objectifs du cours Comprendre ce qu est une

Plus en détail

Technologies du Multimédia et du Web

Technologies du Multimédia et du Web 3 ème Année Licence appliquée Technologies du Multimédia et du Web MoezBEN HAJ HMIDA ISSAT Sousse 2009/2010 Plan Les systèmes e-services Évolution des architectures d applications Les architectures client/serveur

Plus en détail

Réalisation d un serveur CTI-CSTA sur TCP/IP

Réalisation d un serveur CTI-CSTA sur TCP/IP Alcôve http://www.alcove.fr 1/28 Réalisation d un serveur CTI-CSTA sur TCP/IP Julien Gaulmin Cette présentation est librement diffusable sous les termes de la GNU Free Documentation

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

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web PROGRAMMATION PUBLIC Professionnels informatiques qui souhaitent développer des applications et «applets» Java DUREE 4 jours 28 heures OBJECTIF Créer divers «applets» à intégrer dans un site Web dynamique,

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

BONJOURGRID : VERSION ORIENTÉE DONNÉE & MAPREDUCE SÉCURISÉ

BONJOURGRID : VERSION ORIENTÉE DONNÉE & MAPREDUCE SÉCURISÉ Laboratoire LaTICE Univ. de Tunis INRIA LYON Avalon Team Laboratoire d Informatique de Paris Nord (LIPN) BONJOURGRID : VERSION ORIENTÉE DONNÉE & MAPREDUCE SÉCURISÉ Heithem Abbes Heithem Abbes Rencontres

Plus en détail