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

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

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

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

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

Communications performantes par passage de message entre machines virtuelles co-hébergées

Communications performantes par passage de message entre machines virtuelles co-hébergées Communications performantes par passage de message entre machines virtuelles co-hébergées François Diakhaté1,2 1 CEA/DAM Île de France 2 INRIA Bordeaux Sud Ouest, équipe RUNTIME Renpar 2009 1 Plan Introduction

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

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

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

LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1

LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 SAS Cost and Profitability Management, également appelé CPM (ou C&P), est le nouveau nom de la solution SAS Activity-Based Management. Cette version

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

ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges. c Copyleft 2006, ELSE Team

ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges. c Copyleft 2006, ELSE Team ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges c Copyleft 2006, ELSE Team 18 avril 2006 Table des matières 1 Introduction 2 2 Présentation du projet 3 2.1 Une distribution Évolulable..................

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

Point sur la virtualisation

Point sur la virtualisation Le 04/03/2013 OBJECTIF VIRTUALISATION mathieuc@exakis.com EXAKIS NANTES Identification du document Titre Projet Date de création Date de modification Point sur la Objectif 04/03/2013 26/03/2013 virtualisation

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

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

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

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

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

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

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

Architecture des ordinateurs. Optimisation : pipeline. Pipeline (I) Pipeline (II) Exemple simplifié : Instructions de type R

Architecture des ordinateurs. Optimisation : pipeline. Pipeline (I) Pipeline (II) Exemple simplifié : Instructions de type R Architecture des ordinateurs Licence Informatique - Université de Provence Jean-Marc Talbot Optimisation : pipeline jtalbot@cmi.univ-mrs.fr L3 Informatique - Université de Provence () Architecture des

Plus en détail

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

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

Plus en détail

PG208, Projet n 3 : Serveur HTTP évolué

PG208, Projet n 3 : Serveur HTTP évolué PG208, Projet n 3 : Serveur HTTP évolué Bertrand LE GAL, Serge BOUTER et Clément VUCHENER Filière électronique 2 eme année - Année universitaire 2011-2012 1 Introduction 1.1 Objectif du projet L objectif

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

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

WebSphere MQ & Haute Disponibilité

WebSphere MQ & Haute Disponibilité L objectif de cet article est d identifier les problèmes pouvant se poser lors de la mise en place d un système de secours dans une configuration WebSphere MQ, et de proposer des pistes pour régler ces

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

Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup

Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup Sébastien MEDARD GIP RENATER 263 avenue du Général Leclerc CS 74205 35042 Rennes Cedex Résumé L intégration

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

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

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

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

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

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

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

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

Plateforme AnaXagora. Guide d utilisation

Plateforme AnaXagora. Guide d utilisation Table des matières 1. PRESENTATION DE LA PLATE-FORME D APPRENTISSAGE ANAXAGORA... 3 2. ARCHITECTURE FONCTIONNELLE... 4 3. L APPRENTISSAGE... 5 3.1. L ESPACE DE TRAVAIL... 5 3.1.1. Le calendrier... 5 4.

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

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

Le Web: les machines parlent aux machines

Le Web: les machines parlent aux machines Le Web: les machines parlent aux machines Historique Année 70 : ARPA (Advanced Research Project Agency). Relier les centres de recherche : ARPANET. 1972 : Premières spécifications TCP/IP (IP internet Protocol)

Plus en détail

BOUYGUES TELECOM ENTREPRISES - CLOUD

BOUYGUES TELECOM ENTREPRISES - CLOUD BOUYGUES TELECOM ENTREPRISES - CLOUD PARTIE CLIENT Version 1.4. 21/06/2013 Partie client Page 1 Sommaire 1 FONCTIONS CLES DU PORTAIL 3 1.1 Pré-requis d utilisation des services Cloud 3 1.2 Principes de

Plus en détail

Le protocole ARP (Address Resolution Protocol) Résolution d adresses et autoconfiguration. Les protocoles ARP, RARP, TFTP, BOOTP, DHCP

Le protocole ARP (Address Resolution Protocol) Résolution d adresses et autoconfiguration. Les protocoles ARP, RARP, TFTP, BOOTP, DHCP Résolution d adresses et autoconfiguration Les protocoles ARP, RARP, TFTP, BOOTP, DHCP Le protocole ARP (Address Resolution Protocol) Se trouve au niveau de la couche réseau (à côté du protocole ) Routage

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

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

RICM 4 ème année 12/1/2012

RICM 4 ème année 12/1/2012 RICM 4 ème année 12/1/2012 Examen de Systèmes Répartis Durée : 2h, Documents autorisés à l exception des livres. Le barème est indicatif. Partie A Applications Web Question 1. Dans un répertoire contenant

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

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

Ebauche Rapport finale

Ebauche Rapport finale Ebauche Rapport finale Sommaire : 1 - Introduction au C.D.N. 2 - Définition de la problématique 3 - Etat de l'art : Présentatio de 3 Topologies streaming p2p 1) INTRODUCTION au C.D.N. La croissance rapide

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

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

Modèle Client-Serveur Partage du serveur entre clients

Modèle Client-Serveur Partage du serveur entre clients Modèle Client-Serveur Partage du serveur entre clients Un serveur peut servir plusieurs clients Vu d un client particulier client requête réponse serveur Vu du serveur Gestion des requêtes (priorité) Exécution

Plus en détail

Défi Cloud Computing

Défi Cloud Computing EQUIPE RICM 2010 Défi Cloud Computing Dossier de remarques Ricom c est l @base 04/12/2009 Sommaire Introduction... 3 Les applications et la plateforme Cloud Computing... 4 Cloud Computing - RICM-2010 Page

Plus en détail

CAHIER DES CHARGES D IMPLANTATION

CAHIER DES CHARGES D IMPLANTATION CAHIER DES CHARGES D IMPLANTATION Tableau de diffusion du document Document : Cahier des Charges d Implantation EVRP Version 6 Etabli par DCSI Vérifié par Validé par Destinataires Pour information Création

Plus en détail

Systèmes et applications distribués Intergiciels et applications communicantes

Systèmes et applications distribués Intergiciels et applications communicantes Systèmes et applications distribués Intergiciels et applications communicantes Philippe Quéinnec Télécommunication et Réseaux 2e année ENSEEIHT 24 février 2014 Inspiré de cours de G. Padiou, Ph. Mauran

Plus en détail

Gestion de la mémoire sous VMware ESX

Gestion de la mémoire sous VMware ESX Gestion de la mémoire sous VMware ESX 1. Introduction Le partage de ressources offert par la virtualisation apporte des avantages par rapport à des architectures traditionnelles. Cela permet d avoir plus

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

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

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

FileMaker Pro 13. Utilisation d une Connexion Bureau à distance avec FileMaker Pro 13

FileMaker Pro 13. Utilisation d une Connexion Bureau à distance avec FileMaker Pro 13 FileMaker Pro 13 Utilisation d une Connexion Bureau à distance avec FileMaker Pro 13 2007-2013 FileMaker, Inc. Tous droits réservés. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, Californie 95054

Plus en détail

Dynamic Computing Services solution de backup. White Paper Stefan Ruckstuhl

Dynamic Computing Services solution de backup. White Paper Stefan Ruckstuhl Dynamic Computing Services solution de backup White Paper Stefan Ruckstuhl Résumé pour les décideurs Contenu de ce White Paper Description de solutions de backup faciles à réaliser pour des serveurs virtuels

Plus en détail

Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007

Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007 Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007 I. RAPPEL : ADRESSAGE PHYSIQUE : (OSI 2)... 1 A. L ADRESSAGE DANS UN RESEAU

Plus en détail

Cette option est aussi disponible sur les clients Windows 7 sous la forme d un cache réparti entre les différentes machines.

Cette option est aussi disponible sur les clients Windows 7 sous la forme d un cache réparti entre les différentes machines. Le BranchCache Cette fonctionnalité qui apparaît dans Windows 2008 R2 permet d optimiser l accès aux ressources partagées hébergées sur des partages de fichiers ou des serveurs webs internes de type documentaire

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

Plateforme de capture et d analyse de sites Web AspirWeb

Plateforme de capture et d analyse de sites Web AspirWeb Projet Java ESIAL 2A 2009-2010 Plateforme de capture et d analyse de sites Web AspirWeb 1. Contexte Ce projet de deuxième année permet d approfondir par la pratique les méthodes et techniques acquises

Plus en détail

WWW - Intérêts du Web

WWW - Intérêts du Web WWW - Intérêts du Web client universel facilité d'emploi standards ouverts intégration des autres services Internet extensibilité du système faibles coûts logiciel et réseau utilisation au sein d'une entreprise

Plus en détail

Le protocole ARP (Address Resolution Protocol) Résolution d adresses et autoconfiguration. Les protocoles ARP, RARP, TFTP, BOOTP, DHCP

Le protocole ARP (Address Resolution Protocol) Résolution d adresses et autoconfiguration. Les protocoles ARP, RARP, TFTP, BOOTP, DHCP Résolution d adresses et autoconfiguration Les protocoles ARP, RARP, TFTP, BOOTP, DHCP Le protocole ARP (Address Resolution Protocol) Se trouve au niveau de la couche réseau Interrogé par le protocole

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

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

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

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

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

ENRICHIR LES DONNEES DE DETAILS ACCEDEES A TRAVERS UN RAPPORT OLAP

ENRICHIR LES DONNEES DE DETAILS ACCEDEES A TRAVERS UN RAPPORT OLAP ENRICHIR LES DONNEES DE DETAILS ACCEDEES A TRAVERS UN RAPPORT OLAP SAS Web Report Studio offre depuis de nombreuses versions la possibilité de visualiser les observations spécifiques à partir des données

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

ORDONNANCER ET PROGRAMMER DES JOBS AVEC SAS

ORDONNANCER ET PROGRAMMER DES JOBS AVEC SAS ORDONNANCER ET PROGRAMMER DES JOBS AVEC SAS Depuis SAS Management Console, l administrateur de la plate-forme Open Metadata Architetcure (OMA) peut créer des flux et les ordonnancer : SAS se charge de

Plus en détail

User Documentation. Documentation utilisateur. version 0.2b 04-2009

User Documentation. Documentation utilisateur. version 0.2b 04-2009 User Documentation Documentation utilisateur version 0.2b 04-2009 Table des matières 3 French Version....4 English Version.22 Table des matières 4 Table des matières TABLE DES MATIERES 3 A PROPOS DE CE

Plus en détail

Administration réseau Accès aux fichiers distants

Administration réseau Accès aux fichiers distants Administration réseau Accès aux fichiers distants A. Guermouche A. Guermouche Cours 8 : NFS & SMB 1 Plan 1. Introduction 2. NFS 3. SAMBA A. Guermouche Cours 8 : NFS & SMB 2 Plan Introduction 1. Introduction

Plus en détail

Ecole Nationale Supérieure des Télécommunications Les outils XML

Ecole Nationale Supérieure des Télécommunications Les outils XML Ecole Nationale Supérieure des Télécommunications Les outils XML Page 1 sur 13 SOMMAIRE 1 Introduction 3 2 Parseur XML et processeur XSLT 4 2.1 Le Parseur XML v2 4 2.1.1 Les API DOM et SAX 4 2.1.2 Le parseur

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

EP 1 931 091 A1 (19) (11) EP 1 931 091 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 11.06.2008 Bulletin 2008/24

EP 1 931 091 A1 (19) (11) EP 1 931 091 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 11.06.2008 Bulletin 2008/24 (19) (12) DEMANDE DE BREVET EUROPEEN (11) EP 1 931 091 A1 (43) Date de publication: 11.06.2008 Bulletin 2008/24 (51) Int Cl.: H04L 12/58 (2006.01) (21) Numéro de dépôt: 07291423.7 (22) Date de dépôt: 29.11.2007

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

LE SAS SOFTWARE DEPOT

LE SAS SOFTWARE DEPOT LE SAS SOFTWARE DEPOT Depuis SAS 9, l ensemble des logiciels SAS peuvent être installés depuis un unique répertoire : le SAS Software Depot. Il contient tous les exécutables permettant d installer les

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

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

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

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free.

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free. 2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES 2.2 Architecture fonctionnelle d un système communicant Page:1/9 http://robert.cireddu.free.fr/sin LA SEGMENTATION VIRTUELLE DES DOMAINES DE DIFFUSION : LES VLANs

Plus en détail

LOSLIER Mathieu IR1 31 Mai 2011. Rapport TP Firewall

LOSLIER Mathieu IR1 31 Mai 2011. Rapport TP Firewall Rapport TP Firewall 1 Table des matières Rapport TP Firewall... 1 Introduction... 3 1. Plate-forme de sécurité étudiée... 3 2. Routage classique... 3 2.1 Mise en œuvre du routage classique... 4 2.2 Configuration

Plus en détail

Documentation utilisateur FReg.NET

Documentation utilisateur FReg.NET Epitech Documentation utilisateur FReg.NET Document réservé aux utilisateurs souhaitant comprendre rapidement le fonctionnement du logiciel FReg.NET Lago_a, schehl_c, narcis_m, clique_x, tran-p_n 5/14/2010

Plus en détail

La technologie Java Card TM

La technologie Java Card TM Présentation interne au CESTI La technologie Java Card TM sauveron@labri.u-bordeaux.fr http://dept-info.labri.u-bordeaux.fr/~sauveron 8 novembre 2002 Plan Qu est ce que Java Card? Historique Les avantages

Plus en détail

CONFIGURATION P 2 P 3 P 3 P 10 P 11 P 13 P 14 P 16

CONFIGURATION P 2 P 3 P 3 P 10 P 11 P 13 P 14 P 16 CONFIGURATION 1 Présentation 2 Topologie du projet 3 Installation 4 Configuration 4.1 Création de la DMZ publique 4.2 Accès vers l Internet 4.3 Publication d Exchange 4.4 Rapports d activité et alertes

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

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

Cours d Analyse, Algorithmique Elements de programmation

Cours d Analyse, Algorithmique Elements de programmation 1 de 33 Cours d Analyse, Algorithmique Elements de programmation Florent Hivert Mél : Florent.Hivert@lri.fr Adresse universelle : http://www.lri.fr/ hivert 2 de 33 Données et instructions Un programme

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

Référence Etnic Architecture des applications

Référence Etnic Architecture des applications Référence Etnic Architecture des applications Table des matières 1. Introduction... 2 2. Architecture... 2 2.1 Démarche générale... 2 2.2 Modèle d architecture... 3 2.3 Découpe d une architecture applicative...

Plus en détail

1 Programmation Client/Serveur basée sur TCP/IP

1 Programmation Client/Serveur basée sur TCP/IP Outils Informatique pour l ingénieur TD 1 Réseau et Web IP, Client/serveur 1 Programmation Client/Serveur basée sur TCP/IP 1.1 Buts de cette réalisation Ce TP sur la programmation client/serveur a pour

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

DOSSIER SPÉCIAL Datacenter : Les problèmes n arrivent pas qu aux autres

DOSSIER SPÉCIAL Datacenter : Les problèmes n arrivent pas qu aux autres Datacenter : Les problèmes n arrivent pas qu aux AUCUN DATACENTER n est à l abri d un éventuel problème, d une indisponibilité ou d un imprévu! La question est de savoir que faire pour protéger votre Datacenter

Plus en détail

Exercices Active Directory (Correction)

Exercices Active Directory (Correction) Exercices Active Directory (Correction) Exercice : Scénarios pour l'implémentation de composants logiques AD DS Lire les scénarios suivants et déterminer les composants logiques AD DS à déployer dans chaque

Plus en détail

Procédure pas à pas de découverte de l offre. Service Cloud Cloudwatt

Procédure pas à pas de découverte de l offre. Service Cloud Cloudwatt Procédure pas à pas de découverte de l offre Service Cloud Cloudwatt Manuel Utilisateur 03/07/2014 Cloudwatt - Reproduction et communication sont interdites sans autorisation 1/45 Contenu 1. Introduction...

Plus en détail

Quelques propositions pour une organisation des ressources réseaux prenant en compte les besoins du LACL

Quelques propositions pour une organisation des ressources réseaux prenant en compte les besoins du LACL Quelques propositions pour une organisation des ressources réseaux prenant en compte les besoins du LACL Document de travail proposé par Olivier Michel LACL - P2 240 - olivier.michel@univ-paris12.fr Version

Plus en détail