EP3732573A1 - Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee - Google Patents

Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee

Info

Publication number
EP3732573A1
EP3732573A1 EP18842811.4A EP18842811A EP3732573A1 EP 3732573 A1 EP3732573 A1 EP 3732573A1 EP 18842811 A EP18842811 A EP 18842811A EP 3732573 A1 EP3732573 A1 EP 3732573A1
Authority
EP
European Patent Office
Prior art keywords
node
nodes
storage medium
network
state
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.)
Pending
Application number
EP18842811.4A
Other languages
German (de)
English (en)
Inventor
Sébastien DUGUE
Christophe LAFERRIERE
Benoit Welterlen
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
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 EP3732573A1 publication Critical patent/EP3732573A1/fr
Pending 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/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/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING 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/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • 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/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • 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/2038—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 with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0026—PCI express

Definitions

  • the invention relates to the field of fault management methods in a node network and the domain of node network portions associated with this fault management.
  • backups are performed at one or more levels, they are multilevel backups.
  • the calculation can be recovered at least partially without having to be completely restarted, precisely thanks to the backups made.
  • one or the other level of backup is used to recover the calculation in part or in the majority or almost completely.
  • Distributed applications can last much longer than the average network failure time, also called MTBF of a cluster (for "Mean Time Between Failures" in English), so they are likely to be interrupted. In general, they do not have an internal fault-management solution, which can then lead to the loss of local backup data in the event of a physical failure of the compute node, followed by the loss of the entire data set. calculation progress caused by the loss of a single compute node but whose local backup data can no longer be retrieved.
  • the different levels of backup range from the most local backup to the most global backup, ranging from the simplest and fastest backup to the most complex, slowest, and most expensive backup, ranging from the most fragile and weakest backup to the most robust and resilient backup.
  • the first level Ll which makes a local backup, simple and inexpensive, performed very often, resulting in a minimal loss of computation time during a failure that can be recovered at this first level first Ll,
  • the second level L2 which performs a first intermediate backup by duplication on a partner node, less simple and more expensive, resulting in a greater loss of computation time during a failure that can be recovered only at this second level L2 ,
  • the third level L3 which makes a second intermediate backup by Reed-Solomon type encoding, even less simple and even more expensive, resulting in a loss even more important in computing time during a failure that can not be recovered that at this third level L3,
  • the fourth level L4 which performs a global backup at a file system level, complex and very expensive, resulting in a really significant loss of computing time during a failure that can be recovered only at this fourth level L4.
  • the backup is more and more robust and resilient, but it also becomes more and more complex and expensive. That's why the backup of the first level It is performed often, the backup of the second level L2 less often, the backup of the third level L3 even less often, the backup of the fourth level L4 relatively rarely. Therefore, statistically, when a failure occurs, the last coherent state that can be retrieved is very recent at the first level L1, less recent at the second level L2, even less recent at the third level L3, older at the fourth level L4. Consequently, the volume of work lost is very low at the first level L1, relatively limited at the second level L2, notable at the third level L3, and more important at the fourth level L4.
  • the object of the present invention is to provide a fault management method in a node network at least partially overcoming the aforementioned drawbacks.
  • the invention aims to provide a fault management method in a network of nodes improving the compromise between efficiency on the one hand and cost and complexity on the other hand, for at least one level of backup considered.
  • the aim of the invention is to provide a fault management method in a network of nodes that has an efficiency similar or comparable to that of an intermediate level backup, preferably that of the first intermediate backup, advantageously that of the second level. L2, for a cost and complexity similar or comparable to those of a local level backup, preferably those of the first level Ll.
  • the invention proposes to make the link between a storage medium and its redirection node to another node, so as to have the backup performed on the storage medium when the node is failing, possibly through a copy at a level Neighbor node, but without making backup copy at a neighboring node for most nodes that are not failing or for all nodes that are not failing.
  • the link between a storage medium and its node is not realized directly, but indirectly through a network element able to reconfigure this link to link this storage medium to another node when the previous node becomes faulty.
  • This network element links several nodes to their respective storage media, each node being connected to its associated storage medium (or possibly to its associated storage media).
  • a backup is available despite the failure of this node, resulting in a similar efficiency to the second level L2, but no operation is more complex than a simple local backup for the second node.
  • most or all nodes that are not failing which is the majority or even the vast majority of the nodes of the network performing the calculation considered, resulting in a cost and complexity at least comparable if not similar to those of the first level Ll .
  • the cost of the second level L2 is saved, while the ability to restart an application from the backups of the first level L1 is maintained in the event of failure of a computing node.
  • the copy to a neighboring node traditionally performed at the second level L2 is here not performed during the execution of the application in a preventive manner for all the compute nodes, but only in case of failure and only for the failed nodes after occurrence of the breakdown. The copy is then made only to restart the application with the missing data, uploads from the local backup.
  • this backup of cost and complexity similar or comparable to a local backup has the effectiveness of an intermediate backup, which greatly improves the value for money of this backup.
  • this backup of cost and complexity similar to or comparable to a local backup having the efficiency of an intermediate backup preferably makes it possible to replace both a conventional local backup and one or more conventional intermediate backups, by not keeping more than the global backup last resort, to handle the most severe failures, most of the failures can now be managed by the local backup - intermediate proposed by the invention, the latter having the effectiveness of a backup intermediate practically at the cost of a local backup.
  • the present invention proposes a fault management method in a network of nodes, comprising, for each considered node of all or part of the nodes of the network performing the same calculation: first, a local backup step of the network; state of this node considered, at the level of a storage medium of this node considered, the link between this storage medium and this node can be redirected from this storage medium to another node, then a recovery step : the node considered if it is not faulty, from the local backup of the state of this node, or an operational node different from the considered node, if the considered node is failing, from recovering the local backup of the state of this node, by redirecting said link between the node in question and its storage medium so as to connect said storage medium to said node.
  • the local backups of these nodes considered, used for the recovery steps are consistent with each other so as to correspond to the same state of this calculation.
  • the present invention also proposes a part of a network of nodes, comprising: a switch, a plurality of nodes of a group of nodes performing the same calculation in this network of nodes, several storage media respectively attached to these nodes via the switch, these storage media being structured and arranged to locally store the state of the nodes to which they are respectively attached, this switch being structured and arranged for change at least one attachment between a failed node and its storage medium which will then become attached to another node of said plurality of nodes.
  • this fault management method allows the optimization and the resilience of the data backup of an application likely to encounter a failure and the restart of this application using the data saved. .
  • this fault management method offers the possibility of migrating a storage medium from the failed computing node by means of the switch, thus making it possible to directly exploit the local data saved from a node of calculating down in a time that depends only little on the amount of data saved.
  • this fault management method provides fault tolerance that extends in absolute terms to a large number of compute nodes as long as it exists, on each computing node that falls in failure, a calculation node attached to the same switch that can resume the calculation of the failed computing node. It is then possible to restart from the last local backup, even if a large number of the compute nodes fail, as long as each failed compute node has a switch and a neighboring non-faulty computing node connected at the same switch.
  • the invention comprises one or more of the following features which can be used separately or in partial combination with one another or in total combination with one another, applied to one or the other of the objects of the invention. invention mentioned above.
  • each considered non-faulty node there is no step of recovery by another node, the local backup of the state of this node considered not faulty.
  • the operational node different from the defective node concerned is a spare node.
  • non-failing nodes which already have their own computation task to perform, are not loaded in addition to performing this operation of recovering a faulty neighbor node. A possible overload of these non-faulty nodes is then avoided.
  • said redirection of said link between the node in question and its storage medium so as to connect said storage medium to said operational node is achieved by a change of routing in a switch connecting several nodes to their storage media.
  • this redirection is performed by a simple operation performed at a network element that is reliable and controlled.
  • all the nodes restarting steps are synchronized with each other, so as to restart all said nodes in the same calculation state.
  • the recovery step comprising a substep of migration, to the operational node or to the spare node, storage medium of the local backup of the state of the failed node, which relates , this storage medium of the local backup of the state of the failed node, at a predetermined location of the file tree of this operational node or of this spare node, this operational node or this spare node then read, at this predetermined location, the link to the local backup of the state of the failed node, during the recovery step of this operational node or of this spare node, no copy, of the local backup of the state of the node failing, being realized, at another node.
  • the spare node and the failed node that it replaces both belong to the same compute blade.
  • the recovery step comprises: firstly, a substep of migration, to an intermediate node, of the storage medium of the local backup of the state of the failing node, which links, this storage medium of the local backup of the state of the failed node, at a predetermined location of the file tree of this intermediate node, then, a substep of copy, the local backup of the state of the node failing, the storage medium attached to the intermediate node to the storage medium of the operational node or the spare node, the operational node or this spare node then read its storage medium, during its recovery stage.
  • the copy sub-step is not necessary and can be avoided by moving the storage medium to the right place in the spare node's file tree as in the first embodiment described above, or by simply changing the configuration of the the fault tolerance library.
  • This feedback is instantaneous and allows to avoid an additional copy that could take a little time depending on the amount of data to save.
  • the replacement node and the failed node that it replaces belong to different calculation blades.
  • the redirection of the link between the support and the node can be performed even in the event of a major failure and even relatively generalized at the level of a whole computing blade.
  • the migration sub-step changes the attachment of the storage medium of the local backup of the state of the failed node by passing through a switch to which the failed node was attached and its storage medium. local backup of the state of the failed node, but without going through the failed node itself.
  • the redirection can be performed even in case of complete physical failure of the failed node.
  • the change of attachment is achieved by sending a command to the switch, this command passing through one of the nodes attached to the switch by a management port.
  • this switch is a PCIe switch
  • this switch is particularly advantageous because it is particularly suitable for communicating devices with each other without having to go through a microprocessor, thus being able to bypass a faulty computing node for example.
  • the use of this PCIe switch allows the storage medium, for example a storage disk, to be reattached, containing the local backups of the failed computing node to a spare computing node. This operation is fast and does not require a systematic copy of local backup data, and in particular not for non-faulty compute nodes.
  • 3 to 10 nodes are attached to the same switch.
  • the switch can easily manage this small group of nodes for which only one spare node seems to have to be sufficient.
  • the fault management method also includes, for all or part of the nodes of the network performing the same calculation: a step of global backup of all of these nodes, performed less often than all the local backup steps of these nodes.
  • the local-intermediate backup proposed by the invention for managing the vast majority of faults in a simple and efficient manner, and on the other hand the more complex and expensive overall backup but reserved for a minority of severe failures, an excellent compromise between overall complexity and overall efficiency of the fault management method proposed by the invention is achieved.
  • the fault management method proposed by the invention then allows restarting the application, following a physical failure on a node, even complete, and this in most cases, starting from all the local backups, more recent and less expensive, instead of having to restart remote backups that are very often significantly older, some rarer cases of failure sometimes requiring the use of remote global backup.
  • the ability to recover local data from the failed compute node allows you to restart the application from most recent local backups in most cases.
  • the network comprises between 1 and 5 spare nodes for 100 nodes performing the same calculation.
  • this fault management method does not include any other type of local backup of the state of these nodes.
  • the storage media are flash memories.
  • the memories used are simple, fast and permanent.
  • these flash memories are memories NVMe ("Non Volatile Memory Express" in English).
  • the memories used are particularly well suited to communicate with a PCIe switch ("Peripheral Component Interconnect Express" in English).
  • this switch being structured and arranged to change at least one attachment between a faulty node and its storage medium, on command external to the switch.
  • said plurality of nodes comprises between 3 and 10 nodes.
  • the switch can easily manage this small group of nodes for which only one spare node seems to have to be sufficient.
  • this switch is a PCIe switch.
  • this switch is particularly advantageous because it is particularly adapted to be able to communicate with each other peripherals without having to go through a microprocessor.
  • the storage media are flash memories, preferably NVMe memories.
  • the memories used are particularly well suited to communicate with a PCIe switch.
  • the network of computation nodes comprises at least 1000 computation nodes, advantageously at least 5000 computation nodes, still more advantageously at least 10000 computation nodes, making the fault management method according to the invention all the more interesting. Because the complete loss of a current calculation then becomes all the more critical as the network is large.
  • fault tolerance is all the more important that an application runs on a cluster that consists of a larger number of compute nodes. The greater the number of processors, memory and other devices, the greater the probability that a failure will occur before the end of the execution.
  • Applications that are intended to run on this type of platform will use fault tolerance libraries that allow them to save (“checkpoint” in English) the data needed for a restart (“restart” in English). in a state as close as possible to the state that existed just before the failure. Thus, these applications are not forced to restart the calculation from the beginning.
  • FIG. 1 diagrammatically represents an example of a network part including a group of nodes and their storage media connected to each other by a PCIe switch, according to one embodiment of the invention, at which part of the network, an example of a fault management method according to the invention can take place.
  • FIG. 1 diagrammatically represents an example of a network part including a group of nodes and their storage media connected to each other by a PCIe switch, according to one embodiment of the invention, at which part of the network, an example of a fault management method according to the invention can take place.
  • This part of the network comprises several calculation nodes 2, three calculation nodes 21, 22 and 23, in the example of FIG. 1, as well as several storage supports 3, three storage media 31, 32 and 33, example of Figure 1.
  • connection 7 is a 4-way connection.
  • Connection 8 is a 4-way connection.
  • connection 9 is a 2-way connection, here not yet used, each connection 9 being on one side attached to one of the ports 13, 16 or 19 and remaining free on the other side.
  • Each PCIe connection 7 respectively connects one of the computing nodes 21 to 23 to one of the ports 0, 2 or 8 (numbering the electronic switch PLX 8733, but another PCIe switch can be used), respectively referenced 11, 14 or 17 in Figure 1, of the switch 1.
  • Each PCIe connection 8 respectively connects one of the storage media 31 to 33 to one of the ports 1, 3 or 9 , respectively referenced 12, 15 or 18 in Figure 1, of the switch 1.
  • the connection 7, the ports 0 and 1, respectively referenced 11 and 12 in Figure 1, of the switch 1, the connection 8 together form a link 4 connecting the computation node 23 at its support 33.
  • the connection 7, the ports 2 and 3, respectively referenced 14 and 15 in FIG. 1, of the switch 1, the connection 8 together form a link 5 connecting the computation node 22 to its support 32.
  • the connection 7, the ports 8 and 9, respectively referenced 17 and 18 in Figure 1, the switch 1, the connection 8 together form a link 6 connecting the compute node 21 to its support 31.
  • the PCIe connections 7 , 8 or 9, can be
  • the computation node 23 is attached to the default management or management port, that is to say that it is through it that the outgoing sendings of the group of calculation nodes 2 and the receptions from from the outside of the computing node group 2. In the event of failure of this computing node 23, it is replaced by the computing node 22 which is attached to the redundant management or management port, which computing node 22 becomes attached to the new port of management or effective management.
  • the attachment of the storage medium 31 is reconfigured, that is to say that the storage medium 31 will cease to be connected to its calculation node 21 of attachment by default, but will become connected to the calculation node 23, which is attached to the default management port, will be able to trace the local backup of the calculation state of the failed computing node 21, since the storage medium 31, to another spare computing node outside the group of calculation nodes 21 to 23, this other computing node then taking over the calculation task interrupted at the failed computing node 21, from the local backup of the computing state of the computation node 21 sent up from the storage medium 31.
  • the port 9 (numbering of the electronic switch PLX8733, but another PCIe switch can be used) referenced 18 (in FIG. 1), instead of remaining permanently connected to the port 8 referenced 17 as before the failure of the computing node 21, will be, at least temporarily connected to the port 0 referenced 11, to allow the computing node 23 to read, in the storage medium 31, the saved data representative of the calculation state of the node of calculation 21, just before or shortly before, its failure.
  • the local backup in the storage medium 31, of the calculation state of the calculation node 21 before its failure, will be able to go back to the computing node 23 and thus be exploited to restart the calculation with a very good compromise between simplicity of the backup and efficiency of the recovery.
  • the computing node 23 is itself a spare node, it can take over the computation task interrupted by the failed computing node 21.
  • the calculation node 22 If it is the node 23 that becomes faulty, it is first replaced by the calculation node 22 as attached to the management port, and the calculation node 22, as attached to the new management port, performs the operations previously performed by the computing node 23 if it had not become defective.
  • the management of the switch 1 is now described by a manual scenario clarifying and explaining the various operations to be performed, such as for example the migration of the storage medium 31 from a failing calculation node 21 to a spare calculation node 23, the transfer data, restarting the application.
  • Application-side data management is abstracted by the FTI library.
  • the executed application is provided in the examples of the FTI library: hdf.exe.
  • This application is launched on two compute nodes. It will perform local backups on NVMe storage disks attached to these compute nodes by the PCIe switch at regular intervals as well as a global backup on a NFS server ("Network File System" in English) less frequently .
  • NFS server Network File System
  • the migration of the NVMe storage disk from the failed node to another node will then allow the transfer of data from the last local backup of that failed node to the spare node. Once this transfer is made, the application can be restarted and resumes the calculation at the last local backup of the two compute nodes instead of the last older global backup of the network part.
  • a failure recovery is performed with the local backup data of an application MPI ("Message Passing Interface" in English) of a computing node crashing.
  • the data is retrieved by migrating the storage medium of the failing compute node to a compute node adjacent to the same compute blade. This data is then transmitted to a second spare node which will resume the calculation.
  • MPI Message Passing Interface
  • the advantage of this failover is that it allows the application to restart from local backups of all compute nodes. These cheaper local backups are also newer most of the time, and are at worst only as recent as global backups. In addition, the amount of data transferred to resume the calculation will be much lower than in the case of a restart from a global backup.
  • the configuration of the FTI library has been modified ["config.fti" in the “examples” directory], to allow execution on two different compute nodes:
  • the local backup directory ["/ localckpt /"] is an assembly of the SSD storage disk.
  • Solid State Disk available on each compute node, the storage disk S0 (referenced 31 in FIG. 1) on the calculation node N1 and the storage disk S1 (referenced 32 in FIG. 1) on the compute node N2:
  • the computing node N 1 is considered to be down, the storage disk S0 attached to it will be migrated to another computing node, here the computing node N3 (referenced 23 in Figure 1).
  • the compute node N3 is the node that has the switch administration port.
  • the first step is to send the command that allows to reroute the reset PCI ("reset" in English), the last argument being the number of the faulty or faulty node:
  • This command can be executed from neighboring nodes or the management or management node.
  • the recovered saved data is then transmitted to the spare computing node in charge of replacing the failed computing node N1. It can be the same node as the node N3 in charge of the recovery of the data saved on the storage disk S0.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de gestion de panne dans un réseau de nœuds (2), comprenant, pour chaque nœud considéré (2) de tout ou partie des nœuds (2) du réseau effectuant un même calcul : d'abord, une étape de sauvegarde locale de l'état de ce nœud considéré (21), au niveau d'un support de stockage (31) de ce nœud considéré (21), le lien (6) entre ce support de stockage (31) et ce nœud considéré (21) pouvant être redirigé de ce support de stockage (31) vers un autre nœud (23), ensuite, une étape de relance : soit du nœud considéré (21) si celui-ci n'est pas défaillant, à partir de la sauvegarde locale de l'état de ce nœud considéré (21), soit d'un nœud opérationnel (23) différent du nœud considéré (21), si le nœud considéré (21) est défaillant, à partir de la récupération de la sauvegarde locale de l'état de ce nœud considéré (21), en redirigeant ledit lien (6) entre le nœud considéré (21) et son support de stockage (31) de manière à relier ledit support de stockage (31) vers ledit nœud opérationnel (23), les sauvegardes locales de ces nœuds considérés (2), utilisées pour les étapes de relance, sont cohérentes entre elles de sorte à correspondre à un même état de ce calcul.

Description

PROCEDE DE GESTION DE PANNE DANS UN RESEAU DE
NŒUDS ET PARTIE DE RESEAU DE NŒUDS ASSOCIEE
DOMAINE DE L’INVENTION
L’invention concerne le domaine des procédés de gestion de panne dans un réseau de nœuds et le domaine des parties de réseau de nœuds associées à cette gestion de panne.
CONTEXTE DE L’INVENTION
Dans un réseau de nœuds effectuant un même calcul, des sauvegardes sont effectuées à un ou à plusieurs niveaux, ce sont des sauvegardes multiniveaux. Lorsqu’une panne survient, le calcul peut être récupéré au moins en partie sans devoir être intégralement recommencé, justement grâce aux sauvegardes effectuées. Selon le type de panne survenu, l’un ou l’autre des niveaux de sauvegarde est utilisé pour récupérer le calcul en partie ou en même en majorité ou encore presque totalement.
Les applications distribuées peuvent durer beaucoup plus longtemps que la durée moyenne sans panne d’un réseau, encore appelée MTBF d’un cluster (pour « Mean Time Between Failures » en langue anglaise), elles ont donc beaucoup de chances d’être interrompues. Elles n’ont en général pas de solution interne de gestion des pannes, ce peut alors entraîner d’abord la perte des données de sauvegarde locales en cas de panne physique du nœud de calcul, ensuite suivie de la perte de l’ensemble de l’avancement du calcul entraînée par la perte d’un seul nœud de calcul mais dont les données locales de sauvegarde ne peuvent plus être récupérées.
Il existe des solutions de sauvegarde et de redémarrage (« checkpoint/restart » en langue anglaise) à partir de sauvegarde permettant aux applications de sauvegarder leur contexte régulièrement sur différents niveaux de sauvegarde, plus ou moins rapides.
Les différents niveaux de sauvegarde vont de la sauvegarde la plus locale à la sauvegarde la plus globale, allant ainsi de la sauvegarde la plus simple et la plus rapide à la sauvegarde la plus complexe, la plus lente et la plus coûteuse, allant également ainsi de la sauvegarde la plus fragile et la plus faible à la sauvegarde la plus robuste et la plus résiliente.
Selon un art antérieur correspondant à la librairie FTI (« interface de tolérance aux pannes » ou bien « fault tolérance interface » en langue anglaise), il est connu quatre niveaux de sauvegarde qui sont :
Le premier niveau Ll qui réalise une sauvegarde locale, simple et peu coûteuse, effectuée très souvent, d’où une perte minime en temps de calcul lors d’une panne pouvant être récupérée à ce seul premier niveau Ll,
Le deuxième niveau L2 qui réalise une première sauvegarde intermédiaire par duplication sur un nœud partenaire, moins simple et plus coûteuse, d’où une perte plus importante en temps de calcul lors d’une panne ne pouvant être récupérée qu’à ce deuxième niveau L2,
Le troisième niveau L3, qui réalise une deuxième sauvegarde intermédiaire par encodage de type Reed-Solomon, encore moins simple et encore plus coûteuse, d’où une perte encore un peu plus importante en temps de calcul lors d’une panne ne pouvant être récupérée qu’à ce troisième niveau L3,
Le quatrième niveau L4, qui réalise une sauvegarde globale à un niveau système de fichier, complexe et très coûteuse, d’où une perte vraiment importante en temps de calcul lors d’une panne ne pouvant être récupérée qu’à ce quatrième niveau L4.
Du niveau local Ll au niveau global L4, la sauvegarde est de plus en plus robuste et résiliente, mais elle devient également de plus en plus complexe et coûteuse. C’est pour cela, que la sauvegarde du premier niveau Ll est réalisée souvent, la sauvegarde du deuxième niveau L2 moins souvent, la sauvegarde du troisième niveau L3 encore moins souvent, la sauvegarde du quatrième niveau L4 relativement rarement. Par conséquent, statistiquement, lorsqu’une panne survient, le dernier état cohérent qui peut être récupéré est, très récent au premier niveau Ll, moins récent au deuxième niveau L2, encore moins récent au troisième niveau L3, plus ancien au quatrième niveau L4. Par conséquent le volume de travail perdu est, très faible au premier niveau Ll, relativement limité au deuxième niveau L2, notable au troisième niveau L3, plus important ancien au quatrième niveau L4.
RESUME DE L’INVENTION
Le but de la présente invention est de fournir un procédé de gestion de panne dans un réseau de nœuds palliant au moins partiellement les inconvénients précités.
Plus particulièrement, l’invention vise à fournir un procédé de gestion de panne dans un réseau de nœuds améliorant le compromis entre efficacité d’une part et coût et complexité d’autre part, pour au moins un niveau de sauvegarde considéré.
Plus particulièrement, l’invention vise à fournir un procédé de gestion de panne dans un réseau de nœuds qui ait une efficacité similaire ou comparable à celle d’une sauvegarde de niveau intermédiaire, préférentiellement celle de la première sauvegarde intermédiaire, avantageusement celle du deuxième niveau L2, pour un coût et une complexité similaires ou comparables à ceux d’une sauvegarde de niveau local, avantageusement ceux du premier niveau Ll.
Pour cela, l’invention propose de rendre le lien entre un support de stockage et son nœud redirigeable vers un autre nœud, de manière à pouvoir disposer de la sauvegarde réalisée sur le support de stockage lorsque le nœud est défaillant, éventuellement par le biais d’une copie au niveau d’un nœud voisin, mais sans avoir réalisé de copie de sauvegarde au niveau d’un nœud voisin pour la plupart des nœuds qui ne sont pas défaillants ou pour tous les nœuds qui ne sont pas défaillants. Le lien entre un support de stockage et son nœud n’est pas réalisé directement, mais indirectement au travers d’un élément de réseau apte à reconfigurer ce lien pour rattacher ce support de stockage à un autre nœud lorsque le précédent nœud devient défaillant. Cet élément de réseau relie plusieurs nœuds à leurs supports de stockage respectifs, chaque nœud étant relié à son support de stockage associé (ou éventuellement à ses supports de stockage associés).
En résumé, pour un nœud défaillant, on dispose d’une sauvegarde malgré la défaillance de ce nœud, d’où une efficacité similaire au deuxième niveau L2, mais on ne réalise pas d’opération plus complexe qu’une simple sauvegarde locale pour la plupart ou pour tous les nœuds qui ne sont pas défaillants, ce qui est la majorité ou même la grande majorité des nœuds du réseau effectuant le calcul considéré, d’où un coût et une complexité du moins comparable sinon similaire à celles du premier niveau Ll.
Ainsi, selon des modes de réalisation de l’invention, le coût du deuxième niveau L2 est économisé, alors qu’est conservée la capacité à redémarrer une application à partir des sauvegardes du premier niveau Ll en cas de panne d’un nœud de calcul. La copie vers un nœud voisin traditionnellement effectuée au deuxième niveau L2 n’est ici pas réalisée pendant l’exécution de l’application de manière préventive pour tous les nœuds de calcul, mais seulement en cas de panne et seulement pour les nœuds défaillants après survenue de la panne. La copie est alors faite uniquement pour relancer l’application avec les données manquantes, remontées de la sauvegarde locale.
D’une part, cette sauvegarde de coût et de complexité similaires ou comparables à une sauvegarde locale présente l’efficacité d’une sauvegarde intermédiaire, ce qui améliore beaucoup le rapport qualité prix de cette sauvegarde. D’autre part, cette sauvegarde de coût et de complexité similaires ou comparables à une sauvegarde locale présentant l’efficacité d’une sauvegarde intermédiaire, permet préférentiellement de remplacer à la fois une sauvegarde locale classique et une ou plusieurs sauvegardes intermédiaires classiques, en ne gardant en plus que la sauvegarde globale en dernier recours, pour gérer les pannes les plus sévères, la plupart des pannes pouvant être maintenant gérées par la sauvegarde locale - intermédiaire proposée par l’invention, celle-ci ayant l’efficacité d’une sauvegarde intermédiaire pratiquement au prix d’une sauvegarde locale.
A cette fin, la présente invention propose un procédé de gestion de panne dans un réseau de nœuds, comprenant, pour chaque nœud considéré de tout ou partie des nœuds du réseau effectuant un même calcul : d’abord, une étape de sauvegarde locale de l’état de ce nœud considéré, au niveau d’un support de stockage de ce nœud considéré, le lien entre ce support de stockage et ce nœud considéré pouvant être redirigé de ce support de stockage vers un autre nœud, ensuite, une étape de relance : soit du nœud considéré si celui-ci n’est pas défaillant, à partir de la sauvegarde locale de l’état de ce nœud considéré, soit d’un nœud opérationnel différent du nœud considéré, si le nœud considéré est défaillant, à partir de la récupération de la sauvegarde locale de l’état de ce nœud considéré, en redirigeant ledit lien entre le nœud considéré et son support de stockage de manière à relier ledit support de stockage vers ledit nœud opérationnel, les sauvegardes locales de ces nœuds considérés, utilisées pour les étapes de relance, sont cohérentes entre elles de sorte à correspondre à un même état de ce calcul.
A cette fin, la présente invention propose également une partie d’un réseau de nœuds, comprenant : un commutateur, une pluralité de nœuds d’un groupe de nœuds effectuant un même calcul dans ce réseau de nœuds, plusieurs supports de stockage respectivement rattachés à ces nœuds par l’intermédiaire du commutateur, ces supports de stockage étant structurés et disposés pour sauvegarder localement l’état des nœuds auxquels ils sont respectivement rattachés, ce commutateur étant structuré et disposé pour changer au moins un rattachement entre un nœud défaillant et son support de stockage lequel va alors devenir rattaché à un autre nœud de ladite pluralité de nœuds.
Selon des modes de réalisation de l’invention, ce procédé de gestion de panne permet l’optimisation et la résilience de la sauvegarde de données d’une application susceptible de rencontrer une panne et le redémarrage de cette application à l’aide des données sauvegardées.
Selon des modes de réalisation de l’invention, ce procédé de gestion de panne offre la possibilité de migrer un support de stockage du nœud de calcul en panne grâce au commutateur, permettant alors d’exploiter directement les données locales sauvegardées d’un nœud de calcul en panne en un temps qui ne dépend que peu de la quantité de données sauvegardées.
Selon des modes de réalisation de l’invention, ce procédé de gestion de panne offre une tolérance aux pannes qui s’étend dans l’absolu à un grand nombre de nœuds de calcul tant qu’il existe, sur chaque nœud de calcul qui tombe en panne, un nœud de calcul rattaché au même commutateur qui pourra reprendre le calcul du nœud de calcul tombé en panne. Il est alors possible de repartir de la dernière sauvegarde locale, même si un grand nombre des nœuds de calcul tombe en panne, tant que chaque nœud de calcul tombé en panne dispose d’un commutateur et d’un nœud de calcul voisin non défaillant connecté au même commutateur.
Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles, appliquées à l’un ou à l’autre des objets de l’invention précités.
De préférence, pour chaque nœud considéré non défaillant : il n’y a pas d’étape de récupération par un autre nœud, de la sauvegarde locale de l’état de ce nœud considéré non défaillant.
Ainsi, pour tous les nœuds non défaillants, c’est-à-dire pour la grande majorité des nœuds du réseau effectuant un même calcul, aucune opération plus complexe qu’une simple sauvegarde locale n’a été réalisée. De préférence, le nœud opérationnel différent du nœud considéré défaillant est un nœud de rechange.
Ainsi, les nœuds non défaillants, qui ont déjà chacun leur propre tâche de calcul à effectuer, ne sont pas chargés en plus d’effectuer cette opération de récupération d’un nœud voisin défaillant. Une éventuelle surcharge de ces nœuds non défaillants est alors évitée.
De préférence, ladite redirection dudit lien entre le nœud considéré et son support de stockage de manière à relier ledit support de stockage vers ledit nœud opérationnel, est réalisée par un changement d’aiguillage dans un commutateur reliant plusieurs nœuds à leurs supports de stockage.
Ainsi, cette redirection est effectuée par une opération simple réalisée au niveau d’un élément de réseau qui est fiable et maîtrisé.
De préférence, toutes les étapes de relance de nœuds sont synchronisées entre elles, de manière à relancer tous lesdits nœuds dans un même état de calcul.
Ainsi, une complète cohérence du reste du calcul, effectué après la relance, est assurée.
De préférence, dans une première réalisation, l’étape de récupération comprenant une sous-étape de migration, vers le nœud opérationnel ou vers le nœud de rechange, du support de stockage de la sauvegarde locale de l’état du nœud défaillant, qui rattache, ce support de stockage de la sauvegarde locale de l’état du nœud défaillant, à un endroit prédéterminé de l’arborescence de fichiers de ce nœud opérationnel ou de ce nœud de rechange, ce nœud opérationnel ou ce nœud de rechange venant ensuite lire, à cet endroit prédéterminé, le lien vers la sauvegarde locale de l’état du nœud défaillant, lors de l’étape de relance de ce nœud opérationnel ou de ce nœud de rechange, aucune copie, de la sauvegarde locale de l’état du nœud défaillant, n’étant réalisée, au niveau d’un autre nœud.
Ainsi, la récupération est rendue encore plus simple, puisque même pour un nœud défaillant, il n’y a aucune duplication de sa sauvegarde locale qui est réalisée. Il n’y avait déjà pas de duplication réalisée pour la sauvegarde locale des nœuds non défaillants.
De préférence, le nœud de rechange et le nœud défaillant qu’il remplace appartiennent tous les deux à la même lame de calcul.
Ainsi, la redirection du lien entre support et nœud est effectuée plus simplement et plus rapidement, en raison de la proximité géographique entre eux du nœud de rechange et du nœud défaillant.
De préférence, dans une deuxième réalisation, l’étape de récupération comprend : d’abord, une sous-étape de migration, vers un nœud intermédiaire, du support de stockage de la sauvegarde locale de l’état du nœud défaillant, qui rattache, ce support de stockage de la sauvegarde locale de l’état du nœud défaillant, à un endroit prédéterminé de l’arborescence de fichiers de ce nœud intermédiaire, ensuite, une sous-étape de copie, de la sauvegarde locale de l’état du nœud défaillant, du support de stockage rattaché au nœud intermédiaire vers le support de stockage du nœud opérationnel ou du nœud de rechange, ce nœud opérationnel ou ce nœud de rechange venant ensuite lire son support de stockage, lors de son étape de relance.
Ainsi, même si la récupération, pour un nœud défaillant, réalise une duplication de sa sauvegarde locale, en revanche il n’y a pas besoin d’indiquer au nœud opérationnel ou au nœud de rechange à quel endroit aller chercher le lien vers le support de stockage du nœud défaillant à récupérer. Par contre, bien sûr, il n’y a toujours pas de duplication réalisée pour la sauvegarde locale des nœuds non défaillants.
La sous-étape de copie n’est pas nécessaire et peut être évitée en remontant le support de stockage au bon endroit dans l’arborescence de fichier du nœud de rechange comme dans la première réalisation décrite précédemment, ou bien en changeant simplement la configuration de la bibliothèque de tolérance aux pannes. Cette remontée est instantanée et permet alors d’éviter une copie supplémentaire qui pourrait prendre un peu de temps en fonction du volume de données à sauvegarder. De préférence, pour tout ou partie des nœuds du réseau effectuant un même calcul : le nœud de rechange et le nœud défaillant qu’il remplace appartiennent à des lames de calcul différentes.
Ainsi, la redirection du lien entre support et nœud peut être effectuée même en cas de panne importante et même relativement généralisée au niveau de toute une lame de calcul.
De préférence, toutes ces étapes sont réalisées pour tous les nœuds du réseau effectuant un même calcul.
Ainsi, le bénéfice du procédé de gestion de panne proposé par l’invention, est généralisé en étant étendu à l’ensemble des nœuds du réseau effectuant un même calcul.
De préférence, la sous-étape de migration change le rattachement du support de stockage de la sauvegarde locale de l’état du nœud défaillant en passant par l’intermédiaire d’un commutateur auquel était rattaché le nœud défaillant et son support de stockage de la sauvegarde locale de l’état du nœud défaillant, mais sans passer par le nœud défaillant lui-même.
Ainsi, la redirection peut être effectuée même en cas de panne physique complète du nœud défaillant.
De préférence, le changement de rattachement est réalisé par l’envoi d’une commande au commutateur, cette commande passant par l’un des nœuds rattachés au commutateur par un port de management.
Ainsi, c’est le port de management ou de gestion qui est affecté à la récupération des supports de stockage des nœuds défaillants rattachés à un même commutateur.
De préférence, ce commutateur est un commutateur PCIe
(« Peripheral Component Interconnect express » en langue anglaise).
Ainsi, ce commutateur est particulièrement avantageux car il est particulièrement adapté à pouvoir faire communiquer entre eux des périphériques sans devoir passer par l’intermédiaire d’un microprocesseur, donc en pouvant contourner un nœud de calcul défaillant par exemple. L’utilisation de ce commutateur PCIe permet de rattacher le support de stockage, par exemple un disque de stockage, contenant les sauvegardes locales du nœud de calcul en panne à un nœud de calcul de rechange. Cette opération est rapide et ne nécessite pas de copie systématique des données de sauvegarde locales, et en particulier pas pour les nœuds de calcul non défaillants.
De préférence, 3 à 10 nœuds sont rattachés à un même commutateur.
Ainsi, le commutateur peut gérer facilement ce petit groupe de nœuds pour lequel un seul nœud de rechange semble devoir être suffisant.
De préférence, le procédé de gestion de panne comprend aussi, pour tout ou partie des nœuds du réseau effectuant un même calcul : une étape de sauvegarde globale de l’ensemble de ces nœuds, réalisée moins souvent que l’ensemble des étapes de sauvegarde locales de ces nœuds.
Ainsi, avec d’une part la sauvegarde locale-intermédiaire proposée par l’invention pour de gérer la grande majorité des pannes de manière simple et efficace, et d’autre part la sauvegarde globale plus complexe et plus coûteuse mais réservée à une minorité de pannes sévères, un excellent compromis entre complexité globale et efficacité globale du procédé de gestion de panne proposé par l’invention est réalisé.
Dans le cadre d’une application tolérante aux pannes, en utilisant plusieurs niveaux de sauvegarde, comme ici une sauvegarde locale rapide et une sauvegarde globale distante plus complexe et plus coûteuse, le procédé de gestion de panne proposé par l’invention permet alors de redémarrer l’application, suite à une panne physique sur un nœud, même complète, et ceci dans la plupart des cas, en repartant de toutes les sauvegardes locales, plus récentes et moins coûteuses, au lieu de devoir repartir des sauvegardes distantes qui sont très souvent nettement plus anciennes, quelques cas plus rares de panne nécessitant parfois l’utilisation de la sauvegarde globale distante. La possibilité de récupérer les données locales du nœud de calcul en panne permet de redémarrer dans la plupart des cas l’application à partir des sauvegardes locales les plus récentes. De préférence, pour tout ou partie des nœuds du réseau effectuant un même calcul : le réseau comprend entre 1 et 5 nœuds de rechange pour 100 nœuds effectuant ledit même calcul.
Ainsi, le surdimensionnement de la taille du réseau est minime, tandis que la grande majorité des pannes ordinaires sera gérée de manière très efficace.
De préférence, pour tout ou partie des nœuds du réseau effectuant un même calcul : ce procédé de gestion de panne ne comprend aucun autre type de sauvegarde locale de l’état de ces nœuds.
Ainsi, la simplicité et le faible coût de ce type de sauvegarde locale- intermédiaire proposée par l’invention est d’une simplicité similaire à celle d’une sauvegarde purement locale, pour une efficacité bien supérieure.
De préférence, pour tout ou partie des nœuds du réseau effectuant un même calcul : les supports de stockage sont des mémoires flash.
Ainsi, les mémoires utilisées sont simples, rapides et permanentes.
De préférence, ces mémoires flash sont des mémoires NVMe (« Non Volatile Memory express » en langue anglaise).
Ainsi, les mémoires utilisées sont particulièrement bien adaptées pour communiquer avec un commutateur PCIe (« Peripheral Component Interconnect express » en langue anglaise).
De préférence, ce commutateur étant structuré et disposé pour changer au moins un rattachement entre un nœud défaillant et son support de stockage, sur commande extérieure au commutateur.
Ainsi, c’est le commutateur qui effectue la redirection du lien entre le support de stockage et son nœud défaillant, dès qu’un élément externe au commutateur a mis en évidence cette défaillance de nœud et l’a prévenu.
De préférence, ladite pluralité de nœuds comprend entre 3 et 10 nœuds.
Ainsi, le commutateur peut gérer facilement ce petit groupe de nœuds pour lequel un seul nœud de rechange semble devoir être suffisant.
De préférence, ce commutateur est un commutateur PCIe. Ainsi, ce commutateur est particulièrement avantageux car il est particulièrement adapté à pouvoir faire communiquer entre eux des périphériques sans devoir passer par l’intermédiaire d’un microprocesseur.
De préférence, les supports de stockage sont des mémoires flash, de préférence des mémoires NVMe.
Ainsi, les mémoires utilisées sont particulièrement bien adaptées pour communiquer avec un commutateur PCIe.
Préférentiellement, le réseau de nœuds de calcul comprend au moins 1000 nœuds de calcul, avantageusement au moins 5000 nœuds de calcul, encore plus avantageusement au moins 10000 nœuds de calcul, rendant d’autant plus intéressant le procédé de gestion de panne selon l’invention car la perte complète d’un calcul en cours devient alors d’autant plus critique que le réseau est grand.
Le principe de tolérance aux pannes est d’autant plus important qu’une application s’exécute sur un cluster qui est constitué d’un plus grand nombre de nœuds de calcul. Plus le nombre de processeurs, mémoires et autres périphériques, est important, plus la probabilité qu’une panne survienne avant la fin de l’exécution est grande. Les applications qui ont pour but de s’exécuter sur ce type de plateforme vont utiliser des librairies de tolérance aux pannes qui leur permettent de sauvegarder (« checkpoint » en langue anglaise) les données nécessaires à un redémarrage (« restart » en langue anglaise) dans un état le plus proche possible de l’état qui existait juste avant la panne. Ainsi, ces applications ne sont pas contraintes de recommencer le calcul depuis le début.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS
La figure 1 représente schématiquement un exemple, d’une partie de réseau incluant un groupe de nœuds et leurs supports de stockage reliés entre eux par un commutateur PCIe, selon un mode de réalisation de l’invention, au niveau de laquelle partie de réseau, un exemple de procédé de gestion de panne selon l’invention peut se dérouler.
DESCRIPTION DETAILLEE DE L’INVENTION
La figure 1 représente schématiquement un exemple, d’une partie de réseau incluant un groupe de nœuds et leurs supports de stockage reliés entre eux par un commutateur PCIe, selon un mode de réalisation de l’invention, au niveau de laquelle partie de réseau, un exemple de procédé de gestion de panne selon l’invention peut se dérouler.
Cette partie de réseau comprend plusieurs nœuds de calcul 2, trois nœuds de calcul 21, 22 et 23, dans l’exemple de la figure 1, ainsi que plusieurs supports de stockage 3, trois supports de stockage 31, 32 et 33, dans l’exemple de la figure 1.
Ces nœuds de calcul 2 et leurs supports de stockage 3 forment un groupe de nœuds de calcul géré par un commutateur PCIe 1 reliant ces nœuds de calcul 2 à leurs supports de stockage 3 respectifs, par l’intermédiaire de connexions bidirectionnelles PCIe 7, 8 ou 9. Ces connexions PCIe 7, 8 ou 9, peuvent être des connexions PCIe à plusieurs voies. La connexion 7 est une connexion à 4 voies. La connexion 8 est une connexion à 4 voies. La connexion 9 est une connexion à 2 voies, ici non encore utilisée, chaque connexion 9 étant d’un côté rattachée à l’un des ports 13, 16 ou 19 et restant libre de l’autre côté. Chaque connexion PCIe 7 relie respectivement l’un des nœuds de calcul 21 à 23 à l’un des ports 0, 2 ou 8 (numérotation du commutateur électronique PLX 8733, mais un autre Switch PCIe peut être utilisé), respectivement référencés 11, 14 ou 17 sur la figure 1, du commutateur 1. Chaque connexion PCIe 8 relie respectivement l’un des supports de stockage 31 à 33 à l’un des ports 1, 3 ou 9, respectivement référencés 12, 15 ou 18 sur la figure 1, du commutateur 1. La connexion 7, les ports 0 et 1, respectivement référencés 11 et 12 sur la figure 1, du commutateur 1, la connexion 8 forment ensemble un lien 4 reliant le nœud de calcul 23 à son support 33. La connexion 7, les ports 2 et 3, respectivement référencés 14 et 15 sur la figure 1, du commutateur 1, la connexion 8 forment ensemble un lien 5 reliant le nœud de calcul 22 à son support 32. La connexion 7, les ports 8 et 9, respectivement référencés 17 et 18 sur la figure 1, du commutateur 1, la connexion 8 forment ensemble un lien 6 reliant le nœud de calcul 21 à son support 31. Les connexions PCIe 7, 8 ou 9, peuvent être regroupées sur un bus PCIe.
Le nœud de calcul 23 est rattaché au port de gestion ou de management par défaut, c’est-à-dire que c’est par lui que transite les envois vers l’extérieur du groupe de nœuds de calcul 2 et les réceptions en provenance de l’extérieur du groupe de nœuds de calcul 2. En cas de défaillance de ce nœud de calcul 23, celui-ci est remplacé par le nœud de calcul 22 qui est rattaché au port de gestion ou de management redondant, lequel nœud de calcul 22 devient alors rattaché au nouveau port de gestion ou de management effectif.
Lorsqu’un nœud de calcul tombe en panne physique, par exemple le nœud de calcul 21 ou le nœud de calcul 22, considérons ici le nœud de calcul 21, la dernière sauvegarde locale récente de son état de calcul est stockée sur son support de stockage 31.
Dans un système selon l’art antérieur, le support de stockage 31 n’étant accessible que par son nœud de calcul 21 et celui-ci étant en panne physique complète, cette sauvegarde locale récente deviendrait inaccessible, et il faudrait alors recourir à d’autres niveaux de sauvegarde plus complexes et moins récents, d’où une perte importante d’efficacité globale pour le réseau informatique. Dans le système selon un mode de réalisation de l’invention, présenté à la figure 1, le rattachement du support de stockage 31 est reconfiguré, c’est-à-dire que le support de stockage 31 va cesser d’être relié à son nœud de calcul 21 de rattachement par défaut, mais va devenir relié au nœud de calcul 23, lequel étant rattaché au port de gestion par défaut, va pouvoir faire remonter la sauvegarde locale de l’état de calcul du nœud de calcul 21 défaillant, depuis le support de stockage 31, vers un autre nœud de calcul de rechange extérieur au groupe de nœuds de calcul 21 à 23, cet autre nœud de calcul reprenant alors à son compte la tâche de calcul interrompue au niveau du nœud de calcul 21 défaillant, à partir de la sauvegarde locale de l’état de calcul du nœud de calcul 21 remontée depuis le support de stockage 31.
Dans le commutateur 1, le port 9 (numérotation du commutateur électronique PLX8733, mais un autre Switch PCIe peut être utilisé) référencé 18 (sur la figure 1), au lieu de rester relié en permanence au port 8 référencé 17 comme avant la défaillance du nœud de calcul 21, va être, au moins temporairement relié au port 0 référencé 11, afin de permettre au nœud de calcul 23 de venir lire, dans le support de stockage 31, les données sauvegardées représentatives de l’état de calcul du nœud de calcul 21, juste avant ou peu de temps avant, sa défaillance. Ainsi, la sauvegarde locale, dans le support de stockage 31, de l’état de calcul du nœud de calcul 21 avant sa défaillance, va pouvoir remonter jusqu’au nœud de calcul 23 et être ainsi exploitée pour relancer le calcul avec un très bon compromis entre simplicité de la sauvegarde et efficacité de la relance.
Alternativement, si le nœud de calcul 23 est lui-même un nœud de rechange, il peut reprendre à son compte la tâche de calcul interrompue par le nœud de calcul 21 défaillant.
Si c’est le nœud 23 qui devient défaillant, il est d’abord remplacé par le nœud de calcul 22 comme rattaché au port de management, et le nœud de calcul 22, comme rattaché au nouveau port de management, réalise les opérations auparavant réalisés par le nœud de calcul 23 si celui-ci n’était pas devenu défaillant. La gestion du commutateur 1 est maintenant décrite par un scénario manuel clarifiant et expliquant les différentes opérations à effectuer, comme par exemple la migration du support de stockage 31 d’un nœud de calcul défaillant 21 à un nœud de calcul de rechange 23, le transfert des données, le redémarrage de l’application. La gestion des données côté applicatif est abstraite par la librairie FTI.
L’application exécutée est fournie dans les exemples de la librairie FTI : hdf.exe. Cette application est lancée sur deux nœuds de calcul. Elle va réaliser des sauvegardes locales, sur les disques de stockage NVMe reliés à ces nœuds de calcul par le commutateur PCIe à intervalles réguliers ainsi qu’une sauvegarde globale sur un serveur NFS (« Network File System » en langue anglaise) de façon moins fréquente. Une fois l’application lancée, une panne est générée sur un des deux nœuds de calcul. La migration du disque de stockage NVMe du nœud défaillant vers un autre nœud va alors permettre le transfert des données de la dernière sauvegarde locale de ce nœud défaillant vers le nœud de rechange. Une fois ce transfert réalisé, l’application peut être relancée et reprend le calcul à la dernière sauvegarde locale des deux nœuds de calcul au lieu de la dernière sauvegarde globale plus ancienne de la partie de réseau.
Dans ce contexte, une reprise sur panne est réalisée avec les données locales de sauvegarde d’une application MPI (« Message Passing Interface » en langue anglaise) d’un nœud de calcul tombant en panne. Les données sont récupérées grâce à la migration du support de stockage du nœud de calcul défaillant sur un nœud de calcul voisin de la même lame de calcul. Ces données sont ensuite transmises à un second nœud de rechange qui reprendra le calcul. L’intérêt de cette reprise sur panne est qu’elle permet à l’application de redémarrer à partir des sauvegardes locales de tous les nœuds de calcul. Ces sauvegardes locales moins coûteuses sont également plus récentes la plupart du temps, et ne sont au pire qu’ aussi récentes, que les sauvegardes globales. De plus, la quantité de données transférées afin de reprendre le calcul va être bien plus faible que dans le cas d’un redémarrage à partir d’une sauvegarde globale.
Dans le développement qui suit, les parties de texte dans un encadré ou bien entre crochets concernent des lignes de code informatique.
La configuration de la librairie FTI a été modifiée [« config.fti » dans le répertoire « examples »], afin d’autoriser l’exécution sur deux nœuds de calcul différents :
Sur chacun des deux nœuds de calcul, appelés ici Nl (référencé 21 sur la figure 1) et N2 (référencé 22 sur la figure 1), le répertoire de sauvegarde locale [« /localckpt/ »] est un montage du disque de stockage SSD (« Solid State Disk » en langue anglaise) disponible sur chaque nœud de calcul, le disque de stockage S0 (référencé 31 sur la figure 1) sur le nœud de calcul Nl et le disque de stockage Sl (référencé 32 sur la figure 1) sur le nœud de calcul N2 :
Une panne du nœud de calcul Nl est provoquée, causant alors une interruption du calcul de ce nœud de calcul N 1 :
[$ ipmitool -H bmc-Nl -Uuser -Ppass power off]
Dans la trace précédente, les sauvegardes locales de premier niveau Ll sont différenciées des sauvegardes globales de quatrième niveau L4. Le calcul a été interrompu après avoir fait une sauvegarde globale de quatrième niveau L4 et une sauvegarde locale de premier niveau Ll plus récente que la sauvegarde globale de quatrième niveau L4, ce qui statistiquement correspondra à la grande majorité, pour ne pas dire à la quasi-totalité, des cas de survenue de panne en pratique.
Le nœud de calcul N 1 étant considéré en panne, le disque de stockage S0 qui lui était attaché va être migré vers un autre nœud de calcul, ici le nœud de calcul N3 (référencé 23 sur la figure 1). Le nœud de calcul N3 est le nœud qui possède le port d’administration du commutateur.
La première étape est d’envoyer la commande qui permet de router à nouveau la remise à zéro PCI (« reset » en langue anglaise), le dernier argument étant le numéro du nœud fautif ou défaillant :
[$ ipmitool -Hpm-bmc-N3 -Usuper -Ppass raw 0x3a Oxcd 1]
Cette commande peut être exécutée des nœuds voisins ou du nœud de management ou de gestion.
L’état des ports du commutateur (référencé 1 sur la figure 1) est vérifié :
Le port 9 (référencé 18 sur la figure 1) du commutateur, sur lequel se trouve le disque de stockage S0 du nœud de calcul fautif ou défaillant Nl au nœud de calcul courant N3 :
P est demandé au système de scanner à nouveau le bus PCIe :
$ écho 1 > /sys/bus/pei/deviees/0000:00:00.0/rescan
Le disque de stockage S0 est désormais vu :
Une fois le disque de stockage S0 migré, les données qui y sont sauvegardées peuvent être accédées en montant le système de fichiers :
[$ mount /dev/nvmelnl /localckpt_restore/]
Les données sauvegardées récupérées sont alors transmises au nœud de calcul de rechange en charge de remplacer le nœud de calcul Nl en panne. Il peut s’agir du même nœud que le nœud N3 en charge de la récupération des données sauvegardées sur le disque de stockage S0.
Les données sauvegardées puis récupérées étant alors transmises au nœud de calcul désigné de rechange (« spare » en langue anglaise), il ne reste alors plus qu’à relancer l’application en changeant le nœud de calcul Nl en panne par ce dernier nœud de calcul de rechange dans la commande « mpirun » :
P peut être constaté que le calcul (qui détermine ici la valeur d’une erreur valant 0.04888) a donc bien repris à partir des sauvegardes locales de premier niveau Ll.
Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.

Claims

REVENDICATIONS
1. Procédé de gestion de panne dans un réseau de nœuds (2), comprenant, pour chaque nœud considéré (2) de tout ou partie des nœuds (2) du réseau effectuant un même calcul :
d’abord, une étape de sauvegarde locale de l’état de ce nœud considéré (21), au niveau d’un support de stockage (31) de ce nœud considéré (21), le lien (6) entre ce support de stockage (31) et ce nœud considéré (21) pouvant être redirigé de ce support de stockage (31) vers un autre nœud (23),
ensuite, une étape de relance :
o soit du nœud considéré (21) si celui-ci n’est pas défaillant, à partir de la sauvegarde locale de l’état de ce nœud considéré (21),
o soit d’un nœud opérationnel (23) différent du nœud considéré (21), si le nœud considéré (21) est défaillant, à partir de la récupération de la sauvegarde locale de l’état de ce nœud considéré (21), en redirigeant ledit lien (6) entre le nœud considéré (21) et son support de stockage (31) de manière à relier ledit support de stockage (31) vers ledit nœud opérationnel (23),
les sauvegardes locales de ces nœuds considérés (2), utilisées pour les étapes de relance, sont cohérentes entre elles de sorte à correspondre à un même état de ce calcul.
2. Procédé de gestion de panne selon la revendication 1, caractérisé en ce que :
pour chaque nœud considéré non défaillant (22) :
o il n’y a pas d’étape de récupération par un autre nœud (23), de la sauvegarde locale de l’état de ce nœud considéré non défaillant (22).
3. Procédé de gestion de panne selon la revendication 1 ou 2, caractérisé en ce que le nœud opérationnel (23) différent du nœud considéré (21) défaillant est un nœud de rechange (23).
4. Procédé de gestion de panne selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite redirection dudit lien (6) entre le nœud considéré (21) et son support de stockage (31) de manière à relier ledit support de stockage (31) vers ledit nœud opérationnel (23), est réalisée par un changement d’aiguillage dans un commutateur (1) reliant plusieurs nœuds (21, 22, 23) à leurs supports de stockage (31, 32, 33).
5. Procédé de gestion de panne selon l’une quelconque des revendications précédentes, caractérisé en ce que toutes les étapes de relance de nœuds (2) sont synchronisées entre elles, de manière à relancer tous lesdits nœuds (2) dans un même état de calcul.
6. Procédé de gestion de panne selon l’une quelconque des revendications 1 à 5, caractérisé en ce que :
l’étape de récupération comprenant une sous-étape de migration, vers le nœud opérationnel (23) ou vers le nœud de rechange (23), du support de stockage (31) de la sauvegarde locale de l’état du nœud défaillant (21), qui rattache, ce support de stockage (31) de la sauvegarde locale de l’état du nœud défaillant (21), à un endroit prédéterminé de l’arborescence de fichiers de ce nœud opérationnel (23) ou de ce nœud de rechange (23), ce nœud opérationnel (23) ou ce nœud de rechange (23) venant ensuite lire, à cet endroit prédéterminé, le lien vers la sauvegarde locale de l’état du nœud défaillant (21), lors de l’étape de relance de ce nœud opérationnel (23) ou de ce nœud de rechange (23), aucune copie, de la sauvegarde locale de l’état du nœud défaillant (21), n’étant réalisée, au niveau d’un autre nœud (23).
7. Procédé de gestion de panne selon la revendication 6, caractérisé en ce que le nœud de rechange (23) et le nœud défaillant (21) qu’il remplace appartiennent tous les deux à la même lame de calcul.
8. Procédé de gestion de panne selon l’une quelconque des revendications 1 à 5, caractérisé en ce que l’étape de récupération comprend :
d’abord, une sous-étape de migration, vers un nœud intermédiaire (23), du support de stockage (31) de la sauvegarde locale de l’état du nœud défaillant (21), qui rattache, ce support de stockage (31) de la sauvegarde locale de l’état du nœud défaillant (21), à un endroit prédéterminé de l’arborescence de fichiers de ce nœud intermédiaire (23),
ensuite, une sous-étape de copie, de la sauvegarde locale de l’état du nœud défaillant (21), du support de stockage (31) rattaché au nœud intermédiaire (23) vers le support de stockage du nœud opérationnel ou du nœud de rechange, ce nœud opérationnel ou ce nœud de rechange venant ensuite lire son support de stockage, lors de son étape de relance.
9. Procédé de gestion de panne dans un réseau de nœuds, selon la revendication 8, caractérisé en ce que, pour tout ou partie des nœuds (2) du réseau effectuant un même calcul, le nœud de rechange (23) et le nœud défaillant (21) qu’il remplace appartiennent à des lames de calcul différentes.
10. Procédé de gestion de panne selon l’une quelconque des revendications précédentes, caractérisé en ce que toutes ces étapes sont réalisées pour tous les nœuds (2) du réseau effectuant un même calcul.
11. Procédé de gestion de panne selon l’une quelconque des revendications 6 à 10, caractérisé en ce que la sous-étape de migration change le rattachement du support de stockage (31) de la sauvegarde locale de l’état du nœud défaillant (21) en passant par l’intermédiaire d’un commutateur (1) auquel était rattaché le nœud défaillant (21) et son support de stockage (31) de la sauvegarde locale de l’état du nœud défaillant (21), mais sans passer par le nœud défaillant (21) lui-même.
12. Procédé de gestion de panne selon la revendication 11, caractérisé en ce que le changement de rattachement est réalisé par l’envoi d’une commande au commutateur (1), cette commande passant par l’un des nœuds (23) rattachés au commutateur (1) par un port de management
(H).
13. Procédé de gestion de panne selon la revendication 11 ou 12, caractérisé en ce que ce commutateur (1) est un commutateur PCIe.
14. Procédé de gestion de panne selon l’une quelconque des revendications 11 à 13, caractérisé en ce que 3 à 10 nœuds (2) sont rattachés à un même commutateur (1).
15. Procédé de gestion de panne selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend aussi, pour tout ou partie des nœuds du réseau effectuant un même calcul, une étape de sauvegarde globale de l’ensemble de ces nœuds (2), réalisée moins souvent que l’ensemble des étapes de sauvegarde locales de ces nœuds (2).
16. Procédé de gestion de panne selon l’une quelconque des revendications
3 à 15, caractérisé en ce que, pour tout ou partie des nœuds (2) du réseau effectuant un même calcul, le réseau comprend entre 1 et 5 nœuds de rechange (23) pour 100 nœuds (2) effectuant ledit même calcul.
17. Procédé de gestion de panne selon l’une quelconque des revendications précédentes, caractérisé en ce que, pour tout ou partie des nœuds (2) du réseau effectuant un même calcul, ce procédé de gestion de panne ne comprend aucun autre type de sauvegarde locale de l’état de ces nœuds (2).
18. Procédé de gestion de panne selon l’une quelconque des revendications précédentes, caractérisé en ce que, pour tout ou partie des nœuds (2) du réseau effectuant un même calcul, les supports de stockage (3) sont des mémoires flash.
19. Procédé de gestion de panne selon la revendication 18, caractérisé en ce que ces mémoires flash (3) sont des mémoires NYMe.
20. Partie d’un réseau de nœuds, comprenant :
un commutateur (1),
une pluralité de nœuds (2) d’un groupe de nœuds effectuant un même calcul dans ce réseau de nœuds,
plusieurs supports de stockage (3) respectivement rattachés à ces nœuds (2) par l’intermédiaire du commutateur (1),
ces supports de stockage (3) étant structurés et disposés pour sauvegarder localement l’état des nœuds (2) auxquels ils sont respectivement rattachés,
ce commutateur (1) étant structuré et disposé pour changer au moins un rattachement entre un nœud défaillant (21) et son support de stockage (31) lequel va alors devenir rattaché à un autre nœud (23) de ladite pluralité de nœuds (2).
21. Partie d’un réseau de nœuds selon la revendication 20, caractérisée en ce que ce commutateur (1) étant structuré et disposé pour changer au moins un rattachement entre un nœud défaillant (21) et son support de stockage (31), sur commande extérieure au commutateur (1).
22. Partie d’un réseau de nœuds selon la revendication 20 ou 21, caractérisée en ce que ladite pluralité de nœuds (2) comprend entre 3 et 10 nœuds.
23. Partie d’un réseau de nœuds selon l’une quelconque des revendications
20 à 22, caractérisée en ce que ce commutateur (1) est un commutateur PCIe.
24. Partie d’un réseau de nœuds selon l’une quelconque des revendications 20 à 23, caractérisée en ce que les supports de stockage (3) sont des mémoires flash, de préférence des mémoires NYMe.
EP18842811.4A 2017-12-27 2018-12-21 Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee Pending EP3732573A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1763237A FR3076004B1 (fr) 2017-12-27 2017-12-27 Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee
PCT/FR2018/053535 WO2019129986A1 (fr) 2017-12-27 2018-12-21 Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee

Publications (1)

Publication Number Publication Date
EP3732573A1 true EP3732573A1 (fr) 2020-11-04

Family

ID=62143294

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18842811.4A Pending EP3732573A1 (fr) 2017-12-27 2018-12-21 Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee

Country Status (4)

Country Link
US (1) US11249868B2 (fr)
EP (1) EP3732573A1 (fr)
FR (1) FR3076004B1 (fr)
WO (1) WO2019129986A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110324375B (zh) * 2018-03-29 2020-12-04 华为技术有限公司 一种信息备份方法及相关设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100199128A1 (en) * 2009-01-30 2010-08-05 International Business Machines Corporation Fanout connectivity structure for use in facilitating processing within a parallel computing environment
US20120185727A1 (en) * 2011-01-17 2012-07-19 Doe Hyun Yoon Computing system reliability

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6054052A (ja) 1983-09-02 1985-03-28 Nec Corp 処理継続方式
US5696895A (en) * 1995-05-19 1997-12-09 Compaq Computer Corporation Fault tolerant multiple network servers
US7434096B2 (en) * 2006-08-11 2008-10-07 Chicago Mercantile Exchange Match server for a financial exchange having fault tolerant operation
JP5068056B2 (ja) * 2006-10-11 2012-11-07 株式会社日立製作所 障害回復方法、計算機システム及び管理サーバ
CN102037709B (zh) 2008-05-21 2015-08-12 艾利森电话股份有限公司 刀片集群交换中心服务器中的资源池化
JP6056509B2 (ja) * 2013-01-30 2017-01-11 富士通株式会社 情報処理装置および情報処理装置の制御方法
US9026846B2 (en) * 2013-03-15 2015-05-05 Lsi Corporation Data recovery in a raid controller by offloading contents of DRAM to a flash module on an SAS switch
JP5903524B2 (ja) * 2013-03-15 2016-04-13 株式会社日立製作所 計算機切替方法、計算機システム、及び管理計算機
US9619389B1 (en) * 2013-07-11 2017-04-11 Unigen Corporation System for a backward and forward application environment compatible distributed shared coherent storage
US9921926B2 (en) * 2014-01-16 2018-03-20 Hitachi, Ltd. Management system of server system including a plurality of servers
US9280432B2 (en) * 2014-03-21 2016-03-08 Netapp, Inc. Providing data integrity in a non-reliable storage behavior
US9588853B2 (en) * 2014-06-05 2017-03-07 International Business Machines Corporation Automatic management of server failures

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100199128A1 (en) * 2009-01-30 2010-08-05 International Business Machines Corporation Fanout connectivity structure for use in facilitating processing within a parallel computing environment
US20120185727A1 (en) * 2011-01-17 2012-07-19 Doe Hyun Yoon Computing system reliability

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of WO2019129986A1 *
ZIZHONG CHEN ET AL: "Fault tolerant high performance computing by a coding approach", PROCEEDINGS OF THE TENTH ACM SIGPLAN SYMPOSIUM ON PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING , PPOPP '05, 1 January 2005 (2005-01-01), New York, New York, USA, pages 213, XP055001673, ISBN: 978-1-59-593080-4, DOI: 10.1145/1065944.1065973 *

Also Published As

Publication number Publication date
WO2019129986A1 (fr) 2019-07-04
US20210073091A1 (en) 2021-03-11
US11249868B2 (en) 2022-02-15
FR3076004B1 (fr) 2021-03-19
FR3076004A1 (fr) 2019-06-28

Similar Documents

Publication Publication Date Title
US9672372B2 (en) Method for improving mean time to data loss (MTDL) in a fixed content distributed data storage
US10425480B2 (en) Service plan tiering, protection, and rehydration strategies
EP2092442B1 (fr) Récupération rapide d'un groupe primaire
US7657780B2 (en) Enterprise service availability through identity preservation
US20070143374A1 (en) Enterprise service availability through identity preservation
US10216775B2 (en) Content selection for storage tiering
US20070168500A1 (en) Enterprise service availability through identity preservation
CN101501668A (zh) 通过身份保持的企业服务可利用性
US20070150526A1 (en) Enterprise server version migration through identity preservation
US20070143373A1 (en) Enterprise server version migration through identity preservation
FR2859294A1 (fr) Systeme de reseau de disques et procede de commande d'informations d'erreur
FR2946769A1 (fr) Procede et dispositif de reconfiguration d'avionique.
WO2010034920A1 (fr) Determination et gestion de reseaux virtuels
EP3588294A2 (fr) Procédé de gestion de panne dans un réseau de noeuds basé sur une stratégie globale
EP3732573A1 (fr) Procede de gestion de panne dans un reseau de noeuds et partie de reseau de noeuds associee
US20120323869A1 (en) File State Subset Satellites to Provide Block-Based Version Control
FR3082973A1 (fr) Procede de gestion de panne dans un reseau de noeuds base sur une strategie locale
EP2799994A1 (fr) Procédé et dispositif de sauvegarde de données dans une infrastructure informatique offrant des fonctions de reprise d'activité
EP3765959A1 (fr) Gestion des donnees de configuration pour un serveur multimodule
FR3039347A1 (fr) Procede de sauvegarde de l'environnement de travail d'une session d'un utilisateur sur un serveur
WO1997030393A1 (fr) Systeme informatique a transparence de panne pour les applications utilisateur

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200626

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220413

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERGIES ALTERNATIVES

Owner name: BULL SAS

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230330

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERGIESALTERNATIVES

Owner name: BULL SAS