Placement dynamique dans les systèmes répartis à objets.

Transcription

1 Placement dynamique dans les systèmes répartis à objets. Pascal ChatonnayyBénédicte HerrmannyLaurent Philippey François BourdonzPascal Barz Christian Jacquemotx Laboratoire d Informatique de Besançon 16, route de Gray Besançon cedex - France tel : [email protected] WWW : RÉSUMÉ. Nous présentons les travaux réalisés dans le cadre d une étude sur le placement dynamique d objets dans les systèmes répartis. En nous appuyant sur un modèle capable de fournir une prédiction à court terme de l état du système, nous proposons un mécanisme de placement des objets tenant compte de la charge des processeurs et des communications entre objets. Notre plateforme de développement est COOL v2. ABSTRACT. We present our works made in the field of dynamic objects positioning. By the use of a model able to give a short-range prediction, we propose a mechanism which manage processor load and communication volume between objects. COOL v2 is used as a base for our implementation. MOTS-CLÉS : Systèmes Répartis à Objets, Equilibrage de charge, Communications, COOL KEYWORDS: Distributed Objects Systems, Load-balancing, Communications, COOL 1. Introduction. La création de systèmes à image unique [Phi93] est un objectif qui, à court terme, devrait mobiliser des efforts de recherche. Il s agit de fournir, à l utilisateur de ressources réparties, une image identique à celle qu il peut avoir devant une machine monoprocesseur. L ajout de ces fonctions dans les systèmes répartis préexistants ou avenir, en facilitera l utilisation, et, de ce fait, la diffusion. Pour atteindre ce but, plusieurs :Les travaux, rapportés dans cette publication, sont menés dans le cadre d un projet commun entre le SEPT, l Université de Franche-Comté (LIB) et la société Chorus systèmes. y:laboratoire d Informatique de Besançon, Université de Franche-Comté z:service d Etudes Communes de la Poste et de France Télécom x:chorus Systèmes

2 questions restent à résoudre. Il nous semble que la gestion de la charge est un problème déterminant. L équilibrage de charge est un domaine qui a été largement étudié ces dernières années, en particulier dans le champ du placement de processus dans les environnements de type UNIX. Il commence à apparaître comme une fonction nécessaire pour les systèmes répartis à grand nombre de sites. Les avantages apportés par l équilibrage de charge sont nombreux : l utilisation des ressources est rationalisée et optimisée de plus, le programmeur est libéré des contraintes de placement de ses applications. L apparition des Systèmes Répartis à Objets (SRO) pose de nouvelles questions dans le domaine de l équilibrage de charge. Comment transferer la technologie développée pour les processus vers le domaine des objets? Quelles sont les différences entre : les systèmes distribués à base de processus et les SRO? Les objets n accomplissent une tâche complexe que par coopération, comment gérer cette interdépendance logicielle et le flux de communication qui en découle? En ayant ces questions à l esprit, nous nous proposons d étudier le placement dynamique d objets dans les SRO, et plus particulièrement dans COOL v2. L objectif de notre étude est d optimiser l exécution d applications réparties orientées objet, en plaçant leurs différents composants de manière à faciliter l accès aux ressources matérielles et logicielles. L environnement visé est composé de stations de travail et de serveurs interconnectés par un réseau (hétérogène et géographiquement étendu). L optimisation de l exécution est réalisée uniquement par le système. Elle peut être conduite à partir de différents facteurs tels que le temps ou le coût d exécution. Notre travail est motivé par les constatations suivantes : la conception d applications dans les systèmes répartis supportant les objets est en pleine expansion. Le principe de base de ce type de programmation est comparable à l approche client-serveur, un objet client fait appel à des méthodes d un objet serveur présent dans le système. Un serveur peut être soit sur le même site que son client (problème de charge du processeur), soit sur un site distant (problème de charge du réseau de communication). Dans les deux cas il faut envisager de gérer le placement pour optimiser le temps de traitement dans le serveur. De plus, cet objet serveur peut lui-même être client d autres serveurs. les objets sont des entités de petites tailles évoluant dans des contextes de petites tailles : ceci doit permettre des interventions fines sur le système. l apparition de supports d exécution répartis pour les applications objets permet d envisager deux niveaux d intervention: au niveau du langage (par analyse du code) ou/et au niveau de l exécution (par analyse du comportement). le standard défini par l OMG [Con90] [Con93] introduit la notion d IDL. Il s agit d un langage de définition d interfaces standardisant les fonctions d échanges entre les objets. Ces interfaces standards facilitent l accès aux informations concernant les communications. Cet aspect est souvent un problème difficile dans le cadre de l équilibrage de processus [GHPS94].

3 L idée directrice est de minimiser les temps de réponse en fournissant à chaque objet un environnement où il puisse s exécuter dans les meilleures conditions. L exécution d un objet engendre deux types de consommations : d une part l objet consomme des ressources systèmes (processeur, mémoire, disque, réseau, etc.), d autre part il consomme des ressources, que nous appelons logicielles, fournies par d autres objets. Il nous semble important de s intéresser à ces deux phénomènes pour minimiser le trafic réseau et équilibrer la charge entre les différents sites. A partir des données traduisant l état du système nous construisons un graphe relationnel qui, en appliquant la théorie de la dérive des connaissances [Bou92], nous permet d optimiser le placement. Nous nous intéresserons, dans le chapitre 2., aux systèmes répartis à objets, et plus particulièrement à COOL, sur lequel nous réalisons nos développements. Il s agit d un environnement d exécution d objets réparti utilisant le micro noyau Chorus. Ensuite, dans le chapitre 3., nous décrirons le contexte dans lequel sera utilisé le service de placement. Le chapitre 4. est dédié à la description des informations intéressantes pour réaliser l optimisation que nous visons. Le choix du nombre et de la nature des informations est crucial pour les performances du service. Dans le chapitre 5., nous présenterons le modèle relationnel et la dérive des connaissances, et, nous expliquerons comment, grâce à cette technique, nous bâtissons un système d observation fournissant des prédictions, au moins, à court terme. Dans le chapitre 6., nous décrirons, la structure et les algorithmes que nous utilisons pour réaliser l équilibrage de charge. Nous conclurons en insistant sur l intérêt de la prise en compte des communications dans le mécanisme d équilibrage de charge. 2. Les systèmes répartis à objets. Le développement des systèmes répartis à objets a pris de l ampleur ces dernières années. Nous pouvons en prendre pour preuve le nombre de systèmes commercialisés. Dans ce chapitre nous présenterons COOL v2 et quelques systèmes à objets proposant des mécanismes d équilibrage de charge. De manière à définir COOL v2 dans son contexte, nous introduirons tout d abord l OMG et le standard proposé par cette organisation OMG Une des organisations principales dans le domaine des systèmes répartis à objets est l Object Management Group (OMG). Il s agit d un consortium dédié à la promotion de la technologie objet. Son objectif est de mettre en place une structure pour le développement et la promotion des différents aspects de la programmation objet. Pour satisfaire cet objectif, l OMG définit un modèle à base de standard de fait. L OMA est un modèle de référence définissant un système à objets comme un fournisseur de services à des clients. Ces services sont implantés par des objets et offerts aux clients à travers une interface de requêtes. A une requête sont associés une opération, un objet cible, éventuellement des paramètres et un contexte optionnel. L interface décrit l ensemble des opérations qu un client peut demander à un objet. Les

4 Site Capsule Cluster Objet Objet d interface Invocation C++ Invocation distante (RPC) FIG. 1 - Principes et Entités de COOL. interfaces sont définies grâce au langage de définition d interface (IDL). Un objet satisfait une interface s il peut rendre l ensemble des services définis dans cette interface. L OMA définit également des entités spécifiques : l Object Request Broker (ORB) fournit les mécanismes d échange transparent entre les objets répartis. Les fonctions communes correspondent aux services tels que l aide en ligne, l impression, etc. Les services objets sont les services optionnels tels que la persistance, le nommage, etc. Les objets applicatifs désignent les objets spécifiques des applications (des clients et des serveurs). L architecture CORBA définit le modèle du bus de communication logiciel (ORB). Ses composants sont : les souches client (stub), l invocationdynamique, l adapteur d objet, l interface ORB, le squelette d implémentation et le noyau ORB sur lequel reposent les composants précédents. Chaque souche représente une opération ou un ensemble d opérations qu un client invoque via une interface. Grâce au composant d invocation dynamique, un client peut construire une requête sans disposer d un objet d interface COOL v2 Le système COOL (Chorus Object Oriented Layer) [Jac94] fournit une infrastructure pour développer des applications réparties à base d objets au-dessus du micronoyau Chorus. COOL v2 est conforme à la spécification de l OMG pour la réalisation de systèmes répartis à objets. Cette couche étend le langage C++ en introduisant les notions de distribution, de persistance et d interopérabilité.

5 L espace d adressage du système COOL v2 (figure 1) est structuré par des clusters, qui sont des groupes d objets, fortement liés construits au niveau de l application. Les clusters sont alloués à l intérieur de capsules qui sont implémentées dans des processus UNIX. Chaque capsule dispose d un ensemble d activités prenant en charge les requêtes réalisées sur les objets des clusters contenus dans la capsule. Un objet, au moment de sa création, est alloué dans un cluster, il ne peut pas en changer dynamiquement. Les objets présents à l intérieur d un même cluster s invoquent mutuellement par appel de méthode normal. Pour invoquer un objet alloué dans un autre cluster, il est nécessaire de disposer d un objet d interface, représentant local de l objet distant (figure 2.1). Un objet d interface contient un sous ensemble des méthodes publiques de l objet qu il représente. Un objet peut disposer de plusieurs interfaces qui sont définies par le programmeur grâce à l IDL (Interface Définition Language). L invocation de méthodes peut être réalisée à travers le réseau : c est le système qui transforme l invocation de l objet d interface en appel vers le serveur. Ce mécanisme est transparent à la localisation, il s appuie sur les RPC et les services du micro-noyau. Les objets d interface offrent un outil intéressant pour déterminer les besoins en terme de communication de chaque objet. La migration d objets (figure 2.2) est une alternative à l invocation distante, COOL permet de migrer un objet serveur, distant, dans l espace d adressage du client et de procéder ensuite par appel de méthode local (RPC intra-site). La migration ne s applique pas directement à des objets, mais à des clusters de manière à obtenir une granularité en relation avec le coût de l opération Invocation distante 2. Migration Capsule 1 3 Objet d interface Cluster Objet Invocation C++ Invocation distante 3. Duplication FIG. 2 - Les mécanismes de distribution dans COOL v2. Il existe une autre alternative à l invocation distante, il s agit de la duplication (figure 2.3). Cette méthode consiste à créer une copie d un objet distant sur le site local. Le système se charge d assurer la cohérence entre les deux instances du même objet.

6 Un objet est dit persistant s il survit à l exécution qui l a créé. Cette fonctionnalité permet de créer des objets serveurs qui seront présents dans le système jusqu à leur destruction explicite. La persistance est, comme la migration, définie au niveau du cluster Quelques projets d équilibrage de charge Bien que le domaine des systèmes répartis à objets soit relativement jeune, plusieurs équipes se sont intéressées au problème de l équilibrage de charge. Nous présentons ci-dessous trois de ces projets, en décrivant succinctement le système et l approche choisie pour réaliser l équilibrage. Guide est un projet développé conjointement par la société Bull et l IMAG. Un prototype a été développé sur UNIX, et plus récemment au-dessus de Mach 3.0. Dans Guide la communication est réalisée par partage d objets. L unité d exécution est constituée d un domaine qui peut s étendre sur plusieurs machines. Sur un site, chaque activité d un domaine s exécute dans un espace d adressage séparé. Le partage d objets sur un site s effectue par mémoire partagée. Dans le cas de partage avec un site distant, il y a transfert de l exécution, c est-à-dire que l activité s étend sur le site de l objet invoqué. Au sein de ce projet, une étude est menée pour inclure un système de gestion de charge [Jen94]. L évaluation de la charge du système est réalisée en prenant en compte uniquement la charge des processeurs. Chaque site dispose d informations sur tous les autres sites du réseau. L implémentation est en cours à l heure actuelle. Ces travaux s appuient sur des études antérieures concernant le comportement et la granularité des objets [LR93]. The Bellerophon load-balancer [Dic91] consiste en un équilibrage de charge dynamique, au niveau du système, indépendement de la topologie. La technique consiste à réaliser des groupes d objets (clump), puis à déplacer ces clumps vers des sites moins chargés. L ensemble des sites n est pas considéré lors des échanges. Seul un groupe restreint baptisé budy set (ensemble de copains) peut recevoir un clump d un site particulier. Les budy set sont construits pour chaque site à partir de leur voisinage et de sites choisis au hasard. En plus des contraintes de charge, le déplacement des clumps est contrôlé par des indicateurs nommés colocator et contralocator. Deux clumps disposant d un colocator l un pour l autre sont regroupés sur un même site. Alors que deux clumps disposant d un contralocator ne sont jamais regroupés. Muse a été développé dans les laboratoires Sony [Tok90]. L approche choisie pour réaliser la gestion de charge dans ce système est proche de celle que nous présenterons dans les chapitres suivants. Les informations utilisées sont des forces d attraction ou de répulsion calculées en fonction du débit de communication et de l activité des objets. Les objets sont plongés dans un champ, et soumis à des forces. Ils se déplacent pour trouver une position d équilibre. Des travaux sont menés pour tenter de définir une métrique pour l espace dans lequel évoluent les objets. 3. Environnement d application. A terme, un des objectifs de notre travail est de fournir un système d équilibrage de charge pour des bornes de services en cours de développement au SEPT.

7 Le projet du SEPT est de réaliser un réseau géographiquement étendu reliant des sous-réseaux. Ces sous-réseaux sont formés par des réseaux locaux de stations de travail. Chaque sous-réseau possède un système basé sur un ORB CORBA et forme un domaine. Dans la suite nous appellerons ce domaine une borne. Toutes les machines ne disposent pas nécessairement du même ORB, mais ils interopèrent selon les recommandations de l OMG. A l intérieur de chaque borne plusieurs services génériques sont disponibles: gestion de compte, authentification, sécurité, facturation, médiation et navigation. A terme, de nouveaux services France Télécom tels que la vidéo conférence et les réunions de groupe peuvent être envisagés. Les services fournis ne sont pas nécessairement identiques sur chaque borne (un service peut être présent sur l une et pas sur d autres). Les services étant implémentés comme des serveurs persistants, au sens CORBA, ils ne sont présents en mémoire que lors de leur utilisation. La borne doit être vue comme une passerelle entre un client et un service offert par un prestataire. Un utilisateur, un client, dispose d une station de travail avec un ORB. Depuis cette station, il peut se connecter sur une borne spécifique (sur laquelle il dispose d un compte). Grâce à cette connexion il va pouvoir utiliser les services proposés par cette borne, mais aussi ceux proposés par des bornes distantes. Le médium de communication reliant d une part les bornes entre elles et d autre part les clients aux bornes est actuellement RNIS, il évoluera vers ATM dans le futur. Les clients potentiels des bornes sont les industriels dans un premier temps, les particuliers à plus longue échéance. La gestion de la charge, sur les bornes de services, doit être envisagée à deux niveaux. D une part, il faut réaliser une gestion interne à chaque borne de manière à maintenir sur chaque processeur un taux de charge équivalent et à garantir des délais de communication faibles. Ceci dans le but d améliorer le confort d utilisation. D autre part, il faut aussi réaliser une gestion inter-bornes, en effet, les services n étant pas nécessairement disponibles sur la borne de connexion d un utilisateur, l utilisation d un service distant peut provoquer une communication intense entre deux bornes. Les communications entre les bornes ont un coût en temps mais aussi un coût en francs, fonction du volume ou du temps. Il est possible qu il soit plus intéressant de déplacer un service d une borne à une autre plutôt que de maintenir le flux de communications. Compte tenu de ce que nous venons de présenter, nous avons fait le choix d utiliser COOL v2 comme support de nos développements. Les raisons qui motivent ce choix sont les suivantes : d une part COOL v2 est au standard CORBA défini par l OMG, de plus il fournit des mécanismes tels que la migration et la persistance qui sont nécessaires à la réalisation d un service de gestion de charge. Finalement, sa disponibilité sur plusieurs plateformes, et la diffusion du système Chorus sont aussi des arguments importants. 4. Les données de l équilibrage de charge Le service de placement que nous développons a pour objectif d optimiser l exécution des applications misent en œuvre dans les SRO. Cette optimisation passe par la minimisation des temps de réponse des applications, mais aussi par une rationalisation

8 de l utilisation des ressources, de manière à pouvoir exécuter un maximum d applications concurremment. L exécution d un objet engendre deux types de consommations : d une part l objet consomme des ressources matérielles (processeur, mémoire, disque, réseau, etc.), d autre part il consomme des ressources, que nous appelons logicielles, sous la forme de services fournis par d autres objets. Nous pensons que c est en fournissant un environnement d exécution qui optimise l accès à ces deux types de ressources que nous obtiendrons les meilleures performances. Parallèlement, il faut garder à l esprit qu un accès optimal à l une des deux ressources ne garantit pas une exécution optimale, si l autre ressource fait défaut. Le nombre et la nature des informations prises en compte dans l équilibrage influent sur les performances du service. Un grand nombre d informations améliore la qualité de la décision, mais leur diffusion et leur traitement coûte cher. Plusieurs études, et en particulier [CH87], réalisées dans le domaine de l équilibrage de processus, montrent que le nombre d informations doit être restreint. Le problème étant de les choisir et de les combiner afin d obtenir un indicateur significatif. Il est possible de classer les informations dans deux groupes, le premier regroupant les informations statiques et le second les informations dynamiques Les informations statiques Les informations statiques n évoluant pas au cours de la vie du système, peuvent être mises à jour lors de l initialisation et être utilisées durant toute la durée du service. Le coût de leur diffusion est réduit, mais il est nécessaire d en limiter le nombre pour ne pas alourdir les traitements. A titre d exemple, nous pouvons citer : la puissance d un processeur ou la quantité de mémoire d un nœud du réseau. La modification de ces caractéristiques demande l arrêt, au moins partiel, du système, impliquant une réinitialisation du service de placement, et une rediffusion de ces valeurs. Beaucoup d informations statiques traduisent une limite à ne pas dépasser lors de l utilisation d une ressource (exemple : la mémoire). C est à ce titre que nous les utiliserons dans la suite Les informations dynamiques Les informations dynamiques sont très intéressantes, car elles permettent de construire une image instantanée de l état du système. En diffusant des informations locales vers un petit nombre de sites distants, il est possible de fournir à chacun une connaissance suffisante pour prendre des décisions correctes. Mais les informations dynamiques sont coûteuses, d une part parce qu il est nécessaire de les capter et d autre part, parce qu il faut les diffuser suffisamment souvent pour qu elles ne deviennent pas obsolètes sur les sites distants. Le taux d utilisation d une ressource, qui s exprime grâce à une information dynamique, est majoré par une constante (information statique), issue du matériel ou du système Les informations utilisées Dans cette partie, nous discutons l intérêt des différentes données disponibles et nous présentons nos choix.

9 Le taux d utilisation du processeur, exprimé en nombre d activités en cours d exécution permet d évaluer la charge d un site. Il est majoré par une limite issue du système, en cas de dépassement de cette limite, l exécution est refusée. Ce taux d utilisation est optimal lorsqu il est sensiblement équivalent sur tous les sites du réseau, c està-dire lorsque la charge de travail est équitablement répartie. L optimisation du temps de réponse des applications passe par la gestion du processeur et donc par la prise en compte de cette information. La disponibilité du réseau est prise en compte par notre service, à travers une résultante de la coopération entre les objets : le débit de communication. Les objets exécutent une tâche complexe grâce au concours de plusieurs d entre eux. En minimisant la longueur des chemins et des délais de communication nous diminuons d une part le temps de traitement de la tâche et d autre part, nous libérons de la bande passante pour d autres communications. La taille mémoire ainsi que le nombre d acteurs et de portes disponibles sur un site limitent le nombre d applications exécutables sur ce site. En effet, le dépassement d une de ces limites engendre le refus de l exécution. Dans un premier temps, pour simplifier les traitements, nous ne contrôlerons pas le respect de ces limites. Par contre, nous n excluons pas de les intégrer une fois notre approche validée. Dans un contexte de réseau, les différents périphériques sont souvent répartis parmi les sites. Des applications, plus liées que d autres à un type de périphérique, gagneront à en être rapprochées. Bien que ce type d information nous semble important, surtout lorsque le périphérique considéré est le disque, nous ne la prenons pas en compte dans notre étude préliminaire. Cette décision tient essentiellement à un souci de simplification du mécanisme d équilibrage. En résumé, nous prendrons en compte deux informations pour réaliser le placement : les relations entre les objets et la charge des processeurs. Nous introduirons les autres informations dans notre approche si les premiers résultats obtenus permettent d envisager des améliorations de performances. Notre volonté de gérer les communications entre les objets implique la mise en œuvre d un système complexe d observation et de stockage. C est ce système que nous présentons dans la partie suivante. 5. L espace relationnel Le modèle relationnel, baptisé dérive des connaissances [Bou92] est issu de réflexions sur l évolution des systèmes informatiques susceptibles de supporter la gestion et l utilisation des systèmes d information des entreprises. La multiplicité des ordinateurs et des réseaux les reliant augmente dans des proportions vertigineuses les échanges de données électroniques. Cela pose le problème du rapport entre la notion de connaissance et celle d information. Dans ce contexte, nous partons de l hypothèse selon laquelle, pour construire de la connaissance, il faut savoir oublier de l information. Autrement dit, la connaissance est obtenue en restructurant les informations échangées. Se pose alors le problème de la définition de critères pertinents pour oublier ou restructurer l information afin d obtenir de la connaissance. Le modèle relationnel considère une information comme une entité évolutive qui, au-delà du sens véhiculé, possède certaines caractéristiques qui rendent compte de l évo-

10 lution de ses interactions avec son milieu. Cela part de l hypothèse selon laquelle toute entité individuelle existe surtout à travers le rôle qu elle joue au sein de collectivités. Ce rôle se définit suivant plusieurs facettes dont celle des interactions qu entretient cette entité avec les autres. Ces interactions et une représentation des différents contextes qui les ont produites, deviennent alors une partie de ce qui définit ces entités. C est à partir de cette facette relationnelle représentant les conditions d évolutions des interactions des entités entre elles, que le modèle relationnel propose des critères de pertinence pour transformer de l information en connaissance. Le modèle relationnel est applicable aux systèmes qui fondent leur auto-adaptation sur les phénomènes stables (reproductibles dans le temps et l espace) qu ils produisent ; cela exclut donc la prise en compte systématique d éventuels épiphénomènes. Ces contraintes permettent alors au modèle relationnel d être un modèle descriptif, car basé sur une auto-observation continue du fonctionnement réel du système, et capable de prédire l évolutionprobable à court terme des interactions entre les entités du système. Les prédictions s adaptent dynamiquement aux évolutions(grandes tendances) du système. Le paragraphe suivant décrit les trois points de vue fondamentaux (local, collectif et global) qui constituent le cadre de la description relationnelle des interactions entre les entités. Ensuite nous aborderons les notions de flux excitatoire et de flux entropique qui introduisent une dynamique d évolution au niveau des valuations des liens relationnels entre les entités. Enfin nous présenterons dans une dernière partie, le mécanisme à la base de la détection de forme collective stable. Dans la suite, chacune des parties sera divisée en deux sous parties, une première pour présenter le principe dans le modèle relationnel, et une deuxième pour expliquer comment ce principe est utilisé pour réaliser la gestion du placement des objets Les trois points de vue fondamentaux L espace relationnel se décrit suivant trois points de vue qui se complètent et s influencent mutuellement. Il se compose d un graphe non nécessairement connexe, où les nœuds représentant les informations en interaction, sont reliés entre eux par des liens fictifs. Les valeurs attachées à ces liens quantifient la nature des interactions entre les nœuds correspondants. Pour réaliser le gestionnaire de charge, chaque nœud du graphe est associé à un cluster du système, et les arcs représentent le volume de données échangées entre les clusters reliés Le point de vue local : les nœuds Chaque nœud possède sa vision de la base au travers des liens qu il entretient. Pour chaque nœud ces liens sont de deux types ; il y a ceux qui correspondent aux sollicitations vers ce nœud et ceux qui correspondent aux sollicitations à partir de ce nœud. Plusieurs paramètres décrivent chaque nœud dans l espace relationnel ; c est le cas de la masse relationnelle qui est une mesure instantanée de l ensemble des interactions du nœud. Cette vision locale se retrouve dans les calculs des différents paramètres relationnels, puisque à aucun moment ces calculs n intègrent pour un nœud donné, le résultat des conséquences dues aux perturbations dont il est indirectement la cause ;

11 c est-à-dire celles qui sortent de son espace local d interaction. Un nœud, donc un cluster, détermine sa masse relationnelle en observant les invocations dans lesquelles il est impliqué. Chaque nœud dispose d informations sur lui même, son importance dans le système. L importance d un nœud est donnée par sa masse structurelle, calculée en faisant la somme des masses structurelles des objets qu il contient. Ces dernières sont déterminées statiquement en fonction de la classe de l objet: elles consistent en une caractérisation de l importance de l objet. Cette masse peut être assimilée à un coût de traitement Le point de vue collectif : les formes relationnelles collectives L une des propriétés des systèmes observés, via le modèle relationnel proposé, est que ses éléments (nœuds) interagissent entre eux de façon concurrente. Cela signifie que certains nœuds sont activés simultanément par plusieurs nœuds différents. Ceci implique que le modèle travaille à un niveau collectif qui dépasse la vision individuelle de chaque nœud de la base. Typiquement c est le cas où deux clients distincts utilisent indépendamment l un de l autre un serveur commun. Pour bien prendre en compte ce phénomène et celui des propagations d excitation qui peuvent dépasser aussi la vision individuelle des choses, nous introduisons dans le modèle la notion de forme relationnelle collective. Cette notion se distingue des points de vue local et global (la base entière) dans la mesure où elle est dynamique. Tant qu une information existe elle reste un nœud pour le système relationnel ; il en est de même pour la base. Cela n empêche pas de voir leur description relationnelle évoluer dans le temps. Par contre les formes relationnelles collectives vont émerger, disparaître ou se transformer (agrégation, séparation...) au cours du temps. Une forme relationnelle collective est un sous-graphe connexe de la base qui est activé sous l impulsion d excitations. Elle correspond à un regroupement d entités fonctionnellement liées entre elles. Pour qu une forme joue un rôle dans le modèle relationnel, il faut de plus qu elle soit homogène pendant toute la durée de son existence. L homogénéité définit une propriété collective de la forme qui autorise des transformations identiques de chaque élément de la forme sans remettre en cause l identité de cette dernière. Cette propriété garantit la conservation des formes à partir de leur structure invariante. Elles sont observables continûment dans le temps si elles évoluent de façon homogène ; lorsque des parties de ces formes évoluent différemment des parties restantes, il se produit alors une rupture d homogénéité. Une première tentative de description catégorielle de la notion de forme a été faite dans [Alb94]. Au niveau du gestionnaire, une forme relationnelle correspond à un groupe de clusters contenant des objets qui communiquent pour réaliser une fonction. Chaque sollicitation de la fonction produit une chaîne d invocations sensiblement identiques, générant l émergence d un collectif d objets coopérants. Ce collectif est intéressant du point de vue de l équilibrage: en plaçant judicieusement les clusters d une forme, c est-àdire en minimisant les chemins de communication tout en laissant les objets travaillant simultanément sur des sites distincts, il est possible de minimiser le temps de traitement de la fonction.

12 La détection de l émergence des formes reste un problème difficile. Nous l aborderons dans la partie consacrée à l invariance perceptive (5.3.) Le point de vue global : la base La base relationnelle (BCO) regroupe l ensemble du graphe dans lequel on observe l évolution dynamique de formes relationnelles collectives. La base possède ses propres paramètres relationnels qui caractérisent son état relationnel statique mais aussi dynamique (évolution). Par composition des accroissements de masse relationnelle des nœuds ou dans certaines conditions des formes, on obtient la masse de la base et ses variations dans le temps. Grâce aux paramètres relationnels propres à la base BCO, on peut construire de nouveaux paramètres utiles pour les mécanismes évolutionnistes. Suivant le type d heuristique qualitative que nous voulons introduire dans le modèle relationnel et les choix algorithmiques d implémentation (pseudo-répartition ou répartition), les paramètres relationnels de la base peuvent être utilisés dans le calcul du comportement évolutif de chaque nœud de la base. C est le cas par exemple pour le calcul des flux entropiques et excitatoires que subit chaque nœud pendant son évolution. Un exemple d heuristique est de faciliter la mémorisation/conservation des liens relationnels dans le cas de bases ne possédant pas beaucoup de connaissances. Réciproquement lorsque de telles bases atteignent un seuil optimal d absorption de connaissance alors les flux excitatoires et entropiques en tiennent compte pour freiner la mémorisation/conservation de nouveaux liens relationnels. Ce genre d heuristique est intéressant si la saturation d une base implique une chute globale des performances du système. Le recours à ces trois points de vue permet de dissocier les oublis relatifs (restructuration) où une information sort du paysage d une autre information par la rupture du lien entre elles, des oublis absolus où une information n entretient plus aucune interaction avec d autres informations de la base. La mise en œuvre de mécanismes prenant en compte le comportement global du modèle est difficile dans un environnement réparti. En effet, les gestionnaires doivent échanger beaucoup d informations pour obtenir une connaissance de l état de la base à un instant donné. Aussi, nous nous restreindrons à l utilisation de mécanismes locaux (nœuds et sites) et semi-locaux (formes) Dynamique des flux excitatoires et entropiques L intensité des liens qui relient les nœuds entre eux dépend principalement des activations réellement faites entre ces nœuds. C est le domaine d application choisi qui précise la notion d activation; dans le cas des clients/serveurs en informatique, l activation correspond à l émission d une requête de service entre un client et un serveur, Plus un nœud active un autre nœud et plus le coefficient (intensité relationnelle [Bou92]) attaché au lien correspondant est grand. Le flux excitatoire précise la façon dont croît ce coefficient. Pour cela il intègre les heuristiques qualitatives qui tiennent compte des paramètres relationnels du contexte suivant les différents points de vue définis précédemment. Parmi ces paramètres, figurent la composition relationnelle du nœud excitant, la structure topologique de la forme collective dans laquelle évolue ce nœud et éventuellement des informations sur

13 la base elle-même. Dans la mesure où l utilisation du modèle relationnel suit l heuristique selon laquelle la tendance est de regrouper les entités qui entretiennent entre elles un haut niveau d interaction, il fallait introduire une composante qui s oppose à des agglomérations définitives. C est le rôle que joue le flux entropique en diminuant périodiquement les valeurs des liens en fonction du contexte. Chaque nœud de la base est donc soumis simultanément à un flux excitatoire et à un flux entropique qui dépendent de sa configuration relationnelle et de celles de son voisinage (forme et base). Puisque l un des apports de ce modèle relationnel est d expliciter ces formes collectives pour en tenir compte dans le comportement du système, afin d en améliorer son fonctionnement, l échelle temporelle dans laquelle se jouent ces émergences est importante. Il faut que les interactions Dt=Dt?1+d génératrices de formes relationnelles soient significatives, c est-à-dire qu elles durent dans le temps, par reproduction du phénomène par exemple. Mais ces interactions peuvent évoluer au cours du temps et prendre des allures toutes autres. C est pour cela que l on doit observer suffisamment longtemps une forme avant de la prendre en compte en tant que telle. La notion de flux excitatoire est relativement aisée à mettre en œuvre pour le placement. Il faut marquer les liens avec des quantités proportionnelles au débit de communication entre clusters. La notion d entropie est plus difficile à concevoir. En fait, le phénomène entropique traduit l idée qu un I=1CD + lien qui n est pas réactivé périodiquement doit voir son intensité diminuer. Pour ce faire, nous introduisons l entropie sous deux formes : l une associée au temps et l autre associée à la charge des sites impliqués dans la relation. Pour introduire la notion de temps nous utilisons deux quantités : le débit instantané (d=volume échangé par unité de temps) et le débit moyen (D= Moyenne pondérée des débits instantanés).d, à l instantt, est obtenu par le calcul suivant : [1] Les constantesetparamètrent l inertie du modèle ( plusest grand devant, plus le modèle est sensible aux variations de débit). L introduction de la charge permet de tenir compte des contraintes propres aux sites dans le placement. SoitIl intensité relationnelle portée par un lien, I est donnée par le calcul [2] OùCest un coefficient calculé à partir de la charge. SiCest proportionnel à la charge, l oubli du cluster par disparition du lien est favorisé. SiCest inversement proportionnel à la charge, la migration du cluster est favorisée L invariance perceptive C est dans les mécanismes d échange entre les nœuds de la base que se construisent dynamiquement les formes collectives. C est grâce aux mécanismes d homogénéisation et d invariance que l on va détecter les formes et suivre leurs éventuelles évolutions.

14 Le mécanisme d invariance perceptive du système visuel est capable de détecter si un changement comportemental d une entité externe est dû à sa propre action (déplacement de la tête) ou à une cause qui lui est extérieure (exemple, par auto-déplacement d entité extérieure). On élargit ici ce champ perceptif au champ interactionnel. Plus précisément, l invariance perceptive s applique à chacun des liens issus de tout nœud N de la base. Il s agit pour ce nœud N de savoir si l action des interactions qu il a vers chacun des nœuds qu il voit, provoque chez le nœud cible une modification structurelle invariante. En d autres termes quand N active un lien vers un autre nœud, il regarde si l évolution de ce nœud est corrélée à cette activation. Une forme sera donc repérée comme stable, lorsqu il existera des fonctions d invariance sur chacun de ses liens et lorsque dans chacun des référentiels locaux traversés par cette forme, les densités locales seront stables. La détection des formes de notre modèle implique un parcours des chemins d activation qui peut être coûteux. Dans le cadre du placement nous avons choisi de détecter l homogénéité sur une longueur de un lien : l ensemble des clusters ayant des liens stables avec un même cluster est considéré comme appartenant à sa forme relationnelle. L apparition d une rupture d homogénéité dans une forme déclenche une reconsidération du placement de ces membres L utile et le potentiel Nous revenons sur les fondements de cette approche, à savoir le problème de la transformation d information en connaissance. D une certaine façon on peut considérer que dans un contexte donné, une information devient connaissance lorsqu elle est utilisable dans ce contexte. Il apparaît ici la notion de réalité et de potentialité. Une information décorrélée de tout contexte atteint une potentialité maximale et une utilité minimale ; la question est alors de savoir si cette information deviendra un jour une connaissance. Cette vision tend à opposer potentialité avec utilité, en fait, il faut sans doute affiner ces deux notions avant de les présenter comme un couple ago-antagoniste. Ceci montre qu une information peut devenir une connaissance et redevenir une information. Le problème de la transformation de l information en connaissance revient alors à être capable ou non de discerner la position des informations et surtout de leurs évolutions dans les champs de potentialités et d utilité. L étude de l évolution des interactions entre les entités de la base se situe au niveau de l observation des glissements entre des connaissances devenant petit à petit des informations; ceci permet donc de gérer les informations obsolètes, qui engorgent inutilement les systèmes d information. Chaque lien de la base appartient au domaine de l utile puisqu uncontexte donné a produit ce lien. En entrant dans le champ de l utile et donc du réel au sens prédéfini, une connaissance peut soit conserver son statut, soit devenir inutile et rejoindre alors le champ du potentiel. Le modèle relationnel travaille donc davantage dans l observation du réel (vision descriptive) à la frontière du potentiel et de l utile, éliminant ainsi le redondant et l inutile.

15 6. Les Gestionnaires d Objets. Dans un environnement à grand nombre de sites, il n est pas réaliste de centraliser les traitements ou de réaliser un état global du système, l utilisation de ces techniques engendre des points de contention sur le réseau et une faible résistance aux fautes. Nous présenterons dans ce chapitre la structure du gestionnaire de charge et l implantation du modèle relationnel réparti. Puis, nous décrirons les traitements réalisés pour optimiser le placement Structure du gestionnaire. Pour réaliser une véritable gestion répartie du placement, nous équipons chaque site d un gestionnaire de placement. Ce gestionnaire est chargé de la gestion des clusters locaux, du maintient d informations sur la charge locale et des sites avec lesquels les cluster locaux entretiennent une relation, et finalement de la détermination, à intervalles de temps réguliers, de la nécessité d une réorganisation (un déplacement) des objets. A A1 A2 A3 1 B B3 B4 2 C C4 C1 3 4 Clusters locaux Informations sur les communications du cluster vers le site Sites distants FIG. 3 - Structure du gestionnaire. Le gestionnaire (figure 3) dispose de deux listes principales. La première liste compte une entrée pour chacun des clusters locaux, la seconde contient une entrée pour chacun des sites distants ayant un cluster en relation avec un cluster local. Cette liste

16 de sites sert principalement au stockage de la charge des sites distants. Cette charge est exprimée en nombre d activités s exécutant concurremment. Nous verrons dans la partie destinée aux traitements comment cette information est utilisée et mise à jour. Le gestionnaire contient aussi des variables d états, tel que la charge du site courant et un indicateur de migration décrivant si le site est en cours de réalisation d une migration. La liste des clusters locaux contient, pour chaque entrée, un descripteur du cluster et une liste des sites avec qui il entretient, au moins, une relation. Le descripteur contient plusieurs informations: la masse structurelle du cluster (somme des masses structurelles des objets contenus). l âge du cluster exprimé en nombre de réorganisations depuis sa dernière migration. un indicateur UNMAP indique si le cluster est actuellement mappé ou non. La liste secondaire de sites est une Rj=Ij liste de relations. Elle est attachée à chaque entrée dans la liste des clusters et elle se compose Pnk=1Ik d entrées contenant : l intensité relationnellei, la valeur effectivement :RA1=IA1 portée par un lien. Elle est obtenue par application de la formule 2. le débit moyendobtenu par application de la formule 1 surd. le débit instantanéddes communications entre le cluster local et tous les clusters, du site considéré, avec lesquels il entretient une relation. le rapportrobtenu en divisant l intensité relationnelleipar la somme des intensités relationnelles de tous les liens du cluster.rtraduit l importance de la relation considérée parmi l ensemble des relations du cluster. Soit A un cluster entretenant des communications avecnsites notés S1,..,Sn, et soitijl intensité relationnelle du lien entre A et le site SjalorsRj, l importance relative du lien (A, Sj) est donnée par [3] Prenons l exemple du cluster A de la figure 3 IA1+IA2+IA3. Un pointeur sur le représentant du site dans le gestionnaire, permettant d accéder à la charge par une invocation simple. Cette liste est le cœur de la représentation répartie du modèle Les traitements. Deux traitements principaux sont implantés dans le gestionnaire, un traitement périodique, pour le calcul des débits et pour la réorganisation, et un traitement basé sur des événements tels que la création ou la destruction d un cluster. A chacun de ces événements est associé un traitement.

17 Les traitements événementiels Les traitements événementiels sont déclenchés par l arrivée d un événement externe au gestionnaire d objets. Nous donnons ci-dessous une liste indicative des événements et les traitements qui leurs sont associés : création ou destruction de cluster (locale) création : ajout d une entrée initialisée dans la liste des clusters. destruction : suppression de l entrée dans la liste. création ou destruction d une activité : mise à jour de la charge du site. création ou destruction d un objet. mise à jour de la masse relationnelle du cluster. démappage d un cluster : mise àvraide l indicateur UNMAP. invocation depuis un cluster local : enregistrement du volume transmi, transmission de la charge locale à l intérieur du message émis. activation d une méthode locale : enregistrement du volume transmi et de la charge du site qui réalise l invocation. demande de migration : vérification de l état de l indicateur de migration (WAIT- MIG) pour s assurer que le gestionnaire n est pas déjà engagé dans une autre migration. Vérification de la différence de charge. Si la migration est acceptable, créer une nouvelle entrée dans la table des clusters locaux, mettre l âge à 0 et Positionner WAITMIG jusqu à la fin de la réorganisation. Cet indicateur est utilisé pour éviter l instabilité du système. Chacun de ces traitements correspond à une méthode du gestionnaire d objets. Ces méthodes sont invoquées directement par les objets grâce à des fragments de code ajoutés à leur déclaration. Ce mécanisme doit être intégré au système si l intérêt du traitement est validé Les traitements périodiques L essentiel du travail périodique du gestionnaire d objets consiste en la mise à jour des débits moyens et la détection des besoins de réorganisation. Soittune unité de temps, à tous les instants cadencés part, les débits instantanésdsont combinés aux débits moyensdgrâce à la formule 1 présentée au paragraphe Puis les débits instantanés sont remis à 0. Ensuite, les intensités relationnellesisont calculées par application de la formule 2 et finalement, les rapportsrsont calculés grâce à la formule 3. La valeur àt?1derest conservée temporairement pour réaliser la détection des déséquilibres. Une fois la mise à jour des données terminée, le gestionnaire d objets doit analyser les données pour trouver d éventuels déséquilibres et choisir d éventuels candidats à la migration. Cette détection est basée sur la comparaison des deux valeurs successives der.

18 PH=nXk=1jRk;t?Rk;t?1j Une forme est dite homogène si la part relative de chacun des liens qui la composent est conservée dans le temps. Considérons une forme simplifiée, centrée sur un cluster, et composée de l ensemble des liens issus de ce cluster. En régime stationnaire, la part de chaque lien reste stable si les volumes de données échangés restent stables, augmentent ou diminuent en même temps. Examinons le cas d une excitation, donc d une augmentation de volume sur un des liens, sans évolution dans les autres relations (une analyse équivalente peut être faite dans le cas d une diminution). La part relative du lien excité va augmenter et celles des relations stables va diminuer. Le gestionnaire utilise la somme des valeurs absolues des différences entrertetrt?1sur chacun des liens pour détecter les pertes d homogénéité. SoitPHl indicateur de perte d homogénéité, etnle nombre de liens attachés au cluster considéré.phest obtenu par : [4] Cette valeur est nulle si l homogénéité est conservée et positive dans le cas contraire. Une réorganisation du modèle est déclanchée siphest supérieur à un seuil. Si une réorganisation s avère nécessaire, il faut trouver un cluster à migrer. L information sur la perte d homogénéité n est pas suffisante car elle est indépendante du volume traité. Aussi le choix du cluster est fait en fonction des volumes échangés parmi les formes nécessitant une réorganisation, et la migration est réalisée vers le site avec lequel le cluster échange le plus d information. La migration a lieu uniquement si le site distant accepte l excédent de charge induit Les traitements exceptionnels Pour gérer les déséquilibres de charge trop importants, nous introduisons deux traitements exceptionnels qui correspondent à deux situations extrêmes : la sous-charge et la sur-charge. Dans le cas où un site est sous chargé, c est-à-dire que sa charge est inférieure à un seuil ou à une valeur calculée à partir de la charge d autres sites, il émet un appel vers un petit nombre de sites choisis aléatoirement. A la réception de cet appel, un site peut, si sa charge le permet, proposer un cluster au site appelant. Le cluster choisi sera celui qui, d une part modifie le moins la structure relationnelle du site fournisseur, et d autre part engendre des traitements. C est-à-dire le cluster qui a les plus faibles communications et la plus forte masse structurelle. Dans le cas d un site sur chargé, il y a déclenchement d un traitement symétrique au précédent : le cluster sur chargé émet des appels, des sites sollicités acceptent la transaction. Comme ci-dessus le cluster déplacé est celui qui modifie le moins la structure relationnelle tout en étant générateur de traitements. 7. Conclusion Nous avons présenté un mécanisme de placement dynamique des objets dans le système réparti à objets COOL v2. Ce mécanisme s appuye sur le modèle relationnel pour intégrer les interactions entre objets comme critère de choix dans le placement.

19 Trois niveaux d observation (objet, forme et base) des objets sont introduits pour permettre une comparaison des points de vue. Le gestionnaire d objets est actuellement en cours de développement, il n est donc pas possible de présenter ses performances. Cependant, nous sommes optimistes quand aux résultats attendus puisque les déplacements seront peu fréquents et réservés aux relations dont l intensité croît de manière notable et durable. Notre premier but est donc la validation du modèle relationnel en tant qu heuristique de placement. La première étape du projet vise des applications du type client/serveur, où les temps de vie des objets sont très longs. Par la suite, nous espérons adapter le gestionnaire d objets au placement dans un ensemble plus diversifié d applications. Par exemple, dans le cas d applications plus dynamiques, il est probable qu une mise au point des paramètres tels que la durée d une période de mesure sera nécéssaire. Enfin, la mise en place d une structure hiérarchique, même si elle est peu adaptée à la répartition, sera nécéssaire pour une implémentation complète du modèle relationnel, ceci pour mettre en œuvre la vision globale de la base d objets. Références [Alb94] D. Albonico. Dérive des connaissances et théorie des catégories. Projet de fin études, ENST Bretagne. Brest, mars [Bou92] [CH87] [Con90] François Bourdon. Un modèle de dérive des connaissances, application à la bureautique. PhD thesis, Université du Maine, july Thomas L. Casavant and Jon G. Huhl. Analysis of three dynamic distributed strategies with varying global informations requirements. In Proc. of 7th International Conference on Distributed Computing Systems, pages , Berlin, DE, September, IEEE Computer Society. The OMG Consortium. The object management architecture guide. Technical Report , Object Management Groupe, Farmington MA. USA, [Con93] The OMG Consortium. The common object request broker: Architecture and specification. Technical Report , Object Management Groupe, Farmington MA. USA, [Dic91] Peter Dickman. Effective load balancing in a distributed object-support operating system. IEEE, [GHPS94] Hervé Guyennet, Bénédicte Herrmann, Laurent Philippe, and François Spies. A performance study of dynamic load balancing algorithms for multicomputers. In IEEE Ed., editor, MPCS 94, Ischia, Italie, May [Jac94] Christian Jacquemot. Chorus/cool v2 reference manual. Technical Report CS/TR-94-16, Chorus system, 1994.

20 [Jen94] Christian Damsgaard Jensen. Elvis: Load distribution in the distributed object-oriented operating system guide. Rapport préliminaire de master, september [LR93] [Phi93] [Tok90] Serge Lacourte and Michel Riveill. Granularity of objects in distributed systems. In Workshop on Granularity of Objects in Distributed Systems, Kaiserlautern - Germany, july Laurent Philippe. Contribution à l étude et à la réalisation d un système à image unique pour multicalculateur. PhD thesis, Université de Franche- Comté, Besançon, France, January Mario Tokoro. Computational field model: Toward a new computing model/methodology for open distributed environment. June 1990.