WO2013007910A1 - Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration - Google Patents

Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration Download PDF

Info

Publication number
WO2013007910A1
WO2013007910A1 PCT/FR2012/051488 FR2012051488W WO2013007910A1 WO 2013007910 A1 WO2013007910 A1 WO 2013007910A1 FR 2012051488 W FR2012051488 W FR 2012051488W WO 2013007910 A1 WO2013007910 A1 WO 2013007910A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
services
processing station
cluster
nodes
Prior art date
Application number
PCT/FR2012/051488
Other languages
English (en)
Inventor
Virginie MEGY
Valérie FAVIER
Laurent GILOT
Original Assignee
Bull Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull Sas filed Critical Bull Sas
Priority to EP12738544.1A priority Critical patent/EP2729874B1/fr
Publication of WO2013007910A1 publication Critical patent/WO2013007910A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements

Definitions

  • the present invention relates to the administration of clusters and more particularly to a method and a dynamic service management computer program in an administration cluster for rendering these services highly available.
  • High Performance Computing also known as High Performance Computing (HPC)
  • HPC High Performance Computing
  • HPC High Performance Computing
  • modeling and simulation make it possible to reduce development costs and speed up the launch of innovative, more reliable and less energy-consuming products.
  • high performance computing has become an indispensable means of investigation.
  • a cluster typically includes a set of interconnected nodes. Some nodes are used to perform compute tasks (compute nodes), others to store data (storage nodes), and one or more others manage the cluster (administration nodes). Each node is for example a server implementing an operating system such as Linux (Linux is a brand). The connection between the nodes is, for example, carried out using Ethernet communication links and interconnection networks (for example Infiniband) (Ethernet and Infiniband are trademarks).
  • Ethernet communication links and interconnection networks for example Infiniband
  • Figure 1 schematically illustrates an example of a topology 100 of a cluster, type fat-tree.
  • the latter comprises a set of generically referenced nodes 105.
  • the nodes belonging to the set 1 10 are here calculation nodes while the nodes of the set 1 15 are service nodes (storage nodes and administration nodes ).
  • the calculation units may be grouped into subsets 120 called calculation islands, the set 1 being called the service island.
  • the nodes are connected to each other by switches (called switches in English terminology), for example hierarchically.
  • switches in English terminology
  • the nodes are connected to first level switches 125 which are themselves connected to second level switches 130 which are in turn connected to third level switches 135.
  • each node generally comprises one or more microprocessors, local memories as well as a communication interface. More specifically, the node 200 here comprises a communication bus 202 to which are connected:
  • CPU Central Processing Unit
  • RAM Random Access Memory
  • Random Access Memory in English terminology having registers adapted to record variables and parameters created and modified during the execution of programs (as illustrated, each memory component can be associated with a microprocessor); and,
  • communication interfaces 208 adapted to transmit and receive data.
  • the node 200 also has internal storage means 210, such as hard disks, which can notably comprise the executable code of programs.
  • 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 number of components implemented in a cluster varies by cluster to another, with a tendency to set up clusters with more and more equipment. This results in numerous scalability problems in the administration of these clusters. Indeed, the number of devices grows faster than the processing capacity of the administration tools due, in particular, to the internal design of the software used (processing latency), hardware limitations (input / output flow of more and more important) and limitations of the operating system settings used.
  • an administrative cluster is typically implemented. It distributes administrative tasks across a set of service nodes.
  • cluster management systems for example the xCAT open source system, composed of a central administration node which distributes the set of administration tasks statically over service nodes.
  • Each service node is here responsible for a subset of the cluster that it manages in full.
  • the invention solves at least one of the problems discussed above.
  • the subject of the invention is thus a method of dynamic management of services in a cluster of administration of a cluster, said administration cluster comprising at least one central administration node and a plurality of processing stations adapted to the implementation. implementing services for a plurality of computing nodes, said at least one central administration node distributing a service execution in processing stations of said plurality of processing stations, at least one service being implemented via at least one virtual machine executed by a processing station, the method comprising the following steps,
  • the method according to the invention thus makes it possible to improve the availability of services by offering a continuity of execution mechanism when an anomaly is detected in a service execution system.
  • the method according to the invention also makes it possible to facilitate maintenance and / or update operations by authorizing the release of management and monitoring resources when using clusters.
  • the method further comprises a preliminary step of generating configuration data of said at least one virtual machine in a configuration step of said cluster, said generation step being implemented at least partially by said at least one virtual machine. least one central administration node.
  • the method according to the invention is thus adaptive and simple to implement.
  • said restarting step comprises a step of starting a generic virtual machine and a step of configuring said generic virtual machine according to said configuration data of said at least one virtual machine.
  • the method advantageously comprises a step of obtaining said configuration data of said at least one virtual machine, said configuration data of said at least one virtual machine being obtained from a identifier of said stopped virtual machine.
  • Said identifier of said stopped virtual machine can, for example, be obtained from a second identifier of said stopped virtual machine, distinct from said first identifier.
  • Said step of obtaining said configuration data of said at least one virtual machine comprises for example a step of synchronizing data between a file server and said at least one virtual machine.
  • the method further comprises a step of identifying said second processing station.
  • the method further comprises a step of distributing the execution of services in processing stations, as a function of the services to be distributed and the computing nodes targeted by the services to be distributed, said step of distribution being implemented in said at least one central administration node.
  • Said at least one execution parameter may be a parameter directly related to the operation of said at least one virtual machine or to said first processing station.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer.
  • the benefits provided by this computer program are similar to those mentioned above.
  • FIG. 1 illustrates an exemplary topology of a cluster
  • FIG. 2 illustrates an exemplary architecture of a node of a cluster
  • FIG. 3 schematically illustrates an exemplary cluster implementing the invention
  • FIG. 4 schematically illustrates an exemplary algorithm for dynamically distributing services in an administration cluster
  • FIG. 5 schematically illustrates steps for starting a virtual machine in a processing station for the implementation of services for a group of equipment
  • FIG. 6 represents a simplified sequence diagram of the startup of a virtual machine following the stopping of this virtual machine in another processing station.
  • FIG. 7, comprising FIGS. 7a and 7b, illustrates an example of reallocation of virtual machines in a management cluster following the detection of an anomaly in a processing station.
  • the invention aims to dynamically restart services in service nodes in order to make them highly available in an administration cluster based on a hierarchical architecture and based on mixed distribution, based on a breakdown by services and by groups. equipment.
  • the purpose of the services is, for example, to access a console of computation nodes, for example to obtain a memory content (called dump in English terminology) in the event of a system error and / or to monitor nodes of calculation in order to control, in particular, parameters such as temperature, a number of CPUs (acronym for Central Processing Unit in English terminology), a computer cabinet cooling gate state and a state of switches.
  • the administration cluster comprises two administration nodes, a set of processing stations whose number is advantageously dependent on the size of the cluster and a file system shared between the administration nodes and the nodes.
  • treatment stations are here service nodes dedicated to the execution of services.
  • the administration nodes are in charge of distributing the administration services between all the processing stations. Each processing station performs one or more services on all or part of the compute cluster.
  • the shared file system makes it possible to make available to any node of the management cluster the data written by one of the processing stations and thus to be able to distribute the collection of information and their processing on different nodes.
  • a breakdown of services into sub-services is performed according to the heuristics specific to each service and according to the cluster topology.
  • Each virtual machine houses one or more services and each service instance implemented in a virtual machine manages a single group of devices. The configuration of a service is done according to the corresponding group.
  • All virtual machines are generated here from one and the same generic image. Their characterization and configuration are made possible when starting the virtual machine using configuration data. As described below, starting, monitoring, and stopping these virtual machines are performed through a high availability tool implemented in the administration cluster.
  • FIG. 3 schematically illustrates an exemplary cluster 300 embodying the invention.
  • the service nodes of the cluster 300 here comprise two administration nodes 305-1 and 305-2 marked MNGT allowing centralized administration. They also include treatment stations rated MWS (abbreviation Management WorkStation in English terminology), the number of n (the value of n being advantageously determined according to the size of the cluster), referenced 310-1 to 310-n, and a file server 315, here of NFS type (Network File System acronym in English terminology), and generically referenced calculation nodes 320.
  • MWS abbreviation Management WorkStation in English terminology
  • n the value of n being advantageously determined according to the size of the cluster
  • a file server 315 here of NFS type (Network File System acronym in English terminology)
  • calculation nodes 320 here comprise two administration nodes 305-1 and 305-2 marked MNGT allowing centralized administration. They also include treatment stations rated MWS (abbreviation Management WorkStation in English terminology), the number of n (the value of n being advantageously determined according to the size of the cluster), referenced
  • Each processing station here comprises a module of a high availability infrastructure, commonly called HA framework (abbreviation of High Availability in English terminology).
  • the processing station 310-1 comprises the module 325-1 of a high availability infrastructure.
  • the set of modules of the high availability infrastructure forms the latter, referenced 330.
  • Such an infrastructure is, for example, one of the tools known under the names of Cluster Suite and Pacemaker.
  • these modules are implemented in a master / slave mode, the roles can be changed dynamically, especially when an error is detected.
  • Each processing station further comprises one or more virtual machines encapsulating one or more services.
  • the processing station 310-1 here comprises the virtual machines 335-1 1 and 335-12.
  • each processing station comprises a virtualization tool such as KVM (acronym for Kernel-based Virtual Machine). in Anglo-Saxon terminology) which is a virtualization tool for the Linux operating system (Linux is a brand).
  • Each virtual machine implements one or more services associated here with a set of compute nodes.
  • the virtual machines 335-1 1 and 335-12 of the processing station 310-1 are associated with a group of nodes 340-1.
  • the virtual machines of the processing stations 310-2 and 310-n are associated with the node groups 340-2 and 340-n, respectively.
  • the processing stations 310-1 to 310-n are controlled by the administration nodes 305-1 and 305-2.
  • the administration nodes 305-1 and 305-2 as well as the processing stations 310-1 to 310-n can access data, typically files, read and write, in the file server 315.
  • the virtual machine (s) are transferred to another processing station (target processing station).
  • target processing station For these purposes, the virtual machine (s) concerned are stopped and restarted on the target processing station according to a generic image of a virtual machine and one or more configuration files specific to the stopped virtual machine (s).
  • These configuration files are advantageously constituted during the configuration of the cluster.
  • startup, monitoring, and shutdown of virtual machines are performed by the HA 330 framework.
  • Figure 4 schematically illustrates an example algorithm for dynamically distributing services in an administration cluster.
  • a first phase referenced 400 here has for object the determination of configuration files for each virtual machine to be implemented in a processing station.
  • the actions performed during this phase are here by a central administration node, advantageously during the configuration of the cluster, from configuration data thereof.
  • a first step (step 405) of this phase is to determine the number of groups of equipment to be administered. Such a number can be calculated or determined, in particular according to the number of computation nodes, or entered by a user.
  • a next step (step 40) is to identify the services to be implemented for each equipment group. This information typically belongs to cluster configuration data, which is typically available in a database accessible from the management nodes.
  • a next step it is determined whether, for each equipment group, each service to be implemented must be implemented independently of the other services to be implemented for the equipment group considered so determine the number of VMs (rated VMs) to be used for each group equipment and identify the services associated with each of these virtual machines.
  • each virtual machine to be implemented is identified according to the groups of equipment and the services to be implemented for each group.
  • the configuration files of each virtual machine are then generated (step 420) to enable the implementation of the identified virtual machines and, consequently, associated services.
  • the configuration files are here stored in a file server, for example an NFS file server accessible by the processing stations.
  • the configuration files are stored in directories whose names correspond to those of the virtual machines.
  • the configuration files include in particular identifiers and parameters of the services to be executed as well as identifiers of equipment (or a group of equipment).
  • the previously defined virtual machines are launched (step 430).
  • a generic image of virtual machine is used, the virtual machine being specialized according to a group of equipment and one or more services using a configuration file previously created, for example in accordance with step 420 .
  • the virtual machines are here launched on the processing stations defined in the configuration data of the cluster, according to a predetermined allocation mechanism.
  • the processing stations are not. Thus, there may be, on the same processing station, several virtual machines that address different groups of equipment.
  • a failure is detected in a virtual machine or a processing station, a reassignment of the corresponding virtual machine (s) is performed.
  • the virtual machines and / or processing stations (labeled ST) used are then monitored (step 435) and a test is performed (step 440) to determine if a problem has been identified in a virtual machine MVi or a processing station STp . If not, the monitoring step continues.
  • one or more processing stations STq can implement the virtual machine MVi in which a problem has been detected or one or more virtual machines MVj implemented in the processing station STp in which a problem has been detected are identified (step 445).
  • the identification of such treatment stations can be made, for example, according to the capacities and the load levels of the treatment stations.
  • the virtual machine MVi in which a problem has been detected or the MVj machines implemented in the processing station STp in which a problem has been detected are then stopped as well as, if necessary, the processing station STp (step 450) .
  • the processing station STp when an anomaly is detected in a virtual machine, only the latter is stopped and restarted in another processing station without the other virtual machines of the initial processing station being stopped and restarted in a other treatment station (the initial treatment station is therefore not stopped).
  • step 455 The virtual machine MVi in which a problem has been detected or the MVj machines implemented in the processing station STp in which a problem has been detected are then started in the processing stations STq previously identified (step 455). Again, step 455 of starting virtual machines is described in more detail with reference to FIG.
  • steps 435 to 455) are repeated until the process is terminated.
  • FIG. 5 schematically illustrates steps for starting a virtual machine in a processing station enabling the implementation provision of services for a group of equipment. These steps are here implemented and / or controlled by the HA framework.
  • a first step (step 500) consists in initializing the startup of the virtual machine MVi to start. This step includes obtaining a generic image of virtual machine (imag_gen_MV). It is here performed in a standard way. The resulting virtual machine is then started (step 505).
  • imag_gen_MV a generic image of virtual machine
  • a test is performed to determine if the name of the virtual machine MVi to start is known (step 510). If the startup of the virtual machine is initiated by the administration node, the name of the virtual machine is known. It is not necessary to obtain it.
  • the startup of the virtual machine is initiated by the HA framework, in particular following the detection of a problem in a virtual machine or a processing station, the name of the virtual machine is not known and it is needed here to get it. It can be based on information such as a MAC address (acronym for Media Access Control in English terminology), denoted MAC @. Indeed, when a problem is detected in a virtual machine or a processing station, the high availability infrastructure is generally able to obtain the address or the MAC addresses of the virtual machine (s) concerned.
  • the MAC address of the virtual machine MVi to be started (or equivalent information) is then addressed to the MNGT administration nodes (step 515), for example in the form of a request dhcp (acronym of Dynamic Host Configuration Protocol in English terminology -saxonne) to obtain, in response, the name of the virtual machine MVi to start and, preferably, its IP address (abbreviation of Internet Protocol in English terminology). It is observed here that only the administration node that knows the virtual machine corresponding to the transmitted MAC address responds.
  • dhcp acronym of Dynamic Host Configuration Protocol in English terminology -saxonne
  • the name of the MVi virtual machine being started, known or obtained, is then used to obtain the configuration data specific to this virtual machine ⁇ conf_file), in particular data relating to the group of equipment administered by this virtual machine and the or the services concerned (step 520). For these purposes, access to a file server, for example an NFS file server, can be created.
  • the configuration data is then obtained, for example, by synchronizing one or more directories (typically a directory having the name of the virtual machine to start).
  • the MVi virtual machine being started is then configured, in a standard way, according to the configuration data obtained (step 525).
  • the virtual machine MVi makes a dhcp request, at boot time, to obtain its name and its IP address and then makes an NFS assembly to recover, by a synchronization mechanism, its configuration that is in a predetermined directory called MVi.
  • FIG. 6 represents a simplified sequence diagram of the startup of a virtual machine MVi following the stopping of this virtual machine in another processing station.
  • this identifier is transmitted to MNGT management nodes (step 600).
  • the MNGT administration nodes use this identifier to try to find the name and, preferably, the address of the virtual machine concerned, typically the IP address. This data is stored during cluster configuration.
  • the name and address of the virtual machine are then transmitted to it (step 605) by the administration node which knows the virtual machine corresponding to the transmitted MAC address.
  • Access to an NFS file server is then initiated (NFS mount) to obtain, preferably by a synchronization mechanism, the configuration of the virtual machine (steps 610 and 615).
  • This data is obtained by synchronizing the files of a directory with the name of the virtual machine, or a name associated with it, with a virgin and predetermined local location of the virtual machine.
  • the configuration data of a virtual machine includes data for the high availability infrastructure (HA framework) to enable the latter to supervise the virtual machine.
  • HA framework high availability infrastructure
  • a failover service (called failover in English terminology) is advantageously created in the HA framework for each virtual machine. In particular, it allows each virtual machine to be started and stopped, as well as to monitor it. For these purposes, three scripts can be used (a first one being used to identify the services to start when the virtual machine starts up, a second one being used to identify the services to be stopped when the virtual machine is shut down and the third one to being used to identify services to start when starting the virtual machine, for example services linked to services identified via the first script).
  • FIG. 7, comprising FIGS. 7a and 7b, illustrates an example of reassigning virtual machines (and therefore services) in an administration cluster, for example following the detection of an anomaly in a processing station implementing these virtual machines.
  • FIG. 7a represents the state of three processing stations, denoted ST1, ST2 and ST3, of an administration cluster (not represented) at a given instant.
  • the processing station ST1 here comprises a virtual machine MV1 implementing a monitoring service (or monitoring in English terminology) of the calculation nodes 1 to 599 and a virtual machine MV2 implementing a node console service. , called conman (acronym for console manager in English terminology), targeting the same calculation nodes 1 to 599.
  • the processing station ST2 comprises a virtual machine MV3 implementing a monitoring service of the computing nodes 600 to 1199 and a virtual machine MV4 implementing a node console service targeting these same nodes. calculation.
  • the processing station ST3 comprises an MV5 virtual machine implementing a monitoring service of the computing nodes 1 199 to 1800 as well as a virtual machine MV6 implementing a node console service targeting these same calculation nodes. .
  • an anomaly is detected in the processing station ST2.
  • the virtual machines MV3 and MV4 are then stopped and the processing stations ST1 and ST3 are identified to implement the virtual machines MV3 and MV4, respectively.
  • FIG. 7b represents the state of the three treatment stations ST1,
  • the virtual machines MV3 and MV4 were stopped from the processing station ST2 and restarted on the processing stations ST1 and ST3, respectively, according to a mechanism such as that described with reference to FIGS. 4 and 5.
  • the processing station ST2 is no longer used, it can be repaired or stopped and, if necessary, replaced.
  • a mechanism such as the mechanism known as DNS view is used to allow compute nodes to address data to a particular virtual machine.
  • a DNS server includes a look-up table for associating request transmitter addresses (here computing nodes) with destination addresses (here virtual machines) based on cluster configuration data.
  • a DNS server may be configured to indicate that if a request comes from a compute node having a given IP address, this request must be addressed to a virtual machine having another given IP address.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention a notamment pour objet la gestion dynamique de services dans un cluster d'administration comprenant au moins un nœud d'administration central et des stations de traitement adaptées à la mise en œuvre de services visant plusieurs nœuds de calcul, le nœud d'administration central répartissant une exécution de services dans des stations de traitement. Au moins un service est mis en œuvre via au moins une machine virtuelle exécutée par une station de traitement. Si une anomalie est détectée lors de la surveillance (435) d'un paramètre d'exécution de la machine virtuelle exécutée par une première station de traitement, la machine virtuelle est arrêtée (450) et redémarrée (455) dans une seconde station de traitement, le redémarrage de la machine virtuelle étant au moins partiellement basé sur des données de configuration de la machine virtuelle.

Description

Procédé et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration
La présente invention concerne l'administration de clusters et plus particulièrement un procédé et un programme d'ordinateur de gestion dynamique de services dans un cluster d'administration permettant de rendre ces services hautement disponibles.
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. 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 1 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.
Comme illustré sur la figure 2, chaque nœud comprend généralement 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.
Le nombre de composants mis en œuvre dans un cluster, notamment d'équipements tels que des nœuds et des commutateurs, varie d'un cluster à un autre, avec une tendance à la mise en place de clusters comprenant de plus en plus d'équipements. Il en résulte de nombreux problèmes de scalabilité dans l'administration de ces clusters. En effet, le nombre d'équipements croît plus vite que la capacité de traitement des outils d'administration en raison, notamment, de la conception interne des logiciels utilisés (latence de traitement), des limitations matérielles (flux d'entrée/sortie de plus en plus important) et des limitations des paramètres des systèmes d'exploitation utilisés.
Pour répondre à ces problèmes, un cluster d'administration est généralement mis en œuvre. Il permet de répartir les tâches d'administration sur un ensemble de nœuds de service.
Plusieurs architectures de clusters d'administration, basées sur une répartition par services, par groupes d'équipements ou par services et groupes d'équipements, ont été proposées pour répondre au problème de scalabilité.
A titre d'illustration, il existe des systèmes d'administration de clusters, par exemple le système open source xCAT, composés d'un nœud d'administration central qui réparti l'ensemble des tâches d'administration, de façon statique, sur des nœuds de service. Chaque nœud de service est ici responsable d'un sous ensemble du cluster qu'il gère en intégralité.
Cependant, si de telles solutions permettent de répondre, au moins partiellement, aux problèmes de scalabilité évoqués, elles n'offrent pas de caractéristiques de haute disponibilité appelées High-Availability (ou HA) en terminologie anglo-saxonne.
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é de gestion dynamique de services dans un cluster d'administration d'un cluster, ledit cluster d'administration comprenant au moins un nœud d'administration central et une pluralité de stations de traitement adaptées à la mise en œuvre de services visant une pluralité de nœuds de calcul, ledit au moins un nœud d'administration central répartissant une exécution de services dans des stations de traitement de ladite pluralité de stations de traitement, au moins un service étant mis en œuvre via au moins une machine virtuelle exécutée par une station de traitement, le procédé comprenant les étapes suivantes,
- surveillance d'au moins un paramètre d'exécution de ladite au moins une machine virtuelle ; et,
- si une anomalie est détectée en réponse à ladite étape de surveillance, arrêt de ladite au moins une machine virtuelle exécutée par ladite station de traitement, appelée première station de traitement, et redémarrage de ladite machine virtuelle dans une seconde station de traitement, distincte de ladite première station de traitement, le redémarrage de ladite au moins une machine virtuelle étant au moins partiellement basé sur des données de configuration de ladite au moins une machine virtuelle.
Le procédé selon l'invention permet ainsi d'améliorer la disponibilité de services en offrant un mécanisme de continuité d'exécution lorsqu'une anomalie est détectée dans un système d'exécution de services. Le procédé selon l'invention permet en outre de faciliter les opérations de maintenance et/ou de mise en jour en autorisant la libération de ressources de gestion et de surveillance lors de l'utilisation de clusters.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape préalable de génération de données de configuration de ladite au moins une machine virtuelle dans une étape de configuration dudit cluster, ladite étape de génération étant mise en œuvre au moins partiellement par ledit au moins un nœud d'administration central. Le procédé selon l'invention est ainsi adaptatif et simple à mettre en œuvre.
Toujours selon un mode de réalisation particulier, ladite étape de redémarrage comprend une étape de démarrage d'une machine virtuelle générique et une étape de configuration de ladite machine virtuelle générique selon lesdites données de configuration de ladite au moins une machine virtuelle. En outre, toujours selon un mode de réalisation particulier, le procédé comprend avantageusement une étape d'obtention desdites données de configuration de ladite au moins une machine virtuelle, lesdites données de configuration de ladite au moins une machine virtuelle étant obtenues à partir d'un identifiant de ladite machine virtuelle arrêtée. Le procédé selon l'invention est ainsi simple à mettre en œuvre lorsque des systèmes d'exploitation tel que Linux et qu'une infrastructure haute disponibilité telle que Cluster Suite ou Pacemaker sont utilisés.
Ledit identifiant de ladite machine virtuelle arrêtée, appelé premier identifiant, peut, par exemple, être obtenu à partir d'un second identifiant de ladite machine virtuelle arrêtée, distinct dudit premier identifiant.
Ladite étape d'obtention desdites données de configuration de ladite au moins une machine virtuelle comprend par exemple une étape de synchronisation de données entre un serveur de fichiers et ladite au moins une machine virtuelle.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'identification de ladite seconde station de traitement.
Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de répartition de l'exécution de services dans des stations de traitement, en fonction des services à répartir et des nœuds de calcul visés par les services à répartir, ladite étape de répartition étant mise en œuvre dans ledit au moins un nœud d'administration central. Le procédé selon l'invention permet ainsi d'optimiser l'usage des stations de traitement selon les services à exécuter.
Ledit au moins un paramètre d'exécution peut être un paramètre directement lié au fonctionnement de ladite au moins une machine virtuelle ou à ladite première station de traitement.
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. Les avantages procurés par ce programme d'ordinateur 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 de cluster mettant en œuvre l'invention ;
- la figure 4 illustre schématiquement un exemple d'algorithme pour répartir dynamiquement des services dans un cluster d'administration ;
- la figure 5 illustre schématiquement des étapes pour le démarrage d'une machine virtuelle dans une station de traitement permettant la mise en œuvre de services visant un groupe d'équipements ;
- la figure 6 représente un diagramme de séquence simplifié du démarrage d'une machine virtuelle suite à l'arrêt de cette machine virtuelle dans une autre station de traitement ; et,
- la figure 7, comprenant les figures 7a et 7b, illustre un exemple de réaffectation de machines virtuelles dans un cluster d'administration suite à la détection d'une anomalie dans une station de traitement.
De façon générale, l'invention vise à repartir dynamiquement des services dans des nœuds de service afin de les rendre hautement disponibles dans un cluster d'administration basé sur une architecture hiérarchique et reposant sur répartition mixte, basée sur une répartition par services et par groupes d'équipements. Les services ont pour objet, par exemple, d'accéder à une console de nœuds de calcul, par exemple pour obtenir un contenu mémoire (appelé dump en terminologie anglo-saxonne) en cas d'erreur système et/ou de surveiller des nœuds de calcul afin de contrôler, en particulier, des paramètres tels que la température, un nombre de CPU (sigle de Central Processing Unit en terminologie anglo-saxonne), un état de porte de refroidissement d'armoire informatique et un état de commutateurs.
Selon un mode de réalisation particulier, le cluster d'administration comprend deux nœuds d'administration, un ensemble de stations de traitement dont le nombre est avantageusement dépendant de la taille du cluster et un système de fichiers partagé entre les nœuds d'administration et les stations de traitement. Les stations de traitement sont ici des nœuds de service dédiés à l'exécution de services. Les nœuds d'administration sont en charge de distribuer les services d'administration entre toutes les stations de traitement. Chaque station de traitement exécute un ou plusieurs services sur tout ou partie du cluster de calcul.
Le système de fichiers partagé permet de rendre disponible à n'importe quel nœud du cluster d'administration les données écrites par l'une des stations de traitement et, ainsi, de pouvoir répartir la collecte des informations et leur traitement sur des nœuds différents.
Une décomposition des services en sous services est effectuée en fonction des heuristiques propre à chaque service et en fonction de la topologie de cluster.
Ces sous services sont ensuite répartis dans des machines virtuelles hébergées par les stations de traitement. Il est observé que ces sous services étant similaires aux services dont ils dérivent, ils sont considérés, dans la suite de la description, dans un souci de clarté, comme ces services.
Chaque machine virtuelle abrite un ou plusieurs services et chaque instance de service mise en œuvre dans une machine virtuelle gère un unique groupe d'équipements. La configuration d'un service se fait en fonction du groupe correspondant.
Toutes les machines virtuelles sont ici générées à partir d'une même et unique image générique. Leur caractérisation et leur configuration sont rendues possible au démarrage de la machine virtuelle à l'aide de données de configuration. Comme décrit ci-dessous, le démarrage, la surveillance et l'arrêt de ces machines virtuelles sont réalisés via un outil de haute disponibilité mis en œuvre dans le cluster d'administration.
La figure 3 illustre schématiquement un exemple de cluster 300 mettant en œuvre l'invention.
Les nœuds de service du cluster 300 comprennent ici deux nœuds d'administration 305-1 et 305-2 notés MNGT permettant une administration centralisée. Ils comprennent également des stations de traitement notées MWS (sigle de Management WorkStation en terminologie anglo-saxonne), au nombre de n (la valeur de n étant avantageusement déterminée selon la taille du cluster), référencées 310-1 à 310-n, ainsi qu'un serveur de fichiers 315, ici de type NFS (sigle de Network File System en terminologie anglo-saxonne), et des nœuds de calcul génériquement référencés 320.
Chaque station de traitement comprend ici un module d'une infrastructure haute disponibilité, couramment appelée framework HA (sigle de High Availability en terminologie anglo-saxonne). Ainsi, par exemple, la station de traitement 310-1 comprend le module 325-1 d'une infrastructure haute disponibilité. L'ensemble des modules de l'infrastructure haute disponibilité forme cette dernière, référencée 330. Une telle infrastructure est, par exemple, l'un des outils connus sous les noms de Cluster Suite et Pacemaker. Typiquement, ces modules sont mis en oeuvre selon un mode maître/esclave, les rôles pouvant être changés dynamiquement, notamment lorsqu'une erreur est détectée.
Chaque station de traitement comprend en outre une ou plusieurs machines virtuelles encapsulant un ou plusieurs services. Ainsi, par exemple, la station de traitement 310-1 comprend ici les machines virtuelles 335-1 1 et 335- 12. A ces fins, chaque station de traitement comprend un outil de virtualisation tel que KVM (sigle de Kernel-based Virtual Machine en terminologie anglo- saxonne) qui est un outil de virtualisation pour le système d'exploitation Linux (Linux est une marque).
Chaque machine virtuelle met en œuvre un ou plusieurs services associés ici à un ensemble de nœuds de calcul. Selon l'exemple illustré sur la figure 3, les machines virtuelles 335-1 1 et 335-12 de la station de traitement 310-1 sont associées à un groupe de nœuds 340-1. De façon similaire, les machines virtuelles des stations de traitement 310-2 et 310-n sont associées aux groupes de nœuds 340-2 et 340-n, respectivement.
Comme illustré, les stations de traitement 310-1 à 310-n sont contrôlées par les nœuds d'administration 305-1 et 305-2. Les nœuds d'administration 305-1 et 305-2 ainsi que les stations de traitement 310-1 à 310- n peuvent accéder à des données, typiquement des fichiers, en lecture et en écriture, dans le serveur de fichiers 315. Lorsqu'une anomalie est détectée dans une machine virtuelle d'une station de traitement ou dans une station de traitement, la ou les machines virtuelles sont transférées sur une autre station de traitement (station de traitement cible). A ces fins, la ou les machines virtuelles concernées sont arrêtées et redémarrées sur la station de traitement cible selon une image générique de machine virtuelle et un ou plusieurs fichiers de configuration spécifiques à la ou aux machines virtuelles arrêtées. Ces fichiers de configuration sont avantageusement constitués lors de la configuration du cluster.
Comme décrit précédemment, le démarrage, la surveillance et l'arrêt des machines virtuelles sont réalisés par le framework HA 330.
La figure 4 illustre schématiquement un exemple d'algorithme pour répartir dynamiquement des services dans un cluster d'administration.
Une première phase référencée 400 a ici pour objet la détermination de fichiers de configuration pour chaque machine virtuelle devant être mise en œuvre dans une station de traitement. Les actions effectuées lors de cette phase le sont ici par un nœud d'administration central, avantageusement lors de la configuration du cluster, à partir de données de configuration de celui-ci.
Une première étape (étape 405) de cette phase consiste à déterminer le nombre de groupes d'équipements devant être administrés. Un tel nombre peut être calculé ou déterminé, en particulier en fonction du nombre de nœuds de calcul, ou entré par un utilisateur.
Une étape suivante (étape 4 0) vise à identifier les services devant être mis en œuvre pour chaque groupe d'équipements. Ces informations appartiennent typiquement aux données de configuration du cluster, généralement disponibles dans une base de données accessible des nœuds d'administration.
Dans une étape suivante (étape 415), il est déterminé si, pour chaque groupe d'équipements, chaque service devant être mis en œuvre doit être mis en œuvre indépendamment des autres services devant être mis en œuvre pour le groupe d'équipements considéré afin de déterminer le nombre de machines virtuelles (notées MV) devant être utilisées pour chaque groupe d'équipements et identifier les services associés à chacune de ces machines virtuelles. En d'autres termes, chaque machine virtuelle devant être mise en œuvre est identifiée selon les groupes d'équipements et les services à mettre en œuvre pour chaque groupe.
Les fichiers de configuration de chaque machine virtuelle sont alors générés (étape 420) pour permettre la mise en œuvre des machines virtuelles identifiées et, par conséquent, des services associés.
Ces fichiers sont ici mémorisés dans un serveur de fichiers, par exemple un serveur de fichiers de type NFS accessible par les stations de traitement. Selon un mode de réalisation particulier, les fichiers de configuration sont stockés dans des répertoires dont des noms correspondant à ceux des machines virtuelles. Les fichiers de configurations comprennent notamment des identifiants et des paramètres des services devant être exécutés ainsi que des identifiants d'équipements (ou d'un groupe d'équipements).
Dans une phase d'exploitation référencée 425, mise ici en œuvre dans le framework HA, les machines virtuelles préalablement définies sont lancées (étape 430). A ces fins, une image générique de machine virtuelle est utilisée, la machine virtuelle étant spécialisée selon un groupe d'équipements et un ou plusieurs services à l'aide d'un fichier de configuration préalablement créé, par exemple conformément à l'étape 420.
Les machines virtuelles sont ici lancées sur les stations de traitement définies dans les données de configuration du cluster, selon un mécanisme d'attribution prédéterminé.
Selon un mode de réalisation particulier, si les machines virtuelles sont chacune dédiée à un groupe d'équipements particulier, les stations de traitement ne le sont pas. Ainsi, il peut y avoir, sur une même station de traitement, plusieurs machines virtuelles qui adressent des groupes différents d'équipements. Lorsqu'une défaillance est détectée dans une machine virtuelle ou une station de traitement, une réaffectation de la ou des machines virtuelles correspondantes est effectuée.
Le démarrage d'une machine virtuelle sur une station de traitement est décrit plus en détail en référence à la figure 5. Les machines virtuelles et/ou les stations de traitement (notées ST) utilisées sont alors surveillées (étape 435) et un test est effectué (étape 440) pour déterminer si un problème a été identifié dans une machine virtuelle MVi ou une station de traitement STp. Dans la négative, l'étape de surveillance se poursuit.
Si un problème a été identifié dans une machine virtuelle MVi ou une station de traitement STp, une ou plusieurs stations de traitement STq pouvant mettre en œuvre la machine virtuelle MVi dans laquelle un problème a été détecté ou une ou plusieurs machines virtuelles MVj mises en œuvre dans la station de traitement STp dans laquelle un problème a été détecté sont identifiées (étape 445). L'identification de telles stations de traitement peut être réalisée, par exemple, selon les capacités et les niveaux de charge des stations de traitement.
La machine virtuelle MVi dans laquelle un problème a été détecté ou les machines MVj mises en œuvre dans la station de traitement STp dans laquelle un problème a été détecté sont alors arrêtées ainsi que, le cas échéant, la station de traitement STp (étape 450). Selon un mode de réalisation particulier, lorsqu'une anomalie est détectée dans une machine virtuelle, seule cette dernière est arrêtée et relancée dans une autre station de traitement sans que les autres machines virtuelles de la station de traitement initiale ne soient arrêtées et relancées dans une autre station de traitement (la station de traitement initiale n'est donc pas arrêtée).
La machine virtuelle MVi dans laquelle un problème a été détecté ou les machines MVj mises en œuvre dans la station de traitement STp dans laquelle un problème a été détecté sont ensuite démarrées dans les stations de traitement STq préalablement identifiées (étape 455). A nouveau, l'étape 455 de démarrage de machines virtuelles est décrite plus en détail en référence à la figure 5.
Comme illustré, les étapes précédentes (étapes 435 à 455) sont répétées jusqu'à ce qu'il soit mis fin au procédé.
La figure 5 illustre schématiquement des étapes pour le démarrage d'une machine virtuelle dans une station de traitement permettant la mise en œuvre de services visant un groupe d'équipements. Ces étapes sont ici mises en œuvre et/ou contrôlées par le framework HA.
Une première étape (étape 500) consiste en l'initialisation du démarrage de la machine virtuelle MVi à démarrer. Cette étape comprend notamment l'obtention d'une image générique de machine virtuelle (imag_gen_MV). Elle est ici réalisée de façon standard. La machine virtuelle obtenue est ensuite démarrée (étape 505).
Dans une étape suivante, un test est effectué pour déterminer si le nom de la machine virtuelle MVi à démarrer est connu (étape 510). Si le démarrage de la machine virtuelle est initié par le nœud d'administration, le nom de la machine virtuelle est connu. Il n'est donc pas nécessaire de l'obtenir.
Cependant, si le démarrage de la machine virtuelle est initié par le framework HA, en particulier suite à la détection d'un problème dans une machine virtuelle ou une station de traitement, le nom de la machine virtuelle n'est pas connu et il est nécessaire ici de l'obtenir. Il peut l'être à partir d'une information telle qu'une adresse MAC (acronyme de Media Access Control en terminologie anglo-saxonne), notée MAC@. En effet, lorsqu'un problème est détecté dans une machine virtuelle ou une station de traitement, l'infrastructure haute disponibilité est généralement en mesure d'obtenir l'adresse ou les adresses MAC de la ou des machines virtuelles concernées.
L'adresse MAC de la machine virtuelle MVi à démarrer (ou une information équivalente) est alors adressée aux nœuds d'administration MNGT (étape 515), par exemple sous forme d'une requête dhcp (sigle de Dynamic Host Configuration Protocol en terminologie anglo-saxonne) pour obtenir, en réponse, le nom de la machine virtuelle MVi à démarrer et, de préférence, son adresse IP (sigle d'Internet Protocol en terminologie anglo-saxonne). Il est observé ici que seul le nœud d'administration qui connaît la machine virtuelle correspondant à l'adresse MAC transmise répond.
Le nom de la machine virtuelle MVi en cours de démarrage, connu ou obtenu, est alors utilisé pour obtenir les données de configuration spécifiques à cette machine virtuelle {fichier_conf), notamment des données relatives au groupe d'équipements administrés par cette machine virtuelle et le ou les services visés (étape 520). A ces fins, un accès à un serveur de fichiers, par exemple un serveur de fichiers de type NFS, peut être créé. Les données de configuration sont alors obtenues, par exemple, en synchronisant un ou plusieurs répertoires (typiquement un répertoire ayant le nom de la machine virtuelle à démarrer).
La machine virtuelle MVi en cours de démarrage est alors configurée, de façon standard, selon les données de configuration obtenue (étape 525).
A titre d'illustration, selon un mode de mise en œuvre particulier, la machine virtuelle MVi fait une requête dhcp, au boot, pour obtenir son nom et son adresse IP puis fait un montage NFS pour récupérer, par un mécanisme de synchronisation, sa configuration qui se trouve dans un répertoire prédéterminé appelé MVi.
La figure 6 représente un diagramme de séquence simplifié du démarrage d'une machine virtuelle MVi suite à l'arrêt de cette machine virtuelle dans une autre station de traitement.
Comme illustré, lors du démarrage de la machine virtuelle ayant un identifiant connu, ici une adresse MAC (MAC@), à partir d'une image générique, cet identifiant est transmis aux nœuds d'administration MNGT (étape 600). Les nœuds d'administration MNGT utilisent cet identifiant pour essayer de retrouver le nom et, de préférence, l'adresse de la machine virtuelle concernée, typiquement l'adresse IP. Ces données sont mémorisées lors de la configuration du cluster. Le nom et l'adresse de la machine virtuelle lui sont ensuite transmis (étape 605) par le nœud d'administration qui connaît la machine virtuelle correspondant à l'adresse MAC transmise.
L'accès à un serveur de fichiers NFS est ensuite initié (montage NFS) pour obtenir, de préférence par un mécanisme de synchronisation, la configuration de la machine virtuelle (étapes 610 et 615). Ces données sont ici obtenues en synchronisant les fichiers d'un répertoire portant le nom de la machine virtuelle, ou un nom qui lui est lié, avec un emplacement local vierge et prédéterminé de la machine virtuelle. Selon un mode de réalisation particulier, les données de configuration d'une machine virtuelle comprennent des données pour l'infrastructure haute disponibilité (framework HA) afin de permettre à cette dernière de superviser la machine virtuelle.
Un service de basculement (appelé failover en terminologie anglo- saxonne) est avantageusement créé dans le framework HA pour chaque machine virtuelle. Il permet notamment de contrôler le démarrage et l'arrêt chaque machine virtuelle ainsi que de la surveiller. A ces fins, trois scripts peuvent être utilisés (un premier étant utilisé pour identifier les services à démarrer lors du démarrage de la machine virtuelle, un second étant utilisé pour identifier les services à arrêter lors de l'arrêt de la machine virtuelle et le troisième étant utilisé pour identifier des services à démarrer lors du démarrage de la machine virtuelle, par exemple des services liés à des services identifiés via le premier script).
La figure 7, comprenant les figures 7a et 7b, illustre un exemple de réaffectation de machines virtuelles (et donc de services) dans un cluster d'administration, par exemple suite à la détection d'une anomalie dans une station de traitement mettant en oeuvre ces machines virtuelles.
La figure 7a représente l'état de trois stations de traitement, notées ST1 , ST2 et ST3, d'un cluster d'administration (non représenté) à un instant donné.
La station de traitement ST1 comprend ici une machine virtuelle MV1 mettant en œuvre un service de surveillance (ou monitoring en terminologie anglo-saxonne) des nœuds de calcul 1 à 599 ainsi qu'une machine virtuelle MV2 mettant en œuvre un service de console de nœuds, appelé conman (acronyme de console manager en terminologie anglo-saxonne), visant des mêmes nœuds de calcul 1 à 599.
De façon similaire, la station de traitement ST2 comprend une machine virtuelle MV3 mettant en œuvre un service de surveillance des nœuds de calcul 600 à 1 199 ainsi qu'une machine virtuelle MV4 mettant en œuvre un service de console de nœuds visant ces mêmes nœuds de calcul. De même, la station de traitement ST3 comprend une machine virtuelle MV5 mettant en œuvre un service de surveillance des nœuds de calcul 1 199 à 1800 ainsi qu'une machine virtuelle MV6 mettant en œuvre un service de console de nœuds visant ces mêmes nœuds de calcul.
A un instant suivant l'instant de l'état des stations de traitement représenté sur la figure 7a, une anomalie est détectée dans la station de traitement ST2. Les machines virtuelles MV3 et MV4 sont alors arrêtées et les stations de traitement ST1 et ST3 sont identifiées pour mettre en œuvre les machines virtuelles MV3 et MV4, respectivement.
La figure 7b représente l'état des trois stations de traitement ST1 ,
ST2 et ST3 après que les machines virtuelles MV3 et MV4 aient été déplacées vers les stations de traitement ST1 et ST3, respectivement.
Comme illustré, les machines virtuelles MV3 et MV4 ont été arrêtées de la station de traitement ST2 et redémarrées sur les stations de traitement ST1 et ST3, respectivement, selon un mécanisme tel que celui décrit en référence aux figures 4 et 5. La station de traitement ST2 n'étant plus utilisée, elle peut être réparées ou arrêtée et, le cas échéant, remplacée.
Selon un mode de réalisation particulier, un mécanisme tel que le mécanisme connu sous le nom de DNS view est utilisé pour permettre à des nœuds de calcul d'adresser des données à une machine virtuelle particulière. Selon ce mécanisme, un serveur DNS comprend une table de correspondance pour associer des adresses d'émetteurs de requête (ici des nœuds de calcul) à des adresses de destinataire (ici des machines virtuelles) en fonction de données de configuration du cluster.
Ainsi, par exemple, un serveur DNS peut être configuré pour indiquer que si une requête provient d'un nœud de calcul ayant une adresse IP donnée, cette requête doit être adressée à une machine virtuelle ayant une autre adresse IP donnée.
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

REVENDICATIONS
1. Procédé de gestion dynamique de services dans un cluster d'administration d'un cluster, ledit cluster d'administration comprenant au moins un nœud d'administration central et une pluralité de stations de traitement adaptées à la mise en œuvre de services visant une pluralité de nœuds de calcul, ledit au moins un nœud d'administration central répartissant une exécution de services dans des stations de traitement de ladite pluralité de stations de traitement, ce procédé étant caractérisé en ce qu'au moins un service est mis en œuvre via au moins une machine virtuelle exécutée par une station de traitement et en ce qu'il comprend les étapes suivantes,
- surveillance (435) d'au moins un paramètre d'exécution de ladite au moins une machine virtuelle ; et,
- si une anomalie est détectée en réponse à ladite étape de surveillance, arrêt (450) de ladite au moins une machine virtuelle exécutée par ladite station de traitement, appelée première station de traitement, et redémarrage (455) de ladite machine virtuelle dans une seconde station de traitement, distincte de ladite première station de traitement, le redémarrage de ladite au moins une machine virtuelle étant au moins partiellement basé sur des données de configuration de ladite au moins une machine virtuelle.
2. Procédé selon la revendication 1 comprenant en outre une étape préalable de génération (420) de données de configuration de ladite au moins une machine virtuelle dans une étape de configuration dudit cluster, ladite étape de génération étant mise en œuvre au moins partiellement par ledit au moins un nœud d'administration central.
3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ladite étape de redémarrage comprend une étape de démarrage (505) d'une machine virtuelle générique et une étape de configuration (525) de ladite machine virtuelle générique selon lesdites données de configuration de ladite au moins une machine virtuelle.
4. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape d'obtention (520) desdites données de configuration de ladite au moins une machine virtuelle, lesdites données de configuration de ladite au moins une machine virtuelle étant obtenues à partir d'un identifiant de ladite machine virtuelle arrêtée.
5. Procédé selon la revendication 4 comprenant en outre une étape d'obtention (515) dudit identifiant de ladite machine virtuelle arrêtée, appelé premier identifiant, à partir d'un second identifiant de ladite machine virtuelle arrêtée, distinct dudit premier identifiant.
6. Procédé selon la revendication 4 ou la revendication 5 selon lequel ladite étape d'obtention desdites données de configuration de ladite au moins une machine virtuelle comprend une étape de synchronisation de données entre un serveur de fichiers et ladite au moins une machine virtuelle.
7. Procédé selon l'une quelconque des revendications 1 à 6 comprenant en outre une étape d'identification (445) de ladite seconde station de traitement.
8. Procédé selon l'une quelconque des revendications 1 à 7 comprenant en outre une étape de répartition de l'exécution de services dans des stations de traitement, en fonction des services à répartir et des n uds de calcul visés par les services à répartir, ladite étape de répartition étant mise en œuvre dans ledit au moins un nœud d'administration central.
9. Procédé selon l'une quelconque des revendications 1 à 8 selon lequel ledit au moins un paramètre d'exécution est un paramètre directement lié au fonctionnement de ladite au moins une machine virtuelle ou à ladite première station de traitement.
10. 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.
PCT/FR2012/051488 2011-07-08 2012-06-28 Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration WO2013007910A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP12738544.1A EP2729874B1 (fr) 2011-07-08 2012-06-28 Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1156235 2011-07-08
FR1156235A FR2977691B1 (fr) 2011-07-08 2011-07-08 Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration

Publications (1)

Publication Number Publication Date
WO2013007910A1 true WO2013007910A1 (fr) 2013-01-17

Family

ID=46579205

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/051488 WO2013007910A1 (fr) 2011-07-08 2012-06-28 Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration

Country Status (3)

Country Link
EP (1) EP2729874B1 (fr)
FR (1) FR2977691B1 (fr)
WO (1) WO2013007910A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106547861A (zh) * 2016-10-21 2017-03-29 天脉聚源（北京）科技有限公司 一种智能管理机器节点的数据库的方法及装置
CN106681791A (zh) * 2016-11-09 2017-05-17 重庆邮电大学 一种基于对称邻居关系的增量式虚拟机异常检测方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100058108A1 (en) * 2008-09-04 2010-03-04 Hitachi, Ltd. Method for analyzing fault caused in virtualized environment, and management server
US20100325471A1 (en) * 2009-06-17 2010-12-23 International Business Machines Corporation High availability support for virtual machines
US7925923B1 (en) * 2008-01-31 2011-04-12 Hewlett-Packard Development Company, L.P. Migrating a virtual machine in response to failure of an instruction to execute
WO2011051025A1 (fr) * 2009-10-30 2011-05-05 International Business Machines Corporation Procédé et système de gestion de défauts dans des environnements informatiques virtuels

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8549364B2 (en) * 2009-02-18 2013-10-01 Vmware, Inc. Failure detection and recovery of host computers in a cluster

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7925923B1 (en) * 2008-01-31 2011-04-12 Hewlett-Packard Development Company, L.P. Migrating a virtual machine in response to failure of an instruction to execute
US20100058108A1 (en) * 2008-09-04 2010-03-04 Hitachi, Ltd. Method for analyzing fault caused in virtualized environment, and management server
US20100325471A1 (en) * 2009-06-17 2010-12-23 International Business Machines Corporation High availability support for virtual machines
WO2011051025A1 (fr) * 2009-10-30 2011-05-05 International Business Machines Corporation Procédé et système de gestion de défauts dans des environnements informatiques virtuels

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106547861A (zh) * 2016-10-21 2017-03-29 天脉聚源（北京）科技有限公司 一种智能管理机器节点的数据库的方法及装置
CN106681791A (zh) * 2016-11-09 2017-05-17 重庆邮电大学 一种基于对称邻居关系的增量式虚拟机异常检测方法

Also Published As

Publication number Publication date
FR2977691A1 (fr) 2013-01-11
EP2729874B1 (fr) 2022-07-13
EP2729874A1 (fr) 2014-05-14
FR2977691B1 (fr) 2013-07-12

Similar Documents

Publication Publication Date Title
Kangjin et al. Fid: A faster image distribution system for docker platform
EP2550597B1 (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
FR3025333A1 (fr) Serveur comprenant une pluralite de modules
US9521194B1 (en) Nondeterministic value source
US10860375B1 (en) Singleton coordination in an actor-based system
US10516734B2 (en) Computer servers for datacenter management
FR3002807A1 (fr) Procede de detection d'attaques
EP2876551A1 (fr) Procédé, programme d'ordinateur et dispositif de configuration ou de maintenance d'un système informatique dans un cluster
WO2012140344A1 (fr) Procédé et dispositif de traitement de commandes d'administration dans un cluster
WO2019153880A1 (fr) Procédé de téléchargement de fichier miroir dans un groupe, nœud et serveur d'interrogation
FR2958059A1 (fr) Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs
EP2729874B1 (fr) Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration
EP2704010A1 (fr) Procédé et dispositif de traitement de commandes dans un ensemble d'éléments informatiques
WO2011151569A1 (fr) Procede de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede
US9348672B1 (en) Singleton coordination in an actor-based system
US10374915B1 (en) Metrics processing service
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é
EP2721487B1 (fr) Procede, dispositif et programme d'ordinateur pour la mise à jour logicielle de clusters optimisant la disponibilite de ces derniers
US20190050256A1 (en) Systems and methods for distributed management of computing resources
Pol Big data and hadoop technology solutions with cloudera manager
WO2013088019A1 (fr) Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité
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
FR3039024A1 (fr) Systeme et procede automatique de deploiement des services sur un noeud reseau
EP2727057B1 (fr) Procede et programme d'ordinateur pour identifier dynamiquement des composants d'un cluster et automatiser des operations de gestion optimisee du cluster

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: 12738544

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012738544

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE