FR2816419A1

FR2816419A1 - Procede de repartition de charge entre serveurs d'un systeme informatique distribue

Info

Publication number: FR2816419A1
Application number: FR0014155A
Authority: FR
Inventors: Jean Brunet; Jean Luc Richard; Francois Exertier; Adriana Danes
Original assignee: Evidian SA
Current assignee: Evidian SA
Priority date: 2000-11-06
Filing date: 2000-11-06
Publication date: 2002-05-10
Anticipated expiration: 2020-11-06
Also published as: FR2816419B1

Abstract

Le procédé comprend un contrôle de charge (22) par les serveurs (17a-17c), la détermination (22a) d'un transfert de tâches (J1, J2) à partir d'un serveur (17a) et la négociation (23a) avec d'autres serveurs (17b, 17c), à partir du contrôle de charge (22b, 22c) et éventuellement de la prise en compte (24b, 24c) de contraintes applicatives dans ces autres serveurs, des tâches à transférer. La détermination et/ ou la négociation peuvent se faire pendant l'exécution des tâches à transférer.

Description

Titre
Procédé de répartition de charge entre serveurs d'un système informatique distribué.

Domaine technique.

La présente invention se rapporte à un procédé de répartition de charge entre serveurs d'un système informatique distribué. L'invention est particulièrement adaptée à la mise en place d'une répartition dynamique de charge.

Le procédé peut s'appliquer à tout système informatique distribué et est aussi particulièrement adapté aux applications d'administration de systèmes et/ou de réseaux et/ou d'applications, lorsque ces applications adoptent une architecture distribuée. Dans un système d'administration classique, l'architecture est centralisée dans un serveur gestionnaire (manager) principal ou une hiérarchie de gestionnaires incluant un gestionnaire principal et au moins un supra-gestionnaire. Dans un système d'administration distribué, le traitement des données d'administration est décentralisé sur des serveurs gestionnaires intermédiaires constituant une architecture distribuée. Les serveurs intermédiaires sont placés entre le serveur principal, ou une hiérarchie de serveurs gestionnaires, et les ressources informatiques gérées dans un système d'information. Ils se partagent la gestion de ces ressources pour leur surveillance, leur sécurité, etc. Les tâches d'administration qui composent une application d'administration distribuée se trouvent donc disséminées sur les serveurs intermédiaires. L'affectation d'une tâche à un serveur intermédiaire dépend des ressources qui lui sont accessibles, des services disponibles sur le serveur, mais aussi de la charge du serveur. Il peut donc être intéressant de savoir redistribuer des tâches sur les serveurs disponibles, de façon dynamique, en fonction de la charge des serveurs et en fonction d'autres critères, notamment applicatifs. L'invention a donc aussi pour objets corollaires un système informatique et un système d'administration mettant en oeuvre le procédé de répartition de charge de l'invention, ainsi qu'un

programme d'ordinateur pour la mise en oeuvre du procédé de l'invention et un support d'enregistrement du programme, tel qu'un cédérom.

L'art antérieur.

Dans un système informatique distribué, une application distribuée est composée d'unités de traitement, appelées tâches, qui sont exécutées sur plusieurs serveurs. Chaque tâche se trouve dans un serveur et s'exécute dans ce serveur pour effectuer un travail prédéterminé. Cependant, chaque tâche peut a priori s'exécuter dans n'importe quel serveur et peut être déplacée d'un serveur à un autre serveur. Chaque tâche communique avec les autres tâches, afin de rendre à la fin d'exécution de toutes les tâches le service offert par l'application.

Le démarrage d'une application distribuée commence par le déploiement des tâches dans le système informatique. Le déploiement des tâches consiste à les implanter, en fonction d'une configuration initiale et/ou de critères de répartition de charge, sur des serveurs du système informatique. On connaît plusieurs procédés de répartition de la charge entre serveurs d'un système informatique distribué. Par exemple, selon le document EP0692763A (US5, 951,634) du demandeur, chaque serveur calcule régulièrement sa charge et son taux d'évolution et détermine la pente de la courbe d'évolution et la moyenne de charge, de sorte qu'il suffit d'interroger

les serveurs pour connaître le moins chargé. Selon le document EP0715257A (WO96/17297 et US5, 993, 038) du demandeur, chaque machine a un démon, dont l'un sert de maître et les autres servent d'agents. Tous calculent régulièrement la charge de leurs machines respectives. Le maître collecte de chaque agent les données de charge du serveur correspondant et les transmet aux autres agents, de sorte qu'il suffit à une application d'interroger l'agent de sa machine pour connaître la machine la moins chargée pour y être exécutée.

Ces procédés antérieurs s'appliquent au déploiement des tâches d'une application dans le système informatique. Cependant, l'exécution de toutes les tâches dans le système informatique se déroule dans une période de

temps assez grande, de plusieurs dizaines de minutes jusqu'à plusieurs heures par exemple. Pendant ce temps, la répartition de charge dans le système peut varier très fortement et peut même être complètement différente, notamment en cas de défaillance de l'un des serveurs. La configuration initiale de la répartition de la charge peut donc devenir inadaptée et le bon déroulement de l'application peut même en être affecté. Le problème est donc de pouvoir re-configurer l'application, en répartissant autrement les tâches sur les serveurs.

Une nouvelle répartition des tâches n'est efficace que si elle peut prendre en compte plusieurs critères, notamment des critères de charge du système et des critères liés à l'application. Un critère de charge peut par exemple être une surcharge d'un serveur et la répartition a pour but de transférer sur un autre serveur non surchargé tout ou partie des tâches de l'application qui avaient été initialement confiées au serveur. On assure ainsi à la fois une bonne exécution, dans un temps minimal, de toutes les autres tâches que le serveur doit exécuter et une bonne exécution par l'autre serveur des tâches que le serveur initial ne pouvait pas traiter correctement. Des critères applicatifs peuvent être par exemple la structure de l'application, la ré-organisation de l'application et l'accessibilité de certaines ressources utilisées par l'application.

Il serait aussi avantageux que la nouvelle répartition des tâches soit facilement adaptable à différents environnements. Un système peut incorporer différents types de systèmes d'exploitation, ouverts ou non, et même un type de système d'exploitation tel que UNIXTM peut avoir des formes différentes, telles que AIXTM, Linux et Solaris. Ces divers systèmes d'exploitation présentent différents moyens pour accéder aux données de charge du système. On comprend l'intérêt d'une répartition facilement adaptable à ces différents moyens. On comprend aussi l'intérêt d'une facilité qui serait offerte pour pouvoir prendre en compte les contraintes applicatives des différents environnements de la façon indiquée au paragraphe précédent,
Il n'existe pas à présent de procédé et de dispositif permettant de reconfigurer au mieux les tâches d'une application lors de son exécution. Par

exemple, en mettant en oeuvre les procédés décrits dans les deux documents cités, un serveur trop chargé peut savoir quels sont les autres serveurs moins chargés que lui. Il pourrait donc leur transférer tout ou partie des tâches de l'application à traiter. Cependant, un tel transfert serait autoritaire et les tâches pourraient ne pas convenir aux serveurs hôtes ou à la bonne exécution dans le temps des tâches transférées. En outre, ce procédé peut amener des transferts trop fréquents si les serveurs hôtes des tâches transférées deviennent eux-mêmes surchargés. De tels transferts ralentiraient l'exécution de l'application au lieu de l'accélérer.

Sommaire de l'invention.

Un premier but de l'invention est de permettre, à un procédé de répartition de charge dans un système informatique distribué, une reconfiguration des tâches d'une application lors de son exécution.

Un second but est d'adapter la reconfiguration non seulement à des critères de charge mais aussi à des critères applicatifs, liés aux tâches à transférer et/ou à l'application et éventuellement aux relations que peuvent avoir ces tâches avec d'autres applications. Par exemple, une application de performance peut nécessiter le recours d'une autre application ou d'un outil applicatif ou non.

Un troisième but de l'invention est de pouvoir adapter la reconfiguration à l'environnement matériel et/ou logiciel, par exemple aux serveurs, à leur topologie, aux tâches, à leurs fonctions, etc. afin que le transfert assure une bonne exécution des tâches et profite si possible au fonctionnement du système informatique distribué.

L'invention a pour premier objet un procédé de répartition de charge entre serveurs d'un système informatique distribué, les serveurs incluant au moins un processeur et des moyens de mémoire et le procédé comprenant un contrôle de charge par lesdits serveurs et étant caractérisé en ce qu'il comprend en outre la détermination d'un transfert d'au moins une tâche contenue dans les moyens de mémoire d'au moins un serveur et la

négociation avec au moins un autre serveur, à partir du contrôle de charge fait dans au moins ledit autre serveur, d'au moins ladite tâche à transférer.

L'invention a pour second objet un système informatique distribué comprenant des serveurs incluant au moins un processeur, des moyens de mémoire, des moyens de traitement de tâches et des moyens de contrôle de charge, caractérisé en ce qu'il comprend : des moyens de détermination d'un transfert d'au moins une tâche contenue dans les moyens de mémoire d'au moins un premier desdits serveurs ; et au moins un moyen de service de négociation inclus dans les moyens de mémoire d'au moins un second serveur respectif desdits serveurs pour la négociation d'au moins la tâche à transférer à partir d'au moins ledit premier serveur vers au moins un autre serveur, à partir du contrôle de charge d'au moins ledit autre serveur correspondant.

Le système peut être un système d'administration d'un système d'information, dans lequel lesdits serveurs incluent au moins un serveur principal et des serveurs intermédiaires du système d'administration.

Présentation des dessins.

- La figure 1 est une vue synoptique de système d'administration d'un système d'information pour la mise en oeuvre d'un exemple de procédé conforme à l'invention pour la répartition de la charge entre serveurs d'administration.

- La figure 2 est une vue schématique d'un exemple de structure pour la mise en oeuvre de l'invention dans les trois serveurs intermédiaires du système d'administration représenté sur la figure 1.

- Et la figure 3 est un diagramme illustrant des étapes du procédé de répartition de la charge du système d'administration représenté sur les figures 1 et 2.

Description détaillée d'exemples illustrant l'invention.

La figure 1 représente un système d'administration 10 d'un système d'information 11. L'exemple qui suit se rapporte au système

d'administration et de sécurité connu sous le nom de marque déposée OpenMaster du demandeur. Sa conception est conforme aux normes ISO de l'administration de systèmes et réseaux. Dans ces conditions, les termes utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes"administrer"et "gérer"et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais"manage"et ses dérivés. L'homme du métier connaît bien ces normes. Compte tenu de leur masse informative, on ne donnera ici que les éléments nécessaires à la compréhension de l'invention.

Le système d'information illustré 11 est un système informatique distribué et se compose de machines 12, en l'occurrence huit machines 12a- 12h, organisées en un ou plusieurs réseaux 13 correspondant à un ou plusieurs protocoles quelconques, de préférence dédiés à l'administration et normalisés. Par exemple, le réseau 13 peut utiliser le protocole SNMP (Simple Network Management Protocol), le protocole CMIP (Common Management Information Protocol) reposant sur la norme ISO définissant des services pour le transfert des informations d'administration, appelés services CMIS (Common Management Information Services), et les protocoles de la Toile mondiale.

Une machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter une fonction donnée, un ordinateur, ainsi qu'un système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées et passerelles entre réseaux.

Le système d'information 11 est ordinairement un système informatique comprenant plusieurs processeurs 14, un processeur 14 étant par exemple illustré dans seulement trois machines 12 pour la clarté des dessins, des moyens de mémoire 15 pour contenir les logiciels et les données du système, et des moyens d'entrée-sortie (non illustrés) servant à la communication entre machines par l'intermédiaire du réseau 13, ainsi qu'à

une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. Un tel système peut par exemple gérer des données à distance, distribuer des données, commander l'exécution de programmes à distance sur des machines spécialisées, partager localement des ressources physiques ou logicielles et communiquer. Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles, telles que machines, imprimantes, circuits virtuels, réseaux et applications. Le système d'administration 10 utilise au moins l'une de ces ressources selon une technologie orientée objets, bien connue de l'homme du métier.

Le système d'administration 10 choisi a une architecture de type client-serveur pour administration. Cette architecture ne correspond pas à une architecture classique client-serveur, dans laquelle les clients envoient des requêtes aux serveurs pour qu'ils effectuent un traitement et retournent une réponse. Dans le cas présent, les clients sont les machines gérées, auxquelles le serveur envoie des requêtes pour les interroger ou leur faire exécuter des commandes. En d'autres termes, la partie serveur gère et la partie cliente comprend la ou les ressources à gérer. De plus la communication entre clients et serveur se fait de préférence, mais pas nécessairement, de manière asynchrone. Dans l'exemple illustré, la partie serveur comprend un serveur principal 16 inclus dans la machine 12a et trois serveurs intermédiaires 17a-17c inclus dans les machines respectives 12b-12d tandis que la partie cliente comprend quatre stations clientes 18 (18a-18d) permettant l'accès aux ressources à gérer incluses dans les machines respectives 12e-12h. Les trois serveurs intermédiaires 17a-17c sont connectés à travers le réseau 13 entre eux ainsi qu'au serveur principal 16. Les deux serveurs intermédiaires 17a et 17b sont connectés aux stations clientes 18a, 18b et 18c, 18d, respectivement. Pour des raisons de simplification de la description et des dessins, les quatre machines 12e-12h sont seulement celles contenant les ressources gérées par les serveurs 16,17a et 17b, étant bien entendu qu'en partique le nombre de machines gérées peut être quelconque et que le serveur intermédiaire 17c posséderait aussi des machines gérées. Selon une option courante et avantageuse du système d'administration 10, les

serveurs gèrent aussi les machines correspondantes 12a-12d ou, d'une manière plus générale, gère tout ou partie des machines 12 pouvant exister dans le système d'administration. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme du métier de faire une généralisation du système décrit et illustré.

Dans le système d'administration 10 illustré, les ressources gérées dans les machines 12e-12h sont identifiées sous forme d'objets organisés hiérarchiquement dans des sous-arbres respectifs ayant une racine commune et formant une base d'informations d'administration ordinairement appelée base MIB (Management Information Base). Cette base n'est pas une base de données proprement dite, mais est assimilable à un catalogue de caractéristiques puisqu'elle contient la description et le contenu de toutes les classes représentatives des objets gérés par le système d'administration 10.

Le serveur principal 16 fournit un ensemble de services ou fonctions de base, appelées aussi primitives, disponibles pour toutes les applications d'administration. Ces fonctions sont bien adaptées à la structure hiérarchique de la base MIB. Elles incluent notamment les fonctions : M-GET pour lire une ou plusieurs instances d'objets gérés, M-SET pour mettre à jour une ou plusieurs instances, M-CREATE pour créer une instance, M-ACTION pour activer une opération spécifique sur une ou plusieurs instances et M-EVENT pour envoyer un événement.

Dans un système d'administration classique, le serveur principal 16 est directement connecté aux stations clientes 18. Cette organisation centralisée offre de nombreux avantages mais présente l'inconvénient d'être limitée à un nombre donné de stations clientes, de l'ordre d'une centaine, ainsi qu'à un nombre limité d'objets, des centaines de milliers en l'occurrence.

Au-delà de ces nombres, le flux de données d'administration risque d'encombrer le réseau 13 et devient trop important pour être traité correctement par le serveur 16. Les trois serveurs intermédiaires 17a-17c illustrés forment une couche intermédiaire d'administration 17 appelée MLM (Middle-Level Management) et pouvant incorporer un grand nombre de serveurs 17. Chaque serveur intermédiaire 17 est connecté à des stations

clientes 18, deux dans l'exemple illustré pour les serveurs 17a et 17b, pour gérer des ressources qu'elles contiennent. Ce n'est que pour la clarté de dessins que le serveur intermédiaire 17c est illustré sans connexion avec des stations clientes. Ainsi, le système d'administration 10 peut gérer un très grand nombre pouvant atteindre plusieurs milliers de machines, ainsi qu'un très grand nombre d'objets, pouvant être de plusieurs millions. Les trois serveurs intermédiaires 17a-17c sont aussi interconnectés pour pouvoir communiquer entre eux, notamment pour répartir la charge entre eux selon le procédé qui va maintenant être décrit.

Le procédé suppose que le serveur principal 16 est utilisé par un opérateur pour une application d'administration A représentée sur la figure 1. L'application A illustrée est supposée contenir dix tâches J1-J10 pouvant être distribuées dans le système d'administration 10. Le système d'administration 10 procure un environnement d'exécution distribué, dans lequel les tâches peuvent a priori s'exécuter sur n'importe quel serveur 16,17 et peuvent être déplacées d'un serveur intermédiaire 17 à un autre. Seules des contraintes propres à l'application A pourraient empêcher une tâche de s'exécuter sur un serveur donné 17, par exemple le serveur ne supporte pas un service applicatif nécessaire à la tâche ou n'a pas accès à une ressource utilisée par la tâche. Le démarrage de l'application distribuée A commence par le déploiement des tâches J1-J10 dans le système d'administration 10. Le déploiement peut se faire selon un procédé classique, tel que celui décrit dans l'un des deux documents antérieurs cités en introduction de la présente demande.

La figure 2 est une vue schématique des trois serveurs intermédiaires 17a, 17b et 17c et illustre un exemple de structure 20 pour la mise en oeuvre du procédé par ces serveurs. Chaque serveur intermédiaire 17 comprend un module 21 de traitement de tâches, appelé aussi module gestionnaire ou module MLM, un module 22 de contrôle de charge, un module 23 de service de négociation, appelé service de négociation, et un module 24 de décision. Les modules peuvent être représentés par des interfaces de programmation d'application API (Application Programming Interfaces). Pour

la commodité de description, les chiffres désignant les modules sont affectés de la lettre correspondant au serveur intermédiaire, dit serveur hôte, de sorte que le serveur 17a inclut les modules 21a-24a. Dans chaque serveur 17a, 17b et 17c, le module 22 de contrôle de charge et le module 24 de décision sont tous deux connectés au module MLM 21 et au module 23 de négociation. Les modules de négociation 23 sont interconnectés entre eux par l'intermédiaire du réseau 13. Le service de négociation 23 met en oeuvre l'algorithme représentatif du procédé de l'invention illustré dans la figure 3. Le module 22 de contrôle de charge permet de connaître notamment la charge du serveur hôte et sa capacité d'accueil de tâches par rapport à une valeur de charge maximale. Pour cela, il peut avoir accès, par exemple périodiquement, aux données relatives à la charge du serveur hôte 17. Il peut aussi être notifié automatiquement d'un défaut de charge, une surcharge dans l'exemple choisi. Une autre possibilité est de répondre à une requête du serveur principal pour faire un transfert de charge indépendant de tout défaut de charge. Une telle requête pourrait se produire par exemple d'une consigne de regroupement de systèmes, par exemple un regroupement de stations sous le serveur hôte, ou un autre serveur 17. Elle pourrait aussi se produire en cas de changement de droit ou de propriétaire, qui fait qu'une ou plusieurs tâches n'ont plus le droit de s'exécuter sur un serveur. Le fait que ce soit un module 22 facilite beaucoup l'adaptation à l'environnement propre au serveur hôte. Le module de décision 24 détermine si le serveur hôte 17 peut recevoir une tâche d'un autre serveur 17. La détermination est faite selon des critères tels que la présence sur le serveur hôte de modules applicatifs utilisés par une tâche et l'accessibilité du serveur hôte à des ressources requises par la tâche. Le module 24 est donc adapté aux contraintes applicatives du serveur hôte. On

suppose que le procédé de déploiement des tâches J1-J10 de l'application d'administration A a attribué les tâches J1-J4 au serveur 17a, les tâches J5J7 au serveur 17b et les tâches J8-J10 au serveur 17c.

La figure 3 est un diagramme illustrant des étapes d'un exemple d'application du procédé de répartition de charge conforme à l'invention. À l'étape SI du procédé de répartition de charge illustré dans la figure 2, dans le

serveur intermédiaire 17a le module 22a de contrôle de charge détecte dans le module gestionnaire 2 la une surcharge et en informe le service de négociation 23a. À une étape S2, le module 22a détermine le nombre de tâches que le module gestionnaire 21a peut exécuter correctement et, par conséquent, le nombre NI de tâches à lui retirer. On suppose que le module 22a a déterminé de retirer un nombre NI = 2 de tâches. Ce nombre est transmis par le module 22a au service 23a par un message negociate (2). Le service 23a détermine quelles sont parmi les tâches J1-J4 les deux tâches à transférer. Par exemple, cette détermination peut dépendre des tâches et de l'application, ou du niveau de charge du serveur s'il est possible d'analyser la charge de chaque tâche. Un service de négociation est donc paramétré ou configuré en conséquence. On suppose que le service 23 a déterminé les deux tâches Jl et J2. À une étape S3, le service 23a détermine une liste L des serveurs cibles 17 susceptibles d'accueillir tout ou partie du nombre NI des tâches Jl et J2. Ce peut être la liste de tous les serveurs accessibles à l'application et/ou la liste des serveurs voisins. Pour avoir cette liste, le service 23a de l'exemple illustré interroge un serveur de topologie 19 pouvant être sur l'une des quatre machines 12a-12d du système d'administration de la

figure 1 ou sur une machine différente. Une requête getNeighbours (MLMl) signifie qu'elle est émise par le serveur 17a, nommé MLM1, et que ce serveur demande à obtenir les serveurs qui lui sont voisins. En retour, le serveur de topologie 19 donne une liste LI de laquelle il peut déterminer la liste L des serveurs qui conviennent potentiellement comme cibles pour les tâches Jl et J2. Une réponse MLM2 et MLM3 désigne les serveurs 17b et 17c et il est

supposé qu'ils sont les deux cibles valides et potentielles pour Jl et J2 de la liste L.

Le service 23a négocie alors avec les serveurs cibles 17b et 17c de la liste L le transfert des tâches Jl et J2. Dans l'exemple illustré, il négocie à distance, par l'intermédiaire de messages, avec les services de négociation 23b et 23c des serveurs respectifs 17b et 17c. La négociation choisie comme exemple a pour but de connaître le nombre N2 de tâches qu'un des serveurs cibles de la liste L peut accueillir et de les lui transférer et, si N2 est inférieur

au nombre NI des tâches à retirer du serveur 17a, de négocier avec un autre serveur cible de la liste L. A une étape S4 du procédé, le service de négociation 23a consulte la liste L pour désigner le premier serveur 17 avec lequel il va négocier, en l'occurrence le serveur 17b. À une étape S5, le service 23a interroge par une requête getNegoServiceO le serveur 17b pour connaître son service de négociation. La réponse NegoService2 identifie le service de négociation 23b. A une étape S6, le service 23a négocie avec le service 23b le transfert des tâches Jl et J2, en lui envoyant une requête localNegociate ( {Jl, J2}). A une étape S7, le service 23b détermine s'il peut

accueillir les tâches Jl et J2. La détermination choisie comprend une interrogation faite par le service 23b au module 22b de contrôle de charge pour savoir si le module 21b de traitement des tâches peut supporter une charge plus importante. Dans la négative, le service 23b répondrait que le serveur hôte 17b ne peut accueillir aucune des tâches proposées. On suppose que le module 22b donne une réponse positive à la demande du service 23b.

Dans ce cas, le service 23b interroge le module de décision 24b pour savoir si le serveur 17b a les ressources applicatives nécessaires pour traiter les tâches Jl et/ou J2. On suppose que le module 24b décide de ne pouvoir accueillir que la tâche Jl et non la tâche J2. A une étape S8, le service 23a est informé par

un message {JI} du service 23b que ce dernier peut accueillir la tâche Jl et la lui transfère. Le transfert est commandé par le service 23a par un message moveTasks (JJ11) envoyé au module 21a de traitement des tâches, qui les transfère au moyen d'un message moveTo (MLM2).

À une étape S9, le service 23a compare le nombre N3 des tâches transférées avec le nombre NI = 2 des tâches à transférer. En l'occurrence, le nombre N3 correspond au nombre N2 = 1 de tâches que le premier des serveurs cibles choisi 17b peut accueillir. Le reste n'étant pas nul, le service 23a retourne à l'étape S4 pour consulter la liste L et connaître le serveur suivant avec lequel négocier la tâche restante J2, en l'occurrence le serveur 17c. Les mêmes étapes S5-S9 recommencent entre les serveurs 17a et 17c. En bref, à l'étape S5 le service 23a interroge le serveur 17c et connaît dans la réponse NegoService3 l'identification du service 23c. A l'étape S6, le service

23a négocie par un message localNegociate ( {J2}) le transfert de la tâche J2. A l'étape S7, le service 23c détermine s'il peut accueillir la tâche J2. En supposant l'accueil possible, le service 23a à l'étape 88 est informé par un message {J2} du service 23c que ce dernier peut accueillir la tâche J2 et la lui transfère. Le transfert est commandé par le service 23a par un message moveTasks ( {J2}) envoyé au module 21a de traitement des tâches, de sorte que la nouvelle valeur du nombre N3 est égale à la valeur précédente ajoutée d'une unité (N3 = N3+1 = 2). À l'étape S9, le service 23a compare le nombre total N3 des tâches transférées avec le nombre NI = 2 des tâches à transférer. Le reste étant nul, la négociation s'achève à une étape SIC. Elle se traduit par l'envoi d'un message de fin endOfNegociationO au module 21a de traitement des tâches.

Chaque service de négociation 23 illustré est entièrement générique, en ce sens qu'il représente un modèle (template) logiciel de répartition de charge qui peut s'appliquer à tout serveur intermédiaire 17. Ce modèle utilise des fonctions complètement adaptables à l'environnement du service. Dans l'exemple illustré, on a vu que ces fonctions sont attribuées aux deux modules 22 et 24, qui permettent respectivement de prendre en compte les contraintes de charge de système du serveur hôte 17 et les contraintes applicatives du serveur hôte. Par conséquent, il ressort que l'emploi des ces deux fonctions est très avantageux mais n'est pas nécessaire, la fonction relative à la charge pouvant suffire.

La négociation peut aussi être différente de celle illustrée. Par exemple, au lieu de la négociation successive illustrée avec les serveurs de la liste L, elle pourrait être cumulative, comprenant une étape d'interrogations à tout ou partie des serveurs cibles de la liste L et une étape de sélection de ceux-ci pour se libérer des tâches à transférer.

D'autre part, le service de négociation 23a pourrait se déplacer sur les serveurs cibles 17b et 17c et y interroger le service de négociation 23b et 23c correspondant. Ceci éviterait l'envoi du message localNegociateO de l'étape S6 et réduirait le trafic dans le réseau 13. En variante, on comprend alors qu'il peut ne pas être nécessaire que tous les serveurs intermédiaires

aient un service de négociation 23. Par exemple, si lors de l'étape S5 le serveur 17a apprenait que le serveur cible 17b n'avait pas de service de négociation 23b, le service 23a se déplacerait pour aller dans le serveur cible 17b et pourrait être conçu pour y négocier à la place du service 23b avec les modules 21b, 22b et 24b. Cela aurait pour conséquence limite possible de pouvoir mettre le service de négociation dans un seul serveur, le serveur principal 16 par exemple, ou le serveur de topologie 19, ou autre. Mais l'intérêt du procédé de l'invention serait dans ce cas moins grand. L'utilisation d'un service de négociation 23 mobile est possible notamment si le système d'administration 10 dispose d'une technologie à agents mobiles. Un agent mobile est un objet de technologie JavaTM, qui peut se déplacer d'un serveur à l'autre selon certains critères, comme un itinéraire prédéfini ou sur un ordre direct de migration par exemple, pour y exécuter une ou plusieurs de ses méthodes. Le procédé est donc particulièrement bien adapté aux environnements distribués sous forme d'agents mobiles, où les tâches et le service de négociation lui-même sont représentés par des agents. Il peut cependant être mis en oeuvre dans un environnement distribué classique. Un tel environnement peut être par exemple celui utilisant l'architecture d'objets distribués connue sous le nom d'architecture CORBA (Common Object Request Broker Architecture) définie par le groupement de fournisseurs et d'utilisateurs travaillant à la normalisation de la gestion des objets et connu sous le nom OMG (Object Management Group) et/ou RMI (Remote Method Invocation) de la société Sun Microsystems pour des objets distribués écrits en langage Java.

Selon une autre variante, le serveur de topologie 19 pourrait aussi indiquer dans la liste LI l'identification des services de négociation 23 des serveurs intermédiaires 17 de la liste Ll. Ceci éviterait l'étape S5 du procédé. Plus généralement, la liste L n'est pas nécessairement extraite d'un serveur, comme illustré. Parmi les cas possibles, la liste LI ou L pourrait se trouver dans chaque serveur. D'autre part, le service de négociation 23a peut notifier le transfert des tâches au module 21a de traitement des tâches par appels asynchrones, s'il en a la possibilité. Enfin, dans l'exemple illustré, la

détermination des tâches à transférer lors de l'étape S3 comprend l'envoi par le module 22a du nombre NI au service 23a et le choix par le service 23a des tâches à transférer. Cependant, il serait possible par exemple que le choix se fasse par le module 22a. Dans ce cas, le message qu'il aurait émis serait negociate ( {Jl, J2}). Le choix pourrait se faire aussi par le module de décision 24a, seul ou avec le module 22a. Mais la négociation pourrait se réduire à déterminer uniquement un nombre NI de tâches, sans sélection des tâches à transférer.

On a vu aussi que la surcharge d'un serveur pour provoquer une répartition de charge conformément au procédé de l'invention n'est qu'un cas particulier et qu'un autre cas parmi d'autres peut être une réponse à une requête faite par un opérateur pour modifier une répartition de charge. Par conséquent, la détermination d'un transfert de tâches n'est pas limitée à l'initiative du module 22 et peut par exemple être issue d'une application d'administration du serveur principal 16 et prendre la forme d'une requête de répartition de charge similaire à negociateO. En outre, bien que seulement les serveurs intermédiaires 17 mettent en oeuvre le procédé de l'invention, il ressort de l'exemple illustré que le serveur principal 16 et même une hiérarchie de serveurs principaux pourrait aussi le mettre en oeuvre.

En résumé, le procédé de répartition de charge entre serveurs 16, 17a-17c d'un système informatique distribué comprend un contrôle de charge par les serveurs, la détermination d'un transfert d'au moins une tâche Jl, J2 à partir d'au moins un serveur 17a et la négociation 23a avec au moins un autre serveur 17b, 17c, à partir du contrôle de charge fait dans au moins ledit autre serveur, d'au moins ladite tâche à transférer. Dans l'exemple illustré, le transfert est déterminé par le nombre NI de tâches à transférer. Cette caractéristique n'est pas nécessaire, puisque le procédé pourrait comprendre un cycle récurrent comprenant les étapes de déterminer une tâche à transférer et négocier son transfert. Selon l'exemple illustré, la détermination inclut aussi la sélection d'au moins la tâche à transférer. On a vu aussi que la sélection est optionnelle. D'autre part, selon l'option de l'exemple décrit, la négociation est faite aussi à partir d'une décision prise par au moins ledit

autre serveur selon des critères applicatifs. Selon le mode de négociation illustré, le module 23a négocie avec les modules 23b et 23c, qui utilisent eux- mêmes les modules de décision 24b et 24c respectifs. Selon un autre mode possible, le module 23a pourrait négocier directement avec les modules de décision respectifs 24b et 24c à travers le réseau 13, ou pourrait se déplacer dans les serveurs correspondants. De même, la négociation décrite et illustrée est faite successivement avec au moins ledit autre serveur 17b, 17c, si possible jusqu'à épuisement des tâches à transférer. Cependant, on a vu aussi que la négociation pouvait comprendre une étape d'interrogations avec tout ou partie des serveurs et une étape de sélection de leurs réponses. Le procédé de l'invention permet de façon optionnelle mais très avantageuse de faire la détermination et/ou la négociation pendant l'exécution d'au moins la tâche à transférer.

L'invention a aussi pour objet un système informatique distribué 10, 11 comprenant des serveurs 16,17 incluant des moyens 21 de traitement de tâches et des moyens 22 de contrôle de charge, et peut contenir d'autres types de serveurs. Le système comprend en outre des moyens 22 de détermination d'un transfert d'au moins une tâche Jl, J2 à partir d'au moins un premier 17a desdits serveurs, et au moins un moyen 23a-23c de service de

négociation inclus dans au moins un second serveur respectif 17a-17c desdits serveurs pour la négociation d'au moins la tâche à transférer à partir d'au moins ledit premier serveur 17a dans au moins un autre serveur 17b, 17c, à partir du contrôle de charge d'au moins ledit autre serveur correspondant. De préférence, le transfert de charge est déterminé par les moyens 22 de contrôle de charge. On a vu qu'il peut aussi être déterminé par une requête de répartition de charge, par exemple issue d'une application d'administration

extérieure au second serveur et similaire à negociateO. De préférence également, la négociation est faite entre moyens 23a-23c de service de négociation inclus dans des serveurs respectifs 17a-17c. Dans l'exemple illustré, tous les moyens contenus dans les serveurs sont sous forme de modules. Cette forme est très avantageuse, mais n'est pas nécessaire. On a vu que le moyen de service de négociation peut être un agent mobile. Selon un

autre mode possible, au moins le second serveur comprend un moyen de décision (24) utilisé pour décider selon des critères applicatifs si le second serveur peut ou non accueillir tout ou partie des tâches à transférer. Enfin, bien que l'invention peut s'appliquer à tout système informatique, elle convient plus particulièrement un système d'administration 10 d'un système d'information 11, lesdits serveurs incluant au moins un serveur principal 16 et des serveurs intermédiaires 17 du système d'administration 10.

Claims

Revendications 1. Procédé de répartition de charge entre serveurs (16, 17a-17c) d'un système informatique distribué (10, 11), les serveurs incluant au moins un processeur (14) et des moyens de mémoire (15) et le procédé comprenant un contrôle de charge (22) par lesdits serveurs et étant caractérisé en ce qu'il comprend en outre la détermination (22a) d'un transfert d'au moins une tâche (Jl, J2) contenue dans les moyens de mémoire (15) d'au moins un serveur (17a) et la négociation (23a) avec au moins un autre serveur (17b, 17c), à partir du contrôle de charge fait dans au moins ledit autre serveur, d'au moins ladite tâche à transférer.
2. Procédé selon la revendication 1, caractérisé en ce que le transfert est déterminé par le nombre (NI) des tâches à transférer.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la détermination inclut la sélection d'au moins la tâche à transférer.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la négociation est faite aussi à partir d'une décision prise (24b) par au moins ledit autre serveur (17b) selon des critères applicatifs.
5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que la négociation est faite successivement avec au moins ledit autre serveur jusqu'à épuisement des tâches à transférer.
6. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que la négociation comprend une étape d'interrogations avec tout ou partie des serveurs et une étape de sélection de leurs réponses.

<Desc/Clms Page number 19>
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que la détermination et/ou la négociation se font pendant l'exécution d'au moins la tâche à transférer.
8. Système informatique distribué (10, 11) comprenant des serveurs (16,17) incluant au moins un processeur (14), des moyens de mémoire (15), des moyens (21) de traitement de tâches et des moyens (22) de contrôle de charge, caractérisé en ce qu'il comprend : des moyens (22) de détermination d'un transfert d'au moins une tâche (Jl, J2) contenue dans les moyens de mémoire d'au moins un premier (17a) desdits serveurs ; et au moins un moyen (23a-23c) de service de négociation inclus dans les moyens de mémoire (15) d'au moins un second serveur respectif (16,17a-

17c) desdits serveurs pour la négociation d'au moins la tâche à transférer à partir d'au moins ledit premier serveur (17a) vers au moins un autre serveur (16,17b, 17c), à partir du contrôle de charge d'au moins ledit autre serveur correspondant.
9. Système selon la revendication 8, caractérisé en ce que le transfert de charge est déterminé par les moyens (22) de contrôle de charge.
10. Système selon la revendication 8 ou 9, caractérisé en ce que le transfert de charge est déterminé par une requête (negociate) de répartition de charge.
11. Système selon l'une des revendications 8 à 10, caractérisé en ce que la négociation est faite entre les moyens (23a-23c) de service de négociation inclus dans des serveurs respectifs (17a-17c).
12. Système selon l'une des revendications 8 à 11, caractérisé en ce que le moyen (23a-23c) de service de négociation est un module.

<Desc/Clms Page number 20>
13. Système selon l'une des revendications 8 à 12, caractérisé en ce que le moyen (23a-23c) de service de négociation est un agent mobile.
14. Système selon l'une des revendications 8 à 13, caractérisé en ce qu'au moins le second serveur comprend un moyen de décision (24) utilisé pour décider selon des critères applicatifs si le second serveur peut ou non accueillir tout ou partie des tâches à transférer.
15. Système selon l'une des revendications 8 à 14, caractérisé en ce que le système est un système d'administration (10) d'un système d'information (11) et en ce que lesdits serveurs incluent au moins un serveur principal (16) et des serveurs intermédiaires (17) du système d'administration (10).