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.