WO2010052441A1 - Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs - Google Patents

Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs Download PDF

Info

Publication number
WO2010052441A1
WO2010052441A1 PCT/FR2009/052158 FR2009052158W WO2010052441A1 WO 2010052441 A1 WO2010052441 A1 WO 2010052441A1 FR 2009052158 W FR2009052158 W FR 2009052158W WO 2010052441 A1 WO2010052441 A1 WO 2010052441A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
software module
subset
synchronization
identified
Prior art date
Application number
PCT/FR2009/052158
Other languages
English (en)
Inventor
Dominique Vinay
Loïc LAMBERT
Philippe Motet
Soazig David
Original Assignee
Active Circle
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 Active Circle filed Critical Active Circle
Priority to JP2011535156A priority Critical patent/JP2012508412A/ja
Priority to EP09768166A priority patent/EP2353277A1/fr
Priority to US13/128,489 priority patent/US20110218962A1/en
Publication of WO2010052441A1 publication Critical patent/WO2010052441A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • a service 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.
  • 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.
  • a computer cluster system provides that several computers can copy locally the same data from common storage means.
  • 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.
  • the architecture of the system provides a particular role for the coupling system and the common storage means.
  • 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:
  • the candidate software module is synchronized with the other software module found
  • the candidate software module and this other software module found are integrated in this new identified subset.
  • 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.
  • a synchronization method according to the invention may further comprise the following steps: detection, by a first identified subset, of a second identified subset,
  • 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.
  • 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.
  • a synchronization method according to the invention may further comprise the following steps:
  • a synchronization method may further comprise the following steps:
  • each subset constituted and identified there is provided a permanent synchronization mechanism of the software modules between them particularly effective and not centralized.
  • 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.
  • 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.
  • a synchronization method according to the invention may further comprise the following steps:
  • 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,
  • 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:
  • 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.
  • 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.
  • 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
  • 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 2 , 12 3 , 12 4 and 12 5 , spread over several areas.
  • Each server is of a classic type and will not be detailed.
  • On each server 12 13 12 2 , 12 3 , 12 4 and 12 5 is installed at least one specific software and hardware module 14 1 s 14 2 , 14 3 , 14 4 and 14 5 of management of a service, for example a data storage service.
  • FIG. 1 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.
  • a software and hardware module per server 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 1 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.
  • 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.
  • 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.
  • 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 2 , 14 3 , 14 4 and 14 5 of the servers 12 2 , 12 3 , 12 4 and 12 5 will not be detailed because they are similar to the software and hardware module ⁇ ⁇ ⁇ .
  • the servers 12 13 12 2 and 12 3 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 4 and 12 5 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.
  • 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.
  • 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 15 14 2 , 14 3 , 14 4 or 14 5 for managing the service.
  • 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.
  • FIG. 2 represents a possible distribution of descriptive data catalogs between the five software and hardware modules 14 1s 14 2 , 14 3 , 14 4 and 14 5 .
  • a first global C A catalog is replicated on the five software and hardware modules 14 15 14 2 , 14 3 , 14 4 and 14 5 . 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.
  • the catalog C B i can be replicated in several different fields.
  • 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 2 of the domain 28 and on the module 14 5 of the domain 32.
  • the software and hardware modules 14 2 , 14 3 , 14 4 and 14 5 are associated with respective local catalogs C 62 , C 63 , C 64 and C 65 .
  • the catalog C 62 is saved on the modules 14 2 and 14 3 of the domain 28 and on the module 14 4 of the domain 32;
  • the catalog C 63 is saved on the module 14 3 of the domain 28 and on the modules 14 4 and 14 5 of the domain 32;
  • the catalog C 64 is saved on the module 14 4 of the domain 32 and on the modules 14i and 14 3 of the domain 28;
  • the catalog C 65 is saved on the module 14 5 of the domain 32 and on the modules 1 A ⁇ and 1 A 2 of the domain 28.
  • This synchronization method aims to group the software and hardware modules 14 15 14 2 , 14 3 , 14 4 and 14 5 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 15 14 2 , 14 3 , 14 4 and 14 5 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • this selection is also a function of a workload of at least a portion of the software and hardware modules of this identified subset.
  • a software and hardware module of the identified subset can not be selected.
  • 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.
  • 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.
  • 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.
  • the software and hardware module 14 is integrated with the identified synchronized subset which therefore now includes one more element.
  • 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.
  • 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.
  • 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.
  • a new synchronized subset is created and identified in which we integrate both software and hardware modules 14 and 14 r
  • 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.
  • 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.
  • 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.
  • each synchronized subset includes a software and hardware module selected to be specifically marked as an identifier of that subset.
  • 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.
  • the software and hardware module 14 is stopped.
  • it is activated but isolated, that is to say without being synchronized with another software and hardware module of the computer system 10.
  • the third state E3 it is a member of a synchronized subset identified.
  • 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.
  • 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.
  • 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.
  • 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 ,.
  • 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.
  • 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.
  • 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 subset in which it is located of another identified synchronized subset with which it can merge.
  • 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. .
  • a first synchronized subset During a first step 200, a first synchronized subset
  • S1 detects a second synchronized subset S2 with which it is possible to merge.
  • 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. .
  • the subset Sj is deleted.
  • 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.
  • 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.
  • a new subset S2 is created in which are integrated all the software and hardware modules of this other part.
  • 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.
  • the software layer of each software and hardware module of the computer system 10 comprises:
  • a modification of description data can be completely defined by an action A determined on this description data item.
  • 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.
  • 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.
  • 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;
  • lncr (A) is a random value generated at the execution of the action A on the replication of the relevant description data.
  • an action A is executed on a replication Di of the description data D, this replication Di being stored by the server 12.
  • the replication Di of the description data D has a value val, a version number N and a signature S.
  • 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.
  • 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).
  • 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.
  • 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 ,.
  • 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 ',
  • 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,.
  • the replication Di of the description data D 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.
  • an action B is executed on one of them, the software and hardware module 14 J; in a step 502.
  • the action B is executed on a second instance of the replication Dj of the description data D.
  • the replication Dj of the data of description D has the value val, the version number N and the signature S.
  • 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).
  • the message MA is transmitted in particular to the software module and hardware 14, including the replication Dj.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the software and hardware module 14 compares the versions of the description data of the software and hardware module 14 with its own.
  • 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.
  • 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 .
  • 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,.
  • the software and hardware module 14 processes the first list so as to update, in its replication of the catalog, the relevant description data.
  • 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.
  • 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 ,.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)

Abstract

Selon ce procédé de synchronisation d'un ensemble de modules logiciels d'un système informatique, chaque module logiciel s'exécute sur un serveur du système informatique pour la gestion d'un ensemble de données numériques. La synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation (102, 104, 110) des données communes qu'ils gèrent. Ce procédé comporte un regroupement (106, 112) de modules logiciels de l'ensemble, activés et synchronisés entre eux, en au moins un sous-ensemble synchronisé et une identification de ce sous-ensemble, et, pour chaque module logiciel candidat suite à son démarrage ou redémarrage, activé mais non synchronisé avec au moins un autre module logiciel : recherche (100) d'un autre module logiciel activé de l'ensemble; si un autre module logiciel activé est trouvé et s'il appartient à un sous-ensemble identifié, synchronisation (102, 104) du module logiciel candidat avec au moins l'un des modules logiciels de ce sous-ensemble identifié; intégration (106) du module logiciel candidat dans le sous-ensemble identifié.

Description

PROCEDE ET SYSTEME DE SYNCHRONISATION D'UN ENSEMBLE DE MODULES LOGICIELS D'UN SYSTEME INFORMATIQUE DISTRIBUE EN GRAPPE DE SERVEURS
La présente invention concerne un procédé et un système de synchronisation d'un ensemble de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau. Elle concerne également un programme d'ordinateur pour la mise en œuvre de ce procédé.
L'invention s'applique plus particulièrement à un système informatique dans lequel chaque module logiciel s'exécute sur un serveur du système informatique pour la gestion d'un ensemble de données numériques, au moins une partie de ces données numériques étant répliquée sur plusieurs modules logiciels, et dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation des données communes qu'ils gèrent. Les données numériques sont par exemple des données de description d'un service et le service fourni par le système informatique est par exemple un service de stockage de données distribué entre les serveurs interconnectés en réseau, chaque serveur étant relié à des périphériques de stockage à disque dur ou bande magnétique. Dans ce cas, les données numériques comportent par exemple des données de description d'utilisateurs du service de stockage, des données de description de l'infrastructure et du fonctionnement du système informatique pour la fourniture du service, et des données de description des données stockées et de leur mode de stockage.
Le service fourni par le système informatique peut également être un service de transmission de données d'information, de traitement de données, de calcul, de transaction ou une combinaison de ces services. Dans chaque cas, les données de description sont adaptées spécifiquement au service fourni.
Les serveurs du système informatique sur lesquels s'exécutent les modules logiciels sont généralement interconnectés par au moins un réseau de type LAN (de l'Anglais « Local Area Network ») et/ou WAN (de l'Anglais « Wide Area Network »). Cet ensemble de serveurs interconnectés en réseau peut notamment être appelé « grappe de serveurs », les modules logiciels étant alors généralement qualifiés de « nœuds » de la grappe.
Dans une telle architecture, un serveur ou un module logiciel particulier est en principe dédié à la gestion de l'ensemble des modules logiciels, notamment pour la synchronisation des données numériques répliquées. Ceci pose des problèmes lorsque le serveur ou le module logiciel dédié à la gestion de l'ensemble est défaillant.
Par exemple dans la demande de brevet publiée sous le numéro FR 2 851 709, il est prévu qu'un service puisse être fourni, via un réseau de communication, à un utilisateur par un serveur principal associé à une base de données. Des serveurs auxiliaires connectés à ce serveur principal sont également prévus dans le réseau de communication pour rendre ce service plus rapidement accessible à l'utilisateur. Mais ils doivent alors être synchronisés avec le serveur principal, notamment avec sa base de données. Pour réaliser cette synchronisation du serveur principal vers les serveurs auxiliaires, le réseau de communication est doté de moyens spécifiques de synchronisation, par exemple mis en œuvre dans des serveurs de ressources. Il apparaît donc que certains éléments du réseau de communication, le serveur principal et les serveurs de ressources, ont un rôle très particulier et leur défaillance risque d'avoir des conséquences immédiates sur la qualité de service fournie.
Dans la demande de brevet publiée sous le numéro US 2007/0233900, un système en grappe de calculateurs prévoit que plusieurs calculateurs puissent copier localement une même donnée issue de moyens de stockage communs. Pour gérer la synchronisation de l'ensemble des copies d'une même donnée, un système de couplage entre les calculateurs prévoit la mise à jour des moyens de stockage communs chaque fois qu'une donnée copiée localement est modifiée par un calculateur, de sorte que les autres calculateurs puissent mettre leurs données copiées localement à jour, en référence aux moyens de stockage communs. Là encore, l'architecture du système prévoit un rôle particulier pour le système de couplage et les moyens de stockage communs.
Centraliser la synchronisation des modules logiciels, dans le sens d'une synchronisation des données numériques communes qu'ils gèrent, est pourtant la solution la plus simplement envisageable. En répartissant cette synchronisation sur plusieurs voire tous les serveurs du système informatique, cela pose des problèmes de coordination des serveurs. Il n'existe donc pas aujourd'hui de solution complètement satisfaisante.
Il peut ainsi être souhaité de prévoir un procédé de synchronisation de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau qui permette de s'affranchir d'au moins une partie des problèmes et contraintes précités.
L'invention a donc pour objet un procédé de synchronisation d'un ensemble de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau, chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble de données numériques dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation des données communes qu'ils gèrent, caractérisé en ce qu'il comporte les étapes suivantes :
- regroupement de modules logiciels de l'ensemble, activés et synchronisés entre eux, en au moins un sous-ensemble synchronisé et identification de ce sous-ensemble, et
- pour chaque module logiciel candidat suite à son démarrage ou redémarrage, activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble :
- recherche d'un autre module logiciel activé de l'ensemble,
- si un autre module logiciel activé est trouvé et s'il appartient à un sous- ensemble identifié, synchronisation du module logiciel candidat avec au moins l'un des modules logiciels de ce sous-ensemble identifié, et
- intégration du module logiciel candidat dans le sous-ensemble identifié. Ainsi, tout en évitant une synchronisation centralisée, puisque chaque module logiciel activé mais non encore synchronisé gère lui-même sa synchronisation avec un autre module logiciel de l'ensemble, le suivi global de la synchronisation de l'ensemble des modules logiciels est assuré par la présence et la gestion de révolution de sous-ensembles homogènes de modules logiciels synchronisés. Ces sous-ensembles sont identifiés pour permettre leur suivi.
De façon optionnelle, pour chaque module logiciel candidat, si un autre module logiciel est trouvé mais qu'il n'appartient pas à un sous-ensemble identifié : - un nouveau sous-ensemble synchronisé est créé et identifié,
- le module logiciel candidat est synchronisé avec l'autre module logiciel trouvé, et
- le module logiciel candidat et cet autre module logiciel trouvé sont intégrés dans ce nouveau sous-ensemble identifié. De façon optionnelle également, lors de la synchronisation du module logiciel candidat avec au moins l'un des modules logiciels du sous-ensemble identifié comportant l'autre module logiciel trouvé, le choix d'au moins un module logiciel de ce sous-ensemble identifié pour réaliser la synchronisation est fonction d'une charge de travail d'au moins une partie des modules logiciels de ce sous-ensemble identifié. Il est ainsi possible de répartir avantageusement la charge de travail occasionnée par la synchronisation elle-même.
De façon optionnelle également, un procédé de synchronisation selon l'invention peut comporter en outre les étapes suivantes : - détection, par un premier sous-ensemble identifié, d'un second sous- ensemble identifié,
- regroupement des modules logiciels de ces deux sous-ensembles identifiés dans l'un de ces deux sous-ensembles identifiés,
- suppression de l'autre de ces deux sous-ensembles identifiés, et - synchronisation de chaque module logiciel faisant initialement partie du sous-ensemble supprimé avec au moins l'un des modules logiciels du sous-ensemble choisi pour le regroupement.
Ainsi, ce procédé de synchronisation tend à favoriser la fusion entre sous- ensembles homogènes tant que la synchronisation complète de tous les modules logiciels de l'ensemble n'est pas obtenue.
De façon optionnelle également, dans chaque sous-ensemble identifié, un module logiciel est sélectionné pour être spécifiquement marqué comme identifiant de ce sous-ensemble identifié.
Ce module logiciel sélectionné dans chaque sous-ensemble joue alors un rôle de marqueur permettant à tous les autres modules logiciels de reconnaître leur appartenance à un sous-ensemble identifié.
De façon optionnelle également, un procédé de synchronisation selon l'invention peut en outre comporter les étapes suivantes :
- détection d'une rupture de connexion entre deux parties complémentaires d'un sous-ensemble identifié, comportant chacune au moins un module logiciel,
- à partir de ce sous-ensemble identifié, génération et identification de deux sous-ensembles intégrant l'une, respectivement l'autre, des deux parties complémentaires. Ainsi, une rupture étant source d'impossibilité à maintenir une synchronisation des modules logiciels d'un même sous-ensemble, ce procédé prévoit la séparation de chaque sous-ensemble en deux sous-ensembles dès qu'une telle rupture de connexion est détectée. De façon optionnelle également, un procédé de synchronisation selon l'invention peut comporter en outre les étapes suivantes :
- exécution, sur un premier module logiciel appartenant à un sous-ensemble identifié, d'une action agissant sur une donnée numérique gérée par ce premier module logiciel, - transmission d'un message de synchronisation identifiant l'action à l'ensemble des autres modules logiciels du même sous-ensemble identifié comportant une réplication de cette donnée numérique,
- sur réception de ce message par l'un quelconque des modules logiciels concernés, exécution de l'action identifiée sur ce module logiciel de manière à agir sur la réplication de la donnée numérique située sur ce module logiciel.
Ainsi, dans chaque sous-ensemble constitué et identifié, il est prévu un mécanisme de synchronisation permanente des modules logiciels entre eux particulièrement efficace et non centralisé. En effet, l'exécution d'une action sur un premier module logiciel d'un sous-ensemble a pour conséquence, grâce à la transmission d'un message identifiant cette action, l'exécution de cette même action sur l'ensemble des autres modules logiciels du même sous-ensemble gérant une réplication de la donnée numérique concernée par cette action. Par conséquent, quel que soit le module logiciel sur lequel est d'abord exécutée l'action, celui-ci remplit une fonction de gestionnaire de synchronisation dans le sous-ensemble et le résultat est le même : tout se passe comme si l'action s'était exécutée sur l'ensemble des modules logiciels comportant la donnée numérique concernée par l'action, dans le sous-ensemble considéré. Aucun module logiciel ne joue donc de rôle privilégié ou particulier du point de vue de la gestion des données numériques, ce qui rend le système informatique complet moins vulnérable aux ruptures de continuité de service en cas de défaillance d'un module logiciel ou d'un serveur.
De façon optionnelle également, un procédé de synchronisation selon l'invention peut comporter en outre les étapes suivantes :
- lors de la synchronisation du module logiciel candidat, celui-ci comportant une partie des données numériques, extraction d'un état des réplications de cette partie des données numériques sur au moins un autre module logiciel, et enregistrement du module logiciel candidat en tant que récepteur potentiel d'au moins un message de synchronisation identifiant une action sur une réplication de ses données numériques située sur un autre module logiciel,
- synchronisation des données numériques du module logiciel avec les données numériques de l'autre module logiciel et, pendant cette synchronisation, mise dans une file d'attente des messages de synchronisation éventuellement reçus, - une fois la synchronisation terminée, traitement de la file d'attente.
L'invention a également pour objet un système de synchronisation d'un ensemble de modules logiciels d'un système informatique, comportant plusieurs serveurs interconnectés en réseau, chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble de données dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation des données communes qu'ils gèrent, caractérisé en ce qu'il comporte :
- des moyens d'identification d'au moins un sous-ensemble regroupant des modules logiciels de l'ensemble activés et synchronisés entre eux, et
- pour chaque module logiciel candidat suite à son démarrage ou redémarrage, activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble :
• des moyens de recherche d'un autre module logiciel activé de l'ensemble,
- si un autre module logiciel activé est trouvé et s'il appartient à un sous- ensemble identifié, des moyens de synchronisation du module logiciel candidat avec au moins l'un des modules logiciels de ce sous-ensemble identifié, et - des moyens d'intégration du module logiciel candidat dans le sous- ensemble identifié.
Enfin, l'invention a également pour objet un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes d'un procédé de synchronisation tel que défini précédemment, lorsque ledit programme est exécuté sur un ordinateur.
L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels :
- la figure 1 représente schématiquement la structure générale d'un système informatique de stockage de données distribué en plusieurs serveurs interconnectés en réseau,
- la figure 2 illustre un exemple de répartition de données de description dans le système informatique de la figure 1 ,
- la figure 3 illustre les étapes successives d'un procédé de synchronisation mis en œuvre dans le système de la figure 1 selon un mode de réalisation de l'invention,
- la figure 4 représente un diagramme d'états et de transitions entre ces états de modules logiciels et matériels du système informatique de la figure
1 , pour la mise en œuvre du procédé de synchronisation de la figure 3,
- les figures 5 et 6 illustrent partiellement les étapes successives de procédés de synchronisation selon d'autres modes de réalisation de l'invention, - les figures 7 et 8 illustrent des exemples de mise en œuvre d'une étape particulière de synchronisation du procédé de synchronisation de la figure 3, et
- la figure 9 illustre un exemple de mise en œuvre d'une autre étape particulière de synchronisation du procédé de synchronisation de la figure 3.
Le système informatique 10 représenté sur la figure 1 comporte plusieurs serveurs 121 ; 122, 123, 124 et 125, répartis sur plusieurs domaines. Chaque serveur est de type classique et ne sera pas détaillé. En revanche, sur chaque serveur 1213 122, 123, 124 et 125 est installé au moins un module logiciel et matériel spécifique 141 s 142, 143, 144 et 145 de gestion d'un service, par exemple un service de stockage de données.
Cinq serveurs et deux domaines sont représentés sur la figure 1 à titre purement illustratif mais toute autre structure de système informatique distribué en plusieurs serveurs interconnectés en réseau peut convenir pour la mise en œuvre d'un procédé de synchronisation selon l'invention. Par souci de simplification également, il est représenté un module logiciel et matériel par serveur, de sorte que les modules et leurs serveurs respectifs pourront être confondus dans la suite de la description, sans pour autant devoir être confondus dans une mise en œuvre plus générale de l'invention. Le module logiciel et matériel "U1 du serveur 12! est détaillé sur la figure 1. Il comporte une première couche logicielle 16i constituée d'un système d'exploitation du serveur 12^ II comporte une deuxième couche logicielle 18i de gestion de données de description du service de stockage de données fourni par le système informatique 10. Il comporte une troisième couche logicielle et matérielle 2Oi remplissant au moins deux fonctions : une première fonction de stockage, sur un disque dur interne du serveur 121 ; des données de description du service de stockage et une deuxième fonction de mémoire cache, sur ce disque dur également, de données stockées sur des périphériques de stockage du serveur 12i. Enfin, il comporte une quatrième couche logicielle et matérielle 221 s 24i d'entrepôts de données, comportant au moins un entrepôt de données sur disque dur 22! et/ou au moins un entrepôt de données sur bandes magnétiques 24i. Pour la suite de la description, un entrepôt de données désigne un espace virtuel de stockage de données constitué d'une ou plusieurs partitions de disque, ou d'une ou plusieurs bandes magnétiques, parmi les périphériques de stockage du serveur auquel il est associé.
Les modules logiciels et matériels 142, 143, 144 et 145 des serveurs 122, 123, 124 et 125 ne seront pas détaillés parce qu'ils sont similaires au module logiciel et matériel λ Λλ.
Dans l'exemple illustré par la figure 1 , les serveurs 1213 122 et 123 sont interconnectés entre eux par un premier réseau 26 de type LAN pour créer un premier sous-ensemble ou domaine 28. Ce premier domaine 28 correspond par exemple à une organisation géographique localisée, telle qu'un site géographique, un bâtiment ou une salle informatique. Les serveurs 124 et 125 sont interconnectés entre eux par un second réseau 30 de type LAN pour créer un second sous-ensemble ou domaine 32. Ce second domaine 28 correspond également par exemple à une autre organisation géographique localisée, telle qu'un site géographique, un bâtiment ou une salle informatique. Ces deux domaines sont reliés entre eux par un réseau de type WAN 34, tel que le réseau Internet.
Ainsi ce système informatique en grappe de serveurs répartis sur plusieurs sites géographiques permet d'envisager un stockage de données d'autant plus sûr que celles-ci peuvent être répliquées sur des modules logiciels et matériels situés sur des sites géographiques différents.
Le service de stockage fourni par ce système informatique 10 et les données effectivement stockées sont avantageusement complètement définis et décrits par un ensemble de données de description qui vont être décrites dans leurs principes généraux en référence à la figure 2. De la sorte, la gestion de ces données de description par la couche logicielle 18, de l'un quelconque des modules logiciels et matériels 14, assure la gestion du service de stockage du système informatique 10.
Les données de description sont par exemple regroupées en plusieurs ensembles structurés selon leur nature et éventuellement liés entre eux. Un ensemble structuré, qui sera appelé « catalogue » dans la suite de la description, peut se présenter sous la forme d'une arborescence de répertoires contenant eux- mêmes d'autres répertoires et/ou des fichiers de données de description. La représentation des données de description selon une arborescence de répertoires et de fichiers comporte l'avantage d'être simple et donc économique à concevoir et à gérer. De plus cette représentation est souvent suffisante pour le service visé. Il est aussi possible, pour des applications plus complexes, de représenter et gérer les données de description en bases de données relationnelles.
Un catalogue de données de description peut être global, c'est-à-dire concerner des données de description utiles à l'ensemble du système informatique 10, ou bien local, c'est-à-dire concerner des données de description propres à un ou plusieurs module(s) logiciel(s) et matériel(s) 1415 142, 143, 144 ou 145 de gestion du service. Avantageusement, chaque catalogue est répliqué sur plusieurs serveurs ou modules logiciels et matériels. Lorsqu'il est global, il est de préférence répliqué sur l'ensemble des modules logiciels et matériels. Lorsqu'il est local, il est répliqué sur un nombre prédéterminé de modules logiciels et matériels dont au moins celui ou ceux qu'il concerne.
A titre d'exemple, la figure 2 représente une répartition possible de catalogues de données de description entre les cinq modules logiciels et matériels 141 s 142, 143, 144 et 145.
Un premier catalogue CA global est répliqué sur les cinq modules logiciels et matériels 1415 142, 143, 144 et 145. Il comporte par exemple des données décrivant l'infrastructure générale et le fonctionnement général du système informatique 10 pour la fourniture du service, notamment l'arborescence des domaines et des modules logiciels et matériels du système informatique 10. Il peut aussi comporter des données décrivant des utilisateurs potentiels du service de stockage de données et leurs droits d'accès, par exemple des utilisateurs préalablement inscrits, ainsi que les zones de partage, la structure ou le mode de stockage et la réplication de données stockées. D'autres catalogues sont locaux, comme par exemple le catalogue CBi , contenant des données de description propres au module logiciel et matériel 14i telles que des données relatives à l'infrastructure locale et au fonctionnement local du serveur 12i et de ses périphériques de stockage, ou à l'organisation en entrepôts du module logiciel et matériel 141 s ou bien encore aux données numériques effectivement stockées dans ces entrepôts. Ce catalogue est répliqué en trois exemplaires, dont un sur le module logiciel et matériel λ Λλ. Pour améliorer la sécurité et la robustesse du système informatique 10, le catalogue CBi peut être répliqué dans plusieurs domaines différents. Ici, le système complet comportant deux domaines 28 et 32, le catalogue CBi est par exemple sauvegardé sur les modules 14i et 1 A2 du domaine 28 et sur le module 145 du domaine 32.
De même, les modules logiciels et matériels 142, 143, 144 et 145 sont associés à des catalogues locaux respectifs C62, C63, C64 et C65. Par exemple, le catalogue C62 est sauvegardé sur les modules 142 et 143 du domaine 28 et sur le module 144 du domaine 32 ; le catalogue C63 est sauvegardé sur le module 143 du domaine 28 et sur les modules 144 et 145 du domaine 32 ; le catalogue C64 est sauvegardé sur le module 144 du domaine 32 et sur les modules 14i et 143 du domaine 28 ; et le catalogue C65 est sauvegardé sur le module 145 du domaine 32 et sur les modules 1 Aλ et 1 A2 du domaine 28.
La liste précitée de catalogues de données de description n'est pas exhaustive et n'est fournie qu'à titre d'exemple, de même que le nombre de réplications de chaque catalogue.
Par cette réplication des catalogues, ici sur au moins trois modules logiciels et matériels pour chaque catalogue, on remarque que même si un module logiciel et matériel, voire deux, est (sont) hors d'état de fonctionnement, le système dans son ensemble est capable d'accéder à l'ensemble des données de description de sorte que la gestion du service de stockage de données n'est pas nécessairement interrompue. En pratique, cette continuité de service maintenue est efficace à partir du moment où une synchronisation des catalogues et plus généralement des données de description est assurée. Les données effectivement stockées sont également répliquées pour des questions de sécurité du service de stockage fourni de sorte que toute action ou modification portant sur ces données doit être aussi être appliquée aux différentes réplications. Une synchronisation des données effectivement stockées doit donc aussi être assurée.
En d'autres termes, une synchronisation des modules logiciels et matériels 141 ; 142, 143, 144 et 145, comportant une synchronisation des données communes qu'ils gèrent, doit être assurée.
Pour cela, un procédé de synchronisation selon l'invention va maintenant être détaillé en référence aux figures 3, 4, 5 et 6.
Ce procédé de synchronisation vise à regrouper les modules logiciels et matériels 1415 142, 143, 144 et 145 du système informatique 10 en au moins un sous- ensemble identifié dans lequel tous les modules logiciels et matériels sont activés et synchronisés entre eux. Sa finalité peut même être de n'aboutir qu'à un seul sous- ensemble synchronisé, celui-ci regroupant alors tous les modules logiciels et matériels 1415 142, 143, 144 et 145 du système informatique 10, synchronisés entre eux.
Ce procédé vise donc principalement à gérer le démarrage ou le redémarrage d'un module logiciel et matériel du système informatique 10 en vue de l'intégrer à l'un des sous-ensembles synchronisés existants ou à un nouveau sous-ensemble à créer. De façon optionnelle, il vise également à gérer des arrêts de modules logiciels et matériels, des ruptures de réseau, des détections d'un sous-ensemble synchronisé par un autre, etc. : autant d'événements susceptibles de faire évoluer les sous- ensembles synchronisés du système informatique 10. Comme illustré sur la figure 3, lors d'une première étape 100, résultant par exemple de l'activation d'un module logiciel et matériel 14, suite au démarrage d'un nouveau serveur dans le système informatique 10 ou au redémarrage d'un serveur existant, ce module logiciel et matériel, activé mais pas encore synchronisé avec un autre module logiciel et matériel du système informatique 10, recherche un autre module logiciel et matériel activé du système informatique 10.
Si un autre module logiciel et matériel 14, activé est trouvé et s'il appartient à un sous-ensemble synchronisé identifié, on passe à une étape 102 de sélection d'au moins l'un des modules logiciels et matériels du sous-ensemble identifié pour réaliser une synchronisation du module logiciel et matériel 14, avec ce(s) module(s) logiciel(s) et matériel(s) sélectionné(s). En premier lieu, la sélection est basée sur les données numériques du module logiciel et matériel 14, qui doivent être synchronisées. Les modules logiciels et matériels du sous-ensemble identifié concernés par cette sélection sont donc ceux qui gèrent des données en commun avec le module logiciel et matériel 14,. De façon optionnelle, cette sélection est aussi fonction d'une charge de travail d'au moins une partie des modules logiciels et matériels de ce sous-ensemble identifié. Par exemple, il peut être considéré qu'au delà d'une charge prédéterminée, un module logiciel et matériel du sous-ensemble identifié ne peut pas être sélectionné. Ainsi, si un module logiciel et matériel sollicité a temporairement une surcharge, il peut indiquer au module logiciel et matériel 14, de choisir un autre module logiciel et matériel. Si aucun module logiciel et matériel sollicité n'est disponible à un instant donné, le module logiciel et matériel 14, peut attendre que le pic d'activité se termine pour se synchroniser. Ainsi, la charge de travail est répartie équitablement entre les modules logiciels et matériels sollicités si un grand nombre de modules logiciels et matériels démarrent en même temps ou si un module logiciel et matériel démarre alors que les autres sont très sollicités.
Ensuite, au cours d'une étape 104, une synchronisation du module logiciel et matériel 14, avec le ou les modules sélectionnés est réalisée. Un exemple non limitatif d'une telle synchronisation sera détaillé en référence à la figure 9. Lors d'une étape 106 suivante, le module logiciel et matériel 14, est intégré au sous-ensemble synchronisé identifié qui comporte donc désormais un élément de plus.
Enfin, on passe à une étape 108 au cours de laquelle on maintient en permanence les modules logiciels et matériels du sous-ensemble identifié synchronisés entre eux, selon un mécanisme prédéterminé dont un exemple non limitatif sera détaillé en référence aux figures 7 et 8. Au cours de cette étape également, le système informatique 10 surveille tout événement susceptible de faire évoluer le sous-ensemble identifié : détection d'un autre sous-ensemble synchronisé avec lequel fusionner, détection d'une rupture de connexion entre deux parties du sous-ensemble destinées alors à se séparer, perte d'un module logiciel et matériel (par exemple par arrêt du serveur correspondant), etc.
A l'étape 100, si un autre module logiciel et matériel 14, activé est trouvé mais qu'il n'appartient pas à un sous-ensemble synchronisé identifié, on passe à une étape 1 10 de synchronisation du module logiciel et matériel 14, avec le module logiciel et matériel 14,. Cette synchronisation peut être identique à celle envisagée à l'étape 104. Elle sera détaillée en référence à la figure 9.
Ensuite, au cours d'une étape 1 12, un nouveau sous-ensemble synchronisé est créé et identifié dans lequel on intègre les deux modules logiciels et matériels 14, et 14r
Enfin, on passe à une étape 1 14 au cours de laquelle on maintient en permanence les deux modules logiciels et matériels 14, et 14, de ce nouveau sous- ensemble identifié synchronisés entre eux, selon un mécanisme prédéterminé qui peut être identique à celui envisagé à l'étape 108 et qui sera détaillé en référence aux figures 7 et 8. Au cours de cette étape également, le système informatique 10 surveille tout événement susceptible de faire évoluer le nouveau sous-ensemble créé : détection d'un autre sous-ensemble synchronisé avec lequel fusionner, détection d'une rupture de connexion entre les deux modules logiciels et matériels 14, et 14, destinés alors à se séparer, perte d'un module logiciel et matériel (par exemple par arrêt du serveur correspondant), etc.
A l'étape 100, si aucun autre module logiciel et matériel 14, activé n'est trouvé, le module logiciel et matériel 14, ne peut pas être synchronisé et reste isolé, bien qu'activé donc opérationnel. On passe alors à une étape 1 16, au cours de laquelle le système informatique 10 surveille tout événement susceptible de faire évoluer la synchronisation du module logiciel et matériel 14, : détection d'un sous-ensemble synchronisé dans lequel il pourrait être intégré, détection d'un autre module logiciel et matériel activé mais isolé avec lequel il pourrait être synchronisé, arrêt du serveur sur lequel il est implémenté, etc.
Dans un mode de réalisation de l'invention, chaque sous-ensemble synchronisé inclut un module logiciel et matériel sélectionné pour être spécifiquement marqué comme identifiant de ce sous-ensemble. Par exemple, dans la situation de l'étape 1 12 précédemment décrite, c'est le module logiciel et matériel 14, qui peut être sélectionné comme devant identifier le nouveau sous-ensemble créé suite à sa détection par le module logiciel et matériel 14,. Un sous-ensemble est alors identifié par ce module logiciel et matériel sélectionné, de sorte que tout événement générateur d'une exclusion de ce module logiciel et matériel sélectionné du sous-ensemble génère la disparition de ce sous- ensemble et la création éventuelle d'un ou plusieurs nouveaux sous-ensembles. Un module logiciel et matériel quelconque 14, du système informatique 10 peut donc se trouver dans quatre états différents E1 , E2, E3 et E4 représentés sur la figure 4 avec leurs transitions.
Dans le premier état E1 , le module logiciel et matériel 14, est arrêté. Dans le second état E2, il est activé mais isolé, c'est-à-dire sans être synchronisé avec un autre module logiciel et matériel du système informatique 10. Dans le troisième état E3, il est membre d'un sous-ensemble synchronisé identifié. Enfin, dans le quatrième état E4, il est membre d'un sous-ensemble synchronisé identifié et marqué comme identifiant de ce sous-ensemble. Une première transition t1 fait passer le module logiciel et matériel 14, de son état arrêté E1 à l'étape 100 de recherche d'un autre module logiciel et matériel activé du système informatique 10. En d'autres termes, au cours de l'étape 100, le module logiciel et matériel 14, est activé mais à la recherche d'une synchronisation des données numériques qu'il gère. Cette situation est provoquée par exemple par le démarrage ou le redémarrage du serveur correspondant.
Une deuxième transition t2 fait passer le module logiciel et matériel 14, de l'étape 100 à son état activé mais isolé E2. C'est l'état dans lequel il se trouve si suite à l'étape 100 il passe à l'étape 1 16 par ce qu'il n'a détecté aucun autre module logiciel et matériel activé. Une troisième transition t3 fait passer le module logiciel et matériel 14, de l'étape 100 à son état E3 de membre d'un sous-ensemble synchronisé identifié. C'est l'état dans lequel il se trouve si suite à l'étape 100 il passe à l'étape 102 (il rejoint un sous-ensemble synchronisé existant) ou 1 10 (il rejoint un sous-ensemble synchronisé créé par le module logiciel et matériel isolé qu'il a détecté). Une quatrième transition t4 fait passer le module logiciel et matériel 14, de son état activé mais isolé E2 à son état E4 d'identifiant d'un sous-ensemble synchronisé. C'est l'état dans lequel il se trouve s'il a été détecté par un autre module logiciel et matériel pour effectuer une synchronisation. Il devient alors l'identifiant du nouveau sous-ensemble créé. Une cinquième transition t5 fait passer le module logiciel et matériel 14, de son état E3 de membre d'un sous-ensemble synchronisé identifié à son état E4 d'identifiant d'un sous-ensemble synchronisé. C'est l'état dans lequel il peut se trouver si le sous-ensemble auquel il appartient a perdu son module identifiant (arrêt du serveur correspondant par exemple), ou si le module logiciel et matériel 14, lui- même a perdu le contact avec le module identifiant du sous-ensemble dans lequel il se trouve suite à une rupture de connexion. Il peut alors devenir l'identifiant d'un nouveau sous-ensemble créé, mais il doit pour cela être sélectionné.
En effet, dans cette situation, un nouveau module identifiant doit être sélectionné pour tous les modules logiciels et matériels du sous-ensemble considéré qui ont perdu contact avec le module identifiant initial : une solution est de créer un nouveau sous-ensemble pour tous ces modules logiciels et matériels et d'en sélectionner un pour être l'identifiant de ce nouveau sous-ensemble, par exemple le module logiciel et matériel 14,.
En d'autres termes, dans le mode de réalisation décrit en référence à la figure 4, si le module identifiant d'un sous-ensemble synchronisé s'arrête, l'un des autres modules logiciels et matériels de ce sous-ensemble devient le module identifiant. Mais pour cela, un nouveau sous-ensemble est créé et tous les autres modules logiciels et matériels de l'ancien sous-ensemble deviennent membre du nouveau sous-ensemble. Si la connexion réseau entre deux sites distants d'un même sous- ensemble synchronisé est rompue, une partie des membres de ce sous-ensemble va se trouver séparée du module identifiant de ce sous-ensemble. Parmi ces modules logiciels et matériels séparés du module identifiant, l'un va être sélectionné pour devenir le module identifiant d'un nouveau sous-ensemble qui comprendra les modules logiciels et matériels du site isolé. En pratique, un nouveau sous-ensemble est créé chaque fois qu'un ou plusieurs modules logiciels et matériels sont séparés du module identifiant. L'un d'eux devient par sélection (transition t5) le module identifiant du nouveau sous-ensemble.
Une sixième transition t6 fait passer le module logiciel et matériel 14, de son état activé mais isolé E2 à son état arrêté E1. Cette transition se produit notamment dans deux situations :
- une première situation est l'arrêt du serveur sur lequel est implanté le module logiciel et matériel 14, ;
- une seconde situation est la détection par le module logiciel et matériel 14, d'un sous-ensemble synchronisé identifié ou d'un autre module logiciel et matériel dans l'état E2.
En effet, dans la seconde situation, il doit se synchroniser avec au moins l'un des modules logiciels et matériels du sous-ensemble détecté pour en faire partie (étapes 102 à 106) ou avec l'autre module logiciel et matériel isolé détecté (étapes 1 10, 1 12). Or, comme le module logiciel et matériel 14, a évolué de manière isolée, une solution est de le redémarrer, ce qui devrait conduire, via l'étape 100, aux transitions t1 et t3 lors de ce redémarrage.
Une septième transition t7 fait passer le module logiciel et matériel 14, de son état E3 ou E4 de membre ou identifiant d'un sous-ensemble synchronisé identifié à son état arrêté E1.
Cette transition se produit notamment dans deux situations :
- une première situation est l'arrêt du serveur sur lequel est implanté le module logiciel et matériel 14, ;
- une seconde situation est la détection par le sous-ensemble dans lequel il se trouve d'un autre sous-ensemble synchronisé identifié avec lequel il peut fusionner.
Dans la seconde situation, si la fusion se fait par maintien de l'autre sous- ensemble et disparition du sous-ensemble dans lequel le module logiciel et matériel 14, se trouve, ce dernier et les autres modules logiciels et matériels du sous- ensemble amené à disparaître doivent se synchroniser avec au moins l'un des modules logiciels et matériels de l'autre sous-ensemble détecté pour en faire partie (étapes 102 à 106). Or, comme les deux sous-ensembles ont évolué de manière isolée, une solution est de redémarrer le module logiciel et matériel 14, et les autres modules logiciels et matériels du sous-ensemble amené à disparaître, ce qui devrait conduire, via l'étape 100, aux transitions t1 et t3 lors de ce redémarrage.
La figure 5 illustre les étapes successives mises en œuvre de façon optionnelle par un procédé de synchronisation selon l'invention, lorsqu'un sous- ensemble synchronisé du système informatique 10 en détecte un autre, conformément à la seconde situation de la transition t7 décrite précédemment. Au cours d'une première étape 200, un premier sous-ensemble synchronisé
S1 détecte un second sous-ensemble synchronisé S2 avec lequel il est possible de fusionner.
Lors d'une étape suivante 202, un choix est fait pour savoir lequel des deux sous-ensembles doit être supprimé et lequel doit être conservé pour regrouper finalement tous les modules logiciels et matériels de ces deux sous-ensembles. Le sous-ensemble conservé sera noté Si, i = 1 ou 2, et le sous-ensemble supprimé sera noté Sj, j = 2 ou 1 .
Le choix se fait par exemple par logique majoritaire :
- le sous-ensemble comportant le plus grand nombre de modules logiciels et matériels est conservé, - si les deux sous-ensembles comportent le même nombre de modules logiciels et matériels, le hasard détermine celui qui est conservé. Le critère de choix pourrait être différent ou affiné. Il pourrait par exemple prendre en compte un nombre de modifications exécutées sur les données gérées par les modules logiciels et matériels de chaque sous-ensemble S1 et S2. Il pourrait aussi prendre en compte le nombre de sessions ouvertes par des utilisateurs sur les modules logiciels et matériels de chaque sous-ensemble S1 et S2, puisque le redémarrage d'un module logiciel et matériel nécessite l'arrêt des sessions en cours sur ce module et peut provoquer une gêne pour un ou plusieurs utilisateurs. Ensuite, à une étape 204, chaque module logiciel et matériel du sous- ensemble Sj se synchronise avec au moins un module logiciel et matériel du sous- ensemble Si. Un exemple non limitatif d'une telle synchronisation sera détaillé en référence à la figure 9.
A l'étape 206 suivante, le sous-ensemble Sj est supprimé. Enfin, au cours d'une dernière étape 208, tous les modules logiciels et matériels initialement dans ce sous-ensemble intègrent le sous-ensemble Si.
Les étapes 204, 206 et 208 s'appliquent à tous les modules logiciels et matériels du sous-ensemble Sj et accompagnent leurs transitions successives t7, t1 et t3. La figure 6 illustre les étapes successives mises en œuvre de façon optionnelle par un procédé de synchronisation selon l'invention, lorsqu'une rupture de connexion à l'intérieur d'un sous-ensemble synchronisé du système informatique 10 génère deux parties complémentaires de ce sous-ensemble, comportant chacune au moins un module logiciel et ne pouvant plus communiquer entre elles, conformément à la situation de la transition t5 décrite précédemment.
Au cours d'une première étape 300, un sous-ensemble synchronisé S1 détecte une rupture de connexion entre deux parties complémentaires de S1 comportant chacune au moins un module logiciel.
L'une des deux parties complémentaires de S1 comporte nécessairement son module identifiant. Cette partie reprend alors l'identité de S1.
L'autre des deux parties comporte des modules logiciels et matériels ayant perdu tout contact avec le module identifiant de S1. On passe alors à une étape 302, lors de laquelle un nouveau sous-ensemble S2 est créé dans lequel sont intégrés tous les modules logiciels et matériels de cette autre partie. Au cours de cette intégration, aucune synchronisation n'est nécessaire. Seul un module logiciel et matériel de ce nouveau sous-ensemble S2 doit être sélectionné pour en être l'identifiant. Ce module logiciel et matériel sélectionné suit alors la transition t5.
Il a été vu précédemment qu'au cours des étapes 108 et 1 14, on maintient en permanence les modules logiciels et matériels d'un même sous-ensemble synchronisés entre eux, selon un mécanisme prédéterminé dont un exemple non limitatif va maintenant être détaillé.
Pour cela, la couche logicielle de chaque module logiciel et matériel du système informatique 10 comporte :
- des moyens d'émission d'un message de synchronisation, identifiant une action agissant sur une donnée numérique qu'elle gère, vers l'ensemble des autres modules logiciels et matériels appartenant au même sous- ensemble synchronisé et comportant une réplication de cette donnée numérique, suite à l'exécution de cette action sur ce module logiciel et matériel, et - des moyens d'exécution d'une action agissant sur une donnée numérique et identifiée dans un message de synchronisation, de manière à agir sur la réplication de la donnée numérique située sur ce module logiciel et matériel, en réponse à une réception de ce message de synchronisation. Comme les données numériques, notamment les données de description, gérées par un module logiciel et matériel sont avantageusement organisées en catalogues, un mécanisme de synchronisation permanent des catalogues au sein d'un même sous-ensemble va maintenant être détaillé.
Tout d'abord, il convient de préciser qu'une synchronisation d'un catalogue dans un sous-ensemble s'impose à partir du moment où une réplication d'une donnée de description de ce catalogue est modifiée sur un module logiciel et matériel quelconque de ce sous-ensemble. Une modification de donnée de description peut être complètement définie par une action A déterminée sur cette donnée de description. Par exemple, une modification d'une donnée de description concernant un utilisateur peut être définie par une action sur ses droits d'accès au système informatique 10 choisis parmi un ensemble de droits comportant des droits d'administrateur système, des droits d'administrateur de données, des droits d'opérateur, des droits de simple utilisateur. Dans ce cas, l'action A identifie précisément la donnée de description à laquelle elle s'applique et la nouvelle valeur de cette donnée de description (en l'occurrence : administrateur système, administrateur de données, opérateur ou simple utilisateur). L'action A est identifiée par un identificateur universel unique et peut être sauvegardée, de sorte que l'état courant d'une donnée de description peut être retrouvé en connaissant l'état initial de cette donnée de description et la série des actions qui ont été opérées sur elle depuis sa création. Chaque réplication locale d'une donnée de description D est en outre associée à une version V qui comporte un numéro de version N et une signature S. Dans un mode de réalisation préféré, toute modification création ou suppression apportée par une action A sur une réplication de la donnée de description D modifie également sa version V de la façon suivante : - N ^ N + 1 ;
- S <- S + lncr(A), où lncr(A) est une valeur aléatoire générée à l'exécution de l'action A sur la réplication de la donnée de description concernée. Comme illustré sur la figure 7, lors d'une première étape 400, une action A est exécutée sur une réplication Di de la donnée de description D, cette réplication Di étant stockée par le serveur 12,. Avant l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val, un numéro de version N et une signature S. Après l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val', un numéro de version N' = N + 1 et une signature S' = S + lncr(A).
Pendant l'exécution de l'action A, la réplication Di de la donnée de description D est protégée de sorte que d'autres actions sur cette réplication ne puissent pas être exécutées. Ces autres actions éventuelles sont mises en attente dans une liste prévue à cet effet et sont exécutées séquentiellement dès la fin d'exécution de l'action A.
Lors d'une étape 402 suivante, un message de synchronisation M est généré par le module logiciel et matériel 14,. Ce message M comporte l'identifiant universel de l'action A, ou une description complète de cette action A, ainsi que la valeur de l'incrément de signature lncr(A). Lors de cette même étape, le message M est transmis à des modules logiciels et matériels 14j et 14k appartenant au même sous- ensemble que le module logiciel et matériel 14, et comportant également une réplication de la donnée de description D.
Ensuite, lors d'une étape 404, à réception du message de synchronisation M, le module logiciel et matériel 14j exécute l'action A sur la réplication Dj de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les valeurs respectives val', N' et S'. La mise à jour du numéro de version N se fait en appliquant la même règle que celle appliquée par le module logiciel et matériel 14, et la mise à jour de la signature se fait grâce à la transmission de l'incrément de signature lncr(A) généré par le module logiciel et matériel 14,.
Ensuite également, lors d'une étape 406, à réception du message de synchronisation M, le module logiciel et matériel 14k exécute l'action A sur la réplication Dk de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les valeurs respectives val',
N' et S'.
Grâce à ce procédé de synchronisation répété à chaque exécution d'une action sur l'une quelconque des données de description du système informatique 10, les catalogues répliqués sur plusieurs nœuds d'un même sous-ensemble synchronisé restent identiques, au temps de réalisation de la synchronisation près.
D'autres techniques de modification de la version V d'une réplication de donnée de description que celle présentée en référence à la figure 7 sont envisageables en alternative, mais il est avantageux de prévoir que la mise à jour de la signature S soit incrémentale et commutative, ce qui permet de gérer les modifications croisées de différentes réplications d'une même donnée de description, comme cela est illustré par la figure 8.
En effet, lors d'une première étape 500, une action A est exécutée sur une première instance d'une réplication Di de la donnée de description D, cette réplication Di étant stockée par le serveur 12,. Avant l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val, un numéro de version N et une signature S. Après l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val', un numéro de version N' = N + 1 et une signature S' = S + lncr(A).
Avant même que le module logiciel et matériel 14, n'ait eu le temps d'envoyer un message de synchronisation MA aux autres modules logiciels et matériels de son sous-ensemble ayant une réplication de la donnée de description D, une action B est exécutée sur l'un d'entre eux, le module logiciel et matériel 14J; lors d'une étape 502. Lors de cette étape, l'action B est exécutée sur une seconde instance de la réplication Dj de la donnée de description D. Avant l'exécution de l'action B, la réplication Dj de la donnée de description D a la valeur val, le numéro de version N et la signature S. Après l'exécution de l'action B, la réplication Dj de la donnée de description D a une valeur val", différente de val', le numéro de version N' = N + 1 et une signature S" = S + lncr(B), différente de la signature S'. Ainsi, à l'issue des étapes 500 et 502, bien que les réplications Di et Dj aient le même numéro de version N', leurs signatures et valeurs respectives sont différentes. Leurs versions V et V", identifiées à la fois par leurs numéros de version et par leurs signatures, sont donc différentes. Lors d'une étape 504 suivante, le message de synchronisation MA est généré par le module logiciel et matériel 14,. Ce message MA comporte l'identifiant universel de l'action A, ou une description complète de cette action A, ainsi que la valeur de l'incrément de signature lncr(A). Lors de cette même étape, le message MA est transmis notamment au module logiciel et matériels 14, comportant la réplication Dj. De même, lors d'une étape 506 suivante, un message de synchronisation MB est généré par le module logiciel et matériel 14,. Ce message MB comporte l'identifiant universel de l'action B, ou une description complète de cette action B, ainsi que la valeur de l'incrément de signature lncr(B). Lors de cette même étape, le message MB est transmis notamment au module logiciel et matériel 14, comportant la réplication Di.
Lors d'une étape 508, à réception du message de synchronisation MB, le module logiciel et matériel 14, exécute l'action B sur la réplication Di de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les valeurs respectives val'", N" et S'". La valeur val'" résulte de l'action B sur val', c'est-à-dire de la combinaison des actions A et B sur la valeur val de la donnée de description D. La valeur N" est égale à N' + 1 , soit N + 2. Enfin, la valeur de S'" est égale à S' + lncr(B) = S + lncr(A) + lncr(B).
Enfin, lors d'une étape 510, à réception du message de synchronisation MA, le module logiciel et matériel 14, exécute l'action A sur la réplication Dj de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les mêmes valeurs respectives val'", N" et S'" que pour Di à l'étape 508. En effet, la valeur val'" résulte de l'action A sur val", c'est-à-dire de la combinaison des actions A et B sur la valeur val de la donnée de description D. La valeur N" est égale à N' + 1 , soit N + 2. Enfin, la valeur de S'" est égale à S" + lncr(A) = S + lncr(B) + lncr(A), grâce à la propriété incrémentale et commutative de la mise à jour de la signature.
On remarque donc qu'à l'issue des étapes 508 et 510, les réplications Di et Dj sont correctement synchronisées, leurs versions identiques attestant de l'identité de leurs valeurs. II a été vu précédemment qu'au cours des étapes 104, 1 10 et 204, on réalise ponctuellement un synchronisation d'un module logiciel et matériel 14, avec au moins un module logiciel et matériel 14, sélectionné, selon un mécanisme prédéterminé dont un exemple non limitatif va maintenant être détaillé en référence à la figure 9. Ce mécanisme permet de rattraper un éventuel retard ou un décalage pris par le module logiciel et matériel 14, par rapport au module logiciel et matériel 14, sélectionné dans la gestion des données de description qu'ils ont en commun.
Selon ce mécanisme, lors d'une première étape 600 au cours de laquelle le module logiciel et matériel 14, est en recherche d'un autre module logiciel et matériel pour la synchronisation d'au moins l'un de ses catalogues de données de description, celui-ci sélectionne le module logiciel et matériel 14,. Il sélectionne bien sûr l'un des modules logiciels et matériels gérant une réplication du catalogue qu'il souhaite mettre à jour. Lorsque le module logiciel et matériel 14, est sélectionné, au cours de cette même étape 600, le module logiciel et matériel 14, lui transmet son identifiant ainsi qu'une information concernant les versions de chacune des données de description de son catalogue (i.e. numéro de version et signature).
Ensuite, lors d'une étape 602, le module logiciel et matériel 14, établit une représentation figée du contenu de son catalogue et crée une liste d'attente pour la réception de tout nouveau message de synchronisation concernant ce catalogue. Suite à l'étape 600 également, lors d'une étape 604, le module logiciel et matériel 14, est inscrit comme possesseur d'une réplication du catalogue et destinataire de messages de synchronisation éventuels concernant ce catalogue. Il crée lors de cette étape également une liste d'attente pour la réception de tout nouveau message de synchronisation concernant ce catalogue. Suite à l'étape 602, lors d'une étape 606, le module logiciel et matériel 14, compare les versions des données de description du module logiciel et matériel 14, avec les siennes.
Cette recherche des différences entre deux réplications d'un même catalogue peut être facilitée lorsque le catalogue de données de description est structuré selon un arbre dans lequel les données de description sont soit des nœuds (lorsqu'elles ont une relation de filiation directe ou indirecte avec au moins une donnée de description « fille »), soit des feuilles (lorsqu'elles sont situées en terminaison de l'arbre dans cette représentation hiérarchique). En effet, dans ce cas, chaque nœud de l'arbre peut être associé à une signature globale qui représente la somme des signatures de ses données « filles », c'est-à-dire les données de description situées en aval de ce nœud dans l'arbre. Ainsi, la recherche des différences se fait en parcourant l'arbre, de sa racine vers ses feuilles, autrement dit d'amont en aval : chaque fois qu'un nœud de l'arbre a une même signature globale dans les deux réplications du catalogue, cela signifie que ce nœud et l'ensemble des données « filles » de ce nœud sont identiques, de sorte qu'il n'est pas utile d'explorer plus avant la sous- arborescence de l'arbre définie à partir de ce nœud.
Lors de cette même étape, le module logiciel et matériel 14, constitue une première liste de données de description comportant les valeurs et versions des données de description dont la version qu'il possède est plus récente que celle du module logiciel et matériel 14,. Il constitue en outre éventuellement une seconde liste de données de description comportant les identifiants des données de description dont la version qu'il possède est moins récente que celle du module logiciel et matériel 14,. Il transmet alors ces deux listes au module logiciel et matériel 14,.
Lors d'une étape 608, le module logiciel et matériel 14, traite la première liste de manière à mettre à jour, dans sa réplication du catalogue, les données de description concernées.
Lors d'une étape 610, il transmet au module logiciel et matériel 14, les valeurs et versions des données de description identifiées dans la seconde liste.
Ensuite, lors d'une étape 612, le module logiciel et matériel 14, traite ces valeurs et versions de données de description identifiées dans la seconde liste de manière à mettre à jour, dans sa réplication du catalogue, les données de description concernées. Chaque fois qu'il traite une mise à jour de donnée de description, il transmet un message de synchronisation, conformément au procédé décrit en référence à la figure 7, aux éventuels modules logiciels et matériels de son sous- ensemble comportant une réplication de cette donnée de description à l'exception du module logiciel et matériel 14,.
Suite à cette mise à jour de catalogue entre le module logiciel et matériel 14, et le module logiciel et matériel 14,, la représentation figée du contenu du catalogue est désactivée du côté du module logiciel et matériel 14, lors d'une étape 614 et le module logiciel et matériel 14, en est informé lors d'une étape 616.
Ainsi, lors de dernières étapes respectives 618 et 620, les modules logiciels et matériels 14, et 14, se libèrent pour traiter le cas échéant les messages de synchronisation reçus dans leurs listes d'attente respectives pendant toute la durée des étapes 606 à 616, de manière à résorber et supprimer ces listes d'attente, puis pour se mettre en situation de reproduire les étapes de synchronisation telles que décrites en référence aux figures 7 et 8 lorsque la situation se présente.
Les étapes 600 à 618 sont répétées autant de fois que nécessaire sur le module logiciel et matériel 14, pour la mise à jour de l'ensemble de ses catalogues de données de description.
Il apparaît clairement qu'un procédé et/ou système tel que décrit précédemment permet la synchronisation décentralisée des données répliquées d'un système informatique distribué en plusieurs serveurs, tout en assurant un suivi global de la synchronisation de l'ensemble des modules logiciels par la présence et la gestion de l'évolution de sous-ensembles synchronisés.
On notera par ailleurs que l'invention n'est pas limitée au mode de réalisation décrit précédemment. Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées au mode de réalisation décrit ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. Dans les revendications qui suivent, les termes utilisés ne doivent pas être interprétés comme limitant les revendications au mode de réalisation exposé dans la présente description, mais doivent être interprétés pour y inclure tous les équivalents que les revendications visent à couvrir du fait de leur formulation et dont la prévision est à la portée de l'homme de l'art en appliquant ses connaissances générales à la mise en œuvre de l'enseignement qui vient de lui être divulgué.

Claims

REVENDICATIONS
1. Procédé de synchronisation d'un ensemble de modules logiciels (1 Aλ , 1813
142, 143, 144, 145) d'un système informatique (10) distribué en plusieurs serveurs (12i, 122, 123, 124, 125) interconnectés en réseau (26, 30, 34), chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble
(CA, CBI , CB2, CB3, CB4, CB5) de données numériques dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation (102, 104, 1 10) des données communes qu'ils gèrent, caractérisé en ce qu'il comporte les étapes suivantes :
- regroupement (106, 1 12) de modules logiciels de l'ensemble, activés et synchronisés entre eux, en au moins un sous-ensemble synchronisé (S1 , S2) et identification de ce sous-ensemble, et - pour chaque module logiciel candidat (14,) suite à son démarrage ou redémarrage, activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble : - recherche (100) d'un autre module logiciel activé de l'ensemble,
• si un autre module logiciel activé est trouvé et s'il appartient à un sous-ensemble identifié, synchronisation (102, 104) du module logiciel candidat avec au moins l'un (14,) des modules logiciels de ce sous-ensemble identifié, et
• intégration (106) du module logiciel candidat dans le sous- ensemble identifié.
2. Procédé de synchronisation selon la revendication 1 , dans lequel, pour chaque module logiciel candidat (14,), si un autre module logiciel est trouvé mais qu'il n'appartient pas à un sous-ensemble identifié :
- un nouveau sous-ensemble synchronisé est créé et identifié (1 12),
- le module logiciel candidat est synchronisé avec l'autre module logiciel trouvé (14j), et
- le module logiciel candidat (14,) et cet autre module logiciel trouvé (14,) sont intégrés (1 12) dans ce nouveau sous-ensemble identifié.
3. Procédé de synchronisation selon la revendication 1 ou 2, dans lequel, lors de la synchronisation (102, 104) du module logiciel candidat (14,) avec au moins l'un (14,) des modules logiciels du sous-ensemble identifié comportant l'autre module logiciel trouvé, le choix (102) d'au moins un module logiciel (14,) de ce sous- ensemble identifié pour réaliser la synchronisation est fonction d'une charge de travail d'au moins une partie des modules logiciels de ce sous-ensemble identifié.
4. Procédé de synchronisation selon l'une quelconque des revendications 1 à 3, comportant en outre les étapes suivantes :
- Détection (200), par un premier sous-ensemble identifié (S1 ), d'un second sous-ensemble identifié (S2),
- regroupement (208) des modules logiciels de ces deux sous- ensembles identifiés dans l'un (Si) de ces deux sous-ensembles identifiés,
- suppression (204) de l'autre de ces deux sous-ensembles identifiés, et
- synchronisation (206) de chaque module logiciel faisant initialement partie du sous-ensemble supprimé avec au moins l'un des modules logiciels du sous-ensemble (Si) choisi pour le regroupement.
5. Procédé de synchronisation selon l'une quelconque des revendications 1 à 4, dans lequel, dans chaque sous-ensemble identifié, un module logiciel est sélectionné pour être spécifiquement marqué comme identifiant de ce sous- ensemble identifié.
6. Procédé de synchronisation selon l'une quelconque des revendications 1 à 5, comportant en outre les étapes suivantes :
- détection (300) d'une rupture de connexion entre deux parties complémentaires d'un sous-ensemble identifié (S1 ), comportant chacune au moins un module logiciel,
- à partir de ce sous-ensemble identifié (S1 ), génération (302) et identification de deux sous-ensembles (S1 , S2) intégrant l'une, respectivement l'autre, des deux parties complémentaires.
7. Procédé de synchronisation selon l'une quelconque des revendications 1 à 6, comportant en outre les étapes suivantes :
- exécution (400), sur un premier module logiciel (14i) appartenant à un sous-ensemble identifié, d'une action (A) agissant sur une donnée numérique (Di) gérée par ce premier module logiciel,
- transmission (402) d'un message de synchronisation (M) identifiant l'action (A) à l'ensemble des autres modules logiciels (14j, 14k) du même sous-ensemble identifié comportant une réplication (Dj, Dk) de cette donnée numérique, - sur réception de ce message (M) par l'un quelconque des modules logiciels concernés, exécution (404, 406) de l'action identifiée sur ce module logiciel de manière à agir sur la réplication de la donnée numérique située sur ce module logiciel.
8. Procédé de synchronisation selon l'une quelconque des revendications 1 à 7, comportant en outre les étapes suivantes :
- lors de la synchronisation du module logiciel candidat (14i), celui-ci comportant une partie des données numériques, extraction (602) d'un état des réplications de cette partie des données numériques sur au moins un autre module logiciel (14j), et enregistrement (604) du module logiciel candidat (14i) en tant que récepteur potentiel d'au moins un message de synchronisation identifiant une action sur une réplication de ses données numériques située sur un autre module logiciel, - synchronisation (606, 608, 610, 612) des données numériques du module logiciel (14i) avec les données numériques de l'autre module logiciel (14j) et, pendant cette synchronisation, mise dans une file d'attente des messages de synchronisation éventuellement reçus,
- une fois la synchronisation terminée (614, 616), traitement de la file d'attente (618, 620).
9. Système de synchronisation d'un ensemble de modules logiciels (141 s 18i, 142, 143, 144, 145) d'un système informatique (10), comportant plusieurs serveurs (121 ; 122, 123, 124, 125) interconnectés en réseau (26, 30, 34), chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble (CA, CBI , C62, C63, C64, C65) de données dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble (14,, 14j) comporte une synchronisation des données communes qu'ils gèrent, caractérisé en ce qu'il comporte :
- des moyens d'identification d'au moins un sous-ensemble regroupant des modules logiciels de l'ensemble activés et synchronisés entre eux, et
- pour chaque module logiciel candidat (14,) suite à son démarrage ou redémarrage, activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble : - des moyens de recherche d'un autre module logiciel activé de l'ensemble,
• si un autre module logiciel activé est trouvé et s'il appartient à un sous-ensemble identifié, des moyens de synchronisation du module logiciel candidat avec au moins l'un (14,) des modules logiciels de ce sous-ensemble identifié, et
• des moyens d'intégration du module logiciel candidat (14,) dans le sous-ensemble identifié.
10. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes d'un procédé de synchronisation selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.
PCT/FR2009/052158 2008-11-10 2009-11-10 Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs WO2010052441A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2011535156A JP2012508412A (ja) 2008-11-10 2009-11-10 サーバクラスタに配信されるコンピュータシステムのソフトウェアモジュール集合の同期化方法および同期化システム
EP09768166A EP2353277A1 (fr) 2008-11-10 2009-11-10 Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs
US13/128,489 US20110218962A1 (en) 2008-11-10 2009-11-10 Method and system for synchronizing a set of software modules of a computing system distributed as a cluster of servers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0806252 2008-11-10
FR0806252A FR2938356B1 (fr) 2008-11-10 2008-11-10 Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs

Publications (1)

Publication Number Publication Date
WO2010052441A1 true WO2010052441A1 (fr) 2010-05-14

Family

ID=40897687

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/052158 WO2010052441A1 (fr) 2008-11-10 2009-11-10 Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs

Country Status (5)

Country Link
US (1) US20110218962A1 (fr)
EP (1) EP2353277A1 (fr)
JP (1) JP2012508412A (fr)
FR (1) FR2938356B1 (fr)
WO (1) WO2010052441A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9230084B2 (en) * 2012-10-23 2016-01-05 Verizon Patent And Licensing Inc. Method and system for enabling secure one-time password authentication
US9411868B2 (en) * 2013-08-23 2016-08-09 Morgan Stanley & Co. Llc Passive real-time order state replication and recovery

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995002294A1 (fr) * 1993-07-09 1995-01-19 Apple Computer, Inc. Systeme et procede de synchronisation distribuee
FR2851709A1 (fr) 2002-12-31 2004-08-27 Activia Networks Systeme, serveur et procede fournissant des ressources de synchronisation a un reseau de communications comprenant des serveurs de services
US20050080796A1 (en) * 2003-10-10 2005-04-14 International Business Machines Corporation Data synchronization between distributed computers
US20060242327A1 (en) * 1999-09-01 2006-10-26 Microsoft Corporation System and Method for Data Synchronization
US20070233900A1 (en) 1999-06-30 2007-10-04 Computer Sciences Corporation System and method for synchronizing copies of data in a computer system
US20080059952A1 (en) * 2006-08-29 2008-03-06 International Business Machines Corporation Method for Replicating and Synchronizing a Plurality of Physical Instances with a Logical Master
US7437601B1 (en) * 2005-03-08 2008-10-14 Network Appliance, Inc. Method and system for re-synchronizing an asynchronous mirror without data loss

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7203687B2 (en) * 2004-02-26 2007-04-10 International Business Machines Corporation Peer-to-peer replication member initialization and deactivation
US7543020B2 (en) * 2005-02-10 2009-06-02 Cisco Technology, Inc. Distributed client services based on execution of service attributes and data attributes by multiple nodes in resource groups
US8051170B2 (en) * 2005-02-10 2011-11-01 Cisco Technology, Inc. Distributed computing based on multiple nodes with determined capacity selectively joining resource groups having resource requirements
US7457835B2 (en) * 2005-03-08 2008-11-25 Cisco Technology, Inc. Movement of data in a distributed database system to a storage location closest to a center of activity for the data
US7805503B2 (en) * 2007-05-10 2010-09-28 Oracle International Corporation Capability requirements for group membership
FR2932289B1 (fr) * 2008-06-06 2012-08-03 Active Circle Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees.

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995002294A1 (fr) * 1993-07-09 1995-01-19 Apple Computer, Inc. Systeme et procede de synchronisation distribuee
US20070233900A1 (en) 1999-06-30 2007-10-04 Computer Sciences Corporation System and method for synchronizing copies of data in a computer system
US20060242327A1 (en) * 1999-09-01 2006-10-26 Microsoft Corporation System and Method for Data Synchronization
FR2851709A1 (fr) 2002-12-31 2004-08-27 Activia Networks Systeme, serveur et procede fournissant des ressources de synchronisation a un reseau de communications comprenant des serveurs de services
US20050080796A1 (en) * 2003-10-10 2005-04-14 International Business Machines Corporation Data synchronization between distributed computers
US7437601B1 (en) * 2005-03-08 2008-10-14 Network Appliance, Inc. Method and system for re-synchronizing an asynchronous mirror without data loss
US20080059952A1 (en) * 2006-08-29 2008-03-06 International Business Machines Corporation Method for Replicating and Synchronizing a Plurality of Physical Instances with a Logical Master

Also Published As

Publication number Publication date
JP2012508412A (ja) 2012-04-05
EP2353277A1 (fr) 2011-08-10
FR2938356A1 (fr) 2010-05-14
FR2938356B1 (fr) 2011-06-24
US20110218962A1 (en) 2011-09-08

Similar Documents

Publication Publication Date Title
US9436556B2 (en) Customizable storage system for virtual databases
EP1815359B1 (fr) Système et procédé de sauvegarde distribuée pérenne des données
TW497071B (en) Method and apparatus for managing clustered computer systems
EP2962242B1 (fr) Procede de detection d&#39;attaques de machines virtuelles
CN105723679A (zh) 用于数据流的客户端可配置安全选项
EP1866754A1 (fr) Systeme et procede de migration d&#39;un systeme d&#39;exploitation, des donnees d&#39;utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur
CN105765575A (zh) 数据流摄取和持久性技术
FR2843209A1 (fr) Procede de replication d&#39;une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe.
FR2773237A1 (fr) Systeme et procede pour modifier le mappage de partitions vers des unites logiques dans une memoire d&#39;ordinateur
JP2022500730A (ja) 分散型異種ストレージシステムにおけるデータ一貫性のリアルタイムチェックのための方法、デバイス、およびシステム
WO2009147357A1 (fr) Procede et systeme de synchronisation de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs, application au stockage de donnees
WO2010052441A1 (fr) Procede et systeme de synchronisation d&#39;un ensemble de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs
EP4026016A1 (fr) Migration d&#39;une chaîne de blocs de données
FR3051934A1 (fr) Procede d&#39;identification d&#39;au moins une fonction d&#39;un noyau d&#39;un systeme d&#39;exploitation
CH718446A2 (fr) Système et méthode pour la sauvegarde par agents distribués de machines virtuelles
WO2012172234A1 (fr) Procede, dispositif et programme d&#39;ordinateur pour la mise à jour logicielle de clusters optimisant la disponibilite de ces derniers
EP3144812A1 (fr) Architecture client/serveur pour l administration d&#39;un supercalculateur
WO2010052440A1 (fr) Procede et systeme de stockage virtualise d&#39;un ensemble de donnees numeriques
EP2734921B1 (fr) Procede, programme d&#39;ordinateur et dispositif d&#39;aide au deploiement de clusters
FR3039024A1 (fr) Systeme et procede automatique de deploiement des services sur un noeud reseau
FR2888651A1 (fr) Procede pour la prise en compte automatique et le stockage persistant de parametres de personnalisation a priori volatils
WO2019086786A1 (fr) Procédé de communication entre processus, programme d&#39;ordinateur et installation informatique correspondants
EP3123314B1 (fr) Procédé et dispositif de contrôle du changement de système d&#39;exploitation dans des noeuds de service d&#39;un calculateur haute performance
CH718447A2 (fr) Système et méthode pour la restauration de machines virtuelles par des agents distribués.
FR3100351A1 (fr) connexion à chaîne de blocs de données

Legal Events

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

Ref document number: 09768166

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011535156

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13128489

Country of ref document: US

Ref document number: 2009768166

Country of ref document: EP