WO2013088018A1 - Procédé et programme d'ordinateur de configuration d'équipements dans une infrastructure informatique ayant une architecture de type infiniband - Google Patents
Procédé et programme d'ordinateur de configuration d'équipements dans une infrastructure informatique ayant une architecture de type infiniband Download PDFInfo
- Publication number
- WO2013088018A1 WO2013088018A1 PCT/FR2012/052730 FR2012052730W WO2013088018A1 WO 2013088018 A1 WO2013088018 A1 WO 2013088018A1 FR 2012052730 W FR2012052730 W FR 2012052730W WO 2013088018 A1 WO2013088018 A1 WO 2013088018A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- equipment
- node
- infrastructure
- configuration
- computer
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
- H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
Definitions
- the present invention relates to the management of computer infrastructures such as clusters and data centers, and more particularly to a method and a computer program for configuring equipment in a computer infrastructure having a data architecture.
- Infiniband type Infiniband is a brand).
- Figure 1 schematically illustrates an example of a topology 100 of a cluster, type fat-tree.
- the latter includes a set of nodes
- the nodes belonging to the set 1 10 are here computation nodes while the nodes of the set 1 15 are service nodes (storage nodes and administration nodes).
- the calculation nodes can be grouped into subsets 120 called computing islands, the set 15 being called service island.
- a cluster can be decomposed into elementary infrastructures also called subnets in English terminology.
- Each subnet is managed by managers and agents including a master subnet manager such as the one known as OpenSM.
- the communication bus allows the communication and interoperability between the different elements included in the node 200 or connected to it.
- the microprocessors 204 control and direct the execution of the instructions or portions of software code or programs. When powering up, the program or programs that are stored in a non-volatile memory, for example a hard disk, are transferred into the RAM 206.
- the method of the invention thus facilitates the startup, configuration and / or deployment of equipment in a computer infrastructure having an Infiniband type architecture, typically nodes in a cluster.
- the method according to the invention combines characteristics of Infiniband type architectures for obtaining route information and the availability of configuration data of IT infrastructures.
- an asynchronous notification message is generally issued, in a computer infrastructure having an Infiniband type architecture, by a switch to which a device is directly connected when it is started.
- the main subnet manager can then rediscover the corresponding basic infrastructure to identify the equipment and establish their direct route paths.
- FIG. 3 schematically illustrates an example of elementary infrastructure 300 in which topological information of a node added to this elementary infrastructure can be automatically obtained by an administration node implementing a main subnet manager. (master subnet manager).
- Switches 315-1 through 315-4 are each connected to four different nodes.
- the switch 315-1 is connected to the nodes 305 and 310-1 to 310-3.
- Switches 315-1 through 315-4 are further connected to switches 315-5 and 315-6.
- Each node is here connected to each of the other nodes via at most three switches.
- a test is then performed to determine if the node for which a start notification has been received is a new node (step 445), that is to say a blank node started for the first time in this context of the IT infrastructure. .
- a test may notably consist in comparing the state of this node with a predetermined state, for example the "NEW" state.
- a test is then performed to determine if the tests of the node have been passed successfully (step 460). If not, an error is reported to the administrator, for example in a log file.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Hardware Redundancy (AREA)
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
Procédé et programme d'ordinateur de configuration d'équipements dans une infrastructure informatique avant une architecture de type Infiniband
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 œuvre sur des systèmes de traitement de données appelés clusters (parfois traduit « grappes de serveurs »). Un cluster comprend typiquement un ensemble de nœuds interconnectés. Certains nœuds sont utilisés pour effectuer des tâches de calcul (nœuds de calcul), d'autres pour stocker des données (nœuds de stockage) et un ou plusieurs autres gèrent le cluster (nœuds d'administration). Chaque nœud est par exemple un serveur mettant en œuvre un système d'exploitation tel que Linux (Linux est une marque). La connexion entre les nœuds 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 nœuds
génériquement référencés 105. Les nœuds appartenant à l'ensemble 1 10 sont ici des nœuds de calcul tandis que les nœuds de l'ensemble 1 15 sont des nœuds de service (nœuds de stockage et nœuds d'administration). Les nœuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 15 étant appelé îlot de service.
Les nœuds 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 nœuds 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 nœuds, 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 nœud 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 nœud comprend typiquement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le nœud 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 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 à recevoir des données.
Le nœud 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 l'interopérabilité entre les différents éléments inclus dans le nœud 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.
Lors de l'installation d'un cluster, chaque nœud est typiquement testé avant d'être configuré. A ces fins, chaque fois qu'un nouveau nœud est mis en route, une routine de test pré-chargée dans le nœud sous forme d'image est installée et exécutée puis, lorsque le nœud a été testé et qu'il est considéré comme stable, une image liée au rôle du nœud dans le cluster est obtenu, typiquement via le réseau de communication auquel est connecté le nœud, 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 nœud est opérationnel au sein du cluster. Cependant, si le déploiement peut être réalisé de façon automatique, il est mis en œuvre par un opérateur ou administrateur qui identifie les nœuds 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 œuvre, en particulier, pour installer les systèmes d'exploitation nécessaires et les applications logicielles, requièrent un temps de plus en plus long.
II 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 nœuds 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 œuvre 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 œuvre 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 nœud d'un cluster ;
- la figure 3 illustre schématiquement un exemple d'infrastructure élémentaire dans laquelle des informations topologiques d'un nœud ajouté à cette infrastructure élémentaire peuvent être automatiquement obtenues par un nœud d'administration ; et,
- la figure 4 illustre schématiquement certaines étapes mises en œuvre 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 nœud 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 (subnef), 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 nœud d'administration, par exemple le nœud 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.
II 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 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 nœud ajouté à cette infrastructure élémentaire peuvent être automatiquement obtenues par un nœud d'administration mettant en œuvre un gestionnaire principal de subnet (master subnet manager).
Comme illustré, l'infrastructure élémentaire 300 comprend ici un nœud d'administration 305, un ensemble de nœuds 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.
Les commutateurs 315-1 à 315-4 sont chacun connectés à quatre nœuds différents. Ainsi, par exemple, le commutateur 315-1 est connecté aux nœuds 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 nœud est donc ici connecté à chacun des autres nœuds via au plus trois commutateurs.
A titre d'illustration, le nœud 305 est connecté au nœud 310-14 via les commutateurs 315-1 , 315-5 et 315-4. Plus précisément, le port de sortie du nœud 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 nœud 310-14. De même, les liens étant ici bidirectionnels, le port de sortie du nœud 3 0-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 nœud 305.
Lorsque le gestionnaire principal de l'infrastructure élémentaire 300 explore cette dernière, il établit les chemins de routes directes entre le nœud d'administration 305 et chacun des autres nœuds et donc, en particulier, au moins un chemin de routes directes entre le nœud 305 et le nœud 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 nœud 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 nœud 305 et le nœud 310-14, est effectué selon les références des ports de sortie utilisés. Ainsi, un chemin de routes directes entre le nœud 305 et le nœud 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 nœud de référence, c'est-à-dire du nœud 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 nœuds 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 nœud 305 et le nœud 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 nœud 310-14 par rapport au nœud de référence, ici le nœud d'administration 305.
Il est supposé ici que le nœud 310-14 est démarré à un instant f. 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 nœud 310-14). A la réception de ce message, le gestionnaire principal de l'infrastructure élémentaire 300 exécuté par le nœud 305 peut réexplorer l'infrastructure élémentaire 300 et ainsi déterminer que le nœud 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 nœud visé. A ces fins, l'agent de configuration utilise des informations de configuration de l'infrastructure informatique pour identifier le nœud 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 nœud. Ces caractéristiques sont, par exemple, le type, le rôle et/ou la fonction de chaque nœud, par exemple s'il s'agit d'un nœud de calcul ou d'un nœud 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 nœuds.
II est observé ici que s'il existe plusieurs chemins de routes directes pour un nœud donné, le choix d'un chemin ou d'un autre est sans importance
en ce qu'ils permettent d'identifier un même nœud, par sa position, dans l'infrastructure.
La figure 4 illustre schématiquement certaines étapes mises en œuvre 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 nœud dans un cluster.
Après avoir démarré un nœud (étape 400), un message de notification asynchrone {trap) est typiquement émis (étape 405) par un commutateur auquel est connecté ce nœud. 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 nœud nouvellement démarré. Une notification est alors émise (étape 420) par le gestionnaire pour alerter un agent de configuration du démarrage d'un nœud. Une telle notification comprend un chemin de routes directes.
Dans un souci de clarté, les étapes mises ici en œuvre 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 nœud, 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 nœud dont un chemin de routes directes a été reçu avec la notification. Typiquement, ces caractéristiques visent le nom du nœud, 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 nœud, 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 n ud pour lequel une notification de démarrage a été reçue est un nouveau nœud (étape 445), c'est à dire un nœud 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 nœud 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 nœud (étape 450). Une telle image est, de préférence, préinstallée dans le nœud. 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 nœud à 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 nœud 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 nœud 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 nœud a été testé avec succès. A ces fins, l'état du nœud dans la base de données peut être modifié, le nouvel état étant, par exemple, « TESTED ». Le nœud est ensuite redémarré et l'algorithme reboucle sur lui-même pour traiter un nouveau démarrage de nœud (comme représenté, l'algorithme retourne à l'étape 430).
Si le nœud pour lequel une notification de démarrage a été reçue n'est pas un nouveau nœud (étape 445), un autre test est effectué pour déterminer si le nœud 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 nœud 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 n ud avec l'état prédéterminé « TESTED ».
Si le nœud 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 nœud 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 nœud obtenue parmi les caractéristiques du nœud 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 nœud a été installé. A ces fins, l'état du nœud 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 nœud (comme représenté, l'algorithme retourne à l'étape 430).
De même, si le nœud pour lequel une notification de démarrage a été reçue n'est pas un nouveau nœud (étape 445) et si le nœud 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 nœud 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 nœud (comme représenté, l'algorithme retourne à l'étape 430).
Un exemple de dispositif adapté à mettre en œuvre 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 nœud de cluster par exemple le nœud 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
1. 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. 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. 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. Procédé selon la revendication 2 ou la revendication 3 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. 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. 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. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de test dudit équipement, ladite étape de test étant effectuée avant ladite étape de configuration dudit équipement.
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.
9. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre 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. Dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1161582A FR2984052B1 (fr) | 2011-12-13 | 2011-12-13 | Procede et programme d'ordinateur de configuration d'equipements dans une infrastructure informatique ayant une architecture de type infiniband |
| FR1161582 | 2011-12-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2013088018A1 true WO2013088018A1 (fr) | 2013-06-20 |
Family
ID=47436077
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2012/052730 WO2013088018A1 (fr) | 2011-12-13 | 2012-11-27 | Procédé et programme d'ordinateur de configuration d'équipements dans une infrastructure informatique ayant une architecture de type infiniband |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2984052B1 (fr) |
| WO (1) | WO2013088018A1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090216853A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Subnet management discovery of point-to-point network topologies |
| US7721324B1 (en) * | 2004-03-18 | 2010-05-18 | Oracle America, Inc. | Securing management operations in a communication fabric |
-
2011
- 2011-12-13 FR FR1161582A patent/FR2984052B1/fr active Active
-
2012
- 2012-11-27 WO PCT/FR2012/052730 patent/WO2013088018A1/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7721324B1 (en) * | 2004-03-18 | 2010-05-18 | Oracle America, Inc. | Securing management operations in a communication fabric |
| US20090216853A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Subnet management discovery of point-to-point network topologies |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2984052B1 (fr) | 2014-01-03 |
| FR2984052A1 (fr) | 2013-06-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0599706B1 (fr) | Dispositif de traitement de l'information permettant la gestion d'une ressource informatique par un système d'administration | |
| FR2988943A1 (fr) | Systeme de supervision de la securite d'une architecture | |
| FR2957700A1 (fr) | Procede, programme d'ordinateur et dispositif d'optimisation de chargement et de demarrage d'un systeme d'exploitation dans un systeme informatique via un reseau de communication | |
| WO2010034920A1 (fr) | Determination et gestion de reseaux virtuels | |
| EP2553584A1 (fr) | Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs | |
| EP2190160A1 (fr) | Système et procédé pour le déploiement dynamique de traitements distribués | |
| FR2948247A1 (fr) | Procede et systeme pour la gestion performante et automatisee de reseaux virtuels. | |
| FR3013866A1 (fr) | Procede, programme d'ordinateur et dispositif de configuration ou de maintenance d'un systeme informatique dans un cluster | |
| EP2955875B1 (fr) | Serveur, client et système de gestion d'un réseau d'interconnexion | |
| EP2751959A1 (fr) | Procédé d'échange de données entre noeuds d'une grappe de serveurs et grappe de serveurs mettant en oeuvre ce procédé | |
| EP2577920B1 (fr) | Procédé de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé | |
| WO2013088018A1 (fr) | Procédé et programme d'ordinateur de configuration d'équipements dans une infrastructure informatique ayant une architecture de type infiniband | |
| EP3216175B1 (fr) | Procédé de surveillance et de contrôle déportés d'un cluster utilisant un réseau de communication de type infiniband et programme d'ordinateur mettant en oeuvre ce procédé | |
| EP2729874B1 (fr) | Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration | |
| WO2013088019A1 (fr) | Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité | |
| FR2976695A1 (fr) | Procede, dispositif et programme d'ordinateur pour la mise a jour logicielle de clusters optimisant la disponibilite de ces derniers | |
| US20200271774A1 (en) | Radar visualization of cloud native environments | |
| FR2981236A1 (fr) | Procede de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede | |
| EP2734921B1 (fr) | Procede, programme d'ordinateur et dispositif d'aide au deploiement de clusters | |
| FR3067832A1 (fr) | Fourniture de services inter-groupements | |
| EP2727057B1 (fr) | Procede et programme d'ordinateur pour identifier dynamiquement des composants d'un cluster et automatiser des operations de gestion optimisee du cluster | |
| FR3039024A1 (fr) | Systeme et procede automatique de deploiement des services sur un noeud reseau | |
| EP2077500A1 (fr) | Système informatique à haute disponibilité | |
| FR3040805A1 (fr) | Procede automatique de mise en place et maintenance de services de haute disponibilite dans un systeme d'exploitation en nuage | |
| FR3038179A1 (fr) | Systeme et procede automatique de configuratuin d'un repartiteur de charge par un service decouverte dans un systeme d'exploitation compose de ou ou plusieurs noeuds |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12806580 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 12806580 Country of ref document: EP Kind code of ref document: A1 |