Une approche hiérarchique des serveurs de calcul

Transcription

1 Une approche hiérarchique des serveurs de calcul Eddy Caron Frédéric Desprez Eric Fleury Frédéric Lombard Jean-Marc Nicod Martin Quinson Frédéric Suter * LIP - ENS Lyon (UMR CNRS-INRIA 5668), 46 allée d Italie, F Lyon Cedex 07 {ecaron, desprez, mquinson, fsuter}@ens-lyon.fr ** LORIA - INRIA Lorraine (UMR 7503), 615 rue du Jardin Botanique, F Villers-Les-Nancy Cedex fleury@loria.fr *** LIFC, Université de Franche Comté, 16 route de Gray, F Besançon Cedex {lombard, nicod}@lifc.univ-fcomte.fr ABSTRACT. This paper presents the architecture and the algorithms used in DIET (Distributed Interactive Engineering Toolbox), a hierarchical set of components to build Network Enabled Server applications in a Grid environment. This environment is built on top of different tools which are able to locate an appropriate server depending of the client s request, the data localization (which can be anywhere on the system, because of previous computations) and the dynamic performance characteristics of the system. RÉSUMÉ. Cet article présente l architecture et les algorithmes utilisés dans DIET (Distributed Interactive Engineering Toolbox), un ensemble hiérarchique de composants pour la construction d applications basées sur les serveurs de calcul dans un environnement de metacomputing. Cet environnement est basé sur différents outils capables de localiser un serveur approprié en fonction de la requête envoyée par un client, des données ayant pu être calculées par des requêtes précédentes (et donc localisées sur d autres serveurs) et des caractéristiques dynamiques du système, en terme de performances. KEYWORDS: Metacomputing, performance prediction, hierarchical scheduling, network enabled servers, CORBA MOTS-CLÉS : Metacomputing, prédiction de performances, ordonnancement hiérarchique, serveurs de calcul, CORBA CPRSR. Volume X - næx/2000, pages 1 à X

2 2 CPRSR. Volume X - næx/ Introduction Les problèmes de très grande taille issus de la simulation numérique peuvent désormais être résolus via Internet grâce aux environnements de metacomputing [FOS 98a]. Plusieurs approches co-existent telles que les langages orientés objet [LEG ], les environnements à base de passage de messages [MPI, PAC ], les boites à outils [FOS 98b], les environnements de calcul global [NIM, XTR ], ceux basés sur le Web [IMW, KAP 98, WEB ], etc. Par ailleurs, la plupart des applications courantes sont numériques et l utilisation de bibliothèques adéquates telles que les BLAS [DON 90], LAPACK [AND 99], ScaLAPACK [J.C 95] ou PETSc [BAL 98] est devenue obligatoire. L intégration de telles bibliothèques dans des applications de haut niveau utilisant des langages comme Fortran ou C est loin d être aisée. En effet, l utilisateur doit toujours spécifier une partie du parallélisme pour les utiliser et distribuer lui-même les structures de données. Enfin, la puissance de calcul (ou la capacité mémoire) nécessaire à ces applications n est malheureusement pas disponible sur toutes les stations de travail. Notre plate-forme cible est le réseau rapide connectant les grappes et les machines parallèles des différentes unités de recherche de l INRIA (projet RNRT VTHD 1 ). Cette architecture est donc fortement hiérarchique puisque le réseau VTHD connecte les UR INRIA entre elles, qui elles-mêmes possèdent dans leurs réseaux propres des grappes de machines connectées par des réseaux plus ou moins rapides. Les machines d où sont lancées les calculs sont soit directement connectées au réseau VTHD ou simplement connectées par les réseaux internes des laboratoires ayant accès à cette plate-forme. Nous sommes donc confrontés à trois problèmes : trouver de la puissance de calcul et de la capacité de stockage, utiliser un réseau hiérarchique de machines et enfin permettre à l utilisateur de porter son application de manière simple et (relativement) transparente. L approche RPC [MAT 00a, MAT 00b] est un bon candidat pour élaborer des environnements de résolution de problèmes dans un environnement de metacomputing. On appelle généralement ces environnements des serveurs de calculs ou NES (Network Enabled Servers). Plusieurs outils offrant cette fonctionnalité comme Net- Solve [NET ], NINF [NIN ], NEOS [NEO ] ou RCS [ARB 97] sont déjà disponibles mais aucun d entre eux ne gère pour l instant spécifiquement les réseaux hiérarchiques de machines. Cet article présente l architecture de DIET (Distributed Interactive Engineering Toolbox), un ensemble hiérarchique de composants pour l élaboration d applications basées sur des serveurs de calcul. Dans un premier temps, nous présentons l architecture générale de la plate-forme DIET et ses principaux composants. Ensuite, nous expliquons comment CORBA peut être utilisé pour connecter les différents composants de DIET. Puis nous décrivons les algorithmes utilisés pour découvrir les ressources ½. http ://

3 Serveurs de Calcul DIET 3 matérielles et logicielles susceptibles de résoudre un problème soumis par un client. Enfin, nous présentons quelques idées de travaux futurs avant de conclure. 2. Architecture de DIET et outils associés Dans cette section, nous donnons des détails sur l architecture de DIET et nous présentons les différents composants impliqués dans sa hiérarchie. Dans [MAT 00b], les auteurs donnent un état de l art des environnements basés sur des NES qui permettent d accéder à des serveurs de calcul via le réseau. D ordinaire, de tels environnements sont composés de cinq types de composants différents : les clients qui soumettent les problèmes aux serveurs, les serveurs qui résolvent les problèmes soumis par les clients, des moniteurs qui récupèrent des informations sur l état des ressources de calcul et les stockent dans une base de données qui contient aussi des informations concernant les ressources matérielles et logicielles, et enfin un ordonnanceur (appelé aussi parfois des agent) qui choisit un serveur approprié en fonction du problème soumis et des informations contenues dans la base de données. Les projets NetSolve [NET ] ou Ninf [NIN ] suivent cette approche. Malheureusement, il n est possible de lancer qu un seul agent chargé de l ordonnancement pour un groupe de serveurs de calculs donné. Cela crée un goulot d étranglement des performances empêchant le déploiement de NetSolve pour de grands groupes de serveurs, et rend le système peu résistant aux erreurs. En effet, la mort du processus agent rend inutilisable la plate-forme toute entière. Pour résoudre ces problèmes, DIET se propose de répartir le travail de l agent selon une nouvelle organisation. Il est ainsi remplacé par un ensemble d agents organisés selon deux approches : une approche multi-agents de type peer to peer améliorant la robustesse du système associée et une approche hiérarchique favorisant l efficacité de l ordonnancement. Cette répartition du rôle de l agent offre divers avantages : une meilleure répartition de la charge entre les différents agents, une plus grande stabilité du système (si un des éléments venait à s arrêter, les autres éléments pourraient se réorganiser pour le remplacer), une gestion simplifiée en cas de passage à l échelle (l administration de chaque groupe de serveurs et des agents associés peut être déléguée). Les différents composants de l architecture de DIET sont présentés dans la section 2.1. Un serveur se compose de Computational Resources Daemons (CRD) et d un Server Daemon (SeD). Nous avons ensuite une hiérarchie (organisée de manière arborescente) d agents dont les Leader Agents (LA) et les Master Agents (MA). Plusieurs hiérarchies pourront co-exister au sein de DIET : les différents MA seront alors connectés en peer to peer. Dans ce chapitre, nous ne présenterons cependant que l approche hiérarchique statique.

4 4 CPRSR. Volume X - næx/2000 Nous allons maintenant détailler les fonctionnalités de base de chacun de ces composants. Un aperçu d outils utilisés dans DIET (SLiM & FAST) sera également donné (section 2.2). Client MA MA MA MA MA MA LA LA LA SeD CRD Figure 1. Vue générale de DIET Composants de DIET Client Un client est une application qui utilise DIET pour résoudre des problèmes. Plusieurs types de clients doivent être capables de se connecter à DIET. Un problème peut être soumis depuis une page web, un environnement de résolution de problèmes tel que Scilab [CAR 01] ou Matlab ou depuis une programme compilé Master Agent (MA) Un MA est directement relié aux clients. Il reçoit des requêtes de calcul des clients et choisit un (ou plusieurs) SeDs qui sont capables de résoudre le problème en un temps raisonnable. Un MA possède les mêmes informations qu un LA, mais il a une vue globale (et de haut niveau) de tous les problèmes qui peuvent être résolus et de toutes les données qui sont distribuées dans tous ses sous-arbres Leader Agent (LA) Un LA compose un niveau hiérarchique dans les agents DIET. Il peut être le lien entre un Master Agent et un SeD, entre un autre LA et un SeD ou entre deux LAs. Son but est de diffuser les requêtes et les informations entre les MAs et les SeDs. Il tient à jour une liste des requêtes en cours de traitement et, pour chacun de ses sous-arbres, le

5 Serveurs de Calcul DIET 5 nombre de serveurs pouvant résoudre un problème donné, ainsi que des informations à propos des données Server Daemon (SeD) Un SeD est le point d entrée d un serveur de calcul. Il gère l ensemble des CRDs et se trouve sous la responsabilité d un LA. Il tient à jour une liste des données disponibles sur un serveur (éventuellement avec leur distribution et le moyen d y accéder), une liste des problèmes qui peuvent y être résolus, et toutes les informations concernant sa charge (mémoire disponible, nombre de CRDs disponibles, etc.). Sur une machine parallèle, un SeD sera donc installé sur le frontal de cette machine et les CRD sur les nœuds eux-mêmes Computational Resources Daemons (CRD) Une ressource de calcul est un ensemble de composants matériels et logiciels qui peuvent effectuer des calculs séquentiels ou parallèles sur des données envoyées par un client (ou par un autre serveur). Il s agit donc d une ressource qui est en attente d une demande de fonction séquentielle ou parallèle de la part du démon de serveur (voir section suivante). Les routines parallèles sont exécutées par un ensemble de CRD lancés sur les nœuds de la machine. Sur une machine interactive, chaque nœud doit avoir un CRD. Dans les autres cas (comme pour les systèmes à traitement par lots), les calculs sont lancés directement du Server Daemon Outils associés à DIET Cette partie présente SLiM et FAST qui sont des outils utilisés par DIET. Ils sont cependant indépendants, et peuvent être intégrés à d autres projets de metacomputing. Ainsi, FAST a été intégré avec succès à la plate-forme NetSolve pour améliorer la précision des prédictions de performances utilisées par l agent pour l ordonnancement SLiM : Scientific Libraries Metaserver SLiM est un outil permettant de déterminer quelles ressources de calcul sont capables de résoudre un problème donné. Le but de SLiM est de faire le lien entre une description du problème et les implémentations disponibles sur les serveurs. Dans la plupart des cas, la correspondance n est pas unique : un même problème peut être résolu par différentes implémentations de différentes bibliothèques, alors qu un autre problème pourra nécessiter plus d une étape de calcul pour être résolu. Par exemple, si l utilisateur veut résoudre un système d équations linéaires au moyen d une matrice creuse, dépendante des données, cela peut s effectuer grâce à un solveur direct ou via un préconditionneur suivi d un solveur itératif. Le point principal de cette approche est de trouver une manière uniforme d exprimer le problème et de décrire les données. Nous aurions pu utiliser le langage de description de problèmes de NetSolve, mais il n est pas standard et ne comporte pas de

6 6 CPRSR. Volume X - næx/2000 moyen d exprimer les appels à des routines parallèles. CORBA semble être une bonne alternative, mais, même si de nombreux services existent pour des domaines tels que la finance et la médecine, aucun service pour le calcul scientifique n a encore été intégré à la norme CORBA. SLiM pourrait cependant être considéré comme un bon candidat pour devenir un service CORBA pour la découverte des ressources disponibles dans un environnement de type grille. Pour cela, SLiM se base sur les taxonomies de problèmes existantes et reconnues que sont GAMS [BOI 94] et RIB [BRO 99]. Toutes les informations nécessaires sont stockées dans un arbre LDAP [HOW 99]. LDAP est le protocole de gestion de bases de données distribuées que nous avons choisi pour ses optimisations en lecture et en recherche de données. De plus, LDAP est très utilisé dans la communauté du metacomputing FAST : Fast Agent s System Timer Application Cliente Connaissances Ordinateurs Mémoire existante Vitesse processeur Système Batch Réseau Bande passante Latence Topologie Protocoles Calculs Faisabilité Espace nécessaire Temps nécessaire 1 Acquisition de données statiques 2 LDAP FAST FAST API Logiciels de bas niveau 4 Acquisition de données dynamiques 3 NWS Connaissances Ordinateurs Etat (en/hors service) Charge processeur Charge mémoire Etat du Batch Réseau Bande passante Latence Figure 2. Vue générale de FAST. FAST [DES 01, QUI 02] est un outil de modélisation des performances dynamiques dans un environnement de metacomputing. Comme l indique la Figure 2, FAST est composé de plusieurs couches et s appuie sur des logiciels de bas niveau. Tout d abord, il utilise un logiciel de surveillance réseau et d activité processeur pour gérer les ressources changeant au cours du temps comme la bande passante et la charge du processeur. FAST utilise le Network Weather Service (NWS [WOL 99]), un outil développé à l Université du Tennessee, Knoxville. C est un système distribué qui scrute périodiquement diverses ressources réseau et de calcul et prédit dynamiquement leur comportement. Pour acquérir les données statiques, FAST inclut des routines de modélisation du temps et de l espace nécessaires pour chaque triplet {problème ; machine ; jeu de paramètres}. Elles sont basées sur l étalonnage à l installation de chaque routine sur chaque machine pour un jeu de paramètres représentatifs (benchmarks puis approximation polynomiale). Cependant, pour certaines routines comme celles qui traitent des matrices creuses, l utilisateur peut fournir lui-même une estimation du temps de calcul en fonction des paramètres en entrée et du nombre de processeurs

7 Serveurs de Calcul DIET 7 utilisés. Si cette fonction ne peut être donnée, l ordonnanceur choisira tout simplement le serveur le plus rapide (et/ou le moins chargé) capable de résoudre le problème demandé. Pour stocker ces données statiques, FAST utilise le même arbre LDAP que SLiM. Le stockage des données dynamiques est géré par NWS. L interface de programmation de FAST est composée d un petit ensemble de fonctions qui combinent les données statiques et dynamiques acquises grâce au niveau inférieur pour produire des valeurs «prêtes à l emploi» pour un ordonnanceur. Le module d acquisition des données dynamiques de FAST améliore NWS. En effet, s il n y a pas de mesure directe de NWS entre deux machines, FAST recherche automatiquement le plus court chemin entre elles dans le graphe des liens scrutés. Dans ce cas, la bande passante estimée est la plus petite observée sur ce chemin. Pour la latence, FAST prend la somme des latences mesurées. De plus, FAST implémente un système de cache des résultats pour réduire le nombre d interrogations de NWS et améliorer les temps de réponse du système Interactions entre SLiM FAST et DIET Pour donner un premier aperçu des interactions entre SLiM et FAST et DIET, considérons un système simple composé d un unique agent et de plusieurs serveurs. La figure 2 montre les différentes étapes d une soumission de problème. L algorithme utilisé dans le cas où plusieurs agents sont organisés hiérarchiquement comme dans DIET est détaillé à la section 4.2. La figure 3 montre les différentes étapes lors de la soumission d un problème. Application Cliente 1 4 SLiM Diet 2 3 FAST Figure 3. Intéraction entre SLiM-FASTet DIET. SLiM donne l implémentation correspondant à la description du problème. DIET gère la recherche du service, l ordonnancement des calculs et le placement des données. L agent envoie la description du problème à résoudre à la hiérarchie DIET (Fig.3 1). DIET interroge SLiM qui contacte la base de données et recherche l ensemble des implémentations susceptibles de résoudre ce problème (Fig.3 2). Cet ensemble est ensuite envoyé à FAST qui prédit le temps d exécution de chacune des solutions pour chacun des serveurs disponibles (Fig.3 3). FAST récupère les données statiques de la base de données (Fig.2 2) et les données dynamiques de NWS (Fig.2 3). Enfin, ces

8 8 CPRSR. Volume X - næx/2000 données sont combinées par FAST en une liste de couples {serveur ; temps estimé} qui est renvoyée à la hiérarchie DIET (Fig. 3 3). L agent DIET prend finalement une décision et retourne la référence du serveur le plus à même à résoudre le problème (Fig.3 4) Scénario d utilisation de DIET Un nouveau client de DIET doit d abord contacter le Master Agent le plus approprié (suivant sa proximité dans le réseau). Une fois que son Master Agent est identifié, le client peut lui soumettre un problème. Pour choisir le serveur le plus approprié pour résoudre ce problème, le Master Agent propage une requête dans ses sous-arbres afin de trouver à la fois les données impliquées (parfois issues de calculs précédents et ainsi déjà présentes sur certains serveurs) et les serveurs capables de résoudre l opération demandée. L algorithme utilisé pour le traitement de ces requêtes sera détaillé en section 4.2. Ensuite, le Master Agent renvoie l adresse du serveur choisi au client et effectue le transfert des données persistantes impliquées dans le calcul. Le client communique ses données locales au serveur et alors la résolution du calcul peut être effectuée. Les résultats pourront être renvoyés au client en fonction du problème. En général, nous essayons autant que possible de laisser les données sur place. 3. Plates-formes objets distribuées Les environnements de type NES peuvent être implantés en utilisant une couche de communication classique par sockets. Ninf et NetSolve sont implantés de cette manière. Plusieurs problèmes de cette approche ont été soulignés comme par exemple le manque de portabilité ou la limitation due au nombre de sockets ouvertes au même instant. Notre souhait est d implanter et ensuite déployer un environnement de type NES distribué efficace à une plus grande échelle. Des environnements objets distribués tels que Java, DCOM ou Corba ont prouvé être une bonne base pour la construction d applications gérant l accès à des services distribués. Ils fournissent non seulement des communications transparentes en milieu hétérogène, mais ils offrent également un cadre pour le déploiement à grande échelle d applications distribuées. Étant un standard ouvert et indépendant du langage, Corba a été choisi comme base pour implanter DIET La norme Corba La norme CORBA, définie par l Object Management Group (OMG), propose une interface standard pour la programmation d applications distribuées à base objets. Un système respectant cette norme est construit autour d un bus de communication entre objets, l Object Request Broker (ORB). Les communications sont réalisées sous forme d appel de méthodes entre des objets pouvant se trouver sur différentes machines.

9 Serveurs de Calcul DIET 9 Différentes implémentations de la norme existent, chacune disponible sur de nombreuses plates-formes. L interopérabilité entre ces implémentations est garantie par le General Inter ORB Protocol (GIOP). Les applications basées sur CORBA bénéficient par conséquent d une bonne portabilité. Du point de vue du développeur, CORBA peut être utilisé avec plusieurs langages de programmation, dont C, C++ et Java. CORBA fournit donc une interface orientée objet de haut niveau pour le développement d applications distribuées. Chaque objet peut exporter certaines de ses méthodes sur le réseau. Pour ce faire, il s enregistre auprès de l ORB et reçoit une référence. La transparence des communications sur un réseau hétérogène est assurée par un compilateur IDL (Interface Description Language) fourni avec chaque ORB. Ce compilateur génère automatiquement le code permettant l encapsulation et la restitution des types de données complexes. CORBA utilise le protocole CDR pour l encapsulation des types simples. Ce protocole est plus performant que XDR. Les données ne subissent en effet de codage que lorsque cela est nécessaire. Le typage dynamique et le téléchargement de la description d un type sont également supportés par le code généré Utilisation de Corba dans DIET D autre part, le niveau de transparence autorisé par C ORBA n affecte pas les performances. La plupart des implémentations de CORBA disposent en effet d une couche de communication fortement optimisée dont les performances se rapprochent de celles des sockets [ANT 98]. De plus, le point crucial du point de vue performances dans DIET sera de trouver le meilleur serveur de calcul pour une requête donnée. Comparé au temps de calcul, le temps passé pour la sélection d un serveur doit être court. La sélection des implémentations des problèmes peut utiliser l IDL Corba, qui constitue une manière standard de décrire ces problèmes. De plus, l architecture Corba définit des ensembles d interfaces spécifiques pour des domaines dédiés, i.e., les codes métiers. Par exemple, des codes métiers ont été définis pour les applications médicales et financières. aucune norme n a pour l instant été proposée pour le calcul scientifique. En utilisant l héritage d interface, d aucun peut définir des problèmes génériques et les implémentations existantes, i.e., le problème est défini comme interface haute et l implémentation en héritera (par exemple toutes les implémentations de produit de matrices hériterons de l interface MatMult). De plus le calcul sur la Grille est un domaine de recherche très actif. Les platesformes existantes sont sujettes à de fréquentes modifications expérimentales et ajouts. Les plates-formes de développement orientées objet autorisent un développement plus simple et une meilleure maintainabilité du code. Corba est donc bien adapté au support de ressources distribuées dans un environnement de type Grille à grande échelle. De nouveaux services dédiés peuvent facilement être publiés, aussi bien que des services existant peuvent être utilisés. Nous pouvons donc conclure que des systèmes Corba sont une des alternatives pour le développement de services spécifiques à la Grille.

10 10 CPRSR. Volume X - næx/2000 Cl MA MA MA MA MA LA LA LA LA LA LA Figure 4. Initialisation d un système DIET. Notre première implantation de DIET est basée sur OmniORB, une implémentation libre de Corba qui offre de bonnes performances de communication. 4. Algorithmes d initialisation et de résolution dans DIET Afin de définir un système hiérarchique d agents, il faut spécifier l ordre dans lequel les agents doivent être démarrés et la politique d administration du système ainsi que l algorithme distribué permettant le placement des calculs sur l ensemble des serveurs. Dans ce paragraphe, nous détaillons le premier point en donnant l exemple de l initialisation d un système DIET simple. Ensuite, nous discutons de la manière dont un serveur est choisi pour résoudre un problème donné en prenant les temps de calcul et de communication en considération Initialisation de DIET La figure 4 montre chaque étape de l initialisation d un système de metacomputing simple. Cette initialisation s effectue du haut vers le bas, chaque élément venant se connecter à son père. L ajout de nouveaux éléments à l arborescence DIET est possible à tout instant selon le même principe. Le système peut donc être administré de manière dynamique. Le nœud père étant un paramètre de lancement de chaque LA et chaque LA transmettant les changements locaux de configuration à son père, l administration peut elle aussi être hiérarchique. Par exemple, un LA peut gérer les serveurs d une organisation comme un laboratoire, chaque équipe lançant et administrant un LA fils pour gérer ses propres serveurs. Chaque MA gère un domaine (comme une université), donnant aux calculs de ses clients un accès privilégié aux serveurs situés dans son domaine. La recherche d un serveur par un MA s effectuera toujours d abord dans son propre

11 Serveurs de Calcul DIET 11 F(A,B) CLIENT MA LA1 LA2 LA3 LA11 LA12 S111 S112 S121 S122 A B S123 F() S21 S31 F() S32 Plus court chemin de l emplacement des données au serveur choisi Figure 5. Exemple de soumission de problème. domaine. Les domaines gérés par les autres MAs ne sont explorés que si le problème ne peut être résolu dans le domaine courant en respectant les exigences du client Résoudre un problème Nous supposons que l architecture décrite au paragraphe précédent possède plusieurs serveurs capables de résoudre le problème et que chacune des données nécessaires au calcul n est disponible qu en un seul exemplaire dans le système. Dans l exemple présenté dans la figure 5 nous considérons un problème F() utilisant les données A et B. L algorithme présenté ici permet à un MA de choisir un des serveurs qu il gère pour exécuter un calcul. Cette décision est prise en trois étapes : mise en correspondance du problème du client avec les implémentations disponibles dans DIET avec SLiM ; localisation des données impliquées et des serveurs sachant résoudre le problème durant la descente d une requête du MA dans l arbre (voir 4.2.1) ; évaluation des temps de calcul et de communication pour chacun des serveurs grâce à FAST. Elle a lieu lors de la remontée de la réponse au MA (voir 4.2.2) ; choix d un serveur puis envoi de l ordre de migrer les données et d effectuer le calcul. Ceci est fait par le MA (voir 4.2.3). Par souci de simplification, cette section fait référence à un système impliquant un seul MA. Les algorithmes présentés s étendent facilement au cas général en diffusant les requêtes de calcul aux autres MAs et en traitant les autres MAs comme des LAs (voir section 4.4.1).

12 12 CPRSR. Volume X - næx/2000 NomDeProblème Attributs : param 1... param n MonNom Données Calc Localisation TempsVersMoi Nom tcalc tcomm... Localisation TempsVersMoi Nom... tcalc tcomm V1 Vn V1 Vn (a) Struture de requête (b) Structure de réponse Figure 6. Structures de requête et de réponse Localisation des données et des serveurs Structure des requêtes Pour effectuer son choix, le MA doit localiser les serveurs qui sont capables de résoudre le problème soumis et les données impliquées dans le calcul. Cela est fait en envoyant une structure de requête aux serveurs concernés. Cette structure, décrite par la figure 6 (a), contient deux champs : NomDeProblème : le nom du problème ; Attributs : une liste de paramètres, comportant des détails sur leurs tailles et propriétés afin d évaluer les temps de calcul et de communication Algorithme Le MA reçoit une requête de résolution du problème d un client. Il construit la structure de requête. Puis, il envoie cette requête à tous ses fils qui savent localiser soit une donnée nécessaire, soit un serveur capable de résoudre le problème. Les fils transmettent la même requête à leurs fils en suivant le même schéma. À ce stade, nous pouvons distinguer deux cas de figure : le fils est un LA. La requête est transmise à ce fils s il est concerné par la requête, c est-à-dire si on trouve dans sa sous-arborescence un serveur capable de résoudre le problème ou l une des données impliquées dans la requête. le fils est un serveur qui possède une donnée recherchée ou qui sait résoudre le problème. Il répond à la requête comme décrit au paragraphe Lors de la transmission de la requête, chaque Leader Agent étiquette tous ses fils atteints par la requête. Il attend alors une réponse de tous ses fils étiquetés pour répondre en suivant l algorithme présenté à la section

13 Serveurs de Calcul DIET Évaluation des temps de calcul et de communication Structure des réponses Une fois que la requête a atteint les feuilles de l arbre, des réponses sont initiées, et remontent le long des branches en étant agrégées à chaque étape. La figure 6 (b) présente la structure utilisée pour ces réponses. Elle compte trois champs : MonNom : le nom du composant qui envoie la réponse ; Données : le tableau qui décrit chaque donnée impliquée dans le calcul. Chaque entrée contient deux champs : Localisation : le nom du composant possédant la donnée, s il est connu (ce champ a une valeur nulle sinon) ; TempsVersMoi : estimation du temps pour communiquer la donnée depuis le composant envoyant la structure, si cette localisation est connue. Calc : le tableau qui décrit chaque serveur sachant résoudre le problème. Trois informations sont conservées pour chaque serveur : Nom : son nom ; tcalc : le temps nécessaire estimé pour satisfaire à la requête de calcul ; tcomm : un tableau contenant le temps estimé pour communiquer chaque donnée impliquée jusqu au serveur. Cette valeur est calculée dynamiquement lors de la remontée de la réponse Algorithme Lorsqu un serveur de calcul reçoit une requête, il retourne une structure de réponse à son père. Il remplit le champ Données pour les données qu il possède, laissant une valeur nulle pour les autres. Si le serveur peut résoudre le problème, il ajoute également une entrée dans le tableau Calc avec son temps de calcul tcalc évalué par FAST. Chaque LA réunit les réponses de tous ses fils étiquetés et les agrège en une seule structure. Les champs concernant les temps de communication sont remplis au fur et à mesure que les structures remontent vers le Master Agent. Le temps de transfert d une donnée vers un serveur est calculé en appelant FAST, qui combine les informations de la surveillance réseau et les attributs des données. Pour réaliser ce calcul, l hypothèse que l arborescence DIET est représentative de la structure du réseau est utilisée. Cet algorithme d évaluation n est donc utilisé que lorsque les agents se trouvent sur les routeurs d un réseau présentant une topologie en étoile. Nous supposons que la donnée emprunte le chemin le plus court. Ce chemin n utilise que des liens entre père et fils ou entre frères. Cette hypothèse est illustrée par la figure 5. for chaque donnée D do if aucun de mes descendants ne possède D then TempsVersMoi = 0

14 14 CPRSR. Volume X - næx/2000 else if un de mes fils référence D then TempsVersMoi = TempsVersMoi pour ce fils temps pour que ce fils m envoie D else if D n est connu par aucun de mes fils then if Il existe un serveur S dans mon sous-arbre sachant résoudre le problème then D sera envoyée à S en passant par moi si S est choisi. µj augmente le tcomm de D pour tous les serveurs S else D sera envoyée à un serveur S par un chemin où je ne figure pas. µje peux terminer le calcul de tcomm pour mes descendants end if end if end for Suite à la requète, les agents attendent les réponses de leurs fils pendant un certain laps de temps au delà duquel elles sont ignorées. Cet état de fait ne permet pas de tirer des conséquences quant à une panne éventuelle d un agent qui ne répond pas ou pas assez vite. Lorsque les réponses arrivent au MA, celui-ci choisit le serveur sur lequel seront effectués les calculs. Cette décision est prise grâce aux temps fournis dans les structures de réponse Choix d un serveur Exploitation des évaluations Lorsque le MA a réuni les réponses de tous ses fils, il évalue le temps total pour chaque serveur sachant résoudre le problème. Ce temps est la somme du temps de calcul nécessaire à la résolution du problème et du temps de communication des données vers ce serveur. Une évaluation du temps total nécessaire pour réaliser l opération sur chaque serveur retenu est ainsi obtenue. Le MA sélectionne le serveur pouvant satisfaire la requête le plus rapidement possible tout en respectant les contraintes relatives au problème (moyens financiers engagés par le client si certains serveurs sont payants, possibilité pour certains serveurs d être réservés, etc). Dans la version actuelle, ces contraintes ne sont pas prises en compte Problème des requêtes croisées Un élément doit cependant être pris en compte lors de la prise de décision. Lorsque FAST calcule l évaluation du temps de calcul sur un serveur, il ne tient compte que de la charge de ce serveur à cet instant. Dans le cas où un serveur n est pas entièrement dédié à la résolution de problèmes depuis la plateforme DIET, nous ne pouvons garantir un niveau élevé de qualité de service en terme de performance. Dans l hypothèse selon laquelle la plateforme DIET ne dispose que de serveurs abonnés dédiés, si une requête soumise à l instantøreçoit une réponse à l instant Ø Øet conduit au choix d un serveurë, alors toutes les réponses de S à une requête

15 Serveurs de Calcul DIET 15 Prérequis : Le LA a récupéré nbréponses réponses Les réponses sont stockées dans le tableau réponses Le LA a nbserveurs descendants sachant résoudre le problème nbdonnées sont impliquées dans le calcul résultat est la structure de réponse qui est construite transit est un tableau temporaire de nom de composants de tailles nbdonnées card(x) est le nombre d éléments de l ensemble x Étape 1 : construction de résultat.données for i = 1 to nbréponses for j = 1 to nbdonnées if réponses[i].données[j].localisation!= null résultat.données[j].localisation = réponses[i].données[j].localisation résultat.données[j].tempsversmoi = réponses[i].données[j].tempsversmoi transit[j] = réponses[i].monnom endif endfor endfor Étape 2 : construction de résultat.calc for i = 1 to nbréponses for j = 1 to card(réponses[i].calc) for k = 1 to nbdonnées if réponses[i].données[k].localisation == null if résultat.données[k].localisation!= null réponses[i].calc[j].tcomm[k] += résultat.[k].tempsversmoi + temps pour envoyer la donnée k de transit[k] vers réponses[i].monnom) else réponses[i].calc[j].tcomm[k] += temps pour envoyer la donnée k de moi vers réponses[i].monnom endif endif endfor résultat.calc = résultat.calc {réponses[i].calc[j]} endfor endfor Étape 3 : mise à jour de résultat.données for i=1 to nbdonnées résultat.données[i].tempsversmoi += temps pour envoyer la donnée i de transit[j] vers moi endfor Étape 4 : Envoi de la réponse résultat.monnom = moi envoyer résultat au noeud père Figure 7. Algorithme de réponse des LAs. soumise entre les datesøetø Øseront erronées. Dans ce cas de figure, la charge de Ëutilisée pour l évaluation du temps de calcul du deuxième problème soumis ne tient pas compte du premier calcul qui s exécutera surëlors du lancement du deuxième calcul. La figure 8 illustre cet exemple. Pour prendre en compte ce risque, il faut maintenir un journal des requêtes au niveau du MA dans lequel sont consignés la date de soumission du problème résolu par S, le temps Øutile à la recherche et au choix de ce serveur et l estimation du temps de résolution de ce problème. Ainsi, pour toute requête émise entre les datesø

16 Ø Ø Ø Ø 16 CPRSR. Volume X - næx/2000 MA Req Rep Ordre SeD Req Rep Ordre problème 2 problème 1 charge processeur Figure 8. Détection des effets de requêtes croisées. etø Øayant conduit au choix du même serveur S, nous devons prendre en compte la décision de résolution du premier problème par S. Nous proposons alors de remettre en cause le choix de S en ajoutant le temps de résolution du premier problème au temps estimé de la résolution du deuxième problème. On se place ainsi dans le pire des cas selon lequel le serveur S est mono-utilisateur. Dans ce cas, une autre décision est prise, pouvant conduire à choisir malgré tout le serveur S Déplacer des données Exportation des données du client Lorsqu un serveur doit accéder à des données se trouvant sur le client pour résoudre un problème, celles-ci doivent être déplacées. Nous supposons que les données peuvent être modifiées durant le processus de résolution. Une copie d une donnée est donc invalidée dès qu elle est envoyée vers un autre site. Ainsi, une donnée n est possédée que par un serveur à un instant donné. Les données sont communiquées par le plus court chemin possible. En l absence de pare-feu, la communication est directe. Dans le cas contraire, la donnée doit transiter par un ou plusieurs proxies. Dans tous les cas, il est préférable que l architecture DIET reflète l architecture physique du réseau. Les senseurs (processus NWS scrutant les liens réseau) placés sur les nœuds de l arbre DIET doivent correspondre aux routeurs du réseau pour que les prévisions de performances de FAST soient les plus précises possibles. Le non respect de cette règle entraîne une surestimation des temps de communication Déplacements entre les serveurs Lorsqu une donnée doit être déplacée d un serveur vers un autre, la communication est initiée par le serveur ayant besoin de la donnée (sur un ordre du Master Agent qui a localisé la donnée lors de la réponse des serveurs). Là aussi, la communication

17 Serveurs de Calcul DIET 17 est la plus directe possible. L ensemble des agents présents dans l arborescence DIET au dessus des deux serveurs concernés par ce déplacement doivent cependant en être informé. Si cette mise à jour n est pas faite, les agents conservent des informations erronées sur l emplacement de la variable déplacée. Chaque agent du sous-arbre auquel appartient la donnée sait en dessous duquel de ses fils elle se trouve. La mise à jour est envoyée par le serveur demandeur à son père qui référence la donnée et transmet l information vers le haut. Un parcours récursif du sous-arbre est ainsi effectué et permet la mise à jour de l information de localisation sur tous les agents concernés. L ancien possesseur de la donnée conserve une référence sur le nouveau possesseur durant un temps déterminé. Les requêtes traitées durant la mise à jour restent donc valides, même si les évaluations des temps de transfert ne sont pas correctes Extensions possibles Version à plusieurs Master Agents Les algorithmes présentés jusqu à présent n impliquent qu un seul MA. Cela convient pour une application de metacomputing à une échelle moyenne (au sein d un laboratoire par exemple). Pour obtenir une extensibilité maximale, plusieurs MAs doivent être disséminés sur le réseau (comme indiqué dans la figure 1). Dans ce schéma, chaque MA doit gérer un ensemble de serveurs capables de communiquer rapidement entre eux. Cela veut en général dire que ces serveurs sont situés dans un même domaine. Dans le cas de VTHD, nous disposerons un MA dans chaque unité de recherche. Un MA doit de plus être capable de diffuser ses requêtes de calcul aux autres MAs. Cela peut être fait en appliquant le même algorithme et en considérant les autres MAs comme des fils spéciaux (LA). Les MAs devront seulement se soucier de ne pas renvoyer des requêtes aux MAs dont elles proviennent Tolérance aux pannes La tolérance aux pannes est un point crucial pour les environnements de calcul distribué. Dans un système hiérarchique comme DIET, deux types de pannes peuvent avoir lieu : la mort d un serveur risquant d entraîner la perte des données. la mort d un agent ; Nous envisageons, pour éviter les pertes de données et minimiser les pertes de temps lors des pannes de serveurs, l utilisation d un système de points de contrôle. Un point de contrôle correspond à la sauvegarde du contexte (pointeur d instruction courante et données intermédiaires) d un calcul sur un serveur dédié à la sauvegarde. En cas de panne d un serveur, son calcul pourra être repris au dernier point de contrôle par un autre serveur sachant résoudre le même problème. Ce dernier téléchargera les informations du serveur de sauvegarde. La spécification d un serveur de sauvegarde,

18 18 CPRSR. Volume X - næx/2000 ainsi que l évaluation du surcoût de l utilisation de points de contrôle, feront l objet de travaux ultérieurs. Dans le cas de la mort d un agent, la panne est détectée par un de ses fils. Une simple communication CORBA suffit à vérifier qu un objet est toujours vivant (une exception étant envoyée si l objet appelé n est plus actif). Lorsqu une panne du père se produit, le fils détectant la panne effectue les actions suivantes : il tente de se connecter à une nouvelle instance de son père si elle existe, en employant le service de nommage CORBA ; en cas d échec, il contacte le premier agent opérationnel se trouvant au dessus de lui dans l arbre (chaque agent ou serveur de DIET possède la liste de ses pères). Il demande à celui-ci de relancer récursivement la partie manquante de la hiérarchie. Deux cas sont possibles : les éléments manquants de la hiérarchie sont relancées, et le ou les agents/serveurs ayant détecté la panne peuvent se reconnecter à leur père comme précisé précédemment ; certains agents ne peuvent être relancés. Les fils de ces agents sont informés qu ils doivent temporairement se connecter à leur plus proche ascendant en état de marche de la hiérarchie DIET. Le père d un agent en panne tente régulièrement de le relancer afin de reconstuire l architecture originale. De cette façon, l intégrité de la structure de l architecture DIET est garantie Supervision d une architecture de type NES La gestion et la supervision apparaissent comme des points cruciaux au sein de l architecture DIET. Il est primordial de pouvoir fournir un cadre unificateur pour la gestion des réseaux des services et des applications déployées. Ce cadre de supervision doit se traduire par la définition d une architecture assurant une interopérabilité entre applications au travers de la portabilité des informations de gestion indépendamment de leur origine. Cette plate-forme de supervision doit aussi être en mesure de faire remonter des informations utiles vers les autres composants de l architecture NES. En effet, des informations comme la vitesse des liens, sur la disponibilité des équipements doivent être prises en compte par DIET lors du choix qu il effectue avant de répondre à une requête d un client. Le but est de regrouper au sein d un même modèle d information la totalité des informations utiles et nécessaires à l ordonnanceur. Nous aurons donc besoin à la fois d instrumenter les outils permettant de récupérer ces informations mais aussi de regrouper et d agréer ces informations à un même endroit et dans un modèle formel facilement extensible et utilisable quels que soient les systèmes ou les applications requérant ces informations. Comme nous l avons vu dans la section 2.2, notre approche consiste à développer nos propres outils de localisation des ressources et de monitoring de l architecture. On envisage, cependant, d évaluer une autre approche basée sur les technologies Java et plus spécifiquement sur JMX (Java Management Extensions) [MIC 99] offre l opportunité de déployer une architecture de type NES dans un environnement de type

19 Serveurs de Calcul DIET 19 metacomputing. Cette approche est basée sur WEBM (Web-Based enterprise Management) dont l effort de normalisation a été pris en charge par la «Distributed Managment Task Force» (DMTF) qui doit prendre en compte les points suivants : La création d une vue homogène de l ensemble des ressources gérées et ce quelles que soient leur nature, localisation et/ou méthode d accès ; La préservation de l existant via une intégration des modèles de l information, architecture de gestion et protocoles déployés ; La constitution d un support d échange d information de gestion entre applications. Les quatre composants de base en gestion de réseau qui ont été proposés et que nous devons mettre en œuvre sont : Une architecture fonctionnelle définissant les intervenants dans la gestion, leur répartition, les fonctions qu ils assurent et leurs rôles respectifs (modèle organisationnel) ; Une approche de modélisation et un formalisme pour la spécification de nouveaux modèles de l information (modèle informationnel); Un modèle de l information unificateur comportant un ensemble d objets gérés de base définissant un modèle générique (modèle fonctionnel) ; Un service et un protocole assurant la communication entre les entités (modèle de communication). Le modèle de l information proposé par WEBM est le modèle CIM (Common Information Model). Nous devons donc définir un modèle de l information basé sur un modèle CIM approprié à la gestion de réseau et orienté plate-forme NES. Bien plus qu une simple collection de ressources modélisées et approuvées par un ensemble de partenaires, CIM a pour objectif de permettre la spécification et la mise à disposition des applications d une description unifiée et extensible des ressources gérées. Cette modélisation est indépendante des approches existantes. Dans l architecture que nous proposons, nous nous attacherons principalement aux objets modélisant un réseau informatique (CIMNetwork) ainsi qu à l extension du modèle pour intégrer les informations relatives à des composants comme NWS et prendre en compte les spécificités d une application distribuée. CIM se place comme le point d accès central d une plate-forme de metacomputing car il est capable de gérer à la fois l infrastructure de monitoring mais aussi de faire remonter les informations qu elle collecte. Du côté des applications distribuées requérant ces informations, CIM/WEBM est capable de leur fournir ces données mais aussi de les gérer en retour et de faire redescendre des commandes vers les outils d instrumentation. Enfin, CIM laisse l entière responsabilité de la modélisation du méta-modèle à l utilisateur. Cette souplesse s accompagne nécessairement d un effort supplémentaire afin de ne pas briser la philosophie du schéma. La mise en œuvre des composants de supervision doit pouvoir être réalisable à l aide de la technologie JMX (Java Management extension) qui suit deux objectifs complémentaires : la gestion d applications Java et la gestion en Java d équipements, réseaux et services qui n intègrent pas forcément la technologie Java. JMX apparaît donc comme l outil de proximité de l instrumentation. Son fonctionnement sous Java

20 20 CPRSR. Volume X - næx/2000 lui permet de travailler sur diverses plate-formes (J2ME, J2EE). L utilisation de Java permet à ce stade de bénéficier d une relative indépendance par rapport à la plateforme et d un interfaçage aisé avec d autres langages, au travers d un bus CORBA par exemple [BEA 00]. À partir de briques de base d une architecture de supervision d application distribuée (tentative de modélisation de CIM) nous allons mettre en œuvre une architecture ouverte et globale de collecte et d organisation des données. JMX et CIM utilisent un système d objets proches ce qui nous permet de faire remonter des informations simplement d un MBean (Managed Bean) de JMX vers un CIMON. Les MBeans sont une extension naturelle des Beans Java de base pour le management réseau. Cela permet de connnecter des extensions à un serveur d applications sans avoir connaissance des détails de l implémentation de celui-ci, autrement dit on écrit des MBeans qui peuvent être utilisés sur tout serveur MBean compliant. Nous utilisons pour ce faire le langage de spécification de CIM : MOF (Meta Object Facility). Nous sommes alors en mesure de définir de façon formelle et unique les données collectées par JMX et agréées dans CIM. Notre but est de créer un modèle JMX simplifié de l architecture CIM en rendant nos MBean «CIM-compliant» et donc exportables dans un CIMON (CIM Object Manager qui est sous la forme d un conteneur d objets CIM). Notre système de supervision possède les caractéristiques suivantes : Extensibilité : puisque JMX est basé sur les JavaBeans, tout agent JMX peut dynamiquement incorporer de nouvelles fonctionnalités depuis un serveur distant de classes java ; Interopérabilité : les agents JMX peuvent être intégrés en CIM/WBEM et en CORBA ; Réutilisabilité : il est possible d intégrer des fonctionnalités externes disponibles en les développant en tant que JavaBean ; Indépendance du type de plate-forme : JMX peut être déployé dans un environnement hétérogène où plusieurs plates-formes coexistent. 5. Conclusion et travaux futurs Dans cet article, nous avons présenté notre vision d un système extensible basé sur des serveurs de calcul distribués sur le réseau. Nous pensons qu une telle hiérarchie est obligatoire pour la construction de tels environnements pour la Grille et que l extensibilité doit être l un des principaux soucis des développeurs. Nous proposons une approche hiérarchique des serveurs de calcul qui utilise des logiciels existants tels que CORBA, NWS ou JMX. Nos travaux futurs consistent tout d abord de tester cette approche sur de vraies applications. Puisque notre plate-forme cible permet des communications à 2,5 Gb/s entre les différentes unités de recherche de l INRIA grâce à VTHD et connecte plusieurs grappes de PCs et machines parallèles, nous pensons que des applications, même fortement couplées, pourraient bénéficier d une telle approche. Nous souhaiterions également connecter nos développements à des infrastructures telles que Globus

21 Serveurs de Calcul DIET 21 pour bénéficier de leurs développements concernant la sécurité, la facturation et l interopérabilité. Notre premier prototype est essentiellement basé sur des optimisations du logiciel NetSolve mais nous souhaitons par la suite développer un environnement basé sur CORBA et Java (et les outils qui leur sont associés). 6. Remerciements Nous remercions les relecteurs pour leurs commentaires qui ont permis d améliorer ce chapitre sur plusieurs points. Ces travaux sont supportés en partie par les projets RNRT VTHD et VTHD++, le projet RNTL GASP et l ACI GRID ASP. 7. References [AND 99] ANDERSON E., BAI Z., BISCHOF C., BLACKFORD S., DEMMEL J., DONGARRA J., CROZ J. D., GREENBAUM A., HAMMARLING S., MCKENNEY A., SORENSEN D., LAPACK Users Guide, Third Edition, SIAM, Philadelphia, PA, 1999, ISBN [ANT 98] ANTHOINE J.-L., CHATONNAY P., LAIYMANI D., NICOD J.-M., PHILIPPE L., Parallel Numerical Computing Using Corba, ARABNIA H. R., Ed., Parallel and Distributed Processing Techniques and Applications (PDPTA 98), vol. III, CSREA Press, july 1998, p [ARB 97] ARBENZ P., GANDER W., MORI J., The Remote Computational System, Parallel Computing, vol. 23, num. 10, 1997, p [BAL 98] BALAY S., GROPP W. D., MCINNES L. C., SMITH B. F., PETSc home page, http :// [BEA 00] BEAZLEY B., IIOP Protocol Adapter for JMX Specification, report num. jsr-70, 2000, Java Specification Requests, [BOI 94] BOISVERT R., The Architecture of an Intelligent Virtual Mathematical Software Repository, Mathematics and Computers in Simulation, vol. 36, 1994, p [BRO 99] BROWNE S., MCMAHAN P., WELLS S., Repository In a Box Toolkit for Software and Resource Sharing, report num. UT-CS , 1999, University of Tennessee Computer Science Dept. [CAR 01] CARON E., CHAUMETTE S., CONTASSOT-VIVIER S., DESPREZ F., FLEURY E., GOMEZ C., GOURSAT M., JEANNOT E., LAZURE D., LOMBARD F., NICOD J.-M., PHI- LIPPE L., QUINSON M., RAMET P., ROMAN J., RUBI F., STEER S., SUTER F., UTARD G., Scilab to Scilab//, the OURAGAN Project, Parallel Computing, vol. 11, num. 27, 2001, p [DES 01] DESPREZ F., QUINSON M., SUTER F., Dynamic Performance Forecasting for Network Enabled Servers in a Metacomputing Environment, Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA 2001), 2001.