EP2353277A1

EP2353277A1 - Method and system for synchronizing a set of software modules of a computing system distributed as a cluster of servers

Info

Publication number: EP2353277A1
Application number: EP09768166A
Authority: EP
Inventors: Dominique Vinay; Loïc LAMBERT; Philippe Motet; Soazig David
Original assignee: Active Circle SA
Current assignee: Active Circle SA
Priority date: 2008-11-10
Filing date: 2009-11-10
Publication date: 2011-08-10
Also published as: US20110218962A1; FR2938356B1; WO2010052441A1; JP2012508412A; FR2938356A1

Abstract

According to this method of synchronizing a set of software modules of a computing system, each software module is executed on a server of the computing system for the management of a digital data set. The synchronization between two software modules of the set comprises a synchronization (102, 104, 110) of the common data that they manage. This method comprises a grouping together (106, 112) of software modules of the set, which are activated and synchronized mutually, into at least one synchronized sub-set and an identification of this sub-set, and, for each candidate software module following its booting or rebooting, activated but not synchronized with at least one other software module: search (100) for another activated software module of the set; if another activated software module is found and if it belongs to an identified sub-set, synchronization (102, 104) of the candidate software module with at least one of the software modules of this identified sub-set; integration (106) of the candidate software module into the identified sub-set.

Description

METHOD AND SYSTEM FOR SYNCHRONIZING A SET OF SOFTWARE MODULES OF A COMPUTER SYSTEM DISTRIBUTED TO A CLUSTER OF SERVERS

The present invention relates to a method and system for synchronizing a set of software modules of a distributed computer system into a plurality of interconnected networked servers. It also relates to a computer program for the implementation of this method.

The invention applies more particularly to a computer system in which each software module executes on a server of the computer system for the management of a set of digital data, at least part of which digital data is replicated on several modules. software, and wherein the synchronization between two software modules of the set includes a synchronization of the common data they manage. The digital data is, for example, data describing a service and the service provided by the computer system is for example a data storage service distributed between the networked interconnected servers, each server being connected to disk storage devices. hard or magnetic tape. In this case, the digital data comprise, for example, description data of users of the storage service, data describing the infrastructure and the operation of the computer system for providing the service, and description data of the stored data. and their storage mode.

The service provided by the computer system can also be an information data transmission, data processing, calculation, transaction or a combination of these services. In each case, the description data is adapted specifically to the service provided.

The servers of the computer system on which the software modules run are generally interconnected by at least one LAN (of the "Local Area Network") and / or WAN (of the "Wide Area Network") network. . This set of servers interconnected network can be called "server cluster", the software modules are usually called "nodes" of the cluster.

In such an architecture, a server or a particular software module is in principle dedicated to the management of all the software modules, especially for the synchronization of the replicated digital data. This poses problems when the server or the software module dedicated to the management of the set is faulty.

For example, in the patent application published under the number FR 2 851 709, provision is made for a service to be provided, via a communication network, to a user by a main server associated with a database. Auxiliary servers connected to this main server are also provided in the communication network to make this service more quickly accessible to the user. But they must then be synchronized with the main server, including its database. To achieve this synchronization of the main server to the auxiliary servers, the communication network is provided with specific means of synchronization, for example implemented in resource servers. It thus appears that certain elements of the communication network, the main server and the resource servers, have a very particular role and their failure may have immediate consequences on the quality of service provided.

In the patent application published under the number US 2007/0233900, a computer cluster system provides that several computers can copy locally the same data from common storage means. To manage the synchronization of all the copies of the same data, a system of coupling between the computers provides for the updating of the common storage means whenever a locally copied data is modified by a computer, so that the other computers can update their copied data locally, with reference to the common storage means. Here again, the architecture of the system provides a particular role for the coupling system and the common storage means.

Centralizing the synchronization of software modules, in the sense of a synchronization of the common digital data that they manage, is nevertheless the most simple solution possible. By distributing this synchronization over several or even all the servers of the computer system, this poses problems of coordination of the servers. So today there is no completely satisfactory solution.

It may thus be desirable to provide a method of synchronizing software modules of a computer system distributed in several servers interconnected network that allows to overcome at least some of the problems and constraints mentioned above.

The subject of the invention is therefore a method for synchronizing a set of software modules of a distributed computer system into a plurality of interconnected networked servers, each software module executing on a server of the computer system for the management of a set digital data of which at least a part is replicated on several software modules, wherein the synchronization between two software modules of the set comprises a synchronization of the common data that they manage, characterized in that it comprises the following steps:

grouping software modules of the set, activated and synchronized with each other, into at least one synchronized subset and identification of this subset, and

for each candidate software module following its startup or restart, activated but not synchronized with at least one other software module of the set:

- search for another activated software module of the set,

if another activated software module is found and if it belongs to an identified subset, synchronization of the candidate software module with at least one of the software modules of this identified subset, and

- integration of the candidate software module into the identified subset. Thus, while avoiding centralized synchronization, since each software module activated but not yet synchronized itself manages its synchronization with another software module of the set, the global tracking of the synchronization of all the software modules is ensured by the presence and revolution management of homogeneous subsets of synchronized software modules. These subsets are identified to enable their tracking.

Optionally, for each candidate software module, if another software module is found but does not belong to an identified subset: - a new synchronized subset is created and identified,

the candidate software module is synchronized with the other software module found, and

the candidate software module and this other software module found are integrated in this new identified subset. Also optionally, during the synchronization of the candidate software module with at least one of the software modules of the identified subset comprising the other software module found, the choice of at least one software module of this subset identified. to achieve synchronization is a function of a workload of at least a portion of the software modules of this identified subset. It is thus possible to advantageously distribute the workload caused by the synchronization itself.

Optionally also, a synchronization method according to the invention may further comprise the following steps: detection, by a first identified subset, of a second identified subset,

- grouping of the software modules of these two subsets identified in one of these two identified subsets,

- deleting the other of these two subsets identified, and - synchronization of each software module initially part of the subset deleted with at least one of the software modules of the subset chosen for the grouping.

Thus, this synchronization method tends to favor the fusion between homogeneous subsets as long as the complete synchronization of all the software modules of the set is not obtained.

Also optionally, in each identified subset, a software module is selected to be specifically marked as an identifier of that identified subset.

This software module selected in each subset then acts as a marker allowing all the other software modules to recognize their belonging to an identified subset.

Optionally also, a synchronization method according to the invention may further comprise the following steps:

detection of a connection break between two complementary parts of an identified subset, each comprising at least one software module,

from this identified subset, generation and identification of two subsets integrating one or the other of the two complementary parts. Thus, since a break is a source of impossibility to maintain synchronization of the software modules of the same subset, this method provides for the separation of each subset into two subsets as soon as such a connection break is detected. Optionally also, a synchronization method according to the invention may further comprise the following steps:

execution, on a first software module belonging to an identified subset, of an action acting on a digital datum managed by this first software module, transmitting a synchronization message identifying the action to all the others software modules of the same identified subset including a replication of this numerical data,

- On receipt of this message by any of the software modules concerned, execution of the action identified on this software module so as to act on the replication of the digital data located on this software module.

Thus, in each subset constituted and identified, there is provided a permanent synchronization mechanism of the software modules between them particularly effective and not centralized. Indeed, the execution of an action on a first software module of a subset has the consequence, through the transmission of a message identifying this action, the execution of this same action on all other software modules of the same subset managing a replication of the digital data concerned by this action. Therefore, whatever the software module on which the action is first executed, it performs a function of synchronization manager in the subset and the result is the same: everything happens as if the action was executed on all the software modules containing the numerical data concerned by the action, in the subset considered. Thus, no software module plays a privileged or particular role from the point of view of digital data management, which makes the entire computer system less vulnerable to service continuity failures in the event of a failure of a software module or a problem. server.

during the synchronization of the candidate software module, which comprises a part of the digital data, extraction of a state of the replications of this part of the digital data on at least one other software module, and registration of the candidate software module as a potential receiver of at least one synchronization message identifying an action on a replication of its digital data located on another software module,

synchronization of the digital data of the software module with the digital data of the other software module and, during this synchronization, queuing of the synchronization messages possibly received, once the synchronization is completed, processing of the data queue 'waiting.

The invention also relates to a system for synchronizing a set of software modules of a computer system, comprising a plurality of interconnected networked servers, each software module running on a server of the computer system for the management of a set of data, at least a part of which is replicated on several software modules, in which the synchronization between two software modules of the set comprises a synchronization of the common data that they manage, characterized in that it comprises:

means for identifying at least one subset comprising software modules of the set that are activated and synchronized with each other, and

Means for searching another activated software module of the set,

if another activated software module is found and if it belongs to an identified subset, means for synchronizing the candidate software module with at least one of the software modules of this identified subset, and integration of the candidate software module into the identified subset.

Finally, the invention also relates to a computer program downloadable from a communication network and / or recorded on a computer-readable medium and / or executable by a processor, characterized in that it comprises code instructions of program for performing the steps of a synchronization method as defined above, when said program is run on a computer.

The invention will be better understood with the aid of the description which follows, given solely by way of example and with reference to the appended drawings in which:

FIG. 1 schematically represents the general structure of a data storage computer system distributed in several interconnected networked servers,

FIG. 2 illustrates an example of distribution of description data in the computer system of FIG. 1,

FIG. 3 illustrates the successive steps of a synchronization method implemented in the system of FIG. 1 according to one embodiment of the invention,

FIG. 4 represents a diagram of states and transitions between these states of software and hardware modules of the computer system of FIG.

1, for implementing the synchronization method of FIG. 3,

FIGS. 5 and 6 partially illustrate the successive steps of synchronization methods according to other embodiments of the invention; FIGS. 7 and 8 illustrate examples of implementation of a particular synchronization step of the method of synchronization of Figure 3, and

FIG. 9 illustrates an exemplary implementation of another particular synchronization step of the synchronization method of FIG. 3.

The computer system 10 shown in Figure 1 comprises several servers 12 _1; 12 ₂ , 12 ₃ , 12 ₄ and 12 ₅ , spread over several areas. Each server is of a classic type and will not be detailed. On the other hand, on each server 12 ₁₃ 12 ₂ , 12 ₃ , 12 ₄ and 12 ₅ is installed at least one specific software and hardware module 14 _{1 s} 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ of management of a service, for example a data storage service.

Five servers and two domains are represented in FIG. 1 for illustrative purposes only, but any other computer system structure distributed in several servers interconnected in a network may be suitable for implementing a synchronization method according to the invention. For the sake of simplification also, there is shown a software and hardware module per server, so that the modules and their respective servers can be confused in the following description, without having to be confused in a more general implementation of the invention. The software and hardware module ^" U ₁ of the server 12 _" is detailed in FIG. 1. It comprises a first software layer 16i consisting of a server operating system 12. It includes a second software management layer 18i of the data management system. description of the data storage service provided by the computer system 10. It comprises a third software and hardware layer 20i fulfilling at least two functions: a first storage function, on an internal hard disk of the server 12 _1; storage service and a second cache function, also on this hard disk, of data stored on storage devices of the server 12. Finally, it comprises a fourth software and hardware layer 22 _{1 s} 24i of data warehouses, comprising at least one hard disk data warehouse _22! and / or at least one data warehouse 24i tapes. for the rest of the descripti On, a data warehouse designates a virtual data storage space consisting of one or more disk partitions, or one or more magnetic tapes, among the storage devices of the server with which it is associated.

The software and hardware modules 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ of the servers 12 ₂ , 12 ₃ , 12 ₄ and 12 ₅ will not be detailed because they are similar to the software and hardware module λ Λ _λ .

In the example illustrated in FIG. 1, the servers 12 ₁₃ 12 ₂ and 12 ₃ are interconnected by a first LAN-type network 26 to create a first subset or domain 28. This first domain 28 corresponds, for example, to a localized geographic organization, such as a geographical site, a building or a computer room. The servers 12 ₄ and 12 ₅ are interconnected by a second network 30 of the LAN type to create a second subset or domain 32. This second domain 28 also corresponds for example to another localized geographical organization, such as a site geographical area, a building or a computer room. These two domains are interconnected by a WAN type network 34, such as the Internet network.

Thus, this clustered computer system distributed over several geographical sites makes it possible to envisage data storage all the more secure that these can be replicated on software and hardware modules located on different geographical sites.

The storage service provided by this computer system 10 and the data actually stored are advantageously completely defined and described by a set of description data which will be described in their general principles with reference to FIG. 2. this description data by the software layer 18, of any of the software and hardware modules 14, manages the storage service of the computer system 10.

The description data are for example grouped into several sets structured according to their nature and possibly linked together. A structured set, which will be called "catalog" in the following description, may be in the form of a directory tree containing themselves other directories and / or description data files. The representation of the description data according to a tree of directories and files has the advantage of being simple and therefore economical to design and manage. In addition, this representation is often sufficient for the service in question. It is also possible for more complex applications to represent and manage the description data in relational databases.

A catalog of description data may be global, that is to say relate to description data useful to the entire computer system 10, or local, that is to say relate to description data specific to one or more software module (s) and hardware (s) 14 ₁₅ 14 ₂ , 14 ₃ , 14 ₄ or 14 ₅ for managing the service. Advantageously, each catalog is replicated on several servers or software and hardware modules. When it is global, it is preferably replicated on all software and hardware modules. When it is local, it is replicated on a predetermined number of software and hardware modules, including at least those it concerns.

By way of example, FIG. 2 represents a possible distribution of descriptive data catalogs between the five software and hardware modules 14 _1s 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ .

A first global C _A catalog is replicated on the five software and hardware modules 14 ₁₅ 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ . It comprises, for example, data describing the general infrastructure and the general operation of the computer system 10 for the provision of the service, in particular the tree structure of the domains and the software and hardware modules of the computer system 10. It may also comprise data describing potential users of the data storage service and their access rights, for example previously registered users, as well as the sharing zones, the structure or the storage mode and the replication of stored data. Other catalogs are local, such as the catalog C _B i, containing descriptive data specific to the software and hardware module 14i such as data relating to the local infrastructure and the local operation of the server 12i and its peripherals. storage, or warehouse organization of the software and hardware module 14 _{1 s} or even the digital data actually stored in these warehouses. This catalog is replicated in three copies, including one on the software and hardware module λ Λ _λ . To improve the security and robustness of the computer system 10, the catalog C _B i can be replicated in several different fields. Here, the complete system comprising two domains 28 and 32, the catalog C _B i is for example saved on the modules 14i and 1 A ₂ of the domain 28 and on the module 14 ₅ of the domain 32.

Similarly, the software and hardware modules 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ are associated with respective local catalogs C ₆₂ , C ₆₃ , C ₆₄ and C ₆₅ . For example, the catalog C ₆₂ is saved on the modules 14 ₂ and 14 ₃ of the domain 28 and on the module 14 ₄ of the domain 32; the catalog C ₆₃ is saved on the module 14 ₃ of the domain 28 and on the modules 14 ₄ and 14 ₅ of the domain 32; the catalog C ₆₄ is saved on the module 14 ₄ of the domain 32 and on the modules 14i and 14 ₃ of the domain 28; and the catalog C ₆₅ is saved on the module 14 ₅ of the domain 32 and on the modules 1 A _λ and 1 A ₂ of the domain 28.

The above list of description data catalogs is not exhaustive and is provided by way of example, as well as the number of replications of each catalog.

By this replication of the catalogs, here on at least three software and hardware modules for each catalog, we notice that even if a software and hardware module, or even two, is (are) out of order, the system as a whole is capable of accessing all the description data so that the management of the data storage service is not necessarily interrupted. In practice, this continuity of service maintained is effective from the moment when synchronization of the catalogs and more generally description data is ensured. The actually stored data is also replicated for security issues of the storage service provided so that any action or modification on that data must also be applied to the different replications. Synchronization of the data actually stored must therefore also be ensured.

In other words, a synchronization of the software and hardware modules 14 _1; 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ , having a synchronization of the common data they manage, must be ensured.

For this, a synchronization method according to the invention will now be detailed with reference to FIGS. 3, 4, 5 and 6.

This synchronization method aims to group the software and hardware modules 14 ₁₅ 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ of the computer system 10 into at least one identified subset in which all the software and hardware modules are activated and synchronized between them. Its purpose may even be to result in only one synchronized subset, which then groups together all the software and hardware modules 14 ₁₅ 14 ₂ , 14 ₃ , 14 ₄ and 14 ₅ of the computer system 10, synchronized between them.

This method is therefore primarily to manage the start or restart of a software and hardware module of the computer system 10 for integration with one of the existing synchronized subsets or a new subset to create. Optionally, it also aims to manage shutdowns of software and hardware modules, network breaks, detections of a subset synchronized by another, and so on. : as many events likely to evolve the synchronized subsets of the computer system 10. As illustrated in Figure 3, during a first step 100, resulting for example from the activation of a software and hardware module 14, following the start of a new server in the computer system 10 or the restart of an existing server, this software and hardware module, activated but not yet synchronized with another software and hardware module of the computer system 10, searches for another software module and hardware enabled computer system 10.

If another activated software and hardware module 14 is found and if it belongs to an identified synchronized subset, a step 102 of selecting at least one of the software and hardware modules of the identified subset is proceeded to to synchronize the software and hardware module 14, with this software module (s) and hardware (s) selected (s). In the first place, the selection is based on the digital data of the software and hardware module 14, which must be synchronized. The software and hardware modules of the identified subset concerned by this selection are therefore those that manage data in common with the software and hardware module 14. Optionally, this selection is also a function of a workload of at least a portion of the software and hardware modules of this identified subset. For example, it can be considered that beyond a predetermined load, a software and hardware module of the identified subset can not be selected. Thus, if a requested software and hardware module temporarily has an overload, it can indicate to the software and hardware module 14, to choose another software and hardware module. If no software module and hardware requested is available at a given time, the software and hardware module 14, can wait until the peak activity ends to synchronize. Thus, the workload is distributed equitably between the software and hardware modules solicited if a large number of software and hardware modules start at the same time or if a software and hardware module starts while the others are very busy.

Then, during a step 104, a synchronization of the software and hardware module 14, with the selected module or modules is performed. A non-limiting example of such a synchronization will be detailed with reference to FIG. 9. In a next step 106, the software and hardware module 14 is integrated with the identified synchronized subset which therefore now includes one more element.

Finally, we proceed to a step 108 during which the software and hardware modules of the identified subset synchronized with each other are permanently maintained according to a predetermined mechanism, a non-limiting example of which will be detailed with reference to FIGS. 7 and 8. During this step also, the computer system 10 monitors any event likely to change the identified subset: detection of another synchronized subset with which to merge, detection of a connection break between two parts of the subset then intended to separate, loss of a software and hardware module (for example by stopping the corresponding server), etc.

In step 100, if another activated software and hardware module 14 is found but does not belong to an identified synchronized subset, a synchronization step of the software and hardware module 14 is carried out, with the module software and hardware 14 ,. This synchronization may be identical to that envisaged in step 104. It will be detailed with reference to FIG. 9.

Then, during a step 1 12, a new synchronized subset is created and identified in which we integrate both software and hardware modules 14 and 14 _r

Finally, we proceed to a step 1 14 during which the two software and hardware modules 14 and 14 of this new identified subset synchronized with each other are permanently maintained according to a predetermined mechanism that may be identical to that envisaged. in step 108 and which will be detailed with reference to FIGS. 7 and 8. Also during this step, the computer system 10 monitors any event that may change the new subset created: detection of another subset synchronized with which to merge, detection of a connection break between the two software modules and hardware 14, and 14, then intended to separate, loss of a software and hardware module (for example by stopping the corresponding server), etc.

In step 100, if no other activated software and hardware module 14 is found, the software and hardware module 14 can not be synchronized and remains isolated, although activated and therefore operational. We then go to a step 1 16, during which the computer system 10 monitors any event likely to change the synchronization of the software and hardware module 14,: detection of a synchronized subset in which it could be integrated, detection another software and hardware module activated but isolated with which it could be synchronized, stop the server on which it is implemented, etc.

In one embodiment of the invention, each synchronized subset includes a software and hardware module selected to be specifically marked as an identifier of that subset. For example, in the situation of the step 1 12 previously described, it is the software and hardware module 14, which can be selected as having to identify the new subset created following its detection by the software and hardware module 14, . A subset is then identified by this software and hardware module selected, so that any event generating an exclusion of this selected software and hardware module of the subset generates the disappearance of this subset and the possible creation of one or more new subsets. Any software and hardware module 14 of the computer system 10 can therefore be in four different states E1, E2, E3 and E4 shown in FIG. 4 with their transitions.

In the first state E1, the software and hardware module 14 is stopped. In the second state E2, it is activated but isolated, that is to say without being synchronized with another software and hardware module of the computer system 10. In the third state E3, it is a member of a synchronized subset identified. Finally, in the fourth state E4, it is a member of a synchronized subset identified and marked as identifier of this subset. A first transition T1 switches the software and hardware module 14 from its stopped state E1 to step 100 of searching for another activated software and hardware module of the computer system 10. In other words, during the step 100, the software and hardware module 14, is activated but in search of a synchronization of the digital data that it manages. This situation is caused for example by starting or restarting the corresponding server.

A second transition t2 switches the software and hardware module 14, from step 100 to its activated but isolated state E2. This is the state in which it is if, following step 100, it proceeds to step 1 16 because it has not detected any other activated software and hardware module. A third transition t3 switches the software and hardware module 14 from step 100 to its member state E3 of an identified synchronized subset. This is the state in which it is if following step 100 it goes to step 102 (it joins an existing synchronized subset) or 1 10 (it joins a synchronized subset created by the module software and isolated hardware that it has detected). A fourth transition t4 switches the software and hardware module 14 from its activated but isolated state E2 to its idle state E4 of a synchronized subset. This is the state in which it is found if it has been detected by another software and hardware module to perform a synchronization. It then becomes the identifier of the new subset created. A fifth transition t5 switches the software and hardware module 14 from its member state E3 of a synchronized subset identified to its E4 identifier of a synchronized subset. This is the state in which it can be if the subset to which it belongs has lost its identifier module (corresponding server shutdown for example), or if the software and hardware module 14, itself has lost contact with the module identifier of the subset in which it is after a connection break. It can then become the identifier of a new subset created, but it must be selected.

Indeed, in this situation, a new identifier module must be selected for all the software and hardware modules of the subset considered that have lost contact with the initial identifier module: a solution is to create a new subset for all these modules software and hardware and select one to be the identifier of this new subset, for example the software and hardware module 14 ,.

In other words, in the embodiment described with reference to FIG. 4, if the module identifying a synchronized subset stops, one of the other software and hardware modules of this subset becomes the module identifier. But for that, a new subset is created and all the other software and hardware modules of the old subset become members of the new subset. If the network connection between two remote sites of the same synchronized subset is broken, part of the members of this subset will be separated from the identifier module of this subset. Among these software and hardware modules separate from the identifier module, one will be selected to become the identification module of a new subset that will include the software and hardware modules of the isolated site. In practice, a new subset is created each time one or more software and hardware modules are separated from the identifier module. One of them becomes by selection (transition t5) the identifier module of the new subset.

A sixth transition t6 switches the software and hardware module 14 from its activated but isolated state E2 to its stopped state E1. This transition occurs in two situations:

a first situation is the shutdown of the server on which the software and hardware module 14 is located;

a second situation is the detection by the software and hardware module 14 of an identified synchronized subset or of another software and hardware module in the state E2.

Indeed, in the second situation, it must synchronize with at least one of the software and hardware modules of the detected subassembly to be part of it (steps 102 to 106) or with the other isolated software and hardware module detected ( steps 1 10, 1 12). Since the software and hardware module 14 has evolved in isolation, one solution is to restart it, which should lead, via step 100, to the transitions t1 and t3 during this restart.

A seventh transition t7 switches the software and hardware module 14 from its state E3 or E4 member or identifier of a synchronized subset identified to its stopped state E1.

This transition occurs in two situations:

a second situation is the detection by the subset in which it is located of another identified synchronized subset with which it can merge.

In the second situation, if the merge is done by maintaining the other subset and disappearing the subset in which the software and hardware module 14, is located, the latter and the other software modules and hardware of the subset Disbanded must synchronize with at least one of the software and hardware modules of the other detected subset to be part of it (steps 102-106). However, as the two subsets have evolved in isolation, one solution is to restart the software and hardware module 14, and other software modules and hardware subset to disappear, which should lead via the step 100, transitions t1 and t3 during this restart.

FIG. 5 illustrates the successive steps implemented optionally by a synchronization method according to the invention, when a synchronized subset of the computer system 10 detects another, according to the second situation of the transition t7 described above. . During a first step 200, a first synchronized subset

S1 detects a second synchronized subset S2 with which it is possible to merge.

In a next step 202, a choice is made to know which of the two subsets must be deleted and which must be retained to finally bring together all the software and hardware modules of these two subsets. The conserved subset will be denoted Si, i = 1 or 2, and the deleted subset will be noted Sj, j = 2 or 1.

The choice is made for example by majority logic:

the subset comprising the largest number of software and hardware modules is kept, - If the two subsets have the same number of software and hardware modules, the chance determines the one that is kept. The choice criterion could be different or refined. It could for example take into account a number of modifications executed on the data managed by the software and hardware modules of each subset S1 and S2. It could also take into account the number of sessions opened by users on the software and hardware modules of each subset S1 and S2, since restarting a software and hardware module requires stopping the sessions in progress on this module. and may cause discomfort for one or more users. Then, in a step 204, each software and hardware module of the subset Sj synchronizes with at least one software and hardware module of the subset Si. A non-limiting example of such a synchronization will be detailed with reference to FIG. 9. .

In the next step 206, the subset Sj is deleted. Finally, in a last step 208, all the software and hardware modules initially in this subset include the subset Si.

Steps 204, 206 and 208 apply to all the software and hardware modules of the subset Sj and accompany their successive transitions t7, t1 and t3. FIG. 6 illustrates the successive steps implemented optionally by a synchronization method according to the invention, when a connection break within a synchronized subset of the computer system 10 generates two complementary parts of this subset, each comprising at least one software module and can no longer communicate with each other, in accordance with the situation of the transition t5 described above.

During a first step 300, a synchronized subset S1 detects a connection break between two complementary parts of S1 each comprising at least one software module.

One of the two complementary parts of S1 necessarily includes its identifier module. This part then takes over the identity of S1.

The other of the two parts comprises software and hardware modules having lost contact with the identifier module of S1. We then go to a step 302, during which a new subset S2 is created in which are integrated all the software and hardware modules of this other part. During this integration, no synchronization is necessary. Only a software module and material of this new subset S2 must be selected to be the identifier. This software and hardware module selected then follows the transition t5.

It has been previously seen that in the course of steps 108 and 114, the software and hardware modules of the same subset synchronized with each other are permanently maintained according to a predetermined mechanism, a non-limiting example of which will now be detailed.

For this, the software layer of each software and hardware module of the computer system 10 comprises:

means for transmitting a synchronization message, identifying an action acting on a digital datum it manages, to all the other software and hardware modules belonging to the same synchronized subset and comprising a replication of this data item digital, following the execution of this action on this software and hardware module, and - means for executing an action acting on a digital data item and identified in a synchronization message, so as to act on the replication of the digital data located on this software and hardware module, in response to a receipt of this synchronization message. Since the digital data, in particular the description data, managed by a software and hardware module are advantageously organized in catalogs, a mechanism for permanent synchronization of the catalogs within the same subset will now be detailed.

First of all, it should be specified that a synchronization of a catalog in a subset is required from the moment when a replication of a description data item of this catalog is modified on any software and hardware module of this subset. A modification of description data can be completely defined by an action A determined on this description data item. For example, a modification of a description data item relating to a user may be defined by an action on his rights of access to the computer system 10 selected from among a set of rights comprising system administrator rights, administrator rights of data, operator rights, single user rights. In this case, the action A identifies precisely the description data to which it applies and the new value of this description data (in this case: system administrator, data administrator, operator or simple user). Action A is identified by a unique universal identifier and can be saved, so that the current state of a description datum can be retrieved by knowing the initial state of this description datum and the series of actions that have been performed on it since its creation. Each local replication of a description data item D is also associated with a version V that includes an N version number and an S signature. In a preferred embodiment, any modification or creation made by an action A on a replication of the description data D also modifies its version V as follows: - N ^ N ₊ 1;

- S <- S + lncr (A), where lncr (A) is a random value generated at the execution of the action A on the replication of the relevant description data. As illustrated in FIG. 7, during a first step 400, an action A is executed on a replication Di of the description data D, this replication Di being stored by the server 12. Before the execution of the action A, the replication Di of the description data D has a value val, a version number N and a signature S. After the execution of the action A, the replication Di of the data description D has a value val ', a version number N' = N + 1 and a signature S '= S + lncr (A).

During the execution of the action A, the replication Di of the description data D is protected so that other actions on this replication can not be executed. These other possible actions are put on hold in a list provided for this purpose and are executed sequentially as soon as the action A has finished.

In a next step 402, a synchronization message M is generated by the software and hardware module 14. This message M comprises the universal identifier of the action A, or a complete description of this action A, as well as the value of the signature increment lncr (A). During this same step, the message M is transmitted to software and hardware modules 14 _j and 14 _k belonging to the same subset as the software and hardware module 14, and also comprising a replication of the description data D.

Then, during a step 404, upon receipt of the synchronization message M, the software and hardware module 14 _j executes the action A on the replication Dj of the description data D, so as to update its value, its version number and its signature which then take the respective values val ', N' and S '. The update of the version number N is done by applying the same rule as that applied by the software and hardware module 14, and updating the signature is done through the transmission of the signature increment lncr (A) generated by the software and hardware module 14 ,.

Then also, during a step 406, upon receipt of the synchronization message M, the software and hardware module _14k executes the action A on the replication Dk of the description data item D, so as to update its value, its version number and its signature which then take the respective values val ',

N 'and S'.

With this synchronization method repeated each time an action is performed on any of the description data of the computer system 10, the catalogs replicated on several nodes of the same synchronized subset remain identical, at the execution time of synchronization close.

Other techniques for modifying version V of a replication of description data than that presented with reference to FIG. 7 can be envisaged as alternatives, but it is advantageous to provide that the update of the signature S is incremental and commutative, which makes it possible to manage the cross-modifications of different replications of the same description data, as illustrated by FIG. 8.

Indeed, during a first step 500, an action A is executed on a first instance of a replication Di of the description data D, this replication Di being stored by the server 12,. Before the execution of the action A, the replication Di of the description data D has a value val, a version number N and a signature S. After the execution of the action A, the replication Di of the data description D has a value val ', a version number N' = N + 1 and a signature S '= S + lncr (A).

Even before the software and hardware module 14 has had time to send a synchronization message MA to the other software and hardware modules of its subset having a replication of the description data D, an action B is executed on one of them, the software and hardware module 14 _J; in a step 502. During this step, the action B is executed on a second instance of the replication Dj of the description data D. Before the execution of the action B, the replication Dj of the data of description D has the value val, the version number N and the signature S. After the execution of the action B, the replication Dj of the description data D has a value val ", different from val ', the number of version N '= N + 1 and a signature S "= S + lncr (B), different from the signature S'. Thus, after the steps 500 and 502, although the replications Di and Dj have the same version number N ', their respective signatures and values are different. Their versions V and V ", identified by both their version numbers and by their signatures, are therefore different In a next step 504, the synchronization message MA is generated by the software and hardware module 14. message MA comprises the universal identifier of the action A, or a complete description of this action A, as well as the value of the signature increment lncr (A). At this same step, the message MA is transmitted in particular to the software module and hardware 14, including the replication Dj. Similarly, in a subsequent step 506, a synchronization message MB is generated by the software and hardware module 14. This message MB includes the universal identifier of the action B, or a complete description of this action B, as well as the value of the signature increment lncr (B) During this same step, the message MB is transmitted in particular to the software and hardware module 14, including the replication Di.

In a step 508, upon receipt of the synchronization message MB, the software and hardware module 14, performs the action B on the replication Di of the description data D, so as to update its value, its number of version and its signature which then take the respective values val '", N" and S' ". The value val '" results from action B over val', that is to say from the combination of actions A and B on the value val of the description data D. The value N "is equal to N '+ 1, ie N + 2. Finally, the value of S'" is equal to S '+ lncr (B) = S + lncr (A) + lncr (B).

Finally, during a step 510, upon receipt of the synchronization message MA, the software and hardware module 14, executes the action A on the replication Dj of the description data item D, so as to update its value, its version number and its signature which then take the same values val '", N" and S' "as for Di in step 508. Indeed, the value val" "results from the action A on val", that is, the combination of the actions A and B on the value val of the description data D. The value N "is equal to N '+ 1, ie N + 2. Finally, the value of S' "is equal to S" + lncr (A) = S + lncr (B) + lncr (A), thanks to the incremental and commutative property of the update of the signature.

It is therefore noted that at the end of steps 508 and 510, the replications Di and Dj are correctly synchronized, their identical versions attesting to the identity of their values. It has been previously seen that during the steps 104, 110 and 204, a synchronization of a software and hardware module 14, with at least one software and hardware module 14, selected according to a predetermined mechanism, one of which Nonlimiting example will now be detailed with reference to FIG. 9. This mechanism makes it possible to make up for a possible delay or an offset taken by the software and hardware module 14, with respect to the software and hardware module 14, selected in the data management of the software. description they have in common.

According to this mechanism, during a first step 600 in which the software and hardware module 14, is in search of another software and hardware module for the synchronization of at least one of its description data catalogs , this one selects the software and hardware module 14,. It selects of course one of the software and hardware modules managing a replication of the catalog that it wishes to update. When the software and hardware module 14 is selected, during this same step 600, the software and hardware module 14, transmits its identifier and information about the versions of each of the description data of its catalog (ie number version and signature).

Then, during a step 602, the software and hardware module 14, establishes a fixed representation of the contents of its catalog and creates a waiting list for the receipt of any new synchronization message concerning this catalog. Following step 600 also, during a step 604, the software and hardware module 14 is registered as possessor of a replication of the catalog and recipient of any synchronization messages concerning this catalog. During this step, he also creates a waiting list for receiving any new synchronization messages concerning this catalog. Following step 602, during a step 606, the software and hardware module 14 compares the versions of the description data of the software and hardware module 14 with its own.

This search for differences between two replications of the same catalog can be facilitated when the description data catalog is structured according to a tree in which the description data is either nodes (when they have a direct or indirect relationship with at least one description datum "girl"), or leaves (when they are located at the end of the tree in this hierarchical representation). Indeed, in this case, each node of the tree can be associated with a global signature which represents the sum of the signatures of its data "girls", that is to say the description data located downstream of this knot in the tree. Thus, the search for differences is made by traversing the tree, from its root to its leaves, in other words from upstream to downstream: each time a node of the tree has the same global signature in the two replications of the catalog , this means that this node and the set of data "girls" of this node are identical, so it is not useful to further explore the subtree of the tree defined from this node .

During this same step, the software and hardware module 14 constitutes a first list of description data comprising the values and versions of the description data whose version it has is more recent than that of the software and hardware module 14. It also possibly constitutes a second list of description data comprising the identifiers of the description data whose version it possesses is less recent than that of the software and hardware module 14. It then transmits these two lists to the software and hardware module 14,.

In a step 608, the software and hardware module 14 processes the first list so as to update, in its replication of the catalog, the relevant description data.

In a step 610, it transmits to the software and hardware module 14, the values and versions of the description data identified in the second list.

Then, during a step 612, the software and hardware module 14, processes these values and versions of description data identified in the second list so as to update, in its replication of the catalog, the relevant description data. Each time it processes an update of description data, it transmits a synchronization message, in accordance with the method described with reference to FIG. 7, to the possible software and hardware modules of its subset including a replication of this data item. description except software and hardware module 14 ,.

Following this catalog update between the software and hardware module 14, and the software and hardware module 14 ,, the frozen representation of the contents of the catalog is deactivated on the software and hardware module 14 side, during a step 614 and the software and hardware module 14, is informed in a step 616.

Thus, in the last respective steps 618 and 620, the software and hardware modules 14 and 14 are released to process, if appropriate, the synchronization messages received in their respective waiting lists during the entire duration of the steps 606 to 616, in order to resorb and delete these waiting lists, then to put in situation to reproduce the synchronization steps as described with reference to Figures 7 and 8 when the situation arises.

Steps 600 to 618 are repeated as many times as necessary on the software and hardware module 14, for updating all of its description data catalogs.

It is clear that a method and / or system as described above allows the decentralized synchronization of the replicated data of a computer system distributed in several servers, while ensuring overall monitoring of the synchronization of all the software modules by the presence and management of the evolution of synchronized subsets.

Note also that the invention is not limited to the embodiment described above. It will be apparent to those skilled in the art that various modifications can be made to the embodiment described above, in the light of the teaching that has just been disclosed. In the following claims, the terms used are not to be construed as limiting the claims to the embodiment set forth in this description, but must be interpreted to include all the equivalents that the claims are intended to cover by reason of their formulation and whose prediction is within the reach of those skilled in the art by applying his general knowledge to the implementation of the teaching that has just been disclosed to him.

Claims

1. Method of synchronizing a set of software modules (1 A _λ , 18 ₁₃

14 ₂ , 14 ₃ , 14 ₄ , 14 ₅ ) of a computer system (10) distributed in several servers (12, 12 ₂ , 12 ₃ , 12 ₄ , 12 ₅ ) interconnected in a network (26, 30, 34), each software module running on a server of the computer system for the management of a set

(C _A, C _IB, C _B2, C _B3, _B4 C, 5 C _B) of digital data including at least a portion is replicated on several software modules, wherein the synchronization between two software modules of the assembly comprises a synchronization (102, 104, 1 10) of the common data that they manage, characterized in that it comprises the following steps:

- grouping (106, 1 12) software modules of the set, activated and synchronized with each other, in at least one synchronized subset (S1, S2) and identification of this subset, and - for each candidate software module (14,) following its start or restart, activated but not synchronized with at least one other software module of the set: - search (100) of another activated software module of the set,

• if another activated software module is found and if it belongs to an identified subset, synchronization (102, 104) of the candidate software module with at least one (14,) of the software modules of this identified subset , and

Integration (106) of the candidate software module into the identified subset.

The synchronization method according to claim 1, wherein, for each candidate software module (14), if another software module is found but it does not belong to an identified subset:

a new synchronized subset is created and identified (1 12),

the candidate software module is synchronized with the other software module found (14 _days ), and

the candidate software module (14) and this other found software module (14) are integrated (1 12) in this new identified subset.

3. Synchronization method according to claim 1 or 2, wherein, during the synchronization (102, 104) of the candidate software module (14), with at least one (14) of the software modules of the subset identified. with the other module found software, the choice (102) of at least one software module (14,) of this subset identified to perform the synchronization is a function of a workload of at least a portion of the software modules of this subset. identified set.

4. Synchronization method according to any one of claims 1 to 3, further comprising the following steps:

Detecting (200), with a first identified subset (S1), of a second identified subset (S2),

grouping (208) the software modules of these two subsets identified in one (Si) of these two identified subsets,

- deleting (204) the other of these two identified subsets, and

- synchronization (206) of each software module initially part of the subset deleted with at least one of the software modules of the subset (Si) chosen for the grouping.

The synchronization method according to any one of claims 1 to 4, wherein in each identified subset, a software module is selected to be specifically marked as an identifier of that identified subset.

6. Synchronization method according to any one of claims 1 to 5, further comprising the following steps:

detection (300) of a connection break between two complementary parts of an identified subset (S1), each comprising at least one software module,

from this identified subset (S1), generation (302) and identification of two subsets (S1, S2) integrating one or the other of the two complementary parts.

The synchronization method according to any of claims 1 to 6, further comprising the steps of:

execution (400), on a first software module (14i) belonging to an identified subset, of an action (A) acting on a digital datum (Di) managed by this first software module,

transmission (402) of a synchronization message (M) identifying the action (A) to all the other software modules (14j, 14k) of the same identified subset including a replication (Dj, Dk) of this digital data, on receipt of this message (M) by any of the software modules concerned, execution (404, 406) of the action identified on this software module so as to act on the replication of the digital data item located on this software module .

8. Synchronization method according to any one of claims 1 to 7, further comprising the following steps:

during synchronization of the candidate software module (14i), which comprises a part of the digital data, extraction (602) of a state of the replications of this part of the digital data on at least one other software module (14j), and registering (604) the candidate software module (14i) as a potential receiver of at least one synchronization message identifying an action on a replication of its digital data located on another software module, - synchronization (606, 608, 610 612) digital data of the software module (14i) with the digital data of the other software module (14j) and, during this synchronization, queuing synchronization messages possibly received,

- Once the synchronization is complete (614, 616), processing the queue (618, 620).

9. System for synchronizing a set of software modules (14 _{1 s} 18i, 14 ₂ , 14 ₃ , 14 ₄ , 14 ₅ ) of a computer system (10), comprising several servers (12 _1, 12 ₂ , 12 ₃ , 12 ₄ , 12 ₅ ) interconnected in a network (26, 30, 34), each software module executing on a server of the computer system for the management of a set (C _A , C _BI , C ₆₂ , C ₆₃ , C ₆₄ , C ₆₅ ) of data at least a part of which is replicated to several software modules, wherein the synchronization between two software modules of the set (14, 14 _j ) comprises a synchronization of the common data that they manage. characterized in that it comprises:

for each candidate software module (14,) following its start or restart, activated but not synchronized with at least one other software module of the set: means for searching another activated software module of the set,

If another activated software module is found and if it belongs to an identified subset, means for synchronizing the candidate software module with at least one (14) of the software modules of this identified subset, and

Means for integrating the candidate software module (14) into the identified subset.

Computer program downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the execution of the steps of a synchronization method according to any of claims 1 to 8 when said program is run on a computer.