1 / 20

Un outil de monitoring pour le d éploiement dynamique de JuxMem

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. La grille et ses ressources. La grille de calcul Un ensemble de ressources h étérogènes interconnectées par un réseau

cora-vinson
Download Presentation

Un outil de monitoring pour le d éploiement dynamique de JuxMem

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Un outil de monitoring pourle déploiement dynamique de JuxMem Loïc Cudennec IRISA / INRIA, PARIS project-team Stage de M2RI de Voichita Almasan

  2. La grille et ses ressources • 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

  3. La gestion des ressources • 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] Applications distribuées Gestionnaire des ressources SE SE SE noeud noeud noeud

  4. Les applications distribuéesUn double niveau de dynamicité • 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

  5. Le déploiement • Décrire les besoins d’une application • Sélectionner les ressources adéquates • S’adapter aux évenements : surcharge, volatilité… Demande informations grille application Selection ressources Lancement jobs Surveillance execution

  6. Etude de cas : JuxMem • 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 2003-2006) • Support de la dynamicité de l’application • Objet de ce travail : moyens d’interactions avec la grille

  7. JuxMemJuxtaposed Memory • 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 • http://juxmem.gforge.inria.fr

  8. JuxMemService de partage de données pour la grille • Modèle hiérarchique (fédération de grappes) Juxmem group Data group Cluster group A Cluster group C Cluster group B

  9. JuxMemPrésentation des rôles manager client Requête d’allocation • 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 provider

  10. ScénariosUn scénario statique • Allocation sur 1 provider, dans le même cluster manager client Requête d’allocation provider provider

  11. ScénariosUn premier scénario dynamique • Allocation sur 3 providers, dans 1 cluster (tolérance aux fautes des noeuds) manager client Requête d’allocation déploiement provider provider provider

  12. ScénariosUn deuxième scénario dynamique • Allocation sur 2*2 providers, dans 2 clusters (tolérance aux fautes des clusters) manager déploiement manager client Requête d’allocation déploiement provider provider provider provider

  13. Proposition : un outil de monitoring • 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) Application JuxMem Moniteur Gestionaires ressources

  14. Proposition : un outil de monitoring (2) Recherche de providers client manager (1) Requête d’allocation (4) Requête d’extension (3) Stockage provider moniteur Interactions JuxMem Couche de coordination (5) Interactions infrastructure RéservationOAR DéploiementADAGE provider (6) Déploiement

  15. Mise en oeuvre du moniteur • 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 Serveur Moniteur C Programme Client C Requête d’allocation déploiement manager provider

  16. Evaluation du moniteur • 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 • http://oar.imag.fr • Outil de déploiement : ADAGE • [PARIS, IRISA] • Déploiement automatique d’applications distribuées à partir d’une description générique • http://adage.gforge.inria.fr

  17. Evaluation du moniteur1 cluster, 1 nouveau noeud toutes les 15 secondes M • En violet : temps de réponse du moniteur • En vert : temps de réponse d’OAR P P P

  18. Evaluation du moniteur1 cluster (Manager+Provider) toutes les 15 secondes M M M • En violet : temps de réponse du moniteur P P P

  19. Evaluation du moniteurx cluster (Manager+Provider) par étape M M M M M M • En violet : temps de réponse du moniteur P P P P P P

  20. Conclusion • 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])

More Related