- UMR 5205 Une Grille Pervasive vue du coté des données Jean-Marc Pierson 17 novembre 2005 Habilitation à Diriger des Recherches

2 Une Grille… “ Resource sharing & coordinated problem solving in dynamic, multi- institutional virtual organizations” (I. Foster) Resource sharing : partage de matériels, de services, de logiciels Coordinated problem solving : pour faire du calcul coûteux Virtual Organizations : les utilisateurs, répartis géographiquement, sont regroupés pour partager Multi-institutional : au delà des frontières d’administration des matériels Dynamic :  Les utilisateurs arrivent et partent à tout moment  Les ressources sont volatiles

3 RRRRRRRRR VO

4 … Pervasive ”The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.” (M. Weiser) technologies that disappear : leurs utilisateurs ne sont pas au courant de leur présence fabric of everyday life : le tissu (social, culturel et technologique) de tous les jours Notion de pro-activité : le système agit, ne réagit plus… Pas encore d’actualité, aujourd’hui disons « dispositifs de plus en plus légers » : PDA, téléphone portable, senseurs

5 Une Grille Pervasive RRRRRRRRR Mobilité Imprédictibilité Contexte

6 …vue du coté des données Gestion et traitement de données réparties à grande échelle Motivations :  les données sont au cœur des applications  la grille les a longtemps oubliées  impossible de tout faire, il faut choisir…  LIRIS : Système d’information, donc plus données que calculs

7 Cas d’utilisation 1

8 Cas d’utilisation 2

9 Briques de base pour la gestion des données Stockage : sur l’infrastructure stable Réplication : efficacité, redondance Cache collaboratif : efficacité Accès : médiation, négociation Indexation sémantique : indexer en fonction du contenu Recherche : y compris requêtes hybrides Transport : adapté en fonction de la qualité du réseau

10 Briques de base pour la gestion des données Sécurité : authentification, autorisation, cryptage Adaptation : au contexte de consultation de la donnée Manipulation/Traitement : généralisation de l’adaptation (ex: anonymisation, moyenne, etc) Visualisation : spécialisation du précédent Interfaces Homme-Machine : interaction non intrusive + services monitoring, ordonnancement de tâches, découverte dynamique de services, historique

11 Briques de base pour la gestion des données Stockage : sur l’infrastructure stable Réplication : efficacité, redondance Cache collaboratif : efficacité Accès : médiation, négociation Indexation sémantique : indexer en fonction du contenu Recherche : y compris requêtes hybrides Transport : adapté en fonction de la qualité du réseau Sécurité : authentification, autorisation, cryptage Adaptation : au contexte de consultation de la donnée Manipulation/Traitement : généralisation de l’adaptation (ex: anonymisation) Visualisation : spécialisation du précédent Interfaces Homme-Machine : interaction non intrusive + services monitoring, ordonnancement de tâches, découverte dynamique de services, historique

12 Emplacement des services ? Infrastructure stable/instable Capacités de calcul hétérogènes Possibilités de stockage très diverses Tout ne doit pas être partout Chaque service a ses propres besoins en termes de ressources de calcul, de ressources de stockage et de connexion externe Un dispositif embarque un ensemble cohérent de services parmi cette liste : modularité nécessaire

13 Sécurité dans une Grille Pervasive… Challenges :  Communauté d’utilisateurs étendue, inter-organisation et dynamique  Ressources dynamiques et distribuées  Pas de centralisation des droits Authentification Autorisation, délégation d’autorité : contrôle d’accès Intégrité et confidentialité : Communications sûres, stockage sûr, anonymisation Paiement, audit, monitoring : Traçabilité, non-répudiabilité

14 Sécurité dans les grilles [L. Seitz]  Contôle d’accès : Sygn, certificats Sygn :  Decentralisé :  Source d’autorités des ressources  Gestion des permissions par certificats  Pas de “single point of failure”  Flexibilité :  Role Based Access Control (RBAC)  Autorisations hors-ligne et ad-hoc

15 Sygn : 3 acteurs, 3 étapes

16 Sygn : 3 acteurs, 3 étapes

17 Permission = Certificat d’autorisation (AC) : SOA de la ressource Propriétaire de l’AC Droits ouverts : objet+action Validité Signature Sygn : 3 acteurs, 3 étapes

18 Sygn : 3 acteurs, 3 étapes Une ressource peut être un ensemble de ressources Une permission peut être donnée à un rôle Une chaîne de certificats peut être nécessaire pour accéder à une donnée

19 Sygn pour une Grille Pervasive Forte décentralisation Découplage des droits (aux données) des données elles mêmes Tolérance aux fautes (corruption à portée limitée) Certificats « légers » Extensible, paramétrable (pour l’accounting, l’anonymisation), et donc adaptable Nécessite la présence d’un PDP/PEP sur la zone de stockage A résoudre… : authentification des utilisateurs, chaîne de certificats à construire par l’utilisateur

20 Stockage crypté [L. Seitz] Motivation : Les données peuvent être stockées en dehors du domaine administratif de leurs propriétaires Le contrôle d’accès ne sert à rien si les sites sont compromis. Besoin de cryptage des données : CryptStore CryptStore : distribution de la clé de cryptage Pas d’administration centralisée, pas de tierce partie de confiance Tolérance aux fautes, interopérabilité avec les contrôles d’accès Idée reprise dans EGEE Stockage crypté distribué : partage de clés

21 Gestion de cache Cache et systèmes distribués  pour améliorer les performances (hit rate)  pour améliorer la collaboration (hot topics)  pour cacher la structure interne/externe : chaque institution veut garder le contrôle sur ses données Caches collaboratifs  partager les index : où se trouve une donnée ?  gérer collectivement les données : où placer une donnée ?

22 Indexation sémantique pour cache [D.Coquil] Caches collaboratifs Les documents sont associés à des concepts de l’arbre Les concepts sont plus ou moins reliés entre-eux Une température est associée à un document et augmente lorsqu’il est accédé, ou qu’un document proche est accédé Les documents les plus froids sont effacés les premiers du cache Collaboration entre caches

23 [Y. Cardenas] Caches collaboratifs et grille de calcul Motivation :  ça n’existe pas dans les grilles  ajouter des nouvelles caractéristiques aux caches collaboratifs, en utilisant la Grille :  gérer les données cachées en fonction de leur activité (effacement, déplacement, découpe, fusion)  gérer les techniques de remplacement des caches selon les usages d’un cache. Solution :  utiliser les méta-données pour collaborer, indexer les données  un cache hiérarchique à deux niveaux : cache local et cache virtuel global Du point de vue de l’utilisateur : un cache uniforme où des données sont stockées Cache et grille

24 Basic Grid Cache Service Grid Service OGSA Catalogue de métadonnées Politique de remplacement dynamique Implémenté avec Globus Toolkit 4

25 Cache dans une Grille Pervasive Cache prévu pour l’infrastructure stable a priori, donc peu d’influence directe sur les dispositifs mobiles Problèmes :  si des documents sont cachés dans des zones de stockage non pérennes :  Inutilité d’avoir une vue globale trop volatile  Si un fichier a été scindé, la perte d’un morceau entraine la perte de tout un fichier caché  l’indexation des documents dans un arbre d’indexation sémantique oblige les caches locaux à se mettre d’accord sur la façon de classer…

26 Pervasive Computing : Adaptation [G. Berhe] : Architecture à base de services pour l’adaptation de contenu multimédia dans les systèmes pervasifs

27 Adaptation architecture

28 Graphes d’adaptation Chemin d’adaptation logique : définit l’ordre des opérations à effectuer sur un média Chemin d’adaptation physique : spécifie l’ordre d’exécution des services, pour une composition optimisée des services.

29 Adaptation de l’adaptation à une Grille Pervasive Calcul des chemins d’adaptation peu coûteux Travail sur la description sémantique des services, des profils et des contenus déjà fait Problèmes :  Présence des services d’adaptation : autour de l’utilisateur, internet ?  Valuer les arcs du graphe d’adaptation en fonction du contexte : un service puissant sur un dispositif peu accessible ou un service moins puissant sur un endroit sur lequel on peut compter ?  Contexte :  Comment connaître ce contexte dynamique ?  Sécurité/confidentialité du contexte ?  Sécurité : confiance envers les services utilisés ?

30 Résumé des contributions Réplication  pour les systèmes pervasifs, algorithmique distribuée de gestion autonome et dynamique de réplica [J. Gossa]  puis… grille de calcul [J. Gossa] Cache collaboratif  pour les Systèmes d’information multimédia, suivant la température des documents [D. Coquil]  pour les grilles de calcul [Y. Cardenas] Accès  médiation et négociation dans les grilles [N.H. Andrianarisoa]  architecture distribuée d’accès aux données images médicales [H. Duque] Indexation sémantique  indexation selon le contenu des documents [D. Coquil] Recherche  requêtes hybrides sur données d’hôpitaux [H. Duque] Sécurité  authentification par la méfiance [R. Saadi]  autorisation, cryptage [L. Seitz] Adaptation  au cœur du réseau actif [avec L. Lefèvre]  des données multimédias [G. Berhe] Visualisation : système distribué à base de composants [à Calais] Monitoring : notion de vue multi-échelle sur les ressources [J. Gossa]

31 Thèses défendues Décentralisation : pas de point central de contrôle, autonomie, localité du contrôle/des données Sémantique : protocoles, algorithmes, prenant en compte la sémantique des données, des accès, des services Dynamique : les décisions prises s’adaptent au contexte

32 Au final, une grille pervasive, c’est… « Juste » une Grille normale, dans laquelle on injecte :  la mobilité des utilisateurs : qui, quand, où ?  la prise en charge du contexte : périphériques, réseaux, intérêt des utilisateurs ?  imprédictibilité : plus forte dynamique des acteurs ? Méthode : on modifie un middleware existant (exemple : OGSA/WSRF, Globus) en ajoutant ces contraintes ? Une première étape nécessaire…

33 Où alors … on repart à zéro en imaginant les services nécessaires Questions : quels services, où les placer, quels sont les services embarqués sur les périphériques, quelle est la part de l’architecture obligatoire, quelle est la part optionnelle ? Aspects clés de l’architecture :  Décentralisation  Tolérance aux fautes  Réactivité et proactivité

34 Les perspectives… … sont nombreuses trop  ? Problématiques clés :  Pro-activité  Sémantique  Contexte dynamique, mobilité, impredictibilité L’architecture globale reste à définir, à implémenter, notamment pour étendre le point de vue au-delà des données…

35 Replaçons tout ça dans le contexte… …des projets académiques …des collaborations nationales, internationales …des collaborations industrielles …des étudiants …des résultats publiés

36 Projets de Recherche (en France) ACI GRID (Globalisation Ressources Informatiques et Données) :  MEDIGRID (+Creatis) : traitement d’images sur grille  DARTS (+Citi) : plateforme à composants pour grille  DATAGRAAL (+…) : animation de la communauté  GRID5000 : coordinateur applications LIRIS (plateforme de l’ENS-Lyon) ACI Masse de Données  GGM (+IRIT, LIFL) : Grille Géno-Médicale [coordinateur] RAGTIME : information médicale sur grille en Rhône-Alpes

37 Projets de Recherche (autres) Participation à EGEE, sous-groupe « Sécurité », notamment KTH Stockholm Participation au Global Grid Forum, groupe Metadata et groupe Ubiquité PAI Amadeus [coordinateur], PAI Galilléo Collaboration avec l’Université d’Addis-Abeba (stage de master communs)

38 Collaborations industrielles 3 Degrés De Liberté : incubation d’entreprise Rhône- Alpes, collaboration équipe RESO/ENS-Lyon AFSSE (Agence Française de Sécurité Sanitaire Environnementale) CIFREs :  Aricie (N.A. Andrianarisoa)  GridXpert (F-K. Moulaï) Associations Opal’Air et Coparly : environnement

39 Recherche: autres activités collectives Participation à des comités de programme, notamment UbiMob (« Ubiquité et Mobilité ») « Program Chair »  VLDB DMG’05 : Data Management in Grids, publié par Springer LNCS  VLDB DMG’06 (à venir) « Program Co-Chair » et organisation locale (avec L. Lefèvre, LIP, ENS-Lyon) ICPS’06 : Int. Conf. on Pervasive Services, Lyon, juin Elu au conseil de laboratoire CSE Lyon2 et Franche-Comté

40 Bilan chiffré 6 étudiants en thèse (2005:1, 2006:2, 2007:3) 7 étudiants en DEA/Masters 1 édition de revue (« Systèmes d’Information Pervasifs ») 1 édition d’actes de conférence (VLDB DMG’05, Springer LNCS) 4 articles de journaux 25 conférences internationales (dont 2 « enseignement ») 5 conférences nationales 4 workshops 2 conférences invitées

41 Replaçons tout ça dans le temps… sept 2001 sept 2005 sept 2004 sept 2003 sept 2002 sept 1997 Calais Visu distribuée ACI MEDIGRID jan 2006 ACI DARTS ACI DATAGRAAL ACI GGM RAGTIME AFSSE 3DDL PAI EGEE Sécurité Grille : L. Seitz Sécu. Pervasif : R. Saadi Cache Grille : Y. Cardenas Adaptation Pervasif : G. Berhe Médiation Grille : N.H. Andrianarisoa Répl./Monitoring: J. Gossa

42 Enseignement En synergie avec la recherche :  Réseaux, de la base de TCP/IP aux systèmes pervasifs  Master Recherche : « Grid Computing : du calcul aux données » Collaborations :  TICE : projets européens Genius, eTutor  Master Addis-Abeba : cours de Systèmes Distribués Organisation :  Direction de l’IUP GMI, Calais  Coordination INSA  Coordination Projet SERBER : Plateforme pédagogique pour la Sécurité Réseaux

43 Enfin, merci à tous…