FR2984052A1 - Procede et programme d'ordinateur de configuration d'equipements dans une infrastructure informatique ayant une architecture de type infiniband - Google Patents

Abstract

L'invention a notamment pour objet la configuration d'équipements dans un cluster ayant une architecture de type Infiniband suite au démarrage de ces équipements. Le cluster comprend ici une pluralité d'équipements dont au moins un équipement d'administration configuré pour accéder à des données de configuration du cluster, l'équipement d'administration pouvant être notifié du démarrage d'équipements et pouvant explorer le cluster pour établir au moins un chemin de routes directes pour accéder à un équipement. Après avoir reçu (430) une notification de démarrage d'un équipement, la notification comprenant un chemin de routes directes pour accéder à cet équipement dans le cluster, au moins une caractéristique de cet équipement est obtenue (435) à partir des données de configuration du cluster selon le chemin d'accès à l'équipement. Ce dernier est alors configuré (475) selon ladite au moins une caractéristique obtenue.

Description

La présente invention concerne la gestion d'infrastructures informatiques telles que des clusters et des centres de traitement de données (ou data centre) et plus particulièrement un procédé et un programme d'ordinateur de configuration d'équipements dans une infrastructure informatique ayant une architecture de type Infiniband (Infiniband est une marque). 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'automobile, 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 (parfois traduit « grappes de serveurs »). Un cluster comprend typiquement un 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 connexion entre les noeuds est, par exemple, réalisée à l'aide de liens de communication Ethernet et de réseaux d'interconnexions (par exemple 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 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. Les commutateurs routent des messages de leurs sources vers leurs destinations selon des tables de routages programmées lors de l'initialisation du cluster. A ces fins, un port de sortie est généralement associé, dans chaque commutateur, à une ou plusieurs destinations. Un cluster peut être décomposé en infrastructures élémentaires aussi appelées subnets en terminologie anglo-saxonne. Chaque subnet est géré par des gestionnaires et des agents dont un gestionnaire principal de subnet (master subnet manager) tel que celui connu sous le nom d'OpenSM.

Un gestionnaire principal de subnet peut scanner de façon périodique l'infrastructure élémentaire correspondante pour déterminer si des équipements, typiquement des noeuds, ont été ajoutés ou supprimés. De telles modifications sont notamment liées au démarrage d'équipements et à des pannes. En outre, des messages de notification asynchrone, appelés traps en terminologie anglo-saxonne, peuvent être automatiquement émis à destination du gestionnaire principal de subnet pour l'informer d'une telle modification sans que celui-ci ait à scanner l'infrastructure élémentaire. Un message de notification asynchrone est typiquement émis par un commutateur auquel est connecté l'équipement ajouté ou supprimé. Un message correspondant est alors généralement adressé à un administrateur du cluster qui peut alors, le cas échéant, installer un nouveau noeud après avoir obtenu son adresse logique (généralement disponible dans une base de données de configuration du cluster). Comme illustré sur la figure 2, chaque noeud comprend typiquement 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) ; - des composants de mémoire vive 206 (RAM, acronyme de 10 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, - des interfaces de communication 208 adaptées à transmettre et à 15 recevoir des données. Le noeud 200 dispose en outre ici de moyens de stockage interne 210, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes. Le bus de communication permet la communication et 20 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 volatile, par exemple un disque dur, sont transférés dans la mémoire vive 206. 25 Lors de l'installation d'un cluster, chaque noeud est typiquement testé avant d'être configuré. A ces fins, chaque fois qu'un nouveau noeud est mis en route, une routine de test pré-chargée dans le noeud sous forme d'image est installée et exécutée puis, lorsque le noeud a été testé et qu'il est considéré comme stable, une image liée au rôle du noeud dans le cluster est obtenu, 30 typiquement via le réseau de communication auquel est connecté le noeud, puis est installée. L'obtention et l'installation d'une image, généralement appelées le déploiement, sont souvent réalisées de façon automatique. Après l'installation de cette image, le noeud est opérationnel au sein du cluster. Cependant, si le déploiement peut être réalisé de façon automatique, il est mis en oeuvre par un opérateur ou administrateur qui identifie les noeuds devant être déployés et obtient leurs caractéristiques nécessaires au déploiement, notamment leur adresse logique dans le cluster. La taille des clusters augmente de jour en jour. Par conséquent, leur installation et le déploiement logiciel associé, mis en oeuvre, en particulier, pour installer les systèmes d'exploitation nécessaires et les applications logicielles, requièrent un temps de plus en plus long.

Il existe donc un besoin pour améliorer la configuration d'équipements dans une infrastructure informatique telle qu'un cluster, en particulier une infrastructure informatique ayant une architecture de type Infiniband. L'invention a ainsi pour objet un procédé de configuration d'un équipement dans une infrastructure informatique ayant une architecture de type Infiniband, suite au démarrage dudit équipement, ladite infrastructure informatique comprenant une pluralité d'équipements dont au moins un équipement d'administration configuré pour accéder à des données de configuration de ladite infrastructure informatique, ledit au moins un équipement d'administration pouvant être notifié du démarrage dudit équipement et pouvant explorer ladite infrastructure informatique pour établir au moins un chemin de routes directes pour accéder audit équipement, ce procédé comprenant les étapes suivantes, - réception d'une notification de démarrage dudit équipement, ladite notification comprenant un chemin de routes directes pour accéder audit équipement dans ladite infrastructure informatique ; - obtention d'au moins une caractéristique dudit équipement à partir desdites données de configuration de ladite infrastructure informatique selon ledit chemin d'accès audit équipement ; - configuration dudit équipement selon ladite au moins une caractéristique.

Le procédé selon l'invention permet ainsi de faciliter le démarrage, la configuration et/ou le déploiement d'équipements dans une infrastructure informatique ayant une architecture de type Infiniband, typiquement de noeuds dans un cluster. A ces fins, le procédé selon l'invention combine des caractéristiques des architectures de type Infiniband permettant l'obtention d'informations de routes et la disponibilité de données de configuration d'infrastructures informatiques. Ladite au moins une caractéristique dudit équipement comprend, de préférence, une adresse logique dudit équipement dans ladite infrastructure informatique. Une telle caractéristique permet notamment l'exécution de commandes (ou scripts) visant, par exemple, l'installation d'une image à l'adresse logique identifiée. Avantageusement, ladite au moins une caractéristique dudit équipement comprend en outre une information de type, rôle, fonction et/ou état dudit équipement dans ladite infrastructure informatique permettant de choisir des commandes spécifiques à exécuter, déterminées en fonction du rôle, de la fonction et/ou de l'état dudit équipement. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'obtention d'une image à déployer, ladite étape de configuration comprenant une étape de déploiement de ladite image obtenue dans ledit équipement. Avantageusement, le procédé comprend en outre une étape d'identification d'une image à déployer, ladite identification utilisant ladite information de type, rôle, fonction et/ou état dudit équipement. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de mise à jour desdites données de configuration de ladite infrastructure informatique suite à la configuration dudit équipement. Le procédé selon l'invention permet ainsi de conserver une cohérence entre des données de configurations et la configuration de ladite infrastructure informatique. De façon avantageuse, le procédé comprend en outre une étape de test dudit équipement, ladite étape de test étant effectuée avant ladite étape de configuration dudit équipement. Ledit équipement n'est ainsi configuré que sous certaines conditions, par exemple s'il peut effectivement être utilisé dans ladite infrastructure informatique. Avantageusement, le procédé comprend en outre une étape de mise à jour desdites données de configuration de ladite infrastructure informatique suite au test dudit équipement afin de conserver une cohérence entre des données de configurations et la configuration de ladite infrastructure informatique. L'invention a aussi 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 dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif 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 illustre schématiquement un exemple d'infrastructure élémentaire dans laquelle des informations topologiques d'un noeud ajouté à cette infrastructure élémentaire peuvent être automatiquement obtenues par un noeud d'administration ; et, - la figure 4 illustre schématiquement certaines étapes mises en oeuvre conformément à l'invention pour configurer un équipement dans une infrastructure informatique suite au démarrage de ce dernier. De façon générale, l'invention vise à obtenir des informations topologiques d'un équipement tel qu'un noeud appartenant à une infrastructure informatique ayant une architecture de type Infiniband, typiquement un cluster, lors de son lancement, afin d'obtenir des caractéristiques de cet équipement.

De telles caractéristiques peuvent notamment être obtenues à partir d'une base de données décrivant l'infrastructure informatique. Ces caractéristiques sont alors utilisées pour configurer automatiquement l'équipement.

De telles informations topologiques sont typiquement la position ou l'emplacement d'un équipement au sein d'une infrastructure informatique. Il est tout d'abord rappelé ici qu'une particularité des architectures de type Infiniband est la possibilité d'indiquer, dans un message de gestion d'une infrastructure élémentaire (subnet), appelé SMP (sigle de Subnet Management Packet en terminologie anglo-saxonne), le numéro du port par lequel il est émis par chaque commutateur traversé lors de sa transmission. De telles indications permettent ainsi, dans une infrastructure informatique ayant une architecture de type Infiniband, de déterminer la position relative d'un équipement par rapport à un second, c'est-à-dire un chemin entre deux équipements. Dans le contexte Infiniband, les indications définissant un chemin entre un équipement donné et un équipement de référence portent le nom de Direct Route path. L'équipement de référence est typiquement un noeud d'administration, par exemple le noeud dans lequel est exécuté le gestionnaire principal du subnet concerné. Selon la topologie de l'infrastructure informatique, il peut y avoir plusieurs chemins de routes directes (Direct Route paths) entre un équipement donné et un équipement de référence.

En d'autres termes, un chemin de routes directes d'un équipement donné décrit les liens successifs qu'un paquet de donnée émis par l'équipement de référence doit utiliser pour atteindre cet équipement donné. Il s'exprime en une suite de références de port de sortie de commutateurs que le paquet doit utiliser pour atteindre sa destination.

Les chemins de routes directes entre un équipement de référence et d'autres équipements sont généralement établis lors de la découverte de l'infrastructure élémentaire par le gestionnaire principal de subnet correspondant. Une telle découverte utilise généralement des algorithmes classiques d'exploration d'arbres.

L'établissement des chemins de routes directes peut également être effectué suite à la réception d'un message de notification asynchrone (trap) afin, notamment, de déterminer le ou les chemins de routes directes d'un équipement nouvellement ajouté à l'infrastructure élémentaire. Comme indiqué précédemment, un message de notification asynchrone est généralement émis, dans une infrastructure informatique ayant une architecture de type Infiniband, par un commutateur auquel est directement relié un équipement lors du démarrage de ce dernier. A la réception d'un tel message, le gestionnaire principal de subnet peut alors effectuer une redécouverte de l'infrastructure élémentaire correspondante pour identifier les équipements et établir leurs chemins de routes directes.

Il est ainsi possible d'obtenir automatiquement des informations topologiques d'équipements ajoutés à une infrastructure élémentaire. Le gestionnaire principal de subnet est ici configuré pour alerter un agent spécifique, par exemple un agent de configuration d'équipement, du démarrage d'un équipement et lui transmettre le ou les chemins de routes 15 directes. A titre d'illustration, la figure 3 illustre schématiquement un exemple d'infrastructure élémentaire 300 dans laquelle des informations topologiques d'un noeud ajouté à cette infrastructure élémentaire peuvent être automatiquement obtenues par un noeud d'administration mettant en oeuvre un 20 gestionnaire principal de subnet (master subnet manager). Comme illustré, l'infrastructure élémentaire 300 comprend ici un noeud d'administration 305, un ensemble de noeuds référencés 310-1 à 310-15 ainsi que les commutateurs 315-1 à 315-6. Chaque commutateur a ici six ports bidirectionnels numérotés 1 à 6. 25 Les commutateurs 315-1 à 315-4 sont chacun connectés à quatre noeuds différents. Ainsi, par exemple, le commutateur 315-1 est connecté aux noeuds 305 et 310-1 à 310-3. Les commutateurs 315-1 à 315-4 sont en outre connectés aux commutateurs 315-5 et 315-6. Chaque noeud est donc ici connecté à chacun des autres noeuds via au plus trois commutateurs. 30 A titre d'illustration, le noeud 305 est connecté au noeud 310-14 via les commutateurs 315-1, 315-5 et 315-4. Plus précisément, le port de sortie du noeud 305 est connecté au port d'entrée 1 du commutateur 315-1 dont le port de sortie 5 est connecté au port d'entrée 1 du commutateur 315-5 dont le port de sortie 4 est lui-même connecté au port d'entrée 5 du commutateur 315-4 dont le port de sortie 3 est connecté au port d'entrée du noeud 310-14. De même, les liens étant ici bidirectionnels, le port de sortie du noeud 310-14 est connecté au port d'entrée 3 du commutateur 315-4 dont le port de sortie 5 est connecté au port d'entrée 4 du commutateur 315-5 dont le port de sortie 1 est lui-même connecté au port d'entrée 5 du commutateur 315-1 dont le port de sortie 1 est connecté au port d'entrée du noeud 305. Lorsque le gestionnaire principal de l'infrastructure élémentaire 300 explore cette dernière, il établit les chemins de routes directes entre le noeud d'administration 305 et chacun des autres noeuds et donc, en particulier, au moins un chemin de routes directes entre le noeud 305 et le noeud 310-14. Par convention, il est admis qu'un chemin de routes directes commence toujours par l'identifiant 0. En outre, pour des raisons de clarté, il est supposé ici que chaque noeud ne comprend qu'un port d'entrée et de sortie ayant la référence 1. Comme décrit précédemment, l'établissement d'un chemin de routes directes entre deux équipements et donc entre le noeud 305 et le noeud 310-14, est effectué selon les références des ports de sortie utilisés. Ainsi, un chemin de routes directes entre le noeud 305 et le noeud 310-14 commence par l'expression {0, 1} dans laquelle la référence 0 désigne le début d'un chemin de routes directes et la référence 1 désigne la référence du premier port de sortie (le port de sortie du noeud de référence, c'est-à-dire du noeud d'administration), comme représenté. Il est observé ici que les informations permettant d'établir les liens entre des ports de commutateurs et entre des ports de commutateurs et de noeuds sont généralement stockées dans des tables de routage et/ou dans une base de données de configuration de l'infrastructure informatique. Le chemin de routes directes considéré ici entre le noeud 305 et le noeud 310-14 (représenté en trait gras sur la figure 3) utilisant le port de sortie 5 du commutateur 315-1, la référence 5 est ajoutée à l'expression {0, 1} représentant le chemin de routes directes qui devient {0, 1, 5} comme illustré. De même, le chemin de routes directes considéré ici utilisant le port de sortie 4 du commutateur 315-5, la référence 4 est ajoutée à l'expression {0, 1, 5} qui devient {0, 1, 5, 4} comme illustré. De façon similaire encore, le chemin de routes directes considéré ici utilisant ensuite le port de sortie 3 du commutateur 315-4, la référence 3 est ajoutée à l'expression {0, 1, 5, 4} qui devient {0, 1, 5, 4, 3} comme illustré. Cette dernière expression représente ainsi un exemple de chemin de routes directes du noeud 310-14 par rapport au noeud de référence, ici le noeud d'administration 305. Il est supposé ici que le noeud 310-14 est démarré à un instant t. Suite à ce démarrage et comme décrit précédemment, un message de notification asynchrone est émis par le commutateur 315-4 (auquel est connecté le noeud 310-14). A la réception de ce message, le gestionnaire principal de l'infrastructure élémentaire 300 exécuté par le noeud 305 peut ré-explorer l'infrastructure élémentaire 300 et ainsi déterminer que le noeud dont un chemin de routes directes est {0, 1, 5, 4, 3} vient de démarrer.

Conformément à l'invention, cette information est transmise à un agent de configuration d'équipements afin de configurer le noeud visé. A ces fins, l'agent de configuration utilise des informations de configuration de l'infrastructure informatique pour identifier le noeud dont un chemin de routes directes a été établi. Typiquement, de telles informations de configuration sont regroupées dans une base de données définissant toutes les caractéristiques de l'infrastructure informatique et, en particulier, sa topologie ainsi que les caractéristiques de chaque noeud. Ces caractéristiques sont, par exemple, le type, le rôle et/ou la fonction de chaque noeud, par exemple s'il s'agit d'un noeud de calcul ou d'un noeud d'entrée/sortie, leur nom et leur état ainsi que leur adresse logique dans l'infrastructure informatique, par exemple leur adresse IP (sigle d'internet Protocol en terminologie anglo-saxonne). A partir de ces informations, l'agent de configuration peut lancer automatiquement, le cas échéant, des installations d'images et/ou des tests permettant la configuration des noeuds.

Il est observé ici que s'il existe plusieurs chemins de routes directes pour un noeud donné, le choix d'un chemin ou d'un autre est sans importance en ce qu'ils permettent d'identifier un même noeud, par sa position, dans l'infrastructure. La figure 4 illustre schématiquement certaines étapes mises en oeuvre conformément à l'invention pour configurer un équipement dans une infrastructure informatique suite au démarrage de ce dernier. A titre d'illustration, la figure 4 vise plus précisément la configuration d'un noeud dans un cluster. Après avoir démarré un noeud (étape 400), un message de notification asynchrone (trap) est typiquement émis (étape 405) par un commutateur auquel est connecté ce noeud. Ce message de notification asynchrone est reçu (étape 410) par le gestionnaire principal de l'infrastructure élémentaire correspondante qui peut alors ré-explorer cette dernière (étape 415) afin, notamment, d'établir des chemins de routes directes du noeud nouvellement démarré. Une notification est alors émise (étape 420) par le gestionnaire pour alerter un agent de configuration du démarrage d'un noeud. Une telle notification comprend un chemin de routes directes. Dans un souci de clarté, les étapes mises ici en oeuvre par l'agent de configuration sont référencées 425. Suite à la réception (étape 430) d'une notification émise par un gestionnaire principal d'une infrastructure élémentaire alertant l'agent de configuration du démarrage d'un noeud, l'agent de configuration interroge (étape 435) une base de données de configuration de l'infrastructure informatique, référencée ici 440, pour obtenir des caractéristiques du noeud dont un chemin de routes directes a été reçu avec la notification. Typiquement, ces caractéristiques visent le nom du noeud, son type, son rôle, sa fonction, son état et son adresse logique, par exemple son adresse IP, dans l'infrastructure informatique. Il est observé ici que si de telles données sont généralement stockées dans une base de données, elles peuvent également être disponibles sous d'autres formes. Selon un mode de réalisation particulier, cette requête peut comprendre un identifiant local du noeud, par exemple un identifiant connu sous le nom de GUID (acronyme de obtenu de Globally Unique IDentifier en terminologie anglo-saxonne), obtenu de façon standard par le gestionnaire principal de l'infrastructure élémentaire, afin de mettre à jour la base de données interrogée.

Un test est alors effectué pour déterminer si le noeud pour lequel une notification de démarrage a été reçue est un nouveau noeud (étape 445), c'est à dire un noeud vierge démarré pour la première fois dans ce contexte de l'infrastructure informatique. Un tel test peut notamment consister à comparer l'état de ce noeud avec un état prédéterminé, par exemple l'état « NEW ».

Dans l'affirmative, l'agent de configuration lance un outil de déploiement pour installer une image ayant pour objet de tester le noeud (étape 450). Une telle image est, de préférence, préinstallée dans le noeud. Après que l'image ait été installée, le test correspondant est lancé (étape 455). Un tel test consiste par exemple à remplir la mémoire de travail du noeud à un niveau très élevé de remplissage et à effectuer des calculs matriciels. Il peut également s'agir d'un test de son équipement réseau (par exemple une carte réseau) et/ou de sa mémoire de masse (par exemple un disque dur). Un test est alors effectué pour déterminer si les tests du noeud ont été passés avec succès (étape 460). Dans la négative, une erreur est signalée à l'administrateur, par exemple dans un fichier de type log. Si, au contraire, les tests du noeud ont été passés avec succès, la base de données de configuration de l'infrastructure informatique est, de préférence, mise à jour (étape 465) afin d'indiquer que le noeud a été testé avec succès. A ces fins, l'état du noeud dans la base de données peut être modifié, le nouvel état étant, par exemple, « TESTED ». Le noeud est ensuite redémarré et l'algorithme reboucle sur lui-même pour traiter un nouveau démarrage de noeud (comme représenté, l'algorithme retourne à l'étape 430). Si le noeud pour lequel une notification de démarrage a été reçue n'est pas un nouveau noeud (étape 445), un autre test est effectué pour déterminer si le noeud a été testé et si les tests ont été passés avec succès (étape 470), c'est-à-dire si c'est le premier démarrage du noeud après son installation au cours de laquelle il a été testé et qu'il doit être déployé. Un tel test peut notamment consister à comparer l'état du noeud avec l'état prédéterminé « TESTED Si le noeud a été testé et si les tests ont été passés avec succès, l'agent de configuration lance un outil standard de déploiement pour installer une image applicative (étape 475). A ces fins, lorsque plusieurs images sont susceptibles d'être déployées, l'image à déployer est avantageusement identifiée selon des caractéristiques du noeud préalablement obtenues (en fonction du chemin de routes directes), en particulier selon son type, son rôle et/ou sa fonction dans l'infrastructure informatique. La ou les images susceptibles d'être déployées sont ici mémorisées dans des moyens de stockage accessibles dans l'infrastructure informatique. Pour permettre le déploiement de l'image identifiée, l'adresse logique du noeud obtenue parmi les caractéristiques du noeud est ici utilisée. Le déploiement de l'image est alors effectué.

La base de données de configuration de l'infrastructure informatique est ensuite, de préférence, mise à jour (étape 480) afin d'indiquer que le noeud a été installé. A ces fins, l'état du noeud dans la base de données peut être modifié, le nouvel état étant, par exemple, « DEPLOYED ». L'algorithme reboucle ensuite sur lui-même pour traiter un nouveau démarrage de noeud (comme représenté, l'algorithme retourne à l'étape 430). De même, si le noeud pour lequel une notification de démarrage a été reçue n'est pas un nouveau noeud (étape 445) et si le noeud n'est pas dans un état selon lequel il s'agit de son premier démarrage après son installation (étape 470), cela signifie que le noeud a déjà été déployé et ne requiert pas de traitement particulier. L'algorithme reboucle alors sur lui-même pour traiter un nouveau démarrage de noeud (comme représenté, l'algorithme retourne à l'étape 430). Un exemple de dispositif adapté à mettre en oeuvre l'invention, notamment les étapes décrites en référence à la figure 4, plus particulièrement les étapes de l'agent de configuration (référencées 425), est un noeud de cluster par exemple le noeud décrit en référence à la figure 2.

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.

Claims (10)

1. REVENDICATIONS1. Procédé de configuration d'un équipement dans une infrastructure informatique ayant une architecture de type Infiniband, suite au démarrage dudit équipement, ladite infrastructure informatique comprenant une pluralité d'équipements dont au moins un équipement d'administration configuré pour accéder des données de configuration de ladite infrastructure informatique, ledit au moins un équipement d'administration pouvant être notifié du démarrage dudit équipement et pouvant explorer ladite infrastructure informatique pour établir au moins un chemin de routes directes pour accéder audit équipement, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (430) d'une notification de démarrage dudit équipement, ladite notification comprenant un chemin de routes directes pour accéder audit équipement dans ladite infrastructure informatique ; - obtention (435) d'au moins une caractéristique dudit équipement à partir desdites données de configuration de ladite infrastructure informatique selon ledit chemin d'accès audit équipement ; - configuration (475) dudit équipement selon ladite au moins une caractéristique.
2. 2. Procédé selon la revendication 1 selon lequel ladite au moins une caractéristique dudit équipement comprend une adresse logique dudit équipement dans ladite infrastructure informatique.
3. 3. Procédé selon la revendication 2 selon lequel ladite au moins une caractéristique dudit équipement comprend en outre une information de type, rôle, fonction et/ou état dudit équipement dans ladite infrastructure informatique.
4. 4. Procédé selon la revendication 2 ou la revendication 3 30 comprenant en outre une étape d'obtention (475) d'une image à déployer, ladite étape de configuration comprenant une étape de déploiement de ladite image obtenue dans ledit équipement.
5. 5. Procédé selon la revendication 4, dépendante de la revendication 3, comprenant en outre une étape d'identification d'une image à déployer, ladite identification utilisant ladite information de type, rôle, fonction et/ou état dudit équipement.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5 comprenant en outre une étape de mise à jour (480) desdites données de configuration de ladite infrastructure informatique suite à la configuration dudit équipement.
7. 7. Procédé selon l'une quelconque des revendications précédentes 10 comprenant en outre une étape de test dudit équipement, ladite étape de test étant effectuée avant ladite étape de configuration dudit équipement.
8. 8. Procédé selon la revendication 7 comprenant en outre une étape de mise à jour (465) desdites données de configuration de ladite infrastructure informatique suite au test dudit équipement. 15
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. Dispositif comprenant des moyens adaptés à la mise en oeuvre 20 de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.