240 likes | 334 Views
Extension du modèle de cohérence à l’entrée pour la visualisation dans les applications de couplage de codes sur grilles. Loïc Cudennec, Sébastien Monnet Irisa / Projet PARIS. Les grilles de calculateurs Introduction. Besoins grandissant en puissance de calcul Applications scientifiques
E N D
Extension du modèle de cohérence à l’entrée pour la visualisation dans les applications de couplage de codes sur grilles Loïc Cudennec, Sébastien Monnet Irisa / Projet PARIS CDUR 2005 - Paris
Les grilles de calculateursIntroduction • Besoins grandissant en puissance de calcul • Applications scientifiques • Supercalculateurs -> Grappes (réduction des coûts) • Grappes -> Grilles (passage à l’échelle) • Grille = fédération de ressources • Réseau de distribution électrique • 103 - 104 nœuds • Calcul distribué • Applications visées • Couplage de code CDUR 2005 - Paris
Mécanique des solides Optique Dynamique Conception de Satellite Thermodynamique Le couplage de code • Applications visées : simulations numériques distribuées • Besoin de visualisation CDUR 2005 - Paris
Gestion des données dans les grilles • Localisation et transfert explicite des données • Plate-forme Globus basée sur GridFTP [ANL] • GAMESS, NVO, BIRN, DPOSS, NARA, … • Limitations • Trop complexe dans les grands systèmes • Gestion des données à la charge de l’utilisateur • Aucune garantie sur la cohérence des copies d’une donnée CDUR 2005 - Paris
MVP Mém. Mém. Mém. CPU CPU CPU Réseau Gestion des données : petite échelleSystèmes à mémoire virtuellement partagée (MVP) • Echelle : 101 à 102 nœuds • Transparence • Localisation et transfert des données • Mémoire unique • Additionner plusieurs mémoires physiques • Projeter dans un espace d’adressage virtuel • Masquer les accès distants • Limitation • Ne passe pas à l’échelle, environnement statique CDUR 2005 - Paris
Gestion des données : grande échelle Systèmes pair-à-pair • Décentralisation • Nœud client et serveur • Utilisation des ressources des participants • Vue locale du système • Propriétés • Passage à l’échelle : 105 à 106 nœuds • Haute volatilité • Auto-organisation • Limitation • Données non-modifiablesexceptions : Ivy [MIT], Oceanstore [UCB], Pastis [LIP6] CDUR 2005 - Paris
Gestion des données : la grille Synthèse : un service de partage de données pour la grille CDUR 2005 - Paris
JuxMem Un service de partage de données pour la grille • S’inspire des MVP et du PàP • Plate-forme d’expérimentation de protocoles de cohérence tolérants aux fautes • Repose sur la plate-forme pair-à-pair JXTA (Sun) • Projet « Grid Data Service » (GDS) • ACI Masse de données • IRISA (Rennes), LIP (Lyon) et LIP6 (Paris) • Depuis 2003 : 3 thèses, 3 stages de DEA • Langages • JAVA (16248 lignes de code) • C (9728 lignes de code) CDUR 2005 - Paris
Home Tolérance aux fautes LDG (Local Data Group) GDG (Global Data Group) JuxMem (Juxtapose Memory) Cohérence et tolérance aux fautes • Modèle de cohérence relâchée : la cohérence à l’entrée • Association entre donnée et objet de synchronisation • Verrou en écriture et en lecture • Ecrivain unique • Lecteurs multiples Passage à l’échelle CDUR 2005 - Paris
JuxMem: une architecture hiérarchique Modèle logique Support physique réseau Grappe de calculateurs CDUR 2005 - Paris
Cohérence Adaptateur Communication de goupe Diffusion atomique Consensus Détecteurs de fautes Communication de groupe Application de mécanismes de tolérance aux fautes • Travail fondamentald’algorithmique distribuée • Propriétés souhaitées • Groupes auto-organisants • Diffusion atomique • Architecture en couches • Basé sur les travaux d’André Schiper (EPFL) • Détection hiérarchique de défaillancesMarin Bertier (LIP6) CDUR 2005 - Paris
Protocole de cohérenceProtocole hiérarchique (2) Envoi du verrou en écriture (3) Demande du verrou en lecture (1) Demande du verrou en écriture CDUR 2005 - Paris
Protocole de cohérenceUn protocole hiérarchique (6) Demande et envoi du verrou en lecture (7) Relâchement du verrou (4) Relâchement du verrou (5) Envoi du verrou en lecture CDUR 2005 - Paris
Ecriture Lecture Ecriture Lecture Donnée Lecture (observation) Problème : la visualisation • Applications visées : • Applications basées sur le couplage de code • Objectif : améliorer l’observation d’une donnée partagée • Accélérer l’accès à une donnée • Ne pas dégrader les performances des autres sites • Moyen • Relâcher les contraintes de cohérence sur les observations CDUR 2005 - Paris
Evaluation des performances La cohérence à l’entrée • Le scénario de l’observateur • 50 écritures • 50 lectures • 50 observations • La plate-forme experimentale : Grid’5000, site rennais • Opterons bi-processeurs 2.2GHz, 2Go RAM • Réseau ethernet gigabit Observateur (lecteur) Producteur (écrivain) Consommateur (lecteur) CDUR 2005 - Paris
Temps d’accès moyens (1ko) • Producteur : 19 ms • Consommateur : 19 ms • Observateur : 19 ms Evaluation des performances La cohérence à l’entrée • Temps d’accès moyens (1ko) • Producteur : 19 ms • Consommateur : 19 ms CDUR 2005 - Paris
Proposition d’amélioration La lecture relâchée • Exploiter des copies « anciennes » • Applications : visualisation, moteurs de recherche • Copies disponibles sur le client et son LDG • Ne plus prendre le verrou en lecture • Rapidité de la lecture • Réduction du risque de famine • Nouvelle primitive d’accès : « rlxRead » • En revanche des données moins « fraîches » sont acceptées CDUR 2005 - Paris
LDG 1 LDG 2 D o c Proposition d’amélioration La lecture relâchée • Contrôler la fraîcheur de la donnée • Borner l’écart entre la version la plus récente et celle retournée par la lecture relâchée • Spécifier une fenêtre de lecture • Nouvelle primitive d’accès : rlxRead(tampon, fenetre) • Maîtriser la version de la donnée retournée • Limiter le nombre de prises de verrou en écriture successives (D) • Limiter l’écart des versions entre le client et son LDG (o) CDUR 2005 - Paris
LDG 1 LDG 2 D o c Lecture relâchée Modélisation UML CDUR 2005 - Paris
Evaluation du protocole Comportement d’un observateur • Le scénario de l’observateur • Producteur : 50 écritures • Consommateur : 50 lectures • Observateur : 50 lectures Observateur (lecteur) rlxRead Producteur (écrivain) Consommateur (lecteur) CDUR 2005 - Paris
Evaluation des performances La cohérence à l’entrée, extension lecture relâchée • Temps d’accès moyens (1ko, D=0, o=0) • Producteur : 19 ms • Consommateur : 19 ms • Observateur : 9 ms CDUR 2005 - Paris
Temps d’accès moyens (1Mo, D=0, o=0) • Producteur : 69 ms • Consommateur : 63 ms • Observateur : 44 ms Evaluation des performances La cohérence à l’entrée, extension lecture relâchée • Temps d’accès moyens (1Mo, D=3, o=6) • Producteur : 60 ms • Consommateur : 61 ms • Observateur : 23 ms CDUR 2005 - Paris
Conclusion • Extension d’un modèle de cohérence • Notion de lecture relâchée • Application : visualisation • Mise en œuvre dans la plate-forme JuxMem • Evaluation des performances • Développement d’une application synthétique pour les tests • Mesures sur le site rennais de la plate-forme Grid’5000 • 10 types d’expérimentations réalisées • Gain de temps en lecture jusqu’à 50% • Mécanisme peu intrusif : pas de dégradation des performances CDUR 2005 - Paris
Perspectives • Tests multi-sites • Expérimentations en cours : passage à l’échelle • Une centaine de nœuds répartis sur 4 sites (Rennes, Lyon, Orsay, Sophia) • Par site : 6 copies de la données 6 producteurs, 6 consommateurs et 6 observateurs… • Auto-adaptabilité • Variation de la fenêtre de lecture • Adaptation en fonction de la charge réseau • Qualité d’observation http://juxmem.gforge.inria.fr/ CDUR 2005 - Paris