FR2981236A1 - Procede de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede - Google Patents

Abstract

L'invention concerne le routage adaptatif pseudo-dynamique, pour l'exécution d'une application, dans un cluster comprenant des noeuds et des liens de communication statiques entre ces noeuds. Le routage est basé sur des niveaux de charge des liens de communication. Après avoir identifié (605) des noeuds devant être utilisés pour exécuter l'application, une connexion devant être établie entre ces noeuds, au moins une route connectant ces noeuds est déterminée (610), ladite au moins une route étant déterminée selon ces noeuds, les liens de communication et un niveau de charge associé à chaque lien de communication. Une route déterminée est alors sélectionnée. Une valeur de poids associé à chaque lien de communication de la route sélectionnée est ensuite estimée (685), notamment selon une indication de performance d'une exécution antérieure de l'application. Un niveau de charge associé à chaque lien de communication comprenant la route sélectionnée est incrémenté (625) selon ledit poids estimé.

Description

La présente invention concerne le routage dans un cluster, c'est-à- dire la détermination de routes de communication entre un ensemble de noeuds du cluster, et plus particulièrement un procédé de routage adaptatif pseudodynamique dans un cluster comprenant des liens de communication statiques et un programme d'ordinateur mettant en oeuvre ce procédé.

Le calcul haute performance, aussi appelé HPC (sigle de High Performance Computing en terminologie anglo-saxonne) se développe pour la recherche universitaire comme pour l'industrie, notamment dans des domaines techniques tels que l'aéronautique, l'énergie, la climatologie et les sciences de la vie. La modélisation et la simulation permettent en particulier de réduire les coûts de développement, d'accélérer la mise sur le marché de produits innovants, plus fiables et moins consommateurs d'énergie. Pour les chercheurs, le calcul haute performance est devenu un moyen d'investigation indispensable. Ces calculs sont généralement mis en oeuvre sur des systèmes de traitement de données appelés clusters. Un cluster comprend typiquement un 20 ensemble de noeuds interconnectés. Certains noeuds sont utilisés pour effectuer des tâches de calcul (noeuds de calcul), d'autres pour stocker des données (noeuds de stockage) et un ou plusieurs autres gèrent le cluster (noeuds d'administration). Chaque noeud est par exemple un serveur mettant en oeuvre un système d'exploitation tel que Linux (Linux est une marque). La 25 connexion entre les noeuds est, par exemple, réalisée à l'aide de liens de communication Ethernet ou Infiniband (Ethernet et Infiniband sont des marques). La figure 1 illustre schématiquement un exemple d'une topologie 100 d'un cluster, de type fat-tree. Ce dernier comprend un ensemble de noeuds 30 génériquement référencés 105. Les noeuds appartenant à l'ensemble 110 sont ici des noeuds de calcul tandis que les noeuds de l'ensemble 115 sont des noeuds de service (noeuds de stockage et noeuds d'administration). Les noeuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 115 étant appelé îlot de service. Les noeuds sont reliés les uns aux autres par des commutateurs (appelés switch en terminologie anglo-saxonne), par exemple de façon hiérarchique. Dans l'exemple illustré sur la figure 1, les noeuds sont connectés à des commutateurs 125 de premier niveau qui sont eux-mêmes reliés à des commutateurs 130 de deuxième niveau qui sont à leur tour reliés à des commutateurs 135 de troisième niveau. Comme illustré sur la figure 2, chaque noeud comprend 10 généralement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le noeud 200 comporte ici un bus de communication 202 auquel sont reliés : - des unités centrales de traitement ou microprocesseurs 204 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; 15 - des composants de mémoire vive 206 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution de programmes (comme illustré, chaque composant de mémoire vive peut être associé à un microprocesseur) ; et, 20 - des interfaces de communication 208 adaptées à transmettre et à recevoir des données. Le noeud 200 dispose en outre ici de moyens de stockage interne 212, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes. 25 Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le noeud 200 ou reliés à lui. Les microprocesseurs 204 commandent et dirigent l'exécution des instructions ou portions de code logiciel du ou des programmes. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non 30 volatile, par exemple un disque dur, sont transférés dans la mémoire vive 206. Il est observé ici que les performances d'un cluster sont directement liées à la qualité des routes permettant le transfert de données entre les noeuds, établies via des liens de communication. De façon générale, des liens de communication physiques sont établis entre les noeuds et les commutateurs lors de la configuration matérielle d'un cluster, les routes de communication étant elles-mêmes déterminées dans une phase d'initialisation à partir d'une définition des connexions devant êtres établies entre les noeuds. Selon la technologie de communication mise en oeuvre, la configuration des routes peut être statique ou dynamique. A titre d'illustration, la technologie Infiniband permet, dans un cluster, une configuration statique des routes. Cette configuration utilise des tables statiques de routage (ou LFT, sigle de Linear Forwarding Table en terminologie anglo-saxonne) dans chaque commutateur. Lorsque cette technologie est mise en oeuvre, un algorithme de routage tel que les algorithmes connus sous les noms de FTree, MINHOP, UPDN et LASH peut être utilisé. De façon simplifiée, l'algorithme FTree détermine des routes de telle sorte que celles-ci soient réparties autant que possible à travers les liens de communication existants. A ces fins, lors du routage d'un réseau de communication entièrement connecté selon une architecture de type fat-tree, chaque noeud du réseau est considéré comme ayant une même importance. Ainsi, lorsqu'une route est établie entre deux noeuds d'un même lien, le nombre de routes utilisant ce lien, appelé la charge du lien, est augmenté de un. Lorsque l'algorithme de routage cherche à établir une nouvelle route et que plusieurs possibilités se présentent, il compare les niveaux de charge associés aux liens sur lesquels sont basées ces possibilités et choisit celle dont les liens ont le niveau de charge le plus faible.

La qualité de routage peut être exprimée en termes de nombre de routes par lien. La figure 3, comprenant les figures 3a à 3e, illustre ce principe de routage dans un commutateur 300 lors d'une phase d'initialisation d'un cluster comprenant ce commutateur.

Le commutateur 300 a ici quatre liens de communication d'entrée, notés 310-1 à 310-4, reliant le commutateur 300 à des entrées 305-1 à 305-4 et deux liens de communication de sortie, notés 320-1 et 320-2, reliant le commutateur 300 à des sorties 315-1 et 315-2. Avant l'initialisation, aucun des liens 310-1 à 310-4, 320-1 et 320-2 ne comprend de route. Les niveaux de charge associés à ces liens sont donc nuls comme illustré sur la figure 3a à côté de chaque lien. Puis, lorsqu'une route doit être établie entre l'entrée 305-1 et une sortie du commutateur 300, le lien 310-1 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-1 (les niveaux de charge associés aux liens 320-1 et 320-2 étant égaux, ici à zéro, le premier lien est sélectionné). Les niveaux de charge associés aux liens 310-1 et 320-1 sont alors incrémentés de un pour indiquer que ces liens mettent en oeuvre une route supplémentaire, comme illustré sur la figure 3b. De même, lorsqu'une route doit être établie entre l'entrée 305-2 et une sortie du commutateur 300, le lien 310-2 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-2 (le niveau de charge associé au lien 320-1 étant égal à un et le niveau de charge associé au lien 320-2 étant égal à zéro, ce dernier lien est sélectionné). Les niveaux de charge associés aux liens 310-2 et 320-2 sont alors incrémentés de un pour indiquer que ces liens mettent en oeuvre une route supplémentaire, comme illustré sur la figure 3c. De façon similaire, lorsqu'une route doit être établie entre l'entrée 305-3 et une sortie du commutateur 300, le lien 310-3 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-1 (les niveaux de charge associés aux liens 320-1 et 320-2 étant égaux, le premier lien est sélectionné). Les niveaux de charge associés aux liens 310-3 et 320-1 sont alors incrémentés de un pour indiquer que ces liens mettent en oeuvre une route supplémentaire, comme illustré sur la figure 3d.

Enfin, lorsqu'une route doit être établie entre l'entrée 305-4 et une sortie du commutateur 300, le lien 310-4 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-2 (le niveau de charge associé au lien 320-1 étant égal à deux et le niveau de charge associé au lien 320-2 étant égal à un, ce dernier lien est sélectionné). Les niveaux de charge associés aux liens 310-4 et 320-2 sont alors incrémentés de un pour indiquer que ces liens mettent en oeuvre une route supplémentaire, comme illustré sur la figure 3e. Lorsque toutes les routes entre les noeuds ont été établies, les tables statiques de routage des commutateurs sont mises à jour. Cependant, alors que ces algorithmes de routage donnent de bons résultats, ces derniers ne sont pas optimaux.

L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé pour ordinateur de routage adaptatif pseudo-dynamique pour l'exécution d'une application dans un cluster comprenant une pluralité de noeuds, des liens de communication statiques reliant des noeuds de ladite pluralité de noeuds, ledit routage étant basé sur des niveaux de charge associés auxdits liens de communication, ce procédé comprenant les étapes suivantes, - identification d'au moins deux noeuds dudit cluster devant être utilisés pour exécuter ladite application, une connexion devant être établie entre lesdits au moins deux noeuds identifiés ; - détermination d'au moins une route connectant lesdits au moins deux noeuds identifiés selon lesdits liens de communication, ladite au moins une route étant déterminée selon lesdits au moins deux noeuds identifiés, une pluralité de liens de communication desdits liens de communication et au moins un niveau de charge associé à chaque lien de communication de ladite pluralité de liens de communication, et sélection d'une route déterminée ; - estimation d'une valeur de poids associé à chaque lien de communication de ladite route sélectionnée, ladite valeur de poids étant au moins partiellement estimée selon au moins une indication de performance d'une exécution antérieure de ladite application ; et, - incrémentation d'un niveau de charge associé à chaque lien de communication comprenant ladite route sélectionnée selon ledit poids estimé. Le procédé selon l'invention permet ainsi d'améliorer le routage d'un cluster pour l'exécution d'une application en prenant en compte des informations relatives à une exécution antérieure de l'application.

Le procédé comprend en outre, avantageusement, une étape de détermination de ladite au moins une indication de performance d'une exécution antérieure de ladite application. Selon un mode de réalisation particulier, ladite étape de détermination de ladite au moins une indication de performance comprend une étape d'obtention de valeurs initiale et finale d'au moins un compteur de performance, ladite indication de performance étant basée sur une variation de valeur dudit au moins un compteur de performance. Le procédé selon l'invention est ainsi particulièrement simple à mettre en oeuvre en ce qu'il utilise des informations généralement disponibles dans un cluster visant des caractéristiques d'exécution d'applications. Le procédé comprend en outre, de préférence, une étape d'obtention du schéma de routage lié à l'exécution de ladite application afin de permettre l'établissement d'un lien entre une application et des ressources matérielles mises en oeuvre pour l'exécution de cette application. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'un niveau de priorité d'exécution de ladite application, ladite étape d'estimation d'une valeur de poids associé à ladite route sélectionnée selon au moins une indication de performance d'une exécution antérieure de ladite application étant effectuée en réponse à ladite étape de détermination d'un niveau de priorité de ladite application. Ainsi, l'optimisation du routage d'un cluster est notamment basée sur la priorité d'exécution des applications devant être exécutées. De façon avantageuse, le procédé comprend en outre une étape préalable visant à déterminer si un nouveau routage lié à l'exécution de ladite application doit être effectué. Un nouveau routage peut ainsi être effectué de façon sélective afin qu'il ne soit effectué que sous certaines conditions, en particulier que si ce nouveau routage présente un intérêt réel. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de mise à jour d'au moins une table de routage statique, ladite au moins une table de routage statique étant associée à au moins un commutateur dudit cluster, ledit au moins un commutateur reliant au moins deux noeuds dudit cluster. Le procédé selon l'invention peut ainsi être mis en oeuvre dans des clusters utilisant des technologies telles qu'Infiniband. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de lancement de l'exécution de ladite application.

L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé précédemment. Les avantages procurés par ce programme d'ordinateur et ce moyen de stockage d'informations sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre un exemple de topologie d'un cluster ; - la figure 2 illustre un exemple d'architecture d'un noeud d'un cluster ; - la figure 3, comprenant les figures 3a à 3e, illustre le principe de routage, selon un algorithme de type FTree, dans un commutateur lors d'une phase d'initialisation d'un cluster comprenant ce commutateur ; - la figure 4 représente un diagramme de séquence simplifié illustrant le rôle de modules logiciels intervenant dans la mise en oeuvre de l'invention ; - la figure 5, comprenant les figures 5a à 5d, illustre un exemple du principe de routage avec des poids, dans un commutateur, lors d'une phase d'initialisation d'un cluster comprenant ce commutateur ; et, - la figure 6, comprenant les figures 6a et 6b, illustre certaines 30 étapes d'un exemple d'algorithme pour router ou re-router un cluster comprenant des liens de communication statiques.

Il a été observé que si les routes d'un réseau de communication dans un cluster sont de même nature, la nature des noeuds reliés par ces routes joue un rôle vis-à-vis du volume de données échangé et donc de la bande passante utilisée. Ainsi, par exemple, une route connectant deux noeuds de calcul utilise généralement moins de bande passante qu'une route connectant un noeud de calcul à un noeud de stockage. De même, les routes utilisées pour connecter des noeuds de calcul utilisés pour effectuer une même tâche ont généralement besoin d'une bande passante plus élevée que celles utilisées pour connecter des noeuds de calcul utilisés pour effectuer des tâches différentes. Il est rappelé ici qu'une tâche ou un processus, aussi appelée job en terminologie anglo-saxonne, est une application définie, en particulier, dans un temps et un lieu. Elle est généralement exécutée par un ensemble de noeuds après avoir été lancée par un gestionnaire de tâches, aussi appelé batch manager, resource manager ou job manager en terminologie anglo-saxonne. Le gestionnaire de tâches a notamment pour objet de déterminer le nombre de noeuds nécessaires à l'exécution d'une tâche, de vérifier qu'il existe un nombre de noeuds disponibles suffisant pour exécuter la tâche, en tenant compte, le cas échéant, de contraintes particulières, notamment de contraintes déterminées par un utilisateur, d'allouer des noeuds à l'exécution de la tâche et de lancer son exécution. Certaines applications sont exécutées périodiquement, par exemple tous les jours. En outre, des priorités peuvent être assignées à des applications pour favoriser leur exécution par rapport à l'exécution d'autres applications.

Ainsi, par exemple, une priorité élevée peut être associée à une application de prévision météorologique afin d'obtenir des résultats à une heure donnée. Cependant, s'il est possible de déterminer des règles générales d'assignation de poids à des routes pour améliorer le routage d'un cluster, l'efficacité d'un routage est aussi liée aux applications mises en oeuvre.

L'invention vise donc l'obtention d'informations précises de topologie et de performances liées à une application mise en oeuvre par des noeuds d'un cluster selon une attribution effectuée par un module routage pour permettre, le cas échéant, une amélioration de cette attribution lors d'une mise en oeuvre ultérieure de cette même application. Ces informations peuvent notamment être obtenues à partir de données statistiques issues des dispositifs d'interconnexion utilisés, par exemple de commutateurs de type Infiniband. Le traitement de ces données permet d'établir un profil d'application pouvant être utilisé pour améliorer une opération de routage selon des mesures réelles. Il est observé ici que si l'invention a notamment pour objet d'améliorer le routage lié à une application lorsque cette dernière est ré-exécutée, re-router une application avant son exécution nécessite du temps et représente donc un coût. Il est donc avantageux de n'effectuer une opération de routage que si l'application visée a un niveau de priorité élevé. La figure 4 représente un diagramme de séquence simplifié illustrant le rôle de modules logiciels intervenant dans la mise en oeuvre de l'invention. Outre des modules logiciels liés à une première et une seconde applications 400 et 405, les modules logiciels mis en oeuvre sont ici le gestionnaire de tâches 410 (jobManager), le module d'optimisation 415 selon l'invention appelé ici RAKI (sigle de Routing Advanced Knowledge for lnterconnect technlogies en terminologie anglo-saxonne) et le gestionnaire d'administration et de réseau 420 (par exemple le module connu sous le nom d'openSM). Il est supposé ici que la première application (application 1) n'a pas un niveau de priorité élevé tandis que la seconde application (application 2) a un niveau de priorité élevé (application privilégiée au sens de l'invention). Le gestionnaire de tâches a notamment pour objet de gérer les priorités, les queues et les charges dans le cluster. Il s'agit, par exemple, de l'un des modules logiciels connus sous les noms de PBS Professional (PBS est une marque), LSF (sigle de Load Sharing Facility en terminologie anglo-saxonne) et Slurn (acronyme de Simple Linux Utility for Resource Management en terminologie anglo-saxonne).

Le module d'optimisation selon l'invention a notamment pour objet d'identifier les applications devant être considérées comme privilégiées, de construire des profils de performances pour les applications considérées comme privilégiées et d'appliquer des techniques de renforcement d'apprentissage pour aider à améliorer le retour sur investissement d'un cluster, c'est-à-dire ici d'améliorer les performances du cluster pour l'exécution d'applications données en optimisant le routage.

Le module d'optimisation permet de mémoriser des caractéristiques d'applications, par exemple leur nom, leur taille et l'historique de leurs exécutions. Il permet également d'associer des caractéristiques de routage des composants du cluster, nécessaires à l'exécution de l'application, selon les caractéristiques de l'application visée. Le module d'ajustement permet en outre de mémoriser un profil de performance créé durant l'exécution d'une application et permettant d'améliorer le routage des composants du cluster nécessaires à l'exécution de l'application. De telles informations peuvent, par exemple, être mémorisées dans une base de données. Le module d'optimisation décide s'il est avantageux ou non de re- router les composants du cluster nécessaires à l'exécution d'une application, notamment en ajustant des poids de liens. Le gestionnaire d'administration et de réseau détermine les schémas de routage devant être utilisés et les déploie via, par exemple, des tables de routage. Pour déterminer des schémas de routage, des poids de connexions sont utilisés comme décrit ci-après. Une première étape représentée sur la figure 4 consiste au démarrage ou à l'activation du module d'optimisation selon l'invention (RAKI). Cette étape est ici initiée (étape 425) par le gestionnaire d'administration et de réseau 420 à l'aide d'une commande appelée ici startRAKIO. Dans une étape suivante (étape 430), une interrogation est émise par le gestionnaire de tâches 410 pour déterminer si le module d'optimisation RAKI est opérationnel. Cette interrogation est ici réalisée à l'aide d'une commande appelée RAKIM. Selon un mode de réalisation particulier, l'absence de réponse dans un délai prédéterminé signifie que le module d'optimisation RAKI n'est pas opérationnel.

Lorsqu'une application doit être exécutée, une commande, typiquement appelée scheduleO, est adressée au gestionnaire de tâches afin que ce dernier réserve des ressources pour l'exécution de cette application.

Ainsi, par exemple, lorsque l'application 1 (400) doit être exécutée, une commande schedule() est adressée au gestionnaire de tâches 410 (étape 435). En fonction des ressources disponibles et de la priorité associée à l'application 1, le gestionnaire de tâches va planifier l'exécution de cette application.

Cependant, conformément à l'invention, le gestionnaire de tâches détermine si l'application 1 est privilégiée au sens de l'invention, c'est-à-dire si elle doit faire l'objet d'une analyse particulière et, le cas échéant, d'un nouveau routage. A ces fins, le gestionnaire de tâches adresse une commande, appelée ici privileged?0, au module d'optimisation RAKI (étape 440).

L'application 1 ne devant pas être considérée comme une application privilégiée au sens de l'invention, une réponse négative est reçue du module d'optimisation RAKI (étape 445) ou aucune réponse n'est reçue en réponse à la commande privileged?() (selon un mode de réalisation particulier, l'absence de réponse dans un délai prédéterminé signifie que l'application ne doit pas être considérée comme privilégiée). Dans ce cas, son exécution est gérée de façon standard par le gestionnaire de tâches. De façon similaire, lorsque l'application 2 (405) doit être exécutée, une commande schedule() est adressée au gestionnaire de tâches 410 (étape 450). A nouveau, le gestionnaire de tâches interroge le module d'optimisation RAKI à l'aide d'une commande privileged?() (étape 455) pour déterminer si cette application doit être considérée comme privilégiée au sens de l'invention. L'application 2 étant considérée comme telle, une réponse en ce sens est adressée au gestionnaire de tâches (étape 460). Une commande appelée ici CountersPic0 est alors adressée par le module d'optimisation RAKI au gestionnaire de tâches (étape 465) afin de déterminer l'état d'indicateurs de dispositifs d'interconnexions utilisés, c'est-à-dire de prendre une photographie de l'état de ces dispositifs avant l'exécution de l'application 2. Typiquement, les indicateurs utilisés sont des compteurs de volume du trafic entre chaque paire de ports des dispositifs et des compteurs de blocage de données entre ces paires de ports. Ces états sont, de préférence, transmis au module d'optimisation RAKI (étape 470) où ils sont mémorisés.

Parallèlement, avant ou après, le module d'optimisation RAKI détermine s'il existe un profil pour l'application devant être exécutée, ici l'application 2, et, dans l'affirmative, détermine s'il convient de re-router le cluster, c'est-à-dire reconfigurer des commutateurs du cluster. Dans ce cas, une commande, appelée ici routePrivileged0 est transmise au gestionnaire d'administration et de réseau 420 (étape 475) afin que ce dernier re-route l'application et transmette les résultats aux tables de routage mises en oeuvre. S'il n'est pas nécessaire de re-router l'application, cette dernière est exécutée selon la configuration précédemment définie.

L'application 2 est alors exécutée. A la fin de son exécution (étape 480), le gestionnaire de tâches ré-exécute la fonction précédemment appelée par la commande CountersPic0 pour déterminer l'état d'indicateurs de dispositifs d'interconnexions utilisés, c'est-à-dire de prendre une photographie de l'état de ces dispositifs après l'exécution de l'application 2. A nouveau, ces états sont, de préférence, transmis au module d'optimisation RAKI (étape 485) où ils sont mémorisés. Ainsi, en comparant les états de ces indicateurs avant et après l'exécution de l'application 2, il est possible de caractériser les performances de son exécution.

Ainsi, lorsqu'une application est invoquée par un utilisateur pour être exécutée, il est tout d'abord déterminé si cette application doit être considérée comme privilégiée (au sens de l'invention) ou non. Si l'application ne doit pas être considérée comme privilégiée, elle est traitée de façon standard, sans rerouter le cluster. Déterminer si une application doit être considérée comme privilégiée peut être basé sur des heuristiques telles que le type de l'application, le nombre de noeuds utilisés, le trafic généré dans le cluster et les ressources disponibles du cluster. Si une application doit être considérée comme privilégiée, des actions sont invoquées lorsqu'elle est lancée. Tout d'abord, les valeurs de compteurs de performance des commutateurs impliquées dans l'exécution de cette application sont mémorisées. Par ailleurs, un profil de cette application est obtenu d'une base de données. Un tel profil représente ici un schéma de routage et le trafic associé déterminé lors de l'exécution précédente de l'application. Ce profil permet notamment d'affiner le routage de l'application en assignant et en adaptant des poids à des routes connectant certains noeuds d'un cluster afin de biaiser l'algorithme de routage utilisé vis-à-vis de certaines routes et, par conséquent, d'optimiser l'allocation de bande passante à chaque route dans les liens de communication mis en oeuvre. Comme indiqué précédemment, un profil d'application est déterminé à partir du schéma de routage et d'informations issues de compteurs de performance. Un tel profil est construit, puis ajusté, en deux temps, l'un étant effectué avant l'exécution de l'application et l'autre après. Le pseudo-code donné en annexe (pseudo-code 1) illustre un exemple particulièrement simple d'instructions pour évaluer un tel profil. Dans une première phase mise en oeuvre avant l'exécution de l'application, le schéma de routage est déterminé et les valeurs des compteurs de performance des commutateurs impliqués sont mémorisées à l'aide d'une fonction appelée populate. A ces fins, un arbre de noeuds (tree) est établi à partir d'une liste de noeuds (elected nodes) accessible via le gestionnaire de tâches. Connaissant la topologie des connexions physiques, il est possible d'associer à l'arbre de noeuds construits les ports utilisés (port tree). En utilisant une approche d'analyse large (appelée large parsing approach en terminologie anglo-saxonne) visant tous les ports interférants des commutateurs mis en oeuvre pour l'exécution de l'application, il est possible de tenir compte des tâches annexes, aussi appelées alien jobs, afin d'isoler le trafic issu de ces tâches interférantes.

Le volume de données ayant transité (port volume) et le volume de données bloquées (port blocked) sont alors mémorisés pour chaque port identifié dans l'arbre de noeuds déterminé. Dans une seconde phase, après l'exécution de l'application, une fonction, appelée profile, est appelée. Elle a notamment pour objet de déterminer le volume de données ayant transité (port volume) et le volume de données bloquées (port blocked) pour chaque port identifié dans l'arbre de noeuds déterminé, durant l'exécution de l'application. Cette estimation est obtenue en retranchant le volume mémorisé de données ayant transité (port tree[ii.volume) et le volume mémorisé de données bloquées (port treelliblocked) au volume de données ayant transité (port volume) et au volume de données bloquées (port blocked), mesurés à la fin de l'exécution de l'application, pour chaque port identifié dans l'arbre de noeuds. Les valeurs obtenues sont alors ajustées (port tree statistic adj.) pour tenir compte du trafic généré par l'exécution de tâches annexes. Un tel ajustement peut être réalisé de façon statistique selon le trafic mesuré sur les ports interférants des commutateurs mis en oeuvre pour l'exécution de l'application. Les poids devant être utilisés pour router le cluster afin d'exécuter l'application sont alors ajustés selon les valeurs obtenues. Un tel ajustement consiste par exemple à augmenter les valeurs des poids associés à des liens correspondant à des valeurs de trafic importantes et à diminuer les valeurs des poids associés à des liens correspondant à des valeurs de trafic faibles. A ces fin, des seuils peuvent être utilisés. Les informations permettant d'ajuster les poids devant être utilisés pour router le cluster afin d'exécuter l'application sont alors stockées, de préférence après avoir été compressées, pour pouvoir être utilisées ultérieurement, typiquement lorsque l'application sera exécutée à nouveau.

L'assignation et, le cas échéant, l'ajustement d'un poids donné à certains types de routes ou à certaines routes permet de biaiser le routage en faveur de certaines routes qui ont des besoins spécifiques en termes de bande passante. Ainsi, en utilisant un poids dont la valeur est élevée pour une route connectant deux noeuds, il est possible d'allouer une bande passante plus élevée à la communication de données entre ces noeuds. L'assignation de poids à des routes durant une phase de routage peut être réalisée à travers une API (sigle d'Application Program Interface en terminologie anglo-saxonne). L'assignation de poids lors de la phase de routage peut notamment 30 être déterminée en fonction du type des noeuds, du ou des groupes auxquels ils appartiennent ou en fonction des tâches exécutées par ces noeuds, de façon distincte. Comme décrit précédemment, ces poids peuvent être modifiés pour tenir compte d'informations de performance. Pour assigner un poids en fonction du type des noeuds ou du ou des groupes auxquels ils appartiennent, un fichier de poids, appelé weight file, peut être utilisé. Il permet ici d'assigner des poids à des routes définies par des identifiants de port, appelés port GUIDs (sigle de Globally Unique IDentifiers en terminologie anglo-saxonne) dans un réseau de communication de type Infiniband. Un tel fichier est analysé avant la phase de routage. Il contient une liste des éléments communicants du réseau de communication, typiquement des noeuds, regroupés par type, et une liste de poids pour des couples formés entre ces groupes. Lors de leur analyse, ces poids peuvent être utilisés pour remplir une matrice qui décrit l'incrément de niveau de charge devant être utilisé pour chaque lien de communication lors de la phase de routage. Par défaut, lorsque la valeur d'un poids pour une route connectant deux types de noeuds n'est pas définie, sa valeur est égale à un. Les valeurs obtenues des poids peuvent alors être modifiées selon des informations d'ajustement associée à des applications et déterminées lors de l'exécution de ces applications.

Lorsqu'une route est établie à travers un ensemble de liens durant la phase de routage, le niveau de charge associé à chacun de ces liens est incrémenté de la valeur du poids lié aux types de noeuds entre lesquels la route est établie. La figure 5, comprenant les figures 5a à 5d, illustre le principe de 25 routage en fonction du type des noeuds ou du ou des groupes auxquels ils appartiennent, dans un commutateur 500, lors d'une phase d'initialisation d'un cluster comprenant ce commutateur. Comme le commutateur 300 illustré sur la figure 3, le commutateur 500 a ici quatre liens de communication d'entrée, notés 510-1 à 510-4, reliant le 30 commutateur 500 à des entrées 505-1 à 505-4 et deux liens de communication de sortie, notés 520-1 et 520-2, reliant le commutateur 500 à des sorties 515-1 et 515-2. Les entrées sont, par exemple, des sorties de noeuds du réseau ou des sorties d'autres commutateurs. Avant l'initialisation, aucun des liens 510-1 à 510-4, 520-1 et 520-2 ne comprend de route. Le niveau de charge associé à chacun de ces liens est donc nul comme illustré sur la figure 5a à côté de chaque lien. Puis, lorsqu'une route doit être établie entre l'entrée 505-1 et une sortie du commutateur 500, le lien 510-1 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 520-1 (le même niveau de charge nul étant associé aux liens 520-1 et 520-2, le premier lien est sélectionné). Il est supposé ici que la route utilisant les liens 510-1 et 520-1 qui vient d'être établie a pour objet de connecter un noeud de calcul à un noeud de stockage. Par conséquent, si la valeur du poids d'une route connectant des noeuds de type calcul et stockage est 200, cette valeur est utilisée pour incrémenter le niveau de charge des liens 510-1 et 520-1, comme illustré sur la figure 5b.

De même, lorsqu'une route doit être établie entre l'entrée 505-2 et une sortie du commutateur 500, le lien 510-2 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 520-2 (un niveau de charge égal à 200 étant associé au lien 520-1 et un niveau de charge nul étant associé au lien 520-2, ce dernier, dont le niveau de charge a la valeur la plus faible, est sélectionné).

A nouveau, s'il est admis que la route utilisant les liens 510-2 et 520- 2 qui vient d'être établie a pour objet de connecter un noeud de service à un noeud de calcul et que la valeur du poids d'une route connectant des noeuds de type service et calcul est 99, cette valeur est utilisée pour incrémenter le niveau de charge des liens 510-2 et 520-2, comme illustré sur la figure 5c.

De façon similaire, lorsqu'une route doit être établie entre l'entrée 505-3 et une sortie du commutateur 500, le lien 510-3 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 520-2 (un niveau de charge égal à 200 étant associé au lien 520-1 et un niveau de charge égal à 99 étant associé au lien 520-2, ce dernier, dont le niveau de charge a la valeur la plus faible, est sélectionné). S'il est admis que la route utilisant les liens 510-3 et 520-2 qui vient d'être établie a pour objet de lier deux noeuds de calcul et que la valeur du poids d'une route connectant des noeuds de type calcul est 1, cette valeur est utilisée pour incrémenter le niveau de charge des liens 510-3 et 520-2, comme illustré sur la figure 5d. Un extrait de fichier de poids est présenté en annexe (extrait 1). Il illustre un exemple de groupage de noeuds d'un réseau de communication, chaque groupe représentant ici des types distincts de noeuds, ainsi que l'affectation initiale de poids à des couples de type de noeuds. Selon cet exemple, les noeuds ayant pour port GUIDs les valeurs 0x100901, 0x101201, 0x100903, 0x1101203, 0x101207, 0x100909 et 0x101209 sont des noeuds de type « storage », c'est-à-dire des noeuds de stockage. La définition d'un type de noeuds est ici réalisée à l'aide de l'indication DEF suivie du nom du groupe lui-même suivi de la liste des port GUIDs correspondants, placée entre accolades. De même, les noeuds ayant pour port GUIDs les valeurs 0x100905, 0x101205 et 0x100907 sont des noeuds de type « admin », c'est-à-dire des noeuds d'administration. De façon similaire, les noeuds ayant pour port GUIDs les valeurs 0x10090b, Ox010120b, 0x10090d, Ox10120d, Ox10090f, Ox10120f, 0x100911, 0x101211, 0x100913, 0x101213, 0x100915, 0x100917, 0x101217 et 0x100919 sont des noeuds de type « compute », c'est-à-dire des noeuds de calcul. Par ailleurs, un type de noeuds appelé « service » regroupe tous les noeuds de types « storage » et « admin ».

Les poids sont ici donnés en fin de fichier. La syntaxe pour définir le poids d'une route connectant deux noeuds utilise ici la formulation « ID1 => ID2 poids » où ID1 est le port GUID ou le groupe du noeud d'origine, 1D2 est le port GUID ou le groupe du noeud de destination et poids est la valeur devant être utilisée lors du calcul de la charge d'un lien. Selon cet exemple, une valeur de poids égale à 200 est ajoutée à toutes les routes allant d'un noeud de calcul, noeud de type « compute », vers un noeud de stockage, noeud de type « storage » (« compute => storage 200 »). De façon similaire, une valeur de poids égale à 99 est ajoutée à toutes les routes allant d'un noeud de service, noeud de type « service », vers un noeud de calcul, noeud de type « compute » (« service => compute 99 »). De même, une valeur de poids égale à 200 est ajoutée à toutes les routes allant d'un noeud d'administration (noeud de type « admin ») vers un noeud de stockage, noeud de type « storage » (« admin => storage 200 »). Naturellement, d'autres poids initiaux peuvent être définis. De même, une syntaxe différente peut être utilisée. Par ailleurs, si, selon les exemples 5 donnés précédemment, les routes sont considérées comme étant directionnelles, le niveau de charge associé à une route peut être le même que celui associé à la route inverse comme si les routes étaient bidirectionnelles. Un tel routage peut être effectué lors de l'initialisation du cluster ou être effectué conjointement à un re-routage lié à l'exécution d'une application. 10 Avant de lancer l'exécution d'une application, une liste des identifiants des noeuds alloués à l'exécution de cette application est transmise à un module logiciel de gestion de poids intra-tâche durant une étape appelée prologue de la tâche (ou job prologue en terminologie anglo-saxonne). Cette liste est établie par le gestionnaire de tâches avant de lancer l'application. 15 Le module de gestion de poids intra-tâche associe alors un identifiant de tâche aux identifiants de noeuds appartenant à la liste reçue et établit, de préférence, une correspondance entre ces identifiants de noeuds et des informations mémorisées dans une base de données, notamment des identifiants de port, ou port GUIDs, afin d'établir une correspondance entre un 20 identifiant de tâche et des port GUIDs. Un poids ayant une valeur particulière est alors assigné à chaque couple de port GUIDs associés à un même identifiant. Ainsi, lors du routage, lorsqu'une route est créée via un ensemble de liens de communication, le niveau de charge de ces liens est incrémenté d'une valeur égale à ces poids. 25 A titre d'illustration, si le niveau de charge d'un lien de communication utilisé pour établir une route entre deux noeuds n'étant pas alloués à l'exécution d'une même application est égale à un, le niveau de charge d'un lien de communication similaire utilisé pour établir une route entre deux noeuds alloués à l'exécution d'une même application peut être égale à dix. 30 Ainsi, selon cet exemple, lorsqu'une route connectant des port GUIDs associés à un même identifiant de tâche est créée via un ensemble de liens de communication, le niveau de charge de chacun de ces liens de communication est incrémenté de dix. Après avoir assigné des poids initiaux à des couples de noeuds, ou plus précisément, ici, à des couples de port GUIDs, la valeur de ces poids peut 5 être ajustée selon des informations de performance préalablement calculées. A titre d'illustration, la valeur du poids initial assigné à un couple de port GUIDs peut être incrémentée de dix si le ratio entre les volumes de données ayant transité et de données bloquées associés à ce couple est inférieur à un premier seuil prédéterminé et décrémentée de dix si ce ratio est 10 supérieur à un second seuil prédéterminé. Il est ainsi possible d'ajuster le poids de chaque couple de port GUIDs. Il est observé ici qu'une application est identifiée sur des noeuds dont la cartographie de tous les ports est connue puisqu'ils sont référencés dans le système d'administration du cluster. En outre, à un port d'un commutateur de 15 premier niveau correspond un faible nombre de processus (ou jobs) typiquement un seul, parfois deux ou trois. Ainsi, le gestionnaire de processus peut, à partir des références de ports, déterminer le nom d'une application, par exemple en utilisant ses caractéristiques, notamment ses symboles. A ce nom d'application est associé un profile. 20 Un message peut alors être transmis à un gestionnaire réseau, appelé subnet manager en terminologie anglo-saxonne, pour re-router le cluster en fonction de l'application à exécuter. Après le re-routage, la tâche est lancée. Puis, après son exécution, les valeurs des poids des couples de noeuds (ou de port GUIDs) alloués à 25 l'exécution de cette tâche sont réinitialisés à leur valeur initiale, par exemple à la valeur une. Cette étape est appelée épilogue. Lors de la phase de routage, les routes sont, de préférence, déterminées de façon ordonnée de telle sorte qu'une route associée à un poids dont la valeur est supérieure à celle d'un poids d'une autre route soit 30 déterminée avant cette autre route afin d'optimiser le routage. Cet ordre peut être déterminé à partir de la matrice de poids et des groupes de noeuds permettant de les identifier en fonction de leur type et à partir d'une table de poids déterminée lors du lancement d'une tâche. La figure 6, comprenant les figures 6a et 6b, illustre certaines étapes d'un exemple d'algorithme pour router ou re-router un cluster comprenant des liens de communication statiques. La figure 6a illustre schématiquement un exemple d'algorithme mis en oeuvre pour déterminer et sélectionner une route connectant deux noeuds ainsi que pour déterminer le niveau de charge d'un lien de communication après la sélection d'une route.

Une première étape (étape 600) a ici pour objet l'initialisation d'une matrice de poids permettant d'associer un poids à un couple de noeuds formé de deux noeuds (même poids quelque soit le sens de la route) ou d'un noeud d'origine et d'un noeud de destination (poids lié au sens d'une route) comme illustré en annexe (table 1). Cette matrice peut notamment être établie à partir d'un fichier de poids tel que celui présenté en annexe (extrait 1). Cette étape permet également de mémoriser les correspondances entre un identifiant d'un noeud avec son type et/ou un ou plusieurs groupes auxquels il appartient. Alternativement, la matrice de poids peut établir directement les poids associés à chaque couple de noeuds comme illustré partiellement en annexe (table 2).

La table 1 indique le poids devant être affecté à une route connectant un type de noeud source à un type de noeud destination tandis que la table 2 indique le poids devant être affecté à une route connectant un noeud source à un noeud destination. Dans une étape suivante (étape 605), une paire de noeuds entre lesquels une route doit être établie est identifiée. La paire de noeuds comprend ici un noeud source et un noeud destination. Cette étape est une étape de base des algorithmes de routage pour permettre de définir les routes devant être établies. Les noeuds sont, par exemple, identifiés selon des port GUIDs. Les étapes de détermination des routes possibles pour connecter ces noeuds identifiés et de sélection de la meilleure route sont alors réalisées (étape 610) selon un algorithme standard, par exemple selon l'algorithme FTree.

Dans une étape suivante (étape 615), le type des noeuds identifiés ou le ou les groupes auxquels ils appartiennent sont obtenus selon les informations obtenues durant l'étape d'initialisation. Comme suggéré par l'utilisation de traits pointillés, cette étape est optionnelle car si, en particulier, la matrice de poids déterminée durant la phase d'initialisation associe directement des poids aux identifiants des noeuds, il n'est pas nécessaire, à ce stade, d'en déterminer le type et/ou de déterminer le ou les groupes auxquels ils appartiennent. Le poids de la route connectant ces deux noeuds est alors estimé (étape 620). Cette estimation est basée sur les types des noeuds, le ou les groupes auxquels ils appartiennent et/ou leur identifiant, par exemple leur port GUID, ou sur des résultats de calcul précédemment effectués si les deux noeuds identifiés sont des noeuds de calcul alloués à l'exécution d'une même tâche.

Lorsque le poids est lié au type des noeuds identifiés ou à un ou plusieurs groupes auxquels ils appartiennent, il est, de préférence, directement donné par une lecture de la matrice de poids préalablement déterminée. Alternativement, un poids peut être estimé selon une référence mémorisée dans la matrice de poids selon une fonction ou une table prédéterminée. Les poids issus de la matrice de poids peuvent également être majorés ou minorés selon des circonstances particulières liées, par exemple, à la topologie du cluster et à la position des liens mis en oeuvre par la route considérée. Lorsque le poids est lié à la tâche effectuée par les noeuds identifiés, il est obtenu via une table de poids telle que celle présentée en annexe (Table 25 3). Si la valeur du poids d'une route n'est pas égale à une valeur par défaut, elle est égale à une valeur déterminée en fonction d'un type de noeuds ou de groupes d'appartenance ou en fonction d'une allocation selon une tâche mais elle n'est, de préférence, pas égale à une valeur déterminée en fonction 30 d'un type de noeuds ou de groupes d'appartenance et en fonction d'une allocation selon une tâche. Par conséquent, si cette valeur est déterminée à partir de la matrice de poids utilisée, il n'est pas toujours nécessaire de vérifier si le poids doit être modifié en fonction de l'allocation des noeuds identifiés. La table 3 comprend ici trois colonnes correspondant respectivement à un port GUID source, un port GUID destination et une valeur de poids. 5 Chaque ligne correspond à une route entre le noeud comprenant le port GUID source et le noeud comprenant le port GUID destination. Le poids estimé est alors, le cas échéant, ajusté selon des informations de performance préalablement déterminées. A ces fins, les informations de performance liées à l'application visée sont obtenues. Le poids 10 estimé est alors ajusté selon ces informations et des règles prédéterminées. Le poids estimé et, éventuellement, ajusté pour la route sélectionnée est alors utilisé pour mettre à jour le niveau de charge associé aux liens de communication mis en oeuvre par la route considérée (étape 625). Comme décrit précédemment, la valeur du poids estimé peut être ajoutée au niveau de 15 charge des liens de communication mis en oeuvre par la route considérée. Comme suggéré par la flèche en trait pointillé, les étapes 605 à 625 peuvent être répétées pour établir de nouvelles routes. Typiquement, les étapes 605 à 625 sont répétées pour toutes les routes devant être établies dans le cluster dans lequel l'algorithme illustré sur la figure 6a est mis en oeuvre. 20 La figure 6b illustre certaines étapes d'un exemple d'algorithme de calcul de poids de routes connectant deux noeuds lorsque ces noeuds sont alloués à l'exécution d'une même application. Comme indiqué précédemment, lorsqu'une nouvelle application doit être lancée, le gestionnaire de tâches détermine si celle-ci peut être exécutée 25 et, dans l'affirmative, établit la liste des noeuds alloués à l'exécution de celle-ci. Ainsi, lorsqu'une nouvelle application doit être exécutée (étape 630), le module de gestion de poids intra-tâche reçoit la liste des noeuds alloués à son exécution (étape 635). Un identifiant de tâche est associé à ces identifiants de noeuds. 30 Si aucune nouvelle application ne doit être exécutée, l'algorithme boucle sur lui-même jusqu'à ce qu'il soit stoppé.

Un test est alors effectué (étape 640) pour déterminer si l'application devant être exécutée est, au sens de l'invention, une application devant être considérée comme privilégiée. Comme décrit précédemment, ce test peut être basé sur des heuristiques telles que le type de l'application, le nombre de noeuds utilisés, le trafic généré dans le cluster et les ressources disponibles du cluster. Si l'application devant être exécutée ne doit pas être considérée comme privilégiée, une instruction est transmise au gestionnaire de tâches pour permettre l'exécution de l'application considérée (étape 645). L'algorithme retourne alors à l'étape 630 dans l'attente d'une nouvelle application à exécuter. Au contraire, si l'application devant être exécutée doit être considérée comme privilégiée, le schéma de routage est obtenu (étape 650) ainsi que les valeurs de performance (étape 655). Comme décrit précédemment, les valeurs de performance sont, par exemple, les valeurs de 15 compteurs mis en oeuvre dans les commutateurs devant être utilisés par l'application considérée. Un test est alors effectué (étape 660) pour déterminer s'il convient d'effectuer un re-routage du cluster pour optimiser, en particulier, l'exécution de l'application devant être exécutée. 20 Un tel test peut notamment consister à comparer le nombre de noeuds alloués à l'application à exécuter avec le nombre de noeuds utilisés du cluster et/ou à comparer le temps estimé d'exécution de l'application avec et sans re-routage. S'il n'est pas nécessaire d'effectuer un re-routage, une instruction est 25 transmise au gestionnaire de tâches pour permettre l'exécution de l'application considérée (étape 665). L'algorithme retourne alors à l'étape 630 dans l'attente d'une nouvelle tâche à effectuer. Cependant, comme décrit précédemment, les valeurs de performance sont obtenues (étape 670) à la fin de l'exécution de l'application et le profil de l'application est estimé et mémorisé (étape 675). 30 L'estimation du profil de l'application, pour adapter des poids de connexions dans un cluster, peut simplement consister en la création d'un ensemble de valeurs de performance. Cependant, de façon avantageuse, le profile est estimé à partir de ces valeurs selon un algorithme standard de datamining permettant un apprentissage incrémentai du profil de telle sorte que ce dernier converge vers une solution optimale. Au contraire, si un re-routage doit être effectué, une étape suivante (étape 680) vise à établir un lien entre des identifiants de noeuds et des informations de routage telles que des port GUIDs. Cette étape est typiquement réalisée à partir de la liste d'identifiants de noeuds reçue du gestionnaire de tâches et de données de configuration généralement mémorisées dans une base de données. Cette étape permet notamment d'identifier des adresses sources et destinations de noeuds alloués à l'exécution d'une même tâche et entre lesquels des routes doivent être établies. Enfin, un poids est attribué et ajusté (étape 685) à chaque route connectant une adresse de sortie d'un noeud alloué à la tâche devant être exécutée à une adresse d'entrée d'un noeud alloué à cette même tâche. De telles adresses sont, de préférence, des port GUIDs. Cette étape permet d'établir une table de poids telle que celle illustrée en annexe (Table 3). Le cluster est alors re-routé selon un algorithme tel que celui décrit en référence à la figure 6a (référence A). Le nouveau schéma de routage est obtenu ainsi que les valeurs de performance correspondantes (étapes non représentées). Comme décrit précédemment, les valeurs de performance sont, par exemple, les valeurs de compteurs mis en oeuvre dans les commutateurs devant être utilisés par l'application considérée. Une instruction est ensuite transmise au gestionnaire de tâches pour permettre l'exécution de l'application considérée (étape 665). L'algorithme retourne alors à l'étape 630 dans l'attente d'une nouvelle tâche à effectuer. A nouveau, comme décrit précédemment, les valeurs de performance sont obtenues (étape 670) à la fin de l'exécution de l'application et le profil de l'application est estimé et mémorisé (étape 675). Il est observé que l'algorithme décrit en référence à la figure 6 peut, par exemple, être mis en oeuvre dans un dispositif dont l'architecture est similaire à celle décrite en référence à la figure 2.

Cet algorithme est typiquement mis en oeuvre au niveau du gestionnaire de réseau s'exécutant sur un noeud d'administration. Par ailleurs, il est observé que l'utilisation de poids dans un algorithme de routage est compatible avec un algorithme de gestion de qualité 5 de service (appelé QoS, sigle de Quality of Service en terminologie anglo-saxonne). Il est rappelé ici que la gestion de qualité de service, typiquement basée sur des niveaux de service et des crédits associés à chaque route selon un concept de lien virtuel, permet de favoriser certaines routes en cas de contention du réseau. Cette gestion est donc indépendante du routage en lui-10 même. Ces deux approches sont donc complémentaires pour améliorer la transmission de données dans un cluster et ainsi améliorer les performances de ce dernier. En outre, les informations de performance obtenues peuvent être affichées, sous forme graphique ou textuelle, pour permettre à un utilisateur 15 d'analyser le routage d'une application. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

ANNEXE lBs::RAKI::populate(context information): tree convert node in tree (elected_nodes); port_tree parse tree, list up and down ports (tree); foreach port of port_tree: port_tree[i].volume get the port counter volume (port volume); port_tree[i].blocked get the port retry/blocked counter volume (port blocked); IBs::RAKI::profile(context information): foreach port of port_tree: port_tree[i].volume <- port volume - port_tree[i].volume; port_tree[i].blocked ÷- port blocked - port_tree[i].blocked; port_tree statistic adj. with job's external ports (port_tree); apply heuristic algorithm for weight adjustement (port_tree); compress and store adjustement information (context information); Pseudo-code 1 : évaluation d'un profil de performance DEF storage { 0x100901 0x101201 0x100903 0x1101203 0x101207 0x100909 0x101209 } DEF admin { 0x100905 0x101205 0x100907 DEF service { storage admin } DEF compute { Ox10090b Ox10120b Ox10090d Ox10120d Ox10090f Ox10120f 0x100911 0x101211 0x100913 0x101213 0x100915 0x100917 0x101217 0x100919 } compute => storage 200 service => compute 99 admin => storage 200 Extrait 1 source/dest. storage admin service compute storage 1 1 1 99 admin 200 1 1 99 service 1 1 1 99 compute 200 1 1 1 Table 1 source/dest. 0x100901 0x101201 0x100903 ... 0x100919 0x100901 - 200 200 ... 1 0x101201 200 - ... 1 0x100903 200 200 - ... 1 ... ... ... ... _ ...30

Claims (10)

1. REVENDICATIONS1. Procédé pour ordinateur de routage adaptatif pseudo-dynamique pour l'exécution d'une application dans un cluster comprenant une pluralité de noeuds, des liens de communication statiques reliant des noeuds de ladite pluralité de noeuds, ledit routage étant basé sur des niveaux de charge associés auxdits liens de communication, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - identification (605) d'au moins deux noeuds dudit cluster devant être utilisés pour exécuter ladite application, une connexion devant être établie entre lesdits au moins deux noeuds identifiés ; - détermination (610) d'au moins une route connectant lesdits au moins deux noeuds identifiés selon lesdits liens de communication, ladite au moins une route étant déterminée selon lesdits au moins deux noeuds identifiés, une pluralité de liens de communication desdits liens de communication et au moins un niveau de charge associé à chaque lien de communication de ladite pluralité de liens de communication, et sélection d'une route déterminée ; - estimation (685) d'une valeur de poids associé à chaque lien de communication de ladite route sélectionnée, ladite valeur de poids étant au moins partiellement estimée selon au moins une indication de performance d'une exécution antérieure de ladite application ; et, - incrémentation (625) d'un niveau de charge associé à chaque lien de communication comprenant ladite route sélectionnée selon ledit poids estimé.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape de détermination (675) de ladite au moins une indication de performance d'une exécution antérieure de ladite application.
3. 3. Procédé selon la revendication 2 selon lequel ladite étape de détermination de ladite au moins une indication de performance comprend une étape d'obtention de valeurs initiale (655) et finale (670) d'au moins uncompteur de performance, ladite indication de performance étant basée sur une variation de valeur dudit au moins un compteur de performance.
4. 4. Procédé selon la revendication 2 ou la revendication 3 comprenant en outre une étape d'obtention (650) du schéma de routage lié à l'exécution de ladite application.
5. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de détermination (640) d'un niveau de priorité d'exécution de ladite application, ladite étape d'estimation d'une valeur de poids associé à ladite route sélectionnée selon au moins une indication de performance d'une exécution antérieure de ladite application étant effectuée en réponse à ladite étape de détermination d'un niveau de priorité de ladite application.
6. 6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape préalable visant à déterminer (660) si un nouveau routage lié à l'exécution de ladite application doit être effectué.
7. 7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de mise à jour d'au moins une table de routage statique, ladite au moins une table de routage statique étant associée à au moins un commutateur dudit cluster, ledit au moins un commutateur reliant au moins deux noeuds dudit cluster.
8. 8. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de lancement de l'exécution de ladite application.
9. 9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
10. 10. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur 30 comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.