WO2013088020A1 - Procédé et programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité - Google Patents

Procédé et programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité Download PDF

Info

Publication number
WO2013088020A1
WO2013088020A1 PCT/FR2012/052732 FR2012052732W WO2013088020A1 WO 2013088020 A1 WO2013088020 A1 WO 2013088020A1 FR 2012052732 W FR2012052732 W FR 2012052732W WO 2013088020 A1 WO2013088020 A1 WO 2013088020A1
Authority
WO
WIPO (PCT)
Prior art keywords
equipment
high availability
group
management
nodes
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/FR2012/052732
Other languages
English (en)
Inventor
Jean-Olivier GERPHAGNON
Alain MOULLE
Philippe Couvee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
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
Publication of WO2013088020A1 publication Critical patent/WO2013088020A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F11/202—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 where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F11/202—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 where processing functionality is redundant
    • G06F11/2035—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 where processing functionality is redundant without idle spare hardware

Definitions

  • the present invention relates to the administration of computer infrastructures such as clusters and data centers (or data centers). and more particularly an outsourced and centralized computer management method and computer program of failures in an IT infrastructure including high availability equipment.
  • HPC High Performance Computing
  • Performance Computing in English terminology is developing for both academic research and industry, particularly in technical fields such as automotive, aerospace, energy, climatology and life sciences.
  • 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 00 of a cluster, type fat-tree.
  • the latter comprises a set of nodes generically referenced 105.
  • the nodes belonging to the set 110 are here nodes of calculation 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 1 being called 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 206 Random Access Memory in English
  • registers adapted to record variables and parameters created and modified during the execution of programs (as illustrated, each memory component alive can be associated with a microprocessor);
  • 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.
  • the program or programs that are stored in a non-volatile memory for example a hard disk, are transferred into the RAM 206.
  • a non-volatile memory for example a hard disk
  • These solutions offering high availability characteristics, called High-Availability (or HA) in English terminology, require a set of relatively complex technical components and a coverage of the high availability field clearly identified.
  • a high availability system covers a type of faults commonly referred to as "simple faults" in which a single equipment of a predetermined set of equipment fails at a given time.
  • a failure of a device can be caused by the failure of a hardware component such as a central processing unit (CPU), a memory or a power supply, or a failure (typically called a bug) of a component. software implemented by the equipment in question.
  • Such a mechanism can, for example, be implemented in a cluster using the Unix operating system (Unix is a brand) with a high availability management system (called high availability cluster because of the grouping of a set of components, hardware and software, to provide a particular function) such as the open source product known as "Pacemaker”. It allows the control of high-availability components (monitoring and reconfiguration in the event of a failure), in particular by using a dedicated monitoring network called "heartbeat" verifying that the targeted components are operational.
  • FIG. 3 schematically represents a portion 300 of a cluster comprising high availability equipment, here four nodes referenced 305-0 to 305-3, and three referenced switches 310. -0 to 310-2 connected to a communication network 315.
  • the node 305-0 is connected to the switch 310-0
  • the nodes 305-1 and 305-2 are connected to the switch 310-1
  • the node 305 -3 is connected to switch 310-2.
  • Each node may include one or more software modules (not shown) that may cause a failure.
  • the failure of an equipment may be related to a hardware failure of a component of the latter or to a failure of a software component implemented. by the latter.
  • Figure 3a shows the situation in which all the nodes, switches and the communication network are functioning correctly.
  • services that can exchange data are performed in nodes 305-0 to 305-3.
  • the services referred to here are services in the sense of high availability. They are linked to the resources of the nodes and can be software services as such, file systems, processes, IP addresses (abbreviation of Internet Protocol in English terminology), etc.
  • the nodes 305-0 to 305-3 are part of the same group of high availability equipment (high availability group or HA group). Thus, when one of these nodes is faulty (for a hardware or software reason), one or more operational nodes of the group take over. This is also true for the equipment that connects them to the network (switches 310-0 to 310-2). If one of these devices is defective (also for a hardware or software reason), a flip-flop is performed to ensure continuity of service.
  • Figure 3b illustrates the principle of high availability implemented when the switch 310-0 has a failure, making the latter unavailable (as illustrated by the solid line cross).
  • the node 305-0 When the switch 310-0 is faulty, the node 305-0 is no longer visible from the nodes 305-1, 305-2 and 305-3 (the nodes 305-1, 305-2 and 305-3 no longer receive the heartbeat of the knot 305-0). The latter therefore deduce an anomaly for the node 305-0 (as illustrated by the dotted line cross).
  • the high availability mechanism distributed in the nodes 305-1, 305-2 and 305-3 is therefore implemented to redistribute the services performed by the node 305-0 on the nodes 305-1, 305-2 and 305-3. as well as related parameters such as IP addresses (as illustrated by the arrows).
  • the invention solves at least one of the problems discussed above.
  • the subject of the invention is thus a method of dynamically managing services in a computing infrastructure comprising a plurality of equipment items, at least one of which forms at least one group of high availability equipment, according to which services managed by a device of said least one group of high availability equipment are transferred to at least one other device of said group of high availability equipment when said equipment is considered to be defective, the method comprising a step of monitoring each equipment of said at least one equipment group with high availability to identify a failure, this method being at least partially implemented in at least one high availability management equipment, said at least one high availability management equipment being an equipment of said cluster and being distinct from the equipment of said set of equipment forming said self ns a group of high availability equipment.
  • the method according to the invention thus enables decision-making by an external high availability control system having an overall visibility of the state of the equipment of the same group of high availability equipment. It thus eliminates the risks associated with the fact that two devices believing themselves alone can launch each of the identical resources, which can notably cause problems of data corruption and operating errors. It also eliminates risks that two devices are no longer mutually "kill" each other, which can lead to a loss of resources. In addition, it also eliminates issues related to the intrinsic load of the equipment, that is, the system load that can cause high availability or resource response problems, such as service problems. .
  • said step of monitoring each device of said at least one group of high availability equipment to identify a failure comprises a step of receiving an indication of operation of each equipment of said at least one group of devices.
  • high availability equipment said step of receiving an operation indication being implemented in said at least one high availability management equipment or in at least one equipment of said at least one group of high availability equipment.
  • an equipment can notably be considered as failing in the absence of receiving an indication of operation of this equipment during a predetermined time interval.
  • the method further comprises a step of receiving a notification to stop a faulty equipment considered.
  • the method further comprises a step of verifying at least one condition related to a set of equipment of said at least one group of equipment with high availability, a step of transfer of services between a defective equipment considered and another equipment of said at least one group of high availability equipment being performed in response to said verification step.
  • the method according to the invention can thus take into account the general condition of the equipment of said at least one group of high availability equipment.
  • the method according to the invention furthermore preferably comprises a step of identifying at least one operational equipment of said at least one group of equipment with high availability, said services managed by said equipment considered defective being transferred to said at least one operational equipment.
  • the method further comprises a step of selecting at least one operational equipment from one or more identified operational equipment, said selection being based on high availability levels associated with groups of high-level equipment. availability to which belongs at least one identified operational equipment, the use of multiple levels of high availability facilitating the management of multiple failures.
  • the method further comprises a step of transferring said services managed by said faulty equipment considered to at least one equipment of a second group of high availability equipment, said at least one group of equipment with high availability being called at least a first group of high availability equipment, when no operational equipment is identified in said at least one first group of high availability equipment. It is thus possible to migrate services from one group of highly available equipment to another to ensure continuity of service.
  • said step of transferring said services managed by said equipment considered defective is implemented at least partially by at least one equipment to which at least one of said services is transferred. It is possible to use some of the existing high availability solutions.
  • said at least one high availability management equipment belongs to a high availability equipment group dedicated to the management of high availability and distinct from said at least one group of high availability equipment.
  • 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 comprising FIGS. 3a and 3b, schematically represents a portion of a computing infrastructure including high availability equipment when all these equipment are functioning correctly and when a fault is detected, respectively;
  • FIG. 4 schematically illustrates the architecture of a portion of an IT infrastructure comprising several high availability groups, one of which is used to manage the high availability management externally and centrally;
  • FIG. 5 comprising FIGS. 5a, 5b and 5c, illustrates steps of two examples of algorithms for managing the high availability of groups of high availability equipment according to the invention from a device of a device. group dedicated to the management of high availability;
  • FIG. 6, comprising FIGS. 6a to 6d, illustrates a fault management scenario in a part of an IT infrastructure including a centralized high availability management mechanism according to the invention.
  • FIG. 7 schematically illustrates a portion of a computing infrastructure comprising high availability equipment grouped by high availability groups according to several levels of internal and external high availability, allowing a management of multiple faults within groups of high availability and between high availability groups;
  • FIG. 8 illustrates the implementation of high availability mechanisms, according to the invention, when a failure of a network of communication is detected in the part of the IT infrastructure shown in Figure 7.
  • the invention aims to outsource at least part of the responsibility for managing the high availability of a group of equipment to another group of equipment that is in charge of this task, centrally and dedicated .
  • the object of the invention is to move at least part of the high availability management of a set of high availability groups to a specific group of equipment (also configured as a high equipment group). availability).
  • Figure 4 schematically illustrates the architecture of a portion of an IT infrastructure such as a cluster comprising a plurality of high availability equipment groups, one of which is used to externally and centrally manage the high availability management.
  • the illustrated portion of the IT infrastructure here comprises four functional node groups referenced 400-0 to 400-3, each of these groups comprising, in this example, four nodes.
  • node group 400-0 comprises the four nodes 405-00 to 405-03.
  • the sets of nodes 400-0 to 400-3 are connected to a group of nodes 410 dedicated to the management of high availability via switches referenced 415-0 and 415-1.
  • the node group 410 dedicated to the management of high availability here comprises three nodes.
  • Each node of the node group 410 dedicated to high availability management is connected to each node of each of the node groups 400-0 to 400-3 via the switches 415-0.
  • each node of the node group 410 dedicated to high availability management is connected to each node of each of the node groups 400-0 to 400-3 via the switches 415-1.
  • the connection 420 between a node 410 node dedicated to the management of high availability and switches 415-1 includes a single link
  • the connection 425 between the nodes of the node group 400-2 and the switches 415-1 here comprises four links (one per node pair).
  • the entire management of high availability is handled by the group dedicated to the management of high availability.
  • the group dedicated to the management of high availability is handled by this group.
  • only certain operations relating to the management of high availability are processed by this group.
  • a commonly used high availability mechanism is to check, by each of the equipment in a group, the good functioning of the other equipment of the same group, to which resources or sets of resources are affected, as well as resources themselves, such as services, file management systems, and address configurations (typically IP addresses). More generally, this mechanism is intended to verify all the hardware and / or software resources of a group. Such a mechanism, implemented within a group of equipment forming a network, may in particular consist of verifying the proper functioning of the resources by receiving indications of proper operation. It is observed here that such indications can pass through a secondary network, for example an administration network.
  • the invention therefore aims to move this mechanism and, where appropriate (in accordance with the first implementation described) the monitoring mechanisms of each monitored resource, to equipment of a group dedicated to the management of high availability to optimize managing high availability and, in particular, eliminating the risk of split-brain and dual-fencing.
  • the equipment of the high availability equipment groups manage their resources in a standard way, that is to say of the same only in the current solutions. It is therefore not necessary to carry out a complete software redevelopment of the mechanisms implemented. Nevertheless, it is observed here that the monitoring mechanism making it possible to take the decision to activate the mechanism of inhibition of an equipment (operation called fence in Anglo-Saxon terminology) is not necessary within each equipment of the groups. high availability. In fact, in the event of equipment failure, the Dedicated high availability management group equipment detect this failure and make the decision to perform the so-called fencing operation. When this operation is performed and acknowledged (that is, actually executed), the equipment in the dedicated high availability management group informs each active device in the relevant HA group to allow redeployment. resources previously implemented by the defective equipment on the other equipment of the group.
  • Another method of failure management is also possible by maintaining high availability management locally at the high availability equipment group.
  • the failure of a resource is detected by all (other) devices in the group that generate a fence instruction, as in commonly implemented solutions.
  • the generated fence instruction is not addressed here to the faulty equipment (or to the equipment including a faulty resource), but to the equipment of the group dedicated to the management of high availability to using a particular request for a fence instruction of the equipment detected as faulty.
  • the equipment in the dedicated high availability management group decides whether or not to execute the fence instruction based on the information available to them by checking the overall state of the high availability equipment group (and, if applicable, other groups of high availability equipment they control).
  • fence instruction If the fence instruction is to be executed, a confirmation is sent to the HA equipment that submitted the initial request with an indication of success. If, on the other hand, the fence instruction is not executed, a corresponding indication is sent to the equipment in the HA group that submitted the initial request so that no resources are redeployed in the device group. high availability.
  • Such a method makes it possible to divert the standard operation of the fencing operation without any other particular modifications. It is recalled here that the operation called fence aims to "kill" a faulty equipment considered to inhibit it so that none of the resources of this equipment does not respond to solicitations.
  • the associated high availability system detects that all the resources of the defective equipment no longer responds and, consequently, migrates these resources to operational equipment, typically operational equipment of the group. of high availability equipment to which belongs the equipment considered defective.
  • the purpose of this operation is to "kill" the defective equipment so that it is no longer taken into account by the operational equipment and that its resources are migrated to the latter.
  • the dedicated high availability management group is itself a group of high availability equipment comprising at least two or more devices, used, for example, according to a quorum decision mechanism.
  • This dedicated high availability management group does not require a particular element. In fact, it only supports the monitoring of equipment of high availability equipment groups, the decision making or not of the "fencing" instructions requested by the groups of high availability equipment and the processing fencing instructions to be performed.
  • each equipment of the dedicated high availability management group is connected to all the equipment of the high availability equipment groups by two communication networks, in order to ensure the surveillance of all these equipment and the redundancy of access for this monitoring (to avoid blocking points, called SPOF, acronym for Single Point Of Failure in English terminology).
  • the two communication networks used may be of the same type or of different types.
  • a first communication network may be of the Ethernet type and the second of the Inifiniband type or the first of type Ethernet 1G and the second of type Ethernet 10G (Ethernet and Infiniband are trademarks).
  • Such an implementation thus allows the centralized implementation of a heartbeat high availability management, that is to say a heartbeat type management of all groups of high availability equipment.
  • each equipment of the dedicated high availability management group is connected to all the equipment of the high availability equipment groups by two communication networks, in order to ensure the monitoring of all of this equipment requires that at least two devices from the dedicated high availability management group be connected to all equipment in the high availability equipment groups.
  • FIG. 5a illustrates steps of a first exemplary algorithm for managing the high availability of groups of high availability equipment according to the invention from a device of a group dedicated to the management of high availability. .
  • a first step (step 500) consists of an initialization of the algorithm.
  • This step aims, in particular, the initialization of counters used to identify a failure of a device.
  • a counter noted Timen j is associated with each equipment j of each group i of high availability equipment. These counters are initialized to zero during the initialization phase. These counters are automatically incremented over time, for example of the value one every n ms.
  • a next step (step 505) is to receive indications of the operation of high availability equipment group equipment.
  • the operating indications are heartbeat type.
  • receiving an indication of operating an equipment j of a group / 'highly available equipment, noted HBj j establishes that this equipment operates at the moment.
  • the counter corresponding to the equipment from which an operation notification is received ie here the timer Timen j associated with the equipment j of the group / equipment with high availability, is reset to the value zero ( step 510).
  • a test is performed (step 515) to determine if there is a counter associated with a device of a group of high availability equipment having a value greater than a threshold ⁇ predetermined, indicating a failure of the corresponding equipment . If not, the algorithm loops back on itself.
  • variables m and n are initialized to zero (step 520).
  • the variable m represents here an equipment index in a group of high availability equipment while the variable n is intended to indicate the number of operational equipment in this group.
  • the equipment / group k is an equipment, for example a node, which no longer correctly transmits its heartbeat (in accordance with the process of verifying that the equipment is operational and accessible) to equipment of the dedicated group of high availability management. In this case, it is therefore necessary to determine which operational equipment belongs to the same group of high availability equipment as the failed equipment in order to reorganize the resources.
  • a test is performed (step 525) for comparing the counter value Timer km associated with the equipment m k group ⁇ threshold. If the value of the counter T ⁇ er m associated with the equipment m of the group k is lower than the threshold ⁇ , the equipment m of the group / is operational. The index m is then stored and the variable n is incremented by one (step 530).
  • the index m is incremented by one (step 535) and a test is performed (step 540) to determine whether the value of the index m is greater than or equal to a value m max representing the number of equipment in group k. If not, the preceding steps referenced 525 to 540 are repeated.
  • step 545 another test is performed (step 545) to determine if there are operational devices in the group k, that is to say say if the variable n is greater than zero.
  • an equipment of the dedicated high-availability management group issues a fence instruction for the operational equipment of this group to "kill" the faulty equipment in order to redistribute the resources assigned to it and that it is no longer taken into account by the operational equipment (step 555).
  • this equipment of the dedicated high-availability management group informs the operational equipment of the group k that the fence operation has gone well. The transfer of resources, typically services and associated parameters, between the faulty equipment and the operational equipment is carried out by them, in a standard way.
  • the implementation of this operation can be carried out, for example, via the communication network used, at the level of the operating system or at the BMC / IPMI level (abbreviations of Baseboard Management Controller and Intelligent Platform Management Interface in English terminology), or via an electrical management that can use a controllable PDU (acronym for Power Distribution Unit in English terminology).
  • the algorithm then loops back on itself to treat, if necessary, other failures.
  • FIGS. 5b and 5c illustrate steps of a second exemplary algorithm for managing the high availability of groups of high availability equipment according to the invention from an equipment of a group dedicated to the management of the high availability.
  • the steps represented in FIG. 5b are here implemented in equipment of a group of equipment with high availability while the steps represented in FIG. 5c are implemented in equipment of a group of equipment dedicated to the management of high availability.
  • a first step (step 500 ') consists of an initialization which aims, in particular, the initialization of counters used to identify a failure of a device.
  • a counter noted Timer j is associated with each equipment j of the group of high availability equipment to which belongs the equipment implementing the algorithm, except the latter. These counters are initialized to zero during the initialization phase. They are automatically incremented over time, for example of the value one every n ms.
  • a next step (step 505 ') is to receive indications of equipment operation of the group of high availability equipment to which belongs the equipment implementing the algorithm.
  • the operating indications are heartbeat type.
  • the counter corresponding to the equipment from which an operation notification is received that is to say here the counter Timer j associated with the equipment j, is reset to zero (step 510 '). As shown, these two steps are repeated for each received indication of operation.
  • a test is performed (step 515 ') to determine if there is a counter associated with a device of the high availability equipment group, to which belongs the equipment implementing the algorithm, having a value greater than one.
  • threshold ⁇ predetermined, indicating a failure of the corresponding equipment. If not, the algorithm loops back on itself.
  • a fence notification is addressed to the equipment of the group d equipment dedicated to managing the high availability of the group to which the equipment implementing the algorithm belongs (step 555 ').
  • the equipment / equipment for example a node, no longer correctly transmits its heartbeat (in accordance with the process for verifying that the equipment is operational and accessible) to the equipment of its equipment group to high availability.
  • a fence notification is sent to equipment in an equipment group dedicated to high availability management. The latter having a global view of the equipment of the high availability group including the faulty equipment considered can determine whether or not a fence operation should be carried out.
  • the algorithm implemented in equipment of a group of equipment dedicated to the management of high availability comprises a first initialization step (step 560) during which a variable is initialized Nb_n ⁇ ud_op, for each group of high availability equipment controlled by the equipment group dedicated to the management of high availability to which belongs the equipment implementing the algorithm. This variable corresponds to the number of operational equipment in the corresponding group when the algorithm is started.
  • a next step (step 565) a test is performed to determine if a fence notification has been received from equipment of a group k of high availability equipment. If not, the algorithm loops on itself as shown.
  • a test is performed (step 570) to determine whether the number of operational equipment of group k of high availability equipment, noted Nb_node_op k is greater than one, c ' that is to say if, in addition to the equipment considered defective, there is at least one equipment capable of implementing the resources previously implemented by the defective equipment considered.
  • This test also aims to verify that conditions related to the group of high-availability equipment to which belongs the equipment considered defective are met to perform a fence operation.
  • a fence instruction is transmitted to the faulty equipment considered (step 575).
  • a test is then performed to verify that the fence operation has been correctly performed (step 580). If the fence operation has been correctly performed, the value of the variable Nb_node_op k is decremented by one (step 585) and a confirmation message is sent to the operational equipment of the group of high availability equipment to which the equipment belongs. failed (step 590) to allow the migration of the resources implemented by the faulty equipment considered, typically services and associated parameters. The algorithm then loops back on itself, as illustrated, to handle, if necessary, other fence operations.
  • an error message is preferably generated (step 595). Again, the algorithm loops back on itself, as illustrated, to handle, if necessary, other fence operations.
  • the equipment of the high availability equipment groups are each interconnected with each equipment of the group of equipment dedicated to the management of the high availability by at least two independent and reliable communication networks. These two networks are physically separate (they use different switches) for all groups of high availability equipment.
  • FIG. 6, comprising FIGS. 6a to 6d, illustrates a fault management scenario in a part of an IT infrastructure comprising a centralized high availability management mechanism according to the invention.
  • Figure 6a schematically illustrates the architecture of a portion of an IT infrastructure here including three groups of high availability equipment, one of which is used to externally and centrally manage the high availability management.
  • the illustrated portion of the computer infrastructure here comprises two groups of functional equipment referenced 600-0 and 600-1, each of these groups comprising, in this example, four nodes.
  • the group 600-0 includes the four nodes 605-00 to 605-03 while the group 600-1 includes the four nodes 605-10 to 605-13.
  • Each node of each node group 600-0 and 600-1 is connected to a node of a node group 610 dedicated to the management of high availability via switches referenced 615-0 and 615-1, for example switches Ethernet.
  • the node group 610 dedicated to the management of high availability here comprises three nodes referenced 620-0 to 620-2.
  • each node of each group of nodes 600-0 and 600-1 is doubly connected to a node of the node group 610 dedicated to the management of high availability via two different communication networks (using different switches) .
  • node groups 600-0 and 600-1 are here dedicated to the management of a file system of the Luster type implementing object storage servers (OSS, an acronym for Object Storage Server in English terminology) for storing data in object storage targets (OST, an Object Storage Target acronym in English terminology) local disk file systems.
  • OSS object storage servers
  • OST object Storage Target acronym in English terminology
  • the nodes of the group 610 dedicated to high availability management detect the failure of the node 605-01 (directly or via a fence notification received from the operational nodes). of the group in which the failure was detected, ie nodes 605-00, 605-02 and 605-03). They then issue a fence-type instruction to node 605-01. The latter is then "killed" so that the other nodes of the group are informed of the failure by the group dedicated to the management of high availability (represented in FIG. 6b by straight arrows in bold lines) and can migrate the allocated resources. at node 605-01 to one or more operational nodes of the group (shown in FIG. 6b by curved arrows in bold lines).
  • Figure 6c illustrates the configuration of equipment groups 600- 0, 600-1, and 610 after the resources allocated to node 605-01 were distributed over nodes 605-00, 605-02, and 605-03.
  • the centralized management mechanism of high availability is capable of handling multiple failures.
  • the resources it manages are transferred to the nodes 605-02 and 605-03.
  • the multiple fault management mechanism is easy to implement because the management of high availability is centralized with an overall view of the state of high availability equipment groups because it is not no longer needed to have quorum management in groups monitored high-availability equipment because the decision-making part is outsourced.
  • the centralized management mechanism of high availability allows a switch between groups, that is to say a transfer of services between nodes of different groups.
  • the identification of a solution is advantageously carried out in two stages. Firstly, an analysis is performed at the high availability equipment group or groups in which the failure or failures have been detected in an attempt to find a solution at this level, as described above. If no solution is identified during this first analysis, a second analysis based on high availability mechanisms outside the high availability groups is then performed.
  • FIG. 7 represents a part of an IT infrastructure comprising four high availability groups referenced 700-0 to 700-4.
  • Each high availability group here comprises four nodes and three switches (two nodes being separately connected to two switches and two other nodes being connected to the same switch).
  • a first node of the equipment group 700-0 implements the object storage targets OST1, OST2 and OST3, a second node implements the object storage targets OST4, OST5. and OST6, a third node implements the object storage targets OST7, OST8 and OST9 and a fourth node here implements the object storage targets OST10, OST11 and OST12.
  • the equipment of each group of high availability equipment is advantageously divided into high availability groups according to several internal levels.
  • a first level of internal high availability is associated with the group 700-0 while a second internal level is associated with the groups 705-00 and 705-01 which here each comprise two nodes of the group 700-0, such as illustrated.
  • the equipment of Groups 700-1, 700-2, and 700-3 are divided into high availability groups according to several internal levels, similarly.
  • the second level of high availability here has a higher value than the first level of high availability.
  • a solution is sought for the lowest level. If no solution is found for this level, a solution is sought for the higher level and so on.
  • equipment is common to several groups of different levels (each HA group of a level includes equipment of a lower level HA group).
  • switches belong to the first level group 700-0 and the second level group 705-01.
  • equipment is common to several groups of the same level.
  • a switch in the 700-0 group belongs to both the second-level groups 705-00 and 705-01.
  • the high availability groups 700-0 and 700-1 here correspond to a first file system whereas the high availability groups 700-2 and 700-3 correspond here to a second file system.
  • the high availability groups 700-0 and 700-1 are grouped together to form a first high availability cell.
  • a first level of external high availability referenced 710-0 is associated with the elements of this cell.
  • the high availability groups 700-2 and 700-3 are grouped together to form a second high availability cell to which is also associated a first external high availability level (710-1), two high availability levels being also associated with each element of the cell as shown.
  • the cells here comprise only two groups of high availability, the number of groups is not limited to two.
  • a second level of external high availability (not shown) is here associated with all the equipment of the two cells.
  • Each high availability group is connected to two nodes 720-0 and 720-1 of a group 715 of equipment dedicated to the management of high availability (and forming another group of high availability).
  • the nodes 720-0 and 720-1 thus allow services executed by nodes of a high availability group to be transferred to one or more other nodes of the same high availability group according to an internal high availability level or to nodes of a high availability group. one (or more) other high availability group from the same or another cell at an external high availability level.
  • FIG. 8 illustrates the implementation of high availability mechanisms, according to the invention, when a failure of the communication network 800 connecting the switches of the high availability group 700-0 and the nodes 720-0 and 720-1. is detected (represented by the solid line cross).
  • the foregoing description aims at managing failures in equipment such as nodes
  • the invention is not limited to the nodes but can be implemented with other resources of a computing infrastructure such as a cluster or a data center (usually called data center), including switches.
  • a computing infrastructure such as a cluster or a data center (usually called data center), including switches.
  • the description essentially targets the services implemented on the nodes, the invention may also relate to application processes as well as equipment controllers, for example storage controllers and network controllers, in which implement software modules to manage high availability at multiple levels.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)

Abstract

L'invention a notamment pour objet la gestion externalisée et centralisée de pannes dans un cluster comprenant des équipements à haute disponibilité, permettant de migrer des services d'un équipement vers un autre lorsqu'une défaillance est détectée. Certains de ces équipements forment un groupe d'équipements à haute disponibilité selon lequel des services gérés par un équipement du groupe sont transférés à au moins un autre équipement du groupe lorsque ledit équipement est considéré défaillant. Une surveillance de chaque équipement du groupe est effectuée pour identifier une défaillance. Une partie de la gestion de surveillance des équipements et de la migration de services est mise en œuvre dans un équipement de gestion de haute disponibilité appartenant au cluster, distinct des équipements dudit groupe d'équipements, qui est responsable de la gestion de la haute disponibilité.

Description

Procédé et programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatigue comprenant des équipements à haute disponibilité La présente invention concerne l'administration 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 gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité.
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 00 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 110 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. Pour certaines applications dites critiques, il est nécessaire de proposer des solutions permettant d'assurer la disponibilité du cluster en cas de panne de l'un de ces composants. Ces solutions offrant des caractéristiques de haute disponibilité, appelées High-Availability (ou HA) en terminologie anglo- saxonne, nécessitent un ensemble de composants techniques relativement complexes et une couverture du champ de haute disponibilité clairement identifiée.
De façon générale, un système à haute disponibilité couvre un type de pannes communément appelées « simples pannes » selon lequel un seul équipement d'un ensemble prédéterminé d'équipements tombe en panne à un instant donné. Une panne d'un équipement peut notamment être provoquée par la défaillance d'un composant matériel tel qu'une unité centrale de traitement (CPU), une mémoire ou une alimentation électrique, ou par une défaillance (typiquement appelée bug) d'un composant logiciel mis en œuvre par l'équipement considéré.
Un tel mécanisme peut, par exemple, être mis en œuvre dans un cluster utilisant le système d'exploitation Unix (Unix est une marque) avec un système de gestion de la haute disponibilité (appelé cluster de haute disponibilité du fait du regroupement d'un ensemble de composants, matériels et logiciels, afin de fournir une fonction donnée) tel que le produit open source connu sous le nom de « Pacemaker ». Il permet le contrôle de composants à haute disponibilité (surveillance et reconfiguration en cas de panne) en utilisant notamment un réseau de surveillance dédié appelé « heartbeat » vérifiant que les composants visés sont opérationnels.
Typiquement, il consiste, pour chaque équipement d'un ensemble d'équipements à haute disponibilité, à surveiller chacun des autres équipements (réception d'un heartbeat de chaque équipement). Lorsqu'un équipement est considéré en panne, ce dernier est isolé et les processus exécutés par celui-ci sont répartis sur les autres équipements de l'ensemble d'équipement selon une liste de configuration de pannes et une liste d'adaptation correspondante. Ces listes sont prédéterminées et exhaustives. Elles ne peuvent donc viser toutes les configurations possibles de pannes et s'il est possible de gérer toutes les pannes simples, il est impossible, en pratique, de gérer les doubles de pannes de cette façon.
Les solutions de haute disponibilité aujourd'hui utilisées sont généralement déployées directement sur les équipements concernés par la problématique de continuité de service.
A titre d'illustration, la figure 3, comprenant les figures 3a et 3b, représente schématiquement une partie 300 d'un cluster comprenant des équipements à haute disponibilité, ici quatre nœuds référencés 305-0 à 305-3, et trois commutateurs référencés 310-0 à 310-2 reliés à un réseau de communication 315. Comme illustré, le nœud 305-0 est connecté au commutateur 310-0, les nœuds 305-1 et 305-2 sont connectés au commutateur 310-1 et le nœud 305-3 est connecté au commutateur 310-2. Chaque nœud peut comprendre un ou plusieurs modules logiciels (non représentés) pouvant être à l'origine d'une défaillance. Dans un souci de clarté, il convient de comprendre, dans la suite de la description, que la défaillance d'un équipement peut être liée à une défaillance matérielle d'un composant de ce dernier ou à une défaillance d'un composant logiciel mis en œuvre par ce dernier.
La figure 3a représente la situation dans laquelle tous les nœuds, les commutateurs et le réseau de communication fonctionnent correctement. Dans ce cas, des services, pouvant s'échanger des données, sont exécutés dans les nœuds 305-0 à 305-3. Les services visés ici sont les services au sens de la haute disponibilité. Ils sont liés aux ressources des nœuds et peuvent être des services logiciels en tant que tels, des systèmes de fichiers, des processus, des adresses IP (sigle d'Internet Protocol en terminologie anglo-saxonne), etc..
Il est ici considéré que les nœuds 305-0 à 305-3 font partie d'un même regroupement d'équipements à haute disponibilité (groupe de haute disponibilité ou groupe HA). Ainsi, lorsque l'un de ces nœuds est défaillant (pour une raison matérielle ou logicielle), un ou plusieurs nœuds opérationnels du groupe prennent le relais. Ceci est également vrai pour les équipements qui les relient au réseau (commutateurs 310-0 à 310-2). Si l'un de ces équipements est défaillant (également pour une raison matérielle ou logicielle), une bascule est effectuée pour assurer la continuité de service. La figure 3b illustre le principe de haute disponibilité mis en œuvre lorsque le commutateur 310-0 connaît une défaillance, rendant ce dernier indisponible (comme illustré par la croix en trait continu). Lorsque le commutateur 310-0 est défaillant, le nœud 305-0 n'est plus visible des nœuds 305-1 , 305-2 et 305-3 (les nœuds 305-1 , 305-2 et 305-3 ne reçoivent plus le heartbeat du nœud 305-0). Ces derniers en déduisent donc une anomalie visant le nœud 305-0 (comme illustré par la croix en trait pointillé). Le mécanisme de haute disponibilité distribué dans les nœuds 305-1 , 305-2 et 305-3 est donc mis en œuvre pour redistribuer les services exécutés par le nœud 305-0 sur les nœuds 305-1 , 305-2 et 305-3 ainsi que les paramètres associés tels que des adresses IP (comme illustré par les flèches).
Ainsi, en d'autres termes, si un nœud ou un équipement réseau associé à ce nœud tombe en panne, une bascule des services mis en œuvre par ce nœud est automatiquement effectuée pour transférer ces services vers un ou plusieurs nœuds fonctionnels.
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 une infrastructure informatique comprenant une pluralité d'équipements dont au moins un ensemble forme au moins un groupe d'équipements à haute disponibilité selon lequel des services gérés par un équipement dudit au moins un groupe d'équipements à haute disponibilité sont transférés à au moins un autre équipement dudit groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, le procédé comprenant une étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance, ce procédé étant au moins partiellement mis en œuvre dans au moins un équipement de gestion de haute disponibilité, ledit au moins un équipement de gestion de haute disponibilité étant un équipement dudit cluster et étant distinct des équipements dudit ensemble d'équipements formant ledit au moins un groupe d'équipements à haute disponibilité. Le procédé selon l'invention permet ainsi une prise de décision par un système externe de contrôle de haute disponibilité ayant une visibilité globale de l'état des équipements d'un même groupe d'équipements à haute disponibilité. Il permet ainsi de supprimer des risques liés au fait que deux équipements se croyant seuls peuvent lancer chacun des ressources identiques, pouvant notamment entraîner des problèmes de corruption de données et des erreurs de fonctionnement. Il permet également de supprimer des risques selon lesquels deux équipements ne se voyant plus se « tuent » mutuellement, pouvant entraîner une perte de ressources. En outre, il permet également de s'affranchir de problèmes liés à la charge intrinsèque des équipements, c'est-à-dire la charge système pouvant entraîner des problèmes de réponse au niveau de la haute disponibilité ou des ressources, par exemple des services.
Selon un mode de réalisation particulier, ladite étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance comprend une étape de réception d'une indication de fonctionnement de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité, ladite étape de réception d'une indication de fonctionnement étant mise en œuvre dans ledit au moins un équipement de gestion de haute disponibilité ou dans au moins un équipement dudit au moins un groupe d'équipements à haute disponibilité. Selon ce mode de réalisation, un équipement peut notamment être considéré comme défaillant en l'absence de réception d'une indication de fonctionnement de cet équipement durant un intervalle de temps prédéterminé.
Le procédé selon l'invention permet également de s'affranchir d'une problématique de gestion de quorum. En effet, dans une solution de haute disponibilité standard, il est nécessaire d'avoir, pour un groupe d'équipements à haute disponibilité, un nombre minimum d'équipements "actifs" (c'est-à-dire fonctionnant correctement, sans défaillance). Dans un cas général, cette valeur est calculée selon la formule Quorum = (N / 2) + 1 où N est le nombre total d'équipements dans le groupe d'équipements à haute disponibilité. Ainsi, dans le cas d'un groupe d'équipements à haute disponibilité comprenant quatre équipements, un quorum minimum est égal à trois (3 = 4 / 2 + 1). Cela signifie qu'un seul équipement peut-être défaillant dans un groupe d'équipements à haute disponibilité comprenant quatre équipements.
Il n'est pas envisageable, lorsque l'organe décisionnel de haute disponibilité est mis en uvre dans le groupe d'équipements à haute disponibilité, de se passer de quorum car dans ce cas les risques de split-brain (risques liés au fait que deux équipements se croyant seuls lancent chacun les mêmes ressources) ou de dual-fencing (risques liés au fait deux équipements ne se voyant plus s'inhibent mutuellement) sont extrêmement élevés. Conformément au procédé selon l'invention, l'extemalisation d'une partie de la gestion de la haute disponibilité permet de ne plus avoir besoin de maintenir un quorum car l'ensemble des décisions sont prises par l'équipement de gestion de la haute disponibilité qui peut donc décider d'inhiber autant d'équipements qu'il le juge utile avec une redistribution, pour un groupe d'équipements à haute disponibilité comprenant quatre équipements, pouvant aller de quatre équipements vers un seul (lorsque trois équipements sont défaillants).
Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'une notification visant l'arrêt d'un équipement considéré défaillant. Un tel mode de réalisation présente l'avantage de ne requérir que peu de modifications des solutions existantes de haute disponibilité qui peuvent ainsi être utilisées pour mettre en œuvre le procédé selon l'invention.
De façon avantageuse, le procédé comprend en outre une étape de vérification d'au moins une condition liée à un ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, une étape de transfert de services entre un équipement considéré défaillant et un autre équipement dudit au moins un groupe d'équipements à haute disponibilité étant effectuée en réponse à ladite étape de vérification. Le procédé selon l'invention peut ainsi prendre en compte l'état général des équipements dudit au moins un groupe d'équipements à haute disponibilité.
Le procédé selon l'invention comprend en outre, de préférence, une étape d'identification d'au moins un équipement opérationnel dudit au moins un groupe d'équipements à haute disponibilité, lesdits services gérés par ledit équipement considéré défaillant étant transférés audit au moins un équipement opérationnel. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de sélection d'au moins un équipement opérationnel parmi un ou des équipements opérationnels identifiés, ladite sélection étant basée sur des niveaux de haute disponibilité associés à des groupes d'équipements à haute disponibilité auxquels appartient ledit au moins un équipement opérationnel identifié, l'utilisation de plusieurs niveaux de haute disponibilité facilitant la gestion de pannes multiples.
Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de transfert desdits services gérés par ledit équipement considéré défaillant vers au moins un équipement d'un second groupe d'équipements à haute disponibilité, ledit au moins un groupe d'équipements à haute disponibilité étant appelé au moins un premier groupe d'équipements à haute disponibilité, lorsqu'aucun équipement opérationnel n'est identifié dans ledit au moins un premier groupe d'équipements à haute disponibilité. Il est ainsi possible de migrer des services d'un groupe d'équipements à haute disponibilité à un autre pour assurer une continuité de service.
Toujours selon un mode de réalisation particulier, ladite étape de transfert desdits services gérés par ledit équipement considéré défaillant est mise en uvre au moins partiellement par au moins un équipement vers lequel au moins un desdits services est transféré. Il est ainsi possible d'utiliser une partie des solutions de haute disponibilité existantes.
Selon un mode de réalisation particulier, ledit au moins un équipement de gestion de haute disponibilité appartient à un groupe d'équipements à haute disponibilité dédié à la gestion de la haute disponibilité et distinct dudit au moins un groupe d'équipements à haute disponibilité.
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, comprenant les figures 3a et 3b, représente schématiquement une partie d'une infrastructure informatique comprenant des équipements à haute disponibilité lorsque tous ces équipements fonctionnent correctement et lorsqu'une panne est détectée, respectivement ;
- la figure 4 illustre schématiquement l'architecture d'une partie d'une infrastructure informatique comprenant plusieurs groupes à haute disponibilité dont l'un est utilisé pour gérer de façon externe et centralisée la gestion de haute disponibilité ;
- la figure 5, comprenant les figures 5a, 5b et 5c, illustre des étapes de deux exemples d'algorithmes pour gérer la haute disponibilité de groupes d'équipements à haute disponibilité conformément à l'invention à partir d'un équipement d'un groupe dédié à la gestion de la haute disponibilité ;
- la figure 6, comprenant les figures 6a à 6d, illustre un scénario de gestion de panne dans une partie d'une infrastructure informatique comprenant un mécanisme centralisé de gestion de haute disponibilité conforme à l'invention
- la figure 7 illustre schématiquement une partie d'une infrastructure informatique comprenant des équipements à haute disponibilité regroupés par groupes de haute disponibilité selon plusieurs niveaux de haute disponibilité internes et externes, permettant une gestion de pannes multiples au sein de groupes de haute disponibilité et entre groupes de haute disponibilité ; et,
- la figure 8 illustre la mise en œuvre de mécanismes de haute disponibilité, conformément à l'invention, lorsqu'une panne d'un réseau de communication est détectée dans la partie de l'infrastructure informatique représentée sur la figure 7.
De façon générale, l'invention vise à externaliser au moins une partie de la responsabilité de la gestion de la haute-disponibilité d'un groupe d'équipements à un autre groupe d'équipements ayant en charge cette tâche, de façon centralisée et dédiée.
Il est d'ores et déjà observé qu'une prise de décision par un système externe de contrôle de haute disponibilité ayant une visibilité globale de l'état des équipements d'un même groupe d'équipements à haute disponibilité offre de nombreux avantages. En particulier, cette approche permet de supprimer des risques dits de split-brain, c'est-à-dire des risques liés au fait que deux équipements se croyant seuls lancent chacun les mêmes ressources, pouvant notamment entraîner des problèmes de corruption de données et des erreurs de fonctionnement, ainsi que des risques dits de dual-fencing selon lesquels deux équipements ne se voyant plus se « tuent » mutuellement, pouvant entraîner une perte de ressources. Elle permet également de s'affranchir de problèmes liés à la charge intrinsèque des équipements, c'est-à-dire la charge système pouvant entraîner des problèmes de réponse au niveau de la haute disponibilité ou des ressources, par exemple des services.
En d'autres termes, l'invention a pour objet de déplacer au moins une partie de la gestion de haute disponibilité d'un ensemble de groupes de haute disponibilité à un groupe spécifique d'équipements (également configuré en groupe d'équipements à haute disponibilité).
La figure 4 illustre schématiquement l'architecture d'une partie d'une infrastructure informatique telle qu'un cluster comprenant plusieurs groupes d'équipements à haute disponibilité dont l'un est utilisé pour gérer de façon externe et centralisée la gestion de haute disponibilité.
La partie illustrée de l'infrastructure informatique comprend ici quatre groupes de nœuds fonctionnels référencés 400-0 à 400-3, chacun de ces groupes comprenant, dans cet exemple, quatre nœuds. Ainsi, à titre d'illustration, le groupe de nœuds 400-0 comprend les quatre nœuds 405-00 à 405-03. Les ensembles de nœuds 400-0 à 400-3 sont connectés à un groupe de nœuds 410 dédié à la gestion de la haute disponibilité via des commutateurs référencés 415-0 et 415-1. Comme illustré, le groupe de nœuds 410 dédié à la gestion de la haute disponibilité comprend ici trois nœuds.
Chaque nœud du groupe de nœuds 410 dédié à la gestion de la haute disponibilité est connecté à chaque nœud de chacun des groupes de nœuds 400-0 à 400-3 via les commutateurs 415-0. De même, chaque nœud du groupe de nœuds 410 dédié à la gestion de la haute disponibilité est connecté à chaque nœud de chacun des groupes de nœuds 400-0 à 400-3 via les commutateurs 415-1 Ainsi, par exemple, si la connexion 420 entre un nœud du groupe de nœuds 410 dédié à la gestion de la haute disponibilité et les commutateurs 415-1 comprend un seul lien, la connexion 425 entre les nœud du groupe de nœuds 400-2 et les commutateurs 415-1 comprend ici quatre liens (un par paire de nœud).
L'architecture illustrée sur la figure 4 permet plusieurs mises en œuvre de l'invention.
Selon une première implémentation, l'ensemble de la gestion de la haute disponibilité est traitée par le groupe dédié à la gestion de la haute disponibilité. Alternativement, selon une seconde implémentation, seules certaines opérations relatives à la gestion de la haute disponibilité sont traitées par ce groupe.
Il est observé ici que s'il semble intéressant de mettre en œuvre l'ensemble de la gestion de la haute disponibilité dans le groupe dédié à la gestion de la haute disponibilité, une telle solution s'avère néanmoins, en pratique, aujourd'hui, peu réalisable du fait de la charge générée et la complexité d'implémentation. En effet, l'ensemble des tâches de surveillance et d'opérations gérées par l'ensemble des nœuds de chaque groupe étant ici reporté dans un groupe distant dédié à la gestion de la haute disponibilité, ce groupe doit comprendre un nombre de nœuds important, pouvant engendrer un coût excessif.
Par conséquent, le transfert d'une partie seulement de la gestion de la haute disponibilité dans un groupe distant dédié à la gestion de la haute disponibilité s'avère généralement efficace en termes de performances et de coûts et adapté à de grandes et très grandes infrastructures informatiques, notamment des clusters de type HPC.
Comme décrit précédemment, un mécanisme de haute disponibilité couramment utilisé a pour objet la vérification, par chacun des équipements d'un groupe, du bon fonctionnement des autres équipements du même groupe, auxquels des ressources ou des ensembles de ressources sont affectés, ainsi que des ressources elles-mêmes, par exemple des services, des systèmes de gestion de fichiers et des configurations d'adresses (typiquement des adresses IP). Plus généralement, ce mécanisme a pour objet la vérification de toutes les ressources matérielles et/ou logicielles d'un groupe. Un tel mécanisme, mis en œuvre au sein d'un groupe d'équipements formant un réseau, peut notamment consister à vérifier le bon fonctionnement des ressources par la réception d'indications de bon fonctionnement. Il est observé ici que de telles indications peuvent transiter par un réseau secondaire, par exemple un réseau d'administration.
L'invention vise donc à déplacer ce mécanisme et, le cas échéant (conformément à la première implémentation décrite) les mécanismes de surveillance de chaque ressource surveillée, vers des équipements d'un groupe dédié à la gestion de la haute disponibilité afin d'optimiser la gestion de la haute disponibilité et, notamment, supprimer des risques de split-brain et de dual- fencing.
Selon la seconde implémentation, les équipements des groupes d'équipements à haute disponibilité (à l'exception des équipements du groupe dédié à la gestion de la haute disponibilité) gèrent leurs ressources de façon standard, c'est-à-dire de la même manière que dans les solutions actuelles. Il n'est donc pas nécessaire d'effectuer un redéveloppement logiciel complet des mécanismes mis en œuvre. Néanmoins, il est observé ici que le mécanisme de surveillance permettant de prendre la décision d'activer le mécanisme d'inhibition d'un équipement (opération appelée fence en terminologie anglo- saxonne) n'est pas nécessaire au sein de chaque équipement des groupes à haute disponibilité. En effet, en cas de défaillance d'un équipement, les équipements du groupe dédié de gestion de la haute disponibilité détectent cette défaillance et prennent la décision de réaliser l'opération dite de fencing. Lorsque cette opération est réalisée et acquittée (c'est-à-dire effectivement exécutée), les équipements du groupe dédié de gestion de la haute disponibilité en informent chaque équipement actif du groupe d'équipements à haute disponibilité concerné afin d'autoriser un redéploiement des ressources précédemment mises en uvre par l'équipement défaillant sur les autres équipements du groupe.
Une autre méthode de gestion de défaillances est également possible en conservant une gestion de la haute disponibilité de façon locale au groupe d'équipements à haute disponibilité. Ainsi, la défaillance d'une ressource est détectée par tous les (autres) équipements du groupe qui génèrent une instruction de fence, comme dans les solutions couramment mises en œuvre. Cependant, contrairement à ces dernières, l'instruction de fence générée n'est pas ici adressée à l'équipement défaillant (ou à l'équipement comprenant une ressource défaillante), mais aux équipements du groupe dédié à la gestion de la haute disponibilité à l'aide d'une requête particulière visant une instruction de fence de l'équipement détecté comme défaillant. Les équipements du groupe dédié de gestion de la haute disponibilité décident d'exécuter ou non l'instruction de fence en fonction des informations à leur disposition en vérifiant l'état global du groupe d'équipements à haute disponibilité (et, le cas échéant, des autres groupes d'équipements à haute disponibilité qu'ils contrôlent). Si l'instruction de fence doit être exécutée, une confirmation est transmise aux équipements du groupe d'équipements à haute disponibilité ayant soumis la requête initiale avec une indication de succès. Si, au contraire, l'instruction de fence ne doit pas être exécutée, une indication correspondante est transmise aux équipements du groupe d'équipements à haute disponibilité ayant soumis la requête initiale afin qu'aucune ressource ne soit redéployée dans le groupe d'équipements à haute disponibilité. Une telle méthode permet de détourner le fonctionnement standard de l'opération de fencing sans autre modifications particulières. Il est rappelé ici que l'opération appelée fence vise à « tuer » un équipement considéré défaillant afin de l'inhiber pour qu'aucune des ressources de cet équipement ne réponde à des sollicitations. Il en résulte que le système à haute disponibilité associé (centralisé ou non) détecte que l'ensemble des ressources de l'équipement considéré défaillant ne répond plus et, par conséquent, migre ces ressources sur des équipements opérationnels, typiquement des équipements opérationnels du groupe d'équipements à haute disponibilité auquel appartient l'équipement considéré défaillant. En d'autres termes, cette opération vise à « tuer » l'équipement défaillant de telle sorte qu'il ne soit plus pris en compte par les équipements opérationnels et que ses ressources soient migrées sur ces derniers.
Comme décrit précédemment, le groupe dédié de gestion de la haute disponibilité est lui-même un groupe d'équipements à haute disponibilité comprenant au minimum deux équipements ou plus, utilisés, par exemple, selon un mécanisme de décision par quorum. Un double système de surveillance utilisant deux réseaux de communication distincts, c'est-à-dire ici deux réseaux heartbeat, est mis en œuvre. Ce groupe dédié de gestion de la haute disponibilité ne nécessite pas d'élément particulier. En effet, il ne prend en charge que la surveillance des équipements des groupes d'équipements à haute disponibilité, la prise de décision d'exécution ou non des instructions de "fencing" demandées par les groupes d'équipements à haute disponibilité et le traitement des instructions de "fencing" devant être réalisées.
Comme illustré sur la figure 4, chaque équipement du groupe dédié de gestion de la haute disponibilité est connecté à tous les équipements des groupes d'équipements à haute disponibilité par deux réseaux de communication, afin d'assurer la surveillance de tous ces équipements et la redondance d'accès pour cette surveillance (afin d'éviter des points de blocage, appelés SPOF, acronyme de Single Point Of Failure en terminologie anglo- saxonne). Les deux réseaux de communication utilisés peuvent être de même type ou de types différents. Ainsi, par exemple, un premier réseau de communication peut être du type Ethernet et le second du type Inifiniband ou le premier de type Ethernet 1 G et le second du type Ethernet 10G (Ethernet et Infiniband sont des marques).
Une telle implémentation permet ainsi la mise en œuvre centralisée d'une gestion de haute disponibilité de type heartbeat, c'est-à-dire une gestion de type heartbeat de tous les groupes d'équipements à haute disponibilité.
Il est observé ici que si, sur la figure 4, chaque équipement du groupe dédié de gestion de la haute disponibilité est connecté à tous les équipements des groupes d'équipements à haute disponibilité par deux réseaux de communication, afin d'assurer la surveillance de tous ces équipements, il suffit qu'au moins deux équipements du groupe dédié de gestion de la haute disponibilité soient connectés à tous les équipements des groupes d'équipements à haute disponibilité. En outre, il est possible d'utiliser plus de deux réseaux de communication pour surveiller tous les équipements des groupes d'équipements à haute disponibilité.
La figure 5a illustre des étapes d'un premier exemple d'algorithme pour gérer la haute disponibilité de groupes d'équipements à haute disponibilité conformément à l'invention à partir d'un équipement d'un groupe dédié à la gestion de la haute disponibilité.
Comme illustré, une première étape (étape 500) consiste en une initialisation de l'algorithme. Cette étape vise, en particulier, l'initialisation de compteurs utilisés pour identifier une panne d'un équipement. A ces fins, un compteur noté Timenj est associé à chaque d'équipement j de chaque groupe i d'équipements à haute disponibilité. Ces compteurs sont initialisés à la valeur zéro durant la phase d'initialisation. Ces compteurs sont automatiquement incrémentés au cours du temps, par exemple de la valeur un toutes les n ms.
Une étape suivante (étape 505) consiste à recevoir des indications de fonctionnement d'équipements de groupes d'équipements à haute disponibilité. Les indications de fonctionnement sont de type heartbeat. Ainsi, la réception d'une indication de fonctionnement d'un équipement j d'un groupe /' d'équipements à haute disponibilité, notée HBjj, permet d'établir que cet équipement fonctionne correctement à l'instant présent. Le compteur correspondant à l'équipement duquel est reçue une notification de fonctionnement, c'est-à-dire ici le compteur Timenj associé à l'équipement j du groupe / d'équipements à haute disponibilité, est réinitialisé à la valeur zéro (étape 510).
Comme représenté, ces deux étapes sont répétées pour chaque indication de fonctionnement reçue.
Parallèlement, un test est effectué (étape 515) pour déterminer s'il existe un compteur associé à un équipement d'un groupe d'équipements à haute disponibilité ayant une valeur supérieure à un seuil Θ prédéterminé, indiquant une panne de l'équipement correspondant. Dans la négative, l'algorithme reboucle sur lui-même.
S'il existe un compteur associé à un équipement / d'un groupe k d'équipements à haute disponibilité dont la valeur est supérieure au seuil Θ, des variables m et n sont initialisées à la valeur zéro (étape 520). La variable m représente ici un index d'équipement dans un groupe d'équipements à haute disponibilité tandis que la variable n a pour objet d'indiquer le nombre d'équipements opérationnels dans ce groupe.
Il est observé que l'équipement / du groupe k est un équipement, par exemple un nœud, qui ne transmet plus correctement son heartbeat (conformément au processus permettant de vérifier que l'équipement est opérationnel et accessible) à des équipements du groupe dédié de gestion de la haute disponibilité. Dans ce cas, il convient donc de déterminer quels sont les équipements opérationnels appartenant au même groupe d'équipements de haute disponibilité que l'équipement défaillant afin de réorganiser les ressources.
A ces fins, un test est exécuté (étape 525) pour comparer la valeur du compteur Timerk m associé à l'équipement m du groupe k au seuil Θ. Si la valeur du compteur T\ er m associé à l'équipement m du groupe k est inférieure au seuil Θ, l'équipement m du groupe / est opérationnel. L'index m est alors mémorisé et la variable n est incrémentée de un (étape 530).
Si la valeur du compteur Timerk m associé à l'équipement m du groupe k est supérieure ou égale au seuil 6> ou après avoir mémorisé l'index m et incrémenté la variable n, l'index m est incrémenté de un (étape 535) et un test est effectué (étape 540) pour déterminer si la valeur de l'index m est supérieure ou égale à une valeur mmax représentant le nombre d'équipement dans le groupe k. Dans la négative, les étapes précédentes référencées 525 à 540 sont répétées.
Si, au contraire, la valeur de l'index m est supérieure ou égale à une valeur mmax, un autre test est effectué (étape 545) pour déterminer s'il existe des équipements opérationnels dans le groupe k, c'est-à-dire si la variable n est supérieure à zéro.
Si aucun des équipements du groupe k n'est opérationnel, c'est-à- dire si la valeur de la variable n est nulle, aucune solution standard de haute disponibilité ne peut être envisagée car il n'est pas possible de migrer les ressources de l'équipement défaillant vers un autre équipement du même groupe de haute disponibilité. Cependant, dans ce cas, il peut être possible, comme décrit ci-après, si l'architecture de l'infrastructure informatique le permet, de migrer toutes les ressources associées au groupe k, dans lequel une défaillance a été détectée et dont aucun équipement ne répond, vers des équipements d'un autre groupe d'équipements à haute disponibilité (étape 550).
Au contraire, s'il existe au moins un équipement opérationnel dans le groupe k, c'est-à-dire si la valeur de la variable n est supérieure ou égale à un, un équipement du groupe dédié de gestion de la haute disponibilité émet une instruction de fence à destination des équipements opérationnels de ce groupe pour « tuer » l'équipement défaillant afin de redistribuer les ressources qui lui étaient affectées et qu'il ne soit plus pris en compte par les équipements opérationnels (étape 555). En outre, cet équipement du groupe dédié de gestion de la haute disponibilité informe les équipements opérationnels du groupe k que l'opération de fence s'est bien déroulée. Le transfert des ressources, typiquement de services et de paramètres associés, entre l'équipement défaillant et les équipements opérationnels est réalisé par ces derniers, de façon standard.
L'implémentation de cette opération peut être réalisée, par exemple, via le réseau de communication utilisé, au niveau du système d'exploitation ou au niveau BMC/IPMI (sigles de Baseboard Management Controller et d'Intelligent Platform Management Interface en terminologie anglo-saxonne), ou via une gestion électrique pouvant utiliser un PDU (sigle de Power Distribution Unit en terminologie anglo-saxonne) contrôlable.
Comme illustré, l'algorithme reboucle alors sur lui-même pour traiter, le cas échéant, d'autres défaillances.
Les figures 5b et 5c illustrent des étapes d'un second exemple d'algorithme pour gérer la haute disponibilité de groupes d'équipements à haute disponibilité conformément à l'invention à partir d'un équipement d'un groupe dédié à la gestion de la haute disponibilité. Les étapes représentées sur la figure 5b sont ici mises en œuvre dans des équipements d'un groupe d'équipements à haute disponibilité tandis que les étapes représentées sur la figure 5c sont mises en œuvre dans un équipement d'un groupe d'équipements dédié à la gestion de la haute disponibilité.
Comme illustré, une première étape (étape 500') consiste en une initialisation qui vise, en particulier, l'initialisation de compteurs utilisés pour identifier une panne d'un équipement. A ces fins, un compteur noté Timerj est associé à chaque équipement j du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en œuvre l'algorithme, à l'exception de ce dernier. Ces compteurs sont initialisés à la valeur zéro durant la phase d'initialisation. Ils sont automatiquement incrémentés au cours du temps, par exemple de la valeur un toutes les n ms.
Une étape suivante (étape 505') consiste à recevoir des indications de fonctionnement d'équipements du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en œuvre l'algorithme. Les indications de fonctionnement sont de type heartbeat. Ainsi, la réception d'une indication de fonctionnement d'un équipement j, notée HBj, permet d'établir que cet équipement fonctionne correctement à l'instant présent.
Le compteur correspondant à l'équipement duquel est reçue une notification de fonctionnement, c'est-à-dire ici le compteur Timerj associé à l'équipement j, est réinitialisé à la valeur zéro (étape 510'). Comme représenté, ces deux étapes sont répétées pour chaque indication de fonctionnement reçue.
Parallèlement, un test est effectué (étape 515') pour déterminer s'il existe un compteur associé à un équipement du groupe d'équipements à haute disponibilité, auquel appartient l'équipement mettant en uvre l'algorithme, ayant une valeur supérieure à un seuil Θ prédéterminé, indiquant une panne de l'équipement correspondant. Dans la négative, l'algorithme reboucle sur lui- même.
S'il existe un compteur associé à un équipement / du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en oeuvre l'algorithme dont la valeur est supérieure au seuil Θ, une notification de fence est adressée aux équipements du groupe d'équipements dédié à la gestion de la haute disponibilité du groupe auquel appartient l'équipement mettant en œuvre l'algorithme (étape 555').
Il est noté ici que l'équipement / est un équipement, par exemple un nœud, qui ne transmet plus correctement son heartbeat (conformément au processus permettant de vérifier que l'équipement est opérationnel et accessible) aux équipements de son groupe d'équipements à haute disponibilité. Dans ce cas, une notification de fence est transmise à des équipements d'un groupe d'équipements dédié à la gestion de la haute disponibilité. Ce dernier ayant une vue globale des équipements du groupe à haute disponibilité comprenant l'équipement considéré défaillant peut déterminer s'il convient d'effectuer une opération de fence ou non.
L'algorithme mis en œuvre dans des équipements d'un groupe d'équipements dédié à la gestion de la haute disponibilité, illustré sur la figure 5c, comprend une première étape d'initialisation (étape 560) au cours de laquelle est initialisée une variable Nb_nœud_op, pour chaque groupe d'équipements à haute disponibilité contrôlé par le groupe d'équipements dédié à la gestion de la haute disponibilité auquel appartient l'équipement mettant en œuvre l'algorithme. Cette variable correspond au nombre d'équipements opérationnels dans le groupe correspondant lorsque l'algorithme est lancé. Dans une étape suivante (étape 565), un test est effectué pour déterminer si une notification de fence a été reçue d'un équipement d'un groupe k d'équipements à haute disponibilité. Dans la négative, l'algorithme boucle sur lui-même, comme illustré.
Si, au contraire, une notification de fence a été reçue, un test est effectué (étape 570) pour déterminer si le nombre d'équipements opérationnels du groupe k d'équipements à haute disponibilité, noté Nb_nœud_opk est supérieur à un, c'est-à-dire si, outre l'équipement considéré défaillant, il y a au moins un équipement susceptible de mettre en uvre les ressources précédemment mises en œuvre par l'équipement considéré défaillant. Ce test vise également à vérifier que des conditions liées au groupe d'équipements à haute disponibilité auquel appartient l'équipement considéré défaillant sont remplies pour réaliser une opération de fence.
Dans l'affirmative, une instruction de fence est transmise à l'équipement considéré défaillant (étape 575). Un test est ensuite effectué pour vérifier que l'opération de fence a été correctement effectuée (étape 580). Si l'opération de fence a été correctement effectuée, la valeur de la variable Nb_nœud_opk est décrémentée de un (étape 585) et un message de confirmation est adressé aux équipements opérationnels du groupe d'équipements à haute disponibilité auquel appartient l'équipement considéré défaillant (étape 590) pour permettre la migration des ressources mises en œuvre par l'équipement considéré défaillant, typiquement de services et de paramètres associés. L'algorithme reboucle alors sur lui-même, comme illustré, pour traiter, le cas échéant, d'autres opérations de fence.
Si, au contraire, le nombre d'équipements opérationnels du groupe k d'équipements à haute disponibilité est inférieur ou égal à un, un message d'erreur est, de préférence, généré (étape 595). A nouveau, l'algorithme reboucle sur lui-même, comme illustré, pour traiter, le cas échéant, d'autres opérations de fence.
Comme décrit précédemment, les équipements des groupes d'équipements à haute disponibilité sont chacun interconnectés avec chaque équipement du groupe d'équipements dédié à la gestion de la haute disponibilité par au moins deux réseaux de communication indépendants et fiables. Ces deux réseaux sont physiquement séparés (ils utilisent des commutateurs différents) pour tous les groupes d'équipements à haute disponibilité.
Il est observé ici que les équipements du groupe d'équipements dédié à la gestion de la haute disponibilité doivent être robustes et avoir une configuration conforme à la réalité physique et logique de l'infrastructure globale de l'infrastructure informatique.
La figure 6, comprenant les figures 6a à 6d, illustre un scénario de gestion de panne dans une partie d'une infrastructure informatique comprenant un mécanisme centralisé de gestion de haute disponibilité conforme à l'invention.
La figure 6a illustre schématiquement l'architecture d'une partie d'une infrastructure informatique comprenant ici trois groupes d'équipements à haute disponibilité dont l'un est utilisé pour gérer de façon externe et centralisée la gestion de haute disponibilité.
La partie illustrée de l'infrastructure informatique comprend ici deux groupes d'équipements fonctionnels référencés 600-0 et 600-1 , chacun de ces groupes comprenant, dans cet exemple, quatre nœuds. Ainsi, le groupe 600-0 comprend les quatre nœuds 605-00 à 605-03 tandis que le groupe 600-1 comprend les quatre nœuds 605-10 à 605-13.
Chaque nœud de chaque groupe de nœuds 600-0 et 600-1 est connecté à un nœud d'un groupe de nœuds 610 dédié à la gestion de la haute disponibilité via des commutateurs référencés 615-0 et 615-1 , par exemple des commutateurs Ethernet. Comme illustré, le groupe de nœuds 610 dédié à la gestion de la haute disponibilité comprend ici trois nœuds référencés 620-0 à 620-2. Ainsi, comme illustré, chaque nœud de chaque groupe de nœuds 600-0 et 600-1 est doublement connecté à un nœud du groupe de nœuds 610 dédié à la gestion de la haute disponibilité via deux réseaux de communication différents (utilisant des commutateurs différents).
A titre d'illustration, les groupes de nœuds 600-0 et 600-1 sont ici dédiés à la gestion d'un système de fichiers de type Lustre mettant en œuvre des serveurs de stockage d'objets (OSS, sigle d'Object Storage Server en terminologie anglo-saxonne) pour stocker des données dans des cibles de stockage d'objets (OST, sigle d'Object Storage Target en terminologie anglo- saxonne) gérant des systèmes de fichiers de disques locaux.
Toujours à titre d'illustration, il est supposé qu'une défaillance intervient dans le nœud 605-01 , comme représenté par la plus grande croix en trait gras sur la figure 6b. Du fait de cette défaillance, aucune notification de fonctionnement (heartbeat) n'est adressée aux nœuds du groupe 610 dédié à la gestion de la haute disponibilité, comme représenté par les deux plus petites croix en trait gras sur la figure 6b.
Ainsi, en utilisant un algorithme tel que ceux décrits en référence à la figure 5, les nœuds du groupe 610 dédié à la gestion de la haute disponibilité détectent la défaillance du nœud 605-01 (directement ou via une notification de fence reçue des nœuds opérationnels du groupe dans lequel la défaillance a été détectée, c'est-à-dire des nœuds 605-00, 605-02 et 605-03). Ils adressent alors une instruction de type fence au nœud 605-01. Ce dernier est alors « tué » afin que les autres nœuds du groupe soient informés de la défaillance par le groupe dédié à la gestion de la haute disponibilité (représenté sur la figure 6b par des flèches droites en trait gras) et puissent migrer les ressources allouées au nœud 605-01 vers un ou plusieurs nœuds opérationnels du groupe (représenté sur la figure 6b par des flèches courbes en trait gras).
La figure 6c illustre la configuration des groupes d'équipements 600- 0, 600-1 et 610 après que les ressources allouées au nœud 605-01 aient été réparties sur les nœuds 605-00, 605-02 et 605-03.
Il est observé ici que le mécanisme de gestion centralisé de la haute disponibilité est capable de gérer les pannes multiples. Ainsi, par exemple, si le nœud 605-00 connaît à son tour une défaillance, comme illustré sur la figure 6d, les ressources qu'il gère sont transférées sur les nœuds 605-02 et 605-03. Le mécanisme de gestion de panne multiple est facile à mettre en œuvre du fait que la gestion de la haute disponibilité est centralisée avec une vision d'ensemble de l'état des groupes d'équipements à haute disponibilité du fait qu'il n'est plus nécessaire d'avoir une gestion de quorum dans les groupes d'équipements à haute disponibilité surveillés car la partie décisionnelle est extern a lisée.
En outre, le mécanisme de gestion centralisé de la haute disponibilité permet une bascule entre groupes, c'est-à-dire un transfert de services entre des nœuds de groupes différents.
Lors de la détection de défaillances, l'identification d'une solution est avantageusement réalisée en deux temps. Tout d'abord, une analyse est effectuée au niveau du ou des groupes d'équipements à haute disponibilité dans lequel la ou les défaillances ont été détectées pour tenter de trouver une solution à ce niveau, comme décrits précédemment. Si aucune solution n'est identifiée au cours de cette première analyse, une seconde analyse basée sur des mécanismes de haute disponibilité externes aux groupes de haute disponibilité est alors effectuée.
Un tel mode de réalisation est illustré sur la figure 7 qui représente une partie d'une infrastructure informatique comprenant quatre groupes de haute disponibilité référencés 700-0 à 700-4.
Chaque groupe de haute disponibilité comprend ici quatre nœuds et trois commutateurs (deux nœuds étant connectés de façon distincte à deux commutateurs et deux autres nœuds étant connectés à un même commutateur).
A titre d'illustration, un premier nœud du groupe d'équipements 700- 0 met ici en œuvre les cibles de stockage d'objets OST1 , OST2 et OST3, un deuxième nœud met en œuvre les cibles de stockage d'objets OST4, OST5 et OST6, un troisième nœud met en œuvre les cibles de stockage d'objets OST7, OST8 et OST9 et un quatrième nœud met ici en œuvre les cibles de stockage d'objets OST10, OST11 et OST12.
Les équipements de chaque groupe d'équipements à haute disponibilité sont avantageusement répartis en groupes de haute disponibilité selon plusieurs niveaux internes. Ainsi, par exemple, un premier niveau de haute disponibilité interne est associé au groupe 700-0 tandis qu'un second niveau interne est associé aux groupes 705-00 et 705-01 qui comprennent ici chacun deux nœuds du groupe 700-0, comme illustré. Les équipements des groupes 700-1 , 700-2 et 700-3 sont répartis par groupes de haute disponibilité selon plusieurs niveaux internes, de façon similaire.
Par convention, le second niveau de haute disponibilité a ici une valeur supérieure à celle du premier niveau de haute disponibilité. Lorsqu'une solution de haute disponibilité est recherchée au sein d'un groupe d'équipements à haute disponibilité, une solution est cherchée pour le niveau le plus faible. Si aucune solution n'est trouvée pour ce niveau, une solution est cherchée pour le niveau supérieur et ainsi de suite.
Comme illustrés, des équipements sont communs à plusieurs groupes de niveaux différents (chaque groupe HA d'un niveau comprend des équipements d'un groupe HA d'un niveau inférieur). Par exemple, des commutateurs appartiennent au groupe 700-0 de premier niveau et au groupe 705-01 de second niveau. En outre, des équipements sont communs à plusieurs groupes de même niveau. Par exemple, un commutateur du groupe 700-0 appartient aux deux groupes 705-00 et 705-01 de second niveau.
Les groupes de haute disponibilité 700-0 et 700-1 correspondent ici à un premier système de fichiers tandis que les groupes de haute disponibilité 700-2 et 700-3 correspondent ici à un second système de fichiers.
Les groupes de haute disponibilité 700-0 et 700-1 sont regroupés pour former une première cellule de haute disponibilité. Un premier niveau de haute disponibilité externe référencé 710-0 est associé aux éléments de cette cellule.
De façon similaire, les groupes de haute disponibilité 700-2 et 700-3 sont regroupés pour former une seconde cellule de haute disponibilité à laquelle est également associé un premier niveau de haute disponibilité externe (710-1), deux niveaux de haute disponibilité étant également associés à chaque élément de la cellule comme représenté.
Il est observé ici que si les cellules ne comprennent ici que deux groupes de haute disponibilité, le nombre de groupes n'est pas limité à deux.
Un second niveau de haute disponibilité externe (non représenté) est ici associé à l'ensemble des équipements des deux cellules. Chaque groupe de haute disponibilité est relié à deux noeuds 720-0 et 720-1 d'un groupe 715 d'équipements dédié à la gestion de la haute disponibilité (et formant un autre groupe de haute disponibilité). Les nœuds 720-0 et 720-1 permettent ainsi de transférer des services exécutés par des nœuds d'un groupe de haute disponibilité vers un ou plusieurs autres nœuds du même groupe de haute disponibilité selon un niveau de haute disponibilité interne ou vers des nœuds d'un (ou plusieurs) autre groupe de haute disponibilité de la même cellule ou d'une autre cellule selon un niveau de haute disponibilité externe.
La figure 8 illustre la mise en œuvre de mécanismes de haute disponibilité, conformément à l'invention, lorsqu'une panne du réseau de communication 800 reliant les commutateurs du groupe de haute disponibilité 700-0 et les nœuds 720-0 et 720-1 est détectée (représentée par la croix en trait plein).
Dans cette configuration de panne, il n'existe pas de solution basée sur les mécanismes de haute disponibilité liés aux niveaux de haute disponibilité interne (c'est-à-dire aux groupes 700-0, 705-00 et 705-01). En effet, la panne du réseau de communication 800 reliant les commutateurs du groupe de haute disponibilité 700-0 et les nœuds 720-0 et 720-1 engendre une panne multiple dans les groupes de haute disponibilité correspondant aux groupes 700-0, 705-00 et 705-01 (représentée par les croix en trait pointillé).
Par contre, il existe une solution liée à la cellule 710-0 consistant à transférer les services mis en œuvre dans les nœuds du groupe de haute disponibilité 700-0 (service OST1 à OST12) vers des nœuds du groupe de haute disponibilité 700-1 comme représenté par la flèche 805.
Il est observé ici que si aucune solution n'avait été trouvée dans la cellule 710-0, une solution aurait consisté à chercher dans la cellule dont le niveau de haute disponibilité externe est directement supérieur au précédent (lié à la cellule 710-0), c'est-à-dire ici la cellule comprenant les cellules 710-0 et 710-1.
Il est noté ici que si, pour des raisons d'illustration, la description qui précède vise la gestion de pannes dans des équipements tels que des nœuds, l'invention n'est pas limitée aux nœuds mais peut être mise en œuvre avec d'autres ressources d'une infrastructure informatique telle qu'un cluster ou un centre de traitement de données (généralement appelé data centre), notamment des commutateurs. De même, bien que la description vise essentiellement les services mis en œuvre sur les nœuds, l'invention peut également concerner des processus applicatifs ainsi que des contrôleurs d'équipements, par exemple des contrôleurs de stockage et des contrôleurs de réseau, dans lesquels peuvent être implémentés des modules logiciels permettant la gestion de la haute disponibilité selon plusieurs niveaux.
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 une infrastructure informatique comprenant une pluralité d'équipements (405) dont au moins un ensemble forme au moins un groupe (400) d'équipements à haute disponibilité selon lequel des services gérés par un équipement dudit au moins un groupe d'équipements à haute disponibilité sont transférés à au moins un autre équipement dudit groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, le procédé comprenant une étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance, ce procédé étant caractérisé en ce que ledit procédé est au moins partiellement mis en uvre dans au moins un équipement de gestion de haute disponibilité, ledit au moins un équipement de gestion de haute disponibilité étant un équipement dudit cluster, distinct des équipements dudit ensemble d'équipements formant ledit au moins un groupe d'équipements à haute disponibilité, et appartenant à un groupe d'équipements à haute disponibilité dédié à la gestion de la haute disponibilité, distinct dudit au moins un groupe d'équipements à haute disponibilité.
2. Procédé selon la revendication 1 selon lequel ladite étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance comprend une étape de réception (505, 505') d'une indication de fonctionnement de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité, ladite étape de réception d'une indication de fonctionnement étant mise en œuvre dans ledit au moins un équipement de gestion de haute disponibilité ou dans au moins un équipement dudit au moins un groupe d'équipements à haute disponibilité.
3. Procédé selon la revendication 2 selon lequel un équipement est considéré comme défaillant (515, 515') en l'absence de réception d'une indication de fonctionnement de cet équipement durant un intervalle de temps prédéterminé.
4. Procédé selon la revendication 2 ou la revendication 3 comprenant en outre une étape de réception (565) d'une notification visant l'arrêt d'un équipement considéré défaillant.
5. Procédé selon la revendication 4 comprenant en outre une étape de vérification (570) d'au moins une condition liée à un ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, une étape de transfert de services entre un équipement considéré défaillant et un autre équipement dudit au moins un groupe d'équipements à haute disponibilité étant effectuée en réponse à ladite étape de vérification.
6. Procédé selon l'une quelconque des revendications 2 à 5 comprenant en outre une étape d'identification (540) d'au moins un équipement opérationnel dudit au moins un groupe d'équipements à haute disponibilité, lesdits services gérés par ledit équipement considéré défaillant étant transférés audit au moins un équipement opérationnel.
7. Procédé selon la revendication 6 comprenant en outre une étape de sélection d'au moins un équipement opérationnel parmi un ou des équipements opérationnels identifiés, ladite sélection étant basée sur des niveaux de haute disponibilité associés à des groupes d'équipements à haute disponibilité auxquels appartient ledit au moins un équipement opérationnel identifié.
8. Procédé selon la revendication 6 ou la revendication 7 comprenant en outre une étape de transfert desdits services gérés par ledit équipement considéré défaillant vers au moins un équipement d'un second groupe d'équipements à haute disponibilité, ledit au moins un groupe d'équipements à haute disponibilité étant appelé au moins un premier groupe d'équipements à haute disponibilité, lorsqu'aucun équipement opérationnel n'est identifié dans ledit au moins un premier groupe d'équipements à haute disponibilité.
9. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite étape de transfert desdits services gérés par ledit équipement considéré défaillant est mise en oeuvre au moins partiellement par au moins un équipement vers lequel au moins un desdits services est transféré.
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.
11. Dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 9.
PCT/FR2012/052732 2011-12-13 2012-11-27 Procédé et programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité Ceased WO2013088020A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1161584 2011-12-13
FR1161584A FR2984054B1 (fr) 2011-12-13 2011-12-13 Procede et programme d'ordinateur de gestion externalisee et centralisee de pannes dans un cluster comprenant des equipements a haute disponibilite

Publications (1)

Publication Number Publication Date
WO2013088020A1 true WO2013088020A1 (fr) 2013-06-20

Family

ID=47436079

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052732 Ceased WO2013088020A1 (fr) 2011-12-13 2012-11-27 Procédé et programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité

Country Status (2)

Country Link
FR (1) FR2984054B1 (fr)
WO (1) WO2013088020A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106603722A (zh) * 2017-01-22 2017-04-26 杭州迪普科技股份有限公司 一种管理设备的确定方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7076691B1 (en) * 2002-06-14 2006-07-11 Emc Corporation Robust indication processing failure mode handling
US20090252047A1 (en) * 2008-04-02 2009-10-08 International Business Machines Corporation Detection of an unresponsive application in a high availability system
US20110022882A1 (en) * 2009-07-21 2011-01-27 International Business Machines Corporation Dynamic Updating of Failover Policies for Increased Application Availability

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7076691B1 (en) * 2002-06-14 2006-07-11 Emc Corporation Robust indication processing failure mode handling
US20090252047A1 (en) * 2008-04-02 2009-10-08 International Business Machines Corporation Detection of an unresponsive application in a high availability system
US20110022882A1 (en) * 2009-07-21 2011-01-27 International Business Machines Corporation Dynamic Updating of Failover Policies for Increased Application Availability

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106603722A (zh) * 2017-01-22 2017-04-26 杭州迪普科技股份有限公司 一种管理设备的确定方法及装置
CN106603722B (zh) * 2017-01-22 2020-06-09 杭州迪普科技股份有限公司 一种管理设备的确定方法及装置

Also Published As

Publication number Publication date
FR2984054A1 (fr) 2013-06-14
FR2984054B1 (fr) 2015-10-02

Similar Documents

Publication Publication Date Title
US9239749B2 (en) Network fault detection and reconfiguration
US9087005B2 (en) Increasing resiliency of a distributed computing system through lifeboat monitoring
FR3025333A1 (fr) Serveur comprenant une pluralite de modules
CN108173911A (zh) 一种微服务故障检测处理方法及装置
EP3189636B1 (fr) Procédé de surveillance et d'alerte de configuration de routage dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé
US20200310899A1 (en) Method for retrieving metadata from clusters of computing nodes with containers based on application dependencies
EP2454850A1 (fr) Procede et systeme pour la gestion performante et automatisee de reseaux virtuels.
EP2149823A1 (fr) Système aéronautique embarqué à reconfiguration dynamique, procédé associé et aéronef embarquant un tel système
WO2021152262A1 (fr) Procede de surveillance de donnees echangees sur un reseau et dispositif de detection d'intrusions
WO2017025203A1 (fr) Gestion de cycle de vie d'un contenant de logiciel
WO2019115173A1 (fr) Dispositif et procede de controle de sondes permettant la detection d'intrusions sur un reseau
WO2015033049A1 (fr) Moyens de protection pour systèmes informatiques industriels
EP2751959B1 (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é
WO2013088020A1 (fr) Procédé et programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité
US9930140B2 (en) Tie-breaking for high availability clusters
WO2013088019A1 (fr) Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité
EP4074011B1 (fr) Plateforme de gestions de micro services concernant la gestion d'une batterie
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
EP3216170B1 (fr) Procédé de reconfiguration rapide d'un routage sur panne d'un port d'un commutateur
EP2729874B1 (fr) Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration
EP2799994A1 (fr) Procédé et dispositif de sauvegarde de données dans une infrastructure informatique offrant des fonctions de reprise d'activité
WO2013127660A1 (fr) Réseau de dispositifs formant un système de diagnostic
US20250130899A1 (en) Method to detect boot failure of peer compute node
FR2978262A1 (fr) Procede, programme d'ordinateur et dispositif d'aide au deploiement de clusters

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

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

Country of ref document: EP

Kind code of ref document: A1