WO2013088019A1 - Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité - Google Patents

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

Info

Publication number
WO2013088019A1
WO2013088019A1 PCT/FR2012/052731 FR2012052731W WO2013088019A1 WO 2013088019 A1 WO2013088019 A1 WO 2013088019A1 FR 2012052731 W FR2012052731 W FR 2012052731W WO 2013088019 A1 WO2013088019 A1 WO 2013088019A1
Authority
WO
WIPO (PCT)
Prior art keywords
equipment
high availability
groups
group
level
Prior art date
Application number
PCT/FR2012/052731
Other languages
English (en)
Inventor
Jean-Olivier GERPHAGNON
Alain MOULLE
Philippe Couvee
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 WO2013088019A1 publication Critical patent/WO2013088019A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error 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/202Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error 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/202Error 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/2023Failover techniques
    • G06F11/2028Failover techniques eliminating a faulty processor or activating a spare
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error 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/202Error 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/2023Failover techniques
    • G06F11/203Failover techniques using migration

Definitions

  • the present invention relates to the administration of computer infrastructures such as clusters and data centers and more. particularly a method and a computer program for managing multiple failures, including double failures, in a computing infrastructure including high availability equipment.
  • High Performance Computing also known as High Performance Computing (HPC)
  • HPC High Performance Computing
  • HPC High Performance Computing
  • modeling and simulation make it possible to reduce development costs and speed up the launch of innovative, more reliable and less energy-consuming products.
  • high performance computing has become an indispensable means of investigation.
  • a cluster typically includes a set of interconnected nodes. Some nodes are used to perform compute tasks (compute nodes), others to store data (storage nodes), and one or more others manage the cluster (administration nodes). Each node is for example a server implementing an operating system such as Linux (Linux is a brand). The connection between the nodes is, for example, carried out using Ethernet communication links and interconnection networks (for example Infiniband) (Ethernet and Infiniband are trademarks).
  • Ethernet communication links and interconnection networks for example Infiniband
  • Figure 1 schematically illustrates an example of a topology 00 of a cluster, type fat-tree.
  • the latter includes a set of nodes
  • the nodes belonging to the set 110 are here computation nodes while the nodes of the set 115 are service nodes (storage nodes and administration nodes).
  • the calculation nodes can be grouped into subsets 120 called calculation islands, the set 115 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. When setting under power, the program or programs that are stored in a non-volatile memory, for example a hard disk, are transferred into the RAM 206.
  • a high availability system covers a type of faults commonly referred to as "simple faults" in which a single equipment fails at a given time. So-called “multiple” failures, or simultaneous failures, are much more complex to manage because the number of cases to be processed increases exponentially with the number of devices.
  • 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 part 300 of a cluster comprising high availability equipment, here four nodes referenced 305-0 to 305-3, and three switches. referenced 310-0 to 310-2 connected to a network of As shown, 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 and the node 305-3 is connected to the 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 switch 310-0 is faulty, the node 305-0 is no longer visible nodes 305-1, 305-2 and 305-3. 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. nodes 305-1, 305-2 and 305-3 as well as associated parameters such as IP addresses (as illustrated by the arrows).
  • a service switch implemented by this node is automatically performed to transfer these services to one or more functional nodes.
  • Figure 3c illustrates the limitations of the high availability principle.
  • the nodes 305-1 and 305-2 here share the same switch 310-1, for example for reasons of cost or architecture. Therefore, the failure of the switch 310-1 (represented by a solid line cross in FIG. 3c) causes the detection of a double fault since each of the nodes 305-1 and 305-2 becomes isolated (represented by a cross in FIG. dashed line in Figure 3c).
  • the nodes 305-1 and 305-2 are no longer visible nodes 305-0 and 305-3 which then consider the nodes 305-1 and 305-2 as faulty.
  • Such a configuration is generally not managed by the high availability mechanisms implemented in the nodes.
  • these mechanisms consist of a fault configuration list and a corresponding adaptation list, forming a solution.
  • These lists being exhaustive, they can not aim at all the possible configurations of faults and if it is possible to manage all the simple faults, it is impossible, in practice, to manage the doubles of faults in this way.
  • a hardware solution is to add a switch to ensure that each node has a switch of its own.
  • a switch may not be possible, especially for reasons of cost and / or architecture.
  • 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, at least one of which forms at least one group.
  • high availability equipment in which services managed by a device of said at least one group of high availability equipment are transferred to at least one other device of said at least one group of high availability equipment when said equipment is considered to be defective a first level of high availability being associated with said at least one group of high availability equipment, a plurality of subsets of said set of equipment of said at least one group of high availability equipment, called first group of equipment with high availability, forming a plurality of second groups of high availability equipment, a second high availability level being associated with said second groups of high availability equipment and the method comprising the following steps,
  • the method according to the invention thus makes it possible to provide high availability solutions to IT infrastructures when multiple failures are identified without requiring the addition of particular equipment generating significant costs.
  • said step of seeking a high availability solution in high availability equipment groups. associated with said second high availability level and including the at least one failed equipment is recursively applied to high availability equipment groups having a high availability level higher than the level previously used for the search. of a solution and comprising said at least one faulty equipment.
  • the method according to the invention thus makes it possible to find solutions of high availability for numerous configurations of computer infrastructures and / or multiple failures varied.
  • the method preferably further comprises a step of transferring at least one service implemented in said at least one failed equipment to at least one targeted device in an identified solution to ensure a high availability function of the device. 'Informatique infrastructure.
  • said step of searching for a high availability solution in groups of high availability equipment with which said second level of high availability is associated and comprising said at least one faulty equipment item comprises a step of changing the Execution environment for at least one service of at least one equipment of said at least one first group of high availability equipment.
  • said process steps are implemented by equipment of said at least one first group of equipment with high availability without the need to use special equipment.
  • said IT infrastructure comprises at least two first groups of high availability and, when at least one equipment of said at least two first groups of high availability equipment is faulty and no solution has has been identified in the first group of high availability equipment comprising the faulty equipment or in groups of high availability equipment with which said second level of high availability is associated and comprising said at least one faulty equipment, the method further comprises a step of identifying at least a first group of high availability equipment among said at least two groups of high availability equipment, distinct from the first group of high availability equipment comprising said at least one failed equipment, adapted to receive services executed by equipment of said first group of equipment. high availability equipment comprising said at least one failed equipment and forming a high availability solution.
  • the method according to the invention thus makes it possible to improve a high availability function of the IT infrastructure.
  • said step of identifying at least a first group of high availability equipment among said at least two groups of high availability equipment, adapted to receive services executed by equipment of said first a group of high availability equipment comprising said at least one faulty equipment and forming a high availability solution is implemented in equipment separate from said at least two first groups of high availability equipment. It is thus possible to use a particular piece of equipment to implement certain stages of the invention in order to limit the load of equipment of groups of equipment with high availability.
  • a faulty equipment is typically a broken down equipment or a piece of equipment considered to be inoperative because of other equipment that is out of order, said breakdown being able to be hardware and / or software, an equipment that can notably be a node.
  • 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 and a device comprising means adapted to the implementation of each of the steps of the method described above.
  • 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
  • a device comprising means adapted to the implementation of each of the steps of the method described 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, 3b and 3c, schematically represents a part of a computer infrastructure including high availability equipment when all these equipment are functioning correctly, when a fault is detected and when a double fault is detected. , respectively ;
  • FIG. 4 schematically illustrates a portion of a computing infrastructure comprising high availability equipment grouped by high availability groups according to several levels of high availability according to the invention
  • FIG. 5 comprising FIGS. 5a and 5b, illustrates examples of breakdown and double failure, respectively, in the part of the IT infrastructure described with reference to FIG. 4;
  • FIG. 6 illustrates an example of certain steps of an algorithm used in a node to implement 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 communication network is detected in the part of the IT infrastructure shown in FIG. 7.
  • the invention aims to circumvent the limitation according to which so-called high availability systems do not know how to manage two simultaneous failures by defining several levels of monitoring, hereinafter referred to as high availability levels, and by interleaving these levels.
  • Such a solution has a particularly important economic advantage in that it reduces equipment considered as single points of failure (SPOF) by not multiplying the number of equipment but by giving responsibility for failover to an application layer of multiple nested levels.
  • SPOF single points of failure
  • an object storage server implements between two and eight object storage targets.
  • Such part of the IT infrastructure is, for example, similar to that illustrated in FIG.
  • such a piece of computer infrastructure referred to herein as 400, comprises, according to this example, four nodes referenced 405-0 to 405-3 and three switches referenced 410-0 to 410-2. Similar to the portion of the computer infrastructure shown in FIG. 3, the nodes 405-0 and 405-3 are connected to the switches 410-0 and 410-2, respectively, while the nodes 405-1 and 405- 2 are connected to the switch 410-1, the switches 410-0 to 410-2 being interconnected by a communication network 415.
  • the node 405-0 here implements the object storage targets OST1, OST2 and OST3, the node 405-1 implements the object storage targets OST4, OST5 and OST6, the node 405-2 sets up implement the targets of storage of OST7, OST8 and OST9 objects and the node 405-3 here implements the object storage targets OST10, OST11 and OST12.
  • these sets of equipment are divided into high availability groups (HA groups) according to several levels.
  • HA groups high availability groups
  • a first level of high availability is associated with group 420, denoted Grp1_HA level 1, which here comprises all the equipment of part 400 of the IT infrastructure.
  • a second level of high availability is associated with groups 425-0 and 425-1, denoted Grp1_HA level 2 and Grp2_HA level 2, respectively.
  • the second level of high availability has a value here. higher than the first level of high availability.
  • equipment is common to several groups of different levels (each HA group of a level includes equipment of a lower level HA group).
  • switches 410-0 and 410-1 belong to the first level group 420 and the second level group 425-1.
  • equipment is common to several groups of the same level.
  • switch 410-1 belongs to the second-level groups 425-0 and 425-1.
  • the first level in charge of managing the group of equipment concerned makes it possible to detect the simple faults relating to these equipments and to act accordingly by correctly distributing the load of a considered node in breakdown on the remaining nodes.
  • HA groups are used concerned, second-level, including failing devices to identify one or more high-availability groups so that only one failure is detected per identified HA group.
  • a test is performed to determine if it is possible to find a solution to distribute the load of the defective equipment or equipment to other equipment in the group. If yes, this solution is implemented.
  • the high availability groups linked to this high availability group and the directly higher level are selected and for each of them a test is performed to determine if it is possible to find a solution for distributing the load of equipment or equipment failing to other equipment in the group. If so, this solution is implemented and the algorithm continues for the other groups of the same level in which failures were detected. If not, the algorithm continues recursively.
  • an equipment can be considered as failing for hardware or software reasons.
  • a transfer of services is typically performed between different equipment of the same group of equipment with high availability.
  • a node includes a set of multiple NICs and one of them fails, the data that passed through the failed interface (failed NIC) may be redirected to another NIC interface. same node.
  • the services are transferred between different equipments (typically from one node to another) but that in the case of a hardware failure, services can be transferred within the same equipment (previous example of the network card) or to another device.
  • FIG. 5 comprising FIGS. 5a and 5b, illustrates examples of breakdown and double failure, respectively, in the part of the IT infrastructure described with reference to FIG. 4.
  • the switch 410-0 fails, the node 405-0 becomes invisible to the nodes 405-1, 405-2 and 405-3 which then call the high availability mechanism described above.
  • the high availability group with the lowest level ie the group 420 (Grp1_H1 level 1), is thus selected.
  • the group 420 As described with reference to FIG. 3b, there is a standard solution for distributing the load of the node 405-0 considered to be faulty, that is to say here the object storage targets OST1, OST2 and OST3, towards the nodes 405-1 to 405-3. This solution is then implemented.
  • the switch 410-1 fails, the nodes 405-1 and 405-2 become invisible for the nodes 405-0 and 405-3 which then call the high availability mechanism described. previously.
  • the high availability group with the lowest level ie the group 420 (Grp1_H1 level 1), is thus selected.
  • the group 420 (Grp1_H1 level 1), is thus selected.
  • specific high availability software taking into account one or more levels of high availability, may be used.
  • Heartbeat networks are used for each high availability group of each level.
  • the implementation can be done in different ways at the application layer.
  • the native operating system (Operating System OS) of the node can be used to manage the first level of high availability while a virtual system implemented on the node, representing a virtual node (also called virtual OS), can be used to manage a second level of high availability.
  • a virtual system implemented on the node representing a virtual node (also called virtual OS)
  • other virtual systems can be implemented on the node and used to handle other levels of high availability.
  • the services to be migrated with associated parameters when a device is faulty are implemented, within a node, in the system (native or virtual) corresponding to the first level of high availability. Then, when a failure is detected and there is no solution in the first level of high availability, these services and, if applicable, associated parameters, are moved (usually with equipment services down) to the system (native or virtual) corresponding to the high availability level for which a solution exists.
  • Figure 6 illustrates an example of certain steps of an algorithm used in a node to implement the invention.
  • the same high availability management applications are implemented in each of the nodes of a high availability group (of the lowest level). It is therefore not necessary to provide synchronization mechanism between the nodes.
  • a first step (step 600) here consists in initializing a variable called Niv.HA, representative of the current high availability level, to the value 1.
  • a test is performed to determine if one or more faults are detected.
  • This test uses standard mechanisms of the high availability algorithms aiming in particular to check that the nodes of the same group of high availability (initially of the lowest level of high availability) are accessible and / or in a predetermined state.
  • the algorithm loops on itself until at least one failure is detected or the algorithm is terminated.
  • a high availability solution is sought (step 610).
  • a step consists in identifying a predetermined fault configuration in a table or a database 615, for the current high availability level (Lvl.HA), to identify how to distribute the services performed by the failed node (s) to one or more other nodes in the same high availability group of the level current high availability.
  • Lvl.HA current high availability level
  • a test is then performed (step 620) to determine if there is a predetermined solution for the distribution of services performed by the failed node or nodes.
  • step 625 the solution is applied by performing the transfers (step 625), as standard.
  • the algorithm then loops back to step 605 to handle, if necessary, new faults.
  • variable Lv.HA representing the current high availability level
  • a test is then performed to determine if the new value of the Niv.HA variable corresponds to a real high availability level (step 635), that is, if the level of high availability Niv.HA is set.
  • the previous steps 610 to 635) are repeated, as illustrated, to determine if there is a solution in the group of high availability corresponding to the new high availability level.
  • change environment (step 640). Such a change may include moving from one system (native or virtual) to another and, if necessary, transferring the services executed in the initial system to the new system used.
  • the invention can also be implemented for sets of high availability groups, for example high availability groups using the same distributed file system.
  • the invention then makes it possible to rule out the limitation of the number of nodes per high availability group which is generally limited to 2, 4 or 8 storage nodes (OSS), notably because of the number of fiber-type links to the bays. storage, such a constraint having in particular the consequence that the number of high availability groups of storage nodes is, in a cluster, typically between two and several tens.
  • a solution based on a mechanism of high availability by levels allows, via a control system external to the groups of high availability, for example a node itself configured according to a mechanism of high availability, dedicated to the management of these groups, to manage a particular level of high availability allowing 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. First, an analysis using the high availability mechanisms internal to the high availability groups, as previously described, is preferably performed. 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 a computing infrastructure comprising four high availability groups referenced 700-0 to 700-4 such as that described with reference to FIG. 4 (reference 400).
  • 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 705-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 (705-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 attached to two high availability management nodes (forming another high availability group), referenced 710-0 and 710-1, providing the high availability function at the high availability group.
  • Nodes 710-0 and 710-1 thus allow services executed by nodes of a high availability group to be transferred to nodes of one (or more) other high availability group of the same or other cell. cell according to 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 415 connecting the switches of the high availability group 700-0 and the nodes 710-0 and 710-1. is detected (represented by the solid line cross).
  • the invention is not limited to nodes but can be implemented with other resources of a computing infrastructure such as a cluster or a data center (usually called a data center), including switches.
  • a computing infrastructure such as a cluster or a data center (usually called a 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)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

L'invention a notamment pour objet la gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité dont certains forment un premier groupe à haute disponibilité auquel est associé un premier niveau. Des sous-ensembles d'équipements de ce premier groupe forment des second groupes à haute disponibilité auxquels est associé un second niveau. Après avoir détecté (605) une défaillance d'un équipement du premier groupe, une solution de haute disponibilité est recherchée (610) dans des groupes auxquels est associé le premier niveau et comprenant l'équipement défaillant. Si aucune solution n'est identifiée (620), une solution est recherchée (630, 610) dans des groupes auxquels est associé le second niveau et comprenant l'équipement défaillant.

Description

Procédé et programme d'ordinateur de gestion de pannes multiples 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 de pannes multiples, notamment de doubles 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 115 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 115 é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 tombe en panne à un instant donné. Les pannes dites « multiples », ou pannes simultanées, sont beaucoup plus complexes à gérer car le nombre de cas à traiter augmente exponentiellement avec le nombre d'équipements. 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.
A titre d'illustration, la figure 3, comprenant les figures 3a, 3b et 3c, 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. 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 équipement réseau associé à un 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.
La figure 3c illustre les limites du principe de haute disponibilité. Comme décrit précédemment, les nœuds 305-1 et 305-2 partagent ici le même commutateur 310-1 , par exemple pour des raisons de coût ou d'architecture. Par conséquent, la défaillance du commutateur 310-1 (représenté par une croix en trait continu sur la figure 3c) entraîne la détection d'une double panne car chacun des nœuds 305-1 et 305-2 devient isolé (représenté par une croix en trait pointillé sur la figure 3c).
En effet, lorsque le commutateur 310-1 est défaillant, les nœuds 305- 1 et 305-2 ne sont plus visibles des nœuds 305-0 et 305-3 qui considèrent alors les nœuds 305-1 et 305-2 comme défaillants.
Une telle configuration n'est généralement pas gérée par les mécanismes de haute disponibilité mis en œuvre dans les nœuds. Typiquement, ces mécanismes consistent en une liste de configuration de pannes et une liste d'adaptation correspondante, formant une solution. Ces listes étant exhaustives, elles ne peuvent 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.
Une solution matérielle consiste à ajouter un commutateur pour garantir que chaque nœud dispose d'un commutateur qui lui est propre. Cependant, une telle solution peut ne pas être envisageable, notamment pour des raisons de coûts et/ou d'architecture.
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 au moins un groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, un premier niveau de haute disponibilité étant associé audit au moins un groupe d'équipements à haute disponibilité, une pluralité de sous-ensembles dudit ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, appelé premier groupe d'équipements à haute disponibilité, formant une pluralité de second groupes d'équipements à haute disponibilité, un second niveau de haute disponibilité étant associé auxdits seconds groupes d'équipements à haute disponibilité et le procédé comprenant les étapes suivantes,
- détection d'une défaillance d'au moins un équipement dudit ensemble d'équipements ;
- recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit premier niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant ; et,
- si aucune solution de haute disponibilité n'est identifiée dans des groupes d'équipements à haute disponibilité auxquels est associé ledit premier niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant,
o recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant.
Le procédé selon l'invention permet ainsi d'apporter des solutions de haute disponibilité à des infrastructures informatiques lorsque des pannes multiples sont identifiées sans nécessiter l'ajout d'équipements particuliers engendrant des coûts importants.
Da façon avantageuse, ladite étape de recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant est appliquée de façon récursive à des groupes d'équipements à haute disponibilité auxquels est associé un niveau de haute disponibilité de rang supérieur au niveau précédemment utilisé pour la recherche . d'une solution et comprenant ledit au moins un équipement défaillant.
Le procédé selon l'invention permet ainsi de trouver des solutions de hautes disponibilités pour de nombreuses configurations d'infrastructures informatiques et/ou des pannes multiples variées.
Le procédé comprend en outre, de préférence, une étape de transfert d'au moins un service mis en œuvre dans ledit au moins un équipement défaillant vers au moins un équipement visé dans une solution identifiée afin d'assurer une fonction de haute disponibilité de l'infrastructure informatique.
Selon un mode de réalisation particulier, ladite étape de recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant comprend une étape de changement d'environnement d'exécution d'au moins un service d'au moins un équipement dudit au moins un premier groupe d'équipements à haute disponibilité. Le procédé selon l'invention est ainsi facile à mettre en œuvre dans de nombreux environnements en utilisant des technologies dites de virtualisation.
Toujours selon un mode de réalisation particulier, lesdites étapes du procédé sont mises en œuvre par des équipements dudit au moins un premier groupe d'équipements à haute disponibilité sans qu'il soit nécessaire d'utiliser d'équipements particuliers.
Toujours selon un mode de réalisation particulier, ladite infrastructure informatique comprend au moins deux premiers groupes de haute disponibilité et, lorsqu'au moins un équipement desdits au moins deux premiers groupes d'équipements à haute disponibilité est défaillant et qu'aucune solution n'a été identifiée dans le premier groupe d'équipements à haute disponibilité comprenant l'équipement défaillant ni dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant, le procédé comprend en outre une étape d'identification d'au moins un premier groupe d'équipements à haute disponibilité parmi lesdits au moins deux groupes d'équipements à haute disponibilité, distinct du premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant, adapté à recevoir des services exécutés par des équipements dudit premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant et formant une solution de haute disponibilité. Le procédé selon l'invention permet ainsi d'améliorer une fonction de haute disponibilité de l'infrastructure informatique.
Toujours selon un mode de réalisation particulier, ladite étape d'identification d'au moins un premier groupe d'équipements à haute disponibilité parmi lesdits au moins deux groupes d'équipements à haute disponibilité, adapté à recevoir des services exécutés par des équipements dudit premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant et formant une solution de haute disponibilité, est mise en œuvre dans un équipement distinct desdits au moins deux premiers groupes d'équipements à haute disponibilité. Il est ainsi possible d'utiliser un équipement particulier pour mettre en œuvre certaines étapes de l'invention afin de limiter la charge des équipements des groupes d'équipements à haute disponibilité.
Un équipement défaillant est typiquement un équipement en panne ou un équipement considéré en panne du fait d'un autre équipement en panne, ladite panne pouvant être matérielle et/ou logicielle, un équipement pouvant notamment être un nœud.
L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment.
P'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, 3b et 3c, représente schématiquement une partie d'une infrastructure informatique comprenant des équipements à haute disponibilité lorsque tous ces équipements fonctionnent correctement, lorsqu'une panne est détectée et lorsqu'une double panne est détectée, respectivement ;
- la figure 4 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é conformément à l'invention ;
- la figure 5, comprenant les figures 5a et 5b, illustre des exemples de panne et de double panne, respectivement, dans la partie de l'infrastructure informatique décrite en référence à la figure 4 ;
- la figure 6 illustre un exemple de certaines étapes d'un algorithme utilisé dans un nœud pour mettre en œuvre 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 à contourner la limitation selon laquelle les systèmes dits de haute disponibilité ne savent pas gérer deux pannes simultanées en définissant plusieurs niveaux de surveillance, appelés par la suite niveaux de haute disponibilité, et en imbriquant ces niveaux.
Une telle solution présente un avantage économique particulièrement important en ce qu'elle permet de réduire les équipements considérés comme des points uniques de défaillance (SPOF, Single Point Of Failure en terminologie anglo-saxonne) en ne multipliant pas le nombre d'équipements mais en donnant la responsabilité de la reprise sur panne à une couche applicative de plusieurs niveaux imbriqués.
A titre d'illustration, il est ici considéré une partie d'une infrastructure informatique telle qu'un cluster, utilisant un système de fichiers distribué 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. Selon le matériel utilisé, un serveur de stockage d'objets met en œuvre entre deux et huit cibles de stockage d'objets. Une telle partie de infrastructure informatique est, par exemple, similaire à celle illustrée sur la figure 3.
Comme illustré sur la figure 4, une telle partie d'infrastructure informatique, référencée ici 400, comprend, selon cet exemple, quatre nœuds référencés 405-0 à 405-3 et trois commutateurs référencés 410-0 à 410-2. De façon similaire à la partie de l'infrastructure informatique représentée sur la figure 3, les nœuds 405-0 et 405-3 sont connectés aux commutateurs 410-0 et 410-2, respectivement, tandis que les nœuds 405-1 et 405-2 sont connectés au commutateur 410-1, les commutateurs 410-0 à 410-2 étant reliés entre eux par un réseau de communication 415.
Le nœud 405-0 met ici en œuvre les cibles de stockage d'objets OST1 , OST2 et OST3, le nœud 405-1 met en œuvre les cibles de stockage d'objets OST4, OST5 et OST6, le nœud 405-2 met en œuvre les cibles de stockage d'objets OST7, OST8 et OST9 et le nœud 405-3 met ici en œuvre les cibles de stockage d'objets OST10, OST11 et OST12.
Conformément à l'invention, ces ensembles d'équipements sont répartis en groupes de haute disponibilité (groupes HA) selon plusieurs niveaux. Ainsi, selon l'exemple illustré sur la figure 4, un premier niveau de haute disponibilité est associé au groupe 420, noté Grp1_HA niv 1 , qui comprend ici tous les équipements de la partie 400 de l'infrastructure informatique.
De même, un second niveau de haute disponibilité est associé aux groupes 425-0 et 425-1 , notés Grp1_HA niv 2 et Grp2_HA niv 2, respectivement. Par convention, le second niveau de haute disponibilité a ici une valeur. supérieure à celle du premier niveau de haute disponibilité.
Comme illustrés sur la figure 4, 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, les commutateurs 410-0 et 410-1 appartiennent au groupe 420 de premier niveau et au groupe 425-1 de second niveau. En outre, des équipements sont communs à plusieurs groupes de même niveau. Par exemple, le commutateur 410-1 appartient aux groupes 425-0 et 425-1 de second niveau.
L'utilisation de plusieurs groupes de haute disponibilité ayant différents niveaux de haute disponibilité et comprenant des équipements communs permet de gérer facilement des situations de pannes multiples et en particulier de doubles pannes en décomposant l'infrastructure informatique considérée pour permettre le traitement de ces pannes multiples comme de simples pannes.
En effet, le premier niveau en charge de gérer le groupe d'équipements concernés, ici des nœuds, permet de détecter les pannes simples relatives à ces équipements et d'agir en conséquence en répartissant correctement la charge d'un nœud considéré en panne sur les nœuds restants. Lorsque plusieurs pannes sont détectées dans le groupe de haute disponibilité de premier niveau, il est fait appel aux groupes de haute disponibilité concernés, de second niveau, comprenant les équipements défaillants afin d'identifier un ou plusieurs groupes de haute disponibilité de telle sorte qu'une seule panne soit détectée par groupe de haute disponibilité identifié.
Ainsi, en d'autres termes, lorsqu'une ou plusieurs pannes sont détectées dans un groupe de haute disponibilité d'un niveau donné, un test est effectué pour déterminer s'il est possible de trouver une solution pour répartir la charge de l'équipement ou des équipements défaillants aux autres équipements du groupe. Dans l'affirmative, cette solution est mise en œuvre. Au contraire, s'il n'existe pas de solution, les groupes de haute disponibilité liés à ce groupe de haute disponibilité et du niveau directement supérieur sont sélectionnés et, pour chacun d'eux, un test est effectué pour déterminer s'il est possible de trouver une solution pour répartir la charge de l'équipement ou des équipements défaillants aux autres équipements du groupe considéré. Dans l'affirmative, cette solution est mise en œuvre et l'algorithme se poursuit pour les autres groupes de même niveau dans lesquels des pannes ont été détectées. Dans la négative, l'algorithme se poursuit de façon récursive.
Il est rappelé ici qu'un équipement peut être considéré comme défaillant pour des raisons matérielles ou logicielles. Cependant, un transfert de services est typiquement réalisé entre des équipements différents d'un même groupe d'équipements à haute disponibilité. Néanmoins, par exemple, si un nœud comprend un ensemble de plusieurs cartes réseau et que l'une d'elles tombe en panne, les données qui transitaient par l'interface défaillante (carte réseau en panne) peuvent être redirigées vers une autre interface du même nœud. Ainsi, il peut être considéré qu'en cas de panne logicielle, les services sont transférés entre des équipements différents (typiquement d'un nœud vers un autre) mais que dans le cas d'une panne matérielle, des services peuvent être transférés au sein d'un même équipement (exemple précédent de la carte réseau) ou vers un autre équipement.
La figure 5, comprenant les figures 5a et 5b, illustre des exemples de panne et de double panne, respectivement, dans la partie de l'infrastructure informatique décrite en référence à la figure 4. Comme illustré sur la figure 5a, si le commutateur 410-0 tombe en panne, le nœud 405-0 devient invisible pour les nœuds 405-1 , 405-2 et 405-3 qui appellent alors le mécanisme de haute disponibilité décrit précédemment.
Le groupe de haute disponibilité ayant le niveau le plus bas, c'est-à- dire le groupe 420 (Grp1_H1 niv 1), est ainsi sélectionné. Comme décrit en référence à la figure 3b, il existe une solution standard pour répartir la charge du nœud 405-0 considéré comme défaillant, c'est-à-dire ici les cibles de stockage d'objets OST1 , OST2 et OST3, vers les nœuds 405-1 à 405-3. Cette solution est alors mise en œuvre.
De même, comme illustré sur la figure 5b, si le commutateur 410-1 tombe en panne, les nœuds 405-1 et 405-2 deviennent invisibles pour les nœuds 405-0 et 405-3 qui appellent alors le mécanisme de haute disponibilité décrit précédemment.
Le groupe de haute disponibilité ayant le niveau le plus bas, c'est-à- dire le groupe 420 (Grp1_H1 niv 1), est ainsi sélectionné. Cependant, comme décrit en référence à la figure 3c, il n'existe pas de solution standard pour répartir la charge des nœuds 405-1 et 405-2 considérés comme défaillants, c'est-à-dire ici les cibles de stockage d'objets OST4 à OST9, vers les nœuds 405-0 et 405-3.
Les groupes de haute disponibilité appartenant au groupe 420 précédemment sélectionné et dont le niveau est directement supérieur, c'est-à- dire les groupes 425-0 (Grp1_H1 niv 2) et 425-1 (Grp2_H1 niv 2), sont alors sélectionnés.
Il y a une seule panne dans le groupe de haute disponibilité 425-0 et il existe une solution standard à ce problème consistant à transférer la charge du nœud défaillant, ici le nœud 405-1 vers le ou les autres nœuds du groupe de haute disponibilité, c'est-à-dire ici le nœud 405-0. Cette solution est donc mise en œuvre, comme illustré, en déplaçant les cibles de stockage d'objets OST4 à OST6 vers le nœud 405-0.
De même, il y a une seule panne dans le groupe de haute disponibilité 425-1 et il existe une solution standard à ce problème consistant à transférer la charge du nœud défaillant, ici le nœud 405-2 vers le ou les autres nœuds du groupe de haute disponibilité, c'est-à-dire ici le nœud 405-3. Cette solution est donc mise en œuvre, comme illustré, en déplaçant les cibles de stockage d'objets OST7 à OST9 vers le nœud 405-3.
Pour gérer le mécanisme de haute disponibilité par niveaux, un logiciel de haute disponibilité spécifique, prenant en considération un ou plusieurs niveaux de haute disponibilité, peut être utilisé.
Selon un mode de réalisation particulier, des réseaux dits Heartbeat différents sont utilisés pour chaque groupe de haute disponibilité de chaque niveau.
L'implémentation peut être faite de différentes façons au niveau de la couche applicative.
Il est possible de mettre en œuvre un environnement de haute disponibilité permettant de gérer les divers niveaux et également d'intégrer un système de classement automatique d'équipements par niveau, selon un type d'équipement considéré, une position dans l'infrastructure informatique (par exemple un équipement de réseau ou de stockage) et une fonction. Via les informations disponibles dans une base de données descriptive de l'infrastructure informatique, il est possible de prédéterminer le rôle et les relations entre des composants devant faire partie d'un même groupe HA ou devant faire partie d'un groupe HA d'un niveau supérieur. Il est alors possible de définir la hiérarchie des groupes HA en se basant sur la topologie (relations entre les équipements, principalement au niveau du réseau et/ou du stockage), le rôle de l'équipement visé et surtout sur les liens de cet équipement vers d'autres équipements devant également être opérationnels pour que cet équipement puisse fournir le service attendu.
Il est également possible d'utiliser des produits disponibles utilisant des mécanismes de virtualisation afin de simuler divers niveaux au sein d'un même nœud. Ainsi, par exemple, le système d'exploitation (OS, Operating System en terminologie anglo-saxonne) natif du nœud peut être utilisé pour gérer le premier niveau de haute disponibilité tandis qu'un système virtuel mis en œuvre sur le nœud, représentant un nœud virtuel (aussi appelé OS virtuel), peut être utilisé pour gérer un second niveau de haute disponibilité. De façon similaire, d'autres systèmes virtuels peuvent être mis en œuvre sur le nœud et utilisés pour gérer d'autres niveaux de haute disponibilité.
Selon un tel mode de réalisation, les services devant être migrés avec des paramètres associés lorsqu'un équipement est défaillant sont mis en œuvre, au sein d'un nœud, dans le système (natif ou virtuel) correspondant au premier niveau de haute disponibilité. Puis, lorsqu'une panne est détectée et qu'il n'existe pas de solution dans le premier niveau de haute disponibilité, ces services et, le cas échéant, des paramètres associés, sont déplacés (en général avec des services de l'équipement en panne) vers le système (natif ou virtuel) correspondant au niveau de haute disponibilité pour lequel il existe une solution.
La figure 6 illustre un exemple de certaines étapes d'un algorithme utilisé dans un nœud pour mettre en œuvre l'invention. Selon le mode de réalisation présenté ici, les mêmes applications de gestion de haute disponibilité sont mises en œuvres dans chacun des nœuds d'un groupe de haute disponibilité (du niveau le plus bas). Il n'est donc pas nécessaire de prévoir de mécanisme de synchronisation entre les nœuds.
Une première étape (étape 600) consiste ici à initialiser une variable appelée Niv.HA, représentative du niveau de haute disponibilité courant, à la valeur 1.
Dans une étape suivante (étape 605), un test est effectué pour déterminer si une ou plusieurs pannes sont détectées. Ce test utilise des mécanismes standard des algorithmes de haute disponibilité visant notamment à vérifier que les nœuds du même groupe de haute disponibilité (initialement du plus bas niveau de haute disponibilité) sont accessibles et/ou dans un état prédéterminé.
Si aucune panne n'est détectée, l'algorithme boucle sur lui-même jusqu'à ce qu'au moins une panne soit détectée ou qu'il soit mis fin à l'algorithme.
Au contraire, si une panne est détectée, une solution de haute disponibilité est recherchée (étape 610). Typiquement, une telle étape consiste à identifier une configuration de panne prédéterminée dans une table ou une base de données 615, pour le niveau de haute disponibilité courant (Niv.HA), afin d'identifier la façon de répartir les services exécutés par le ou les nœuds en panne sur un ou plusieurs autre nœuds du même groupe de haute disponibilité du niveau de haute disponibilité courant.
Un test est alors effectué (étape 620) pour déterminer s'il existe une solution prédéterminée pour la répartition des services exécutés par le ou les nœuds en panne.
Dans l'affirmative, la solution est appliquée en effectuant les transferts (étape 625), de façon standard. L'algorithme reboucle alors à l'étape 605 pour traiter, le cas échéant, de nouvelles pannes.
Il est observé ici que s'il n'y a pas de panne dans le groupe de haute disponibilité correspondant au nouveau niveau de haute disponibilité auquel appartient le nœud considéré, il existe une solution qui consiste à ne rien faire.
Dans le cas contraire, s'il n'existe pas de solution prédéterminée pour la répartition des services exécutés par le ou les nœuds en panne, la variable Niv.HA, représentant le niveau de haute disponibilité courant, est incrémentée de un (étape 630).
Un test est alors effectué pour déterminer si la nouvelle valeur de la variable Niv.HA correspond à un niveau de haute disponibilité réel (étape 635), c'est-à-dire si le niveau de haute disponibilité Niv.HA est défini.
Dans la négative, il est mis fin à l'algorithme, aucune solution ne pouvant être apportée à la panne ou aux pannes détectées.
Dans le cas contraire, si la nouvelle valeur de la variable Niv.HA correspond à un niveau de haute disponibilité réel, les étapes précédentes étapes 610 à 635) sont répétées, comme illustré, pour déterminer s'il existe une solution dans le groupe de haute disponibilité correspondant au nouveau niveau de haute disponibilité.
Selon le mode de mise en œuvre de l'invention, il peut être nécessaire, après avoir modifié le niveau de haute disponibilité, de changer d'environnement (étape 640). Un tel changement peut notamment consister à passer d'un système (natif ou virtuel) à un autre et, si nécessaire, à transférer les services exécutés dans le système initial vers le nouveau système utilisé. L'invention peut également être mise en œuvre pour des ensembles de groupes de haute disponibilité, par exemple des groupes de haute disponibilité utilisant un même système de fichiers distribué. L'invention permet alors d'écarter la limitation du nombre de n uds par groupe de haute disponibilité qui est généralement limité à 2, 4 ou 8 nœuds de stockage (OSS), notamment du fait du nombre de liens de type fibre vers les baies de stockage, une telle contrainte ayant en particulier pour conséquence que le nombre de groupes de haute disponibilité de nœuds de stockage est, dans un cluster, typiquement compris entre deux et plusieurs dizaines.
Une solution basée sur un mécanisme de haute disponibilité par niveaux permet, via un système de contrôle externe aux groupes de haute disponibilité, par exemple un nœud lui-même configuré selon un mécanisme de haute disponibilité, dédié à la gestion de ces groupes, de gérer un niveau de haute disponibilité particulier permettant une bascule entre groupes, c'est-à-dire un transfert de services entre des nœuds de groupes différents.
En cas de détection de panne, l'identification d'une solution est avantageusement réalisée en deux temps. Tout d'abord, une analyse utilisant les mécanismes de haute disponibilité internes aux groupes de haute disponibilité, comme décrits précédemment, est, de préférence, effectuée. 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 tel que celui décrit en référence à la figure 4 (référence 400).
Dans un souci de clarté, ces groupes ont ici des architectures similaires cependant, des architectures différentes peuvent tout aussi bien être mises en œuvre.
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é 705-0 est associé aux éléments de cette cellule.
Comme illustré, deux niveaux de haute disponibilité internes sont associés à chaque élément de la cellule (groupes ayant les références 420 d'une part et 425-0 et 425-1 d'autre part), conformément au groupe 400 de haute disponibilité décrit en référence à la figure 4.
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 (705-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 nœuds de gestion de haute disponibilité (formant un autre groupe de haute disponibilité), référencés 710-0 et 710-1 , assurant la fonction de haute disponibilité au niveau des groupés de haute disponibilité. Les nœuds 710-0 et 710-1 permettent ainsi de transférer des services exécutés par des nœuds d'un groupe de haute disponibilité 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 415 reliant les commutateurs du groupe de haute disponibilité 700-0 et les nœuds 710-0 et 710-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 420, 425-0 et 425-1). En effet, la panne du réseau de communication 415 reliant les commutateurs du groupe de haute disponibilité 700-0 et les nœuds 710-0 et 710-1 engendre une panne multiple dans les groupes de haute disponibilité correspondant aux groupes 420, 425-0 et 425-1 de la figure 4 (représentée par les croix en trait pointillé).
Par contre, il existe une solution liée à la cellule 705-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 800.
II est observé ici que si aucune solution n'avait été trouvée dans la cellule 705-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 705-0), c'est-à-dire ici la cellule comprenant les cellules 705-0 et 705-1.
11 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 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 au moins un groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, ce procédé étant caractérisé en ce qu'un premier niveau de haute disponibilité est associé audit au moins un groupe d'équipements à haute disponibilité, en ce qu'une pluralité de sous- ensembles dudit ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, appelé premier groupe d'équipements à haute disponibilité, forme une pluralité de second groupes d'équipements à haute disponibilité, un second niveau de haute disponibilité étant associé auxdits seconds groupes d'équipements à haute disponibilité et en ce qu'il comprend les étapes suivantes,
- détection (605) d'une défaillance d'au moins un équipement dudit ensemble d'équipements ;
- recherche (610) d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit premier niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant ; et,
- si aucune solution de haute disponibilité n'est identifiée (620) dans des groupes d'équipements à haute disponibilité auxquels est associé ledit premier niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant,
o recherche (630, 610) d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant.
2. Procédé selon la revendication 1 selon lequel ladite étape de recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant est appliquée de façon récursive à des groupes d'équipements à haute disponibilité auxquels est associé un niveau de haute disponibilité de rang supérieur au niveau précédemment utilisé pour la recherche d'une solution et comprenant ledit au moins un équipement défaillant.
3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de transfert d'au moins un service mis en œuvre dans ledit au moins un équipement défaillant vers au moins un équipement visé dans une solution identifiée.
4. Procédé selon l'une quelconque des revendications 1 à 3 selon lequel ladite étape de recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de' haute disponibilité et comprenant ledit au moins un équipement défaillant comprend une étape de changement d'environnement d'exécution d'au moins un service d'au moins un équipement dudit au moins un premier groupe d'équipements à haute disponibilité.
5. Procédé selon l'une quelconque des revendications précédentes selon lequel lesdites étapes du procédé sont mises en oeuvre par des équipements dudit au moins un premier groupe d'équipements à haute disponibilité.
6. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite infrastructure informatique comprend au moins deux premiers groupes de haute disponibilité et, lorsqu'au moins un équipement desdits au moins deux premiers groupes d'équipements à haute disponibilité est défaillant et qu'aucune solution n'a été identifiée dans le premier groupe d'équipements à haute disponibilité comprenant l'équipement défaillant ni dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant, le procédé comprend en outre une étape d'identification d'au moins un premier groupe d'équipements à haute disponibilité parmi lesdits au moins deux groupes d'équipements à haute disponibilité, distinct du premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant, adapté à recevoir des services exécutés par des équipements dudit premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant et formant une solution de haute disponibilité.
7. Procédé selon la revendication 6 selon lequel ladite étape d'identification d'au moins un premier groupe d'équipements à haute disponibilité parmi lesdits au moins deux groupes d'équipements à haute disponibilité, adapté à recevoir des services exécutés par des équipements dudit premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant et formant une solution de haute disponibilité, est mise en œuvre dans un équipement distinct desdits au moins deux premiers groupes d'équipements à haute disponibilité.
8. Procédé selon l'une quelconque des revendications précédentes selon lequel un équipement défaillant est un équipement en panne ou un équipement considéré en panne du fait d'un autre équipement en panne, ladite panne étant matérielle et/ou logicielle.
9. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite pluralité d'équipements comprend une pluralité de nœuds.
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/052731 2011-12-13 2012-11-27 Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité WO2013088019A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1161583 2011-12-13
FR1161583A FR2984053B1 (fr) 2011-12-13 2011-12-13 Procede et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des equipements a haute disponibilite.

Publications (1)

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

Family

ID=47436078

Family Applications (1)

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

Country Status (2)

Country Link
FR (1) FR2984053B1 (fr)
WO (1) WO2013088019A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104023061A (zh) * 2014-06-10 2014-09-03 浪潮电子信息产业股份有限公司 一种lustre的oss高可用集群方案
US20190334990A1 (en) * 2018-04-27 2019-10-31 Exten Technologies, Inc. Distributed State Machine for High Availability of Non-Volatile Memory in Cluster Based Computing Systems

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080189468A1 (en) * 2007-02-02 2008-08-07 Vmware, Inc. High Availability Virtual Machine Cluster
US20100262860A1 (en) * 2009-04-09 2010-10-14 Chandramouli Sargor Load balancing and high availability of compute resources
WO2011002169A2 (fr) * 2009-07-02 2011-01-06 엔에이치엔(주) Système de gestion de base de données à haute disponibilité et procédé de gestion de base de données utilisant ce système

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080189468A1 (en) * 2007-02-02 2008-08-07 Vmware, Inc. High Availability Virtual Machine Cluster
US20100262860A1 (en) * 2009-04-09 2010-10-14 Chandramouli Sargor Load balancing and high availability of compute resources
WO2011002169A2 (fr) * 2009-07-02 2011-01-06 엔에이치엔(주) Système de gestion de base de données à haute disponibilité et procédé de gestion de base de données utilisant ce système

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104023061A (zh) * 2014-06-10 2014-09-03 浪潮电子信息产业股份有限公司 一种lustre的oss高可用集群方案
US20190334990A1 (en) * 2018-04-27 2019-10-31 Exten Technologies, Inc. Distributed State Machine for High Availability of Non-Volatile Memory in Cluster Based Computing Systems

Also Published As

Publication number Publication date
FR2984053B1 (fr) 2014-01-10
FR2984053A1 (fr) 2013-06-14

Similar Documents

Publication Publication Date Title
US20210012239A1 (en) Automated generation of machine learning models for network evaluation
EP2697936B1 (fr) Procédé et dispositif de traitement de commandes d'administration dans un cluster
EP2998877A2 (fr) Serveur comprenant une pluralité de modules
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é
WO2009153498A1 (fr) Procede de generation de requetes de manipulation d'une base de donnees d'initialisation et d'administration d'une grappe de serveurs, support de donnees et grappe de serveurs correspondants
FR2946769A1 (fr) Procede et dispositif de reconfiguration d'avionique.
WO2021152262A1 (fr) Procede de surveillance de donnees echangees sur un reseau et dispositif de detection d'intrusions
WO2011117528A1 (fr) Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs
US20200310899A1 (en) Method for retrieving metadata from clusters of computing nodes with containers based on application dependencies
WO2013088019A1 (fr) Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité
FR2960369A1 (fr) Procede d'optimisation de routage dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede
EP2704010A1 (fr) Procédé et dispositif de traitement de commandes dans un ensemble d'éléments informatiques
EP2721487B1 (fr) Procede, dispositif et programme d'ordinateur pour la mise à jour logicielle de clusters optimisant la disponibilite de ces derniers
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é
WO2013175138A1 (fr) Procede, dispositif et programme d'ordinateur de controle dynamique de distances d'acces memoire dans un systeme de type numa
Maia et al. Dataflasks: epidemic store for massive scale systems
WO2011151569A1 (fr) Procede de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede
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é
EP2729874B1 (fr) Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration
WO2019122626A1 (fr) Systeme et procede d'elaboration et d'execution de tests fonctionnels pour grappe de serveurs
WO2013050682A1 (fr) Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé
WO2013088018A1 (fr) Procédé et programme d'ordinateur de configuration d'équipements dans une infrastructure informatique ayant une architecture de type infiniband
FR2930697A1 (fr) Procede et dispositif de configuration dynamique d'un reseau de communication pour la simulation temps reel de l'integration de composants electroniques dans un vehicule
EP2192739A1 (fr) Mécanisme de tolérance aux fautes optimisé pour réseau pair-à-pair
FR2977338A1 (fr) Procede et programme d'ordinateur pour identifier dynamiquement des composants d'un cluster et automatiser des operations de gestion optimisee du cluster

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12806581

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

Country of ref document: EP

Kind code of ref document: A1