Contribution à l allocation dynamique de ressources pour les composants expressifs dans les systèmes répartis

Transcription

1 Numéro d ordre : 988 THÈSE présentée à L U.F.R DES SCIENCES ET TECHNIQUES DE L UNIVERSITÉ DE FRANCHE-COMTÉ pour obtenir le GRADE DE DOCTEUR DE L UNIVERSITÉ DE FRANCHE-COMTÉ Spécialité Automatique et Informatique Contribution à l allocation dynamique de ressources pour les composants expressifs dans les systèmes répartis par Vincent PORTIGLIATTI Soutenue le 2 décembre 2003 devant la Commission d Examen : Guy Bernard Professeur, Institut National des Télécommunications Rapporteur Daniel Hagimont HDR Chargé de recherche, INRIA Rhône-Alpes Rapporteur Laurent Philippe Professeur, LIFC Université de Franche-Comté Directeur Hervé Guyennet Professeur, LIFC Université de Franche-Comté Examinateur Emmanuel Cecchet Chargé de recherches, INRIA Rhône-Alpes Examinateur

2 2

3 Remerciements Le travail que j ai réalisé au cours de ma thèse n aurait certainement pas été possible sans la bienveillance et l aide de nombreuses personnes. Je tiens à les en remercier de tout cœur. Je remercie l ensemble des membres du jury, à savoir : M. Guyennet Hervé, Professeur à l Université de Franche-Comté au LIFC. M. Philippe Laurent, Professeur à l Université de Franche-Comté au LIFC. M. Guy Bernard, Professeur à l Institut National des Télécommunications d Evry M. Daniel Hagimont, HDR Chargé de recherche à l INRIA Rhône-Alpes M. Emmanuel Cecchet, Chargé de recherches à l INRIA Rhône-Alpes Je remercie Guy Bernard, Daniel Hagimont et Emmnuel Cecchet pour avoir accepté d être mes rapporteurs, pour les bons conseils et les remarques pertinentes qu ils ont émis sur mon travail. Je remercie Hervé Guyennet pour avoir présidé le jury de cette thèse. Je remercie chaleureusement Laurent Philippe, mon directeur de thèse pour le soutien, la bonne humeur, le jazz, la musique tzigane et la goutte, ainsi que les conseils avisés qu il m a prodigué lors de cette grande épopée. J espère ne pas l avoir déçu. Je remercie Bénédicte Herrmann et Sylvie Damy et pour leur gentillesse et leur bienveillance lors de ces longues années. Je fais de même pour Isabelle Jacques et Christine Chevallier, pour nos discussions intimes. ;-) Je remercie toutes les autres personnes qui ont participé de loin ou de près à cette grande aventure comme JM Nicod, Michel Lacroix et tous les autres membres de l équipe Trader. Sans oublier Frédéric Lombard, Célina Charlet, JC Voisinet, Bruno DelFabbro (encore plus vieux que moi, c est pas peu dire!!) mes compagnons de galères (parler de RAM pour un informaticien c est normal!). Je remercie l ensemble des membres du LIFC au sein duquel j ai effectué cette thèse et où je me sent comme chez moi! ;) Je remercie l ensemble des personnes de la SMER avec lesquelles j ai eu des moments inoubliables (Merci Benoit, ou bien? sinon?) Je remercie tous mes amis externes, mes compagnons de comptoir aux heures de détentes : Mister-Noug et Marycoton, Chinchin, Amal, Bip-Bip, Phil W., Jer mon colloc, Steph, Maud et Lozza, Maud et Tchonguy, Glou, Freddys, Fanny, Céline, Emilie, Pan, Le gibus, Kors, Elise, Angéline, Caroline (ma copine...la la la) et je vais arrêter là car ils sont trop nombreux et j ai la mémoire qui flanche, j me souviens plus très bien (vous connaissez la chanson (Resnay style TM)). Je remercie tout spécialement M. Berthet et Mme Georgeon pour avoir mis tous leurs espoirs en moi et m avoir pousser à aller là ou je suis maintenant. ;-) 3

4 4 J espère que ceux que j ai oubliés dans cette immense liste voudront bien pardonner cet oubli. Par conséquent, je remercie également tout ceux que je n ai pas cités et que j ai oublié volontairement! ;-) Finalement, je remercie l ensemble de ma famille, mes proches pour leur amour, leurs confiances, leurs constances et leurs aides, aux heures où, seul, je n y serais pas parvenu. Je dédie cette thèse à ceux que j aime et qui m ont fait l honneur de croire en moi.

5 Table des matières Introduction 15 1 Contexte et problématique Le contexte matériel Les réseaux locaux et d interconnexions L hétérogénéité dans les réseaux Le modèle matériel Le contexte système Le modèle de référence RM-ODP La norme CORBA La norme RM-ODP et la norme CORBA DCOM Java RMI Synthèse Le modèle système Le contexte applicatif Les évolutions de l applicatif Le modèle applicatif Problématique La gestion des ressources L expression des besoins Les contraintes et les préférences La prise de décision Conclusion Les composants Introduction aux composants Les composants Les interfaces et les services Les spécifications et les contrats Les connecteurs Les différentes catégories de composants Les langages de description d architecture Les concepts des ADL Les principaux ADL Le langage de coordination

6 6 TABLE DES MATIÈRES Les principaux types de langage de coordination Les standards Le modèle de composant d UML Les Enterprise Java Beans Le Corba Component Model Microsoft.NET Conclusion La gestion de ressources dans les systèmes répartis Les propriétés de la gestion de ressources Les algorithmes et leurs principes Les composantes de l équilibrage de charge Les politiques de gestion de charge La politique d information La distribution des informations La politique de localisation L administration L administration d infrastructure L administration d exécution La mobilité des objets Le placement La migration La duplication Des exemples de systèmes de gestion de ressources ANTS Load Balancing System CATScan FarGo YALB (Yet Another Loadbalancing System) Condor flock Utopia multi clusters Bellerophon Computational Field Model (CFM) Conclusion La modélisation par graphes Les graphes appliqués aux systèmes distribués Pourquoi optimiser? Préambule sur les graphes Définition et notations Définitions de base Partitionnements de graphes La modélisation du problème La caractérisation du modèle Caractérisation Définition d une application ou logiciel Définition du matériel ou hardware Le graphe d application

7 TABLE DES MATIÈRES Le graphe matériel La recherche d une fonction de coût Le but de la fonction de coût Conclusion partielle Les propriétés des fonctions de coût Les différentes consommations La consommation mémoire La consommation d entrée/sortie La consommation de contraintes La consommation de préférences La consommation réseau La consommation processeur Activité réseau, processeur et besoins applicatifs Optimisation des différentes activités Les autres solutions Discussion sur un algorithme L algorithme L algorithme de placement Les hypothèses Les principes Les résultats Conclusion La prise de décision Préambule sur l aide multicritère La formulation multicritère d un problème de décision Les méthodes multicritères Les critères et leur propriétés L expression d un critère Les différents types de critères L agrégation multicritère Les différentes procédures multicritères La procédure sommative La procédure multiplicative La procédure lexicographique L analyse de la concordance L analyse de la discordance Résumé Exemples de méthodes La méthode ELECTRE I La méthode ELECTRE II La méthode ELECTRE III La méthode ELECTRE IV Les files d attente La prise de décision Le placement statique L évaluation d algorithmes

8 8 TABLE DES MATIÈRES Résumé La décision logique Le problème de décision Quelques critères classiques pour la décision Conclusion Un gestionnaire de placement à composants expressifs Un modèle d administration Les bases fondamentales La réflexion au niveau des applications Une allocation automatique de ressources Les ressources et leurs optimisations Les ressources d un réseau local L optimisation d un réseau local Les objectifs Le cadre de l étude Les limitations L ensemble des informations Le service de placement GO Le modèle du placement du GO Les traitements des gestionnaires Les différentes stratégies de placement L implémentation du placement La procédure de décision logique Résumé Le gestionnaire ORM Les interfaces du module ORM La définition des propriétés Le langage de contraintes Le calcul des contraintes Le calcul des préférences L agrégation des critères Conclusion Les tests La plateforme de tests Le simulateur d applications Un exemple de paramétrage d une application Le serveur Le client Le client/serveur Les paramètres des applications Les différents tests de performances Les tests sans prise en compte des besoins applicatifs Le test 1 serveur et 2 clients Le test 2 serveurs et 2 clients Le test 2 serveurs, 1 client/serveur et 8 clients

9 TABLE DES MATIÈRES Synthèse Les tests avec prise en compte des besoins applicatifs Le test 2 serveurs et 2 clients Le test 4 serveurs et 4 clients Le test 7 serveurs 3 clients/serveurs et 10 clients Synthèse L analyse des paramètres pour l optimisation Conclusion Conclusion et perspectives Conclusion Perspectives Les contrats de composants L utilisation du langage XML Le service de courtage A Définition XML : MACHINE 153 B Définition XML : COMPONENT 157

10 10 TABLE DES MATIÈRES

11 Table des figures 1.1 L architecture CORBA OMA Exemple de partitionnement d un graphe complet Les trois types d arêtes Exemple de partitionnement du graphe applicatif Exemple de plongement du graphe applicatif sur le graphe matériel Découpage du graphe en fonction de la densité de communication Découpage du graphe en fonction de la charge Architecture du GO-Domain Architecture du GO-Site Architecture des différents services Coût du système GO par rapport au nombre d objets La mobilité du serveur pour optimiser les communications Les résultats de l ancien test 1s2c de HY Chan La mobilité des serveurs pour optimiser les communications La mobilité des serveurs en fonction de la charge et des communications Configuration du test 2 serveurs et 2 clients : placement initial Configuration du test 2 serveurs et 2 clients après déplacements Mobilité en fonction de la charge, des communications et des contraintes Mobilité en fonction de la charge, des communications et des préférences Mobilité en fonction de la charge, des communications et des besoins applicatifs

12 12 TABLE DES FIGURES

13 Liste des tableaux 6.1 Opérateurs et évaluations associées des contraintes Caractéristiques des machines de test Le plan d expériences

14 14 LISTE DES TABLEAUX

15 Introduction Il est incontestable que l outil informatique est devenu depuis une vingtaine d années, un élément essentiel de la vie et du travail de millions de personnes, qu ils soient programmeurs, administrateurs ou simples utilisateurs. L informatique, réservée autrefois aux initiés, s est banalisée par sa présence indispensable dans de nombreux domaines ainsi que par les différentes avancées technologiques. Ces avancées ont permis l émergence de réseaux permettant de connecter les systèmes informatiques entre eux. Le but avoué est de partager des ressources autant matérielles que logicielles et de répondre aux besoins des différents intervenants. Les systèmes informatiques répartis et distribués sont nés de ce concept. Ils ont permis aux différentes informations et aux diverses ressources de se soustraire au modèle centralisé par la distribution et la répartition sur un ensemble plus ou moins important d ordinateurs inter-connectés non forcément homogènes. Cependant, le partage simple des ressources et des informations n est plus une approche, ni une réponse suffisante pour utiliser et gèrer les applications de plus en plus complexes et dynamiques. De plus, le logiciel est soumis à des contraintes fortes telles que la réduction des coûts de développement et de maintenance des applications ainsi qu à la perpétuelle course à l ergonomie et à l adaptabilité. Nombreuses sont les réponses qui sont apportées à ce problème. La plus récente, et la plus communément admise, est l approche par composants issue directement de la technologie objet. Véritables briques logicielles, les composants permettent de concevoir et de construire par assemblage des applications. L un des intérêts de cette technologie est de permettre aux applications de tirer aisément partie d un environnement matériel intrinsèquement distribué puisque basé sur l Internet. Il s agit alors, pour construire une application, de développer et d assembler des composants dont les interactions avec les autres composants sont réalisées par des invocations permettant de proposer différents services. L exécution peut se faire facilement dans un environnement distribué en utilisant des supports d exécution qui offrent une transparence des invocations distantes. Dans ce cadre, l administration de l exécution et le déploiement de composants devient une phase critique de l exécution. Il est nécessaire, pour obtenir de bonnes performances, de savoir gérer de façon dynamique le placement de chacun des composants en tenant compte de leurs besoins propres. Ces besoins peuvent être de natures diverses et variées comme par exemple les propriétés matérielles ou des ressources logicielles nécessaires à l exécution correcte du composant. La thèse que nous défendons est que le déploiement des composants ainsi que la gestion de ressources doit utiliser des informations dynamiques traduisant l état de l environnement ainsi que celui des desideratas des composants applicatifs. Pour réaliser le déploiement, ces informations nécessitent un traitement dynamique lors de la prise de décision. Cette dernière doit être également dynamique, ce qui implique l émergence de nouveaux problèmes lors de la création et de l exécution d une décision de déploiement et/ou de placement en regard de notre contexte d allocation de ressources. Par conséquent, notre objectif est de permettre une 15

16 16 Introduction gestion dynamique pour optimiser et rationnaliser, d une part, les performances d exécution des composants et, d autre part, les ressources des systèmes dans lesquels cette exécution a lieu par l utilisation de décisions sur le placement de ces composants. L intérêt de la gestion dynamique du placement pour les composants vient du couplage fort entre l application et le système : il est possible d obtenir, au plan du système, des informations sur la structure de l application et ses composants par l utilisation, par exemple, de fichiers de configuration. Nous travaillons dans un contexte distribué, ce qui nous permet, entres autres, de nous appuyer sur des techniques existantes de gestion de charge des machines ainsi que sur les interactions de communications entre composants pour asseoir notre étude. Nous utilisons plusieurs techniques de mobilité. Ces techniques sont : le placement et la migration. Ces différentes méthodes nous permettent de distribuer la charge des machines, d optimiser les performances des applications au point de vue communication et, par conséquent, d obtenir une exécution plus efficace. Par exemple, la mobilité inhérente aux composants peut être utilisée pour les placer au plus près des ressources qu ils utilisent, sur les sites les plus disponibles ou bien sur ceux désirés en accord avec leurs besoins. En plaçant les composants au plus près de ce qu ils utilisent, il est possible de réduire les temps d accès et l utilisation des ressources. De la même manière, en plaçant les composants sur les sites dont les ressources sont les plus disponibles, l utilisation des ressources est mieux répartie. Cependant, nous pensons qu il est très difficile de proposer une solution générale qui répondrait aux problèmes de l ensemble des composants et constructions possibles d applications. Cette grande difficulté est imposée par l incertitude du comportement des applications. Cette incertitude a une forte incidence sur les paramètres à prendre en compte lors des décisions du placement des applications et/ou des composants. Nous affirmons que l expression des besoins par l application peut lever certaines de ces incertitudes car il est possible d obtenir une plus grande connaissance sur cette application et son comportement. Ceci va également dans le sens des descripteurs de déploiement des composants qui autorisent la modification du comportement des composants sans recompilation. De ce constat, nous devons donc choisir une approche similaire qui favorise l évolution des besoins applicatifs et de leurs paramètres, mais aussi l ensemble des autres habituellement utilisés (charge, communication, etc). Cela nous permettra de nous rapprocher d une solution générale pour répondre à notre problématique. Par conséquent, il est nécessaire d observer en permanence le système et ses performances d exécution afin de détecter tout changement pour pouvoir, le cas échéant, satisfaire de nouveaux besoins et/ou ré-équilibrer le système en fonction des débits de communications et de la charge des machines. D autre part, pour mesurer la qualité d un déploiement, il est important d étalir une évaluation des gains obtenus. Ces évaluations seront la validation de notre modèle qui comprend un système gérant les besoins applicatifs et permet une administration automatique par rapport à l environnement matériel, système et logiciel. Le plan de la Thèse Nous présentons, dans le chapitre 1, un modèle de gestion et d allocation de ressources expressive au sein d un système réparti à composants et nous introduisons le contexte de notre étude. Nous décrivons le support fourni par le système matériel, le contexte système ainsi que le contexte applicatif. Nous en déduisons notre problématique et posons nos premières hypothèses de travail.

17 Introduction 17 Le chapitre 2 présente l état de l art au niveau des composants. Nous présentons différents concepts utilisés pour concevoir, déployer et administrer les composants. Nous présentons également les différents standards que sont UML 2, les Enterprise Java Beans, le Corba Component Model et.net. Le chapitre 3 expose l état de l art des recherches dans le domaine de l allocation de ressource dans les systèmes répartis. Nous décrivons quelques travaux réalisés pour les systèmes répartis «traditionnels» et ceux traitant des systèmes répartis à objets et à composants. Le chapitre 4 est dédié à la modélisation de notre problématique par l utilisation de la théorie des graphes. Nous spécifions notre problématique et particulièrement le partitionnement et le placement par rapport aux différentes informations que nous utilisons comme la charge, le débit, les besoins applicatifs et les propriétés matérielles. Nous recherchons également une fonction de coût. Nous présentons ensuite un algorithme pour le placement des composants dans notre système. Dans le chapitre 5 nous présentons une partie des bases de notre étude. Nous définissons et décrivons certains concepts théoriques servant de base à notre travail. Nous introduisons les notions de décisions, d agrégations multicritères, de files d attentes ainsi que certains modes de décisions logiques. Le chapitre 6 explicite la mise en œuvre de notre modèle répondant à notre problématique. Nous présentons plus particulièrement le placement au sein d un système de placement à objets expressifs, prenant en compte les besoins applicatifs. Nous présentons notre solution en détaillant l architecture et les différents mécanismes utilisés et précisons la portée et les limites de ce système. Nous présentons dans le chapitre 7, les résultats les plus significatifs que nous avons obtenus grâce à l implantation de notre système. Nous validons notre système par la réalisation de plans d expériences pour analyser les performances des différents tests effectués. Nous prenons en compte les différents paramètres de notre problématique ainsi que d autres variables essentielles à notre modèle et nous exposons les résultats obtenus. Enfin, dans le chapitre 8, nous concluons cette thèse en rappelant nos objectifs, nos principaux résultats ainsi que les perspectives de recherches et d améliorations futures de notre système.

18 18 Introduction

19 Chapitre 1 Contexte et problématique Les notions de Composant, Internet, Intranet, Corba, Java et Web sont aujourd hui banalisées. Ces notions autorisent et participent à la création ainsi qu à l exécution d applications au sein d environnements distribués sur des réseaux à plus ou moins grande échelle. Les applications sont devenues encore plus dynamiques et plus mobiles par l utilisation du concept de composant. La notion de composant, intrinsèquement distribué est également lié fortement à la notion d applications et de ressources matérielles grâce à l Internet. L évolution des applications et, dans une moindre mesure, celle des ressources matérielles par mise-à-jour, ajout, modification et suppression peut entraîner des variations de comportements plus ou moins significatives. Cette dynamicité plus ou moins grande nécessite une prise en charge adéquate par une gestion et une administration efficace. Se pose alors le problème de l optimisation de l utilisation des ressources et des applications, ainsi que la gestion de leurs accès. Notre travail s inscrit sur cet axe. Les ressources dont nous désirons optimiser, gèrer l exécution ainsi que l accès peuvent être divisés et séparés en trois notions. Nous introduisons la notion de contexte matériel qui correspond aux ressources physiques puis celle du contexte système qui correspond aux différents modèles et supports logiciels possibles et enfin celle de contexte applicatifs qui correspond aux types d applications que nous désirons prendre en compte. Dans notre cas, ces applications sont d une granularité fine ou moyenne, c est à dire qu elles sont dynamiques et n ont pas une durée de vie trop longue. Nous développons dans ce chapitre ces différentes notions pour en extraire leurs problématiques et ainsi expliciter et mieux cerner notre propre problématique de travail. 1.1 Le contexte matériel Le contexte matériel est la base des applications. Il représente les ressources matérielles sur lesquelles elles s exécutent. Ces ressources sont de natures diverses. Par exemple, une ressource matérielle peut être un processeur, une mémoire, une unité de stockage, une connexion réseau, etc. Si l on se place dans le contexte des systèmes distribués, le réseau est habituellement l un des critères majeurs qui caractérise le contexte matériel car il permet de communiquer, d échanger et de transférer des données et/ou des applications. Ceci est d autant plus vrai que certains concepts, comme les composants, mettent la notion de réseau au centre de leur fonctionnement et de leur déploiement. Ces réseaux peuvent être soit locaux, soit d interconnexion. Nous détaillons ci-après ces deux concepts. 19

20 20 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE Les réseaux locaux et d interconnexions Les réseaux locaux sont constitués de machines reliées entre elles. Les liaisons ou connexions peuvent prendre différentes formes (Ethernet, b, Firewire, USB, etc). Les différentes solutions existantes offrent généralement des services d adressage direct entre les machines, limitant ainsi l incidence de la topologie (bus, anneau, bus logique, etc) sur les propriétés intrinsèques. On considère les réseaux locaux comme des réseaux privés, bien qu avec l Internet cette notion soit un peu faussée et restrictive, ainsi au plan de la sécurité car l augmentation de leur taille induit un travail colossal pour l administration et la surveillance du parc de machines. L interconnexion des réseaux locaux permet d étendre l offre de services disponibles en autorisant les invocations clientes de trouver un service sur d autres réseaux distants lorsque celui-ci n est pas disponible localement. Plusieurs différences existent entre les réseaux locaux et les réseaux d interconnexions. Nous pouvons citer, par exemple, le coût des communications, une hétérogénéité fortement probable ainsi qu une sécurité inférieure ou non existante. La sécurité est un problème vaste [Des90] qui peut être résolu de différentes manières. Il est possible de crypter les informations en utilisant diverses méthodes comme par exemple Kerberos [NAM97] pour les utilisateurs et DCE [OSF97] pour les invocations à distantes ou celles utilisées par le langage JAVA pour les applets. Ces problèmes de sécurité peuvent jouer un rôle important lors de la répartition de charge, ne serait-ce que, par exemple, pour les droits d accès à certaines ressources matérielles sensibles. La notion de réseau est définie comme un critère qui étend et s appuie sur les concepts de groupe et de domaine issus de la norme RM-ODP (Reference Model Open Distributed Processing). Dans cette norme, un réseau est un point d attache où les différents clients et/ou machines se connectent, permettant ainsi d invoquer des serveurs et d échanger des informations localement ou à distance. Un service ou une information peut être utilisée si, et seulement si, le client ou la machine est rattachée au domaine adéquat. La norme différencie la notion de domaine de celle de groupe qui sont parfois confondues. Un groupe < X > correspond à un ensemble d objets avec une relation de caractérisation particulière < X >. La relation < X > caractérise soit la relation structurelle entre les objets, soit un comportement commun et attendu des objets. La notion de groupe peut s appliquer à tout type de ressources : processeur [ZWZD93, EB94], périphériques, fichiers, processus, etc. Un message pourra alors être envoyé au groupe sans connaître l adresse des membres (Amoeba [KTV93], Isis [Bir93], PVM [GBa94], MPI [Gro94]). Un groupe peut également être défini dans les applications coopératives [GL99] ou toutes autres formes dans lesquelles la notion de groupe est présente. Un domaine < X > est un ensemble d objets, chacun de ces objets étant relié à un objet contrôleur par une relation caractéristique < X >. Il existe un objet contrôleur associé à chaque domaine. Un domaine peut être un ensemble de machines reliées par un réseau local. La notion de domaine est également présente dans la norme CORBA [Sie96, HC97]. D après cette norme, un domaine est une partie indépendante où les composants possèdent des caractéristiques communes et respectent des règles communes. Ces définitions peuvent distinguer, même si elles sont souvent confondues, certaines ressources comme les réseaux qui interconnectent des types de machines disposant de ressources homogènes et/ou hétérogènes. Le fort couplage entre les composants d une application distribuée induit une hétérogénéité plus importante.

21 1.1. LE CONTEXTE MATÉRIEL L hétérogénéité dans les réseaux L hétérogénéité est très présente dans les réseaux WAN, mais peut également exister dans les réseaux locaux. Habituellement, les choix d évolution des réseaux locaux se font souvent en faveur du maintien d une homogénéité des ressources. Ceci pour simplifier les problèmes de mise en œuvre et permettre des échanges d informations, sans codage particulier, ou même des déplacements de codes exécutables parfois sans recompilation. Cette situation tend à changer. De plus en plus, des machines et des systèmes différents sont interconnectés au sein du réseau local. Cette diversification permet d apporter plus de souplesse dans le choix des systèmes, des machines et des applications. Dans ce contexte, le langage JAVA de Sun est une bonne solution car il s affranchit des problèmes liés à l hétérogénéité par l utilisation de machines virtuelles propres à chaque type de processeur, permettant de cette façon de créer, d exécuter et de placer des applications génériques fonctionnant sur tous les systèmes disposant d une JVM. L hétérogénéité peut alors prendre une place plus importante au sein d un réseau local, tout en minimisant les problèmes liés aux spécificités de chaque machine. Néanmoins, si l on n utilise pas le langage JAVA, l hétérogénéité matérielle et logicielle peut amener des contraintes fortes sur l exécution et le placement, car les ressources et les besoins applicatifs (processeurs et vitesses processeurs, tailles mémoires, système d exploitation, périphériques, sécurité, etc) peuvent être très différentes et non forcément compatibles pour certaines applications. De plus, les services ou logiciels disponibles sur une machine ne sont pas forcément disponibles sur l ensemble des autres machines et les ressources offertes par une machine ne sont pas nécessairement omniprésentes car elles peuvent évoluer dans le temps et l espace. De ce constat, l hétérogénéité peut induire le problème suivant : un code exécutable sur un type précis de processeur n est pas forcément compatible sur un autre type de processeur car les données ne sont pas codées de la même manière sur l ensemble des machines. L échange de données entre deux machines hétérogènes doit supposer qu un codage existe et soit reconnu par l ensemble des entités communicantes (normes ASN.1, XDR, etc). De plus, un programme ne peut être exécuté que sur des classes de machines dont les processeurs sont compatibles, limitant ainsi les possibilités de déplacement de code aux machines de même classe. Ces problèmes, parfois minimes, peuvent entraîner des contraintes sur le placement des applications, en particulier pour celles attachées à des ressources spécifiques. Si le partage de ressources est courant dans les réseaux locaux, il doit être modulé par l hétérogénéité possible induite par ces connexions, ainsi que les différentes configurations et systèmes qui y sont ajoutés ou modifiés. Il est alors important d intégrer et de prendre en compte l expression des besoins applicatifs Le modèle matériel Le modèle matériel que nous décrivons est un ensemble ou groupe de ressources, comme le conçoit la norme RM-ODP, qui représente la plateforme d exécution des applications. Ces ressources sont de types divers (réseau, processeur, mémoire, etc). Elles permettent de caractériser une ou plusieurs machines d un domaine qu il soit local ou WAN. Ces caractéristiques peuvent nous aider à mieux comprendre, par une définition plus précise, les différentes possibilités offertes pour l exécution des applications qui est intimement liée aux ressources matérielles. Cette connaissance nous permet d affiner le placement des applications sur les ressources matérielles. De surcroît, ces informations autorisent à prendre en compte l hétérogénéité pos-

22 22 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE sible au sein de l environnement d exécution et induire une notion de qualité de service plus conséquente. La sécurité, l hétérogénéité et l optimisation de la qualité de service impliquent une extension du modèle, communément admis, d allocation de ressources et de répartition de charge. 1.2 Le contexte système Le contexte système s appuie sur les systèmes répartis à objets et sur le déploiement de composants. Des études ont été menées pour normaliser ces concepts. La norme RM-ODP [ISO96] a donné un cadre pour la spécification de tels systèmes. Il existe trois grands standards de fait dans l industrie informatique : CORBA (Common Object Request Broker Architecture) de l OMG (Object Management Group) ; DCOM (Distributed Component Object Model) de Microsoft avec son évolution.net de Microsoft et enfin JAVA RMI (Remote Method Invocation) de SUN MicroSystems. Nous explicitons ci-après ces trois grands standards Le modèle de référence RM-ODP Le modèle de référence RM-ODP définit un cadre architectural. Il présente notamment le concept de point de vue. Un point de vue est une perspective que l on peut avoir d un système tout en cachant les autres point de vues. Il existe cinq points de vue dans RM-ODP : Le point de vue entreprise définit les rôles des différents intervenants du système ainsi que les objectifs et les politiques globales. Le concept principal de ce modèle est un contrat qui exprime les obligations entre les différents participants dans une entreprise. Les concepts importants incluent agents, rôles, communautés et fédérations. Actuellement, le but est de progresser vers un langage plus spécifique [ISO99a]. Le point de vue information considère les sources et les destinations des informations échangées. Il fournit une interprétation commune assurant qu un concept identifié dans une interface est équivalent à un concept référencé dans une invocation distante. Le point de vue traitement détermine la décomposition fonctionnelle du système en un ensemble d objets qui interagissent via des interfaces permettant ainsi leur répartition. La création d une liaison est réalisée pour l interaction entre des objets via ces interfaces. Le point de vue ingénierie explicite l infrastructure nécessaire pour réaliser les interactions entre les objets. Il définit un ensemble de concepts abstraits pour modéliser les communications et les ressources système. Sur le plan des communications, le modèle définit le concept d un canal qui consiste en une configuration avec des objets talons (représentants locaux de l objet distant), des objets de liaisons (qui assurent l intégrité du canal de communication), des objets de protocoles (fournissent une abstraction du protocole de communication) et un intercepteur. Sur le plan des ressources système, le modèle définit le concept de noeuds, capsules, et grappes. Le point de vue technologie qui considère les solutions techniques, les matériels et logiciels nécessaires pour réaliser le système. RM-ODP définit aussi un ensemble de transparences permettant une abstraction de la complexité de ces systèmes répartis : la transparence d accès, de persistance, de localisation, de migration, de relocalisation, de défaillance, de transaction et de réplication. Ces notions

23 1.2. LE CONTEXTE SYSTÈME 23 doivent servir de base à la construction d un système réparti pour les objets ou pour les composants. Ce modèle abstrait est généralement considéré comme la référence en la matière même si la norme CORBA définit également ses propres structures La norme CORBA La norme CORBA est spécifiée par l Object Management Group (OMG) qui est composé de la plupart des industriels du logiciel et de groupes de recherche académique. Elle vise à spécifier les fonctionnalités d un bus logiciel pour les applications distribuées. Elle a un souci constant de prendre en compte l hétérogénéité (des systèmes, réseaux ou langages) tout en préservant l interopérabilité. Cette stratégie vise à faciliter l intégration d applications existantes (par encapsulation). Son principe est de décrire les fonctionnalités des objets distribuables dans un langage indépendant de tout contexte. Pour cela, l OMG a normalisé l Interface Definition Langage (IDL) qui permet uniquement de décrire des interfaces. A partir de cette spécification il est possible de générer une traduction (projection) de l interface dans différents langages (C, C++, SmallTalk, Java, etc). En plus de la génération d interface, les souches clientes (Stub) et les squelettes d implémentation (Skeleton) associés peuvent être générés pour le langage cible. Ainsi, une application écrite en C dont l interface a été décrite en utilisant le langage IDL pourra, par exemple être utilisée par une autre application écrite en Java. Ces Stub et Skeleton servent d interfaces avec un ORB particulier. L architecture de l ORB est également décrite dans la norme (le A de CORBA). Les objets sont connectés par le Object Request Broker (ORB) comme nous le montrons sur le schéma 1.1. L ORB peut être implanté comme un serveur, une librairie ou un système. Pour qu il soit possible de communiquer entre les ORBs l OMG a défini le General Inter ORB Protocol (GIOP) qui définit le format des messages et la Common Data Representation (CDR) pour le format des données échangées. Ce protocole peut être instancié au dessus de différents autres protocoles. Une des intances est l Internet Inter ORB Protocol (IIOP) au dessus du protocole TCP. Les instances sont alors référencées par un unique Interoperable Objet Reference (IOR). Les clients peuvent communiquer avec d autres objets de deux façons : 1. Avec le Stub généré à partir de l interface IDL qui permet d appeler un objet dont l interface est connue statiquement. 2. Avec l interface d invocation dynamique (DII) qui permet de construire les appels dynamiquement. Ces deux approches se retrouvent au niveau du serveur avec le Skeleton généré à partir de l IDL et le Dynamic Skeleton Interface (DSI) qui permet d interpréter les requêtes dynamiquement. Toutes deux utilisent un Object Adapter (OA) qui définit le mécanisme d activation et d exportation des objets. Deux adapter sont actuellement normés le Basic Object Adapter (BOA) et le plus récent Portable Object Adapter (POA) qui doit permettre une meilleure portabilité entre les différentes implémentations des différents vendeurs. Les Repositories sont des bases de données. l Interface Repository (IR) stocke les informations de type des objets et l Implementation Repository stocke les informations sur les implémentations des objets. Chaque objet est enregistré par l OA.

24 24 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE CLIENTS SERVEURS INTERFACE D INVOCATION DYNAMIQUE DII INTERFACE D INVOCATION STATIQUE SII INTERFACE ORB Interface Adaptateur d Objets INTERFACE INTERFACE SQUELETTE SQUELETTE STATIQUE DYNAMIQUE Adaptateur d Objets OBJECT REQUEST BROKER Référentiel des interfaces Référentiel des implémentations Fig. 1.1 L architecture CORBA OMA En plus du bus, l OMG a spécifié l interface d un certain nombre d objets et services. Ces spécifications et celles de CORBA forment l Object Management Architecture (OMA). Ces objets sont regroupés par classes : Les Common Object Services (COS). Les utilitaires communs. Les interfaces de domaine. Les objets applicatifs. Un certain nombre d interfaces d objets du COS sont spécifiées. En particulier, celle du service de nommage des objets La norme RM-ODP et la norme CORBA On peut considérer RM-ODP comme un méta-standard pour les systèmes répartis ouverts. Il fournit un cadre sur des concepts architecturaux et une terminologie pour faciliter les standards spécifiques. Dans ce contexte, RM-ODP est un modèle plus abstrait que des standards existants tels que CORBA. Il existe un lien fort entre CORBA et RM-ODP puisque CORBA concrétise les concepts principaux de RM-ODP. Par exemple, si l on s intéresse au point de vue traitements, l IDL (Interface Defination Language) de CORBA peut être utilisé pour concevoir la décomposition fonctionnelle du système en un ensemble d objets avec ses interfaces. Dans le point de vue ingénierie, c est l ORB qui assure pour les liaisons entre les talons et les squelettes. Le standard de Protocol Support for Computational Interactions [ISO99b] fournit un lien important entre une architecture ODP et les définitions de CORBA par l OMG. Il montre les correspondances entre les protocoles (GIOP) de CORBA avec l infrastructure de communication de ODP.

25 1.2. LE CONTEXTE SYSTÈME DCOM DCOM est la technologie de composants développée par Microsoft pour Windows. C est, en fait, la pierre angulaire de toutes les nouvelles technologies que Microsoft a introduit dans Windows, telles qu OLE, DirectX et ActiveX. La grande force de DCOM est le nombre de machines sur lesquelles il est installé, tout simplement en raison des parts de marché de Windows dans le monde. Par contre, DCOM souffre d une complexité non négligeable, et de son aspect fermé vis à vis des autres systèmes à objets tels que Corba 2 ou à composants pour Corba 3.0. Contrairement à CORBA, DCOM spécifie les interfaces entre les composants au plan binaire, et non au niveau source. Ceci signifie que la manière d utiliser les interfaces des composants n est pas imposée par les langages de programmation (il n y a pas de «projection» du langage de description des interfaces pour chaque langage de programmation). Le seul paramètre qui compte est la structure de ces interfaces et les conventions d appel utilisées par ces méthodes. Ce choix technique fournit une certaine liberté dans la manière d implémenter et d utiliser les composants mais est techniquement beaucoup plus compliqué lors de l implémentation. En effet, alors que dans Corba les communications et la gestion de la durée de vie des composants sont pris en charge par les proxies et les stubs générés par le compilateur IDL (dont les interfaces sont normalisées), cette tâche est dévolue au programmeur dans DCOM. DCOM fournit tous les services de base d un système à composants : création et gestion de la durée de vie des composants, marshalling, répartition, gestion des versions, réutilisabilité, extensibilité, gestion des langages de scripts, détection des interblocages, etc. A présent, il est utilisé par la plupart des services de Windows. L une des manières les plus faciles de l utiliser est bien entendu de recourir à des outils comme Visual Basic et ses dérivés. Mais il est toujours possible de programmer et d utiliser des composants de manière plus classique, en C ou en C++. Toutefois, il est fortement recommandé d utiliser le C++ et les librairies ATL Active Template Libraries de Microsoft, car la programmation directe de DCOM est véritablement très difficile. DCOM a connu différentes évolutions et changements de noms du fait du marketing de Microsoft. La technologie de DCOM s est initialement appelée OLE (Object Linking and Embedding), car il permettait d incorporer directement des objets d autres applications ou de réaliser des liens sur ces objets dans un document composite. Techniquement parlant, OLE est un ensemble d interfaces permettant d obtenir ce résultat d intégration et de lien entre les applications. Microsoft a ensuite fait la distinction entre ces interfaces et le modèle objet de composants sur lequel elles se basent. Ce modèle objet a été appelé COM (Component Object Model). Dès le départ, Microsoft avait prévu que COM puisse être distribué, mais l implémentation de DCOM n est apparue réellement qu avec Windows NT 4. Par la suite, Microsoft a développé son API de jeux pour Windows 95 nommée DirectX. Cette API utilise exclusivement l architecture de COM, et a inauguré l introduction de la lettre X dans les noms de technologies de Microsoft. Avec l arrivée d Internet, les contrôles ActiveX sont apparus. Au delà de la nouveauté apparente, il est possible de les assimiler à des contrôles OLE classiques, mais il fallait trouver un nom spécifique pour les développeurs Internet. Finalement, les «Active Template Libraries» ne sont rien d autre qu une librairie C++ permettant de développer des contrôles ActiveX plus facilement. En fait, un contrôle ActiveX n est rien d autre qu un composant OLE, ou un composant DCOM, ou un composant COM tout court. Ces différentes dénominations sont en réalité des composants ayant plus ou moins

26 26 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE d interfaces à fournir à leurs clients. Quoi qu il en soit, DCOM est à présent incontournable. Il est omniprésent dans Windows, et toutes les nouvelles technologies présentes et à venir ne seront utilisables qu au travers de lui. La programmation classique de Windows est donc en train de subir une mutation profonde, et tous les programmeurs auront un jour à s y interesser sérieusement. Cependant, cela ne va pas être aisé, car toute la complexité de DCOM resurgit toujours un jour ou un autre. Mais cette complexité est le prix à payer pour accéder aux nouvelles fonctionnalités de Windows et pour garantir la pérennité et la réutilisabilité des logiciels Java RMI Avec l émergence de l informatique répartie dans les entreprises, il s avère nécessaire de pouvoir accéder à des objets Java à distance. Pour faciliter la tâche du programmeur, les concepteurs de Java ont créé plusieurs classes permettant l invocation de méthodes à distance : c est le Remote Method Invocation (RMI). Avec RMI, toute la programmation au niveau socket est cachée, et le programmeur n a qu à se soucier que de l implémentation des objets distants de son programme. Une application RMI est composée d une partie client et d une partie serveur. Le rôle d un serveur est de créer des objets qu on qualifie de distants, de les rendre accessibles à distance et enfin d accepter des connexions de clients vers ces objets. Le rôle d un client est donc d accéder aux méthodes des ces objets, tout en considérant ces objets comme des objets locaux. RMI est le mécanisme qui permet d assurer la communication entre le serveur et le client et la transparence des accès. Le principe de fonctionnement d une application RMI est le suivant : Le serveur crée les objets et les enregistre auprès d un service appelé rmiregistry. Cela permet aux clients de localiser les objets et d obtenir des références vers ces objets. Lorsqu un client désire invoquer un objet à distance, il consulte la rmiregistry pour localiser l objet : il fournit le nom de l objet et reçoit en retour une référence vers cet objet. Avec la référence nouvellement obtenue, le client pourra invoquer les méthodes de cet objet. Un objet désirant être invoqué à distance (Remote Object), devra implémenter une interface qui étend l interface java.rmi.remote. Lorsqu un client obtient une référence vers cet objet, il obtient en fait une référence vers une souche (stub). Un stub est un mandataire de l objet qui est chargé dans le client au moment de l obtention de la référence. Ainsi la référence que le client utilise pointe vers ce mandataire qui implémente d ailleurs les mêmes interfaces que l objet distant. Le client invoque ainsi, par le biais de sa référence, les méthodes qui résident dans le stub. Ces méthodes se chargent alors elles-mêmes d invoquer les vraies méthodes sur l objet distant en passant à travers le réseau. C est ce mécanisme qui assure la transparence des appels. La création d une application repartie en RMI consiste, par conséquent, en les étapes suivantes : 1. Concevoir et implémenter les composants de l application sous forme d objets locaux ou distants. 2. Compiler les sources et générer les stubs. 3. Rendre les objets accessibles à travers le réseau.

27 1.2. LE CONTEXTE SYSTÈME Démarrer l application. Ces dernières années, la norme CORBA s est vue, elle aussi, implantée au langage JAVA, afin de répondre à la demande des utilisateurs et des développeurs d une passerelle entre JAVA et CORBA mais aussi pour l adoption du protocole IIOP dans Java RMI Synthèse Nous pouvons déduire de ces trois modèles qu ils ont un point commun et un même but : celui de faciliter le développement d applications réparties à objets et ce, grâce à la définition de standards. Ils assurent une transparence des communications entre les objets et/ou les composants. Ces différents modèles, qui ont chacun leurs atouts et leurs inconvénients, se disputent le royaume de l Internet. Par exemple, DCOM, qui est le plus répandu sur les plateformes Windows, tente d interopérer avec d autres plateformes en utilisant, par exemple, le pont COM/IIOP ou les ActiveX et maintenant.net. Le langage JAVA s est également doté de son modèle avec RMI qui présuppose que les programmes clients et serveurs soient tous deux écrits en Java et qu ils soient exécutés par une machine virtuelle Java, de part et d autre du réseau. La norme CORBA se voulant indépendante des langages de programmation et des systèmes d exploitation, repose sur un modèle objet neutre et convient à un environnement hétérogène Le modèle système Des trois standards précédents nous pouvons déduire le modèle système. Ce modèle doit s inspirer et utiliser les grandes lignes directrices tracées par ces standards. Pour ce faire, il convient de caractériser et généraliser l ensemble des propriétés nécessaires et obligatoires pour obtenir un modèle système le plus complet possible. Les caractéristiques du modèle sont les suivantes : Il doit supporter le modèle objet avec des composants et des interfaces ; Il doit fournir une transparence d accès et de migration pour autoriser le placement et le déploiement d application lors de la répartition de charge ; Il doit supporter les différentes architectures de machines et les systèmes d exploitation pour aider à la gestion et la prise en compte de l hétérogénéité ; Il doit accepter les technologies Internet pour répondre à l essor des autoroutes de l information ; Il doit intégrer les interactions entre plusieurs points de vues, par exemple système et langage. Il doit prendre en compte les besoins applicatifs, c est-à-dire les besoins propres des objets par rapport à leur contexte d exécution pour associer une expressivité accrue à la connaissance des applications et permettre un meilleur placement ou déploiement des applications. Les six caractéristiques du modèle système doivent permettre l utilisation et la création de systèmes de répartition de charge et de gestion de ressources plus expressif, plus dynamique et plus adéquat par rapport aux applications.

28 28 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE 1.3 Le contexte applicatif Le contexte applicatif repose principalement sur des applications distribuées implémentées sous forme de composants avec le modèle CORBA. Le contexte applicatif a connu de nombreuses évolutions depuis ces dernières années Les évolutions de l applicatif Les évolutions et la démocratisation de l Internet ont participé à la forte croissance de la complexité des applications disponibles sur le WWW (World Wide Web). Les applications sont devenues, au fil du temps et des avancées technologiques, très dynamiques. Par exemple, le support d applications client-serveur interactives a été créé grâce au protocole CGI (Common Gateway Interface). L interaction avec d autres applications donnant accès à des bases de données et/ou de construction de pages dynamiques est devenue possible. Depuis quelques années d autres langages ont été introduits pour donner encore plus de dynamicité. C est le cas du langage de scripts PHP (Hypertext Preprocessor) ou des ASP (Active Server Page) de Microsoft. La technologie JAVA a permis, elle aussi, d introduire un nouveau concept internet : les applets, programmes chargés depuis un site distant qui peuvent s exécuter sur des machines clientes. Depuis, ce concept a été étendu grâce aux invocations distantes entre les composants, d une part avec RMI et les EJB et, d autre part avec l intégration des architectures à composants de CORBA 3 et.net. Toutes ces avancées sont le résultat d une demande toujours croissante de dynamicité et d ergonomie de la part des utilisateurs et des concepteurs. La masse d informations concernant les applications d aujourd hui est énorme et leur déploiement n est pas toujours facile. En effet, les applications peuvent être à la fois dynamique dans leur comportement mais également dans leur besoins de ressources. Par exemple, une application peut nécessiter une ressource particulière pour un calcul (un processeur puissant) et ensuite une connexion réseau rapide pour transférer les résultats de ses calculs. Nous parlons ici d applications dans leur ensemble, cette notion importante de dynamicité s étend aussi aux composants qu elles contient et qui la caractérise. Chaque composant a, lui aussi, des besoins propres pour son exécution, besoins qui peuvent également varier au cours du temps et dans l espace. Les besoins applicatifs doivent donc correspondre le plus possible aux ressources offertes pour permettre une exécution de manière correcte et/ou efficace. Quelques technologies de déploiement existent mais nous pouvons affirmer que même si elles ne sont pas toutes spécifiquement dédiées aux systèmes répartis, la tendance s oriente vers une architecture à base de composants à grande échelle et pour tous. Cependant, peu de ces systèmes prennent en compte les besoins applicatifs et par extension ceux des composants et leur mobilité, même si le concept d ADL que nous présentons dans le chapitre 2 paragraphe 2.4 donne des éléments de réponse à ce problème Le modèle applicatif Les exemples d applications pouvant être prises en compte dans notre environnement sont nombreuses et diverses (logiciels coopératifs, vidéo-conférence, etc). Une application distribuée est un ensemble de composants communicants : des clients, des serveurs ou les deux à la fois. Les applications ou, du moins tout ou une partie de ses composants, sont distribuées lors du déploiement. Ces composants peuvent modifier leurs comportements, leurs données, leurs

29 1.4. PROBLÉMATIQUE 29 besoins et être remplacés, modifiés ou supprimés de l application. L optimisation de l utilisation des ressources et de leur accès prend ici tout son sens. Elle permet globalement une meilleure exécution de l application. Pour cela, des fonctions de mobilité et de déploiement (placement initial, migration) autorisent le positionnement des composants des applications de manière optimale. L utilisation de procédures de décision ainsi qu un système de gestion des besoins applicatifs, en regard des ressources offertes des machines sur le réseau, participe au déploiement et au placement. Il convient alors d offrir la meilleure qualité de service possible en plaçant ou déplaçant les composants afin d augmenter l efficacité et l exécution des applications et des composants. Par exemple, pour optimiser l utilisation des ressources de communication des composants. Les serveurs et les clients peuvent être placés sur une même machine en utilisant la migration ou la duplication. Pour optimiser l utilisation des ressources d exécution, le placement peut être utilisé pour lancer un serveur sur un ordinateur peu chargé satisfaisant les besoins le composant et l agrégation peut être utilisée pour réduire le nombre de serveurs si certains sont inactifs pendant une période donnée. Bien sûr, ces exemples sont des scénarios simples qui ne permettent d optimiser que certains points de vues. Lorsqu un grand nombre d informations ou de facteurs doivent être pris en compte pour l allocation des ressources, la procédure de prise de décision devient plus complexe. La qualité de décision peut alors devenir un compromis entre complexité et efficacité. 1.4 Problématique Notre étude fait suite aux thèses de P.Chatonnay [Cha98] et de Hy.Chan [Cha99]. Dans ce travail, un gestionnaire d objets nommé GO a été réalisé en utilisant une analyse multicritère qui tient compte des communications et de la charge des machines. Ce modèle a été étendu au multidomaine et à l auto-adaptivité avec une prise en compte de contraintes inter-domaines. [Cha99] propose de réaliser un placement des objets, dans le but d optimiser l exécution des applications réparties en agrégeant des informations concernant trois dimensions de l exécution : la charge des sites, les communications et dans une certaine mesure quelques informations sur les contraintes d exécution entre les différents domaines. Notre modèle s appuie sur un domaine de type réseau local tout en étendant le concept de la prise en compte des besoins applicatifs ainsi que celui des procédures de décision. Nous essayons d améliorer les résultats précédemment obtenus pour que le système GO puisse réagir et utiliser un large éventail de paramètres décrivant au mieux le système et ses composants. Les applications que nous désirons optimiser sont basées sur des composants de grain fin ou moyen. Leur distribution et leur dynamicité nécessite l utilisation d un système d allocation et de gestion de ressources pour réaliser une exécution dans des conditions adéquates sur l ensemble des machines formant notre réseau. Nous ajoutons aux paramètres habituels de la répartition de charge que sont la charge processeur, du réseau, la dépendance entre objets et une dimension de besoins applicatifs. Ces besoins nous permettent de parfaire notre connaissance des composants et ainsi ajuster d une meilleure façon la répartition de charge et le déploiement des applications. L environnement est alors plus adapté aux différents besoins puisqu il est en relation forte avec les ressources matérielles offertes. Ceci entraîne les nouvelles problématiques que nous présentons ci-dessous.

30 30 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE La gestion des ressources Le déploiement d applications réparties utilisant le concept de contraintes et de préférences applicatives pose différents problèmes que nous énumérons ici : L utilisation des ressources, l optimisation des communications, l optimisation de la charge, la qualité d accès aux services, la connaissance des besoins applicatifs et leurs expressions. la connaissance des ressources fournies la prise de décision de placement ou déplacement en fonction de paramètres divers obligatoires et/ou facultatifs. Le déploiement de ce type d applications suppose de respecter différentes contraintes d hétérogénéité et d expressivité des composants tout en optimisant la qualité de service. Pour optimiser l exécution de telles applications, nous cherchons à intervenir sur le placement ou le déplacement des objets en fonction des ressources utilisées et des besoins intrinsèques de chacun. De cette manière, nous pouvons rendre plus rapide l accès et l exécution de leurs méthodes, tout en respectant une exécution correcte et mieux gérée. Une prise de décision efficace est alors nécessaire L expression des besoins L expression des besoins applicatifs est laissée à l utilisateur, au programmeur ou à l administrateur. Les besoins ne sont pas obligatoirement fixés à l avance. Le composant ou l application doit être capable de se reconfigurer dynamiquement en fonction des différents événements ou changements qui peuvent intervenir Les besoins applicatifs Nous devons définir la notion de besoin exprimé par un composant. L expression d un besoin permet à un composant d énoncer le fait que son exécution est liée à une ressource. Par exemple, un composant peut exprimer le besoin d être exécuté sur un type donné de processeur. Le besoin qualifie ainsi la présence obligatoire (une contrainte ou véto) ou le niveau de disponibilité (une préférence) soit dans le temps, soit dans l espace d une ressource ou d un traitement. L idée directrice est qu à chaque portion de code d une application répartie correspond un environnement matériel et logiciel adapté. Il est possible de décomposer un programme en plusieurs phases ayant chacune des besoins spécifiques, ce qui permet d introduire une dynamicité au niveau de l expression de ses besoins Les contraintes et les préférences La réflexion sur notre problématique, nous amène à faire des choix sur les besoins applicatifs nécessaires pour satisfaire au mieux administrateurs, programmeurs et utilisateurs. Pour ce faire, nous devons tout d abord affiner la notion de besoins applicatifs. Nous divisons les besoins en deux catégories : 1. les contraintes, qui correspondent aux besoins minimums nécessaires à l exécution des composants d applications ou des applications en général.

31 1.5. CONCLUSION les préférences, qui permettent de spécifier des besoins facultatifs permettant d affiner la connaissance des composants applicatifs. Cette réflexion est à la base de notre travail, mais il faut également lui adjoindre une prise de décision solide La prise de décision La prise de décision est une question très importante lors du placement ou déplacement d applications et/ou de composants. De nombreuses méthodes sont disponibles pour agréger des critères différents afin de proposer une décision suivant plusieurs points de vues. Nous pouvons citer les procèdures de décision multicritère [RB93] ou logiques, qui peuvent convenir à l allocation de ressources lors de la prise en compte de plusieurs paramètres comme la charge, le volume des communications, etc. Cependant, il ne semble pas avoir de méthode simple et universelle. Nous touchons à l un des problèmes essentiels de l allocation de ressources qui utilise généralement un compromis dans la prise de décision pour le placement, car les informations agrègées peuvent mener à des antagonismes sur ce placement. Ce problème est amplifié par l augmentation des paramètres possibles à prendre en compte. 1.5 Conclusion Nous avons présenté les problèmes posés par la prise en compte de la notion de besoins applicatifs et de la prise de décision dans le placement dynamique. Dans ce contexte, la diversité des ressources et des composants est telle qu elle doit être prise en compte par le système de placement. Ceci suppose de donner au composant la possibilité de définir ses contraintes et ses préférences. Dans ce cas, le travail du service de placement consiste à optimiser l utilisation des ressources tout en respectant les besoins donnés par le composant. Plus précisément, le but de notre travail s articule autour de la gestion et de l allocation de ressources dynamiques reposant sur un modèle distribué grâce à des heuristiques décisionnelles. Cette méthode a pour but d attribuer dynamiquement les ressources du système à la création des composants et lors de leurs exécutions. Le but est alors de trouver le noeud (une machine ou un ensemble de machines), dans le système distribué, qui permettra d obtenir les meilleures performances et la meilleure adéquation avec les besoins du composant par l utilisation de divers mécanismes de gestion de ressources. Pour optimiser l utilisation des ressources et leur accès, nous utilisons des fonctions de mobilité (placement initial, migration) et nous positionnons les composants des applications dans le meilleur environnement possible en utilisant des procédures de décision. Quand un grand nombre d informations ou de facteurs doivent être pris en compte pour l allocation des ressources, la procédure de prise de décision devient plus complexe et la qualité de décision peut devenir un compromis entre complexité et efficacité. Il semble qu il n existe pas ou qu il soit difficile de trouver et de construire une seule méthode d allocation de ressources qui permette de concilier à la fois les objectifs d optimisation du temps d exécution, de la bande passante, de prise en compte de besoins applicatifs et de qualité de service. Le problème auquel nous sommes confrontés est un problème NP-complet du fait du nombre de paramètres possibles et de l incertitude inhérente à une allocation de ressources générique. Néanmoins, le concept de composant peut amener quelques éléments

32 32 CHAPITRE 1. CONTEXTE ET PROBLÉMATIQUE de réponse à notre problématique. Pour cela nous devons analyser son principe pour nous permettre de l utiliser au mieux au sein de notre problème.

33 Chapitre 2 Les composants 2.1 Introduction aux composants Depuis quelques années, le développement à base de composants s est imposé au sein des systèmes informatiques. Par exemple, il est très utilisé pour la conception de composants techniques commerciaux dans les domaines tels que la gestion de l information (systèmes de gestion de bases de données, systèmes de gestion de données techniques, etc) et les intergiciels (moniteurs transactionnels, systèmes répartis à objets, messageries inter-applications). Les avantages de l utilisation de composants logiciels sont a priori clairs. Il s agit essentiellement de réduire les coûts de production, de maintenance et de favoriser la réutilisation des logiciels. Néanmoins, cette démarche est une tâche assez difficile car l assemblage des briques logicielles pour constituer une application efficace et facile à utiliser nécessite un travail qui peut être fastidieux et compliqué. Les composants, et plus particulièrement les composants commerciaux, sont souvent complexes et instables à cause de l ajout fréquent de nouvelles fonctions aux composants par souci de rester compétitif au niveau commercial. Par conséquent, ceci génère une contradiction entre la conception architecturale qui permet de déterminer précisément comment le système est partitionné en composants et l utilisation de composants préexistants qui induit une perte de contrôle sur les décisions de conception fondamentales. Nous devons donc nous pencher sur les concepts mêmes des composants. Les concepts présentés ici sont génériques et sont couramment évoqués dans le contexte des composants logiciels. Nous insistons en particulier sur la notion d assemblage et sur celle de contrat qui sont indissociables de la notion de composant. 2.2 Les composants La définition d un composant n est pas encore aussi complète et communément acceptée que la définition des objets. Cependant, il est possible d énumérer quelques caractéristiques propres à l approche composant. D une manière générale, un composant est un logiciel qui rend un service en utilisant une ou plusieurs interfaces externes. Un composant a vocation à être intégré et à servir dans plusieurs applications. Pour ce faire, il doit être suffisamment autonome et comporter toutes les informations lui permettant, éventuellement, d être assemblé avec d autres composants. 33

34 34 CHAPITRE 2. LES COMPOSANTS Les interfaces et les services Les services offerts par un composant trouvent leurs définitions par l utilisation de plusieurs interfaces externes. Ces interfaces sont associées aux différents rôles de l activité du composant (interface métier, interface de configuration, de maintenance, etc...). Par ailleurs, un composant peut utiliser d autres composants pour son exécution en mettant en place les interfaces requises. Ces interfaces peuvent et doivent être connectées à des interfaces offertes par d autres composants. Ces différents rôles impliquent la définition de spécifications et de contrats pour la bonne exécution du composant et par extension de l application elle-même Les spécifications et les contrats La réutilisation et l intégration d un composant logiciel implique la connaissance du rôle du composant. Il est donc nécessaire d associer au composant des spécifications précises tant fonctionnelles que non-fonctionnelles. Ces spécifications décrivent les services offerts par le composant ainsi que les besoins nécessaires à son fonctionnement (contraintes d exécution, contraintes d environnement, etc) car l environnement peut posséder des propriétés qui auront une influence sur le fonctionnement du composant. Par exemple, il peut s agir de propriétés temporelles sur la vitesse d exécution ou sur la sécurité. Les spécifications doivent également porter sur les comportements du composant associés à ces traitements non-fonctionnels. Les contraintes d environnement comportent de même le type de plateforme (matériel, système d exploitation, architecture réseau, conteneur) dans laquelle le composant doit s exécuter. Ces définitions sont en lien direct avec notre travail où nous cherchons à optimiser les placement des applications en utilisant des propriétés sur le comportement mais aussi sur les contraintes d environnement et d exécution comme par exemple le type de processeur, la bande passante, le niveau de sécurité, etc. Ceci est également à rapprocher fortement du terme de contrat que l on trouve dans la notion de composants. En effet, les contrats sont de plus en plus utilisés pour décrire les propriétés nécessaires et obligatoires pour permettre l exécution du composant. Chaque composant est ainsi spécifié par deux types de contrats : 1. Un contrat d utilisation qui décrit les services offerts et requis par le composant. 2. Des contrats d implantation qui décrivent les contraintes et les propriétés requises de l environnement. Ces contrats doivent naturellement satisfaire au contrat d utilisation. La spécification d un composant se traduit par un ensemble de contrats qui définissent le plus précisément possible ses exigences et ses aptitudes. Les composants permettent d encapsuler des parties de système sans demander à leurs utilisateurs de connaître les détails de leur réalisation. Lorsqu un composant est assemblé avec d autres composants, leurs contrats d utilisation sont confrontés, négociés et parfois adaptés pour satisfaire aux différentes hypothèses et contraintes. Cette phase peut être réalisée automatiquement par un compilateur, manuellement par les concepteurs du système en fonction de la richesse du contrat ou dynamiquement à la demande. Ce principe est celui d une partie de notre architecture de gestion des besoins dynamiques des composants par rapport à leur environnement (contraintes d exécution, préférences d exécution, etc). Un contrat peut en effet se décomposer en quatre niveaux qui dans la pratique se traduisent par des règles d assemblages de moins en moins automatisables. Ces quatre niveaux sont les suivants : 1. Le niveau un : il assure le bon déroulement de l assemblage structurel.

35 2.2. LES COMPOSANTS Le niveau deux : il décrit pour chaque service offert les conditions d utilisation et le résultat attendu. 3. Le niveau trois : il garantit qu en cas d utilisation concurrente le fonctionnement sera correct et conforme au résultat attendu. 4. Le niveau quatre : il précise les conditions quantitatives d utilisation du composant en termes de qualité de service. La plupart des spécifications actuelles de composant (EJB, CCM,.NET) reposent uniquement sur le premier niveau qui assure le typage correct des interfaces offertes et requises (même nom de service, même nombre d arguments, mêmes types, mêmes exceptions, etc). Ces éléments de contrat sont utilisés défensivement à l exécution pour lever des exceptions en cas de rupture de contrat et non pas préventivement par des outils de preuves ou de compilation sophistiqués. Sous réserve d atomicité d exécution des services, le contrat de niveau deux suffit pour garantir le bon fonctionnement du composant. Toutefois, certaines implantations d objet ou de composant incluent du parallélisme et les hypothèses d atomicité ne sont pas toujours garanties. C est le rôle du niveau trois des contrats de décrire les hypothèses de concurrence acceptées par les composants. Enfin, le niveau quatre précise quantitativement le fonctionnement du composant. Le contrat spécifié doit, lors de l assemblage, être confronté aux autres contrats d utilisation pour être accepté tel quel ou modifié lors de l assemblage ou mieux encore, négocié et adapté dynamiquement en cours de fonctionnement du système. Ce dernier point s applique au niveau quatre pour l adaptation de la qualité de service, mais aussi aux trois niveaux qualitatifs lors des évolutions du système. La qualité de service est en lien direct avec notre problématique et notre système de gestion des besoins applicatifs. En effet, la qualité de service est le but avoué de notre système, elle peut (ou non) être qualitative ainsi que quantitative et être représentée par un contrat d implantation. Finalement, la même notion de contrat permet de caractériser les contraintes d assemblages des composants (contrat d utilisation ou d usage) mais aussi les dépendances vis-à-vis du système pour la mise en œuvre (contrat d implantation) Les connecteurs La notion de connecteur [Bel01] recouvre l ensemble des moyens nécessaires pour assurer l interaction entre les composants par la connexion des interfaces requises et offertes. Un connecteur peut être défini de deux manières : au plan conceptuel par la spécification des propriétés des interfaces requises et des interfaces offertes. au plan communication par la spécification d un mode de communication. Le connecteur peut se voir implanté par un ensemble de moyens logiciels et matériels réels pour assurer concrètement l adaptation des propriétés requises à celles offertes La granularité La granularité des entités logicielles concerne leur taille et plus encore leur mode de gestion plus ou moins indépendante. De par son objectif de réutilisation, un composant doit être considéré dès la phase d analyse. L approche objet privilégie des entités logicielles de grain

36 36 CHAPITRE 2. LES COMPOSANTS moyen (comme des objets habituels ou des fichiers) ou de grain fin (comme des variables). Un composant doit pouvoir être déployé et géré indépendamment des autres composants. Ceci amène à lui associer des caractéristiques propres (caractéristiques de désignation, de protection, de gestion de ressources, etc). Cette notion diffère quelque peu de l approche objet de grain fin ou de grain intermédiaire Les structures d accueils Lorsque les composants sont construits et assemblés, ils peuvent être déployés. La structure d accueil correspond à l environnement système dans lequel les composants sont installés, instanciés et activés. Il peut s agir d un système d exploitation ou d un environnement dédié à un certain modèle de composant. Dans ce dernier cas l environnement est appelé généralement structure d accueil. 2.3 Les différentes catégories de composants Au plan conceptuel, on peut différencier trois types de composants : Les composants boîte noire sont des codes compilés ou binaires. Leurs fonctionnalités ne sont accessibles qu au moyen de leurs interfaces publiques et ils ne peuvent être modifiés directement. Pour étendre ou redéfinir certaines de leurs fonctionnalités, il est nécessaire d utiliser des adaptateurs. Les composants boîte blanche sont fournis en code source et sont modifiables avant leur intégration ou assemblage. Les composants boîte grise qui sont un mélange des deux précédents, c est à dire un sous-ensemble des modalités de fonctionnement qui serait ouvert à la modification au moyen d un ensemble de mécanismes prédéfinis. Les composants peuvent également être considérés plutôt comme des services c est à dire réutilisables sous la forme installée du composant. Dans ce cas, un environnement d exécution est offert par le fournisseur du composant sur l un de ses serveurs. Dans les deux cas précédents, toute approche composant se doit d offrir un moyen de rechercher et de trouver en ligne des composants sur étagères ou déployés qui conviennent pour construire une application. Un exemple de standard récent pour traiter ce problème est donné par le protocole et la base de données distribuées UDDI des Web Services. Enfin, les composants métier se distinguent des composants non-métier ou système. Les premiers sont développés dans le cadre d une profession ou d une entreprise et satisfont des besoins liés aux activités d un utilisateur. Les seconds sont des composants développés pour résoudre un problème correspondant à un besoin rencontré par un ensemble d applications de métiers différents (composants de communication, de sécurité, de persistance transactionnelle, etc...). Un composant est donc destiné à être connecté et assemblé avec d autres composants. Les deux principales approches actuelles sont les langages de description d architectures et les langages de coordination. 2.4 Les langages de description d architecture La définition de l architecture est une étape importante dans la conception d un logiciel. Elle doit permettre la réalisation d un produit qui réponde aux besoins des utilisateurs, mais

37 2.4. LES LANGAGES DE DESCRIPTION D ARCHITECTURE 37 qui est également évolutif. Malgré ces deux caractéristiques essentielles, la pratique veut que cette étape soit encore souvent oubliée ou traitée de manière partielle. Actuellement, les recherches sur les ADL ou Architecture Description Languages changent d orientation. En effet, ils sont issus de la communauté des architectes logiciels et définissent une technologie parallèle à celle développée dans le monde objet. Cette définition des architectures permet d avoir un niveau d abstraction élevé et de disposer de modèles qui s approchent du modèle mental du développeur. Une architecture logicielle décrit l ensemble de ses composants avec les règles de leur assemblage. Elle permet la conception d applications en se détachant de détails techniques propres à l environnement et en respectant les conditions fixées par les futurs utilisateurs. En maîtrisant l architecture conceptuelle, il est alors plus facile de gérer ses éventuelles évolutions. En effet la modification d un plan est plus simple que la modification d un système réalisé. En réponse à ce besoin de description d architecture, de nombreux travaux ont été menés depuis une quinzaine d années. Ces travaux concernent la définition de langages de description d architecture ADL comme dans [SG96] et [GP95]. Nous explorons un peu plus profondément la notion d ADL ci-après Les concepts des ADL Il existe trois concepts définis au sein des ADL. Nous les énumérons ci-dessous : 1. le composant est une unité de calcul ou de stockage, simple ou composé (composite), à laquelle est associée une unité d implantation. Sa taille peut aller de la fonction mathématique à une application complète. Il est défini par une partie externe (description des interfaces fournies et requises) et par une partie interne qui correspond à son implémentation et permet la description du fonctionnement de cette partie. 2. le connecteur est un élément d architecture qui modélise de manière explicite les interactions entre un ou plusieurs composants en définissant les règles qui gouvernent ces interactions. Un connecteur est défini par une partie visible qui permet la description des rôles des participants à une interaction et par une partie correspondant à la description de son implantation. Il s agit, dans ce cas, de la mise en œuvre du protocole associé à l interaction. 3. la configuration ou encore la topologie. Les composants et les connecteurs sont des types pouvant être instanciés et assemblés à partir de leurs interfaces pour former une configuration. La configuration structurelle de l application correspond à un graphe connexe des composants et des connecteurs formant l application. La configuration comportementale, quant à elle, modélise le comportement en décrivant l évolution des liens entre composants et connecteurs, ainsi que l évolution des propriétés non fonctionnelles comme les propriétés spatio-temporelles ou la qualité de service. Un langage de contraintes accompagne souvent le langage de description d architectures pour décrire les règles de composition. Ces trois concepts permettent la création des ADL. Il existe plusieurs ADL qui ont été développés ces dernières années Les principaux ADL Les travaux sur les ADL correspondent à la définition de langages dits déclaratifs. Ces langages peuvent se séparer en deux familles distinctes :

38 38 CHAPITRE 2. LES COMPOSANTS Les langages qui privilégient la description des éléments de l architecture et leur assemblage structurel. Les langages de cette famille sont accompagnés d outils de modélisation, d analyseurs syntaxiques et de générateurs de code. Les langages qui se centrent sur la description de la configuration d une architecture et sur la dynamique du système. Les langages de cette famille, en plus d outils de modélisation et de génération de code, sont associés à des plateformes d exécution ou de simulation d un système. Chaque ADL a une particularité. Nous pouvons citer, par exemple : Wright [All97] qui se distingue par les descriptions comportementales à l aide de CSP, Rapide [dtpas97] par la définition de simulation, Aesop [Gar95] par la description de styles d architecture, C2 [MTW96] par les environnements répartis et évolutifs et Darwin [DKM93] par la description des aspects dynamiques. Ce grand nombre de propositions a amené plusieurs classifications et comparaisons pour les ADL actuels et à venir. De plus, plusieurs méta-langages proposent une représentation intermédiaire exploitable par les outils architecturaux des différents ADL. Un vocabulaire commun pour les éléments de la structure a été fixé pour permettre ainsi le passage d un ADL à l autre Le langage de coordination D un point de vue informatique, la coordination peut être exprimée en termes de modèles et langages de coordination. Ce langage est généralement caractérisé par trois éléments : les entités à coordonner ; le médium qui définit le lieu où se fait la coordination ; le type de coordination qui est la technique utilisée pour coordonner les entités. Un modèle de coordination fournit donc la sémantique, alors qu un langage de coordination correspondant fournit une syntaxe pour utiliser le modèle dans une implantation. Les applications actuelles profitent des systèmes parallèles et distribués pour offrir de meilleures propriétés non-fonctionnelles (passage à l échelle, fiabilité, disponibilité, etc). Cependant, le développement de telles applications reste complexe et la présence de multiples sites ajoute un nouveau défi : la coordination de la coopération d un grand nombre d activités concurrentes actives. De ce fait, la programmation d un système parallèle ou réparti pourrait être vue comme une combinaison de deux activités distinctes : une partie calcul comprenant un nombre de processus impliqués dans la manipulation des données. une partie coordination responsable de la communication et de la coopération entre les processus. Cette approche rend les modules plus indépendants et favorise l évolution des applications en modifiant seulement les éléments concernés sans intervenir sur l ensemble de l application. Cette définition a conduit à la proposition d un grand nombre de modèles de coordination et de leur langage de programmation associé. Nous exposons ci-après les principaux types de langage de coordination Les principaux types de langage de coordination Dans les langages de coordination, trois approches permettent de classifier les modèles et langages de coordination :

39 2.5. LES STANDARDS Les modèles orientés données La plupart des modèles appartenant à cette catégorie ont évolué autour de la notion de la mémoire partagée. L activité est alors centrée autour d un espace de données partagé. L application est essentiellement concernée par ce qui arrive aux données. Ces modèles offrent généralement un ensemble de primitives intégrables dans un langage de programmation. Ils sont, de ce fait, dits endogènes car les primitives qui affectent la coordination de chacun des modules sont à l intérieur du module lui-même ce qui mène généralement au mélange des primitives de coordination avec le code de calcul. Ceci tend à éparpiller les primitives de coordination et de communication dans le code source rendant le modèle de coopération et le protocole de communication flou et implicite. Le premier modèle orienté données conçu pour représenter la coordination est Linda [CG92] Les modèles orientés événement Le principe des modèles orientés événement repose sur le principe que l activité dans l application est centrée autour des traitements ou des flux de contrôle. L application est décrite comme une collection d activités qui consomment leurs données en entrée et en conséquence produisent, mémorisent et transforment les nouvelles données qu elles génèrent par ellesmêmes. Ces modèles sont dits exogènes, c est à dire que les primitives qui affectent la coordination de chaque module sont à l extérieur du module lui-même. Ces modèles encouragent le développement des modules de coordination séparément et indépendamment des modules de calcul qu ils sont supposés coordonner. Le langage de coordination est séparé de celui du calcul et est en général plus simple à comprendre et à réutiliser. Il existe plusieurs langages dans cette catégorie comme par exemple Manifold [AHS92] L approche par composant L approche par composant consiste à disposer d un type de composant qui ne s occupe que du calcul et un autre type de composant réutilisable qui ne s occupe que de la coordination des composants de calcul. Cette approche ressemble fortement à l approche orientée événement mais la différence se situe lors de la mise en œuvre de la coordination qui n est pas nécessairement le résultat d une compilation de la coordination mais qui est cachée dans le composant. Cela implique que seules les interfaces des composants apparaissent et que la technique utilisée pour la coordination est indifférente. L initiateur de cette approche est le langage Flo/c [Gün98]. Par la suite, nous nous pencherons plus particulièrement sur l approche par composant. Cette approche est le point central de plusieurs standards que nous présentons dans la section suivante. 2.5 Les standards L un des attraits d une architecture à composants est la possibilité de construire une application à partir de composants provenant d origines diverses. Cela suppose la standardisation des éléments nécessaires à un tel assemblage, notamment pour garantir les trois propriétés caractéristiques d un système ouvert : la portabilité

40 40 CHAPITRE 2. LES COMPOSANTS l interopérabilité l interchangeabilité. Il existe deux orientations de standardisation : l une concerne les outils de spécification et les modèles et l autre les infrastructures d accueil. Dans le domaine des outils de spécification et de modèles utilisables dans une approche composant, nous pouvons citer l UML Unified Modeling Language et la norme ODP Open Distributed Processing. Nous détaillerons l un de ces outils de spécification et de modélisation : UML 2, la présentation succinte de la norme ODP étant déjà réalisée dans le chapitre 1. Nous nous concentrerons également sur les trois standards que sont les EJB (Enterprise Java Beans), le CCM (Corba Component Model) et enfin Microsoft.NET Le modèle de composant d UML 2 Le standard UML 2 [CS02] propose un modèle de composant nettement amélioré par rapport à la version UML 1. Le méta-modèle d UML 2 définit les entités suivantes : Un composant est une entité instanciable qui interagit avec son environnement par l intermédiaire de ports. La description du comportement de ce composant est fondé sur des machines à états. Le composant est constitué de parties et peut inclure des connecteurs internes (pour connecter ensemble des sous-composants). Tous les composants doivent expliciter leurs besoins ainsi que leurs capacités. L utilisation d une méta-entité de dépendance permet d indiquer qu une entité dépend d une autre. Les services d un composant peuvent être invoqués seulement par l intermédiaire des ports de ce composant. Un port est une entité qui émerge d un composant. Le port se comporte comme un point d interaction du composant avec l environnement typé par une interface. Un port peut être requis pour signifier que l instance du composant doit être connectée à un port correspondant de l environnement. Un port qui est non requis offre des services. Ces services offerts peuvent être utilisés ou non selon que le port associé est connecté ou non. Naturellement, les ports peuvent être connectés si et seulement si leurs spécifications de comportement sont compatibles. Un port peut se voir attacher un comportement, lorsqu un composant veut décrire les interactions qui doivent se produire sur le port. Un connecteur est une entité qui relie des ports d instances de composant. Une interface définit un type. Elle contient un ensemble d opérations et/ou de contraintes. Une interface peut être attachée à un port fourni ou requis. Une partie est un fragment interne d un composant L assemblage de composants Une application ou un composant est constitué de l assemblage d autres composants par l intermédiaire de ports interconnectés. Il existe plusieurs types de connecteurs : Le connecteur d assemblage qui permet d assembler deux instances de composants en connectant un port fourni d un composant au port requis de l autre composant. Le connecteur de délégation qui permet de connecter un port externe au port d un sous-composant interne. L invocation d un service sur le port externe sera transmise au port interne auquel il est connecté.

41 2.5. LES STANDARDS Les événements La plupart des modèles de composants incluent un mécanisme pour la signalisation d événements entre le composant et son environnement. UML 2 n inclut pas de concepts spécifiques pour la signalisation d événements aux composants mais s appuie sur un concept déjà existant en UML Les flots UML 2 ne prévoit pas de flots continus qui spécifieraient des propriétés globales (comme la performance) et/ou les items qui circulent dans le flot ne seraient pas observables (au moins à un haut degré d abstraction) Le déploiement des composants A un certain moment de son cycle de vie, un composant sera configuré et installé en tant que sous-ensemble d une installation d une application. Dans UML 2, la notion de composant est indépendante de la plateforme et des modèles de composants spécifiques. UML fournit des outils conceptuels pour projeter les entités représentant les composants indépendants des plateformes sur les entités spécifiques aux différents vendeurs et aux différentes plateformes. Par exemple, un artéfact représente une entité spécifique à une plateforme et un noeud représente une entité capable d héberger une exécution d une instance de composant et de fournir des ressources de calcul et de mémoire Les Enterprise Java Beans Le standard EJB propose une architecture de composants pour le développement et le déploiement d applications réparties fondées sur des composants EJB appelés beans [Mic01]. Il décrit l architecture et les services qu un composant EJB peut utiliser (de manière transparente) mais ne donne aucun détail sur la manière de mettre en œuvre ces services. Cette liberté permet aux vendeurs d architectures EJB de se différencier d un point de vue performances ou possibilités offertes, et de fournir des services supplémentaires. Enfin, les composants EJB étant développés en Java, ils profitent de la portabilité de ce langage L architecture EJB L architecture EJB repose sur deux principes : 1. La fabrique d instance qui permet au client d accéder aux méthodes métier du bean, il doit tout d abord récupérer un accès au bean. Cela se fait par l intermédiaire de la classe EJBHome, qui renvoie une référence sur la classe EJBObject, représentant le bean correspondant. 2. La délégation des requêtes empêche le client d accèder directement au bean. Ses requêtes doivent être envoyées à l interface du bean : la classe EJBObject qui délèguera la requête vers le bean. Les trois classes Java (EJBHome, EJBObject et Bean) sont gérées par un conteneur (container), correspondant à l environnement d exécution du bean. Le standard EJB 2.0 définit également trois types de bean essentiellement différents par rapport à leur durée de vie.

42 42 CHAPITRE 2. LES COMPOSANTS Le Bean Session : ce bean n existe que pour une session demandée par le client. Deux types de bean session existent : Stateless (il n y a pas de maintien d informations à la suite des différentes requêtes qui lui sont adressées. Le Conteneur peut alors partager séquentiellement le bean entre plusieurs clients) et la session Stateful (le bean conserve en mémoire l état du client. Chaque instance du bean n appartient alors qu à son client, et ne peut être partagée). Le Bean Entité (Entity) : ce bean est une représentation de données persistantes. Il existe tant qu il n a pas été détruit explicitement. Pour récupérer un bean entité, un client peut utiliser la clé primaire du bean donnée lors de la création de ce dernier. L accès au bean peut être partagé entre plusieurs clients. Le Bean Orienté Message (Message-Driven) : ce bean est utilisé lorsque ses méthodes métier doivent être asynchrones ; il est invoqué sur réception d un message du client, en utilisant le service JMS de Java (Java Messaging Service). La version EJB 2.0 introduit la notion de localité du bean. La propriété Local ou Remote du bean est choisie lors de la création du bean. Le rôle principal du conteneur est de gérer les instances des différents beans. Suivant le cas, il prendra en charge un pool d instances (par exemple pour les beans sessions avec état). Le conteneur peut, de plus, proposer différents services aux beans. Le bean s exécute en fait dans un contexte définissant les différentes propriétés du client (son identité, les différents rôles qui lui sont attribués), et l état des services mis en œuvre. L infrastructure d accueil des composants EJB comprend également une entité appelée EJB server qui représente le logiciel support des communications et des services techniques nécessaires à l exécution du composant et à son accès par le réseau. Les deux principaux services développés dans le standard EJB 2.0 concernent la sécurité et les transactions. Un descripteur de déploiement est associé à un composant et permet de décrire ses caractéristiques Le Cycle de vie L architecture EJB dispose de services de cycle de vie. Dans les systèmes de load balancing, divers services de cycles de vie sont utilisés, comme le déploiement des applications, des contrats d exécutions qui leur sont associés (contraintes matérielles et logicielles) mais il est également possible de trouver des services d agrégation, de migration et de duplication. Dans le cas des EJB, le standard définit quatre rôles de cycle de vie principaux : 1. Le fournisseur de Bean (Bean Provider) crée le bean et fournit un fichier ejb-jar contenant le code du bean et son descripteur de déploiement. Ce descripteur contient entre autre la description des ressources externes nécessaires pour déployer le bean. 2. L assembleur d application regroupe plusieurs beans pour son application. 3. Le déployeur (Deployer) déploie les beans dans un environnement opérationnel (c està-dire sur un serveur EJB et un conteneur EJB). Il suit les instructions de l assembleur d application tout en respectant le descripteur de déploiement des beans. 4. Le fournisseur de serveur EJB et de conteneur EJB fournit la structure d accueil qui sera utilisée. Le standard n est pas très clair quant au rôle du serveur EJB qui semble confondu avec celui du conteneur.

43 2.5. LES STANDARDS Le Corba Component Model La réponse de l OMG aux limites rencontrées dans les modèles à objets est le CCM CORBA Component Model, modèle de composants qui servira de base au futur standard CORBA 3. La spécification de cette version du standard n est pas encore achevée. Cependant, le chapitre sur le modèle de composants a été finalisé à l OMG en janvier C est donc l un des plus jeunes modèles de composants mais aussi l un des plus prometteur. Pour permettre une compatibilité ascendante, l OMG a défini son modèle de composants comme une extension du modèle objet de CORBA 2. Les composants CORBA représentent donc une spécialisation des objets CORBA tels que nous les connaissons aujourd hui. Les applications visées par les composants CORBA sont des applications réalisées à partir de composants hétérogènes répartis. Le support d exécution est fourni par un conteneur (Container). Un conteneur est un support d exécution générique qui peut accueillir différents types de composants ayant des caractéristiques systèmes communes (en termes de persistance par exemple). Pour ne pas réduire les capacités d un site d exécution à un ensemble de conteneurs statiquement définis et pour ne pas instancier tous les conteneurs possibles sur un site, les conteneurs reposent sur des serveurs de conteneurs. Ces serveurs sont matérialisés sous la forme de processus du système d exploitation hôte et permettent d activer des conteneurs à la demande et selon les besoins. Ces conteneurs peuvent être utilisés pour une distribution de charge. Il est possible de découpler la construction d applications par composants de l initialisation et de la gestion des serveurs. Un conteneur peut créer un POA (Portable Object Adapter) et les intercepteurs pour activer et gèrer un composant. Les conteneurs peuvent être étendus pour implementer une distribution de charge générique sans changer le comportement des composants Le modèle CCM Le modèle de composant de CORBA (CCM) [OMG01] présente des récipients pour découpler la logique composante d application de la configuration, de l initialisation et d administration des serveurs. Dans le CCM, un récipient crée le POA et les intercepteurs exigés pour activer et commander un composant. Ce sont les mêmes mécanismes qui sont employés pour mettre en application les composants serveurs dans le service d équilibrage de charge de TAO [Gro00]. Lorsqu un conteneur vient d être défini comme un support d exécution générique, pour éviter de réduire les possibilités disponibles lors de l instanciation de composants, une entité appelée maison de composants (home) est utilisée. Une maison est un gestionnaire d instances de composants, s occupant principalement de leur cycle de vie. Les maisons de composants contiennent le code réifiant l instanciation des composants, ce qui apporte une certaine souplesse. En plus de permettre l utilisation d un même type de conteneurs avec différents types de composants, cette approche permet d automatiser le déploiement des applications. En effet, il est possible de choisir des sites d exécution à partir d un ensemble connu, puis d installer une application sur ces sites à partir d un poste d administration. Pour cela, en plus de fournir un environnement d exécution (un serveur de conteneurs), un site doit offrir un service de chargement de code. Il est ainsi possible de charger une implémentation de composant sur un site distant (ainsi que l implantation de sa maison associée). Une fois les conteneurs instanciés, les implantations de composants et de maisons chargées, les maisons et les composants instanciés, il ne reste plus qu à interconnecter les instances de composants entre elles

44 44 CHAPITRE 2. LES COMPOSANTS pour former l application. La connexion entre deux instances de composants se fait au travers de ports, les points de connexion. Pour que deux types de composants puissent être mis en relation, il est requis que ces deux types aient un port fourni et un port requis compatibles. Il existe deux modes de connexion entre les types de composants : un mode synchrone pour l invocation de méthodes et un mode asynchrone pour l utilisation d événements. Le modèle de composants CORBA offre une réponse à tous ces besoins Le cycle de vie Le CCM est un framework de composants de type serveur. Le CCM se décompose en deux niveaux : un niveau de base qui permet essentiellement de transformer en composant des objets CORBA. un niveau étendu qui ajoute de nombreuses fonctionnalités. Tout comme les EJB de Sun, auxquels correspond la version de base du CCM en Java, le framework CCM repose sur l utilisation de conteneurs pour héberger les instances de composants et faciliter leur déploiement. La spécification du framework CCM [OMG01] est découpée en quatre modèles couvrant le cycle de développement et de déploiement des applications à base de composants CORBA. Le modèle abstrait offre aux concepteurs le moyen d exprimer les interfaces (fournies et utilisées) et les propriétés d un type de composant. Pour cela, le langage OMG IDL a été étendu pour prendre en compte les nouveaux concepts introduits dans le CCM, essentiellement la prise en compte des interfaces multiples nommées ports Le modèle abstrait Le modèle abstrait permet aussi de définir les gestionnaires d instances de composants. Le modèle de programmation spécifie le langage CIDL (Component Implementation Definition Language) à utiliser pour définir la structure de l implantation d un type de composant, ainsi que certains de ses aspects non-fonctionnels (persistance, transactions, etc). L utilisation de ce langage est associée à un framework, nommé CIF (Component Implementation Framework), qui définit comment les parties fonctionnelles (programmées) et non-fonctionnelles (décrites en IDL / CIDL et générées) doivent coopérer. Il inclut aussi la manière dont l implantation d un composant interagit avec le conteneur Le modèle de déploiement Le modèle de déploiement définit un processus qui permet d installer une application sur différents sites d exécution de manière simple et automatique par l utilisation de packages de composants et de descripteurs XML OSD (Open Software Description). Le modèle d exécution définit l environnement d exécution des instances de composants. Le rôle principal des conteneurs est de masquer et prendre en charge les aspects non-fonctionnels des composants qu il n est alors plus nécessaire de programmer. Le déploiement utilise des propriétés sur l exécution des composants, mais aussi sur les propriétés de construction non fonctionnelles comme par exemple la sécurité. C est donc un pas de plus dans la gestion et la prise en compte des besoins des composants et, par extension, des applications.

45 2.5. LES STANDARDS Microsoft.NET L appellation.net de Microsoft regroupe un ensemble de produits de développement et d exécution pour applications réparties à base de composants permettant, en particulier, la programmation par réutilisation de services dans les Web Services. Les langages supportés (C++, VB.NET, C#) peuvent être compilés en un code intermédiaire MSIL (Microsoft Intermediate Language). Ce code intermédiaire est exécuté par le CLR (Common Language Runtime). Le WSDL (Web Service Definition Langage) est un format de représentation des interfaces de Service Web en XML. C est la représentation XML des langages IDL (OMG) ou MIDL (Microsoft) de description des interfaces. De plus le standard DCOM est l équivalent au niveau de la couche transport du protocole IIOP de CORBA pour Windows. La plateforme d exécution.net propose une évolution de COM+, basé sur COM, nommée.net remoting permettant la distribution de composants. En plus d agréger ces services, COM+ apporte de nouvelles capacités fonctionnelles comme les queued components, un mécanisme de gestion des événements et une possibilité de répartition de charge sur les applications créées. Cette répartition de charge peut s effectuer en fonction de plusieurs paramètres comme par exemple, la charge processeur, le nombre de threads actifs/inactifs, le taux d utilisation de la mémoire, etc. Les requêtes seront redirigées sur les différentes machines composant le système de manière transparente. En quelque sorte les capacités des différentes machines sont agrégées pour répondre aux montées en charge du système. D un point de vue composant, MTS (Microsoft Transaction Server) permet le développement, le déploiement et l exécution de composants répartis fonctionnant sous le contrôle d un conteneur. MTS offre également des services pour la prise en charge des transactions. Dans le cas de transactions réparties il est possible d utiliser MSMQ (Microsoft Message Queue Server) qui est un middleware de type Message Oriented Middleware qui prend en charge la communication asynchrone point à point entre applications. Le rôle premier.net est le modèle composant. Trois modèles de composants sont définis : Le Single Call est une instance du composant qui ne sert qu une seule requête. Ni l état du composant ni le contexte des clients ne sont gérés. Le Singleton Objects est une instance du composant qui peut servir plusieurs clients simultanément. L état du composant est partagé par les clients. Le Client Activated Objects est une instance du composant qui est activée pour chaque client (mode d activation très proche de celui d un composant COM+). Le contexte du client est géré entre ses différents appels. Un assemblage est un regroupement de types (classes, structures, énumérations, etc) et de ressources (images, sons, textes, etc) en un composant déployable. Généralement, un assemblage comporte les 4 éléments suivants : les méta-données qui décrivent l assemblage, les méta-données qui décrivent chacun des types contenus dans l assemblage, le code des types sous la forme de MSIL et les ressources. Cet assemblage peut se ramener à la notion de répartiton de charge et de déploiement d applications. En effet, les ressources peuvent être vues comme des propriétés des composants et des sites d exécutions pour les applications. Chaque composant possède ses propres propriétés d exécutions mais aussi de fonctionnements et d interactions avec le reste des composants de l assemblage.

46 46 CHAPITRE 2. LES COMPOSANTS 2.6 Conclusion Cet état de l art sur l assemblage de composants par contrats montre l ampleur et la complexité du domaine. L ensemble du cycle de vie de développement du logiciel est assez difficile à appréhender et les concepts sont loin de posséder une définition adoptée par tous, à commencer par celle fondatrice de composant. Les solutions techniques à base de composants sont en pleine émergence. Elles se trouvent à la convergence de techniques plus matures mais qui ont montré leurs limites comme les objets, dont les interfaces manquent de symétrie pour former des entités composables simplement. En ce sens, les ADL décrivent peu ou pas assez les architectures ouvertes et dynamiques. Par ailleurs, les langages de coordination nécessitent de lourds mécanismes d introspection pour fonctionner. Nombre de solutions techniques apparaissent s appuyant chacune sur une infrastructure se voulant standard mais qui, du fait de la diversité, s avère spécifique comme Java (EJB), CORBA (CCM) et.net. Elles s appuient souvent sur le concept de MOF (Meta Object Facility) qui permet la gestion des méta-données et autorise leur échange. Nous pouvons donner un point commun supplémentaire à ces trois standards. Nous pouvons assez facilement trouver des similitudes avec les systèmes de distribution de charge. Nous pouvons également confondre le déploiement d applications et le placement d applications. Lors de déploiements dynamiques, nous pouvons donner un équivalent à des déplacements ou migrations de composants. De plus, les composants ont, par leur construction, des propriétés à la fois sur leur exécution mais aussi sur leurs besoins matériels et logiciels. En définitive, ces trois standards permettent la création, le déploiement et la gestion d applications statiques ou dynamiques comme le ferait un système de répartition de charge. Il faut enfin ajouter que la prise en compte de propriétés, dans ces trois standards, à la fois lors du développement du composant, lors du déploiement et de l exécution est globalement équivalente à notre problématique de gestion des besoins applicatifs. Notre travail prend ici tout son sens puisque bien que similaire des trois standards sur le principe de la gestion des besoins applicatifs, il offre une plus grande liberté d expressivité et de déploiement au niveau des composants. Il ne fait pas seulement de la répartition de charge mais une allocation et une gestion des ressources en tenant compte de critères plus larges et plus expressifs au niveau matériel et applicatif comme nous le développons dans le chapitre suivant.

47 Chapitre 3 La gestion de ressources dans les systèmes répartis La gestion de ressources dans les systèmes répartis est un domaine de recherche important. Le but poursuivi est toujours le même : allouer et répartir au mieux par l utilisation de différentes politiques, procédures et services, les ressources physiques (capacités de traitements, de stockage ou autres périphériques) d un ensemble de machines par rapport à l exécution d une ou de plusieurs applications. Le principe de la gestion de ressources repose sur le fait que les entités physiques permettant l exécution, c est à dire les machines ou le parc de machines, ne peuvent pas être déplacées facilement et rapidement. Pour résoudre ce problème, la solution la plus communément admise est de réaliser une optimisation locale par un ordonnancement des tâches à effectuer sur la ou les machines cibles. Néanmoins, il est possible, lorsque l application et le système le permettent, de déplacer directement tout ou une partie de l application pour accélérer les traitements et les temps de réponses de l application. En effet, en déplacant une application sur un site d exécution plus rapide et/ou moins chargé, l utilisation des ressources peut alors être plus efficace donc plus optimale. Dans ce chapitre, nous présentons les diverses propriétés et politiques de gestion de ressources par la présentation de travaux significatifs dans ce domaine. Nous présentons également une partie importante de la gestion de ressources dont le principe initial s appuie sur la gestion de charge. Ce domaine est connexe au nôtre dans le sens où la problématique initiale est aussi applicable pour la gestion de ressources et le déploiement d un type applicatif à base de composants comme dans [FAS01]. 3.1 Les propriétés de la gestion de ressources Il existe diverses propriétés pour réaliser une gestion de ressources. Dans tous les cas, ces mécanismes doivent participer à l amélioration de l efficacité des applications. L efficacité est, à notre sens, une notion de temps de réponse d une application. La gestion de ressources doit globalement améliorer le temps de réponse afin que les traitements soient plus rapides. Par conséquent, le but est de réaliser une minimisation de la moyenne et de la variance des temps de chaque application s exécutant dans le système. En effet, si l on minimise la moyenne alors le temps de réponse d une application est globalement plus court. De même, si l on minimise la variance alors deux exécutions d une même application auront sensiblement le même temps de réponse. En combinant ces deux notions, nous pouvons en déduire que les ressources sont 47

48 48 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS mieux utilisées et satisfont mieux à la fois les besoins des applications et celles des utilsateurs. Le temps d attente est le temps passé par une entité d exécution à attendre une ressource. L efficacité de la gestion peut être mesurée également par la minimisation de la moyenne et celle de la variance du temps d attente. La mise en œuvre d une gestion de ressources est, elle même, consommatrice de ressources, ce qui est paradoxal. Naturellement cette gestion de ressources ne doit pas fortement pénaliser le système et/ou les applications. L efficacité d un tel mécanisme se mesure en fonction de l exécution des applications et donc du temps de réponse par rapport au système sans utilisation de ce mécanisme (et bien évidemment l échange de messages ainsi que l utilisation des ressources). Dans notre contexte d applications basées sur des composants de grain fin ou moyen, il semble évident qu un mécanisme peu gourmand en ressources est sans doute efficace, ce qui nous permet de déduire qu il vaut mieux utiliser des algorithmes simples. La gestion de ressources doit également répondre à un certain nombre de critères et de caractéristiques que nous énonçons ci-dessous : Le système de gestion des ressources doit être efficace afin d améliorer les performances locales et globales en équilibrant des charges au mieux pour éviter de monopoliser une ou des resources pour une seule application. Le système de gestion des ressources doit assurer une certaine stabilité d exécution des applications pour éviter le déplacement intempestif de celles-ci. Son comportement doit donc être suffisamment stable pour ne pas créer des instabilités lors de changements pouvant intervenir dans le système (ajouts, suppressions, pannes, etc). Le système de gestion de ressources doit pouvoir s adapter grâce à son extensibilité aussi bien à de petits ou grands systèmes le mettant en œuvre. Le système de gestion des ressources doit supporter une certaine tolérance aux fautes et/ou pannes pour éviter que le système soit déficient si l un de ses composants ne fonctionne plus ou de manière incorrecte. Le système de gestion des ressources doit être transparent pour l utilisateur, il ne doit pas gêner ou interférer de manière négative avec l exécution des applications. Le système de gestion des ressources doit supporter l hétérogénéité car généralement l ensemble des ressources d un réseau n est pas homogène. Son mécanisme doit permettre de manipuler de façon uniforme l ensemble des ressources. Ces différentes propriétés sont assez difficiles à mettre en œuvre toutes ensembles, ce qui complexifie la création d un système d allocation de ressources. Néanmoins, l utilisation de certaines de ces propriétés peut, sans doute, mener à la création d un système assez performant. En revanche, il semble intéressant de se pencher sur les principes mêmes de la gestion de ressources. 3.2 Les algorithmes et leurs principes Un système d allocation de ressources dans un système réparti repose, d une manière générale, sur une prise de décision qui permettra de placer ou déplacer une ou plusieurs entités pour augmenter les performances globales du système visé. Les différents modules informationnels permettent de bâtir une connaissance de l état du système. La décision prise est le résultat de l intégration des différentes informations modulée ou non par la politique choisie. La base d un système d allocation de ressources dans un système réparti se situe au niveau de la gestion de la charge. Nous détaillons ci-après ces mécanismes et les différentes

49 3.2. LES ALGORITHMES ET LEURS PRINCIPES 49 politiques associées Les composantes de l équilibrage de charge La vaste majorité des algorithmes de répartition de charge dynamique utilisent quatre sortes de modules distincts dont les tâches sont clairement définies : 1. Un module d information qui définit les types d information ou les indicateurs de charge du noeud (charge, longueur des différentes files, historiques) collectés et la manière dont sont acquises ces informations (coopérative, non-coopérative, distribuée, centralisée, politique sur demande, politique périodique, politique de changement d état). 2. Un module de transfert, où l objet (d une manière générale) est transféré d un noeud à un autre. Un seuil peut être utilisé pour limiter le choix des objets à transférer ou ceux à prendre en compte. Un noeud peut décider d être émetteur ou receveur de charge. 3. Un module de localisation qui localise le noeud où l objet doit être déplacé. Plusieurs solutions sont envisageables : aléatoire, basée sur des informations distantes collectées ou sur les voisins directs. 4. Un module de négociation qui interagit avec les modules des autres noeuds par des messages (enchères, votes, contrats, charge, acceptation, refus). Ces quatre sortes de modules participent à l efficacité du système d équilibrage de charge. Ces modules peuvent utiliser différentes politiques de gestion de charge pour leurs fonctionnements Les politiques de gestion de charge Elles donnent les méthodes et les moyens pour optimiser les performances globales du système. Il faut, néanmoins, différencier le partage de charge (pour éviter la surcharge de certains sites du réseau) et l équilibrage de charge (pour essayer de maintenir une charge identique sur chaque site). Nous donnons ci-après les différences entre partage et équilibrage. Il est communément admis que, sur chaque site du réseau, il existe un critère de charge disponible qui représente l état du site. Le partage de charge est souvent mis en relation avec le choix d un seuil à partir duquel un placement ou un déplacement est envisagé pour pallier le problème de passage d un état de donneur de charge à celui de demandeur de charge. La réponse donnée par certains auteurs est l utilisation de deux seuils comme [Zho88, Fol92]. Il y a donc un seuil de surcharge au delà duquel le site doit exporter de la charge et un seuil de souscharge en deçà duquel le site est capable d importer de la charge. Le problème réside dans la définition de ces seuils. Cette définition peut être soit statique (de manière empirique), soit dynamique en utilisant un calcul de la charge moyenne du système. La méthode statique est la plus simple, mais ne permet pas de gérer des variations du système, a contrario de la méthode dynamique, qui elle, peut s adapter facilement au prix d une lourdeur nettement plus importante. Il convient donc de restreindre le calcul de la moyenne à un voisinage. L équilibrage de charge doit maintenir, dans son principe, une charge identique sur l ensemble des sites constituant le réseau. Nous pouvons raisonnablement supposer que la

50 50 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS charge de chaque site doit être similaire à la charge moyenne du système. Mais les traitements nécessaires pour équilibrer la charge sont généralement beaucoup plus importants et coûteux que ceux induits par le placement et/ou par le déplacement des entités au cours de leur exécution. Dans les deux cas, il est nécessaire de créer et de définir d autres politiques complémentaires pour la récolte, la distribution et la localisation des informations qui seront utilisées comme critères lors de la prise de décision de placement et/ou de déploiement. Cette démarche est très utile si l on souhaite adjoindre à la gestion de charge une allocation de ressources La politique d information Cette politique permet de spécifier les informations qui seront utilisées pour déterminer d autres critères utiles lors du processus décisionnel. En ce sens, ces informations permettront de définir une vue plus ou moins précise des états locaux de chaque site ainsi que la politique de diffusion de ces informations aux autres sites. Chaque site pourra alors disposer d une vision globale du système. Plus le nombre d informations sera grand, plus l image globale du système sera précise. A l inverse, la représentation de l état global du système, sans information, sera la moins précise mais moins coûteuse à élaborer. L objectif est de déterminer les informations susceptibles de décrire au mieux l état d un site à chaque instant. Dans la littérature, la plupart des algorithmes agrègent en un seul critère les paramètres décrivant l état local. Souvent, la charge est considérée comme le reflet de la disponibilité du processeur. Les calculs sont réalisés soit à partir de la file d attente des instructions du processeur (plus la file d attente est longue, plus le processeur est chargé), soit grâce à l utilisation de sondes qui calculent le temps écoulé, entre le dernier moment où le processeur leur a donné la main et la fois suivante (plus le temps écoulé entre ces deux instants est long, plus le processeur est chargé, car de nombreux autres processus sont en concurrence). L inconvénient de ces deux calculs de charge processeur, est la non prise en compte des machines hétérogènes. Dans ce cas, la charge processeur ne peut pas être comparée à celle des autres processeurs. Il est donc nécessaire de transformer les résultats par rapport aux puissances relatives de chaque processeur. Il existe d autres informations pouvant être prises en compte pour calculer la charge d un site comme par exemple : le taux de réussite ou d échec de lecture dans la mémoire cache du processeur. Même s il n y a pas de liaison directe entre la charge du processeur et les accès à son cache, cette information peut, malgré tout, constituer un bon indicateur de l activité du processeur. la taille mémoire peut être utilisée également comme critère comme dans [SS84]. Plus une machine dispose de mémoire, moins elle est obligée d utiliser la pagination sur disque qui a pour effet de ralentir le système. Il faut noter qu il n y a, sans doute, pas forcément de corrélation directe entre la taille mémoire d un processus et l utilisation du processeur. la charge réseau qui, lorsqu il est surchargé, peut ralentir le système. Ce cas est souvent présent dans les applications réparties synchrones. Il est assez délicat de combiner les informations de la charge du processeur avec celle de la charge du réseau, du fait des ordres de grandeur différents et des phénomènes non forcément liés entre charge processeur et charge réseau.

51 3.2. LES ALGORITHMES ET LEURS PRINCIPES 51 l ensemble des entrées/sorties peut être utilisé pour déterminer la charge. La longueur de la file d attente des entrées/sorties combinée à celle du processeur, peut traduire le nombre de processus qui utilisent et qui utiliseront le processeur à plus ou moins court terme. Cette notion peut être critique, dans les accès aux réseaux de commnications La distribution des informations Lorsque l estimation de la charge de chaque site est réalisée, il convient de la diffuser pour donner à chacun une image assez globale du système. Cette image devra permettre une prise de décision en rapport avec l état du système. La collecte des informations peut être représentée par quatre couples de propriétés caractérisant chacune une approche différente : distribuée/centralisée : une collecte centralisée permet une prise de décision optimale mais est peu résistante aux pannes et peu propice à la mise à grande échelle du système car les différentes informations risquent d être obsolètes si le nombre de sites est grand (durée d envoi et reception de messages, congestion...). Une collecte distribuée permet de résoudre le problème de la résistance aux pannes mais peut induire des incohérences dans les décisions. directe/indirecte : la collecte peut se réaliser directement sur le site concerné ou via une autre machine. Les informations doivent être valides. D une manière générale on associe, de ce fait, une date de validité aux informations, pour éviter l envoi d informations désuètes comme le décrit [BS85]. totale/partielle : une collecte totale est très liée à la taille du système mais elle est peu extensible. La collecte partielle nécessite la création de sous-ensembles dans le système, que l on appelle voisinage (non obligatoirement topologique). à la demande/périodique : l acquisition des informations à la demande permet de réduire le nombre des communications distantes et généralement coûteuses entre les sites du système. La collecte peut parfois être longue. Une collecte périodique implique la détermination d une période optimale. Cette période doit éviter de surcharger le système et permettre l obtention d informations fiables. Le système pouvant évoluer dans le temps, la période optimale doit, elle aussi, suivre l évolution du régime du système. Généralement, une valeur moyenne des conditions adaptées au système est déterminée de manière empirique tout en évitant l envoi synchronisé des informations sur l ensemble des machines du système au même moment La politique de localisation Cette politique détermine le placement d une entité par rapport à la localisation et au temps. Il existe plusieurs politiques qui réalisent cette fonction : le placement probabiliste adaptif est assez proche d un système aléatoire. Chaque site recèle, a priori, une probabilité différente d être sélectionné. Chaque site dispose de la liste des sites du système, et à chaque site est associé une probabilité. La probabilité varie en fonction du temps et des tentatives précédentes. L acceptation augmente la probabilité alors que le refus la diminue. Les performances sont bonnes si la charge varie peu au cours du temps. le placement autonome repose sur le principe qu un site surchargé, sélectionne un autre site du système pour lui transférer son excédent de charge. La charge est alors soit

52 52 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS refusée soit retransmise à un autre site. C est un placement aléatoire qui dispose de performances assez bonnes, car il est extensible et favorise la dispersion, mais devient assez coûteux lors de brusques montées en charge. le placement coopératif utilise une représentation globale ou partielle du système. Il détecte les optimisations possibles à réaliser sur l environnement d exécution (comme une grande différence de charge entre deux sites, ou l utilisation d une ressource distante). Suivant les informations collectées, une décision sera prise pour placer et/ou déplacer une entité. La décision peut être initiée par : 1. le site lui-même, en utilisant ses propres informations et celle du ou des autres sites choisis. 2. un autre site du système qui, au regard de ses propres informations, demande qu on lui envoie l excédent de charge du site surchargé. 3. par l entité elle-même, lors de son lancement ou par l utilisation d un mécanisme d observation de son comportement. Les informations de ces observations conduiront à une prise de décision sur son placement et/ou son déplacement. Les différentes politiques et critères nécessaires pour la gestion de ressources impliquent la création de systèmes plus facilement administrables. La quantité croissante d informations et de données à gèrer implique une redéfinition obligatoire de la notion d administration. Cette dernière devient alors un concept complexe au regard des applications disponibles aujourd hui. 3.3 L administration Il existe deux domaines d études connexes au nôtre : l administration au niveau matériel et l administration au niveau de l exécution L administration d infrastructure De nombreux outils sont déjà disponibles pour gérer le matériel comme les réseaux, les ordinateurs et les périphériques ainsi que tout ce qui concerne la gestion d un parc informatisé. Tout nouvel ajout, modification et suppression d une composante nécessite une prise en compte par le ou les administrateurs. Il existe deux protocoles largement utilisés qui permettent de gérer ces évolutions matérielles : SNMP Simple Network Management Protocol et CMIP Common Management Information Protocol [Sta93]. Dans les systèmes distribués ouverts, les protocoles tels que SNMP et CMIP qui utilisent un paradigme d agent-gestionnaire (centralisé au plan du gestionnaire) ne suffisent pas. Tout d abord, la quantité de données opérationnelles qui doivent être surveillées et traitées en temps réel augmente considérablement. Ceci peut poser un problème de congestion au plan du gestionnaire. La complexité croissante des systèmes implique la nécessité d observer une vaste quantité de paramètres et de fournir des fonctionnalités évolutives. Le traitement centralisé ne convient donc plus et le gestionnaire doit pouvoir déléguer son travail à des agents et/ou à d autres gestionnaires. De plus, l administration doit également se faire au niveau de la sécurité pour prendre en compte les restrictions d accès et d authentification des profils des utilisateurs. De nombreux logiciels commerciaux tentent d apporter une solution à ces problèmes comme NIS+ [Mic91] de SUN Microsystems, ou encore Systems Management Server (SMS)

53 3.4. LA MOBILITÉ DES OBJETS 53 de Microsoft. La tendance actuelle s oriente vers l administration au niveau des applications pour une meilleure gestion des installations de logiciels, de licences et de droit d accès utilisateur. Naturellement, l évolution rapide et complexe de l informatique engendre de nouveaux challenges pour l administrateur. En effet, avec le poids croissant de l Internet, gérer des applications devient de plus en plus compliqué. Le modèle Client/Serveur permet de découper les applications en objets plus ou moins indépendants qui peuvent se trouver sur des systèmes différents. Cette avancée technologique implique une totale redéfinition du rôle de l administrateur ainsi qu une masse, trop souvent excessive, de contraintes à prendre en compte. Ces contraintes sont souvent liées au trafic Internet croissant et aux problèmes de sécurité imposés par l ouverture et la banalisation des autoroutes de l information. Afin de simplifier et d obtenir une administration globale et standardisée, des projets sont menés dans des sociétés commerciales (Computer Associates Unicenter TNG [CA99], TIVOLI d IBM [IBM99], Visual San d EMC 2 [EMC03], EMEA d Altiris [Alt03]), des laboratoires de recherche et des groupes de recherche comme le DMTF (Desktop Management Task Force) [DMT98] L administration d exécution NetSolve [Pro98b] est un environnement logiciel qui permet d unifier différentes machines et librairies logicielles en un service facile d accès. Il autorise l agrégation des ressources matérielles et logicielles de différentes machines connectées par un réseau et permet de combiner la puissance de toutes ces machines à travers une interface cliente. Il utilise le paradigme Client-Agent-Serveur pour permettre d utiliser au mieux les ressources disponibles tout en cachant la complexité inhérente du système ainsi composé. On peut également citer le projet GLOBUS [Pro98a] qui est un ensemble d éléments qui implémentent des services de base pour la sécurité, l administration de ressources, de communications, etc. Ces deux plateformes tendent à repondre aux exigences de l informatique d aujourd hui, à savoir une solution aux problèmes de l administration automatique. De plus, les utilisateurs, qui exigent une qualité de service de plus en plus élevée, forcent la nécessité d une étude très poussée du problème comme par exemple la gestion des ressources dans ce nouveau type d environnement. Il en résulte que tout nouvel ajout, modification ou suppression d une composante logicielle ou système doit être prise en compte par le ou les administrateurs pour satisfaire au mieux la demande. L étude de l allocation de certaines ressources à déjà été réalisée dans [Gos91, Dic92, Fol96, CHPB96, Bon98]. 3.4 La mobilité des objets La mobilité des objets nous permet, grâce au placement et à la migration de composants, de distribuer la charge des machines, d optimiser les performances des applications et d obtenir une qualité de service optimale. Le problème qui se pose alors est le suivant : quelle technique doit être utilisée pour obtenir le meilleur temps d exécution pour les applications? Il n y a pas de solution miracle qui satisfasse les besoins de toutes les applications. Il en va de même pour les paramètres des algorithmes de décision sur lesquels reposent les choix de mobilité. La raison est que nous ne pouvons considérer qu un seul type d application et qu il n y a pas de certitude quant au comportement de ces applications. Cependant nous pouvons déduire de la mobilité des objets certains principes de base :

54 54 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS 1. Il est impératif d obtenir une continuité dans le service rendu. 2. Il est indispensable de pouvoir administrer de nouveaux ajouts ou retraits dans le système. 3. La tolérance aux fautes doit être prise en compte. Cette mobilité est, par exemple, utilisée dans plusieurs travaux comme ceux de [Ber99, CG96] pour les agents mobiles. Les agents mobiles sont des programmes autonomes dans les réseaux jouant les rôles de représentants d utilisateurs ou d autres entités. Ils disposent de certains avantages comme par exemple : Une baisse sensible du trafic réseau permettant un désengorgement des liens de communications. Une plus grande rapidité d exécution des applications grâce à la délégation d agents sur des tâches telles que la gestion de ressources. Une possibilité de recherche intelligente d informations sur un réseau. Une interaction asynchrone avec les autres agents et une possibilité de migrer vers d autres noeuds tout en restant autonomes. Les avantages décrits sont conformes aux principes de base de la mobilité des objets. Ceci est à rapprocher des principes d une allocation et une optimisation des ressources. De plus, la faculté de mobilité des agents permet une grande lattitude de leur placement et/ou leur déplacement Le placement Le placement consiste à affecter une application ou un composant à un site pour son exécution. La mise en œuvre du placement est simple et peu coûteuse en terme de temps machine. Il semble préférable de placer correctement une application ou un composant au plus tôt pour éviter d avoir recours à la migration, plus coûteuse en terme de temps machine. L ordonnancement statique peut être utilisé pour le placement initial dans le cas où les informations sont connues au départ, c est-à-dire lorsque l on a un graphe de précédence ou de communication prévisible entre tâches. Le placement initial peut également utiliser la localisation dynamique [Tac97] et le service de courtage [OMG98, ISO96]. Le placement initial est la base de l allocation de ressources La migration Nous définissons la migration comme la possibilité de déplacer une entité, lors de son exécution, entre deux noeuds distincts. La souplesse inhérente de la migration pose le problème du surcoût engendré par celle-ci. La migration peut s avérer être impossible à effectuer si l entité réalise des accès à des ressources indisponibles sur les autres noeuds. La migration nécessite : 1. l arrêt de l entité 2. la sauvegarde de l état de l entité avant la migration. 3. le transfert de l entité vers le nouvel emplacement. 4. la création d une nouvelle instance de l entité. 5. la restauration de l état de l entité avant la migration. 6. la reprise de l exécution de l entité

55 3.4. LA MOBILITÉ DES OBJETS 55 Le coût induit par la migration et son impact sur les performances sont étudiés par [LO86, HBD95, BSW93]. Dans la majorité de ces études, nous remarquons que le surcoût engendré par rapport à un placement simple peut être jusqu à quatre fois supérieur et que les processus qui profitent le plus de la migration sont ceux de gros grain. Cela revient à dire qu ils évoluent très peu dans un laps de temps assez long. La migration d objet est facilitée par la nature même des objets [Pet97]. L état est clairement défini par les valeurs de l ensemble des attributs déclarés dans la classe d un objet. La migration de composants est également possible. La différence entre objets et serveurs est leur durée de vie qui doit être assez longue pour un serveur d application alors qu elle est plus petite pour un composant. Il est néanmoins possible d utiliser un serveur d applications à base de composants comme c est le cas dans [FAS01] où un service de déploiement et de placement EJB est mis en œuvre. Ce système donne de bons résultats lors d utilisations intensives d applications. En effet, le coût de la migration et du redéploiement est alors amorti par la forte utilisation des applications. En résumé, l objectif de la migration est d optimiser l utilisation des ressources réparties en cachant aux applications la répartition et la décision prise par le système La duplication La duplication de composants offre de nombreuses possibilités dans le placement et la gestion de ressources où il est intéressant de disposer des mêmes ressources sur différents sites. La duplication permet de multiplier les ressources logicielles. Considérons le cas d un serveur dont le temps de traitement pour une requête est important. La multiplication du nombre de requêtes émises par les clients peut dépasser ses capacités de traitement. Ceci allonge la file des requêtes en attente de traitement et ralentit le temps de réponse des requêtes. La duplication de ce serveur, sur un autre site, et le partage des invocations entre les deux instances de ce même service peut être la solution. Cependant, ceci pose quelques difficultés : la répartition des requêtes entre plusieurs serveurs, la cohérence des états des serveurs, le nombre optimum de duplications pour la meilleure consommation de ressources et la tolérance aux fautes. Malgré tout, pouvoir disposer de plusieurs serveurs sur des sites différents permet de mieux répartir la charge, tout en choisissant le duplicata le mieux adapté pour chaque client. Lorsqu un serveur est surchargé, il demande la création d une nouvelle instance dans le groupe, puis sort du groupe. Lorsque sa charge atteint un seuil suffisamment bas, il peut, soit réintégrer le groupe, soit terminer son travail puis s arrêter. L étude de [Pre96] est réalisée avec l hypothèse de serveurs ne traitant que des requêtes indépendantes, sans maintien d état. Elle ne présente pas de performances. Un modèle proposé par Andrew Tanenbaum [KBTJ92] a pour but d améliorer les performances des applications parallèles en utilisant la duplication d objets. Ce modèle est basé sur la mémoire partagée. Une des particularités de ce modèle est que l accès aux serveurs en lecture ne doit se faire qu en local (si possible) sur le même site, les accès en écriture se faisant sur l objet original. Le nombre de duplicatas est fixé par le rapport du nombre de requêtes en lecture et en écriture. Une fonction de gestion des répliquats dans un système de répartition de charge dynamique est réalisée par [Put03]. Le partage de charge sur les répliquats est réalisé soit par application lors du placement, soit par session pour toute la durée d exécution, soit dynamiquement à chaque requête. Dans un contexte de migration, on trouve des situations où il est difficile de déterminer

56 56 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS un site d accueil lorsqu une migration est souhaitable. Il existe en effet des phénomènes de ping-pong, un serveur migrant constamment entre deux sites. Ce phénomène induit des chutes importantes de performances, liées au coût de la migration. La duplication permet, dans ce cas, de placer deux serveurs sur les deux sites incriminés, évitant ainsi les migrations, tout en satisfaisant la recherche de performances. 3.5 Des exemples de systèmes de gestion de ressources La gestion de domaine au niveau d un groupe de machines et la gestion de ressources dans les systèmes à objets sont deux domaines englobant notre travail. Nous présentons dans ce paragraphe quelques exemples de systèmes d allocation de ressources ANTS Load Balancing System Le système d équilibrage de charge ANTS [Ost01] est un système qui permet aux différentes tâches d être exécutées sur des ordinateurs reliés par un réseau (par exemple un cluster Beowulf). Le noeud le plus adapté, (au moment de l exécution) pour un travail donné, sera choisi pour exécuter la tâche. C est une approche différente de celle des systèmes traditionnels de files d attentes. Une tâche n est pas mise en attente dans une file, elle est exécutée immédiatement sur n importe quel noeud approprié (pour le type donné de la tâche) qui peut être trouvé. Cette fonctionalité rend le noeud approprié à l exécution d un grand nombre de petits travaux, tels que des compilateurs. Un système traditionnel de file d attente prend souvent trop de temps d exécution pour permettre aux tâches telles que les compilations à grande échelle de gagner beaucoup en rapidité CATScan Le projet CATScan [ZC01] s applique aux systèmes embarqués gérés en réseau. CATScan adopte une nouvelle modélisation des systèmes embarqués basée sur des contraintes et sur les transitions de phase pour le matériel et le logiciel s exécutant dessus. Cette caractérisation du système, qui est en général disponible dans la phase de conception, sera représentée sous une forme compacte appelée le diagramme de phase et stockée dans un environnement d exécution pour prévoir les états courants du système et prendre des décisions en temps réel en rapport à ces phases. CATScan permet la reconfiguration du système, son auto-stabilisation ainsi que la tolérance aux fautes. Les différentes contraintes exprimées peuvent être dynamiquement ajoutées et/ou enlevées. Quand la configuration de système doit être changée, en réponse aux changements environnementaux, une nouvelle configuration sera calculée en utilisant des modèles dynamiques et/ou en calculant, pour la tolérance aux fautes, la meilleure configuration de contraintes pour remplacer des composants défaillants afin de compenser leurs fonctions par celles de leurs voisins. CATScan utilise CORBA pour les communications sur le réseau FarGo FarGo [HBSG99] est un middleware léger et un environnement de programmation pour le développement et le déploiement des applications réparties. Il peut être utilisé avec une large palette de rêglages. Les services principaux fournis par FarGo aux programmeurs qui

57 3.5. DES EXEMPLES DE SYSTÈMES DE GESTION DE RESSOURCES 57 construisent de telles applications sont la mobilité et le cheminement composant, la capacité de programmer des rapports de localisation entre les composants ainsi qu un service de surveillance intégré qui permet de concevoir les politiques de relocalisation basées sur des mesures d utilisation d exécution et de ressources. Une grande importance a été accordée à la facilité de programmation. Ce modèle de programmation est très proche de la syntaxe et de la sémantique Java. Sa maîtrise et son emploi sont faciles car il laisse la possibilité d utiliser les APIs avancées de Java à l intérieur du système FarGo YALB (Yet Another Loadbalancing System) Le système YALB est un système d équilibrage de charge pour les environnements hétérogènes de postes de travail [Pro98c]. Ce Système est composé d un Load-Daemon qui calcule la charge locale d un noeud (basé sur la queue de processus du processeur et le facteur de vitesse de la machine) et qui l envoie à tous autres noeuds du système. Il exécute également des contrôles d autentifications (semblables à RFC 931). Le Load-Manager rassemble les charges locales de tous les noeuds et choisit le noeud le plus rapide pour l exécution d une tâche. Le Rexec-Manager exécute des travaux à distance pour un client afin d optimiser l exécution de l application Condor flock Un flock regroupe un ensemble de pools de stations de travail [EDJB + 93]. Chaque pool utilise Condor pour équilibrer la charge en interne. On distingue 4 composants qui sont la Machine Globale, le Service d exécution distante, le Collecteur d information et le Négociateur. La machine globale représente dans chaque pool les autres pools et récupère les informations de charge des autres pools. Ces informations sont alors envoyées au collecteur d information. En fonction de ces informations, le négociateur décide ou non d envoyer des tâches, via la machine globale, dans un autre pool. La machine globale ne joue que le rôle d intermédiaire pour contacter la station d exécution finale de la tâche. Condor peut utiliser, à l aide d un langage de correspondance et d opérateurs logiques, des contraintes sur les tâches à exécuter ou sur les utilisateurs ou toutes autres informations pouvant être utiles pour l équilibrage de charge. Par exemple, le type de la machine désirée pour l exécution d une tâche peut être spécifié en terme de processeur, de système d exploitation, de capacité disque dur, etc. Mais des contraintes liées au temps, à l heure et aux groupes des machines et utilisateurs pouvant accéder aux ressources peut aussi être pris en compte. La description du langage de contraintes de Condor flock est réalisé dans [RLS98] Utopia multi clusters Utopia [ZWZD93] est basé sur les expériences de Ferrari et Zhou [ZF87] qui utilisent des valeurs d indicateurs, des seuils et les mesurent par simulation des performances des algorithmes de placement. Ce système répartit la charge des machines à l intérieur d un groupe. Chaque groupe a une machine maître qui récupère toutes les informations des machines membres (charge, mémoire, activité disque) et les envoie périodiquement aux machines du groupe. En plus des groupes physiques, qui sont basés sur des emplacements physiques de réseaux, des groupes virtuels qui dissocient des localisations physiques peuvent être créés. Chaque utilisateur tient à jour une liste des commandes qui sont susceptibles d être placées à distance, avec

58 58 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS les informations nécessaires au placement (processeur, disque, mémoire, système d exploitation). Il y a également une liste globale définie par l administrateur du système, contenant les commandes les plus gourmandes et éventuellement surchargées par une liste d utilisateurs Bellerophon L approche décrite dans [Dic92] consiste en un équilibrage de charge dynamique, au niveau système, indépendant de la topologie et permettant d éviter les gros déséquilibres de charge. Le modèle objet présenté est délibérément simple, il assure que la stratégie proposée soit largement applicable. Le modèle du processeur retient deux types d hétérogénéité : au niveau de l architecture, deux processeurs peuvent avoir des jeux d instructions différents. Pour pallier ce problème, il est possible d utiliser un méta-langage, qui pourra être interprété ou compilé sur chacun des processeurs. au niveau des ressources matérielles, deux processeurs peuvent avoir des tailles de mémoire distinctes, des vitesses d horloge différentes et d autres différences sur bien d autres aspects du matériel. Ces différences doivent être prises en compte lors des choix de déplacements. La méthode décrite, ne nécessite pas de propriété de diffusion au niveau du réseau, mais seulement des communications point-à-point. Les hypothèses faites dans le domaine des processus ne sont pas satisfaisantes dans le cadre des applications objets. En effet, à un instant donné, il y a une multitude d objets qui forment un certain nombre d applications indépendantes. Bien qu indépendantes, ces applications se partagent certains des objets présents. Le coût d une application est directement en relation avec la distribution des objets qui la composent. L algorithme d équilibrage de charge proposé réalise les tâches suivantes : 1. Il mesure la charge locale de chaque noeud, 2. Il compare la charge de différents noeuds, 3. Il calcule un moyen de rectifier les déséquilibres, 4. Il sélectionne les objets sujets à déplacement, 5. Il réalise le transfert. Cette étude s articule plus particulièrement autour des trois points suivants : l utilisation de plusieurs mesures locales, la restriction du domaine de comparaison à un sous-ensemble (budy) et la détermination de clump d objets (bouquet d objets) candidats au transfert. L un des problèmes majeurs, dans l équilibrage de charge basé sur les objets, est de trouver un ensemble d objets (clump) à déplacer pour équilibrer la charge. En effet, il faut construire ces ensembles pour obtenir une granularité qui soit en relation avec le coût de l opération de migration. Il faut s assurer que les objets regroupés puis déplacés ne vont pas réduire les performances du système en engendrant des surcoûts de communication. L auteur propose de calculer un ratio entre le nombre de communications réalisées à l intérieur du clump et le nombre de communications qui franchissent la frontière du clump (communication depuis l extérieur ou vers l extérieur). Ce ratio peut être vu comme un coefficient de cohésion du clump. Le système Bellerophon introduit la notion de «colocators» et de «contralocators». Deux objets qui contiennent un colocator, l un pour l autre, doivent être toujours sur le même site. Par opposition, deux objets possédant un contralocator, l un pour l autre, ne peuvent pas être sur le même site.

59 3.6. CONCLUSION Computational Field Model (CFM) Le «Computational Field Model» [Tok90] est le résultat d une analogie entre les forces d interactions d un espace physique réel et l utilisation de ressources dans un environnement informatique. Les unes comme les autres peuvent être modélisées par des attractions et des répulsions. Le principe du CFM est d associer, à chaque consommation de ressource, une force d attraction ou de répulsion. Ces forces permettent de calculer, pour chacun des objets du système, sa position d équilibre. En discrétisant les résultats, il est possible d en déduire un placement. Le CFM sert aussi de base à des travaux sur la tolérance aux fautes dans les systèmes distribués à grande échelle comme dans [Ueh97]. Le système Muse a été développé, sur ce principe, dans les laboratoires Sony. Les informations utilisées sont les débits de communication et l activité des objets. Ces travaux permettent de définir une métrique pour l espace dans lequel évoluent les objets. 3.6 Conclusion Nous avons exposé les notions de gestion de ressources, au niveau de l équilibrage de charge des processus, des objets, des composants et des agents. Les études se sont tournées vers une gestion des systèmes à objets et composants répartis, qui reprennent les caractéristiques de l équilibrage de charge des processus (efficacité, stabilité, extensibilité, transparence, tolérance aux fautes). Pour permettre une meilleure gestion des ressources, l utilisation de la mobilité des objets et des composants à été prise en compte (agent mobile, placement, migration, duplication). Les différents exemples d équilibrage de charge nous montrent que de nombreux systèmes existent mais ne répondent pas tous et pas totalement au problème du déploiement dynamique d applications et d utilisation des propriétés des descripteurs de déploiement. Nous désirons optimiser le déploiement et le placement dynamique des applications. Pour cela, il nous semble judicieux de modéliser notre problème pour pouvoir, le cas échéant, apporter des réponses à notre problématique. Notre système de gestion de ressources à base de composants doit donc s appuyer sur un fondement et un modèle mathématique. Nous choisissons de modéliser notre problème par la théorie des graphes pour nous permettre de trouver et créer les algorithmes qui répondrons à notre problématique de déploiement et de placement dynamique lors de notre allocation dynamique de ressources.

60 60 CHAPITRE 3. LA GESTION DE RESSOURCES DANS LES SYSTÈMES RÉPARTIS

61 Chapitre 4 La modélisation par graphes 4.1 Les graphes appliqués aux systèmes distribués La théorie des graphes est l une des réponses apportées à la modélisation des systèmes distribués. De nombreux autres outils sont également disponibles pour permettre la modélisation comme par exemple les mathématiques discrètes, l algorithmique et l optimisation combinatoire. Si leurs frontières communes sont assez floues, en revanche, les techniques et les outils que l on y trouve couvrent un champ très vaste et sont utilisés dans de nombreux domaines d application. Par exemple, les réseaux de communication (réseaux d interconnexion de processeurs ou réseaux de télécommunication) sont souvent modélisés par des graphes ou leurs généralisations (hypergraphes, graphes valués). Notons que beaucoup d aspects algorithmiques ne sont pas spécifiques à la théorie des graphes. Certains algorithmes utilisent des principes généraux (partitionnement, structures de données, etc). Un certain nombre d outils issus de la recherche opérationnelle comme la programmation convexe (programmation linéaire, programmation semi-définie positive), les techniques d arrondi et de résolution de problèmes en nombres entiers ou encore des heuristiques tels que le recuit simulé [KGV83], les algorithmes de recherche tabou [Glo86], les algorithmes génétiques [Hol75] sont parfois aussi utilisées dans les systèmes distribués. Dans ces systèmes, le but recherché est aussi le même : modéliser afin d optimiser le fonctionnement des ressources disponibles ainsi que l exécution. Il faut, malgré tout, s interroger sur les fondements de ce besoin d optimisation Pourquoi optimiser? Dans le domaine des systèmes informatiques, de nombreuses études montrent que dans le cadre d une utilisation standard, valable pour la grande majorité des utilisateurs, l utilisation des ressources est faible. Il y a là une forte variance de la consommation des ressources. Cela signifie qu une machine n utilise l ensemble de ses capacités de traitement que peu souvent, même s il existe parfois des pics d utilisation intensive. Nous pouvons donc considérer que, dans une vaste proportion des machines existantes, les ressources sont mal exploitées et/ou sous exploitées. L optimisation trouve ici sa place pour permettre aux applications et aux utilisateurs de mieux utiliser les ressources disponibles. Par exemple, il n est pas rare de rencontrer des applications et/ou des composants qui sont en attente de traitement, car ils n utilisent qu une machine mono-processeur, alors qu il existe d autres machines non utilisées pouvant également effectuer leurs traitements. Si l on 61

62 62 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES prend le problème d un point de vue réseau, on constate que lorsque les capacités maximales du réseau sont atteintes, les capacités de traitement du processeur sont encore largement disponibles. Nous pouvons citer de nombreux autres exemples comme la mémoire virtuelle qui oblige le processeur à gérer les entrées/sorties locales ou distantes pour compenser le manque de mémoire vive. Tous ces états d attente du processeur engendrent des pertes de cycles de traitements. Nous évoquons ici, le paradoxe de l informatique moderne où la montée en puissance du traitement des processeurs implique que celui-ci passe son temps à attendre des instructions, les données et naturellement les demandes de traitement. Pour expliciter cela d une manière humoristique, le processeur ne fait presque jamais rien, il ne fait qu attendre mais il le fait de plus en plus rapidement. Au vu de toutes ces raisons, il est primordial d optimiser les traitements des machines pour utiliser au mieux leurs capacités et ainsi réduire le nombre et la durée d inactivité des processeurs et de l ensemble des autres composants des machines. Ceci aura comme deuxième conséquence un accroissement notable de la réactivité des applications qui seront exécutées. Le premier pas vers l optimisation est la modélisation du système. Généralement, ces modélisations nécessitent l utilisation d outils mathématiques issus de la théorie des graphes. Nous rappelons dans le paragraphe suivant les notions de base de cette théorie que nous explicitons par des exemples concrets Préambule sur les graphes Nous rappelons qu un graphe orienté (resp. non orienté) est défini par un ensemble V de sommets et un ensemble E d arcs (resp. d arêtes) formé de couples (resp. paires) de sommets et est noté G = (V, E). Typiquement, un sommet peut représenter une ressource (processeur, disques, etc) et une arête peut représenter une liaison physique ou virtuelle de communication entre les éléments représentés par les sommets. On peut être amené à rajouter des informations sur les sommets ou les arêtes. Par exemple, on placera des valuations sur les arêtes qui correspondront à des capacités ou des contraintes. On peut également utiliser la coloration de graphes et/ou de chemin pour représenter par exemple les sections critiques. Un hypergraphe H = (V, E) est une généralisation des graphes où la cardinalité des éléments de l ensemble E peut être supérieure à deux. Ces objets combinatoires permettent de modéliser des entités du monde réel bien au-delà des problèmes d interconnexion et de télécommunication. Citons par exemple les graphes de calcul ou l étude d un état transitoire, du temps avant une panne, etc. L étude des propriétés et des comportements de ces entités est effectuée en profitant de l énorme quantité de résultats existants dans la littérature en mathématiques discrètes, soit sur des propriétés structurelles (par exemple connectivité, couplages, ensembles indépendants, nombre chromatique, etc), soit sur des principes de construction (graphes de Cayley, graphes extrémaux, etc), soit enfin sur l algorithmique qui s y rapporte (algorithmes de flot, connectivité, calcul de couverture par les sommets, etc). De nombreux exemples de la littérature démontrent l importance d une définition précise des modèles, puisque des variations apparemment mineures transforment un problème facile en un problème difficile. Il est aussi fréquent qu un problème en général NP-complet puisse être résolu dans des cas particuliers. Tous ces exemples visent soit à construire le meilleur composant possible satisfaisant les contraintes et optimisant une fonction de coût, on parle alors de problème de conception, l approche est en général duale puisque que la tâche de

63 4.2. DÉFINITION ET NOTATIONS 63 construction s accompagne de la preuve de la qualité de celle-ci, soit à déterminer les propriétés de certains composants combinatoires. 4.2 Définition et notations Nous présentons dans cette section les définitions mathématiques qui nous serons utiles pour notre modélisation Définitions de base Un graphe non-orienté (resp. orienté) G(V, E) est une structure composée d un ensemble V d éléments sommets, que nous supposerons ici fini, et d un ensemble E de paires de sommets appelées arêtes. Pour désigner respectivement les ensembles de sommets et d arêtes d un graphe G, on pourra utiliser les notations V (G) et E(G). Le nombre de sommets d un graphe est appelé ordre de ce graphe. Par exemple, un graphe représentant un réseau est un graphe non-orienté car les liens sont bidirectionnel c est à dire qu un lien entre une machine A et une machine B est équivalent au lien entre la machine B et la machine A Généralité sur les graphes 1. Une arête {v, v } est dite incidente à v et à v. v et v sont les extrémités de {v, v }, et sont dits adjacents. Une arête de la forme {v, v} est appelée boucle. Une arête existant en plusieurs exemplaires dans l ensemble des arêtes est une arête multiple. 2. Un graphe simple est un graphe sans boucles ni arêtes multiples. Par la suite, et sauf mention explicite, nous ne traiterons que de graphes simples. 3. Soit v un sommet d un graphe G. Le degré de v, noté δ(v), est le nombres d arêtes E(G) incidentes à v. Cette notion est étendue au graphe entier : le degré minimal de G, δ(g), est le minimum sur tous les sommets v de V (G) de δ(v). De manière similaire, le degré maximal de G, noté (G), est le maximum de δ(v) sur tous les sommets v de V (G). 4. Une chaîne entre deux sommets v et v d un graphe G est une suite se définissant de la manière suivante : {{v 1, v 2 }, {v 2, v 3 },..., {v k 1, v k }} d arêtes de E(G) telle que v = v 1 et v = v k. Le nombre d arêtes d une chaîne est appelé longueur de la chaîne. Une chaîne peut être le chemin entre deux composants liés d une application si, par exemple, les sommets représentent les composants d un applications et les arêtes les liaisons entre ces composants. 5. La distance entre deux sommets v et v d un graphe G est la longueur de la plus courte chaîne existante entre v et v. 6. Un graphe G est dit connexe s il existe une chaîne entre toute paire de sommets du graphe. Le diamètre d un graphe connexe, noté diam(g), est le maximum, pour toutes les arêtes {v, v } de G, de la distance entre v et v. Un graphe est également dit connexe si pour toute paire de sommets distincts il existe une chaîne les reliant. La direction n a pas d importance pour qu un graphe soit connexe. Si p > 1 (nombre de sous-graphe) le graphe n est point connexe parce qu il possède plus qu un seul sous-graphe. Il existe plusieurs degrés de connexité, selon l aisance de mouvement au sein du graphe. Par exemple, le graphe représentant un réseau local au niveau physique est connexe car il

64 64 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES existe toujours un chemein reliant un sommet à un autre. Généralement, un réseau local est aussi complet. 7. Un graphe complet K(k) est un graphe d ordre k tel que chaque sommet est lié à tous les autres. 8. Un sommet v d un graphe connexe G est périphérique s il existe un sommet v appartenant à G tel que la distance entre v et v est égale au diamètre de G. 9. Un cycle C(k) est un graphe d ordre k dont les sommets sont numérotés de 0 à k 1 et dont les arêtes sont de la forme {i, (i + 1) mod k}, avec 0 i < k. Nous pouvons, à partir de ces définitions, commencer à modéliser notre problème. Nous disposons d un graphe applicatif et un graphe matériel et nous devons réaliser un plongement du graphe applicatif sur le graphe matériel. Cela signifie que nous devons faire coïncider au mieux l applicatif sur le matériel. Pour ce faire, nous devons utiliser les notions de plongements de la théorie des graphes dans notre modèle. Nous détaillons ci-après ces notions Le plongement Le plongement d un graphe G dans un graphe H est un couple ξ G,H = (τ G,H, ρ G,H ) où τ G,H est une application injective de V (G) dans V (H), et ρ G,H est une application injective associant à toute arête {v, v } de G une chaîne ρ G,H ({v, v }) de H liant τ G,H (v ) à τ G,H (v ). Nous pouvons aussi expliciter les notions de dilatation et de congestion de plongement : 1. La dilatation d un plongement ξ G,H (τ G,H, ρ G,H ) est définie par : dil(ξ G,H ) def = max {v, v } E(G)( ρ G,H ({v, v }) ) où ρ G,H ({v, v }) représente la longueur de la chaîne ρ G,H ({v, v }). En résumé, la dilatation de plongement est la longueur de la plus grand chaîne produite par le plongement. 2. La congestion d un plongement ξ G,H = (τ G,H, ρ G,H ) est définie comme : cg(ξ G,H ) def max = {w,w } E(H) ( {ρ G,H ({v, v })/{v, v } E(G) et {w, w } ρ G,H ({v, v })} ) où {w, w } ρ G,H ({v, v }) indique que la chaîne ({v, v }) utilise l arête {w, w } de H. C est le nombre maximum, pour toute arête de H, du nombre de chaînes issues du plongement qui utilisent cette arête. Le plongement permet de manière implicite de réaliser un partitionnement. Or, avant de réaliser ce plongment, nous désirons partitionner nos différents graphes. Ce découpage des graphes en sous-graphes disjoints nous permettra de distribuer au mieux les différents composants des applications pour leurs exécutions sur les différentes machines du réseau lors du plongment. Nous détaillons la notion de partitionnement de graphe ci-après Partitionnements de graphes Soit V (G) l ensemble non-vide des sommets d un graphe G d ordre n. Une partition Π de V (G) est le découpage de V (G) en N (1 N n) parties π, tel que : aucune partie n est vide.

65 4.3. LA MODÉLISATION DU PROBLÈME 65 toutes les parties sont deux à deux disjointes. l union de toutes les parties contient tous les sommets de V (G). Nous donnons un exemple de partition ci-dessous. PARTITION Un graphe G Une partition de G Fig. 4.1 Exemple de partitionnement d un graphe complet Pour tout sommet v de G, π(v) représente la partie de Π contenant v. La taille de la plus def grande partie d une partition est notée : max π = π Π max ( π ). Le cocycle w(π) d une partie π est l ensemble des arêtes ayant exactement une de leur def extrémités dans π. Le cardinal du plus grand cocycle de la partition est max w = π Π max ( w(π) ). Pour toute partie π d une partition Π de G, on notera E I (π) et E E (π) les ensembles des arêtes de E(G) ayant respectivement leurs deux extrémités dans π (arêtes internes aux parties) et aucune de leurs extrémités dans π (arêtes externes à π). Nous pouvons donc définir ces deux ensembles : S E I (Π) def = π Π E I (π) et E E (Π) def = E(G) E I (Π) qui représentent respectivement les arêtes internes et externes à l ensemble des parties de la partition comme dans l exemple ci-dessous (figure 4.2) : cocycle (dots), externes (dash) et internes (traits pleins) Extension de la partition Fig. 4.2 Les trois types d arêtes 4.3 La modélisation du problème Notre problématique nous amène à modéliser notre point de vue sur notre système composé d applications et de ressources matérielles ou hardware. Nous pouvons définir notre

66 66 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES problème comme un problème issu de la théorie des graphes. Nous modélisons notre application et nos ressources matérielles respectivement par un graphe applicatif et un graphe matériel. Par conséquent, il convient de proposer et de mettre en place une solution permettant un mapping efficace entre ces deux graphes. Ce qui signifie que nous devons définir un plongement du graphe applicatif (que nous pouvons voir également comme un graphe de composants) sur le graphe matériel. Nous procédons donc à un partitionnement du graphe applicatif (exemple figure 4.3) puis réalisons un plongement sur le graphe matériel (exemple figure 4.4) : objet objet objet objet objet partitionnement objet objet objet objet objet objet Graphe applicatif d objets objet Graphe applicatif d objets partitionne Fig. 4.3 Exemple de partitionnement du graphe applicatif materiel 1 materiel 2 objet objet objet objet objet objet objet objet objet plongement objet objet objet materiel 3 materiel 4 Fig. 4.4 Exemple de plongement du graphe applicatif sur le graphe matériel Pour commencer, nous pouvons affirmer que : le graphe matériel est forcément connexe et non orienté puisqu il existe toujours un lien bidirectionnel entre toutes les machines. Dans le cas contraire, nous divisons le lien en deux parties.ces deux parties peuvent être utiles si l on désire prendre en compte des notions de sécurité plus fortes (fermeture de certains ports, passage à travers des routeurs, etc). le graphe applicatif est non forcément connexe car les composants de l application ne

67 4.4. LA CARACTÉRISATION DU MODÈLE 67 sont pas tous reliés et n ont pas obligatoirement de communications et d interactions entre eux. les graphes matériel et applicatif n ont pas a priori et d une manière générale d autres propriétés remarquables car le graphe applicatif est non fixé au départ et est dynamique. Le graphe matériel représente les parties physiques du support d exécution et n a pas obligatoirement d autre propriété que la connexité. Nous considérons également qu une application est une entité dynamique. Son exécution peut évoluer dans le temps et dans l espace matériel. Dans une moindre mesure, le graphe matériel est lui aussi dynamique tant au niveau de sa topologie que dans ses propriétés (évolution, panne, etc). Cependant, nous supposerons que l intervalle de variation temporel du graphe matériel est beaucoup plus grand que celui du graphe applicatif. 4.4 La caractérisation du modèle Afin d optimiser l utilisation des ressources et réaliser une modélisation correcte, nous nous interrogeons sur les propriétés de notre problème qui ont une incidence sur notre modèle Caractérisation Nous dicernons et identifions plusieurs caractéristiques majeures. Ces problèmes sont liés à la nature distribuée de notre contexte de travail ainsi qu à l absence d informations globales sur le système La généricité Le partitionnement de nos graphes doit être réalisé pour permettre une optimisation rapide et valable. Il est nécessaire de décomposer les graphes en sous-graphes ou partitions disjoints en regard des relations existantes. Il est sans doute possible de trouver, sur certaines conformations, des propriétés remarquables, mais notre partitionnement doit être réalisé d une manière générique. Nous pouvons affirmer de manière intuitive que lorsqu une relation existe entre, par exemple, deux sous-graphes, le partitionnement aura une incidence sur l optimisation La non-continuité du système Notre système n est pas linéaire ce qui implique que nous devons discrétiser le problème par rapport au temps. Par conséquent, le plongement doit être décomposé en intervalles de temps du fait du caractère distribué des applications et des ressources matérielles. Ce découpage doit également permettre d observer le système afin de découper le système global en systèmes locaux pour réaliser le plongement. Il n est pas envisageable de réaliser une projection statique du graphe applicatif sur le graphe matériel car le temps de calcul des solutions peut être très long (ce genre de problème est considéré comme NP complet voire NP difficile) et ceci va à l encontre de la dynamicité. La projection statique n est donc pas réaliste en regard du problème que nous essayons de résoudre et que nous cherchons à optimiser. La non-continuité du système implique que nous devons effectuer des calculs à des intervalles de temps définis par discrétisation.

68 68 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES La validité des informations La notion de validité des informations est inhérente au caractère distribué des applications. Il est communément admis que, dans un système distribué, toutes les informations concernant l état du système et des applications ne sont pas disponibles et/ou difficile à obtenir d une manière simple et rapide. Nous nous trouvons, au sein même d un des problèmes des sytèmes distribués. Ceci est dû à la nature combinatoire complexe du système et au manque d informations. Il semble donc assez difficile de réaliser une optimisation optimale. De plus, la notion dynamique engendrée par les applications influence grandement le temps de calcul, lorsque celui-ci est possible, des informations nécessaires à la modélisation des dîtes applications. Nous avons, en général, une approximation de l état des informations de l application. Ces approximations nous permettent d avoir des temps de réactivité peu élevés. Pour nous permettre d apporter des solutions à ces problèmes, nous devons, dans un premier temps, définir précisément la nature d une application ainsi que celle du support matériel Définition d une application ou logiciel Un composant logiciel ou une application n est que l expression au niveau macroscopique d une tâche élémentaire processeur, c est à dire qu un composant logiciel est une suite d instructions élémentaires d un processeur. La notion de réutilisabilité est souvent associée aux composants, dans ce cas, des éléments de base sont conçus afin de composer une application future par assemblage de ces briques logicielles de haut niveau (elles mêmes constituées de briques logicielles de base de plus bas niveau). Nous pouvons en déduire qu une application est une entitée logicielle pouvant varier dynamiquement dans le temps et l espace pour permettre l exécution de certaines tâches. A contrario, si l application était figée, il serait alors possible d ordonnancer les tâches de celles-ci par l utilisation d algorithmes déjà existants. Cependant, une application, de par sa nature dynamique, ne se prête peu ou pas à l ordonnancement. De ce constat, nous considérons et caractérisons une application comme un ensemble de composants dynamiques interagissants entre eux et disposants de besoins particuliers pour leurs exécutions. Ces besoins applicatifs peuvent être une ou des ressources matérielles/logicielles, locales ou distantes qui permettent une exécution correcte des composants des applications. Ces applications consomment au cours du temps diverses ressources comme du calcul processeur, de la mémoire, de la bande passante réseau, des entrées/sorties et d autres contraintes et/ou préférences applicatives d exécutions et de placements. Ces différentes informations donnent, à notre sens, une bonne caractérisation du comportement dynamique et des besoins de ces applications lors des exécutions. Dans tous les cas de figure, ces applications, composants ou suites d instructions ne peuvent s exécuter que sur du matériel informatique ou hardware Définition du matériel ou hardware Nous pouvons définir le terme hardware (ou matériel en français) par l ensemble des pièces physiques qui constituent le support de l exécution des applications et plus généralement des logiciels. Le terme hardware est utilisé pour distinguer les parties fixes interconnectées d un système (du moins dans un intervalle de temps assez grand) par rapport à ceux plus variables comme les composants logiciels ou les données pouvant être exécutées, stockées, modifiées ou transportées sur celle-ci. Cette définition peut s appliquer soit à la machine dans son

69 4.4. LA CARACTÉRISATION DU MODÈLE 69 intégralité, soit aux différentes pièces constituant l ensemble de la machine. Il faut alors définir les parties importantes et représentatives de la machine considérée comme par exemple le processeur, la quantité de mémoire vive, la capacité du disque-dur, etc. Il est néanmoins possible d avoir des propriétés logicielles attachées au graphe matériel dans le cas, par exemple, du système d exploitation, du bios, etc. Ces informations donnent une bonne approximation des ressources qui composent le matériel. Cela nous permet de mieux associer chaque ressource demandée par une application à chaque resource représentative du matériel. Que l on soit dans le cas du software ou du hardware, il est possible de modéliser ces deux systèmes complémentaires par la théorie des graphes Le graphe d application De notre point de vue, une application A est un ensemble de nœuds avec des arêtes valuées et des caractéristiques de besoins applicatifs. Ce graphe est alors définit à partir de l ensemble des composants O construisant cette application et de l ensemble des interactions I de ces composants lors de l exécution. Par conséquent nous pouvons écrire : Soit A le graphe d application, soit O l ensemble des composants et soit I l ensemble des interactions entre les composants O lors de leurs exécutions sur le graphe matériel alors une application A est définie par A(I, O). Nous devons à présent définir plus précisément les ensembles O et I. Nous détaillons ci-après ces définitions L ensemble O des composants L ensemble O des composants est un ensemble de n (n Z) composants O i. Nous pouvons écrire que : O i = {O 1,..., O n } et Card{O} = n Il est maintenant nécessaire de caractériser les composants O i. Un composant O i peut être caractérisé à partir d un ensemble de métriques. A notre sens, il existe deux types de métriques : les métriques systèmes et les métriques applicatives. Chaque métrique contient un ensemble de paramètres évoluant en fonction du temps. Les métriques systèmes permettent de caractériser un composant par rapport à ses diverses consommations en ressources physiques que nous jugeons représentatives du comportement de ce composant. Les métriques systèmes se définissent comme suit : Soit M Oi (t) la consommation mémoire de O i en fonction du temps t. Soit R Oi (t) la consommation réseau de O i en fonction du temps t. Soit U Oi (t) la consommation processeur de O i en fonction du temps t. Soit E Oi (t) la consommation d entrée/sortie locale de O i en fonction du temps t. De la même manière, les métriques applicatives correspondent à notre caractérisation des besoins applicatifs (contraintes et préférences) exprimés par un composant. Elles s énoncent comme ceci : Soit C Oi (t) la consommation des contraintes de O i en fonction du temps t. Soit Z Oi (t) la consommation des préférences de O i en fonction du temps t.

70 70 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES Nous en déduisons que, d après notre modèle, chaque composant O i est caractérisé par un ensemble de paramètres P Oi évoluant en fonction du temps t. Nous posons : P Oi (t) = {M Oi (t), R Oi (t), U Oi (t), E Oi (t), C Oi (t), P Oi (t)} Il est possible maintenant de généraliser la définition d un composant à l ensemble O des composants de l application : O = {{M Oi (t), R Oi (t), U Oi (t), E Oi (t), C Oi (t), Z Oi (t)},..., {M On (t), R On (t), U On (t), E On (t), C On (t), Z On (t)}} Nous avons caractérisé l ensemble des composants d une application par rapport à leurs consommations et nous devons à présent définir la notion des interactions entre ces composants L ensemble I des interactions Notre modèle d interactions ne prend pas en compte la diffusion c est à dire que nous considérons qu à t donné un composant O i n a qu une seule interaction avec un autre composant O j. Par conséquent, nous définissons I l ensemble des interactions entre composants en fonction du temps t. Nous posons : I i,j = F (O i, O j )(t) Ceci revient à dire qu une interaction I i,j entre un composant O i et O j est une fonction F qui évolue en fonction du temps t. D une manière générale, tous les composants peuvent potentiellement avoir une interaction entre eux. Cependant, nous limitons ce phénomène en prenant en compte une propriété caractéristique des interactions en utilisant le débit de communication entre les différents composants. Il en résulte qu une interaction I i,j existe si et seulement si : F (O i, O j ) 0. Une interaction existe, de notre point de vue, si un débit entre O i et O j existe et est non nul. F est donc une fonction relative au débit de l interaction. Nous avons défini l ensemble des composants de l application et leurs interactions, il est nécessaire maintenant de modéliser le graphe matériel Le graphe matériel Nous posons l hypothèse que les machines ou sites S sont reliés par des liens réseaux R et que les sites et les liens réseaux sont constants. Par conséquent nous définissons le graphe matériel de la manière suivante : Soit M le graphe matériel défini par M(R, S) avec R correspondant aux liens réseaux et S aux sites. Nous posons R ij = (S i, S j ) le lien réseau entre le site S i et le site S j Chaque site S i est lui même caractérisé par un ensemble de propriétés matérielles H S qu il possède. Nous posons alors H Si les propriétés matérielles de S i :

71 4.5. LA RECHERCHE D UNE FONCTION DE COÛT 71 H Si = {H Mi, H Ri, H Ui,..., H λi } Nous explicitons, ci-dessous, un exemple de propriétés possibles d un site S i H Mi H Ri la quantité mémoire de S i la bande passante réseau théorique sur un lien de S i H Ui le type de processeur de S i Nous pouvons aisément ajouter de nouvelles propriétés notée H λi au site afin de le décrire plus précisément si le besoin s en fait ressentir comme, par exemple, la prise en compte de nouvelles cartes d extensions. L ensemble H Si est, par construction, un ensemble ouvert. Il est possible de caractériser l ensemble des propriétés matérielles d un site S i. Le problème est alors de faire correspondre l application sur le matériel en tenant compte des besoins exprimés par cette application. Le graphe matériel M est très peu dynamique par rapport aux applications. Nous prenons comme hypothèse que le graphe matériel est stable au cours du temps. En effet, si l on se préocupe seulement des caractéristiques physiques des machines que nous désirons modéliser, les changements pouvant intervenir sur ces caractéristiques sont, d une manière générale, peu nombreuses mais également très peu fréquentes au cours du temps. Par exemple, si nous considérons le lien réseau existant entre les machines, nous pouvons affirmer qu il est globalement stable au cours du temps mais il est probable que dans un certain intervalle de temps beaucoup plus grand que la dynamicité temporelle des applications, des variations puissent se produirent (pannes, mises à jours, etc). Par conséquent, si t 1 et t 2 t avec t 1 << t 2 et M = f(t), f(t 1 ) f(t 2 ) alors cela signifie que M peut être considéré comme une constante. Nous en déduisons que R ij = Cte et S j = Cte. Nous avons modélisé les caractéristiques des composants, des interactions ainsi que les sites, nous devons à présent nous pencher sur la recherche d une fonction de coût pour optimiser le déploiement et le placement. Cette fonction doit être représentative de l exécution d une application en regard des ressources physiques et applicatives consommées et utilisées. Elle doit également utiliser la modélisation précédente. 4.5 La recherche d une fonction de coût Nous devons optimiser notre système (placement et exécution d applications sur des machines) par l utilisation d une métrique qui est une fonction de coût de l ensemble de ce système. Cette recherche s appuie sur la définition d une application et des modèles précédents. La définition du terme application est générale, même si il existe des cas particuliers comme par exemple les applications à base de composants. Cependant, si l on se réfère à la définition commune, une application est un logiciel ou un ensemble de logiciels conçu pour réaliser une ou plusieurs tâches particulières (logiciel de comptabilité, de video-conférence, etc). Un logiciel est lui-même un programme informatique au sens large, souvent utilisé pour désigner un ensemble de programmes. Un programme informatique est lui-même une séquence d instructions, établie à l aide d un langage de programmation, indiquant à un ordinateur l ordre des opérations à effectuer. Le programme est écrit dans un langage de programmation qui constitue le programme source, qui, pour être exécuté par le processeur, est compilé en code binaire ou interprété, constituant ainsi le programme objet. Ce programme objet effectuera une ou plusieurs tâches constituant une ou plusieurs briques élémentaires d une activité. Par

72 72 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES extension, une tâche, peut être une ou plusieurs instructions élémentaires du processeur (dans un langage de plus bas niveau) permettant de réaliser toute ou une partie d un programme Le but de la fonction de coût Le but de la fonction de coût est de représenter l exécution d une application par rapport à son environnement. Nous cherchons à optimiser l allocation de ressources et par extension le placement des applications en milieu hétérogène. En recueillant le maximum d informations disponibles par diverses méthodes, nous devons tenter d en déduire un placement et ainsi améliorer le temps de réponse et d exécution des applications. Par exemple, si une application exécute un travail ordinairement en quatre minutes, et si, après notre optimisation, le même travail s exécute en deux minutes, alors nous pouvons dire que l efficacité de l application s est accrue par rapport à l application qui n a pas été optimisée. Il est nécessaire de construire et de définir cette métrique pour optimiser et comparer les différentes exécutions effectuées. Si cette fonction de coût est minimisée alors il en résultera une meilleure utilisation des ressources matérielles et logicielles disponibles et engendrera un gain de rapidité et de satisfaction lors de l utilisation de cette application. Les fonctions présentées précédemment sont dépendantes du temps, il n est alors pas possible d obtenir de continuité de comportement. Par conséquent, nous devons utiliser des intervalles de temps pour construire cette fonction de coût. Cette fonction de coût doit être globale et permettre d étalonner et de modéliser l efficacité ou le gain engendré en cas de placement/déplacement ou déploiement des applications. Le problème qui se pose alors est celui de l évaluation du gain, nous pouvons déjà ébaucher un élément de réponse en introduisant la notion de consommation de cycles processeur. Il nous semble plausible de connaître intuitivement le nombre de cycles nécessaires à une exécution en mesurant une exécution sur deux sites distincts afin de vérifier le gain apporté grâce à, par exemple, la migration d une application sur l un ou l autre des sites en question. Dans tout les cas, il semble que si celle-ci est bien réalisée, une migration apporte dans une majorité de cas un gain substantiel d exécution, ce qui diminue le taux d inactivité des processeurs concernés et diminue les états d attentes pour le processeur, l application et l utilisateur. Cependant, il est indispensable de prendre en compte le modèle de communication qui peut être soit local, soit distant. A contrario, ce modèle peut engendrer des pertes et non un gain Les choix possibles Il existe de nombreux choix possibles pour une fonction de coût représentative de notre problématique. Nous rappelons que nous travaillons dans un contexte distribué ce qui empêche d obtenir la plupart des informations sur l état global du système étudié mais le but visé est toujours d exécuter les applications au plus vite par l utilisation d une fonction de coût. Si l on se place d un point de vue théorique, il est possible de choisir : la consommation processeur globale mais il n est pas possible d avoir directement cette information du fait du caractère distribué des applications visées. De plus, la consommation globale n est pas forcément représentive de l activité de l application car une partie de l activité processeur n est pas dévolue à cette même application mais pour les besoins de fonctionnement du système, comme par exemple les services actifs/inactifs du système d exploitation, le contrôle des périphériques, etc.

73 4.5. LA RECHERCHE D UNE FONCTION DE COÛT 73 le nombre de requêtes exécutées mais les requêtes des différents clients du système ne sont pas, a priori, comparables puisqu elles dépendent de l application considérée et des paramètres des requêtes. le nombre de cycles processeur utilisateur. Ce nombre de cycles réalisé est un sous ensemble de la consommation processeur globale si l on prend comme hypothèse que les cycles ne sont pas différents d une machine à une autre. Cette définition peut être importante si, par exemple, un coût financier est associé au temps d exécution (location de temps de calcul, etc). Dans ce cas, nous pouvons décomposer chaque application en sous parties équivalentes unitaires. Chaque application A est alors une somme d unités d exécution unitaires. Cette unité d exécution nous permet de comparer et d optimiser localement la fonction de coût recherchée pour chaque site. Ce qui revient à dire que le nombre de cycles utilisateur est une somme de l exécution des cycles utilisateurs de l application A sur chaque site : N cycles = i=n i=1 Execution A Si Notre problème revient donc à faire une sommation des cycles locaux de chaque site puis de faire une seconde sommation de chaques sites pour obtenir un nombre de cycles utilisateur global du système. Si l on ne considère que les cycles utilisateurs alors notre but est, dans tous les cas de minimiser leur nombre et par extension de diminuer le taux d inactivité des processeurs. Ceci revient à dire qu il existe une taille d exécution globale et qu un des moyens pour limiter le taux d inactivité des processeurs, donc d augmenter dans l absolu, la rapidité de traitement, peut être la migration. En effet, si l on considère un ensemble de sites pris deux à deux, lors de migration entre ces deux sites (pour optimiser l exécution), on peut remarquer qu entre un temps t 1 et t 2, il y a normalement un gain. Ce gain n est le fait que de l optimisation des cycles utilisateurs. Cependant, le problème réside au niveau des relations entre les sites. Pour un modèle ne comportant que deux sites, la réponse à l optimisation est assez simple à mettre en œuvre, alors que dans un modèle comportant plus de deux sites, il est indispensable de prendre en compte les relations pouvant exister entre les sites et les composants de l application. Ceci est évident, si l on focalise notre vision au niveau des graphes et de leur partitionnement. En effet, si l on subdivise un graphe applicatif en plusieurs sous-graphes, la difficulté réside surtout dans l intégration de ces relations au sein du partitionnement car il existe des problèmes potentiels de relations. Cette approche est réalisée par la notion de formes relationnelles de [Bou94] qui permettent un découpage d un graphe en sous-graphes par analyse de la densité de leurs états. Plus les relations sont fortes plus elles doivent être prises en compte, permettant ainsi de négliger les formes relationelles peu denses c est à dire avec une densité de relation faible. Cet algorithme, non basé sur les cycles utilisateurs mais sur les communications, privilégie donc les sites dont les communications avec d autres sont les plus intenses. Il permet de déduire un découpage et un placement adéquat pour optimiser le système. Notre problématique nécessite l inclusion d autres paramètres comme la charge processeur et les besoins applicatifs. Nous devons réduire le graphe applicatif de départ en un ensemble de sous-graphes sans dépendances. Cela signifie qu il ne doit pas y avoir de relation entre les différents sous-graphes. Les sous-graphes ne doivent pas être connexes. De ce constat, nous pouvons en déduire que si E est la fonction d exécution globale alors : maxe(t) = maxe sous graphe (t)

74 74 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES Ce découpage nous aide lors de la définition et de l expression de la fonction de coût des cycles utilisateurs La fonction de coût Le nombre de cycles global du système est donné par la sommation pour l ensemble des sites de la somme des cycles locaux utilisateurs propres à chaque site. Notre but est d optimiser cette fonction de coût globale. Par conséquent, nous posons : GE la fonction d exécution globale et LE la fonction d exécution locale. Nous pouvons écrire que : GE = i=m i=1 LE i avec LE i = i=n i=1 E(O i) où E est l exécution locale unitaire d un composant O i par rapport à un site S j. Ces formules nous permettent de modéliser notre fonction d optimisation globale puisque nous définissons pour chaque site une fonction de coût local. Nous devons minimiser la fonction GE. Nous partons du principe qu à un instant donné t il n y a pas de mouvement de composant mais qu entre deux instants t 1 et t 2 des composants ont pu se déplacer ou être déplacés pour optimiser globalement le système, changeant ainsi le nombre de cycles utilisateurs consommés. Le problème suivant se pose alors : comment peut-on jouer sur les fonctions locales pour permettre une optimisation locale et par extension une optimisation globale du système? Pour répondre à cette question, nous devons recenser les différentes fonctions de notre modélisation. Nous en déduisons qu il existe six fonctions locales chacune dédiée à un type d information. Ces six fonctions sont les suivantes : 1. Une fonction d évaluation de niveau de charge processeur. 2. Une fonction d évaluation de niveau de communication. 3. Une fonction d évaluation de la charge mémoire. 4. Une fonction d évaluation de la quantité d entrée/sortie. 5. Une fonction d évaluation de besoins applicatifs (contraintes et préférences) au regard des propriétés. 6. Une fonction d agrégation multicritère ou logique paramètrable des fonctions précédentes. Chaque fonction énumérée ci-dessus à un coût. Nous devons donc, non seulement optimiser localement chaque fonction mais aussi veiller à ce que leur mise en œuvre soit la plus négligeable possible en terme de consommation de ressources locales et/ou distantes et de temps. Il semble peu raisonnable de pouvoir optimiser toutes les fonctions ensembles, car il est possible que, localement, une mauvaise optimisation puisse intervenir. Le gain global dû à l optimisation peut être le fait d un gros gain local et d une perte distante. Ce qui revient à dire qu une perte locale n est pas forcément synonyme de perte globale. Il peut exister des fonctions dont l optimisation mène à un antagonisme pour l optimisation d autres fonctions. En effet il n est pas toujours possible d optimiser toutes les fonctions, il est nécessaire, parfois, de perdre sur l optimisation d une fonction pour pouvoir gagner beaucoup plus sur une autre. Par exemple, dans un cadre distribué, si nous désirons optimiser la fonction représentative de la consommation réseau, il semble évident que pour limiter au maximum les échanges, l application soit localisée en un seul endroit. Si l on se place du coté de la fonction représentative

75 4.6. LES PROPRIÉTÉS DES FONCTIONS DE COÛT 75 de la charge processeur et si la charge est au moins 100% pour cette application, alors cette fonction n est pas optimisée puisque par définition, la charge devrait être répartie pour utiliser au mieux les ressources processeurs. Nous avons là un exemple où l optimisation de la charge réseau est antagoniste avec celle de la charge processeur. Néanmoins, il est probable que le gain apporté par l optimisation réseau soit nettement supérieur à la perte occasionnée par l optimisation de la charge processeur. L agrégation de ces deux optimisations (un gain et une perte) demeure positive et apporte, malgré tout, un gain global si l exécution et le temps de réponse de l application sont supérieurs à l exécution sans cette optimisation globale Conclusion partielle Nous cherchons à partitionner nos graphes et réaliser un plongement afin d obtenir des optimums locaux. Cette notion est un peu différente de celle de groupes dans les formes relationelles de [Bou94]. Il est clair, que si l on cherche à optimiser les communications, la meilleure manière est de concentrer l ensemble des composants sur un même site. Les échanges s effectuent alors en local ce qui, par définition, supprime tous les échanges distants sur les liens réseaux. Les communications sont alors optimisées au maximum et il n y a pas de meilleure optimisation possible. Malheureusement, cette possibilité n est pas envisageable dans le cas d un système distribué. De la même manière, si l on s intéresse seulement à l optimisation de la charge processeur, nous pouvons affirmer qu il vaut mieux répartir la charge sur les processeurs les plus rapides afin d accélerer le traitement. En effet, les processeurs les plus rapides ont des capacités de traitements supérieures ou tout du moins un nombre de cycle possible plus élevé. Par conséquent, une même instruction peut être traitée en moins de temps, mais pas obligatoirement en un nombre de cycles processeur moindre. La conséquence pourrait être l abandon, lors des traitements, des processeurs les plus faibles au profit des plus puissants. A contrario de certains travaux, comme par exemple ceux réalisés dans les hypercubes par [BCV03], nous n avons pas un système où l architecture est précisément définie. L autre différence notable se situe au niveau de la charge totale qui n est pas constante au cours du temps. Ce problème bien que similaire au nôtre n est pas réalisable dans le système d équilibrage de charge que nous devons réaliser, car celui-ci n est pas relatif à l architecture sur laquelle nous nous appuyons, mais peut avoir lieu avec n importe quel site composant notre réseau ou graphe. Cependant, il est intéressant de prendre en compte ces résultats car cela nous pousse à penser notre problème en utilisant au mieux la notion de voisinage afin de trouver le ou les meilleurs endroits où l exécution sera la plus efficace. Il va sans dire, qu il faut également minimiser les coûts de tranferts lors des changements de territoires d exécution (exemples des migrations). La meilleure solution ou, plus modestement, le meilleur compromis est d effectuer une répartition en fonction des capacités de chacun. Cette notion entraîne, à notre sens, un meilleur service à l utilisation ainsi qu un meilleur support à une éxécution future. Il convient donc de faire correspondre au mieux, les composants qui ont une consommation de n opérations par seconde et les processeurs qui réalisent n opérations par seconde. Cela correspond à procéder à une minimisation de notre fonction de coût globale. 4.6 Les propriétés des fonctions de coût Nous devons nous attacher maintenant à minimiser les différentes fonctions de coût qui composent notre fonction de coût globale. Ces fonctions sont des consommations de ressources

76 76 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES qui définissent l exécution des composants. Il nous faut au préalable les expliciter Les différentes consommations Nous rappelons que nous modèlisons notre problème de la manière suivante : soit V le plongement du graphe applicatif sur le graphe matériel. On considère M statique en fonction du temps et inversement A dynamique en fonction du temps. Nous posons : M(t) = Constante et A(t) A(t + 1) V : A M O i A et S j M avec S j = V (O i ) Chaque composant est caractérisé par des consommations (mémoire, réseau, processeur, entrée/sortie, contraintes, préférences) qui correspondent aux propriétés des fonctions définies que nous jugeons représentatives. Pour minimiser notre fonction de coût globale, nous devons, par conséquent, borner les consommations la composant pour chaque site S j La consommation mémoire La quantité mémoire est liée à la quantité maximale mémoire sur le ou les sites d exécutions du composant. Mais lors du dépassement de capacité, le système peut utiliser de la mémoire virtuelle et la pagination sur disque pour compenser ce manque. D une manière générale, nous pouvons approximer et nous prenons comme hypothèse que la quantité mémoire utilisée au cours du temps par tous les composants d une application sur un site donné est inférieure ou égale à la mémoire maximale physique RAM présente de ce site pour ne pas engendrer un swap-out par le système. Cette quantité est notée M Sj. i=n i=1 M O i (t) M Sj La consommation d entrée/sortie Il est possible qu un ou plusieurs composants de l application réalisent des entrées/sorties pendant leurs exécutions (accès à des périphériques, etc). Il est alors nécessaire de les prendre en compte. La quantité possible d entrée/sortie d un site est limitée, par conséquent la quantité d entrée/sortie utilisée au cours du temps par tous les composants d un site donné est inférieure ou égale à la quantité maximale théorique possible de ce site. i=n i=1 E O i (t) M Ej La consommation de contraintes Chaque composant est définit également par ses besoins applicatifs en utilisant des contraintes sur les ressources nécessaires pour son exécution. La consommation de contraintes est une fonction F relative aux propriétés (ressources matérielles et logicielles) d un site par rapport aux contraintes des composants de ce site. L exécution est possible si et seulement si la fonction F est évaluée à vrai. Par conséquent, les contraintes sont vues comme des vetos et elles définissent le domaine dans lequel l exécution d un composant ou d une application est possible. F (C Oi (t), S j ) = vrai

77 4.6. LES PROPRIÉTÉS DES FONCTIONS DE COÛT La consommation de préférences Chaque composant peut disposer de préférences sur les ressources pour son éxécution. Cela implique que la consommation de préférences est une fonction F relative aux préférences des composants par rapport aux propriétés d un site La consommation réseau F (Z Oi (t), S j ) La consommation réseau peut se diviser en deux parties, l une locale et l autre distante. La consommation réseau entre des composants, en relation sur le même site, est nulle car il n y a pas utilisation du réseau. Inversement, la consommation entre des composants, en relation sur des sites distincts, est a priori non nulle. Il faut donc minimiser la somme des consommations réseaux de tous ces composants. { V (Oi ) = V (O j ) R(O i, O j )(t) = 0 V (O i ) V (O j ) min i=n i=1 j=m j=1 R(O i, O j )(t) avec i j et n, m Z Cette équation définit la minimisation de la consommation réseau comme une congestion de plongement. En effet, il est nécessaire de réduire au maximum les chaînes existant sur les différents liens réseaux. Plus la minimisation est forte et moins les liens réseaux sont utilisés lors des communications. Cela revient à dire que si l on a une congestion nulle alors les entités communiquent en local. Il est également possible d exprimer la consommation réseau dans l optique d une dilatation de plongement. Le but est toujours de minimiser cette valeur, puisqu elle représente l éloignement entre entités communicantes. Plus l éloignement est faible plus les entités communicantes sont proches. Soit max(r) la capacité des liens réseau maximale entre les sites, alors la minimisation s écrit sous la forme : min i=n i= La consommation processeur j=m j=1 R(O i, O j )(t) max(r) avec n, m Z La consommation processeur peut s exprimer de deux manières différentes suivant l optique où l on se place. Elle est soit une congestion de plongement, soit une dilatation. Dans les deux cas le but est de minimiser cette quantité. Nous pouvons respectivement écrire ceci pour la consommation processeur : V (O i ), V (O j ) min i=n i=1 j=m j=1 U(O i, O j )(t) avec n, m Z Cette équation définit la minimisation de la consommation processeur comme une congestion de plongement. Soit max(u) la capacité processeur maximale de traitement, alors la minimisation de la dilatation s écrit sous la forme : min i=n i=1 j=m j=1 U(O i, O j )(t) max(u) avec n, m Z L optimisation des différentes consommations est maintenant possible sauf dans le cas du processeur et du réseau où il est nécessaire de pousser plus en avant les formules afin de pouvoir dégager une minimisation, car leurs résolutions ne sont pas évidentes. Il faut par conséquent, s attacher à résoudre les problèmes posés par les équations de la consommation réseau et processeur.

78 78 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES 4.7 Activité réseau, processeur et besoins applicatifs Nous présentons ci-après les formules qui modélisent l activité réseau, processeur et celle des besoins. Ces activités (charge réseau, charge processeur des composants et préférences) doivent être minimisées par rapport aux capcités maximales de ces activités pour permettre une optimisation du système. Les différentes formules Nous rapprochons ces formules de la notion d écart-type et nous présentons d autres solutions possibles pour discuter d un algorithme de partitionnement et d optimisation Optimisation des différentes activités D une manière générale, pour optimiser l activité réseau par rapport à la capacité maximale théorique de ce réseau, pour optimiser l activité processeur engendrée par les composants par rapport à la capacité maximale théorique du processeur ainsi que pour optimiser les préférences nous recherchons une solution aux équations suivantes qui ne sont plus des consommations au sens strict du terme. Nous rappelons que le domaine de validité de ces formules dépend des contraintes qui agissent comme des vetos. Nous considérons que lorsque toutes les préférences sont satisfaites, la capacité de satisfaction et de consommation est maximale et vaut 100%. Nous pouvons alors énoncer les formules suivantes : min (charge reseau Capacite Reseau ) min (charge composant Capacite P rocesseur ) min (preference composant 100) Ceci revient à minimiser la charge processeur et réseau de chaque site S j et de maximiser la satisfaction des préférences applicatives. Il n est pas possible d optimiser globalement ces activités du fait du contexte distribué dans lequel nous travaillons. Nous pouvons, malgré tout, le faire localement pour l ensemble des sites. Les capacités réseaux et processeurs peuvent être différentes par leurs natures (type différent, débit différent, etc). Or pour les minimiser et les comparer, nous devons associer une base commune de comparaison. Ceci nous amène à prendre le problème en utilisant la notion d écart-type. Si chaque charge (charge reseau, charge composant ) et si la satisfaction (preference composants sont minimisées par rapport à la moyenne des capacités maximales respectives, alors nous sommes bien en présence d une minimisation d écart-type. Nous pouvons alors introduire et expliciter cette notion qui correspond à nos équations L écart-type L écart-type E(X) est la racine carré de la variance, soit : E(X) = P(X X) 2 Nous cherchons donc à minimiser l écart type respectivement de la consommation réseau, de la consommation processeur et de la consommation de préférences : min Pi=n P j=m i=1 j=1 (R(O i,o j )(t) ( P i=n i=1 P j=m j=1 n R(O i,o j )(t) n )) 2 n et n, m Z et n, m 0

79 4.7. ACTIVITÉ RÉSEAU, PROCESSEUR ET BESOINS APPLICATIFS 79 min Pi=n P j=m i=1 min j=1 (U(O i,o j )(t) ( P i=n i=1 P j=m j=1 U(O i,o j )(t) n )) 2 n et n, m Z et n, m 0 Pi=n P j=m i=1 j=1 (Z(O i(t),o j ) ( P i=n i=1 100 n )) 2 n et n, m Z et n, m 0 Ces formules nous permettent de minimiser à la fois la charge réseau, la charge processeur et la consommation de préférences. Cependant, un problème subsiste pour la minimisation réseau et processeur car nous devons connaître des informations sur l état global du système. Or nous ne disposons pas de toutes les informations nécessaires pour résoudre ces équations. En effet, notre contexte de travail est un système distribué, ce qui implique que certaines informations ne sont pas accessibles simplement ou même impossibles à obtenir. Or, si la connaissance des différences (R(O i, O j )(t) et (U(O i, O j )(t) nous est connue, dans le sens où nous pouvons la calculer localement, il nous est, par contre, impossible de connaître les sommes des différences : i=n j=m i=1 j=1 ( R(O i,o j )(t) n ) et i=n j=m i=1 j=1 ( U(O i,o j )(t) n ). Notre contexte distribué nous empêche de minimiser d une manière calculatoire exacte ces deux équations. Seules des approximations sont réalisables, ce qui peut entraîner quelques problèmes sur l exactitude des résultats recherchés et obtenus. La solution est peut-être de modéliser le gain global apporté par le déplacement d un composant du site i vers le site j Le gain global Si l on considère le gain global lors d un déplacement de charge ω de deux sites entre le temp t et le temps t + 1, alors nous pouvons écrire : ω i (t) k=n ω k k=1 n + ω j (t) k=n ω k k=1 n - ω i (t + 1) k=n ω k k=1 n - ω j (t + 1) k=n ω k k=1 n Malheureusement, nous rencontrons le même type de problème que précédemment, car le deuxième terme de chaque valeur absolue est également inconnu (la somme des moyennes de la charge de chaque site). En effet, nous n avons pas accès à toutes les informations du fait du caractère distribué de notre contexte de travail et il n existe pas de temps global. Ceci nous amène à discrétiser notre problème pour découper le gain global en une somme de gains locaux calculables Les autres solutions Les solutions existantes sont diverses. Elles peuvent soit s appuyer sur l optimisation initiale, soit réaliser cette optimisation de manière incrémentale. Nous pouvons, par exemple, utiliser des heuristiques de connaissance locale qui nous permettront d avoir une métrique de comparaison et de calcul. Cependant, il faudra également trouver un moyen de contourner les problèmes des quantums de temps qui peuvent être différents entre chaque site. Il nous est nécessaire de restreindre notre vision à une dimension locale ou de sous partition. Par cette simplification du problème, nous pouvons intuiter de nombreuses choses sur l état global qui en résulte. Il est possible de prendre le problème du point de vue du gain apporté par un déplacement. Si nous isolons, par découpage simple du graphe, les sommets où ont lieu un déplacement

80 80 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES pour optimiser l exécution alors nous obtenons deux sous-graphes. L un englobe le gain et l autre englobe l ensemble du graphe qui reste inchangé ou non soumis à un déplacement. Nous avons donc un sous-graphe où un gain est réalisé et un sous-graphe complémentaire au premier qui représente un graphe soumis à aucune variation. Nous en déduisons qu il existe globalement un gain par l optimisation réalisée. Nous pouvons énumérer de nombreuses façons de partitionner un graphe, suivant sa topologie. Par exemple, pour un réseau point à point, l utilisation de gradients, comme dans [LK87], est assez indiquée. Pour un réseau local, il existe des algorithmes classiques, souvent statiques. Ceci revient à utiliser une optimisation de site à site, ainsi nous pouvons avoir une information sur le gain apporté. Cependant la somme des optimisations locales peut être différente de l optimisation globale du fait des approximations et de la non connaissance des informations relatives à l état global. Nous pourrions également essayer de connaître la moyenne globale de consommation et/ou d utilisation des différentes ressources et besoins, mais ce problème est NP-Complet car il nécessite le calcul d informations globales qui ne sont pas disponibles ou beaucoup trop longues à obtenir dans un environnement distribué. Cela implique que le nombre de solution est exponentiel et il serait alors obligatoire de parcourir toutes les solutions pour résoudre et trouver la moyenne globale, ce qui n est pas convenable dans le contexte dynamique de notre problématique. De plus, il faudrait alors prouver la convergence de l algorithme vers la moyenne pour assurer qu à chaque parcours de solutions, celles qui sont trouvées se rapprochent bien de la moyenne et sont finies. Ceci n est pas réaliste du fait de la longueur des calculs et des parcours qui sont en jeu. Ce n est pas propice à une optimisation rapide et efficace dans notre contexte de travail. De plus, un tel algorithme reposerait sur un principe assez diffile, que ce soit en complexité de mise en œuvre mais également en complexité de calcul. Cet algorithme s apparenterait plus à une solution d un problème de type CSP (Constraint Satisfaction Problem) où la recherche des solutions possibles ainsi que le parcours de ces solutions est très long. Ceci n est pas compatible avec la recherche d un système d optimisation léger et rapide. L utilisation d heuristiques (partitionnement de sites distincts 2 à 2) nous paraît répondre au mieux aux contraintes de dynamicité, de complexité et d efficacité. Il faut, néanmoins, se poser la question de l efficacité du comportement d un partitionnement de deux à deux sites distincts lors des périodes de stabilité de charge car la solution est peut-être à ce moment là, d utiliser la moyenne globale de la charge, mais sans doute au prix de calculs beaucoup plus lourds comme nous l avons explicité précédemment. Toutes ces réflexions nous amènent à penser et à déduire que nous n avons pas de gain global, au sens où nous n optimisons pas de manière globale, mais une somme d optimisations locales qui améliorent l efficacité globale Discussion sur un algorithme Nous voulons créer un algorithme nous permettant de partitionner notre graphe matériel suivant trois critères : le critère des communications, le critère de la charge processeur, le critère des besoins applicatifs. Nous représentons notre graphe de la manière suivante : chaque nœud représente un site avec un poids correspondant à la charge associée et chaque arête modélise un lien de communication qui est associé à un poids (correspondant au volume de communication dans

81 4.7. ACTIVITÉ RÉSEAU, PROCESSEUR ET BESOINS APPLICATIFS 81 ce lien). Nous pondérons donc à la fois les nœuds et les arêtes. Nous allons nous heurter à un problème difficile à résoudre comme nous l illustrons sur les figures 4.5 et % 10 10% 75% 10 10% 4 25% % 15 60% Decoupage par densite de communication 4 25% % 15 60% Fig. 4.5 Découpage du graphe en fonction de la densité de communication 75% 10 10% 75% 10 10% 4 25% % 15 60% Decoupage en fonction de la charge 4 25% % 15 60% Fig. 4.6 Découpage du graphe en fonction de la charge D après nos exemples, nous pouvons voir que le découpage par rapport aux communications n est pas automatiquement équivalent au découpage par rapport à la charge de chaque nœud. Or, si nous voulons réaliser un algorithme prenant en compte ces deux paramètres non forcément liés, nous allons sans doute avoir des incompatibilités lors de ce découpage. Ceci n est pas satisfaisant. A notre connaissance, il n existe pas d algorithme générique permettant un découpage en sous-graphes disjoints d un graphe quelconque par rapport aux poids sur les arêtes et aux poids des nœuds. Des algorithmes existent pour, par exemple, calculer le plus court chemin (Prim et Kruskal) qui peut être utilisé pour optimiser le routage des communications. Le problème réside dans le caractère généralement centralisé de ces algorithmes. Nous pouvons citer également le recuit simulé distribué, qui peut être utile lors de la mise en place de répartition de charge. Dans tous les cas, ces algorithmes ne permettent pas un découpage selon notre modèle. Ce découpage que nous voulons minimal en sous-graphes disjoints devra être recalculé assez souvent pour répondre au mieux à cette allocation de ressources et de distribution de charge. Nos exemples de découpage par rapport aux communications et à la charge sur les figures 4.5 et 4.6, nous démontre qu il est généralement impossible de trouver un découpage optimal regroupant ces deux critères choisis. Le découpage selon un critère peut s avérer antagoniste au découpage selon les autres critères. Une solution est l utilisation des méthodes multicritères qui permettent d agréger ces différents points de vues en un critère unique, mais le découpage risque de n être pas, lui non plus, optimal. Le découpage sera un compromis, qui généralement peut être considéré comme la solution la plus approchante

82 82 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES ou l approximation d un optimum. Cependant, si l on désire obtenir une solution optimale non approximative, nous devons donc réduire notre problème, en utilisant qu un seul critère (communication ou charge ou besoins applicatifs) pour permettre le partitionnement initial. 4.8 L algorithme Nous définissons ci-après un algorithme de placement utilisant nos graphes suivant les événements et les différents critères à la manière des formes relationnelles L algorithme de placement Nous présentons ici le déroulement du partitionnement lors de l allocation de ressources. Il s appuie sur l algorithme centralisé nommé sparse partitions de [BP90]. Il est modifié pour s adapter à notre problématique (besoins applicatifs, distribution, communications et créations de partitions disjointes). L algorithme initial semble donner de bons résultats mais il semble que sa mise à l échelle puisse poser quelques problèmes. Nous pensons que notre algorithme doit être assez efficace mais doit souffrir des mêmes problèmes que celui sur lequel il est basé. Nous rappelons qu il n y a pas de synchronisme entre les sites. Nous rappelons également que le placement est le résultat d un processus décisionnel logique et que la collecte des informations et leurs traitements est rapide mais pas immédiate. Cet algorithme est une simplification du mécanisme d allocation. Il utilise le partitionnement de manière itérative et calcule, avec l aide d une fonction d évaluation le placement ou le déplacement des composants entre les différents sous-graphes ou partitions pour optimiser l exécution des applications et des composants Les hypothèses Nous établissons plusieurs hypothèses : 1. l algorithme travaille sur un graphe applicatif et matériel quelconque pour répondre à notre désir de généricité. 2. l ensemble des sommets est fini pour induire une fin dans l exécution de l algorithme. 3. les nœuds sont des composants, ils sont pondérés pour représenter les besoins. 4. les arêtes sont les liens de communications, elles sont pondérées pour représenter la densité de communication. 5. chaque sommet connait l ensemble de ses voisins directs avec lesquels il interagit et/ou est en contact. 6. la transmission de message est asynchrone et sans pertes pour éviter la mise en place d un temps global et pour introduire la notion d hétérogénéité pour les différents domaines d exécutions possibles. Soit un graphe applicatif défini par une ensemble de nœuds et d arêtes A(I, O) (interactions et composants) et une procédure de décision P (I, O, C, Z) permettant de décider la viabilité d un placement à partir des différentes informations disponibles en regard des propriétés des sites du graphe matériel. Ces informations sont :l interactions des composants, les composants eux-mêmes, les contraintes et les préférences des composants en regard des propriétés des sites.

83 4.8. L ALGORITHME Les principes L algorithme découpe un graphe A en un ensemble de sous-graphes S disjoints. Pour effectuer cette tâche, un certain nombre de nœuds vont être choisis aléatoirement. Le choix aléatoire est effectué régulièrement par chaque nœud jusqu à ce que le nœud soit élu ou qu il soit informé de son inclusion dans un sous-graphe en construction car chaque nœud choisi, pourra construire son sous-graphe en déterminant les nœuds qui doivent entrer dans son propre sous-graphe par rapport au résultat de l évaluation de la procédure de décision. Il devra ensuite les informer de leur intégration au sein de la construction. Chaque nœud élu, construit son sous-graphe de manière itérative en parcourant les liens qui lui sont rattachés. La construction commence lorsque le nœud élu demande et essaye d englober ses nœuds voisins directs dans la construction et lorsque ceux-ci acceptent (en fonction de leur appartenance ou non à une autre construction). Lorsque le nœud élu a parcouru tous ces voisins directs et a englobé des nœuds voisins directs dans sa construction, il passe la main aux autres membres de son ensemble qui feront la même démarche pour déterminer si leurs voisins directs respectifs peuvent être englobés et ceci sans demander aux autres membres de son ensemble encore en construction. Quand le sous-graphe en construction ne peux plus s étendre, en fonction du résultat de l évaluation de la procédure de décision ou lorsque tous les nœuds sont déjà utilisés, alors la construction se termine. S il reste des nœuds non intégrés, c est à dire dont l évaluation par la fonction de décision n est pas correcte, alors les nœuds voisins directs non utilisés dans un sous-graphe seront inclus dans cette même construction, sinon il sera l unique nœud dans cette construction au cas où tous ses voisins directs sont déjà utilisés par d autres constuctions. Il est fort possible qu il puisse subvenir un phénomène de concurrence, puisque plusieurs élus peuvent travailler simultanément. Un nœud peut être sollicité simultanément par plusieurs élus. Pour résoudre ce problème, nous pouvons ajouter que si le nœud est déjà dans une région en construction alors il informe l élu le demandant et l élu poursuit sa construction en ignorant ce nœud, sinon un système de relations d ordre entre les élus permet d inclure des priorités dans les demandes. Ce système devra initialement énumérer et classer les différents sites suivant leurs importances par rapport aux autres. De ce fait, seul un des élus pourra construire son sous-graphe comme il le veut. Le nœud recevant la demande, devra prendre la demande de l élu prioritaire et informera les autres de son appartenance à cette construction, les autres élus continuerons leur construction en ignorant ce nœud. De plus, les messages étant asynchrones et la construction se faisant de manière itérative (par étapes successives), il est probable que des nœuds aient terminé leur construction avant les autres. Il faut donc mettre en place un compteur d étape pour chaque nœud, pour permettre à chaque nœud d effectuer les mêmes étapes lors des réceptions de messages. DEBUT COMPTEUR-ETAPE = 0; Enumérer(A(I,O)) & Classer(O_{k}) de A(I,O); A CHAQUE TOP FAIRE COMPTEUR-ETAPE++; POUR CHAQUE O_{i} appartenant à A(I,O) faire

84 84 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES TANT QUE O_{i}!appartient Elu(A(I,O)) O_{i}!appartient Construction(O_{j}) FAIRE Tirage_aléatoire(Elu(A(I,O))); FAIT FIN TANT QUE SI O_{i} appartient Elu(A(I,O)) Avertir(Elu((A(I,O))-{O_{i}})); COMPTEUR-ETAPE++; FIN SI TANT QUE Procédure_décision(I(O_{k}), O_{k}, C(O_{k}), Z(O_{k})) satisfaite SI O_{j}!appartient Construction(O_{k}) Inclure (O_{j}, Construction(O_{k})); SINON Essayer(Voisin_direct(O_{k})); FIN SINON FIN SI FIN TANT QUE FIN POUR CHAQUE FAIT FIN A CHAQUE TOP SI O_{j}!appartient Construction(O_{i},...,O_{k}) Construction(O_{j},..,O_{n}); FIN SI FIN Nous pouvons donc, de notre point de vue, adapter cet algorithme pour le partitionnement par rapport aux poids des arêtes (les communications), par rapport aux poids des nœuds (la charge processeur) et des besoins applicatifs. Cependant, il est nécessaire de définir une valeur de comparaison pour permettre ce partitionnement, elle peut, à notre sens, être fixée arbitrairement ou être fixée par rapport aux expériences et/ou à la qualité de service désirée Les résultats L utilisation de cet algorithme nous permet de placer les composants de notre graphe en fonction de la densité de communication (arêtes), en fonction de la charge (nœuds) et en fonction des besoins applicatifs. L utilisation d heuristiques comme par exemple les procédures multicritères ou dans notre cas une procédure logique va nous permettre de prendre une décision sur le placement pour optimiser au mieux, dans la plupart des cas, l exécution des composants c est à dire la charge, les communications engendrées et les besoins sur les différents sites où les composants sont placés. 4.9 Conclusion Notre modélisation du problème sous forme de partitionnement de graphes nous a amené à réfléchir sur la faisabilité d un algorithme permettant le découpage d un graphe en sousgraphes en fonction des critères de communication, de charge et de besoins applicatifs. Il

85 4.9. CONCLUSION 85 nous semble clair que le découpage ne peut pas facilement avoir lieu en fonction de ces trois facteurs pouvant être antagonistes sans l utilisation de procédures de décisions efficaces. Il n existe pas forcément de lien entre la charge processeur, la densité de communication et les besoins applicatifs. Nous pouvons prendre comme exemple un programme distribué faisant du calcul scientifique. Nous pouvons imaginer que les calculs sur chaque processeur accapare au maximum les ressources du processeur et que seul les résultats des calculs sont échangés sur les liens de communication réseau. Il est donc nécessaire soit de ne prendre qu un seul critère de découpage (communication, charge processeur ou besoins applicatifs), soit d utiliser un système d heuristiques (recuit simulé, etc) ou bien agréger, comme dans notre cas, les trois critères par une procédure logique adaptée et rapide afin d assurer au mieux nos souhaits. Le processus de décision et le type de décision ont un rôle clé au sein de notre système.

86 86 CHAPITRE 4. LA MODÉLISATION PAR GRAPHES

87 Chapitre 5 La prise de décision Le placement et son optimisation impliquent généralement la mise en œuvre d un ou de plusieurs modèles mathématiques. L utilisation des mathématiques nous permet de modéliser, avec plus ou moins d efficacité, notre problème. La décision de déplacer une application afin d en améliorer les performances représente une classe importante de problèmes d optimisation combinatoire. Dans les systèmes distribués, trouver une solution optimale de placement ou de migration est un problème NP-complet. De nombreuse études ont été réalisées pour mettre en évidence ce phénomène comme dans [Chr89, FB89, VLL90]. Parmi les outils d optimisation qu il est possible d utiliser, nous pouvons citer la théorie des graphes, la théorie des files d attente, les algorithmes heuristiques, l aide multicritère à la décision [BF96] et les procédures logiques de décision. Dans ce chapitre, nous faisons un rappel sur les théories de décision multicritères, de modélisation des files d attente et de dérive des connaissances. Nous exposons également succintement la décision logique. Nous présentons la logique de l incertain, qui, de notre point de vue, est connexe à notre travail. La connaissance de ces théories nous permet de mieux appréhender notre problème. Nous rappelons que les applications visées sont dynamiques tant au niveau de leur placement que de leur exécution. Ces deux règles nécessitent la construction d une décision de mobilité dynamique viable pour le système d un point de vue temps de construction ainsi qu au point de vue temps d exécution. Pour cette raison, nous cherchons des solutions sousoptimales avec une bonne évaluation heuristique. La décision de placement peut dépendre de plusieurs facteurs comme par exemple l approche multicritères. 5.1 Préambule sur l aide multicritère L aide à la décision prend appui sur la recherche opérationnelle, mais aussi sur d autres disciplines (psychologie, sociologie, économie, informatique, etc) et d autres démarches. Toutefois, toute contribution en recherche opérationnelle ne relève pas nécessairement de l aide à la décision dans la mesure où certains travaux purement mathématiques mis sous l étiquette de la recherche opérationnelle ne sont pas directement tournés vers une aide à la décision comme l explique [RB93]. L aide à la décision implique un minimum d insertion dans le processus de décision : elle ne se fait pas seulement pour mais essentiellement avec les acteurs du processus dans l établissement d une véritable relation d aide. Bernard Roy formule le projet de l aide à la décision en recherche opérationnelle comme suit : 87

88 88 CHAPITRE 5. LA PRISE DE DÉCISION Chercher à prendre appui sur la science pour éclairer les décisions de nature managériale et pour conduire les processus de décision dans les systèmes organisés. En effet, d après Roy, on ne découvre pas un problème comme un objet qui pré-existe car sa formulation ne peut pas, en général, être totalement objective et ne peut être envisagée indépendemment des rapports entre l individu et la réalité. De plus, il ajoute qu il est normal que cette formulation évolue au fur et à mesure du processus de décision. La recherche opérationnelle s est principalement constituée, jusqu à assez récemment du moins, à partir de modèles qui postulent l existence d une fonction objectif (d un critère) unique. On admet ainsi implicitement que pour aider à mieux décider, il existe une règle générale, c est à dire une fonction objectif qui s impose aux yeux de tous pour caractériser la bonne direction dans laquelle il convient de faire évoluer le système étudié. Cette procédure a l avantage de conduire à un problème mathématique bien posé. Ce problème est, par conséquent, posé en des termes tels que la solution, souvent admise comme optimale, est totalement déterminée par sa formulation. C est donc la façon de poser le problème qui crée l existence et le contenu de la solution. Cette solution est généralement obtenue à l aide d algorithmes ou encore d heuristiques. Les situations concrètes où les conséquences sont suffisamment complexes pour qu un seul critère ne puisse appréhender correctement toute les informations nécessaires à la comparaison globale des actions (projets, options, scénarios...) sont nombreuses. Quelle que soit la manière dont on envisage d apporter des éléments de réponse à des questions ayant pour objet d éclairer une décision, il est nécessaire de s intéresser aux conséquences qu entraîne la mise à exécution de chacune des actions envisagées. En général, ces conséquences sont multiples et peuvent s évaluer en des termes variés (économique, technique, de confort, de prestige, etc). Selon [RB93], l argument réaliste selon lequel la réalité est multidimensionnelle ainsi que la prise en compte de plusieurs points de vue pour aider à la décision par l utilisation de méthodes multicritères, ne peut à lui seul justifier l adoption d une démarche multicritère pour aider à la décision. En effet, utiliser un tel argument conduit à considérer le monocritère comme un cas limite et dégénéré du multicritère. De plus, adopter une démarche monocritère, ce n est pas postuler que dans la réalité un seul critère est à l œuvre mais c est, plus simplement, vouloir aider à la décision en ne montrant explicitement qu un seul critère. Nous pouvons considérer qu à la base d une démarche multicritère pour l aide à la décision, existe un acte de foi. Cette conviction consiste à croire que construire explicitement plusieurs critères peut avoir un rôle positif dans le processus de modélisation du problème. C est cet acte de foi qui est la base de ce que Bernard Roy a appelé le nouveau paradigme multicritère pour l aide à la décision. L aide multicritère à la décision est condamnée à travailler dans le cadre d un problème mathématique mal posé car elle prend appui essentiellement sur la construction de plusieurs critères conflictuels. En effet, il n existe, pas en général, de solution réalisant l optimum sur tous les critères simultanément. Notons, toutefois, que le fait qu un problème de décision soit bien posé du point de vue mathématique ne garantit pas qu il soit bien formulé par rapport à la réalité concernée. L aide multicritère à la décision paraît être une discipline bien ancrée dans de nombreux domaines variés. Elle s inscrit dans une voie constructiviste éventuellement confortée par la voie axiomatique en intégrant l idée d apprentissage et ne cherchant pas à découvrir une vérité existante extérieurement aux acteurs impliqués dans le processus.

89 5.1. PRÉAMBULE SUR L AIDE MULTICRITÈRE La formulation multicritère d un problème de décision Nous nous intéressons ici à la modélisation d un problème multicritère. La formulation multicritère d un problème de décision peut être définie comme le triplet modèle A, A/F, E où : A est l ensemble des actions potentielles (envisageables, admissibles, etc). Cet ensemble peut être défini explicitement (ensemble fini) ce qui implique que les contraintes soient implicites. A contrario, il peut être défini implicitement (en général dans un ensemble infini) et les contraintes sont alors explicites. Dans ce deuxième cas, on a recours à la programmation mathématique à objectifs multiples PMOM et l on désigne souvent l ensemble des actions admissibles par le symbole X. A/F est l ensemble fini des attributs ou critères généralement conflictuels, à partir desquels les actions seront évaluées. Cet ensemble des attributs ou critères est la partie la plus délicate de la formulation multicritère d un problème de décision. E est l ensemble des évaluations de performances des actions selon chacun des attributs ou critères, c est-à-dire l ensemble des vecteurs de performances, qui est un vecteur par action. La littérature en aide multicritère à la décision n a pas, jusqu ici, accordé suffisamment d attention à la génération de l ensemble des actions dans le cas discret. C est comme si cet ensemble s imposait a priori. C est généralement vrai pour plusieurs problèmes de décision. Essentiellement, deux approches ont été proposées pour parvenir à construire un ensemble d attributs en une famille de critères : L approche du haut vers le bas qui consiste à construire une structure hiérarchique ayant à son premier niveau l objectif global qui est éclaté en sous-objectifs qui sont à leur tour éclatés en sous- sous-objectifs jusqu à ce que l on atteigne un niveau mesurable que l on qualifie d attributs. L approche du bas vers le haut consiste à identifier toutes les conséquences pouvant résulter de la mise en œuvre des actions, que l on structure en dimensions puis en axes de signification autour desquels sont construits les critères. Un critère est une fonction, définie sur A, qui prend ses valeurs dans un ensemble totalement ordonné. Comme on le verra dans la section suivante, ceux qui adoptent cette deuxième approche se servent de critères pour représenter les préférences du décideur sur les conséquences reliées au critère. L ensemble d attributs ou la famille de critères ainsi construits doit posséder certaines propriétés : exhaustivité, non redondance, cohérence, indépendance... comme l explique [RB93]. De plus, cette famille doit posséder deux qualités importantes : être lisible, c est-à-dire contenir un nombre suffisamment restreint de critères pour qu il soit possible de raisonner sur cette base et, éventuellement, de modéliser des informations inter et intra-critères nécessaires à la mise en œuvre d une procédure d agrégation et être opérationnelle, c est-à-dire être acceptée comme base de travail pour la suite de l étude. Les évaluations (de performances, d impacts...) des actions selon chacun des attributs ou critères peuvent s effectuer en ayant recours à divers moyens (des formules analytiques, des instruments de mesure, des jugements...), être plus ou moins subjectives et être entachées d imperfections plus ou moins importantes. Cette formulation a beaucoup plus de chances d être adéquate si les parties intéressées au problème de décision y participent pleinement car souvent sa légitimité en dépend. En général, cette formulation ne permet pas de répondre totalement au problème de décision et nécessite

90 90 CHAPITRE 5. LA PRISE DE DÉCISION l usage d une méthode multicritère pour dégager les préférences globales du décideur Les méthodes multicritères La plupart des méthodes multicritères s appuient sur la formulation précédente et comportent plus qu une étape. Si l ensemble des actions est implicite et défini par un ensemble de contraintes explicites, la méthode multicritère est généralement de type PMOM. Une partie importante des travaux en PMOM cherche à déterminer l ensemble efficace. La détermination de cet ensemble ne fait pas intervenir les préférences du décideur, n apporte pas une réponse définitive au problème de décision et n est pas nécessairement une étape obligée. En effet, généralement, l ensemble efficace contient une infinité d actions de sorte que l on doit avoir recours à une procédure d agrégation pour dégager la ou les meilleures actions. La plupart de ces méthodes appartiennent à l une de ces trois approches opérationnelles suivantes : 1. L approche du critère unique de synthèse, évacuant toute incomparabilité. 2. L approche du surclassement de synthèse, acceptant l incomparabilité. 3. L approche du jugement local interactif avec itérations essai-erreur. Les méthodes appartenant à la troisième approche se sont principalement développées dans le cadre de la PMOM. Elles alternent les étapes de calculs fournissant les compromis successifs et les étapes de dialogue représentant une source d informations supplémentaires sur les préférences du décideur. Il y a une différence fondamentale entre les procédures d agrégation que contiennent les méthodes multicritères appartenant aux deux premières approches ; toutefois dans les méthodes appartenant à ces deux approches les préférences sont introduites a priori. Dans la première approche, les préférences locales au niveau de chaque attribut sont agrégées en une fonction de valeur ou d utilité unique qu il s agit ensuite d optimiser. A contrario, la deuxième approche vise dans un premier temps à construire des relations binaires, appelées relations de surclassement, pour représenter les préférences du décideurs, compte tenu de l information disponible. De plus, il est possible avant de construire ces relations de surclassement, d introduire des seuils de discrimination comme, par exemple, les seuils d indifférence, de préférence et de veto. Ces seuils modélisent, localement au niveau de chacun des critères, les préférences du décideur. Les principales méthodes ou familles de méthodes appartenant à cette deuxième approche sont : ELECTRE [MPS94], PROMETHEE de [BVM86], ORESTE de [Rou82] et QUALI- FLEX de [Pae78]. Certaines de ces méthodes sont purement ordinales. La liste des méthodes multicritères que l on retrouve dans la littérature est très longue et semble inépuisable. Dans la suite, nous exposons d une manière mathématique, quelques exemples de décisions multicritères et d agrégation multicritère. 5.2 Les critères et leur propriétés Une décision peut être prise selon plusieurs critères définis ou non, probabilistes ou en fonction du résultat d une action et/ou d une décision précédente. Le processus de décision commence par la formation, la transformation et l argumentation des choix effectués qu ils soient vus comme contraintes et/ou préférences. Il est rare que les actions à mener après une décision soient uniques. Ceci est d autant plus vrai si l on considère des actions résultantes

91 5.2. LES CRITÈRES ET LEUR PROPRIÉTÉS 91 comme le placement, la migration ou la duplication. Afin d augmenter la qualité de service, le choix de cette action peut être réalisé par une analyse multicritère L expression d un critère Un critère, normalement exprimé sous la forme d une fonction, est l évaluation d une action potentielle de l ensemble A d après un point de vue. Il est ainsi possible de comparer les résultats des actions a et b avec une fonction g qui regroupe différents critères selon un point de vue. Ceci s exprime de la manière suivante : g(b) g(a) bs g a où S g est une relation binaire signifiant : au minimum aussi bien, par l évaluation du point de vue considéré par la fonction g. La modélisation des préférences relativement à deux actions potentielles a et b permet de définir les relations binaires suivantes : la non préférence : a b (a I b ou a R b) correspond à l absence de raisons qui justifieraient une préférence entre l action a ou l action b, ce qui se passe dans les situations d indifférence (I) et d incomparabilité (R). la préférence : a b (a P b ou a Q b). correspond à l existence de raisons claires et positives qui justifient une préférence stricte (P ) ou faible (Q). le surclassement : a S b (a P b ou a Q b ou a I b). correspond à l existence de raisons claires et positives qui justifient une préférence mais sans qu aucune séparation significative ne soit établie entre les situations de préférence stricte (P ), préférence faible (Q) et d indifférence (I) Les différents types de critères A partir de ces relations, nous pouvons définir plusieurs types de critères en regard des propriétés exprimées : vrai-critère : ap g b g(a) > g(b) et ai g b g(a) = g(b) qui est un critère où l incertitude entre deux évaluations d actions par g est limité aux cas d égalités. Par exemple, lors de la décision de placement d une entité sur un ensemble de machines disposant de caractéristiques processeur différentes, le vrai-critère permettra d établir un classement des meilleures machines candidates jusqu aux moins bonnes en autorisant les ex-aequos par rapport au critère de type de processeur. Le vrai-critère suppose que les actions potentielles soient toutes comparables les unes aux autres, ce qui correspond à un préordre total. pseudo-critère : ap g b g(a) g(b) > p(g(b)), aq g b q(g(b) < g(a) g(b) p(g(b)), ai g b g(a) g(b) q(g(b)) qui est un critère où l incertitude est définie à trois niveaux, en utilisant les définitions de préférence stricte et faible, et d indifférence. Les limites entre les niveaux sont fonction du résultat de l évaluation des actions par g. Tout comme dans la notion de vrai-critère,

92 92 CHAPITRE 5. LA PRISE DE DÉCISION un classement est réalisé et les ex-aequos sont possibles, cependant la notion d incomparabilité est tolérée. Par exemple, si une décision doit être prise, en prenant en compte un critère de charge et de communication, pour le placement d une entité sur un ensemble de machines lors d allocation de ressources, il est possible que la décision amène soit à privilégier une machine pour laquelle la charge est faible soit une autre machine pour son débit de communication. Ces deux décisions peuvent être considérées comme aussi bonnes l une que l autre pour le placement, même si celui-ci est différent au niveau de la localisation, car l évaluation des critères n amène pas de classement strict des actions potentielles. En effet, une action est considérée équivalente à une autre en terme de décision par l utilisation du seuil d indifférence qui ajoute une notion de flou à l expression des critères. quasi-critère : ap g b g(a) g(b) > q(g(b)) et ai g b g(a) g(b) q(g(b)) qui est un critère où l incertitude entre deux évaluations d actions est composée d un intervalle. Cet intervalle est fonction du résultat de l évaluation des actions par g. Nous pouvons reprendre l exemple précédent à la différence près qu il n y a pas de seuils à partir desquels est réalisé le classement des actions potentielles mais des intervalles d incertitudes sur les évaluations. Ceci permet d introduire une notion de flou dans le classement. 5.3 L agrégation multicritère L agrégation multicritère est une méthode permettant d agréger plusieurs critères non forcément définis sur un même ensemble d actions et/ou de choix afin d obtenir la sélection d une action à réaliser. Par exemple, dans le cadre d une problématique α (recommandation de choix menant à la sélection d une action), vouloir résoudre le problème d optimisation revient à : chercher a A tel que g(a ) = Max a A Lorsque A est fini et comporte peu d actions, la résolution de ce problème est triviale. Par contre si A est infini ou trop grand pour une simple énumération (problèmes combinatoires par exemple), il faut alors recourir à des techniques spécifiques telles que la programmation linéaire, non linéaire, dynamique, aux algorithmes de Branch & Bround ou tout autres algorithmes permettant une résolution simple et rapide. Cependant, l agrègation peut comporter quelques problèmes lors de la comparaison de différentes actions possibles au sein de la même procédure multicritère. Plusieurs techniques permettent une bonne résolution de ce problème comme la possibilité d intégrer des coefficients (importance du critère par rapport aux autres), des vetos et des taux de substitution. Il existe deux types de considérations : Cardinale (C) utilise la notion quantitative des différences g j (a) g j (b) pouvant être corrigée par et sur l échelle du critère ou par d autres caractéristiques liées au critère. Ordinale (O) utilise la notion qualitative attribuée aux différences g j (a) g j (b) par rapport à des seuils définis (échelle discrète) et du critère lui même. g(a) Il existe plusieurs types de procédures d agrégations multicritères simples.

93 5.3. L AGRÉGATION MULTICRITÈRE Les différentes procédures multicritères Soit une fonction d utilité U, également appelée critère de synthèse. U est une fonction de l ensemble des critères c i définis pour un problème : U(a) = F (c 1 (a), c 2 (a)..., c n (a)) L agrégation peut utiliser des compensations de critères, des produits pondérés de critères mais aussi des préférences globales pour des relations de synthèse. Le modèle de préférences peut alors être un unique ou plusieurs systèmes relationnels de préférences. En comparant deux actions a et b nous pouvons aboutir à une affirmation de la forme a H b (H étant l une des relations pour S, I, P,, R,, etc). Nous explicitons ci-dessous les différentes méthodes : La procédure sommative La procédure sommative avec pondération consiste à définir pour chaque critère un coefficient d importance k i au critère c i pour réaliser une somme pondérée des critères par les coefficients. U s écrit : U(a) = n i=1 k ic i (a) Ce principe permet d utiliser la compensation de critères. Il est, par contre, obligatoire d exprimer l ensemble des critères dans un espace de valeurs et de grandeurs homogènes. La détermination des coefficients d importance est assez complexe et peut influencer le résultat de l agrégation multicritère. D après [Fis78] il est nécessaire que la contribution de chacun des critères à la fonction d agrégation soit indépendante des valeurs des autres critères afin d utiliser une procédure sommative. Les inconvénients de la procédure sommative sont l imprécision, l incertitude, l indétermination qui affectent les performances. Ces inconvénients imposent un résultat plus ou moins discutable et fragile La procédure multiplicative La procédure multiplicative est similaire dans sa forme à la procédure sommative. U s écrit : U(a) = n i=1 k ic i (a) Elle consiste en un produit pondéré de critères. Elle est adaptée aux critères de distribution exponentielle variant de 0 à +. Ainsi une valeur supérieure à 1 décrit une évaluation positive et une valeur inférieure à 1 décrit une évaluation négative. Elle souffre des mêmes inconvénients que la procédure sommative La procédure lexicographique La procédure lexicographique repose sur la définition d un ordre d importance au sein des critères, permettant de les ordonner par ordre décroissant. Si le critère le plus important permet de choisir une action, elle sera alors choisie. Inversement, l évaluation des actions en fonction du critère d importance juste inférieur est utilisé en cas d égalité entre les évaluations des critères. Ce processus est ré-itéré jusqu à élection d une action ou d un épuisement des différents critères. Il s agit d un mode de choix hiérarchique. Cette solution est utilisée dans [Fol92]. Cette solution est sans doute la plus simple mais son principal défaut est son manque de compensation éventuel d un critère par un autre et la nécessité d un classement des critères.

94 94 CHAPITRE 5. LA PRISE DE DÉCISION L analyse de la concordance Elle correspond à une coalition de critères concordants avec la proposition a S b marquée comme C(a S b). L acceptation ou le refus de la proposition a S b est obtenue par l évaluation de : card(c(b S a))/card(f ) (où card(a) est le cardinal de l ensemble fini A). Ce qui revient à dire qu une action est préférée à une autre si le nombre de critères pour lesquels elle est préférée est supérieur à une valeur définie. Généralement, un coefficient d importance k j > 0 peut être associé à chaque critère. L importance absolue k[c] est alors définie par : et l importance relative par : k[c] = j C k j k[c]/k[f ] où C F L ajustement de la valeur de s permet que l importance de la coalition C(a S b) soit plus ou moins stricte pour accepter la proposition de a S b. Supposons que s = 1, on arrive à un surclassement S. La définition du surclassement étant : a S b C(b S a) = F L analyse de la discordance L analyse de la discordance est utilisée pour invalider une proposition de type a S b, a Q b, a P b ou a I b lorsque la différence (g j (b) g j (a)) de certains critères C(b P a) devient trop importante. Un seuil de veto peut être introduit à chaque critère. S il existe un critère j tel que g j (b) g j (a) > v j, alors la proposition de a b est refusée Résumé Toutes ces procédures permettent d agréger des critères différents avec plus ou moins de finesse et de complexité lors de l aide à la prise de décision. Elles ont toutes des avantages et des inconvénients inhérents à leur méthode. Naturellement, beaucoup d autres types d agrégations existent mais leurs coûts en terme de temps machine/calcul sont trop importants et sont, par conséquent, peu adaptés aux systèmes distribués de grains fins ou intermédiaires. Ils sont souvent réservés aux problèmes très complexes. 5.4 Exemples de méthodes Il existe de nombreuses méthodes pour l aide à la décision multicritère. Nous exposons les grands principes de certaines d entre elles dans la méthode ELECTRE La méthode ELECTRE I ELECTRE I est une méthode assez simple puisqu elle est basée sur des concepts naturels tels que d accord / pas d accord. Elle ne repose pas sur des a priori, néanmoins le caractère très subjectif de certains paramètres importants de son algorithme est compensé par une analyse de robustesse très approfondie. L analyse de robustesse cherche à élaborer des recommandations aussi synthétiques que possible, acceptables par une vaste gamme de valeurs des paramètres. C est en effectuant une

95 5.4. EXEMPLES DE MÉTHODES 95 telle analyse qu il est possible de vaincre les réticences, aussi bien du décideur que de l homme d étude, quant aux valeurs initiales des paramètres. Si en faisant varier les paramètres autour de leur valeur initiale, les résultats ne sont pas modifiés de manière importante, la recommandation est dite robuste. Les paramètres, susceptibles de variations dues soit à l incertitude des données de base soit à la subjectivité des données volontaristes, sont les amplitudes des échelles de critères, le poids des critères, le seuil de concordance et le seuil de discordance. La contrepartie de cet avantage (une analyse de la robustesse très approfondie) est que le résultat fourni est parfois peu net du fait des nuances faites par la méthode ELECTRE I. Elle ne conduit pas, de manière générale, à la mise en évidence directe de la meilleure action potentielle. L utilisateur d une telle méthode doit rester conscient du fait que le noyau, vu auparavant, ne renferme pas les meilleures actions mais en fait les actions les plus difficiles à comparer entre elles et parmi lesquelles se trouve la meilleure action La méthode ELECTRE II Le point de départ d ELECTRE II est tout à fait différent de celui d ELECTRE I, il ne s agit plus d essayer de trouver la meilleure action, mais de classer toutes les actions de la meilleure jusqu à la moins bonne. Du même coup, les résultats sont plus tranchés que dans la précédente méthode. L approche utilisée reste toujours la même, elle est fondée sur la concordance et la discordance. Cependant, les moyens utilisés pour exprimer ces notions sont enrichis par rapport à ceux d ELECTRE I et permettent de tenir compte de la volonté du décideur d une manière plus fine. Une autre grande nouveauté d ELECTRE II est l introduction de deux types de surclassement (fort et faible), la méthode essaie ainsi de mieux respecter les nuances du réel. Enfin, l algorithme de classement est un important pas d innovation. L existence de deux préordres, établis d une manière différente, offre la possibilité de se faire une idée de la solidité des résultats selon un angle de vue complémentaire à celui de l analyse de robustesse : une action qui change énormément de rang entre les deux classements, direct et inverse, est une action qui peut difficilement se comparer aux autres La méthode ELECTRE III La but de la méthode ELECTRE III est de classer les actions potentielles, depuis les meilleures jusqu aux moins bonnes. Cette méthode suit les grands principes déjà énoncé dans la présentation de la méthode ELECTRE II (construction de la relation de surclassement, élaboration de deux classements antagonistes, synthèse d un classement final). Il y a toujours, comme dans les deux précédentes méthodes, une hypothèse de surclassement, les notions de concordance et de discordance. Néanmoins, le changement dans la relation de surclassement comporte dorénavant une part de flou. Désormais, il n est plus nécessaire de classer les couples d actions potentielles en une des trois catégories (surclassement fort, surclassement faible, pas de surclassement du tout). En d autres termes, la réflexion ne porte pas sur l acceptation ou le rejet en bloc de l hypothèse de surclassement, mais sur la crédibilité à accorder à cette hypothèse. Ceci est traduit par le degré de crédibilité de l hypothèse de surclassement, qui varie de 0 à 1. Elle utilise deux seuils dits d indifférence et de préférence stricte pour tenir compte de l incertitude qui entache plus ou moins les évaluations. Un troisième seuil, le seuil de veto, est utilisé dans la concrétisation de la notion de discordance.

96 96 CHAPITRE 5. LA PRISE DE DÉCISION La méthode ELECTRE IV Sa sophistication est beaucoup plus poussée par rapport aux méthodes ELECTRE II et ELECTRE III car il n y a plus de poids attribué à chaque critère. Ce changement fondamental est accompagné d une grande nouveauté : l abandon de l hypothèse de surclassement, qui rend inutiles les notions de concordance et de discordance. ELECTRE IV utilise, comme ELECTRE III, des pseudo-critères, c est-à-dire des critères associés à un seuil de préférence stricte et à un seuil d indifférence. Des règles simples, utilisant ces chiffres, permettent d établir des relations de surclassement entre deux actions. L établissement de ces règles se fait de telle manière qu aucun des critères ne soit par trop prépondérant ou par trop négligeable. Il existe bien d autres types de méthodes ELECTRE, mais aussi comme nous l avons déjà cité les méthodes PROMETHEE, ORESTE et QUALIFLEX. Ces différentes procédures peuvent s adapter à la problématique de la gestion de ressources et de la distribution de charge lors du placement, puisqu elles permettent une prise de décision rapide en prenant en compte un nombre important de critères divers comme par exemple la charge processeur, la charge réseau, etc. D autres solutions sont également possibles avec l utilisation des files d attente. 5.5 Les files d attente La théorie des files d attente peut modéliser différents systèmes et de multiples applications. Plusieurs réalisations dans le domaine du load balancing utilisent cette théorie. Il est possible de distinguer trois catégories dans la littérature : La prise de décision Elle est également possible par une modélisation en file d attente. Le système d attente M/M/1/K/K et son utilisation dans un modèle à population finie sont présentés dans [Arq96]. Ce modèle est facilement transposable à la réplication dans un système distribué. La théorie de la décision vise précisément à évaluer les chances et/ou les coûts de tel ou tel comportement futur d un système en présence d incertitudes. Dans bien des cas, il est possible de s affranchir du passé de ce système et de n évaluer son avenir qu à partir du seul état présent. Une simplification non négligeable qui, en termes mathématiques, consiste à se placer dans le cadre de la théorie des processus de décision markoviens. Un outil de base, en décision markovienne, est la programmation dynamique : à chaque état du système étudié est associée une valeur déterminée par une équation non linéaire. Ceci peut servir à modéliser des systèmes dits à événements discrets. Cette expression fait référence à l occurrence d événements comparables à l arrivée de nouveaux clients dans une file d attente. Ces événements donnent lieu à des phénomènes de synchronisation et de concurrence, que l on rencontre typiquement dans les réseaux de télécommunications et les systèmes informatiques distribués Le placement statique Le placement statique est un domaine où les files d attente peuvent être utiles comme le montre [BF81, ZSE82]. Ce genre de placement est rendu possible grâce à une connaissance estimée du temps d exécution des processus ainsi que celle de l état des ressources dans le système.

97 5.6. LA DÉCISION LOGIQUE L évaluation d algorithmes L évaluation d algorithmes peut être résolu grâce aux files d attente. Elles sont utilisées pour l évaluation des performances de systèmes de répartitions de charge. Dans ce cas, une file d attente modélise chacun des éléments du système (processeur, réseau, etc). La définition de lois d arrivée de tâches sur les différents composants, de temps de traitement par composant et d algorithmes réalisant la mobilité des tâches permet alors, à partir de tirages aléatoires, de réaliser une simulation d exécution réelle comme le montrent [EB93, GPHS94, Spi95]. Des travaux sont présentés pour donner un modèle de répartition de charge dynamique comme dans [TBA97] Résumé La théorie des files d attente est un outil d analyse et de prédiction de performances utilisée pour la modélisation des systèmes informatiques. Elle peut être appliquée, en partie, à notre modèle qui suppose une définition dynamique du graphe des tâches et de leurs besoins. Nous pensons qu il est possible d appliquer la théorie des files d attente à certaines prises de décision dans un environnement d applications dynamiques. Par exemple, si nous disposons d un système dont les performances sont décevantes et que nous voulions optimiser la qualité de service, nous pouvons utiliser les techniques de mobilité telles que la duplication ou la migration. Cependant, ce modèle n est pas suffisant pour répondre à l ensemble de notre problématique car il n est utilisable que dans certaines conditions. Son inconvénient vient de l obligation de définir un graphe de tâches et de besoins. Cela implique que le comportement général de l application ainsi que ses besoins doivent être connus à l avance. Or, une application très dynamique dont le comportement et les besoins varient au cours du temps est donc difficilement modélisable par cette théorie. Malgré tout, elles peuvent être utiles pour certaines prises de décision, le placement statique ou l évaluation d algorithmes lors de recherche d une qualité de service basique comme nous l avons présenté précédemment. Cette qualité de service peut également être initiée par une décision logique sur un ensemble de paramètres. Nous résumons ci-dessous la théorie de décision de l incertain qui sied aux systèmes informatiques. 5.6 La décision logique L objet d une théorie de la décision dans l incertain est de proposer un ou des critères permettant de modéliser le comportement d un agent face à un problème de choix parmi un ensemble d actions disponibles. Selon Savage [Sav54], une action a est une application d un ensemble d états du monde possibles S = {s 1, s2,...} vers un ensemble de conséquences X = {x 1, x 2,...}. L ensemble S représente l ensemble des états du monde dans lesquels l action peut être appliquée, et pour tout état s S, a(s) X représente le résultat de l action appliquée a à l état du monde s. On parle de décision dans l incertain lorsque les conséquences d une action ne sont pas complètement connues avant qu on exécute cette action et/ou lorsque l état du monde n est pas exactement connu au moment du choix de l action. L agent exprime des préférences sur les actions, reflétant ses préférences sur les conséquences des actions.

98 98 CHAPITRE 5. LA PRISE DE DÉCISION Le problème de décision Ce problème de décision revient à choisir quelle action appliquer parmi celles disponibles. Ces actions disponibles forment un sous-ensemble de l ensemble des actions théoriquement envisageables (l ensemble de ces dernières étant l ensemble des applications de S vers X). Classiquement, on suppose l existence d un préordre (relation réflexive et transitive), complet, exprimant les préférences de l agent entre les actions disponibles. L existence de ce préordre impose que l ordre de préférence entre deux actions ne dépend pas de l ordre de préférence entre l une de ces actions et une troisième. Comment choisir une action? Le choix de l agent est supposé guidé par une relation de préférence sur les conséquences éventuelles des actions applicables, et une relation d incertitude entre les états possibles du monde. En effet, une action peut donner de meilleurs résultats qu une autre dans certains états du monde et de moins bons dans d autres. S il en est ainsi, les plausibilités relatives des états du monde possibles doivent être prises en compte pour évaluer les actions. Dans le cas général, cette préférence peut être complexe à déterminer entièrement. Dans le meilleur des cas, elle est exprimée par l intermédiaire d une fonction d utilité, numérique ou ordinale, sur les conséquences. Dans d autres cas, un agent exprime ses préférences suivant plusieurs critères et l un des problèmes à résoudre est d agréger ces différents critères comme nous l avons expliqué précédemment. Dans d autres cas encore, un agent a un critère de décision unique, mais plusieurs agents sont impliqués dans la prise de décision : l agrégation des préférences de plusieurs agents est le thème d étude de la théorie du choix social initié par [Arr51]. Le problème de décision peut éventuellement être entaché d incertitude. Si l état du monde est parfaitement connu, le problème de décision revient à choisir l action dont la conséquence (dans cet état) est préférée à toutes les conséquences des autres actions. Cela revient à dire que les actions sont directement assimilées à leur conséquence et ordonnées d après la relation de préférence entre ces dernières. Il est à noter que dans ce cas, peu importe que la fonction d utilité soit numérique ou non. Seul compte l ordre entre les conséquences Quelques critères classiques pour la décision L ensemble des états possibles du monde est supposé fini, ainsi que l ensemble des actions disponibles. Les quatre critères de décision dans l incertain recensés par Luce et Raiffa [LR57] sont : Le critère MaxiMin [Wal50] évalue les actions selon l utilité de leur pire conséquence possible. Ce critère est absolument pessimiste, et ne permet pas de compensation entre les conséquences d actions répétées. Le critère MiniMax Regret proposé par Savage [Sav51] évalue les actions en fonction des différences, pour chaque état possible du monde, entre les utilités de leur conséquence et de celle que la meilleure action permet d obtenir. Il les évalue ainsi relativement aux autres actions disponibles, contrairement au critère MaxiMin qui évalue les actions de manière absolue. Le critère d Hurwicz généralise le critère [Wal50], puisqu il évalue les actions en fonction d une moyenne pondérée (par un indice de pessimisme) des utilités de leur pire et de leur meilleure conséquence possible. Enfin, le critère de Laplace évalue les actions en fonction de la moyenne arithmétique

99 5.7. CONCLUSION 99 des utilités de toutes leurs conséquences possibles. Ici, la notion de compensation entre conséquences d actions répétées prend tout son sens. Ces quatre critères requièrent des échelles d utilité de plus en plus raffinées : une échelle ordonnée suffit pour le critère de Wald, la notion de différence entre utilités est nécessaire pour le critère de Savage. Les critères d Hurwicz et Laplace nécessitent, eux, de calculer des moyennes. Ces différents critères logiques peuvent amener à une prise de décision, qui pourra optimiser un placement, comme par exemple, dans le cadre de certaine répartition de charge et de la distribution de certaines applications. Cependant, cette démarche souffre de devoir connaître l ensemble des informations et scénarios possibles sur l état du monde, ce qui invalide son utilité dans les systèmes distribués utilisant des applications dynamiques. De plus, ces critères nécessitent généralement un calcul de toutes les conséquences possibles d une action suivant le point de vue et le critère utilisé. Ceci n est pas raisonable dans le cadre d une prise décision rapide sur des applications dynamiques de grain fin ou moyen, mais peut être plus indiqué pour des problèmes de type CSP. Il demeure, que pour des applications de gros grain, ces critères sont sans doute utilisables et viables. 5.7 Conclusion Les modèles que nous avons présentés dans ce chapitre, sont très utiles pour les environnements dynamiques et complexes tels que notre environnement présenté dans chapitre 1. L analyse multicritère y est rigoureusement définie. Normalement elle est utilisée pour donner une approximation par rapport à des formules complexes qu il est parfois difficile de comprendre et d établir. Dans ce contexte, nous pouvons utiliser cette technique pour agréger plusieurs points de vue dans l optimisation et la gestion de ressources qui est un problème NP-complet. Nous pouvons également voir ce problème comme un problème de satisfaction de contraintes comme nous l avons exposé avec les décisions logique de l incertain. Chaque méthode a ses avantages et ses inconvénients, mais leur connaissance peut nous mettre sur la voie de solutions intermédiaires afin de garder le meilleur de chaque monde. De ce constat, nous avons construit une procédure de décision logique qui autorise à partir de prédicats sur la charge, les communications et sur les besoins applicatifs, de rendre une décision de placement et de déploiement dynamique.

100 100 CHAPITRE 5. LA PRISE DE DÉCISION

101 Chapitre 6 Un gestionnaire de placement à composants expressifs Nous développons, dans ce chapitre, notre système de placement à composants expressifs au niveau d un domaine. Il nous semble inévitable de parler, dans un premier temps, du placement automatique d un point de vue administration d applications réparties pour introduire notre concept. 6.1 Un modèle d administration L administration d applications réparties doit répondre à des contraintes assez spécifiques. Par exemple [Bon98] propose une architecture, des mécanismes et des outils pour la conception d applications réparties. Il en dégage cinq propriétés qui doivent être associées à la gestion d une application répartie administrable. Ces propriétés doivent faciliter la tâche du concepteur ainsi que celle de l administrateur. Nous présentons ci-après ces cinq propriétés : la fiabilité, la transparence à la localisation, l homogénéité aux activités d administration, l indépendance par rapport à l environnement, la traçabilité. Chaque application contient des composants d administration communs à toutes les applications ainsi que des composants d administration spécifiques. Ces composants disposent de services offerts pour permettre l administration, ainsi que des services requis de la part d autres composants d administration de l application ou d autres applications. La coopération entre ces composants ainsi que les appels de services se font à l aide d un système de communication souvent basé sur le multicast. Un moteur générique d administration permet de gérer les services offerts et les résultats de ces services à l aide d un langage de script DCML (Dynamic Control Management Language). La définition des composants d administration est pris en compte dès la phase de conception de l application en s intégrant aux différents points de vue de la norme ODP. Ce travail fournit un modèle pour gérer les applications distribuées. Cependant ce travail est abstrait et les applications peu aisées à implanter. De plus, il semble que le modèle ne soit pas extensible car il nécessite une adaptation pour chaque application. La transparence dans l administration des ressources n est pas totale. Ce modèle bien que différent peut s apparenter, dans son principe, à la norme CORBA 3.0. Cette norme 101

102 102CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS offre une infrastructure de communication fondamentale de l environnement d exécution. Il est possible d utiliser cette plateforme pour développer des services afin de gérer des ressources et des applications. L administration des ressources est un problème complexe. Nous détaillons ci-après ces bases fontamentales. 6.2 Les bases fondamentales Dans les environnements distribués, qu ils soient de simples réseaux locaux d ordinateurs, des architectures plus complexes ou des interconnexions à longue distance, l administration des ressources et des applications devient inévitable. L évolution de ces environnements engendre des problèmes de plus en plus complexes à cause de la multiplication des paramètres à prendre en compte. Dans une vaste majorité, les principaux outils et protocoles d administration travaillent au niveau du réseau. Cependant, il existe un besoin de gérer d autres ressources et d informations telles que le processeur, les périphériques et les ressources logiques (les services rendus par des serveurs d application) ainsi que les besoins des composants. De ce constat, l administration de ressources doit pouvoir gérer reflexivité des applications et être modulaire pour s adapter aux évolutions futures La réflexion au niveau des applications La reflexion, comme le décrit [Smi82], nous permet d obtenir la transparence nécessaire et la possibilité d interagir avec les applications. L avantage de la réflexion est que la syntaxe d un programme peut rester constante quand la sémantique change. La réflexion permet donc d unir deux niveaux d information : 1. Un niveau bas représentant le niveau de l application. 2. Un méta-niveau représentant le niveau de la réflexion. Les informations du méta-niveau proviennent de l observation du comportement de l application. Elles sont donc dépendantes de l application elle-même et de l environnement d exécution de l application. Si une information du méta niveau change, cela entraîne une modification au niveau bas et réciproquement de manière à assurer la cohérence entre les deux niveaux. Nous pouvons alors modifier le comportement d une application sans en réécrire le code. Cette propriété est intéressante pour implanter un nouveau service système tel qu un service de sécurité, de tolérance aux pannes ou d équilibrage de charge sans changer les applications existantes. Nous utilisons le langage CORBA Interface Definition Language IDL pour définir les classes ou les services d une application aussi bien que les services système. Les fonctionnalités de CORBA permettent aux applications d activer et d utiliser dynamiquement les services si besoin est. La modification de certains programmes n entraîne pas la recompilation d autres programmes qui les invoquent tant que leur interface ne change pas. Il est donc possible de changer le comportement des objets serveurs sans en informer leurs clients. Cette possibilité simplifie l implantation de services système tels que la migration, la duplication ou l agrégation. Nous avons donc les bases d une allocation automatique de ressources.

103 6.2. LES BASES FONDAMENTALES Une allocation automatique de ressources Pour mettre en place une allocation automatique de ressources, nous disposons de plusieurs composants principaux. Ils sont au nombre de cinq : Les containers : ils sont attachés aux composants et permettent d intervenir sur leur comportement. Pour utiliser la réflexion, chaque service système et chaque application publie ses interfaces. Un générateur de containers prend en entrée ces interfaces et le code des applications pour générer l interface des containers et les containers eux-mêmes. Le container se comporte comme le représentant de l application. Le client invoque donc le container (méta composant) plutôt que directement le composant applicatif lui même. Nous utilisons le concept d intercepteur [OMG98] dans le container. Un intercepteur est chargé d invoquer les services système et les moniteurs d information avant ou après certains événements tels que l initialisation, l invocation ou l arrêt. Les intercepteurs sont des composants qui sont appelés à des points spécifiques des invocations entre composants. En définissant des sous-classes des classes d intercepteurs et en les enregistrant auprès de l ORB, il est alors possible d insérer du code dans le déroulement de l invocation. Pour pouvoir accéder aux containers, les clients doivent inclure l interface des containers générée par le générateur de containers. Le container propose la même interface que l application. Il y ajoute des exceptions systèmes, par exemple l exception MOVED pour signaler que le composant a été migré, et des interfaces d administration, par exemple pour activer ou désactiver un service système, changer des paramètres ou des propriétés pour l application. Dans ce cas, les interfaces servent de deux manières, elles décrivent les fonctionnalités implantées par une application et également le comportement de cette application dans son environnement. Ces propriétés décrivent le comportement du container, la nature et les besoins particuliers du composant. Par exemple, la fonction d un service système peut être autorisée ou interdite pour un composant particulier. Les moniteurs d information : ils collectent les informations sur les applications, leur comportement et leur environnement. Un moniteur d information mémorise les informations sur l état et le comportement du système, telles que le volume de communication entre un client et un serveur, la charge des machines ou la charge des serveurs, les besoins des objets et les propriétés du site d exécution. Il y a plusieurs moniteurs d information qui se partagent la collecte des données. Par exemple, le moniteur de communication et de relations, le moniteur de charge des processeurs, le moniteur d utilisation du réseau ou le moniteur de gestion des besoins applicatifs. D une manière générale, un moniteur d information possède plusieurs interfaces, soit au moins une interface pour chacun des composants avec lesquels il coopère : une interface pour les modules de décision, une interface pour les containers, une interface pour l administrateur, une interface pour les services système, une interface pour d autres moniteurs d information. Les informations servent de paramètres aux modules de décision à leur prise de décision. Pour obtenir les informations dont ils ont besoin, les modules de décision peuvent consulter les moniteurs d information périodiquement. Les moniteurs d information peuvent également envoyer des alarmes aux modules de décision pour leur signaler des événements

104 104CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS importants lorsqu ils ont lieu. Par exemple, lorsque le moniteur d information qui collecte la charge détecte un déséquilibre important entre deux sites, il peut prévenir le module de décision gérant la charge afin que celui-ci résolve le problème. Certains de ces moniteurs, tel que le moniteur de communication, interviennent au niveau des containers. Dans ce cas, chaque invocation du container entraîne une invocation au moniteur. Un administrateur peut activer, configurer ou désactiver un moniteur d information s il estime que son rôle doit être modifié pour permettre au système d évoluer correctement. Dans ce cas, il utilise l interface d administration du moniteur. Les moniteurs d information peuvent également échanger de l information entre eux. Cet échange a généralement lieu entre deux moniteurs du même type. Par exemple, les moniteurs d information qui gèrent les besoins applicatifs consultent les autres sites pour connaître leur propriétés et ainsi vérifier qu il sera possible de déplacer un objet vers l un d entre eux. La technique d utilisation de moniteur n est pas récente puisqu elle est déjà présente dans les agents SNMP qui surveillent les réseaux. C est également le cas des travaux portant sur la traduction des protocoles tels que SNMP et CMIP vers CORBA [GRO97, MS96]. Les modules de décision : ils mettent en place les algorithmes décisionnels et prennent les décisions de modification du placement des applications sur la base des événements en cours et des besoins applicatifs. Les modules de décision implémentent une politique d allocation des ressources en collectant les informations auprès des moniteurs d information, en analysant ces données puis en faisant appel aux services système pour mettre en œuvre leurs décisions. Un module de décision peut donc utiliser plusieurs moniteurs d information (de même qu un moniteur d information peut diffuser ses informations à plusieurs modules de décision) et plusieurs services système. Par exemple, un module de décision de migration statuera sur quand migrer, quel composant migrer, et d où migrer. L analyse des informations sur le comportement du système permet une prise de décision. Pour cela, plusieurs types de procédures peuvent être utilisées comme nous l avons déjà évoqué dans le chapitre 5. Parmi celles-ci nous pouvons citer des procédures basées sur la théorie des graphes, des files d attente, les procédures logiques, l ordonnancement stochastique ou l analyse multicritère. La méthode dépend de la nature et des besoins des applications. Cependant, elles dépendent toutes de la qualité des informations qui sont maintenues par les moniteurs d information. Les services système : ils exécutent les décisions prises par les modules de décision. Ils correspondent aux actions réalisables sur les composants pour permettre l allocation de ressources et son optimisation. Le principal service est celui de migration. Il est cependant possible d ajouter d autres services, si nécessaire, à la condition qu ils soient utilisés par un module de décision. Ces services peuvent eux-mêmes reposer sur d autres services. Par exemple, dans le cas de CORBA, nous utilisons, pour la migration, les services de cycle de vie, de nommage et de fabrique. D une manière générale, chaque service système a trois types d interfaces : une interface pour les containers, une interface pour permettre aux modules de décision de donner leurs ordres, une interface pour administrer le système. Les services système utilisent les containers au niveau des composants. Ces containers agissent comme des souches ou des squelettes dans CORBA. Leur rôle principal est de rediriger certains appels au composant ou émanant du composant vers le service système et d aider à réaliser certaines opérations de contrôle telles que la migration,

105 6.3. LES RESSOURCES ET LEURS OPTIMISATIONS 105 l administration, etc. Toutes les applications qui doivent être gérées par les services système doivent utiliser les containers correspondant. Pour garantir la transparence et l indépendance des applications aux services système, l héritage entre les composants containers et les composants d application est largement utilisé. De plus, les containers sont générés automatiquement pour éviter une programmation fastidieuse. Le module d administration : il permet d agir sur les paramètres des services système qui peuvent être modifiés pour tenir compte du comportement du système afin d obtenir une meilleure flexibilité dans la prise et l exécution des décisions. Il est donc possible à un administrateur du système d intervenir pour donner de nouvelles valeurs. Le module d administration système peut, par exemple, être utilisé pour mieux adapter les procédures de décision. Les principaux paramètres sur lesquels intervient le module d administration sont ceux des modules de décision et ceux des containers. Les paramètres des modules de décision peuvent être ajustés en fonction de l environnement (nombre d utilisateurs, domaine d application, etc). Ces paramètres sont, par exemple, le poids associé à certaines informations plutôt qu à d autres, le poids associé au passé, la longueur des files d attente, la valeur des seuils, les périodes d observation et de décision, les propriétés des sites et les besoins des composants. Lorsque ces paramètres sont modifiés, le comportement des modules de décision concernés est affecté et influence l ensemble des composants gérés par ces modules de décision. Les paramètres des containers sur lesquels nous intervenons à ce niveau sont les propriétés associées au composant. Le module d administration peut également dynamiquement activer ou désactiver les services système. Nous proposons un modèle générique de gestion des ressources et nous le concrétisons dans la plateforme CORBA. Le modèle conçu est générique et fournit un ensemble de transparences évoquées par ODP. Il s intégre aux protocoles préalablement définis et prend en compte les notions d évolutivité, d adaptativité et de gestion des besoins applicatifs. Notre modèle possède une conception modulaire et orientée composant pour qu il puisse intégrer de nouveaux modules ou permettre le remplacement d un module existant par un autre. Notre architecture offre un service de placement répondant à notre problématique. Cette approche nous permet, d une part de valider la faisabilité d un tel service, et d autre part de pouvoir l analyser en supportant l exécution d applications de tests. Nous devons, à présent, expliciter le type de ressources que nous prenons en compte et que nous optimisons. 6.3 Les ressources et leurs optimisations Nous présentons, explicitons et qualifions ci-après, les ressources importantes de notre système d allocation de charge au sein d un réseau local Les ressources d un réseau local De notre point de vue, un réseau local est, habituellement, géré d une manière globale et centralisée. Dans la plupart des cas, un administrateur est chargé de s assurer que les applications ont accès à des ressources suffisantes pour leur exécution. La recherche des ressources nécessaires à une application peut être assez compliquée et doit donc être parfois réalisée par l administrateur lui-même. C est un phénomène assez courant pour le déploiement d une

106 106CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS application répartie. Il est recommandé d éviter une surcharge de certains sites et des ressources qu ils proposent et effectuer un placement de l application en fonction des différentes disponibilités offertes. Pour cela il est nécessaire de disposer d un minimum d informations sur les ressources disponibles. Le standard CORBA, par exemple, ne dispose pas encore d outils pour faciliter le travail de placement des applications, même si des interceptor existent et peuvent servir à l observation des invocations au sein d une application. Afin de pallier ce problème, le placement doit donc être effectué en fonction d une connaissance partielle des ressources accessibles et une connaissance suffisante des besoins applicatifs. Pour cela, différents outils peuvent aider, malgré tout, au placement comme, par exemple, certains outils de supervision permettent à l utilisateur et/ou à l administrateur, de suivre le déroulement d une application. Cette fonction permettant, le cas échéant, de modifier l accès et l utilisation à certaines ressources (accès restreints, pannes, etc) ainsi que le placement de l application. Il est également possible de réaliser cette supervision de manière automatique reposant sur des algorithmes décisionnels et de contrôles L optimisation d un réseau local Nous pouvons dénombrer quatre familles différentes pour l optimisation au sein d un réseau local. Nous explicitons ci-après ces familles L optimisation processeur Le déploiement d une application répartie doit tenir compte des possibilités des processeurs pour s adapter à la puissance de calcul disponible. Comme nous l avons déjà dit dans le chapitre 4, paragraphe 4.5.2, l optimisation maximale de l utilisation du temps processeur ne peut se faire qu en regroupant sur les processeurs les plus rapides, les composants de l application nécessitant beaucoup de calcul afin d utiliser au maximum ces processeurs et ainsi éviter les famines d instructions. Le standard CORBA n intègre pas, de ce point de vue, des services pour définir les meilleurs placements en fonction de la charge processeur, mais des travaux sont réalisés pour pallier ce problème. L optimisation processeur peut ne pas seulement être dictée par un souci d efficacité d utilisation du processeur mais peut être aussi liée aux coûts engendrés par la consommation processeur. En effet, les préoccupations financières, comme par exemple pour la location de serveurs de calculs, peuvent influencer grandement l optimisation. Dans ce cas, l optimisation passe par l évaluation de l occupation processeur et le calcul des coûts engendrés à l aide de fonctions de coût financiers. Les problèmes d hétérogénéité sont aussi importants, car les applications doivent être écrites pour une famille de processeur définie. Le langage JAVA écarte ce problème par sa conception L optimisation des communications Le déploiement d une application répartie doit tenir compte des possibilités de communication au sein du réseau local pour s adapter aux ressources disponibles. Comme nous l avons déjà introduit dans le chapitre 4, paragraphe 4.5.2, l optimisation maximale du débit de communication ne peut se faire qu en regroupant sur un même site les composants de l application qui communiquent beaucoup entre eux.

107 6.3. LES RESSOURCES ET LEURS OPTIMISATIONS 107 L optimisation des débits de communication peut être également dépendante du type de réseau utilisé. Les différentes vitesses maximales ainsi que la capacité garantie minimale peut influencer l optimisation. Les problèmes liés aux coûts engendrés par la communication peuvent être une donnée non négligeable du point de vue de l optimisation, car le placement des applications peut alors être dirigé par des préoccupations financières, comme par exemple pour la location de serveurs de calculs liés aux volumes échangés ou l utilisation de RNIS. Dans ce cas, l optimisation passe par l évaluation et la facturation des débits de communication La qualité de service Le déploiement d une application répartie doit aussi intégrer la qualité de service. Nous qualifions la qualité de service comme étant la sûreté d exécution de l application et le bon fonctionnement des accès au sein de l application par l assurance d une transmission correcte et rapide des services du réseau utilisé (débit, taux d erreur, garanties, etc) et par sa disponibilité. La première garantie est celle des communications. Dans CORBA, l utilisation du protocole TCP/IP offre une garantie pour l acheminement des messages assurant ainsi un premier niveau de qualité de service sur les communications avec transparence d adressage. D une manière générale, la qualité de service est soit statique c est à dire déterminée et prise en compte au moment du déploiement de l application, soit dynamique et, dans ce cas, ne peut pas être totalement maitrisée, même si elle peut être négociée et variable au cours du temps en réponse aux différents besoins et problèmes. Le problème le plus important est dû au caractère non déterministe du système en général au niveau des pannes qui peuvent survenir Les besoins applicatifs Nous justifions l utilisation des besoins applicatifs par les avantages qu ils procurent lors du déploiement des applications réparties. Ce déploiement doit s effectuer en fonction des besoins applicatifs qui vont, de notre point de vue, améliorer de manière significative l adéquation des applications aux ressources offertes. Par une plus grande connaissance des besoins de chaque composant et par extension de l application elle-même, il est possible de construire un système de répartition de charge beaucoup plus proche, en terme de correspondance, des ressources offertes et du comportement des composants. Ces besoins vont également autoriser ou non, différencier ou non, les placements et/ou les déplacements des entités lors des changements de contexte d exécution (migrations). Les besoins seront le reflet de la connaissance de l administrateur, de l utilisateur ou de l application sur les désideratas des composants de l application pour son exécution par rapport à un site donné, un ensemble de sites ou un comportement. La prise en compte des besoins applicatifs est un domaine de recherche assez important. Par exemple, comme nous l avons déjà présenté dans le chapitre 2, paragraphe 2.5.3, le standard CORBA dans sa version 3.0 intègre le CCM Corba Component Model, qui permet la définition de propriétés sur les composants. Ces contraintes sont une réponse à la gestion des besoins applicatifs. Il est possible de spécifier les ressources nécessaires pour une exécution correcte de chaque composant. Cette approche va dans le sens de notre réflexion. De plus, nous pouvons énoncer deux atouts majeurs de l utilisation des besoins applicatifs au sein des composants. Les composants permettent, de par leurs définitions et leur construction, de réaliser de meilleures migrations et une meilleure intégration de la notion de besoins. Le CCM donne des possibilités d intégrer cette nouvelle caractérisation de ressources dans sa définition.

108 108CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS Cette notion participe à un meilleur déploiement et placement des composants hétérogènes répartis et autorise la faisabilité de systèmes de placement dynamique utilisant et prenant en compte les besoins applicatifs. En définitive, un service de placement dynamique doit donc utiliser les besoins de chaque composant, en regard des ressources offertes, comme des informations vitales pour le placement et/ou le déplacement. Il cherchera donc à optimiser le plongement du graphe applicatif sur le graphe matériel en fonction de sa connaissance des ressources, des proprités des sites, tout en respectant les besoins exprimés par les composants de l application. Ceci participe, d une manière importante, à l évolutivité et à la dynamicité des applications. Par conséquent, la définition des besoins doit, elle aussi, être dynamique. En effet, il est fort possible qu un composant définisse lui-même dynamiquement ses besoins par rapport aux différentes tâches qui lui sont dévolues au cours du temps. Il pourra donc modifier ses contraintes et ses préférences d exécution et être déplacé par le service de placement sur un site répondant à ses critères de fonctionnement. Nous détaillons ci-après la mise en œuvre de ce système Résumé L ensemble des problèmes posés jusqu à maintenant participent tous à l amélioration de la qualité de l exécution des composants et dans les accès entre les composants grâce à l optimisation des ressources. De plus, il semble naturel qu une application puisse disposer de ressources minimales pour son exécution qui correspondent à des besoins pour chaque composant. Les réponses apportées par les quatre sources d optimisations précédentes, nous mène sur la voie d un service de placement dynamique permettant d adapter la configuration de l application à la disponibilité des ressources de manière à améliorer la qualité d exécution et de confort de l application. Cependant l implantation d un service de placement dynamique peut supposer des choix de politiques d optimisation. Par exemple, la recherche d une meilleure utilisation des ressources de communication ne privilégie pas forcément la qualité des services rendus par l application, même si cette optimisation participe à l optimisation globale de l application. Nos objectifs sont donc la construction d un système utilisant les réponses et les remarques évoquées précédemment. 6.4 Les objectifs Notre travail utilise le modèle de P. Chatonnay [Cha98] et de HY Chan [Cha99]. [Cha98] propose de réaliser un placement des constituants des applications via un processus de décision multicritère. Ce processus agrège des informations concernant la charge des sites, les dépendances entre les différents composants par l observation des débits de communication des invocations et des contraintes associées à la sémantique des applications. Cette première étude étant limitée au contexte d un réseau local et à l optimisation de l utilisation du réseau et du processeur. [Cha99] y ajoute la notion de multi-domaines en y intégrant un début de prise en compte des besoins applicatifs pour permettre la migration inter-domaines. Notre travail, se dispense de la notion d inter-domaines en se basant sur un domaine simple type réseau local en vue de l intégration et de l utilisation de la notion de composants. Il approfondit la notion de besoins applicatifs. Pour cela, nous étendons le système avec un gestionnaire de contraintes et de préférences pour qu il prenne en compte les besoins applicatifs ainsi que les propriétés intrinsèques des sites d exécution.

109 6.4. LES OBJECTIFS 109 Nous devons rappeler quelques notions essentielles du rôle d un gestionnaire de placement. Son but principal est de faciliter l exécution d applications et/ou de composants entraînant, entre autre, une amélioration de la qualité de service et des performances, une baisse des coûts et une garantie de sécurité et généralement la prise en compte de l hétérogénéité des sites concernés. Par conséquent, il optimise l utilisation des ressources locales sans distinction par rapport aux différents sites. La recherche de l optimisation globale du système par rapport à l optimisation limitée à une application est justifiée, car l optimisation globale permet, dans la plupart des cas, une optimisation des applications du fait de l allégement des communications au sein du réseau et une meilleure répartition de la charge. Après avoir introduit brièvement le concept de besoins applicatifs dans le chapitre 1 paragraphe , nous présentons ci-après, d une manière plus précise, le cadre de notre étude Le cadre de l étude Notre objectif est de réaliser une maquette pour justifier notre point de vue ainsi que notre modèle. Nous pourrons également démontrer qu un service de placement dynamique à composants expressifs permet une meilleure gestion des ressources ainsi qu une meilleure exécution des applications. La prise en considération des besoins ainsi que celle des propriétés sont souvent imposées par le contexte matériel visé. Il est parfois difficile de démontrer l intérêt de certaines démarches, car, dans notre cas, parfois l expressivité des besoins ne mène pas forcément à un résultat tangible et quantitatif mais qualitif. Il y a donc des limites à notre étude Les limitations Nous avons repris les hypothèses de base des deux études précédentes de [Cha98] et [Cha99]. Ces limitations portaient principalement sur le support matériel, afin de limiter le nombre d informations à prendre en compte, et sur le modèle relationnel, pour limiter la complexité de l implantation. Nous avons supprimé certaines limitations. Nous énonçons les anciennes limitations et celles inhérente à notre modèle plus récent Les anciennes limitations Nous détaillons ici les hypothèses de l ancienne architecture : Un réseau local du type bus à diffusion sert de base de test. Les critères d optimisations ne prennent pas en compte la topologie du réseau, les coûts financiers de transfert, etc. La seule optimisation réalisée par le placement automatique est le regroupement de deux composants communiquant sur un même site. Une grande homogénéité dans les stations de travail utilisées implique qu on suppose qu elles offrent des ressources assez équivalentes : vitesse d exécution comparable, mêmes capacités mémoire, etc. Ceci évite de prendre en compte les problèmes liés à l hétérogénéité lors du placement local. L utilisation de CoolOrb et du langage C/C++. Le modèle a subi quelques changements, la plupart liés à la mise en œuvre de notre modèle Les changements Plusieurs modifications ont eu lieu comme nous l énonçons ici :

110 110CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS Notre modèle prend dorénavant en compte l hétérogénéité, les machines n ont pas forcément des ressources équivalentes (matérielles et/ou logicielles). Ceci nous paraît obligatoire pour justifier les besoins applicatifs, la dynamicité des applications ainsi que le placement. Les besoins sont pris en compte ainsi que les propriétés des sites du domaine. Nous avons transformé la plateforme en utilisant le langage JAVA et l ORB du J2SDK de Sun pour nous libérer des contraintes liées au type de processeur ainsi qu au système d exploitation. Ce langage est gage de portabilité. Nous avons créé un langage logique basé sur des opérateurs logique nous permettant l écriture et l expression des besoins applicatifs ainsi que les propriétés des sites. Nous avons ajouté des interfaces d administrations pour les moniteurs d informations afin de les activer, les configurer ou les désactiver. Nous avons aussi ajouté des stratégies réactives pour déclencher des alarmes lorsque des événements importants surviennent dans les besoins des application. Les autres principes de base de l architecture de base n ont pas été réellement modifiées. Il subsiste, cependant, des limitations Les limitations actuelles Les limitations de notre modèle se situent plus à un niveau de l expression des besoins et du domaine du réseau local. Notre base de test est toujours un réseau local. La notion de multi-domaines reste toujours valide mais n est pas implémentée. Cependant, il est malgré tout possible de prendre en compte les coûts financiers de transfert, etc. La topologie n est pas directement utilisable, mais peut l être par la spécification des débits sur le réseau. Par exemple, deux machines reliées par un hub/switch 100Mbits peuvent être équipées, l une d une carte ethernet à 10Mbits et l autre à 100Mbits ou bien évoquer les difficultés liées aux firewall. La topologie du réseau est ici donnée en fonction du débit maximal accepté par la machine la plus faible. Ceci peut être vital, si une application a besoin d un minimum de 100Mbits pour ses échanges. L expression des besoins applicatifs, que ce soit en terme de contraintes ou de préférences, ainsi que les propriétés des sites du réseau doit être représentative. En effet, même s il est possible d énoncer un très grand nombre de besoins et de propriétés, il faut prendre garde que cette masse d informations risque de diluer les informations les plus essentielles et/ou les plus importantes. Ces différences architecturales et limitations nous amènent à une réflexion sur les informations pertinentes essentielles à prendre en compte et à utiliser correspondant aux besoins de propriétés standards ou habituellement utilisées pour caractériser nos composants L ensemble des informations Nous énonçons l ensemble des informations que nous considérons importantes du point de vue de notre modélisation et de notre appréhension d un système de répartition de charge à composants expressifs. Pour cela, nous nous penchons plus particulièrement sur les besoins applicatifs et les propriétés. Nous découpons ces informations en cinq familles : La charge processeur : c est un paramètre important du placement automatique dans un

111 6.5. LE SERVICE DE PLACEMENT GO 111 réseau local. Lorsqu un composant doit être migré, le service de placement vérifie auparavant si les conditions de charge sont bien conformes sur le site cible de la migration. La charge réseau : ce paramètre est également important pour le placement lors de la recherche d une optimisation des communications et du débit. La migration d un composant peut avoir lieu pour permettre une meilleure utilisation des communications et des relations entre les différents composants concernés. Les contraintes des composants : elles sont susceptibles d intervenir dans le placement automatique des applications lors de leur utilisation. Elles sont inhibitrices, comme des vetos, et traduisent la présence d une ressource nécessaire à l exécution d un composant. Si la ressource n est pas présente, l exécution du composant n est pas possible. Par exemple, le type de processeur, la quantité de mémoire vive, le type de système d exploitation sont des informations qui, de notre point de vue, sont pertinentes et importantes. Nous pouvons également citer, la colocation d un composant avec un autre qui peut aussi entraîner le placement la migration d un composant afin de satisfaire à cette contrainte. Un grand nombre de contraintes, même s il permet de mieux caractériser les composants n est peut-être pas toujours souhaitable. Les préférences des composants : ce sont des informations qualitatives, par exemple, la mise à disposition d un débit de réseau permettant à un serveur d assurer une bonne qualité de service. Par contre, un débit inférieur n empêche pas le serveur de s exécuter. Elles servent généralement à affiner la connaissance des composants et, le cas échéant, départager des sites satisfaisant les contraintes de ces composants lors de placements ou de migrations. Elles sont considérées comme facultives mais sont pondérées pour permettre un classemnt suivant un pourcentage d importance. Nous pouvons affirmer qu il n y a pas, au pire lorsque chaque pondération est égale, de préférences plus importantes que d autres, exception faite lors du départage de plusieurs sites égaux au niveau des contraintes demandées. La multiplication des préférences peut impliquer une certaine dilution des informations. Les propriétés des sites : ce sont généralement les caractéristiques majeures des machines (processeurs, mémoires, disques durs, applications installées, systèmes d exploitations, imprimantes, etc). Elles permettent la mise en regard des besoins applicatifs avec les propriétés des machines. Un nombre excessif de propriétés provoque, tout comme pour le cas des contraintes, une dilution des informations importantes. Cette réflexion, nous permet d implémenter les changements et les solutions de notre problème dans le service de placement GO. 6.5 Le service de placement GO Nous traitons ici des aspects pratiques de l implantation d un service de gestion des besoins applicatifs au sein du système de placement GO. Nous évoquons également les structures de données qui sont employées. Le Gestionnaire d Objets (GO) est prévu pour fonctionner dans un environnement de réseau local. Le système GO de se compose de trois modules importants : Un gestionnaire d informations de charge (LOAD), serveur chargé de calculer la charge locale et de collecter les informations de charge nécessaires sur les autres sites. Un gestionnaire d informations (COMOBS), serveur chargé de centraliser les informations liées aux communications entre objets. C est ce serveur qui implante le graphe

112 112CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS relationnel et sa mise à jour. L observation du graphe, liée au modèle de dérive des connaissances, est réalisée par ce serveur. C est lui qui détecte les déséquilibres apparaissant dans les relations et donne au serveur de placement le contexte des composants créant ces déséquilibres. Un gestionnaire de placement (POM), serveur chargé de gérer les déplacements de composants entre le site courant et les autres sites. Les serveurs POM coopèrent pour obtenir un placement optimum. Sur un site, le serveur POM coopère avec les serveurs LOAD et COMBOBS pour déterminer les objets candidats au déplacement tout en tenant compte des informations sur leur représentation dans le modèle relationnel et des valeurs de charge des sites impliqués. [Cha99] étend ce modèle aux multi-domaines avec un début de gestion des contraintes liés à ces domaines comme sur la figure 6.1. GO domaine Contrat Contrainte Domaine Domain Authority Autre domaine Sites POM POM POM LOAD COMOBS LOAD COMOBS LOAD COMOBS GO Site GO Site GO Site Fig. 6.1 Architecture du GO-Domain Un gestionnaire de domaine (Domain Authority) qui est chargé de la gestion des interactions inter-domaines (sous forme de contrats et de contraintes). C est lui qui autorise ou non le placement ou déplacement inter-domaines et la diffusion des services. Un gestionnaire de contraintes de domaine qui constitue un vérificateur de contraintes (Constraint Enforcer) et le dépôt de contraintes applicatives (Constraint Repository). Il prend en compte quelques contraintes applicatives (sécurité, débit, matériel) sur le domaine pour parfaire le placement ou le déplacemnt inter-domaines. Un gestionnaire de contrats qui offre les services pour la mise à jour et le stockage des contrats. L ensemble de ces gestionnaires sont le cœur de l ancien système GO. Nous devons maintenant expliciter notre point de vue sur le placement du nouveau système Le modèle du placement du GO Nous considérons plusieurs cas possibles dans l optimisation du placement des composants par le système GO :

113 6.5. LE SERVICE DE PLACEMENT GO 113 Le composant-serveur est placé sur le même site que le composant-client, donc les contraintes de ce composant sont, au minimum, satisfaites. En effet, lors du placement, chaque contrainte est vérifiée pour son adéquation avec l environnement cible. Si les contraintes d exécution sont satisfaites, alors le placement est possible. Dans le cas où les deux composants sont localisés au même endroit, la charge processeur peut être considérée, si elle n excède pas la puissance de calcul maximale du processeur, comme optimale. Nous parvenons à une situation assez bonne du point de vue de l occupation processeur. Au delà des 100% d occupation processeur, nous devons sans doute déplacer l objet sur un autre site moins chargé dont les propriétés satisfont les besoins de cet objets au mieux. Le composant-serveur est placé sur le même site que le composant-client ce qui implique que les contraintes de cet objet sont, au minimum, satisfaites et, dans ce cas, la communication est considérée comme optimale puisque locale. Si deux composants interagissent beaucoup localement, ceci permet de décharger le réseau de ce volume de communication. C est une situation que nous chercherons à obtenir. Cependant, si les besoins du composant changent et ne correspondent plus aux ressources offertes sur le site où il est placé, nous devrons le déplacer sur un site répondant à ces nouvelles contraintes d exécution. La communication ne sera alors plus optimale d où un antagonisme possible pour la décision d optimisation du placement. Les deux composants se trouvent sur des sites différents. Chaque composant est satisfait des propriétés de son environnement, mais la communication n est pas optimale, puisque non locale. La distribution de la charge peut ou ne pas être optimale, si respectivement les deux sites sont chargés au maximum ou sous chargés. Si aucune mesure de proximité n est intégrée au choix du placement (un des composants ayant une contrainte de colocation avec l autre), nous pouvons, avec les autres critères précédents, nous rapprocher d un optimum global du point de vue charge et respect des besoins applicatifs (l optimisation parfaite est un optimum sur tous les critères mais, comme nous l avons déjà évoqué, est assez difficile à réaliser du fait des antagonismes possibles). Si les besoins applicatifs changent, comme par exemple si les composants désirent être situés sur le même site, il faudra déplacer l un des composants tout en vérifiant que les propriétés du site cible répondent bien à ces nouvelles contraintes et préférences. Il est possible que cela ne soit pas le cas, alors une erreur est générée. Les algorithmes de placement sont basés sur une procédure logique pour ce qui est de la charge processeur, des communications et des besoins applicatifs. De notre point de vue, il n y a de raison pour compliquer d une manière plus importante les algorithmes de placement car le système logique est complet et autorise une grande liberté sur l expressivité. Nous détaillons ci-après les différents traitements de l architecture du système GO. Le gestionnaire GO est distribué au niveau de chaque site (Go-site) comme sur la figure 6.2. L interaction de ces différents gestionnaires permet le placement et/ou le déplacement des objets afin d obtenir des optimisations sur l exécution des applications Les traitements des gestionnaires Pour mettre en place le placement automatique ainsi que la prise en compte des besoins applicatifs dans un réseau local, nous avons ajouté au système GO un gestionnaire d information gérant les besoins applicatifs nommé ORM. Le système GO permet un calcul périodique sur les informations des composants dans les différents gestionnaires. Il n y a pas de synchro-

114 114CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS GO SITE POM LOAD COMOBS ORM Fig. 6.2 Architecture du GO-Site nisation entre chaque GO-site, puisque chaque gestionnaire peut avoir des valeur périodiques différentes pouvant être modifiées au cours du temps. Sur chaque machine du réseau (GO-Site) au moins quatre serveurs sont présents : un moniteur de charge, un moniteur de relations, un moniteur de contraintes et de préférences et un module de placement. Le système GO implante les fonctions et moniteurs (gestionnaires) suivants : 1. Les gestionnaires COMOBS gèrent le graphe relationnel local des composants applicatifs. Il analyse périodiquement ce graphe pour en détecter les caractéristiques : composants ayant le plus fort taux de communication vers d autres sites, composants n ayant pas de relations locales, etc. Ils détectent aussi les composants qui provoquent une modification de l équilibre relationnel. La liste des composants et des relations est périodiquement mise à jour. Le cas échéant, une alarme est envoyée au gestionnaire POM du site qui décidera ou non un déplacement de ce composant pour rééquilibrer les relations du composant. Lorsque le module de placement le consulte, le moniteur d information lui transmet les informations qui peuvent présenter un intérêt. Chaque gestionnaire COMOBS est en relation avec les autres COMOBS de son voisinage pour échanger des informations sur le volume local et distant d autres composants gérés par d autres COMOBS. 2. Les gestionnaires LOAD vérifient le taux de charge des sites. Ils maintiennent à jour l information de charge. L algorithme de diffusion des valeurs est basé à la fois sur une diffusion statistique (en choisissant aléatoirement des sites avec lequel les valeurs sont échangées) et sur une diffusion vers les sites avec lesquels les applications locales communiquent. Cet algorithme empêche les moniteurs de charge de toujours échanger les informations avec les mêmes sites en plus de ceux concernés directement par l application. Les informations sur la charge sont calculées périodiquement. De plus, la puisance de calcul de la machine est, elle aussi, estimée. En cas de surcharge ou sous-charge (un déséquilibre grave), une alarme est envoyée au gestionnaire POM du site qui décidera ou non un déplacement du composant responsable pour réaliser une redistribution de la charge. 3. Les gestionnaires ORM gèrent les besoins applicatifs. Les besoins pris en compte sont divisés en deux catégories : (a) Les contraintes : elles sont associées au minimum de ressources nécessaires et adéquates pour qu un composant s exécute dans le système.

115 6.5. LE SERVICE DE PLACEMENT GO 115 (b) Les préférences : ce sont des informations facultatives pour permettre d affiner la connaissance des besoins du composant pour une meilleure décision de placement au niveau du serveur POM. Les ORM vérifient l adéquation des contraintes et des préférences des composants par rapport aux propriétés des sites. Les besoins sont vérifiés périodiquement pour détecter tout changement dans les contraintes et les préférences du composant. En cas de modification n entraînant plus de correspondance entre les besoins et les propriétés du site sur lequel le composant s exécute, une alarme est envoyée au gestionnaire POM du site qui pourra provoquer le déplacement de ce composant. Chaque gestionnaire ORM peut se mettre en relation avec d autres ORM afin de trouver un site apte à recevoir un composant déplacé. 4. Les gestionnaires POM prennent les décisions pour le placement et/ou déplacement des composants par l utilisation du service de migration. Ils permettent la prise en compte de la mobilité des composants et l optimisation de leur accès aux ressources. Ils reçoivent les alarmes des autres gestionnaires et prennent les décisions en conséquence. Périodiquement, ils consultent les gestionnaires LOAD, COMOBS et ORM pour prendre des décisions de placement sans attendre qu ils soient sollicités. Ceci améliore la réactivité du système. Les informations sont les suivantes : la charge d un site et sa puissance pour LOAD, l intensité de communications et/ou le déséquilibre relationnel pour COMOBS et le respect des contraintes et des préférences pour ORM. Ces quatre moniteurs permettent de gérer le placement des composants sur les sites où ils s exécutent sur un réseau local. Ils utilisent deux stratégies distinctes pour réaliser le placement Les différentes stratégies de placement Les deux stratégies qui sont employées pour le placement d un composant sont les suivantes : La stratégie proactive : elle est appliquée par le module de décision POM lors des consultations des moniteurs d informations COMOBS, LOAD et ORM pour déplacer un composant. Le graphe relationnel de COMOBS est utilisé pour identifier le composant local, et la cible distante de la migration. Si la source est surchargée, cette stratégie est appelée également source-initiative. La stratégie réactive : elle est appliquée lors des alarmes qui sont envoyées par les moniteurs d informations tels que le LOAD et ORM au module de décision POM. Lorsqu un site sous-chargé est détecté, LOAD cherche et identifie le site plus surchargé dans sa liste de site et envoie une alarme à la source. Le module de décision POM de la source cherche un composant, qui a la relation la moins active en utilisant le graphe relationnel, pour le déplacer. Il utilise effectivement une stratégie serveur-initiative. Le gestionnaire ORM peut aussi envoyer une alarme au module POM pour déplacer un composant qui a changé ses besoins de ressources (contraintes et préférences) dynamiquement et ne peut plus être satisfait par les ressources locales.

116 116CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS 6.6 L implémentation du placement Dans cette partie, nous allons expliquer les mécanismes du placement du système GO ainsi que l implémentation du gestionnaire de besoins applicatifs ORM. Le placement tient compte de l hétérogénéité des plateformes, de la sécurité, de la présence de ressources matérielles et/ou logicielles. Les propriétés d un site sont des attributs tels que le processeur, le niveau de sécurité, le type de système d exploitation, le débit d une ligne et le type d architecture matérielle. Elles sont gérées par le gestionnaire ORM. Ce gestionnaire est en mesure d évaluer la cohérence entre ces propriétés et les contraintes et préférences d un composant. Ce serveur offre une interface pour positionner et lire dynamiquement les valeurs des propriétés du site. La vérification exprimée est simple et utilise des notions logiques, mais ne dépend pas du type de propriétés. Certaines sont quantitatives (les contraintes) et d autres qualitatives et pondérées (les préférences). Dans le cas des contraintes, il est nécessaire que l attribut recherché soit défini sur au moins l un des sites du réseau. Par exemple, une contrainte sur le type de processeur implique que le site sur lequel le composant sera exécuté devra possèder ce genre de processeur dans ses propriétés. Pour permettre et réaliser la migration, le service de cycle de vie et les factory sont utilisés [Pet97] et implémentés en JAVA. L utilisation de JAVA participe et concrétise également la migration dans un environnement hétérogène. Ensuite, une factory va créer un nouveau processus et transférer le composant et son état sur le site cible. Le site sur lequel est placé le composant dépend de la décision de migration choisie. Si la décision de migration n autorise le placement que sur un seul site alors le composant est placé et s exécute sur ce site. Si la décision de migration autorise le placement sur un ensemble de sites, c est le gestionnaire ORM qui choisit le site qui est soit le meilleur (respectant les contraintes et les préférences) soit le premier meilleur site en cas d ex-aequo. Les critères de décision du placement sont basés sur le calcul d indicateurs, des informations de communication, de charge et des besoins des composants. Il est obligatoire de faire un choix sur l élément principal du processus de décision. Nous prenons en compte les besoins applicatifs. Par exemple, pour les contraintes, il suffit de vérifier si le déplacement du composant vers un site ne va pas à l encontre d une seule propriété du site cible. Pour les préférences, il est possible de mettre en place une échelle de valeurs, permettant de les calculer et de les comparer. Pour réaliser la prise de décision, nous utilisons une procédure logique permettant d agréger l ensemble des différents critères La procédure de décision logique Lorsque toutes les informations ont été collectées et calculées, il convient alors d agréger l ensemble des indicateurs critères pour réaliser une décision de placement ou de déplacement d un composant. Les critères de charge, de communications et de besoins applicatifs sont évalués en une seule procédure logique. Elle utilise des prédicats pour évaluer différents critères pour la construction de la décision. Son principe est simple et repose sur le modèle suivant : Si le site cible satisfait les contraintes d exécution du composant alors on agrège les évaluations des informations de charge, de communications et de préférences applicatives. L évaluation finale sera comparée à un seuil paramétrable à partir duquel le placement est possible et est source d optimisation. Si l évaluation est supérieure ou égale au seuil alors il y aura placement ou déplacement du composant. Inversement, si le site ne satisfait pas les contraintes d exécution du composant et il est

117 6.7. LE GESTIONNAIRE ORM 117 nécessaire de trouver un autre site candidat pour le placement. Le module ORM peut alors proposer, s il existe, un site satisfaisant les besoins du composant. S il n existe pas alors une erreur est générée, sinon on réitère la méthode précédente pour vérifier l intérêt du placement sur le site trouvé. En définitive, il faut qu à la fois les contraintes soient satisfaites, la charge processeur et l intensité de communication soient au-dessus d un certain seuil paramétrable et que les préférences du composant soient prises en compte le plus possible. Ceci engendrera un placement ou un déplacement d un composant dans le système Résumé Pour réaliser un placement ou un déplacement de composants nous utilisons la méthode suivante : dès que le gestionnaire POM détecte une nécessité de placement par consultation du COMOBS et/ou du LOAD, il demande au gestionnaire de besoins applicatifs ORM d évaluer les besoins du composant par rapport aux propriétés du site élu pour la migration. Si le site cible satisfait toutes les contraintes et offre une meilleure qualité de service (à propos des préférences du composant) alors POM donne l ordre de migrer le composant, avec l utilisation de l analyse logique de la procédure de décision par agrégation du point de vue des communications, de la charge et des besoins applicatifs. Si les besoins du composant ne peuvent pas être satisfaits par le site en question, ORM proposera un site candidat, satisfaisant les contraintes de ce composant, pour cette migration et le composant pourra être déplacé sur un autre site. Ce choix sera guidé par la selection du meilleur site satisfaisant les besoins et les autres critères, soit par le choix du premier site de sa liste lors d ex-aequos. Nous détaillons ci-après le gestionnaire ORM. 6.7 Le gestionnaire ORM Le serveur ORM gère les besoins des composants. Avec ce nouveau serveur, nous respectons la Trading Object Service Specification de CORBA [OMG98, OMG90]. En effet, l IDL standard des propriétés est utilisé ainsi que les opérateurs de l OMG Constraint Language. Le serveur ORM permet de prendre en compte la problématique de l hétérogénéité au niveau du site dans un même domaine. Une liste de composants locaux est construite dans chaque serveur ORM. La gestion des ressources offertes de la machine hôte est également prise en compte. Le serveur ORM peut évaluer les composants par rapport aux ressources offertes locales du site. Cette évaluation sera prise en compte ensuite par le serveur de placement POM. Le serveur ORM utilise des fonctions pour l administration, la communication avec d autres serveurs ORM, des fonctions de mise à jour de ses informations et des fonctions de calculs. La plupart des fonctions, hors calculs, sont accessibles par des interfaces Les interfaces du module ORM Le module ORM dispose de trois interfaces (administration, dialogue avec les modules POM, dialogue avec d autres modules ORM ). L interface d administration permet : d assigner des contraintes et/ou des préférences pour les lier à un composant, de récupérer des contraintes et des préférences d un composant pour leurs comparaisons au sein d un autre ORM,

118 118CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS d assigner des propriétés matérielles et logicielles au site sur lequel le moniteur ORM s exécute. L interface de dialogue avec le module décisionnel POM permet : d évaluer un composant par rapport à un site donné, de proposer un site satisfaisant le composant lorsque le module POM le demande. d indiquer qu un composant a été déplacé afin de le supprimer de la liste des composants gérés par le moniteur ORM du site initial. L interface de dialogue entre les différents moniteurs ORM permet de recevoir les propriétés matérielles et logicielles d un site pour réaliser un calcul et vérifier l adéquation d un composant par rapport à un autre site. Par conséquent, le moniteur ORM est un module informationnel et peut évaluer des composants par des modes de calculs que nous exposons ci-après. Ces calculs se font en regard des propriétés des sites La définition des propriétés Les propriétés d un site correspondent aux caractéristiques hardware ainsi que l environnement logiciel qu il comprend. Elle sont créées dans le but de calculer et de permettre une analyse automatique. D un point de vue hardware les caractéristiques sont assez stables dans le temps. Par exemple, nous pouvons exprimer le type de processeur, la quantité de mémoire vive, le type de carte vidéo, etc. Par définition, il est possible d ajouter, d ôter ou de modifier dynamiquement ou non les informations sur le site que nous voulons décrire. Nous présentons ici un exemple de propriété d une machine FOO : Pentium3 1Ghz 256MB de RAM HD 20 GB Carte Réseau 100Mb Un des problèmes que nous rencontrons se situe sur l expression de ces informations. Les différentes propriétés possibles nécessitent la construction d un langage nous permettant d exprimer ces informations d une manière synthétique pouvant être calculées et comparées par la suite. Une première réponse a été apportée par [Cha99] qui utilise de simples valeurs numériques pour répresenter les informations (par exemple un niveau de sécurité variant de 1 à 4). Cependant, ce modèle n est pas suffisant car il ne permet pas d utiliser un système de résolution et de comparaison logique pour effectuer les différents calculs et ne gère pas les besoins applicatifs. De plus, il se trouve limité par le petit nombre et les possibilités d expression des propriétés prises en compte. Nous avons orienté notre reflexion sur un langage typé, pouvant être traité rapidement de façon logique et autorisant une grande expressivité des informations. Ces informations doivent être mises sous forme de prédicats afin de les traiter par un système logique. Nous détaillons ci-après la construction de ce langage Le langage de contraintes Nous avons créé une grammaire qui est la base de notre langage de contraintes. Elle est un langage de forme logique basé sur des opérateurs de comparaison logique. Ces opérateurs sont les suivants : >, <,,,! =, ==, && (ET logique), (OU logique). Ce langage se veut simple pour permettre une vérification dynamique rapide. C est un compromis entre expressivité et efficacité. Ce langage permet de construire des prédicats et/ou une liste de

119 6.7. LE GESTIONNAIRE ORM 119 prédicats pouvant décrire les besoins applicatifs et les propriétés des sites. Nous présentons les différentes grammaires dans les annexes A et B. Par exemple, les propriétés de la machine Foo seraient exprimées de cette manière : <?xml version="1.0" encoding="iso "?> <MACHINE> <IDENTITY> Foo </IDENTITY> <DECLARATIONS> <PROPERTY> <PROPERTYNAME> CPU </PROPERTYNAME> <OPERATOR> == </OPERATOR> <PROPERTYVALUE> Pentium3 </PROPERTYVALUE> </PROPERTY> <OPERATOR> && </OPERATOR> <PROPERTY> <PROPERTYNAME> SPEED </PROPERTYNAME> <OPERATOR> == </OPERATOR> <PROPERTYVALUE> 1000 </PROPERTYVALUE> </PROPERTY> <OPERATOR> && </OPERATOR> <PROPERTY> <PROPERTYNAME> RAM </PROPERTYNAME> <OPERATOR> == </OPERATOR> <PROPERTYVALUE> </PROPERTYVALUE> </PROPERTY> <OPERATOR> && </OPERATOR> <PROPERTY> <PROPERTYNAME> HD </PROPERTYNAME> <OPERATOR> == </OPERATOR> <PROPERTYVALUE> </PROPERTYVALUE> </PROPERTY> <OPERATOR> && </OPERATOR> <PROPERTY> <PROPERTYNAME> NIC </PROPERTYNAME> <OPERATOR> == </OPERATOR> <PROPERTYVALUE> 100 </PROPERTYVALUE> </PROPERTY> </DECLARATIONS> </MACHINE> Par souci de rapidité et de simplicité, ce langage n est pas relatif à la sémantique des informations, c est à dire qu il n utilise que la forme des informations et non leurs significations. Ce langage est à la base d un mini-moteur de traitement de prédicats qui sont crées à partir de la grammaire. Le traitement est très rapide puisque pour 125 prédicats, le temps de traitement n est que de quelques dizaines de millisecondes. Ceci est rendu possible par l utilisation d une sorte de pattern matching qui implique que le sens des descriptions n est pas évalué et, par conséquent, que le traitement est beaucoup plus simple. En résumé, ce langage nous permet de spécifier les propriétés matérielles et logicielles des sites de manière logique. De la même façon, ce langage est utilisé pour exprimer les besoins applicatifs. Une application ou un composant, peut grâce à ce langage, exprimer ses contraintes et ses préférences d exécution. Un composant peut avoir une ou plusieurs contraintes et/ou une ou plusieurs préférences exprimées sous forme de prédicats.

120 120CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS Les contraintes et les préférences Avec la même méthode que celle des propriétés des sites, nous pouvons également créer des prédicats pour exprimer les contraintes et les préférences des composants. Par exemple, nous pouvons décrire un composant serveur nommé Yong qui a les contraintes et les préférences suivantes : un processeur de type Pentium 3, au moins 128MB de RAM, une carte réseau 100Mb, Yong prefèrerait une quantité de 512MB de RAM avec une préférence pondérée à 70% ou un processeur de type Pentium2 avec une préférence pondérée à 30%. Nous avons énuméré un exemple de contraintes et de préférences pour le composant nommé Yong. Les trois premières informations correspondent à des contraintes d exécution et la quatrième à des préférences d exécution. Pour chaque préférence, une pondération est associée afin d exprimer une relation d ordre entre les diiférentes préférences. Dans l exemple précédent, la préférence de 512Mb de RAM à 70% aura plus d importance que celle de Pentium2 à 30%. Ceci revient à dire que le composant préfère plutôt une quantité de RAM plus importante qu un processeur de type inférieur pour son exécution. La somme des pourcentages de ces deux préférences est égale à 100% qui correspond à la valuation totale de l ensemble des préférences. L expression de ces besoins dans notre langage s énonce comme suit : <?xml version="1.0" encoding="iso "?> <COMPONENT> <TYPE> <S> <IDENTITY> Yong </IDENTITY> <DECLARATIONS> <CONSTRAINT> <CONSTRAINTNAME> CPU </CONSTRAINTNAME> <OPERATOR> == </OPERATOR> <CONSTRAINTVALUE> Pentium3 </CONSTRAINTVALUE> </CONSTRAINT> <OPERATOR> && </OPERATOR> <CONSTRAINT> <CONSTRAINTNAME> RAM </CONSTRAINTNAME> <OPERATOR> >= </OPERATOR> <CONSTRAINTVALUE> </CONSTRAINTVALUE> </CONSTRAINT> <OPERATOR> && </OPERATOR> <CONSTRAINT> <CONSTRAINTNAME> NIC </CONSTRAINTNAME> <OPERATOR> == </OPERATOR> <CONSTRAINTVALUE> 100 </CONSTRAINTVALUE> </CONSTRAINT> <PREFERENCE> <WEIGHT> 70.0 </WEIGHT> <PREFERENCENAME> RAM </PREFERENCENAME> <OPERATOR> >= </OPERATOR> <PROPERTYVALUE> </PROPERTYVALUE> </PREFERENCE> <OPERATOR> </OPERATOR> <PREFERENCE> <WEIGHT> 30.0 </WEIGHT> <PREFERENCENAME> CPU </PREFERENCENAME>

121 6.7. LE GESTIONNAIRE ORM 121 <OPERATOR> == </OPERATOR> <PREFERENCEVALUE> Pentium2 </PREFERENCEVALUE> </PREFERENCE> </DECLARATIONS> </S> </TYPE> </COMPONENT> Les besoins des composants sont généralement fixés mais peuvent être sujet à un changement rapide et dynamique. Nous pouvons, tout comme l application et/ou le composant, modifier dynamiquement les besoins (ajouter, enlever, modifier les informations nécessaires) par l utilisation des interfaces d administrations et de dialogues du module ORM que nous avons préalablement explicitées. A partir de cette formalisation des propriétés des sites et des besoins applicatifs des composants, nous pouvons effectuer des calculs sur les contraintes et les préférences Le calcul des contraintes Le calcul de contraintes est le premier calcul effectué pour vérifier l adéquation des contraintes d un composant avec les propriétés d un site. En effet, le respect des contraintes du site est le minimum à prendre en compte pour le placement ou la migration d un composant. Ce calcul représente le premier critère défini au sein de notre module ORM. La séquence de contraintes du site est de la forme suivante : un champ contenant le nom de la contrainte et un champ contenant la valeur de la contrainte. Les propriétés (contraintes) du site sont comparées aux contraintes du composant. On vérifie, l une après l autre, que chaque contrainte du composant est présente dans la séquence des propriétés du site. Si la contrainte est trouvée dans l ensemble des propriétés du site, on compare alors sa valeur avec celle du composant tout en prenant en compte l opérateur logique de contrainte du composant. Si l opération logique entre la valeur de contrainte du site et celle du composant est vraie alors cette contrainte est satisfaite, on réitère alors la comparaison avec les autres contraintes du composant et des propriétés du site. On obtient les règles de calculs suivantes : si la séquence de contraintes du composant satisfait la séquence de propriétés (contraintes) de la machine, l évaluation vaut VRAI. Cela signifie que toutes les contraintes liées au composant sont équivalentes aux propriétés du site ou bien qu elles sont incluses dans l ensemble des propriétés du site. C est la condition sine qua non pour continuer les calculs sur les préférences. s il n y a pas satisfaction des contraintes, l évaluation vaut FAUX, c est à dire que le site ne répond pas aux exigences du composant, les contraintes deviennent l équivalent d un veto. Par conséquent, il est inutile de poursuivre les calculs sur les préférences. On peut proposer le composant concerné pour une migration car son environnement actuel ne lui convient pas. On peut résumer le calcul des contraintes par le tableau suivant qui prend en compte la satisfaction d une contrainte d un composant par rapport aux propriétés d un site en utilisant les différents opérateurs logiques : Par exemple, le résultat de l évaluation d une contrainte demandant une quantité de mémoire vive > 256MB (RAM > 256) par rapport à une propriété d un site disposant de 128MB (RAM == 128) renverra F AUX. Il faut noter que si une contrainte d un composant ne se retrouve pas dans les contraintes du site (nom de la contrainte introuvable), l arrêt est immédiat car les contraintes de ce com-

122 122CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS Opérateurs contrainte contrainte satisfaite non-satisfaite >, <,,,! =, == VRAI FAUX Tab. 6.1 Opérateurs et évaluations associées des contraintes posant ne seront pas satisfaites. Le calcul des préférences du composant est réalisé seulement lorsque les évaluations des différentes contraintes sont vraies ou lorsque le composant n a pas de contraintes Le calcul des préférences Le calcul des préférences utilise la même base que le calcul des contraintes. Cependant, cette évaluation peut être vue comme un paramètre de raffinement valué des contraintes. Si un composant n a pas de préférence, une valeure moyenne lui est attribué. Nous utilisons les opérateurs logiques de comparaison pour les calculer. La pondération sur les préférences ajoute une notion d importance entre les différentes préférences et permet de rendre une évaluation chiffrée en pourcentage. La somme des préférences doit obligatoirement être égale à 100%. Le rôle de l administrateur, du programmeur et de l utilisateur est de s assurer que la somme des poids fait bien 100%. L évaluation des préférences se situe dans l intervalle [-100%, 100%] avec -100% la plus faible importance et 100% la plus forte. Cet intervalle nous permet d avoir un critère normalisé pour les calculs qui suivront. Ces calculs évaluent les préférences d un composant par rapport aux propriétés liées à un site. C est le deuxième critère qui est défini dans le module ORM. Le calcul, tout comme celui des contraintes, ne prend pas en compte la sémantique des informations. Après avoir évalué les contraintes puis les préférences, il est nécessaire d agréger ces deux critères pour permettre la construction d un avis sur la concordance des besoins applicatifs d un composant en regard des propriétés d un site L agrégation des critères L agrégation des critères est possible si la satisfaction des contraintes est réalisée. On réalise alors une moyenne de ces deux critères avec des paramètres identiques associés aux critères. On peut résumer l agrégation de ces critères de la façon suivante : Soit f une fonction de calcul, E le résultat global de l évaluation. Soit n le nombre de préférence. Soit W le poids associé à chaque préférence. Si (f (contraintes) == FAUX) E = F AUX Si (f (contraintes) == VRAI) E = i=n i=0 f i(p reference i ) Wi=n i=0 et E [ 100, 100] Nous avons modélisé les calculs des différents critères des composants présents dans le serveur ORM. Le critère E, issu de l agrégation des critères de contraintes et de préférences sera ensuite envoyé au serveur POM, à sa demande, afin de construire le critère global utilisant les informations du serveur LOAD et du serveur COMOBS. A partir de l évaluation globale par le serveur POM, une décision de placement ou de migration sera mise en place par l utilisation de la procédure logique de décision. Nous présentons dans le chapitre suivant les

123 6.8. CONCLUSION 123 résultats obtenus lors des tests. Cependant, il est assez difficile d obtenir certains tests car nous pouvons nous situer parfois dans un domaine d optimisation qualitative. 6.8 Conclusion La prise en compte de la notion de besoins applicatifs nécessite l introduction de contraintes et de préférences ainsi qu un langage et une grammaire logique permettant de les exprimer, de les calculer et de les utiliser par la mise en œuvre d une procédure de décision logique. Dans ce contexte, le placement ne cherche plus seulement à optimiser la charge par répartition des composants mais également à satisfaire des contraintes et/ou des préférences liées aux applications en regard des propriétés des sites du réseau. L approche utilisée doit être capable de définir un environnement logiciel permettant une expression de ces besoins et de ces propriétés, aussi bien au niveau du développement pour le programmeur mais aussi au niveau de l exécution pour l administrateur et l utilisateur.

124 124CHAPITRE 6. UN GESTIONNAIRE DE PLACEMENT À COMPOSANTS EXPRESSIFS

125 Chapitre 7 Les tests Nous présentons, dans ce chapitre, les tests réalisés pour valider notre approche ainsi que notre modèle. Nous avons utilisé notre système GO pour le déploiement d applications, qui utilise l ensemble des paramètres dont nous avons besoin, pour créer des tests réels. Nous avons utilisé des plans de tests pour prouver le bien fondé de notre approche. Ces plans de tests sont, pour certains, basés sur ceux utilisés par [Cha99]. Ceci nous permet de comparer nos résultats avec ceux obtenus sur l ancienne plateforme. Mais, nous devons rappeler que le nombre de paramètres que nous pouvons utiliser lors de nos tests est beaucoup plus grand que dans le modèle de [Cha99] ce qui implique que dans de nombreux cas, ces tests sont empiriques car il est souvent difficile de trouver les paramètres adéquats pour effectuer et déployer de manière optimale nos applications. Afin de resteindre le nombre important de choix de paramètres possibles, nous utilisons la méthode Taguchi pour limiter les plans d expériences, pour montrer les interactions entre les paramètres et les différents types d applications. Certains tests montrent des gains quantitatifs et d autres des gains qualitatifs mais ils illustrent à la fois le comportement des applications et celui de notre système GO. Pour valider notre approche, les tests sont réalisés sur au moins quatre machines non homogènes. En effet, l hétérogénéité est un point fondamental de notre étude, les machines de test sont donc différentes dans leur configuration matérielles et souvent logicielles. La seule restriction est liée au langage utilisé JAVA ainsi qu au système d exploitation des machines fonctionnant sous LINUX même s il est possible d utiliser des machines fonctionnant sous Microsoft Windows. Par l utilisation d interfaces d administration sur les serveurs administrant les objets, nous pouvons évaluer un nombre important de paramètres et de scénarios de test et modifier dynamiquement les paramètres décisionnels et exécutifs pour qu ils s adaptent aux besoins des applications et aux besoins de leurs exécutions. 7.1 La plateforme de tests Le système GO est dorénavant implémenté entièrement sous langage JAVA. De nombreuses modifications ont été apportées, ne serait-ce que pour répondre à notre problématique mais également pour utiliser les principes propres de la programmation sous JAVA. En effet, l impossibilité de faire de l héritage multiple a néccessité la réalisation de nombreuses modifications en terme d architecture de composants et de classes. Tout ceci nous a aidé à clarifier notre code et à présent le système est pleinement fonctionnel. Cette plateforme de test va nous permettre d évaluer notre système. Notre système se compose d au moins quatre machines, 125

126 126 CHAPITRE 7. LES TESTS du système gestionnaire GO implémenté en JAVA et de différents jeux d essai. Les machines utilisées sont des compatibles PC reliées par un réseau Ethernet dont les caractéristiques diffèrent. Nous présentons dans le tableau 7.1, les caractéristiques de nos machines de tests : Machines PC 1 PC 2 PC 3 PC 4 PC 5 Viviane Yvain Grappe Enide Arthur Type CPU Pentium Xeon Pentium Xeon Athlon Pentium 3 Pentium 2 Fréquence 1800 Mhz 1800 Mhz 1000 MHz 1130 Mhz 400Mhz RAM 512MB 512MB 512MB 256MB 256MB HD 80Go 80Go 40Go 40Go 36Go NIC 100Mbits 100Mbits 100Mbits 100Mbits 10Mbits OS RH 7.2 RH 7.2 RH 9.0 RH 8.0 RH 9.0 Noyau Version JRE b b b b b06 Tab. 7.1 Caractéristiques des machines de test Nous utilisons ces différentes machines pour réaliser et exécuter deux types de tests : Les tests qui permettent la validation du système JAVA de placement GO en rapport avec l ancienne maquette de [Cha99] intra-domaine. Les tests qui permettent la validation de notre modèle avec gestion des besoins applicatifs intra-domaine. Nous présentons ci-après l architecture de notre système GO nous permettant de créer et administrer des simulations d applications réelles Le simulateur d applications Le but de ce simulateur est d imiter les différents types d applications avec la possibilité d utiliser et de réaliser des tests systèmatiques sur les différentes configurations applicatives possibles. De plus, dans notre environnement distribué, la création d une vraie application n est pas aisée, ne serait-ce qu au niveau coût et temps de développement. Or, nous désirons parcourir et tester le plus large éventail possible de types d applications et ne pas nous restreindre à une seule application spécifique. Le système GO nous permet de nous affranchir de la limitation d une seule application car il autorise, à partir de fichiers de configuration, de lancer une application basée sur des composants (serveurs, clients/serveurs, clients) possèdant un comportement non figé et dynamique au cours du temps. Pour le lancement et le déploiement des applications et des composants, le système GO utilise quatre serveurs principaux : 1. Le serveur de lancement des applications Starter qui permet la création des objets et par extension des applications. Les objets l interrogent ensuite pour connaître leurs paramètres d exécution. Les paramètres et la configuration des applications sont définis dans divers autres fichiers. 2. Le serveur de gestion des événements et des traces Event qui mémorise et inscrit dans des fichiers de résultats le début et la fin de l exécution des objets, les migrations des serveurs, des clients/serveurs ainsi que le nombre d invocations réalisées pendant l exécution des clients.

127 7.1. LA PLATEFORME DE TESTS Le serveur de paramétrage ParamGo permet le paramétrage des gestionnaires LOAD, COMOBS, ORM et POM par l utilisation de fichiers de paramètres. 4. Le serveur principal Master qui lance l exécution des serveurs Starter, Event et ParamGo. Il est possible d exécuter plusieurs tests successifs par l utilisation de plans de tests. Ces plans de test sont organisés par plusieurs fichiers de paramètres (configuration de l application, paramétrage des objets et résultats). MASTER STARTER LANCEMENT COMPOSANT EXECUTION EVENT DEBUT/FIN COMPOSANT PARAMETRES D EXECUTION COMPOSANT EXECUTION SUR SITE APPLICATION GO SITE PARAMGO POM PARAMETRES POM/LOAD/COMOBS/ORM LOAD COMOBS ORM Fig. 7.1 Architecture des différents services Nous illustrons ces quatre serveurs sur la figure 7.1, ils sont les piliers du système GO. Chaque application est créée à partir d un fichier de paramètre. Nous détaillons dans le paragraphe suivant un exemple de fichier de paramétrage d une application Un exemple de paramétrage d une application Nos tests sont semblables de ceux réalisés par HY. Chan [Cha99]. De plus, nous avons ajouté la notion de besoins applicatifs et de propriétés dans le principe de décision lors de la normalisation des différents critères (charge, communication, besoins).

128 128 CHAPITRE 7. LES TESTS Le fichier de paramètres génériques Nous présentons et explicitons ci-après les informations de base (paramètres) pour la configuration des composants. c objectname domainname sitename delay duration cpuconsum io nbserverinvoc servername start duration garde volume i objectname domainname sitename nbloop cpuconsum io nbserverinvoc servername garde volume nbconstraints name operator type value nbpreferences name operator type value percentage s objectname domainname sitename nbloop nbconstraints name operator type value nbpreferences name operator type value percentage Un exemple de fichier de paramètrage Nous décrivons et explicitons un exemple de fichier de paramétrage d une application composée d un serveur, d un client/serveur et d un client : Le serveur <?xml version="1.0" encoding="iso "?> <COMPONENT> <TYPE> <S> <DOMAINNAME> Viviane </DOMAINNAME> <SITENAME> Viviane </SITENAME> <IDENTITY> serv0 </IDENTITY> <DECLARATIONS> <CONSTRAINT> <CONSTRAINTNAME> CPU </CONSTRAINTNAME> <OPERATOR> == </OPERATOR> <CONSTRAINTVALUE> PENTIUM </CONSTRAINTVALUE> </CONSTRAINT> <OPERATOR> && </OPERATOR> <CONSTRAINT> <CONSTRAINTNAME> OS </CONSTRAINTNAME> <OPERATOR> == </OPERATOR> <CONSTRAINTVALUE> LINUX </CONSTRAINTVALUE> </CONSTRAINT> <PREFERENCE> <WEIGHT> </WEIGHT> <PREFERENCENAME> CPU </PREFERENCENAME> <OPERATOR> == </OPERATOR> <PREFERENCEVALUE> PENTIUM4 </PREFERENCEVALUE> </PREFERENCE> </DECLARATIONS> </S>

129 7.1. LA PLATEFORME DE TESTS 129 </TYPE> </COMPONENT> Le client/serveur <COMPONENT> <TYPE> <I> <DOMAINNAME> Viviane </DOMAINNAME> <SITENAME> Yvain </SITENAME> <IDENTITY> cs0 </IDENTITY> <DECLARATIONS> <NBLOOP> 20 </NBLOOP> <CPUCONSUM> 5 </CPUCONSUM> <IO> 5 </IO> <NBSERVERINVOC> 1 </NBSERVERINVOC> <SERVER> <IDENTITY> serv0 </IDENTITY> <GARDE> 1.0 </GARDE> <VOLUME> 1000 </VOLUME> </SERVER> <CONSTRAINT> <CONSTRAINTNAME> CPU </CONSTRAINTNAME> <OPERATOR> == </OPERATOR> <CONSTRAINTVALUE> PENTIUM </CONSTRAINTVALUE> </CONSTRAINT> <OPERATOR> && </OPERATOR> <CONSTRAINT> <CONSTRAINTNAME> OS </CONSTRAINTNAME> <OPERATOR> == </OPERATOR> <CONSTRAINTVALUE> LINUX </CONSTRAINTVALUE> </CONSTRAINT> </DECLARATIONS> </I> </TYPE> </COMPONENT> Le client <COMPONENT> <TYPE> <C> <DOMAINNAME> Viviane </DOMAINNAME> <SITENAME> Viviane </SITENAME> <IDENTITY> cli0 </IDENTITY> <DECLARATIONS> <DELAY> 1 </DELAY> <DURATION> 500 </DURATION> <CPUCONSUM> 20 </CPUCONSUM> <IO> 10 </IO> <NBSERVERINVOC> 1 <NBSERVERINVOC> <SERVER> <IDENTITY> cs0 </IDENTITY> <START> 0 </START> <DURATION> 500 </DURATION> <GARDE> 1.0 </GARDE> <VOLUME> </VOLUME> </SERVER> </DECLARATIONS>

130 130 CHAPITRE 7. LES TESTS </C> </TYPE> </COMPONENT> Nous détaillons et expliquons l ensemble des symboles et valeurs de notre exemple. La première lettre d une ligne d un fichier de paramètre correspond au type d objet à créer. s correspond à un composant serveur, i correspond à un composant client/serveur, c correspond à un composant client. Dans notre exemple, nous avons un serveur nommé serv0, un client/serveur nommé cs0 et un client nommé cli0. Nous définissons ensuite le domaine d exécution domainname, ici Viviane pour l ensemble des objets. Ensuite nous définissons les sites d exécutions sitename de chaque objet Viviane pour le serveur serv0 ainsi que le client cli0 et Yvain pour le client/serveur cs0. Nous avons, ensuite des paramètres propres à chaque entité : Le serveur Le serveur dispose de trois autres types de paramètres : 1. Un serveur fait un calcul avec les mesures nbloop lorsqu il reçoit une invocation. Il réalise un boucle de calcul lors de traitement de cette invocation. Dans notre exemple cette valeur vaut Un serveur peut avoir des contraintes nbconstraints. Dans notre exemple, serv0 a 2 contraintes (CPU == c PENTIUM OS == c LINUX) un nom de contrainte name (CPU et OS). un opérateur de contrainte operator (==). un type de valeur associée à cette contrainte type (c soit une chaîne de caractères). une valeur associée à chaque contrainte value (PENTIUM et LINUX). 3. Un serveur peut avoir des préférences nbpreferences pondérées en pourcentages. Dans notre exemple, serv0 a 1 préférence (CPU == c PENTIUM4) avec 100%. un nom de préférence name (CPU). un opérateur de préférence operator (==). un type de valeur type (c soit une chaîne de caractères). une valeur value (PENTIUM4). un pourcentage qui correspond au poids de la préférence percentage (100%) Le client Le client dispose de cinq autres paramètres : 1. Un client attend delay secondes avant de commencer ses invocations. Dans notre exemple cette valeur vaut 1 seconde. 2. Un client à une durée d exécution duration en secondes. Dans notre exemple cette valeur vaut 500 secondes. 3. Un client consomme un pourcentage de temps processeur cpuconsum. Dans notre exemple cette valeur vaut 20 unités. 4. Un client utilise un pourcentage d entrées-sorties io. Dans notre exemple cette valeur vaut 10 unités.

131 7.1. LA PLATEFORME DE TESTS Un client invoque un ou plusieurs nbserverinvoc serveurs et/ou client/serveurs nommés servername. Dans notre exemple, cli0 invoque qu un seul client/serveur cs0. Ces invocations sont réalisées avec les paramètres suivant : (a) Les invocations du client commencent à start secondes. Dans notre exemple les invocations de cli0 commence à 0 seconde. (b) Le client réalise des invocations pendant une durée duration en secondes. Ici, cli0 invoque pendant 500 secondes. (c) Les invocations s effectuent avec une probabilité garde en utilisant un tirage aléatoire. Ici, la probabilité des invocations est de 1.0. (d) Chaque invocation est composée de volume octets à transmettre par message. Dans notre exemple, le volume du message que cli0 transmet à cs0 est de octets par invocation. Les clients ne déclarent pas de contraintes ni de préférences car ils ne sont pas sujets aux déplacements. Ceci permet d exprimer et de modéliser un client réel qui, dans la plupart des cas, est immobile. Cela permet également d accentuer la dynamicité puisque, comme dans notre contexte, seules les applications peuvent se déplacer Le client/serveur Le client/serveur dispose de six autres paramètres : 1. Un client/serveur fait un calcul avec les mesures nbloop lorsqu il reçoit une invocation. Dans notre exemple cette valeur vaut Un client/serveur consomme un pourcentage de temps processeur cpuconsum. Dans notre exemple cette valeur vaut 5%. 3. Un client/serveur utilise un pourcentage d entrées-sorties io. Dans notre exemple cette valeur vaut 5%. 4. Un client/serveur peut invoquer un ou plusieurs nbserverinvoc serveurs et/ou client- /serveurs nommés servername. Dans notre exemple, cs0 invoque qu un seul serveur serv0. Ces invocations sont réalisées avec les paramètres suivants : (a) Les invocations s effectuent avec une probabilité garde en utilisant un tirage aléatoire. Ici, la probabilité des invocations est de 1.0. (b) Chaque invocation est composée de volume octets à transmettre par message. Dans notre exemple, le volume du message que cs0 transmet à serv0 est de 1000 octets par invocation. 5. Un client/serveur peut avoir des contraintes nbconstraints. Dans notre exemple, cs0 a 2 contraintes (CPU == c PENTIUM OS == c LINUX) un nom de contrainte name (CPU et OS). un opérateur de contrainte operator (==). un type de valeur associée à cette contrainte type (c soit une chaîne de caractères). une valeur associée à chaque contrainte value (PENTIUM et LINUX).

132 132 CHAPITRE 7. LES TESTS 6. Un client/serveur peut avoir des préférences nbpreferences exprimées en pourcentages. Dans notre exemple, cs0 n a pas de préférence, sa valeur est donc 0. L ensemble de ces paramètres nous permet d imiter d une manière assez simple différents types d applications pour analyser les comportements du mécanisme de notre allocation de ressource en accord avec un jeu de paramètres spécifié. Nous montrons dans le paragraphe suivant les différents tests effectués. 7.2 Les paramètres des applications L ensemble des jeux de tests effectués sont semblables à ceux réalisés par [Cha99]. Nous nous appuyons sur ces jeux de tests car ils restent valables à la fois pour notre système et pour notre problématique. Ils ont été démontrés par [Cha99] en utilisant la méthode Tagushi [Roy01]. Ces jeux de tests sont donc valides et représente une bonne base de paramètres par rapport aux applications à base de composants et ceci d une manière générale. Nous utilisons différentes valeurs pour les facteurs et exécutons différents scénarios. Nous essayons de montrer l impact des facteurs sur les performances mais aussi l impact des besoins applicatifs et des propriétés sur les performances ce même système. Nous présentons un tableau 7.2 récapitulatif des paramètres utilisés qui ne sont pas du domaine des besoins applicatifs. Pour chacun des six facteurs le choix des niveaux est réalisé de façon à répartir équitablement les expériences sur une gamme intéressante de valeurs, du point de vue de la plateforme et du type général d application. Ce tableau récapitule donc les douze expériences qui composent un plan d expérience à l aide de la méthode Tagushi. Nous pouvons ainsi simuler différents types d applications ou de groupes d applications. facteur B temps D amort R k V charge V relation S indif expérience Tab. 7.2 Le plan d expériences Nous détaillons ci-dessous la signification des différents paramètres : B temps : elle correspond à la base de temps. Elle détermine, en partie, la sensibilité de la mise à jour des informations ainsi que la quantité des ressources consommées du système. Elle est divisée en quatre niveaux : 20, 40, 80 et 100 secondes.

133 7.3. LES DIFFÉRENTS TESTS DE PERFORMANCES 133 D amort : elle correspond à la durée d amortissement qui détermine une partie de la sensibilité du système. Elle est un multiple de la base de temps soit : 1, 2, 5 et 20. R k : elle correspond aux coefficients d importance relative de la charge face aux communications sur quatre niveaux : 1, 1.5, 2 et 3. Ces niveaux sont équivalents aux couples (k charge,k relation ) suivants : (0, 0.7), (0.23, 0.47), (0.35, 0.35) et (0.47, 0.23). Le premier niveau consiste à privilégier les communications vis-à-vis de la charge et le dernier la charge par rapport aux communications. V charge : il correspond au veto sur la charge. Il spécifie l amélioration minimum sur la charge garantie lors d un déplacement. Il est basé sur quatre niveaux qui correspondent aux nombres de threads : -30, -15, 0 et 5. Une valeur négative signifie qu un déplacement ne sera pas optimal et sans doute moins bon en terme de charge. V relation : il correspond au veto sur les communications. De la même manière que V charge, Il spécifie l amélioration pour les communications et le minimum garanti lors d un déplacement. Il est basé sur quatre niveaux : -30, -15, 0 et 5. Ces quatre valeurs correspondent à des débits de communication par seconde. Une valeur positive signifie qu un déplacement doit obligatoirement améliorer les communications pour être accepté et inversement une valeur négative peut mener à un placement moins bon en terme de communication. S indif : il correspond au seuil d indifférence. Il définit la valeur minimum du critère de synthèse pour admettre un déplacement. Cette valeur, sur deux niveaux, traduit le coût de l opération de déplacement. Nous pouvons donc effectuer différents tests pour valider d une part le modèle de gestion de ressources et d autre part le même modèle avec gestion des besoins applicatifs. De plus, nous devons dans un premier temps évaluer les performances brutes du système en utilisant le langage JAVA et l ORB du j2sdk de Sun. 7.3 Les différents tests de performances Nous présentons les expériences réalisées avec notre système GO. Nous exposons, au vu des résultats, les conclusions que nous en déduisons. Nous ne pouvons pas réaliser un nombre suffisamment important de tests pour couvrir parfaitement l ensemble des applications possibles. Cependant, certains tests nous permettent de valider d une manière assez précise nos modèles. En effet, nous avons mis en évidence l utilité de notre système sur certaines applications spécifiques. Nous avons également obtenu des résultats nous permettant d affirmer dans quelle mesure notre solution n est pas efficace d un point de vue quantitatif et qualicatif. Nous avons effectué et réitéré des tests pour connaître la dépendance du système par rapport à l implémentation JAVA utilisée. Nous avons empêché toutes migrations par l utilisation de contraintes vetos, c est à dire que seuls les sites d exécution de chaque composant ont des propriétés suffisantes pour l exécution de chaque composant. En d autres termes, nous avons immobilisé chaque composant sur leur site de départ par l expression de besoins incompatibles sur les autres sites du système excepté celui d exécution initial. Cette démarche permet de vérifier le coût ainsi que la mise à l échelle de notre système. De plus, nous avons effectué ces tests sur deux machines rigoureusement identiques au niveau matériel et logiciel pour supprimer la notion d hétérogénéité du système.

134 134 CHAPITRE 7. LES TESTS Les tests ont une durée de 10 minutes et utilisent les machines PC 1 et PC 2 du tableau 7.1. Nous comptons alors le nombre d invocations effectuées par les clients pendant ce laps de temps. Nous utilisons les jeux de paramètres 1, 2 et 3 du tableau 7.2 qui ont les périodicités de rafraîchissement des informations les plus basses (20 secondes) afin que le poids de traitement de notre système soit le plus grand possible. Le graphique qui en résulte est fonction du nombre d invocations réalisées suivant les différents jeux de paramètres en ordonnée et suivant les différents tests en abcisse. Nous avons neuf tests qui représentent l augmentation du nombre de clients et de serveurs ainsi que le nombre d invocations réalisées (1s1c correspond au test 1 serveur et 1 client, 2s2c correspond au test 2 serveurs et 2 clients et ainsi de suite jusqu à 20 serveurs et 20 clients). Chaque client invoque avec une taille de message de octets le serveur qui lui est attribué. Les différents clients ont un paramètre de consommation cpu et io de zéro. Par conséquent, seules les invocations sont effectives. Fig. 7.2 Coût du système GO par rapport au nombre d objets Nous remarquons sur le graphique 7.2 que plus le système est chargé par des serveurs et des clients, plus l impact sur les performances de notre système, dans la plupart des cas, diminue. De plus, nous remarquons que le nombre maximum des invocations se situe vers Ce nombre n est pas atteint avec le premier test (1 serveur et un client) ce qui signifie que ce test n utilise pas les capacités maximales des machines. Nous pouvons en déduire que notre système et par extension l implémentation sous JAVA est assez dépendante des machines

135 7.4. LES TESTS SANS PRISE EN COMPTE DES BESOINS APPLICATIFS 135 sur lesquelles il s exécute, mais reste assez stable lors de montée en charge. En effet, le seuil maximal de traitement des machines de tests lors des invocations est en moyenne de 5200, ce qui signifie que nous atteignons le traitement maximum possible des machines pour réaliser les invocations. Nous pouvons remarquer que les histogrammes qui représentent le nombre d invocations des clients n est pas constant pour chaque client, même si leurs paramètres sont identiques. Ceci est sans doute le fait de l implémentation en JAVA et des interactions avec le noyau. Cependant, nous pouvons affirmer que lors de la répétition des différents tests, la variance du nombre d invocations des différents clients est de 15% maximum mais la somme totale des invocations réalisées est assez stable (une augmentation du nombre d invocations chez un client se traduit par une baisse du nombre d invocations chez un autre). Nous déduisons également que les différentes expériences utilisant les paramètres 1, 2 et 3 n ont pas exactement les mêmes résultats et, par conséquent, ont également un impact sur les performances lors des exécutions des tests. Même si la base de rafraichissement demeure à 20 secondes, les différents paramètres de réorganisations internes et d échanges des informations entre les modules du GO ne sont pas toujours identiques, ce qui tend à prouver que nos paramètres permettent de parcourir un panel assez large de comportements de notre système et sans doute de s adapter au mieux aux différentes applications. Nous étudions ci-après le comportement de six applications. Les trois premiers tests illustrent le gain apporté et les pertes apportées par notre système GO sans utiliser les besoins applicatifs. Ceci nous permet de mesurer l impact de l ajout des besoins applicatifs sur le comportement du système et des applications. 7.4 Les tests sans prise en compte des besoins applicatifs Le premier test montre, sur un cas précis, comment le placement, en tenant compte des communications, diffère du placement dirigé par la charge seule. Le deuxième test démontre que le système optimise les communications pour deux serveurs mal placés. Le troisième test montre les différents déplacement opérés par le système sur des objets regroupés sur un même site, en tenant compte des critères de charge et de communication Le test 1 serveur et 2 clients Ce premier test a pour objet de montrer une différence caractéristique entre un placement dirigé uniquement par la charge et un placement dirigé par la charge et par les communications. Le déplacement d une entité entre deux sites de charge équivalente permet d obtenir une optimisation du temps d exécution. Les clients sont placés sur des sites distincts, et invoquent concurremment le serveur. Au départ, le serveur réside sur le site du premier client. Le test se déroule en deux phases : 1. Pendant 1000 secondes, le premier client invoque le serveur avec un volume de 10 octets et une probabilité de 0.1 et le deuxième client distant invoque le même serveur avec un volume de octets et une probabilité de Durant la période des 1000 secondes suivantes, le schéma est inversé c est à dire que le premier client invoque le serveur avec un volume de octets et une probabilité de 1 et le deuxième client distant invoque le même serveur avec un volume de 10 octets et une probabilité de 0.1.

136 136 CHAPITRE 7. LES TESTS Fig. 7.3 La mobilité du serveur pour optimiser les communications Nous déduisons des résultats du graphique 7.3 que lors des expériences 4, 6, 7, 8 et 10 aucune migration n est réalisée et les résultats sont en moyenne un peu moins bons (environ 4%) avec l utilisation de notre système par rapport à la moyenne sans notre système. Ceci est induit par le fait que l exécution de l application testée ne peut être améliorée que du point de vue des communications et que le surcoût de notre système est faible. Il semble que l optimisation de notre système soit sujette, dans le cas 7, à des instabilités inhérentes à l implémentation du runtime de JAVA, car il n y a pas de migration mais les résultats sont un peu supérieurs aux résultats sans notre système. Nous pouvons attribuer cela aux variations du compilateur JIT Just In Time ainsi que celles du système d exploitation. Il faut ajouter que ces expériences posent des vetos importants sur la charge et, par conséquent, n autorisent pas la migration du serveur. Lors des expériences 1, 2, 3, 5, 9 et 12, les paramètres utilisés donnent une augmentation des performances. Dans ces expériences, les valeurs de veto pour la charge sont toutes négatives excepté pour le cas 2. Ceci n empêche pas le placement qui entraîne une dégradation de charge. L expé-rience 1 donne une augmentation moyenne des performances de l ordre de 23%. Les paramètres utilisés dans l expérience 1 sont les plus sensibles par rapport à l environnement (base de temps courte de 20 secondes, durée d amortissement courte de 1, vetos négatifs à -30, seuil d indifférence bas à 0.01). L expérience 1 est la meilleure, non seulement du point de vue de l augmentation des performances mais aussi de l adéquation du système par rapport à l application, car sa réponse est rapide et viable. Lors de l expérience 11, le placement engendre une baisse significative des performances d environ 12%. Ceci est dû au fait que le placement est réalisé tardivement, empêchant, de ce fait, l optimisation des communications (passage à la deuxième phase d invocations des clients). Ce déplacement du serveur par la migration est un mauvais choix source d une baisse

137 7.4. LES TESTS SANS PRISE EN COMPTE DES BESOINS APPLICATIFS 137 Statistiques en fonction de parametres pour la configuration 1s2c nombre de migrations [n] moyenne invovations sans GO invocations serveur moyenne invocations serveur [2] [2] [2] [2] [0] [0] [2] [0] [2] [2] [2] [1] nombre d invocations sans GO fichier de parametres Fig. 7.4 Les résultats de l ancien test 1s2c de HY Chan de performances. D une manière générale, ce test montre que notre système est viable et n impose pas de surcoût important pour sa gestion et son exécution. Il optimise dans de nombreux cas les communications par le déplacement des entités pour l application quelque soit la base de temps pour notre système ou celle de l application elle-même. En effet, dans un temps d exécution limité, le système trouve rapidement les moyens d obtenir un gain sur les performances. Par conséquent, nous en déduisons qu il est recommandé d utiliser des valeurs négatives pour les vetos et d avoir une durée d amortissement sensiblement courte pour optimiser ce type d application. L ancien système se comportait moins bien dans ce test, comme nous le montre le graphique 7.4, puisqu il y avait plus de pertes dans beaucoup plus de paramètres de test. Cependant, il met en évidence que notre implémentation en JAVA nécessite des machines beaucoup plus puissantes pour arriver à la production et à l exécution d un nombre d invocations sensiblement équivalent (environ au maximum) par rapport au langage C++ sur des machines beaucoup plus anciennes (Pentium 166Mhz) Le test 2 serveurs et 2 clients Ce test nous permet de montrer un placement dirigé uniquement par les communications. Ce système permet de passer par des phases sous-optimales pour atteindre une situation optimale. L application est constituée de deux serveurs et de deux clients. Sur chaque site sont placés un client et un serveur. Chacun des clients invoque les deux serveurs (local et distant). Les invocations se déroulent de la manière suivante : 1. Dans un premier temps, chaque client invoque localement le serveur qui est situé sur son site avec un petit volume de donnée de 10 octets. 2. Dans un deuxième temps, chaque client invoque le serveur distant de l autre site avec un volume important de octets. Nous sommes en présence d un système non optimisé du point de vue des communications lors de la deuxième phase du test. Le système devrait donc identifier ces déséquilibres et déplacer les serveurs pour optimiser les communications. Nous pouvons déduire des résultats du graphique 7.5, nous obtenons des gains de performances dans presque tous les cas où il y a migration. Les pertes occasionnées dans les tests

138 138 CHAPITRE 7. LES TESTS Fig. 7.5 La mobilité des serveurs pour optimiser les communications 2 et 4 sont assez importantes et sont inférieures à 4% dans le pire des deux cas et 2% en moyenne. Les cas de perte sont ceux où la ou les migrations n ont pas eu lieu. En effet, dans les expériences 2, 4 et 7, des vetos importants sur la charge sont posés, il n autorisent donc pas la migration des serveurs. Dans les autres cas, il y a au moins une migration qui entraîne une hausse des performances comme dans l expérience 1, qui donne le meilleur résultat avec une amélioration de 58%. Les autres expériences ont des gains plus faibles ou presque insignifiants comme dans les cas 10, 11 et 12 du fait de la réactivité faible du système (base de temps la plus haute). Il faut néanmoins noter que ce scénario de test n implique pas de mauvais placements par le système Le test 2 serveurs, 1 client/serveur et 8 clients Ce test nous permet de démontrer le caractère antagoniste des informations de charge et de communication. Le mécanisme de placement qui tient compte de ces deux critères souvent antinomiques peut engendrer des situations non favorables pour le système et son optimisation. Ce test implique deux serveurs, un client/serveur, et huit clients. Chaque serveur est situé avec quatre clients sur un site. Le client/serveur est situé sur le site du premier serveur. Six clients invoquent le premier serveur tandis que le client/serveur invoque le deuxième serveur

139 7.4. LES TESTS SANS PRISE EN COMPTE DES BESOINS APPLICATIFS 139 tout en étant invoqué lui même par les deux clients restant situés chacun sur un site distinct. Le volume des invocation varie entre 10 et octets. Fig. 7.6 La mobilité des serveurs en fonction de la charge et des communications Nous pouvons résolument penser que si tous les objets sont localisés sur le même site, l optimisation des communications sera optimale au détriment de la charge. Inversement, si les serveurs sont distribués, l optimisation de la charge se rapprochera de l optimum au détriment des communications. Notre système doit donc être capable avec de bons paramètres de trouver un équilibre entre le critère de charge et celui de communication. Les résultats obtenus du graphique 7.6 montrent que nous obtenons des gains dans les expériences 3, 4, 5, 8 et 10. Les deux clients qui invoquent le client/serveur ont un nombre d invocations faible, ceci est dû au fait que dans les paramètres du client/serveur, celui-ci consomme beaucoup de temps cpu et io. Il ne peut donc pas en traiter un nombre important, ce qui diminue le nombre d invocations réalisées par les deux clients. L expérience 8 donne le meilleur résultat avec un gain moyen de presque 40%. L expérience 8 a un meilleur résultat que l expérience 2 car cette dernière réalise trop de migrations pendant le temps du test. Dans ce cas, le serveur est trop mobile et la perte de performances est engendrée par les déplacements. Nous pouvons également dire qu il y a un gain de performance lors des migrations. Ceci tend à prouver que notre système remplit bien sa tâche de placement. Cependant, des paramètres très sensibles à leur environnement, comme par exemple l expérience 2, ne donnent pas toujours de manière absolue la meilleure performance

140 140 CHAPITRE 7. LES TESTS car ils peuvent facilement induire un trop grand nombre de déplacement. Inversement, des paramètres peu sensibles n autorisent que rarement la migration et mettent en exergue, sans l influencer, le coût de notre système comme dans les expériences 11 et 12. Nous avons également un phénomène d instabilité lors de l expérience 9 dont les origines sont sans doute les mêmes que pour le test précédent (des variations du compilateur JIT JAVA et du système d exploitation) Synthèse Nous avons montré, par ces trois exemples la viabilité de notre modèle de placement. Dans de nombreux cas, l optimisation est réussie et apporte un gain substantiel de performances. Cependant, nous pouvons affirmer que l optimisation des communications peut être antinomique avec l optimisation de la charge. Ces deux critères distincts ne sont pas souvent compatibles et mènent souvent à des décisions de placements contraires. Néanmoins, ils participent ensemble aux informations suceptibles d intervenir sur les gains lors du placement et des migrations des entités. De plus, il semble que généralement les paramètres les plus sensibles soient ceux qui répondent le mieux aux différentes applications à base de composants de grain fin ou moyen, même s ils peuvent quelques fois induire des instabilités n entrainant pas les meilleurs gains de performances. En définitive, la base de temps de l application détermine la performance par rapport à la base de temps du système GO. Si l on désire influencer d une autre manière les performances, il est alors nécessaire d introduire des informations données par les composants eux-mêmes. Ces informations correspondent aux besoins applicatifs. Nous introduisons, dans les tests suivants, la notion de besoins applicatifs ainsi que les propriétés matérielles. Nous vérifions que l ajout de ces nouvelles informations induit également un gain quantitif au système et amène un gain qualitatif sur l exécution des applications. 7.5 Les tests avec prise en compte des besoins applicatifs Nous présentons ci-dessous trois tests significatifs qui mettent en jeu les besoins applicatifs. Nous ajoutons donc aux critères précédents de charge et de communication, un critère de besoin applicatif (contraintes, préférences et propriétés des sites) Le test 2 serveurs et 2 clients Nous reprenons le test précédent comportant deux serveurs et deux clients. Nous ajoutons une contrainte de collocation pour l un des deux serveurs car nous prenons l hypothèse que les serveurs s échangent des données pour réaliser un calcul. Par la collocation, nous exprimons le besoin d un composant à être localisé sur un même site qu un ou plusieurs autres composants. Par conséquent, le premier serveur désire être situé sur le même site que le second pour accélérer les échanges entre eux deux. Nous utilisons quatre machines hétérogènes. Les quatre entités sont réparties sur les machines. Nous avons donc deux machines sur lesquelles se trouve un serveur et deux autres sur lesquelles se trouve un client comme sur la figure 7.7. Chaque client invoque de manière égale les deux serveurs distants avec un volume de octets. Chaque serveur consomme 10 mesures de processeur. Nous pouvons voir que l aspect général de la courbe de la moyenne des invocations des serveurs est sensiblement la même que celle du graphique 7.5 précédent. Cependant il existe des changements assez visibles tels que :

141 7.5. LES TESTS AVEC PRISE EN COMPTE DES BESOINS APPLICATIFS 141 MACHINE 1 MACHINE 2 SERV1 CLIENT1 INVOQUE octets MACHINE 3 MACHINE 4 SERV2 CLIENT2 Fig. 7.7 Configuration du test 2 serveurs et 2 clients : placement initial MACHINE 1 MACHINE 2 CLIENT1 SERV2 SERV1 MACHINE 3 MACHINE 4 CLIENT2 Fig. 7.8 Configuration du test 2 serveurs et 2 clients après déplacements 1. une augmentation du nombre de déplacements des serveurs. Ces migrations supplémentaires sont le résultat de la contrainte de collocation entre les serveurs. Au bout d un temps assez court les serveurs sont localisés sur un même site et le premier serveur remplis alors bien la contrainte de collocation. 2. une augmentation de la moyenne du nombre d invocations. Ce gain supplémentaire est dû au déplacement du second serveur vers un client distant afin d accélérer les communications. Peu de temps après, le premier serveur est, lui aussi, déplacé sur le même site que le second serveur pour répondre à sa contrainte de collocation comme le montre la figure 7.8. Il en résulte une augmentation des invocations pour le client. Cependant, il y a perte pour l autre client qui n aura pas de serveur localisé sur son site, mais la forte augmentation des invocations du premier client annule facilement les pertes possibles du second. Nous avons un gain maximal de 78% pour l expérience 1. Dans certaines expériences la migration n est pas possible car il existe des vétos forts pour la charge et les communications comme dans les expériences 2, 4 et 7. Les expériences 10, 11 et 12 montrent soit des pertes, soit un très petit gain, ceci est le résultat de paramètres peu sensibles et d une base de temps trop grande. Les migrations ont bien lieu mais d une manière beaucoup trop tardive par rapport au temps d exécution des tests. Nous voyons que d une manière globale les gains sont plus importants sur le graphique 7.9 par rapport aux résultats du graphique 7.5 qui ne contient pas de contrainte de collocation.

142 142 CHAPITRE 7. LES TESTS Fig. 7.9 Mobilité en fonction de la charge, des communications et des contraintes Le test 4 serveurs et 4 clients Dans ce test, nous décidons de poser des préférences pour les serveurs. Nous voulons que les serveurs s exécutent autant que possible sur les machines les plus rapides de notre réseau. Nous ajoutons des préférences sur le type de processeur et la quantité de mémoire vive pour orienter les décisions de placement vers les machines les plus puissantes. Ce test est réalisé sur quatre machines où sont localisés un serveur et un client. Chaque client invoque de manière égale un serveur distant avec un volume de octets. Chaque serveur consomme 50 mesures de processeur. Nous remarquons sur le graphique 7.10 que dans toutes les expériences où il y a une ou plusieurs migrations, nous obtenons dans l ensemble des gains importants. Les préférences jouent là un rôle assez important puisqu elles permettent de choisir les machines les plus puissantes pour le choix du placement. Nos serveurs consomment beaucoup de puissance processeur, il est donc normal que lorsqu ils sont placés et/ou déplacés sur des machines beaucoup plus puissantes que le reste des autre machines du réseau, l exécution soit beaucoup plus rapide. Nous voyons que les contraintes sur la charge et les communications sont plus fortes que les préférences dans les expériences 2, 4, 7, 8 et 10. Ce qui démontre bien le caractère facultatif des préférences. Elle prennent de l importance lorsqu il n existe pas de vetos comme dans les expériences 1, 3, 6, 9 et 12. Le gain de performances est très grand dans les cas 1 et 3 puisqu il

143 7.5. LES TESTS AVEC PRISE EN COMPTE DES BESOINS APPLICATIFS 143 Fig Mobilité en fonction de la charge, des communications et des préférences est de près de 333%. Le gain est même de 65% pour l expérience 12, ou la migration se fait tardivement. Ce test est celui qui met le plus en valeur notre système, car il n y pas de pertes de performances quelque soit l expérience. Nous sommes donc dans une situation très favorable Le test 7 serveurs 3 clients/serveurs et 10 clients Ce troisième test présenté est plus complexe et plus général. Les objets sont distribués, interagissent entre eux et s exécutent concurremment sur un ensemble de 4 machines. Des contraintes sur la collocation et sur le matériel sont données pour 3 serveurs (type de processeur, système d exploitation, mémoire vive), les quatre autres n ont que des préférences d exécutions. Les clients/serveurs n ont ni contrainte, ni préférence. Dans ce scénario, les serveurs, clients et clients/serveurs sont distribués au hasard, ce qui fait qu ils ne sont pas dans une position optimisée selon les critères de charge, de communication et de besoins applicatifs. Le test se déroule durant 1000 secondes de la manière suivante : Les 7 clients invoquent chacun un serveur (local ou distant) de manière uniforme pendant 400 secondes avec un volume de octets. Ils changent, ensuite jusqu à 1000 secondes leurs comportements d invocations toutes les 150 secondes (volumes de octets puis 10 octets puis octets puis octets) ainsi que les serveurs qu ils

144 144 CHAPITRE 7. LES TESTS invoquent. Les comportements variables des clients sont générés par les fichiers de configurations des composants clients pour simuler une application très dynamique dans son comportement. Les trois client/serveurs sont invoqués par trois clients pendant 500 secondes avec un volume de octets puis les 500 autres secondes avec un volume de 10 octets. Au bout de 400 secondes, 5 clients changent leurs comportements pour la consultation des serveurs. Ils invoquent d autres serveurs et changent leurs volumes de communications. Chaque serveur consomme entre 5 et 20 mesures de processeur. Chaque serveur consomme entre 1 et 10 mesures d entrées/sorties. Le but de ce test est d imiter une situation imprévisible où le changement est brutal, important et fréquent. Ce qui devrait nous rapprocher un peu plus d une application réelle. Fig Mobilité en fonction de la charge, des communications et des besoins applicatifs Les résultats de ce test, visibles sur le graphique 7.11, mettent en évidence deux types de comportements distincts en fonction des jeux de paramètres. 1. Un comportement, visible pour les jeux de paramètres 1, 2, 4, 5, 8, 10, 11 et 12, est caractérisé par une augmentation plus ou moins importante des performances. Nous pouvons avoir un gain maximum de 57% par rapport au temps d exécution sans notre système. Dans ces expériences, les paramètres de vetos sont tous bas et/ou supplantés par les contraintes applicatives (par rapport aux propriétés des sites). Par conséquent,

145 7.6. L ANALYSE DES PARAMÈTRES POUR L OPTIMISATION 145 la migration est, dans la plupart des cas, privilégiée pour équilibrer et satisfaire l application. 2. Un comportement caractérisé par une perte plus ou moins faible dans les expériences restantes. Ce comportement se distingue, malgré tout, par un impact de -11% sur les performances. Dans la plupart des cas, les contraintes applicatives ainsi que celles de charge et de communications empêchent toutes migrations. Il n y a donc aucun placement réalisé et le coût associé est celui de notre système. Il est augmenté par la non satisfaction des contraintes applicatives par rapport à l environnement des composants serveurs. Nous démontrons ici encore que la base de temps utilisée n influence pas le surcoût de notre système. En définitive, notre système est aussi capable d améliorer radicalement les performances dans les systèmes complexes et déséquilibrés. L ajout de contraintes applicatives ainsi que de préférences applicatives peut améliorer non seulement quantitativement mais aussi qualitativement l exécution et le placement des applications. Cependant, il ne faut pas oublier que certaines contraintes se transforment en vetos forts lorsqu elles ne sont pas satisfaites. En effet, dans certains cas, leurs rôles sont prioritaires faces aux contraintes fortes de charge et/ou de communication Synthèse Dans l ensemble des trois tests significatifs, nous assistons dans une large mesure à des gains de performances lors de l exécution des applications. De plus, quand le résultat n est pas quantitativement visible, il reste qualitatif. Les composants sont donc placés et/ou déplacés sur des sites correspondant au mieux à leurs besoins applicatifs en regard des propriétés des sites. Nous fournissons une réponse, la plupart du temps adéquate, aux demandes des applications. Néanmoins, de la même manière que les informations de charge et de communication peuvent être antinomiques, l ajout de contraintes peut, elle aussi être source de conflits lors des décisions de placement. Il est en effet possible qu un site soit un candidat correct au niveau des contraintes mais peut être incorrect au niveau charge et communication. Nous pouvons avoir toutes les combinaisons de ces trois paramètres, ce qui peut être source de problèmes lors des décisions de placements. Mais, globalement, le système arrive à trouver des compromis pour provoquer une meilleure exécution des applications par l utilisation de la procédure de décision logique. La décision prise semble souvent être la ou l une des meilleures solutions pour placer et déplacer les composants afin d optimiser l exécution en regard des besoins applicatifs exprimés et des critères de charge et de communication. Nous analysons ci-après les différents paramètres qui permettent l optimisation du placement et nous nous efforçons de trouver des règles de paramétrage pour des ensembles d applications. 7.6 L analyse des paramètres pour l optimisation Au vu des différents résultats exposés, nous pouvons tirer quelques conclusions et sans doute quels types de paramètres à employer pour certains types d applications. Nous pouvons optimiser certains types d applications par rapport aux charges, aux communications et aux besoins applicatifs. Il est maintenant tout à fait clair que ces critères ne sont pas forcément ou peu liés et non obligatoirement complémentaires car ils peuvent être antagonistes pour

146 146 CHAPITRE 7. LES TESTS chacun d entre eux. Cependant, nous pouvons affirmer que le critère le plus important est celui des besoins applicatifs. Ce qui est le cas dans un système orienté composant client et composant serveur comme le nôtre. Nous remarquons également que le gain est aussi dépendant de la taille, de la fréquence et de la durée des invocations des applications qui correspond à leur granularité. Cette granularité, qui est le ratio entre la consommation processeur et les communications, semble très importante. En effet, si le volume des invocations augmente par rapport à la consommation du temps processeur, le gain augmente. Nous constatons que lorsque la consommation de la ressource processeur augmente, les différences de performances des invocations locales et distantes diminuent. A contrario, si les volumes de communications augmentent, les différences augmentent. A cela, il faut ajouter le coût de notre système. Son coût, associé à la collecte des différentes informations, est d autant plus grand que le grain est faible, mais il est souvent compensé par le gain apporté par les différentes migrations. A l inverse, si le grain augmente, le coût de notre système s amenuise. Nous pouvons, malgré tout, énoncer quelques principes sur les paramètres les plus performants lors de l ensemble de nos tests. 1. La base de temps est importante, plus elle est faible et plus le système réagit rapidement. Il est donc conseillé d utiliser une base faible pour les applications très dynamiques dans le temps et une base plus importante pour les applications un peu plus stables dans le temps. Cependant, il est possible que le gain apporté ne soit pas optimal, mais en général il se rapprochera de cet optimum. 2. La durée d amortissement doit être assez faible, pour la plupart des applications. Cependant, il est possible qu une durée forte puisse donner de meilleurs résultats. 3. Le rapport des coefficients entre charge et communication doit être souvent mis au niveau moyen pour ne pas privilégier un critère plus que l autre, mais si l application effectue beaucoup de calculs et peu de communications, il doit être positionné au maximum et au minimum pour le cas contraire. 4. Les différents vétos sur la charge et les communications sont à mettre en relation avec les coefficients précédents, mais sont, comme nous l avons dit précédemment moins importants que le critère de besoins applicatifs. 5. Le seuil d indifférence doit être souvent positionné à sa valeur la plus haute, ce qui accentue le nombre de migrations possibles et, par voie de fait, de gains possibles. Nous avons décrit un début de solution pour le choix des paramètres qui permettront une optimisation des applications. Mais, il serait nécessaire de réaliser un très grand nombre de tests pour affiner nos premières conclusions. Ce n est pas possible, au vu de la quantité quasiment infinie des types d applications possibles, mais cette première ébauche nous donne quelques pistes à suivre. 7.7 Conclusion Nous avons réussi à montrer l intérêt de notre système à la fois d un point de vue des critères de charge et de communication mais également du point de vue des besoins applicatifs. Nous pouvons déduire de ces résultats qu il existe une forte dépendance entre les paramètres utilisés et le contexte d exécution des applications. Nous pouvons, grâce à notre système, répondre plus précisément aux besoins et à l expressivité des objets/composants par rapport

147 7.7. CONCLUSION 147 à leurs sites d exécution. Notre système a donc un intérêt réel et en nous limitant à des valeurs intéressantes, nous avons pu dégager les grandes lignes qui permettent d attribuer certains paramètres à certains types d applications.

148 148 CHAPITRE 7. LES TESTS

149 Chapitre 8 Conclusion et perspectives 8.1 Conclusion Depuis l avènement au grand public de l Internet et la démocratisation des machines personnelles, les systèmes distribués, le modèle client/serveur et aujourd hui le modèle composant sont de plus en plus répandus. De nombreux standards et langages comme CORBA et JAVA accèlèrent la mise en place de la distribution des applications ainsi que la transparence d accès aux différentes ressources disponibles. Cependant, la complexification des applications et leur caractère distribué induit des difficultés croissantes du point de vue de l administration des applications et de la gestion des ressources. Nous avons implanté un système de gestion de ressources, nommé GO, en JAVA qui utilise le standard CORBA. Ce système permet l allocation des ressources dans les systèmes répartis à composants que nous qualifions d expressifs. Nous avons introduit la notion de besoins applicatifs au sein de ce système. Nous avons trouvé une solution à notre problématique d expressivité des composants par la prise en compte des contraintes et des préférences applicatives ainsi que par la gestion des propriétés matérielles. Après avoir défini un modèle d administration automatique dans un contexte général, nous avons approfondi notre étude par la modélisation de notre problématique et des informations nécessaires par la théorie des graphes dans le cadre d un gestionnaire de placement à composants expressifs et à son implémentation au niveau d un réseau local. Le domaine local correspond au cadre de notre travail. Nous avons réalisé un simulateur d applications, sur les bases des travaux réalisés par [Cha98] et [Cha99]. Nous avons créé le serveur ORM, ainsi qu un langage pour concevoir et exprimer d une manière logique les besoins et les propriétés. Nous avons également créé une procédure de décision logique qui permet d agréger les différents critères de notre système pour réaliser une décision de placement ou de déplacement de composants au sein de ce système. Cela nous permet de répondre au besoin d expressivité des composants et à leur mobiblité. Ce simulateur nous a permi de comparer et de simuler différents types d applications par l utilisation de jeux de paramètres donnés. Les résultats obtenus nous montrent que les performances dépendent du contexte d application et des paramètres choisis. Ils nous montrent aussi l importance des besoins applicatifs lors des différents placements. Par la simulation du comportement d applications réelles, nous avons validé le mécanisme de placement et surtout évalué les décisions basées sur un grand nombre de paramètres. Les décisions ont été prises par des mécanismes de logique booléenne. 149

150 150 CHAPITRE 8. CONCLUSION ET PERSPECTIVES Nous avons montré que l utilisation de notre système amène souvent à une amélioration quantitative et qualitative de l exécution des applications simulées. Ces améliorations quantitatives sont le résultat de l utilisation des critères de charge et de communication, mais aussi des besoins des objets comme par exemple la collocation et/ou les contraintes sur des ressources matérielles. L intégration de l expressivité dans les descripteurs de composants induit de nombreux avantages et améliorations. Par conséquent, les améliorations qualitatives sont également possibles lors de l utilisation des préférences et des contraintes applicatives. Nous avons constaté que le gain lors du placement peut être important lorsque le jeu de paramètres est bien adapté à la situation et à l application. Dans le cas contraire, le surcoût engendré par notre mécanisme d allocation produit une baisse des performances tolérable dans la majorité des cas. Les différents tests nous ont permis de tracer une voie d exploration sur les paramètres à utiliser pour l optimisation de l exécution des applications. Cependant, le problème reste encore ouvert devant le nombre très important d applications possibles et différentes à gérer et à optimiser. La contribution générale de notre travail s étend de la modélisation d administration automatique avec prise en compte des besoins applicatifs dans un système complexe et ouvert jusqu à la concrétisation de notre système GO, grâce au partitionnement de nos différents graphes, du serveur ORM du langage de contraintes logiques ainsi que la prise de décision logique. Nous avons montré que le placement d objets est réalisable dans un environnement hétérogène et que le gain est significatif dans de nombreux cas. La plupart des recherches sur l optimisation de ressources sont théoriques mais il manque des systèmes réels avec lesquels les utilisateurs peuvent travailler. Dans ce contexte, nous avons choisi une plateforme ouverte, standard et répandue : CORBA et un langage nous garantissant la portabilité JAVA. 8.2 Perspectives Ce travail ouvre de nombreuses perspectives qu il est possible d explorer. Nous désirons améliorer et pousser nos travaux sur les points suivants : Les contrats de composants Notre module de gestions des besoins applicatifs doit pouvoir s étendre pour intégrer de manière générique les contrats entre les composants. Le but est alors d associer aux composants, par l utilisation de notre module ORM des spécifications fonctionnelles et nonfonctionnelles encore plus précises et plus ouvertes. Il sera alors possible de décrire et de connaître plus précisément les besoins de chaque application et de ses composants, ce qu il permettra, sans nul doute, de parfaire et d optimiser encore plus leur exécution. Malgré tout, nous avons déjà une bonne base qui peut évoluer assez facilement dans ce sens et qui reste assez ouverte. Nous pouvons, par exemple, utiliser le langage XML pour l écriture et les échanges d informations de nos modules L utilisation du langage XML Nous avons en partie implémenté nos fichiers de configuration des composants en langage XML. Ce codage nous permet de faciliter l écriture et la lecture des informations de configuration de notre système. En effet, les besoins applicatifs sont maintenant codés avec ce standard

151 8.2. PERSPECTIVES 151 qui permet d assurer une grande compatibilité et d interopérabilité avec un ensemble croissant de logiciels. Cet avantage ne va pas sans quelques défauts liés au langage XML lui-même. Les fichiers ont une taille plus importante que nos anciens types de fichiers et leurs traitements (lectures, écritures) sont un peu plus gourmands en ressources et en temps machine. Mais sans doute que la standardisation est à ce prix Le service de courtage Nous pouvons aussi voir notre module de besoins applicatifs comme un courtier de ressources pour composants. Les spécifications de la fonction de courtage sont déjà définies par l ISO et l ITU-T et par l OMG. Les travaux de [DF99] vont dans ce sens en élaborant une proposition sur l idée de courtier de ressources, entendu ressources matérielles. Il décrit une spécialisation du courtier générique en suivant les points de vues ODP. Cependant, il ne gère pas les ressources logicielles. Par conséquent, notre gestionnaire de besoins applicatifs (contraintes et préférences) peut être utilisé dans le mécanisme de courtage de ressources tant matérielles que logicielles avec l utilisation du langage XML. Nous aurions alors un courtier de resources génériques pouvant travailler en conjonction avec le courtier de services.

152 152 CHAPITRE 8. CONCLUSION ET PERSPECTIVES

153 Annexe A Définition XML : MACHINE MACHINE <?xml version="1.0" encoding="iso "?> Schema machine.xsd Elements MACHINE OPERATOR element MACHINE children IDENTITY DECLARATIONS annotation documentation Machine description source <xs:element name="machine"> <xs:annotation> <xs:documentation>machine description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="identity"> <xs:complextype/> </xs:element> <xs:element name="declarations"> <xs:complextype> <xs:sequence minoccurs="0" maxoccurs="unbounded"> <xs:element name="propertyname" type="xs:string"/> <xs:element ref="operator"/> <xs:element name="propertyvalue" type="xs:string"/> <xs:element ref="operator" minoccurs="0"/> </xs:sequence> </xs:complextype> 153

154 154 ANNEXE A. DÉFINITION XML : MACHINE </xs:element> </xs:sequence> </xs:complextype> </xs:element> element MACHINE/IDENTITY source <xs:element name="identity"> <xs:complextype/> </xs:element> element MACHINE/DECLARATIONS children PROPERTYNAME OPERATOR PROPERTYVALUE source <xs:element name="declarations"> <xs:complextype> <xs:sequence minoccurs="0" maxoccurs="unbounded"> <xs:element name="propertyname" type="xs:string"/> <xs:element ref="operator"/> <xs:element name="propertyvalue" type="xs:string"/> <xs:element ref="operator" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> element MACHINE/DECLARATIONS/PROPERTYNAME type xs:string source <xs:element name="propertyname" type="xs:string"/>

155 155 element MACHINE/DECLARATIONS/PROPERTYVALUE type xs:string source <xs:element name="propertyvalue" type="xs:string"/> element OPERATOR type xs:string used by elements MACHINE/DECLARATIONS MACHINE/DECLARATIONS annotation documentation Comparison operator source <xs:element name="operator" type="xs:string" default="=="> <xs:annotation> <xs:documentation>comparison operator</xs:documentation> </xs:annotation> </xs:element>

156 156 ANNEXE A. DÉFINITION XML : MACHINE

157 Annexe B Définition XML : COMPONENT COMPONENT <?xml version="1.0" encoding="iso "?> Schema machine.xsd Elements C COMPONENT CONSTRAINT I OPERATOR PREFERENCE S SERVER element C children DOMAINNAME SITENAME IDENTITY DECLARATIONS used by element COMPONENT/TYPE annotation documentation Client type description source <xs:element name="c"> <xs:annotation> <xs:documentation>client type description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="domainname" type="xs:string"/> <xs:element name="sitename" type="xs:string"/> <xs:element name="identity" type="xs:string"/> <xs:element name="declarations" minoccurs="0"> <xs:complextype> <xs:sequence> 157

158 158 ANNEXE B. DÉFINITION XML : COMPONENT <xs:element name="delay" type="xs:unsignedlong"/> <xs:element name="duration" type="xs:unsignedlong"/> <xs:element name="cpuconsum" type="xs:unsignedbyte"/> <xs:element name="io" type="xs:unsignedbyte"/> <xs:element name="nbserverinvoc" type="xs:unsignedint"/> <xs:element ref="server" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> element C/DOMAINNAME type xs:string source <xs:element name="domainname" type="xs:string"/> element C/SITENAME type xs:string source <xs:element name="sitename" type="xs:string"/> element C/IDENTITY type xs:string source <xs:element name="identity" type="xs:string"/>

159 159 element C/DECLARATIONS children DELAY DURATION CPUCONSUM IO NBSERVERINVOC SERVER source <xs:element name="declarations" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="delay" type="xs:unsignedlong"/> <xs:element name="duration" type="xs:unsignedlong"/> <xs:element name="cpuconsum" type="xs:unsignedbyte"/> <xs:element name="io" type="xs:unsignedbyte"/> <xs:element name="nbserverinvoc" type="xs:unsignedint"/> <xs:element ref="server" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:element> element C/DECLARATIONS/DELAY type xs:unsignedlong source <xs:element name="delay" type="xs:unsignedlong"/> element C/DECLARATIONS/DURATION type xs:unsignedlong source <xs:element name="duration" type="xs:unsignedlong"/>

160 160 ANNEXE B. DÉFINITION XML : COMPONENT element C/DECLARATIONS/CPUCONSUM type xs:unsignedbyte source <xs:element name="cpuconsum" type="xs:unsignedbyte"/> element C/DECLARATIONS/IO type xs:unsignedbyte source <xs:element name="io" type="xs:unsignedbyte"/> element C/DECLARATIONS/NBSERVERINVOC type xs:unsignedint source <xs:element name="nbserverinvoc" type="xs:unsignedint"/> element COMPONENT children TYPE annotation documentation Component description source <xs:element name="component"> <xs:annotation> <xs:documentation>component description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="type"> <xs:complextype> <xs:choice> <xs:element ref="s"/> <xs:element ref="i"/> <xs:element ref="c"/> </xs:choice> </xs:complextype> </xs:element> </xs:sequence>

161 161 </xs:complextype> </xs:element> element COMPONENT/TYPE children S I C source <xs:element name="type"> <xs:complextype> <xs:choice> <xs:element ref="s"/> <xs:element ref="i"/> <xs:element ref="c"/> </xs:choice> </xs:complextype> </xs:element> element CONSTRAINT children CONSTRAINTNAME OPERATOR CONSTRAINTVALUE used by elements S/DECLARATIONS I/DECLARATIONS annotation documentation Constraint description source <xs:element name="constraint"> <xs:annotation> <xs:documentation>constraint description</xs:documentation>

162 162 ANNEXE B. DÉFINITION XML : COMPONENT </xs:annotation> <xs:complextype> <xs:sequence minoccurs="0"> <xs:element name="constraintname" type="xs:string"/> <xs:element ref="operator"/> <xs:element name="constraintvalue" type="xs:string"/> <xs:element ref="operator" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> element CONSTRAINT/CONSTRAINTNAME type xs:string source <xs:element name="constraintname" type="xs:string"/> element CONSTRAINT/CONSTRAINTVALUE type xs:string source <xs:element name="constraintvalue" type="xs:string"/> element I children DOMAINNAME SITENAME IDENTITY DECLARATIONS used by element COMPONENT/TYPE annotation documentation Client/Server type description source <xs:element name="i"> <xs:annotation> <xs:documentation>client/server type description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence>

163 163 <xs:element name="domainname" type="xs:string"/> <xs:element name="sitename" type="xs:string"/> <xs:element name="identity" type="xs:string"/> <xs:element name="declarations"> <xs:complextype> <xs:sequence> <xs:element ref="constraint" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="preference" minoccurs="0"/> <xs:element name="nbserverinvoc" type="xs:unsignedint" minoccurs="0"/> <xs:element ref="server" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> element I/DOMAINNAME type xs:string source <xs:element name="domainname" type="xs:string"/> element I/SITENAME type xs:string source <xs:element name="sitename" type="xs:string"/> element I/IDENTITY type xs:string source <xs:element name="identity" type="xs:string"/>

164 164 ANNEXE B. DÉFINITION XML : COMPONENT element I/DECLARATIONS children CONSTRAINT PREFERENCE NBSERVERINVOC SERVER source <xs:element name="declarations"> <xs:complextype> <xs:sequence> <xs:element ref="constraint" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="preference" minoccurs="0"/> <xs:element name="nbserverinvoc" type="xs:unsignedint" minoccurs="0"/> <xs:element ref="server" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:element> element I/DECLARATIONS/NBSERVERINVOC type xs:unsignedint source <xs:element name="nbserverinvoc" type="xs:unsignedint" minoccurs="0"/> \begin{verbatimtab} \subsection*{element OPERATOR} \includegraphics[scale=0.75]{eps/annex/component/composant_p22.eps} \begin{verbatimtab} type restriction of xs:string used by elements CONSTRAINT CONSTRAINT PREFERENCE PREFERENCE facets length 2 annotationdocumentation Comparison logical operator source <xs:element name="operator"> <xs:annotation>

165 165 <xs:documentation>comparison logical operator</xs:documentation> </xs:annotation> <xs:simpletype> <xs:restriction base="xs:string"> <xs:length value="2"/> </xs:restriction> </xs:simpletype> </xs:element> element PREFERENCE children PREFERENCENAME OPERATOR PREFERENCEVALUE WEIGHT used by elements S/DECLARATIONS I/DECLARATIONS annotation documentation Preference description source <xs:element name="preference"> <xs:annotation> <xs:documentation>preference description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence minoccurs="0"> <xs:element name="preferencename" type="xs:string"/> <xs:element ref="operator"/> <xs:element name="preferencevalue" type="xs:string"/> <xs:element name="weight" type="xs:unsignedbyte"/> <xs:element ref="operator" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> element PREFERENCE/PREFERENCENAME

166 166 ANNEXE B. DÉFINITION XML : COMPONENT type xs:string source <xs:element name="preferencename" type="xs:string"/> element PREFERENCE/PREFERENCEVALUE type xs:string source <xs:element name="preferencevalue" type="xs:string"/> element PREFERENCE/WEIGHT type xs:unsignedbyte source <xs:element name="weight" type="xs:unsignedbyte"/> element S children DOMAINNAME SITENAME IDENTITY DECLARATIONS used by element COMPONENT/TYPE annotation documentation Server type description source <xs:element name="s"> <xs:annotation> <xs:documentation>server type description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="domainname" type="xs:string"/> <xs:element name="sitename" type="xs:string"/> <xs:element name="identity" type="xs:string"/> <xs:element name="declarations"> <xs:complextype> <xs:sequence> <xs:element ref="constraint" minoccurs="0"/> <xs:element ref="preference" minoccurs="0"/>

167 167 </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> element S/DOMAINNAME type xs:string source <xs:element name="domainname" type="xs:string"/> element S/SITENAME type xs:string source <xs:element name="sitename" type="xs:string"/> element S/IDENTITY type xs:string source <xs:element name="identity" type="xs:string"/> element S/DECLARATIONS children CONSTRAINT PREFERENCE source <xs:element name="declarations"> <xs:complextype> <xs:sequence> <xs:element ref="constraint" minoccurs="0"/> <xs:element ref="preference" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element>

168 168 ANNEXE B. DÉFINITION XML : COMPONENT \begin{verbatimtab} \subsection*{element SERVER} \includegraphics[scale=0.75]{eps/annex/component/composant_p32.eps} \begin{verbatimtab} children IDENTITY START DURATION GARDE VOLUME used by elements C/DECLARATIONS I/DECLARATIONS annotation documentation Invoke server description source <xs:element name="server"> <xs:annotation> <xs:documentation>invoke server description</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="identity" type="xs:string"/> <xs:element name="start" type="xs:int"/> <xs:element name="duration" type="xs:int"/> <xs:element name="garde" type="xs:double"/> <xs:element name="volume" type="xs:unsignedlong"/> </xs:sequence> </xs:complextype> </xs:element> element SERVER/IDENTITY type xs:string source <xs:element name="identity" type="xs:string"/> element SERVER/START type xs:int source <xs:element name="start" type="xs:int"/> element SERVER/DURATION type xs:int source <xs:element name="duration" type="xs:int"/>

169 169 element SERVER/GARDE type xs:double source <xs:element name="garde" type="xs:double"/> element SERVER/VOLUME type xs:unsignedlong source <xs:element name="volume" type="xs:unsignedlong"/>

170 170 ANNEXE B. DÉFINITION XML : COMPONENT

171 Bibliographie [AHS92] [All97] F. Arbab, I. Herman, and P. Spilling. An overview of manifold and its implementations. Concurrency : Practice and Experiences 5, pages , R. J. Allen. A Formal Approach to Software Architecture. phd thesis, Carnegie Mellon University, USA, May [Alt03] Altiris. Emea 6.0. http :// [Arq96] D. Arquès. Cours de probabilités et applications à la simulation de files d attente. Université de Franche-Comté, [Arr51] K. Arrow. Social choice and individual values. J. Wiley and Sons, [BCV03] J. Bahi, R. Couturier, and F. Vernier. Load balancing on dynamic network. IPDPDS Euromicro2003 Italy Genoa, [Bel01] L. Bellissard. Des objets aux composants. composants/ bellissard.pdf, [Ber99] [BF81] G. Bernard. Applicabilité et performances des systèmes d agents mobiles dans les systèmes répartis. In Rennes 99 CFSE 1 1ère Conférence française sur les systèmes d exploitation, Rennes, France, 8-11 juin R. M. Bryant and R. A. Finkel. A stable distributed scheduling algorithm. In Proceedings of the 2th International Conference on Distributed Computing Systems, pages , Paris, France, Mars IEEE Computer Society. [BF96] G. Bernard and B. Folliot. Caractéristiques générales du placement dynamique : Synthèse et problématique. In Actes de l école d été Placement Dynamique et Répartition de Charge : application aux systèmes parallèles et répartis, pages 3 25, Juillet www-inf.int-evry.fr/ bernard/distributed systems/distributed systems.html. [Bir93] K.P. Birman. The process group approach to reliable distributed computing. communication of the ACM, 36(12), December [Bon98] X. Bonnaire. Architecture, Mécanismes et Outils pour la Conception d Applications Réparties Hautement Administrables. PhD thesis, Université Paris 6, [Bou94] [BP90] F. Bourdon. The automatic positioning of objects in cool v2. In IEEE Computer Society Press, editor, Proceedings of the 14th International Conference on Distributed Computing Systems (ICDCS), pages , Poznan, Pologne, Juin A. Baruch and D. Peleg. Sparse partitions. In 31st IEEE Symposium on Fondations of Computer, pages , October

172 172 BIBLIOGRAPHIE [BS85] [BSW93] A. Barak and A. Shiloh. A distributed load-balancing policy for multicomputer. Softwore Practice and Experience, 15(9) : , Juillet Ammon Barak, Guday Shai, and Richard G. Wheeler. The mosix distributed operating system load balancing for unix, [BVM86] J.P. Brans, Ph. Vincke, and B. Mareschal. How to select and how to rank projects : the promethee method. European Journal of Operational Research, 24 : , [CA99] CA. Unicenter tng. http :// [CG92] N. Carriero and D. Gelernter. Linda in context. Communication of the ACM 35, pages , [CG96] V. Camps and M-P. Gleizes. Cooperative and mobile agents to find relevant information in a distributed ressources network. In WWW5 AI Workshop Fifth International World Wide Web Conference, Paris, France, May [Cha98] [Cha99] [CHPB96] [Chr89] [CS02] [Des90] [DF99] [Dic92] [DKM93] P. Chatonnay. Gestion de l allocation des ressources aux objets dans les systèmes répartis, une approche multicritère intégrant les communications. PhD thesis, Université de Franche-Comté, France, H-Y. Chan. Gestion auto-adaptive et administration de l allocation des ressources dans les systèmes répartis à objets multidomaines. PhD thesis, Université de Franche-Comté, France, P. Chatonnay, B. Herrmann, L. Philippe, and F. Bourdon. Placement dynamique dans les systèmes répartis à objets. Calculateurs Parallèles, 8(1) :11 30, lifc.univ-fcomte.fr/recherche/p1/projet1.html. P. Chretienne. Task scheduling over distributed memory machines. In Proc. Int l Conf. Distributed Algorithms, Amsterdam, Nov North Holland Publishers. M. J. Chonoles and J. A. Schardt. UML 2 For Dummies. John Wiley and Sons, Y. Deswarte. Tolérance aux fautes, sécurité et protection, Banâtre and all Ed., chapter 9, pages 291,344. INRIA, 90. C. Daval-Frerot. Fédération de courtiers de ressoources en environnement réparti objet. PhD thesis, Université de Franche-Comté, France, P. Dickman. Effective load balancing in a distributed object-support operating system. In L.F. Cabrera, V. Russo, and M. Shapiro, editors, Proceedings of the Second International Workshop on Object Oriention in Operating Systems, pages IEEE, Septembre pd. J. Dulay, N. Kramer, and J. Magee. Structuring Parallel and Distributed Programs. IEEE Software Engineering Journal, 8, [DMT98] DMTF. leading the development, adoption and unification of management... http :// [dtpas97] Rapide design Team Program Analysis and Verification Group Computer Systems. Guide to the rapide 1.0 language reference manual. Stanford University, [EB93] D.J. Evans and W.U.N. Butt. Dynamic load balancing using task-transfer probabilities. Parallel Computing, pages , 1993.

173 BIBLIOGRAPHIE 173 [EB94] D.J. Evans and W.U.N. Butt. Load balancing with network partitioning using host groups. Parallel Computing, 20 : , [EDJB + 93] X. Evers, J. De-Jongh, R. Boontje, D. Epema, and R. Van-Dantzig. Condor flocking : load sharing between pools of workstations. Technical report, Delft University of Technology, The Netherlands, [EMC03] EMCC. Visual san. http :// [FAS01] S. Frénot and M. Avin-Sotres. Migration et déploiement automatique de services. JC2001 proceedings, [FB89] L. Fernández-Bace. Allocating modules to processors in a distributed system. IEEE Transactions on Software Engineering, SE-15, No. 11 : , Nov [Fis78] P.C. Fishburn. A survey of multiattribute/multicriteria evaluation theories. Springer Verlag, [Fol92] B. Folliot. Méthodes et outils de partage de charge pour la conception et la mise en oeuvre d applications dans les systèmes répartis hétérogènes. PhD thesis, Institut Blaise Pascal, Décembre wwwmasi.ibp.fr/francais/recherches/sr/repartis.html. [Fol96] [Gar95] B. Folliot. Contribution à une approche système du placement dynamique dans les système répartis hétérogénes. Thèse d habilitation, Université Paris VI, décembre D. Garlan. An introduction to the aesop system. School of Computer Science, Carnegie Mellon University, July [GBa94] A. Geist, A. Beguelin, and all. PVM : parallel virtual machine. MIT press, [GL99] [Glo86] H. Guyennet and J-C. Lapayre. The group approach in cooperative work and in load balancing. Journal of Parallel and Distributed Computing Practices, F. Glover. Future paths for integer programming and links to artificial intelligence. Computing Operations Research, 13, n5 : , [Gos91] A. Goscinski. Distributed Operating Systems : The Logical Design. Addison- Wesley, [GP95] [GPHS94] D. Garlan and D.E. Perry. Introduction to the Special Issue on Software Architecture. IEEE Transactions on Software Engineering, 21, H. Guyennet, L. Philippe, B. Herrmann, and F. Spies. A performances study of dynamic load balancing algorithms for multicomputers. In IEEE, editor, Proceedings of MPCS 94, Ischia, Italie, Mai lifc.univ-fcomte.fr/. [Gro94] W. Grow. Tutorial on mpi : the message passing interface. http :// [GRO97] THE OPEN GROUP. Inter-domain management : Specification translation. Preliminary specification, THE OPEN GROUP, Document Number : P509. [Gro00] DOC Group. Tao. http :// schmidt/tao.html, [Gün98] M. Günter. Explicit connectors for coordination of active objects. Master s thesis, Faculty of Science University of Bern, 1998.

174 174 BIBLIOGRAPHIE [HBD95] M. Harchol-Balter and A. B. Downey. Exploiting process lifetime distributions for dynamic load balancing. Technical report ucb csd , Berkeley, University of California, Mai [HBSG99] O. Holder, I. Ben-Shaul, and H. Gazit. Dynamic layout of distributed application in fargo. In Proceedings ICSE 99 Los-Angeles, May http :// [HC97] Y. Hoffner and B. Crawford. Using interception to create domains in distributed systems. In The joint international conference on Open Distributed Processing & Distributed Platforms, May [Hol75] J. H. Holland. Adaptation in natural and artificial systems. Ann Arbor, MI, Michigan Press University, [IBM99] IBM. Tivoli. http :// [ISO96] IEC ISO. Open distributed processing - reference model. Technical Report ISO/IEC DIS , , ISO, IEC, 1995, :8000/RM- ODP. [ISO99a] IEC ISO. Open distributed processing - enterprise viewpoint. Technical Report ISO/IEC WD 15414, ISO, IEC, January [ISO99b] IEC ISO. Open distributed processing - protocol support for computational interactions. Technical Report ISO/IEC WD 14752, ISO, IEC, January [KBTJ92] [KGV83] [KTV93] [LK87] [LO86] M.F. Kaashoek, H.E. Bal, A.S. Tanenbaum, and J. Jansen. Replication techniques for speeding up parallel applications on distributed systems. Technical report, Université de Vrije, Amsterdam, S. Kirkpatrick, C. Gelatt, and M. Vecchi. Optimization by simulated annealing. Science, 220, n4598 : , Mai M.F. Kaashoek, A.S. Tannebaum, and K. Verstoep. Group communication in amoeba and its applications. Distributed systems engineering Journal, 1 :48 58, july F. C. H. LIN and R. M. KELLER. The gradient model load balancing method. IEEE Transactions on Software Engineering, 13(1) :32 37, Janvier W. E. Leland and T. J. Ott. Load-balancing heuristics and process behavior. ACM SIGMETRICS, pages 54 69, Mai [LR57] R. Luce and H. Raiffa. Games and Decisions. J. wiley and Sons, [Mic91] [Mic01] [MPS94] Sun Microsystems. Solaris on network information service plus (nis+). Technical report, Sun Microsystems Inc., Sun Microsystems. Enterprise java beans specification 2.0. Sun Microsystems, L.Y. Maystre, J. Pictet, and J. Simos. Méthodes multicritères ELECTRE. Presses polytechniques et universitaires Romandes, [MS96] S. Mazumdar and K. Swanson. Web based management-corba/snmp gateway approach. In Proc. Seventh IFIP/IEEE International Workshop on Distributed Systems : Operations & Management, L Aquila, Italy, October http ://

175 BIBLIOGRAPHIE 175 [MTW96] N. Medvodovic, R. Taylor, and E. Whitehead. Formal Modelling of Software Architectures at Multiple Levels of Abstraction. DICS University of California, Irvine, [NAM97] UC NAMES. Kerberos overview. http :// 97. [OMG90] OMG. The object management architecture guide. Technical Report , Object Management Group, Farmington MA, USA, [OMG98] OMG. Corba v2.3 (draft). Technical report, Object Management Group, Farmington MA, USA, [OMG01] OMG. Corba 3.0 new components chapters. Object Management Group, [OSF97] OSF. Distributed computing environment. http :// [Ost01] [Pae78] J. Ostergaard. The ants load balancing system. http ://unthought.net/antsd/, J.H.P. Paelinck. Qualiflex : A flexible multiple-criteria decision method. Economic Letters, 1 : , [Pet97] Y. Peter. Conception d un mécanisme générique pour permettre la migration dans corba. In Acte de la conférencerenpar 9, pages , Lausanne, Suisse, Mai [Pre96] P. Preda. Equilibrage de charge par duplication de services dans un système réparti à objets. Mémoire de dea, Université de Franche-Comté, Besançon, France, Septembre [Pro98a] The Globus Project. Globus. http :// [Pro98b] The NetSolve Project. Netsolve. http :// [Pro98c] [Put03] The YALB Project. Yet another loadbalancing system. http :// E. Putrycz. Gestion de l utilisation de ressources pour des applications distribués à grande échelle. Phd thesis, Université d Evry Val d Essonne, Evry, France, Juin [RB93] B. Roy and D. Bouyssou. Aide Multicritère à la décision : Méthodes et Cas. Economica, [RLS98] [Rou82] [Roy01] [Sav51] R. Raman, M. Livny, and M. H. Solomon. Matchmaking : Distributed resource management for high throughput computing. In HPDC, pages 140, M. Roubens. Preference relations on actions and criteria in multi-criteria decision making. European Journal of Operational Research, 10 :51 55, Ranjit K. Roy. Design of Experiments Using The Taguchi Approach. Interscience, L.J Savage. The theory of statistical decision. Journal of the American Statistical Association, 46 :55 67, [Sav54] L.J Savage. The Foundations of Statistics. J. wiley and Sons, [SG96] M. Shaw and D. Garlan. Software Architecture - Perspective on an Emerging Discipline. Prentice Hall, 1996.

176 176 BIBLIOGRAPHIE [Sie96] [Smi82] [Spi95] [SS84] J. Siegel. CORBA Fundamentals and Programming. Wiley Computer Publishing, B.C. Smith. Reflection and semantics in procedural language. Technical Report 272, MIT Laboratory for Computer Science, F. Spies. Conception et évaluation de stratégies de répartition de charge Dynamique dans les systèmes distribués. Thèse de doctorat, Université de Franche- Comté, dept-info.univ-fcomte.fr/people/spies/these/these.html. J. A. Stankovic and I. S. Sidhu. An adaptative bidding algorithm for processes, clusters and distributed groups. In Proceedings of the 4th International Conference on Distributed Computing Systems, pages 49 59, San Francisco, Ca, USA, Mai [Sta93] W. Starlings. SNMP, SNMPv2 and CMIP. Don Mills : Addison-Wesley, [Tac97] C. Taconet. Graphes de Réseaux Coopérants et Localisation Dynamique pour les Systèmes Répartis sur Réseaux Étendus. PhD thesis, Université d Évry Val d Essonne, [TBA97] M. Tréhel, C. Balayer, and A. Alloui. Modeling load balancing inside groups using queuing theory. In PDCS 97 (10th International Conference on Parallel and Distributed Computing System), New Orleans, Louisiana, 1 oct. - 3 oct [Tok90] M. Tokoro. Computational field model : Toward a new computing model/methodology for open distributed environment. In Proceeding of 2nd Workshop on Future Trends in Distributed Computing Systems, Le Caire, Egypte, Septembre [Ueh97] M. Uehara. Fault tolerant computing in computational field model. In ECBS, pages 34, [VLL90] B. Veltman, B.J. Lageweg, and J.K. Lenstra. Multiprocessor scheduling with communication delays. Parallel Computing, 16 : , [Wal50] A. Wald. Statistical Decision Functions. J. wiley and Sons, [ZC01] [ZF87] W. Zhang and R. K. Cytron. Catscan : Constraint-based approaches to timebounded synthesis, customization and adaptation in networked embedded systems. http :// zhang/projects/catscan/, S. Zhou and D. Ferrari. A measurement study of load balancing performance. In Proc. of the 7th. Internat. Conf. on Distributed Computing Systems, pages , Berlin, GER, September 21, IEEE Computer Society. [Zho88] S. Zhou. A trace-driven simulation study of dynamic load balancing. IEEE Transactions on Software Engineering, 14 : , [ZSE82] J. Zahorjan, K.C. Seveik, and D. Eager. Balanced job bound analysis of queing networks. Communication of the ACM, 25(2) : , [ZWZD93] S. Zhou, J. Wang, X. Zheng, and P. Delisle. Utopia : A load sharing facility for large, heterogeneous distributed computer systems. Software - Practice and Experience, December 1993.

177 Résumé Le contexte de travail de cette thèse se situe aux frontières des domaines des systèmes répartis à composants, de la gestion de ressources, de l équilibrage de charge et de la mobilité des composants avec prise en compte des besoins applicatifs avec l aide de décisions logiques pour le déploiement et le placement des applications. Notre étude s étend de la modélisation de l administration de ressources et du déploiement pour un système réparti à composants dans un environnement CORBA, à la concrétisation et la mise en oeuvre de notre système. La mobilité des composants basée sur la décision logique utilisant les informations de charge, de communication et de besoins applicatifs (contraintes et préférences) permet d optimiser l allocation de ressources lors du déploiement et du placement. Les résultats obtenus montrent que le surcoût de notre proposition est assez faible par rapport aux avantages procurés. Notre système est capable de fournir une meilleure exécution et un meilleur placement des applications et des composants du point de vue des performances et de la satisfaction de besoins propres à l application en regard des propriétés des sites d exécution. Nous utilisons le concept de réflexion et une technique de containers pour permettre la transparence d allocation de ressources et d adaptation à l environnement. Notre contribution principale dans ce champ de recherche se situe dans l utilisation d une combinaison des théories, des modèles et des plateformes existantes pour avoir une solution implantée et testée, et pouvant être utilisée pour améliorer l efficacité des exécutions des applications à base de composants. Mots clés : Systèmes répartis à composants, Administration et allocation de ressources, besoins applicatifs, procédure logique, graphes. Abstract The context of the work presented in this PhD thesis is between the fields of the components distributed systems, the resources management, the load balancing and the components mobility, with a view to take into account the applications needs, with the help of logical decisions, in order to deploy and the place these applications. Our study ranges from modeling of the resources administration and deployment for a component based distributed system in a CORBA environment, to the implementation of our system. The mobility of the components is based on a logical decision using the load, the communication and the application needs (constraints and preferences) information to optimize the resource allocation during deployment and placement. The results obtained show that the overhead of our system is rather low compared to the given advantages. Our system is able to provide a better execution and a better placement for the applications and components not only in terms of performances, but also in terms of application needs satisfaction compared to the execution site properties. We use the concept of reflexion and a technique of containers to provide the transparency of resource allocation and adaptation to the environment. Our main contribution to this field of research is using a combination of existing theories, models and existing platforms to come up with a tested solution which can be used to improve the effectiveness of component based application execution. Keywords logical procedure, graphs. : Distributed component system, Resources administration and allocation, application needs,