Projet ViSaGe : implémentation de l administration et du monitoring de ViSaGe (Virtualisation du Stockage appliquée aux Grilles informatiques)

RenPar 18/ SympA 2008 / CFSE 6 / JC 2008 Fribourg en Suisse, 11 au 13 février 2008 Projet ViSaGe : implémentation de l administration et du monitoring de ViSaGe (Virtualisation du Stockage appliquée aux Grilles informatiques) Salam Traboulsi, Jacques Jorda, Abdelaziz M zoughi Institut de Recherche en Informatique de Toulouse IRIT Université Paul Sabatier Toulouse III 31062 Toulouse Cedex, France {traboul, jorda, mzoughi}@irit.fr Résumé La grille offre une large gamme de ressources distribuées pour le stockage de données, en particulier pour les tâches interactives telles que les résultats des expérimentations de simulation et d analyse des données. Les principaux problèmes liés au stockage de données dans les grilles sont l hétérogénéité des ressources ainsi que leur dispersion, et leur dynamicité. Pour résoudre ces problèmes, ViSaGe 1 a proposé l agrégation de ces ressources dans un espace virtuel. Chaque ressource de stockage étant caractérisée par sa charge qui évolue durant le temps d exécution, les choix relatifs à la gestion de ces espaces virtuels sont critiques. Dans cet article, nous présentons l utilisation du service d administration et de monitoring Admon comme outil d aide à la gestion de stockage. Nous allons décrire son architecture hiérarchique et ses différentes fonctionnalités, et montrer son efficacité. Il est formé de deux modules : le module d administration qui rend plus aisée la gestion de stockage, à partir des données collectées et analysées par l autre module : le monitoring. Admon est caractérisé par son architecture hiérarchique. Cette architecture permet à ses composants de communiquer afin de gérer le stockage des données pour améliorer la performance. Mots-clés : Administration, Monitoring, Virtualisation du stockage, Grille 1 Introduction La grille est une collection de nœuds de calcul et de stockage [1]. Elle fait partie des évolutions des technologies de télécommunications dans les systèmes informatiques. La grille offre une large gamme de ressources distribuées pour le stockage de données, en particulier pour les tâches interactives telles que les résultats des expérimentations de simulation et d analyse des données [1][2]. Les principaux problèmes liés au stockage de données dans les grilles sont l hétérogénéité des ressources ainsi que leur dispersion, et leur dynamicité [1]. Le projet ViSaGe[4] offre des services de virtualisation de stockage pour résoudre ces problèmes. Il est développé au sein de l IRIT en partenariat avec les industriels SEA- NODES 2, CS SI 3 et EADS CCR 4. ViSaGe permet de regrouper un ensemble de ressources de stockage physiques dans un seul espace de stockage virtuel. Ces ressources de stockage sont dédiées à la virtualisation et appartiennent à des nœuds de calcul ou de stockage. Ces nœuds sont caractérisés par leur qualité de service et leur disponibilité qui évoluent dans le temps. Par exemple, la charge sur un nœud est susceptible d augmenter significativement durant un laps de temps restreint. Une telle évolution de la charge pendant le temps d exécution d une application rend critique la prise de décision dans un 1 Projet national RNTL financé par le ministère de recherche sous contrat # 04K459. http ://www.irit.fr/visage/ 2 http ://www.seanodes.fr/ 3 http ://www.c-s.fr/ 4 http ://www.eads.net/1024/en/trailer_eads.html

système de gestion de stockage comme visage (protocole de gestion de stockage, la distribution des tâches). C est pourquoi une surveillance des mesures critiques (comme la charge du CPU, du réseau et de la bande passante disque) identifiant la charge et du temps de service des applications, est nécessaire. Dans ce contexte, ViSaGe a proposé un outil de surveillance et d aide à la décision et au déploiement. Cet outil est représenté par le service d administration et de monitoring de ViSaGe, et baptisé Admon. Le service d administration et de monitoring est formé de deux modules : l un d administration est dédié à la gestion des composants de ViSaGe, l autre de monitoring se charge de collecter les informations nécessaires pour surveiller chaque nœud pour la gestion du stockage. Dans cet article, nous présenterons l architecture d Admon et montrerons son efficacité. Nous verrons que sa position au sein de ViSaGe lui permet d enrichir ses connaissances concernant l état d un nœud. Dans la section 2, nous présenterons un état de l art des systèmes de monitoring existants. Nous rappellerons dans la section 3 l organisation générale de la grille, puis nous introduirons l architecture logicielle de ViSaGe afin de mieux comprendre comment s organisent les services d administration et de monitoring. Dans la section 4, nous introduirons l interface et les fonctionnalités d Admon, avant de montrer son utilité par des expérimentations dans la section 5. Nous conclurons par la section 6. 2 État de l art Dans un environnement de système distribué comme les grilles, la gestion du stockage s appuie sur des décisions pour améliorer la performance. Ces décisions peuvent être par exemple le placement des données, la distribution des tâches, l équilibrage de la charge, etc. Les informations collectées sur l état des nœuds sont primordiales pour pouvoir prendre des décisions adéquates ; elles concernent les nœuds (de stockage ou de calcul) de la grille, les liens (largeur de la bande passante et latence) et les applications soumises. Dans la littérature nous trouvons plusieurs outils de surveillance pour collecter ces informations, chacun étant caractérisé par les informations auxquelles il s intéresse. Aucun de ces outils ne présentant l ensemble des caractéristiques requises pour un système de virtualisation tel que ViSaGe, notre outil de surveillance Admon se trouve à l intersection des caractéristiques de ces différents outils. Nous allons présenter ci-dessous les principaux d entre eux, et indiquer en quoi ils sont insuffisants pour remplir l objectif fixé. NWS (Network Weather Service) [3] est un outil simple à déployer, qui surveille les nœuds de calcul et les liens. Il fournit des prévisions concernant des exécutions ayant de courtes durées, en se basant sur l historique des informations collectées. NWS semble séduisant, mais il n offre pas de données bas niveau sur le stockage (les débits d entrée/sortie) ni d informations sur les applications soumises. Autopilot [6] est un système de surveillance des applications soumises à l échelle de la grille, mais il n offre pas d informations sur les nœuds de la grille. Il est donc trop superficiel pour notre usage. A l inverse, Hawkeye [8] est un outil pour surveiller les nœuds de la grille et leur liens, mais il ne surveille pas les applications soumises. Ganglia [10] est dans la même catégorie. Ce système collecte des informations sur les nœuds de calcul, de stockage et en plus sur les liens. Ganglia permet d afficher l utilisation des ressources dans le passé (par exemple : la charge du CPU d un nœud pendant la dernière heure ou dernier mois, etc.), mais il n offre pas la possibilité de faire des analyses réelles de performance. A la différence des outils précédants, R-GMA (Relational Grid Monitoring Architecture)[5] fournit des informations sur les nœuds de la grille et les liens, et procède aussi à la génération de traces des applications. Son écueil majeur réside dans son inaptitude à nous proposer des solutions qui permettent ViSaGe à prendre les décisions adéquates, citées ci dessus, améliorant la gestion de stockage. Netlogger (Networked Application Logger) [7] est un outil de surveillance et d analyse de performance. Il est utilisé pour surveiller les nœuds, les liens et les applications. Il permet de détecter les goulots d étranglement d une application (la perte de temps durant l exécution), ce qui en fait un système relativement complet. Netlogger et les systèmes présentés ont montré leurs efficacités pour étudier ou analyser la performance du monitoring et de l exécution des applications, mais pas dans le but d améliorer la performance d un système de stockage. Cependant, dans ViSaGe, nous avons besoin d un outil qui puisse s interfacer avec les autres composants de ViSaGe et qui soit capable, de manière proactive, d utiliser la charge d un nœud pour mieux distribuer les tâches et améliorer la performance des proto- 2

Utilisateur de la grille portail Hôte de proximité Hôte frontal Hôte frontal Pare-feu Site A Site B Hôte contrôleur Nœuds de calcul Nœuds de stockage /* L'utilisateur détermine la valeur des mesures à surveiller*/ Monitored_criteria Value /* Admon Initialise les valeurs des mesures à surveiller*/ User_criteria_name= Monitored_criteria; if(criteria_name = User_criteria_name) then Criteria_max_value=Value; else Criteria_max_value=max_value; /*Monitoring d'admon collecte les valeurs de toutes les mesures */ do{ Criteria_value = collected_value; /*Contacter administration d'admon pour prendre une décision, si nécessaire*/ if( collected_value=criteria_max_value) then send_msg_to_admon(criteria_name) }while(1) Communication inter-site Communication intra-site Hôte frontal Site C FIG. 1 Architecture de la grille. FIG. 2 L algorithme suivi par le monitoring. coles de gestion de stockage. De fait, si la charge d un nœud n est pas due aux applications soumises dans le système distribué géré (c est-à-dire si elle est due à des applications locales), la distribution des applications sur les nœuds peut ne pas être judicieuse. ViSaGe propose donc un outil qui permet d étudier la charge des nœuds, prenant en paramètre les informations collectées sur les ressources de la grille et les traces des applications, pour améliorer la performance de gestion du stockage virtuel. 3 L environnement et l architecture d Admon Dans le but d atteindre les objectifs présentés dans la première section, l architecture d Admon est fortement liée à l environnement de ViSaGe. Nous présenterons dans les sous-sections suivantes l architecture de la grille, l architecture logicielle de ViSaGe et enfin celle d Admon. 3.1 Architecture de la grille La grille est constituée de sites (figure 1). Les sites sont composés d un ensemble de nœuds de stockages et de nœuds de calcul. Un nœud représente un ensemble de ressources possédant une adresse IP : un PC, une baie de stockage, etc. À un site correspond un domaine administratif distinct possédant ses propres politiques de sécurité. L interconnexion entre ces différents sites est réalisée par le biais de leurs hôtes frontaux. Pour utiliser la grille, un utilisateur doit posséder une identité grille. Cela permet au système de limiter ses droits au strict nécessaire et de pouvoir comptabiliser sa consommation de ressources. Pour se connecter l utilisateur doit utiliser un hôte de proximité : un portail de grille. Un portail de grille permet l authentification de l utilisateur et lui présente l interface des différents services qu il est autorisé à utiliser. Une fois connecté, l utilisateur peut utiliser les différents services grilles disponibles. Ces services peuvent être distribués ou centralisés. Leur déploiement respecte généralement l architecture hiérarchique : grille, site, nœud. Pour accéder aux sites, l hôte frontal du site exige une authentification pour avoir l autorisation d usage des ressources de son site, afin de respecter au mieux les politiques de sécurité. Enfin, les nœuds de calcul et de stockage sont utilisés pour exécuter les applications grilles et pour stocker les données. 3.2 Architecture logicielle de ViSaGe ViSaGe est l acronyme de : Virtualisation du Stockage appliquée aux Grilles informatiques. Il s agit d un service de grille de gestion de données qui permet la virtualisation de ressources de stockage hétérogènes et distribuées, accessibles de manière uniforme par le biais d un système de gestion de fichiers spécifique. ViSaGe possède la particularité de mettre en adéquation les besoins de l utilisateur de la grille et les disponibilités du système par le biais de qualité de service définies sur les volumes virtuels. Dans cette sous-section nous allons présenter l architecture logicielle de ViSaGe. 3

application Admon au niveau Grille OMG_Event OAG_Event Monitoring V Visagefs Vrt Vccc Administration V Admon au niveau Site OMS_Event OAS_Event AM_Sensor AM_Event AA_Event Vcom Composant logiciel d admon Admon au niveau nœud Mesures collectées (/proc,...) Composant logiciel de ViSaGe FIG. 3 Interconnexion des composants logiciels de ViSaGe. FIG. 4 Interconnexion des composants logiciels d Admon. ViSaGe est formé de cinq composants principaux (figure 3) : Vcom, Visagefs, Admon, Vrt, et Vccc. Vcom est un système de communication extensible pour les messages de contrôle et le transfert des données. Il fournit aux autres composants de ViSaGe un moyen sûr, efficace et adaptable pour communiquer sans se soucier des détails liés à l infrastructure sous-jacente ; Visagefs [9][11] est un système de gestion de fichiers de niveau grille. Il fournit aux utilisateurs de grille une interface de type fichier pour l accès à leurs données. Il assure les fonctionnalités usuelles d un système de fichier classique, dans le contexte d un environnement distribué large échelle ; Admon est un service d administration et de monitoring pour gérer et surveiller l ensemble des services de ViSaGe. Il est utilisé par tous les autres composants de visage. Nous détaillerons son architecture dans la sous section suivante ; Vrt est un service de virtualisation qui procède aux agrégations logiques des ressources de stockage physiques à la demande d Admon. Il met à la disposition de Visagefs des espaces virtuels de stockage découpés en volumes logiques, qui à leur tour sont découpés en objets de placement (les objets de placement représentent l abstraction du placement physique des données sur les ressources de stockage). A chaque objet de placement est associé une politique de placement des données adaptées fournies à l application par Visagefs. Si, pendant l exploitation des données, la politique de placement choisie initialement ne peut plus satisfaire la qualité de service préconisée par l application, Admon contacte le Vrt et effectue les actions nécessaires permettant d adapter la politique de placement (changement de protocole de cohérence, création d un nouveau réplica, etc.) ; Vccc est une librairie extensible de gestion de la cohérence et de la concurrence. Elle met à la disposition de Vrt et de Visagefs un ensemble de protocoles de gestion de la concurrence et de la cohérence [3]. 3.3 Architecture logicielle d Admon La surveillance des ressources de stockage ainsi que leur gestion sont assurées par le composant d administration et de monitoring de ViSaGe : Admon. Il est composé de deux modules : un module d administration dédié à l administration des composants de ViSaGe (installés sur les nœuds de calcul, les hôtes de contrôleurs et les hôtes frontaux), et un module de monitoring qui permet de collecter des informations nécessaires à la surveillance des performances du système (sur les mêmes nœuds que précédemment). Pour pouvoir propager les informations requises, l architecture logicielle de chacun de ces deux modules d Admon se calque sur l infrastructure de la grille. Un élément logiciel est déployé à chacun des 4

niveaux de cette infrastructure : au niveau grille (un service grille et un outil de niveau grille), au niveau site (un outil de niveau site) et au niveau nœud (un agent local). Le service de grille permet d accéder aux fonctionnalités d Admon par le biais d un portail de grille. Ce service grille respecte le standard WSRF 5. Nous détaillons dans la section suivante les fonctionnalités de composants d Admon. 4 Fonctionnement et utilisation d Admon Cette section va nous permettre de détailler le fonctionnement et l utilisation de différentes routines des éléments d Admon, ainsi que les interfaces offertes. Les informations et les tâches accomplies par ces interfaces résultent d un travail collaboratif entre les modules d administration et de monitoring, ainsi qu entre Admon et les autres composants de ViSaGe. 4.1 Monitoring de ViSaGe Le système de monitoring de ViSaGe est semblable à tout autre système de monitoring (NWS [3], Ganglia [10]... ) en ce qu il sonde les mêmes informations (taux d occupation de CPU, taux d utilisation de disque, taux d utilisation de mémoire et taux d utilisation de la bande passante réseau). Cependant, son originalité consiste à collecter des informations en rapport avec les performances d entrée/sortie du sous-système disque, ainsi que les temps d exécution des différentes applications de lecture et d écriture de Visagefs. L agent de monitoring se situe sur chaque nœud. Il est implémenté par deux routines : AM_sensor et AM_event (figure 4). AM_sensor est un thread qui sert à collecter les informations concernant la disponibilité du système (depuis /proc contenant l état du noyau Linux). À partir de ces informations, AM_sensor génère un ensemble de tuples (date, taux d utilisation de la mémoire, taux d utilisation du CPU, taux d utilisations des disques (nombre de lectures et écritures, débit des opérations de lecture et écriture), taux des données envoyées/reçues sur l interface réseau). Nous avons utilisé le moteur de Base de Données Berkeley, extrêmement rapide et simple à mettre en œuvre, pour rendre persistantes ces informations. AM_event est utilisé pour traiter les messages envoyés via Vcom. Il s occupe de tout ce qui est événementiel (par exemple, contacter AM_event pour récupérer l état actuel du nœud). Se basant sur les informations collectées ou bien sur une contrainte précisée par l utilisateur de la grille, l agent monitoring va suivre la méthodologie illustrée dans la figure 2. Dans sa version actuelle, l agent de monitoring collecte les informations sur un intervalle de temps de cinq secondes. Il synthétise les informations sur un intervalle de temps d une minute afin de différencier les modifications significatives des changements ponctuels liés à des épiphénomènes. Les intervalles de temps choisis sont arbitraires. L outil monitoring site est implémenté par une routine appelée OMS_event (figure 4). À la détection de changement de valeur de données collectées au niveau de chaque nœud, l outil monitoring de site reçoit les nouvelles valeurs de mesures observées sur le nœud correspondant. De plus, il observe le cycle de vie des nœuds de son site. Au cas où un nœud n existe plus, il contacte l outil d administration de son site pour l enlever de la liste des nœuds vivants avant de signaler ce changement à l outil d administration de la grille. L outil monitoring de la grille est implémenté par une routine appelée OMG_event (figure 4). Il sert à récupérer ou à envoyer les informations concernant l état global de la virtualisation. Les informations de monitoring sont aussi utiles pour le Vrt de ViSaGe. Elles permettent au Vrt de retrouver l historique des commandes lancées sur le même nœud, et même prendre en compte cet historique en cas de redémarrage de ViSaGe (par exemple, le chemin d accès vers les ressources de stockage, l identifiant des volumes logiques créés, etc.). 4.2 Administration de visage L outil d administration de la grille prend des décisions par rapport aux informations collectées par le monitoring (figure 3). De plus, il gère les commandes de l utilisateur de la grille via le service de grille d Admon. 5 http ://www.globus.org/wsrf/ 5

L outil d administration de site est le lien entre l outil d administration de la grille et l agent d administration au niveau nœud (figure 4). De plus, il peut inscrire toute nouvelle ressource de stockage et de calcul qui pourra dès lors participer à l espace de stockage virtualisé dans ViSaGe. Les agents d administration constituent le dernier maillon de la chaîne (figure 4). Ils sont distribués sur les nœuds. Ils contactent l outil d administration de leur site pour mettre leur nœud à la disposition de ViSaGe pour participer à l espace virtuel. 4.3 L API d Admon Pour la mise en œuvre de la virtualisation et de l administration des ressources de stockage virtuel de ViSaGe, nous avons conçu un service grille qui enrichit le système d information de la grille par des informations pour la gestion du stockage virtualisé. Le service grille d Admon est composé de deux parties : une partie cliente et une partie serveur. La partie cliente est implémentée en Java et reliée aux services de virtualisation de notre partenaire CS SI. Ces services de virtualisation ont été développés pour être déployé sur une grille quelque soit le système de gestion de fichiers sous-jascent (ViSaGe). Ces services ont été implémentés sur la base du middleware Globus Toolkit (GT4.0) 6 sur des technologies ouvertes compatibles et sécurisées : XML, Java, SOAP, etc.. Ils ont été validés sur la grille elis@ 7. La partie serveur est liée à une interface de communication qui est l API d Admon. Cette partie intègre les différentes méthodes d administration et de monitoring ViSaGe au niveau grille. L utilisateur de la grille, via une page web, a la possibilité d effectuer toutes les commandes et de déterminer une contrainte de performance (la répartition de la charge, etc.). Les commandes d Admon permettent notamment la configuration de ViSaGe et l utilisation des informations du monitoring. La contrainte de l utilisateur enrichira l analyse de performance du monitoring d Admon. Les commandes d administration concernent la création d un espace virtuel, la création d un volume logique, le partage des ressources et le placement des données, le montage du système de gestion du fichiers (Visagefs), etc. Les commandes de monitoring permettent la récupération des informations concernant l état d un nœud, la liste des nœuds ViSaGe, etc. Une partie de ces commandes (par exemple : création d un espace virtuel, création d un volume logique) sont exécutées par le Vrt. Dans ce cas, Admon est utilisé comme moyen de communication. Le reste des commandes sont exécutées par Admon. Les sorties de toutes ces commandes sont en XML. Nous montrerons dans la section suivante l utilisation de ces commandes. 5 Expérimentation Admon est un outil de surveillance dont le but est de gérer au mieux l utilisation des nœuds de la grille en évitant de surcharger les nœuds déjà beaucoup sollicités. La grille étant composée de nœuds hétérogènes appartenant à des domaines administratifs distincts, l ordonnanceur des tâches de la grille peut ne pas avoir le contrôle sur les différents nœuds choisis. Il en résulte que la distribution des tâches dans un tel environnement doit être précédée d une étude de la charge des différents nœuds candidats. Dans cette expérimentation, nous allons montrer comment Admon permet de gérer une évolution de la charge d un nœud due à d autres tâches que celles liées à ViSaGe. Nous utilisons une grille, telle que présentée dans la section 3.1, et regroupant 4 sites : IRIT, SEANODES, EADS CCR et CS SI. Pour les besoins de notre expérience, nous avons choisi 4 nœuds de calcul distribués sur les 4 sites. Nous avons configuré ces 4 nœuds (nœud1, nœud2, nœud3 et nœud4) fonctionnant sous Linux kernel 2.6.23. Nous avons installé sur tous les nœuds les différents agents d admon. Sur nœud1, nous avons installé en plus les outils grille et site d Admon, ce qui signifie qu il y aura, sur ce nœud les métadonnées utilisées pour le stockage virtuel de ViSaGe. Les outils de monitoring au niveau de chaque site connaissent les noeuds du site où ViSaGe s exécute. Les agents de monitoring placés sur chaque nœud collectent les informations pertinentes. Admon analyse la charge de ces nœuds au niveau de l outil de monitoring du site. Cette analyse permet de détecter les variations de la charge sur un nœud, la charge d un nœud par rapport aux autres nœuds (nœud très chargé ou pas chargé), etc. Pour montrer l efficacité et l utilité d Admon pour ViSaGe, nous avons utilisé l application AMIBE. 6 http ://www.globus.org/ 7 http ://agena.c-s.fr : 8081/visageportal 6

noeud1 noeud3 noeud4 noeud2 100 90 80 Charge_CPU (%) 70 60 50 40 30 20 10 0 Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Ro Phase 1D w w w w w w w w w w w w Phase w w 2D w w w w w w w w Phase w w w 3D w 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Temps (sec) FIG. 5 L état des nœuds ViSaGe durant l exécution d AMIBE. AMIBE est un mailleur utilisé par le consortium européen EADS CCR pour les simulations électromagnétiques. Le processus d exécution d AMIBE comprend trois phases, l exécution de chaque phase dépendant des résultats de la phase précédente. La première étape est la phase du maillage 1D. Cette phase commence par une description structurelle du travail. Elle est exécutée sur un seul nœud et génère un répertoire avec un fichier par face à mailler. À la fin de cette phase, l outil d administration d Admon au niveau grille réplique le résultat sur l ensemble des sites utilisés par ViSaGe (avec au moins une réplique par site). Après cette réplication, la mission de la phase 2D peut commencer. Celle-ci permet de créer des répertoires contenant des informations par face. La dernière phase, la phase 3D, collecte et agrège les différents fichiers résultants de la phase 2D dans un même ensemble de fichier 3D. Pour l exécution d AMIBE, nous devons préciser la taille de l arête de chaque face. Dans cet article, notre but étant de montrer les différentes fonctionnalités d Admon, nous avons choisi une valeur moyenne d arête (50), initialisée avant de commencer la première phase. Nous avons utilisé 3 nœuds pour AMIBE : Un noeud pour la phase 1D et 3D et deux autres noeuds pour la phase 2D. Nous avons utilisé la phase 2D pour illustrer notre expérimentation. Nous avons supposé que l utilisateur de l application AMIBE a fixé une contrainte sur la charge du CPU en précisant sa valeur maximale (dans notre exemple 60%), c est-à-dire que le choix des nœuds pour la phase 2D va dépendre de la valeur de la charge du CPU. L expérience se déroule de la manière suivante : Pour commencer, nous avons démarré ViSaGe sur nœud1. La première phase, qui doit permettre de créer les répertoires de la phase 1D sur la machine locale, est exécutée sur nœud1. Nous avons commencé par lancer les commandes d administration nécessaires à la création d un volume logique virtuel sur ce nœud, avant de monter le système de gestion de fichiers (commandes CreateVs, CreateLv, CreateSr, ShareSrs, FormatLv et MountVisagefsNode). Une fois ViSaGe a démarré, nous avons lancé la phase 1D d AMIBE (figure 5). Pour démarrer la deuxième phase, nous avons utilisé Torque (l ordonnanceur des tâches) pour distribuer les tâches sur les noeuds utilisés par notre application. La distribution de tâches doit être judicieuse vis-à-vis de l état des nœuds. Avant l exécution de la phase 2D, nous avons choisi un des deux nœuds candidats à l exécution nœud2 pour lancer des travaux locaux (non relatifs à la grille) simulant l utilisation de ce nœud localement par un utilisateur virtuel. Le but de cette manœuvre est d augmenter la charge du CPU d une manière progressive afin de la stabiliser sur une valeur maxi- 7

male, l outil de monitoring teste la charge des différents nœuds candidats à l exécution de la phase 2D, et compare cette valeur avec la contrainte établie par l utilisateur grille initialement (60 % dans notre exemple). La figure 5 montre l état de la charge CPU des nœuds, et que nœud2 à un taux d occupation CPU maximal 80%. Nous pouvons remarquer qu avant de commencer la phase 2D le taux CPU de ce même nœud est plus plus grand que 70%. Il en résulte que ce nœud ne sera pas utilisé pour la deuxième phase. Pour appliquer cette décision, Admon effectue une mise à jour de la liste des nœuds utilisés par Torque avant la distribution des tâches. Puis il exécute les commandes d administration pour monter le système de gestion de fichiers sur nœud3 et nœud4, et il y réplique les données de la phase 1D. La même figure (figure 5) montre l état des nœuds pendant l exécution de la phase 2D, illustrant leur charge élevée du CPU durant cette phase. L exécution d AMIBE se termine par la phase 3D (figure 5) de synthèse des informations sur nœud1. 6 Conclusion Dans cet article nous avons présenté Admon, un service d administration et de monitoring de ViSaGe dédié à analyser la charge d un nœud pour mieux distribuer les tâches à l échelle de la grille dans un système de stockage virtuel. l implémentation d Admon montre son interfaçage avec les autres composant de ViSaGe. Nous avons montré à travers un cas d utilisation avec l application : le mailleur AMIBE, comment Admon est capable d utiliser le critère charge des nœuds afin de mettre en évidence son aspect proactif. Par conséquent, il permet une meilleure distribution des tâches sur les nœuds les moins chargés pour améliorer le temps de réponse : permettre une exécution optimale de l application. Bibliographie 1. I. Foster and C. Kesselman, editors. "The Grid : Blueprint for a Future Computing Infrastructure". Morgan Kaufmann Publishers, 1999. 2. William E. Johnston, Dennis Gannon, and Bill Nitzberg. "Grids as production computing environments : The engineering aspects of NASA s Information Power Grid". In Proc. 8th IEEE Symp. on High Performance Distributed Computing. IEEE Computer Society Press, 1999. 3. R.Wolski, N.T. Spring, and J. Hayes. "The Network Weather Service : A Distributed Resource Performance Forecasting Service for Metacomputing". Future Generation Computing Systems, Metacomputing Issue, 15(5-6) : 157-768, oct. 1999. 4. F. Thiebolt, I. Frain, A. M zoughi. "Visage- virtualisation du stockage dans les Grilles informatiques". 16ème Rencontre Francophones en Parallélisme Architecture système et composant, pp. 219 224, Avril 2005. 5. A. Cooke, A. Gray, and et al., "The relational grid monitoring architecture : Mediating information about the grid", 2004. 6. www-pablo.cs.uiuc.edu/project/autopilot. 7. D. Gunter and B. Tierney and B. Crowley and M. Holding and J. Lee, "NetLogger : A Toolkit for Distributed System Performance Analysis", In Proceedings of the IEEE Mascots. 8. http ://www.cs.wisc.edu/condor/hawkeye/. 9. F. Thiebolt, A. M zoughi, J. Jorda. "Visagefs - Système de fichiers pour grille à QoS intégrées". 17ème Rencontre Francophones en Parallélisme Architecture système et composant, pp. 196 203, Oct. 2006. 10. M.L. Massie et al. "The ganglia distributed monitoring system : design, implementation, and experience". Parallel Computing 30 (2004) 817-840. 11. F. Thiebolt, A. Ortiz, A. M zoughi. "VisageFS : Dynamic Storage features for wide-area Workflows". Dans : International Conference on Parallel and Distributed Computing Systems (PDCS 2007), Cambridge, Massachusetts, USA, 19/11/07-21/11/07, S.Q. Zheng (Eds.), ACTA Press, pp. 61-66, Nov. 2007. 8