GDS – Paris, 13 Octobre 2006 Un outil de monitoring pour le déploiement dynamique de JuxMem Loïc Cudennec IRISA / INRIA, PARIS project-team Stage de M2RI de Voichita Almasan
GDS - Paris, 13 Octobre La grille de calcul Un ensemble de ressources hétérogènes interconnectées par un réseau Plusieurs domaines d’administration Echelle : 10^3 à 10^4 noeuds Caractérisation des ressources Les noeuds Puissance de calcul Espace de stockage Le réseau Topologie physique Débit Latence La grille et ses ressources
GDS - Paris, 13 Octobre Etablit une interface entre les ressources et les applications Le système d’information Mutualise les informations sur l’état des ressources Propose une vue de la grille Met les informations à disposition de l’ordonnanceur Exemples : Network Weather Service [UCSB] Ganglia [Berkeley/Intel] La gestion des ressources SE noeud SE noeud SE noeud Gestionnaire des ressources Applications distribu é es
GDS - Paris, 13 Octobre Dynamicité de l’infrastructure Des noeuds quittent ou rejoignent la grille Défaillances des noeuds, du réseau, des serveurs de fichiers… Dynamicité de l’application Statiques Utilisent le même nombre de ressources pendant l’execution Besoins prévisibles, réservation statique Dynamiques Modification des ressources pendant l’execution Besoins non prévisibles Interactions avec les gestionnaires de ressources Les applications distribuées Un double niveau de dynamicité
GDS - Paris, 13 Octobre Décrire les besoins d’une application Sélectionner les ressources adéquates S’adapter aux évenements : surcharge, volatilité… Le déploiement grille application Demande informations Selection ressources Lancement jobs Surveillance execution
GDS - Paris, 13 Octobre JuxMem : application distribuée dynamique permettant le partage de données sur la grille Support de la dynamicité de l’infrastructure Mécanismes de routage pair-à-pair (JXTA) Persistance des données en présence de fautes Travaux de Mathieu Jan et Sébastien Monnet (thèses ) Support de la dynamicité de l’application Objet de ce travail : moyens d’interactions avec la grille Etude de cas : JuxMem
GDS - Paris, 13 Octobre Un service de partage de données pour la grille Développé depuis 2003 par PARIS/IRISA Permet l’accès transparent aux données partagées Offre le support pour la tolérance aux fautes et la cohérence des données S’inspire des systèmes à MVP et 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) pour la découverte des ressources JuxMem Juxtaposed Memory
GDS - Paris, 13 Octobre JuxMem Service de partage de données pour la grille Modèle hiérarchique (fédération de grappes) Juxmem group Cluster group A Cluster group B Cluster group C Data group
GDS - Paris, 13 Octobre Les managers Organisent la topologie de JuxMem Les providers Offrent de l’espace de stockage physique Les clients Demandent l’allocation de données dans le service Effectuent des requêtes de lecture/écriture JuxMem Présentation des rôles manager provider client Requête d ’ allocation
GDS - Paris, 13 Octobre Allocation sur 1 provider, dans le même cluster Scénarios Un scénario statique manager provider client Requête d ’ allocation provider
GDS - Paris, 13 Octobre Allocation sur 3 providers, dans 1 cluster (tolérance aux fautes des noeuds) Scénarios Un premier scénario dynamique manager provider client Requête d ’ allocation provider d é ploiement
GDS - Paris, 13 Octobre Allocation sur 2*2 providers, dans 2 clusters (tolérance aux fautes des clusters) Scénarios Un deuxième scénario dynamique managerclient Requête d ’ allocation provider d é ploiement manager provider
GDS - Paris, 13 Octobre Rôle : prendre en charge l’aspect dynamique de JuxMem Interface entre JuxMem et les gestionnaires de ressources Reçoit les requêtes de besoin d’extension de JuxMem Crée et gère les réservations de ressources de l’utilisateur Commande le déploiement de nouveaux rôles JuxMem (provider, manager) Proposition : un outil de monitoring Application JuxMem Moniteur Gestionaires ressources
GDS - Paris, 13 Octobre Proposition : un outil de monitoring Interactions JuxMem Couche de coordination D é ploiement ADAGE R é servation OAR manager client (1) Requête d ’ allocation provider (2) Recherche de providers moniteur (3) Stockage (4) Requête d ’ extension (6) D é ploiement (5) Interactions infrastructure
GDS - Paris, 13 Octobre Implémentation d’un prototype Programmes client et serveur indépendants de JuxMem Communications directes entre client et serveur Modules d’intéraction avec OAR et ADAGE 4000 lignes de code C Mise en oeuvre du moniteur Serveur Moniteur C Programme Client C manager provider d é ploiement Requête d ’ allocation
GDS - Paris, 13 Octobre Plate-forme de test : Grid’5000 4 des 9 sites : Bordeaux, Grenoble, Lyon et Rennes Outil de réservation : OAR [ID-IMAG, Grenoble] Bases de données locales à chaque cluster Outil de déploiement : ADAGE [PARIS, IRISA] Déploiement automatique d’applications distribuées à partir d’une description générique Evaluation du moniteur
GDS - Paris, 13 Octobre En violet : temps de réponse du moniteur En vert : temps de réponse d’OAR Evaluation du moniteur 1 cluster, 1 nouveau noeud toutes les 15 secondes M PPP
GDS - Paris, 13 Octobre En violet : temps de réponse du moniteur Evaluation du moniteur 1 cluster (Manager+Provider) toutes les 15 secondes M P M P M P
GDS - Paris, 13 Octobre En violet : temps de réponse du moniteur Evaluation du moniteur x cluster (Manager+Provider) par étape M P M P M P M P M P M P
GDS - Paris, 13 Octobre Le moniteur est fonctionnel Mise en place d’une interface pour exprimer le besoin de l’application Interactions avec les gestionnaires de réservation et déploiement des ressources Le moniteur est relativement performant Temps de réponse moyen du moniteur < 1s ADAGE : 1s, OAR : 12s Perspectives Intégrer le moniteur comme un rôle JuxMem basé sur un pair JXTA Distribuer le moniteur pour le rendre tolérant aux fautes Partager le moniteur avec d’autres applications (Zorilla [VU/Amsterdam]) Conclusion