Un service de partage de données pour DIET : GDS basé sur JuxMem Mathieu Jan Projet PARIS Lyon, 5 décembre 2003.

Présentation au sujet: "Un service de partage de données pour DIET : GDS basé sur JuxMem Mathieu Jan Projet PARIS Lyon, 5 décembre 2003."— Transcription de la présentation:

1 Un service de partage de données pour DIET : GDS basé sur JuxMem Mathieu Jan Projet PARIS Lyon, 5 décembre 2003

2 2 Plan Rappels sur JuxMem Premier objectif de l’interaction Choix pour le couplage DIET – GDS Exemple d’utilisation DIET – GDS Conclusions et perspectives

3 3 Groupe juxmem Groupe cluster AGroupe cluster B Groupe cluster C Groupe data Architecture physique Architecture virtuelle Architecture de JuxMem

4 4 Interface actuelle de JuxMem juxMemAlloc (size, attribs) juxMemMap (id, attribs) juxMemPut (id, value) juxMemGet (id) juxMemLock (id) juxMemUnlock (id)

5 5 État actuel de JuxMem Nettoyage de code et commentaires Démarrage directement dans le groupe juxmem Configuration des pairs JuxMem Utilisation du projet JDF Description du réseau voulu au format XML Configuration des noeuds Lancement des pairs pour effectuer des tests Déploiement simplifié et automatisé Réalisation des premiers tests spécifique à JuxMem But : passage à l’échelle Passage à JXTA 2.2 Nouvelle version plus efficace du pipe service, … Version finale prévue pour le 15 décembre

6 6 Architecture de DIET MA LA SeD Client Estimation du temps de calcul sur les SeD (FAST) Estimation du temps des communications (FAST) RPC

7 7 Premier objectif de l’interaction Offrir un stockage persistant des données à DIET Persistance entre plusieurs RPCs Faire des essais simples But : que ça marche ! Un MA, 0-2 LA, 0-2 SeD Fournir un premier prototype de cette interaction Pour la prochaine réunion

8 8 Couplage DIET – GDS Idée : utiliser des handles pour les données Nécessaire pour partager des données entre plusieurs RPCs Utilisation d’un ID pour identifier la donnée Différents modes de persistance INOUTINOUT returnno returnreturnno return Sticky C  S Stored Ø C S Stored Ø C  S Stored Persistent C  S Stored C  S Stored C S Stored C  S Stored C  S Stored Volatile C  S NOT stored C  S NOT stored Ø C  S NOT stored Ø

9 9 Couplage DIET – GDS Implémentation de new_data_handle Si donnée persistante : utilisation de GDS Correspond à juxMemAlloc puis juxMemPut Optimisation en 1 primitive : juxMemCreate Implémentation de free_data_handle Pas d’équivalent pour l’instant juxMemDelete(ID) Changement de mode de persistance Exemple : passage de persistent_no_return à persistent_return

10 10 Mapping sur l’API de JuxMem Côté SeD Côté client Couplage DIET – GDS INOUTINOUT returnno returnreturnno return Sticky juxMemPut /Get Ø juxMemPut Ø juxMemPut /Put Persistent juxMemPut /Get juxMemPut /Get juxMemPutjuxMemPut /Get /Get juxMemPut /Get Volatile x x Ø x Ø

11 11 Modifications du code DIET Lors du marshalling mrsh_profile_to_in_args (client) Transmission uniquement des ID des données pour les IN et INOUT unmrsh_in_args_to_profile (SeD) Appel à juxMemGet(ID) pour les IN et INOUT mrsh_profile_to_out_args (SeD) Appel à juxMemPut(ID) pour les INOUT et OUT Transmission uniquement des ID des données pour les OUT unmrsh_out_args_to_profile (client) Appel à juxMemGet(ID) pour les INOUT et OUT

12 12 Modifications du code DIET Choix du SeD à fournir au client Estimation du temps de calcul Utilisation de FAST Estimation du temps d’accès aux données Localisation des différentes copies Appel à juxMemLocate(ID) Retourne une liste de nœuds Appel à FAST pour calculer les temps de déplacement des données Pas optimal

13 13 Interfaçage DIET – GDS Les clients DIET et les SeD utilisent l’API offerte par JuxMem Clients de JuxMem Passage de C++ à Java Solution technique retenue Utilisation de JNI (Java Native Interface) Problème d’accès concurrent aux ressources réseaux (CORBA et sockets) Solution : Padico Expérience de ReMaP/GRAAL Version multi-MA de DIET en utilisant JXTA Réutilisation de la version Java du client DIET

14 14 Exemple d’utilisation de DIET – GDS Mise en place de JuxMem Démarrage d’un gestionnaire de grappe Démarrage des fournisseurs Pas forcément sur les futurs SeD Mise en place de DIET Démarrage d’un MA Démarrage d’un ou plusieurs LA Démarrage des SeD–client JuxMem Démarrage d’un client DIET (version Java) Création des données : handles de données Utilisation de JuxMem Choix du SeD Appel du RPC Transmission des IDs Réutilisation des handles de données par le même client pour un autre RPC, ou par un autre client …

15 15 Exemple d’utilisation de DIET – GDS MA LA SeD Client GC F F F CCC Stockage des données Récupération des données RPC

16 16 Conclusions Avantages Persistance des données entre plusieurs RPCs Gestion transparente au niveau applicatif du transfert des données Pas de modifications de l’API de DIET Problèmes Problème avec OmniORB et JNI Solution : utilisation de Padico ? Roadmap Premier prototype opérationnel pour la prochaine réunion Prendre des exemples de plus en plus complexes

17 17 Perspectives Prédire plus efficacement les temps de déplacement des données Intégré à JuxMem Utilisation du peer info service & meter project Mécanismes de synchronisation des accès aux données Deux clients font des RPCs sur les même données Gestion des sessions Destruction de toute les données associées