WO2009147357A1 - Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees - Google Patents

Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees Download PDF

Info

Publication number
WO2009147357A1
WO2009147357A1 PCT/FR2009/050955 FR2009050955W WO2009147357A1 WO 2009147357 A1 WO2009147357 A1 WO 2009147357A1 FR 2009050955 W FR2009050955 W FR 2009050955W WO 2009147357 A1 WO2009147357 A1 WO 2009147357A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
description data
data
computer system
action
Prior art date
Application number
PCT/FR2009/050955
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 JP2011512177A priority Critical patent/JP2011522337A/ja
Priority to EP09757733A priority patent/EP2300944A1/fr
Priority to US12/996,285 priority patent/US20110088013A1/en
Publication of WO2009147357A1 publication Critical patent/WO2009147357A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload

Definitions

  • the present invention relates to a method and a system for synchronizing software modules of a computer system distributed in a plurality of servers interconnected in a network. It also relates to the application of such a method to a data storage service and 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 managing a set of data describing a service, at least part of the description data. being replicated to a plurality of software modules.
  • 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 storage devices with hard disk or magnetic tape.
  • the description data includes, for example, data describing users of the storage service, data describing the infrastructure and operation of the computer system for providing the service, and data describing the data. stored 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, in particular for the synchronization of the replicated description data.
  • the description data and their possible modifications can be defined so as to optimize the synchronization by making as much as possible the commutative modifications: multiplication of the number of distinct fields in the same description data, modifications defined incrementally to avoid conflicts, definition of "a priori" rules for managing potential conflicts, etc.
  • 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. It may thus be desirable to provide a method for synchronizing software modules of a computer system distributed in a plurality of interconnected networked servers that makes it possible to overcome the aforementioned problems and constraints.
  • the subject of the invention is therefore a method for synchronizing software modules of a computer system distributed in a plurality of interconnected networked servers, each software module executing on a server of the computer system for managing a set of description data. of a service, in which at least part of the description data is replicated to a plurality of software modules, characterized in that it comprises, at each execution, on any of the software modules said first software module, d an action acting on a description datum managed by this first software module, the following steps:
  • the execution of the action on the first software module causing the update of a version index and a signature of the data item.
  • the execution of the action on any of the software modules comprising a replication of this description data causes the same updating of the version and signature index of the replication of the description data concerned. It is thus possible to verify at any time that the replications of description data are actually synchronized.
  • the update of the signature of the relevant description data is designed to be incremental and commutative. This makes it possible to manage possible cross-share conflicts. Indeed, even if, as has been specified above, the actions themselves can be commutative or their conflicts managed by rules a priori, it is advantageous that the signatures are also defined so as to make their updates commutative.
  • the signature increment is the result of random data generation.
  • the description data set comprising a tree in which each description datum is either a node comprising at least one child element or a terminator leaf of the tree, each node of the tree is associated with a global signature corresponding to the sum of the signatures of the description data located downstream of this node in the tree.
  • a method of synchronizing software modules of a computer system distributed in a server cluster may further include the following steps:
  • the invention also relates to an application of a software module synchronization method as described above, to a computer system distributed in a server cluster for providing a distributed data storage service between connected storage devices. each to a server of the computer system.
  • the description data comprises at least one of the elements of the set consisting of data describing the general infrastructure and the general operation of the computer system, data describing users of the data storage service and their rights. access, data describing the structure or mode of storage and replication of stored data, and data describing the local infrastructure and the local operation of a server or software module of the computer system.
  • 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 program code instructions for performing the steps of a method of synchronizing software modules of a distributed computer system into a plurality of interconnected networked servers as previously defined when said program is run on a computer.
  • another subject of the invention is a system for synchronizing software modules of a computer system, comprising a plurality of interconnected networked servers, each software module executing on a server of the computer system for the management of a set of data files.
  • description of a service in which at least part of the description data is replicated to a plurality of software modules, characterized in that it comprises, on each software module managing description data: a synchronization message, identifying an action acting on a description datum, to all the other software modules of the computer system comprising a replication of this description datum, whenever such an action is executed on this software module, and means for executing an action acting on a description datum and identified in a synchronization message, so as to act on the replication of the description datum located on this software module, in response to the reception by this module synchronization message software.
  • 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 according to one embodiment of the invention
  • FIG. 4 illustrates a particular case of execution of the method of FIG. 3, in which a possible conflict of cross-share executions is solved
  • FIG. 5 partially illustrates the successive steps of a synchronization method according to another embodiment of the invention.
  • 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; 14 2 , 14 3 , 14 4 and 14 5 for managing 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.
  • FIG. 1 For the sake of simplicity also, there is shown a software and hardware module per server, so that the modules and their respective servers can be confused in the following description, without having to be confused in a more general implementation of the invention.
  • the software and hardware module 14i of the server 12i is detailed in FIG. 1. It comprises a first software layer 16i consisting of an operating system the server ⁇ 2 ⁇ . It comprises a second software layer 18i for managing the description data of the data storage service provided by the computer system 10. It comprises a third software and hardware layer 20 1 fulfilling at least two functions: a first storage function, a internal hard disk of the server 12 1; storage service description data and a second cache function, also on this hard disk, of data stored on storage devices of the server 12 ⁇ Finally, it comprises a fourth software and hardware layer 22i, 24i of warehouses of data, including at least one data warehouse on hard disk 22 ! and / or at least one tape data warehouse 24i.
  • 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 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 since they 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. These data from description by the software layer 18, of any of the software and hardware modules 14, manages the storage service of the computer system 10.
  • the description data are for example grouped into several sets structured according to their nature and possibly linked together.
  • a structured set which will be called "catalog” in the following description, may be in the form of a directory tree containing themselves other directories and / or description data files.
  • the representation of the description data according to a tree of directories and files has the advantage of being simple and therefore economical to design and manage. In addition, this representation is often sufficient for the service in question. It is also possible for more complex applications to represent and manage the description data in relational databases.
  • a catalog of description data may be global, that is to say relate to description data useful to the entire computer system 10, or local, that is to say relate to description data specific to one or more software module (s) and hardware (s) 14 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 catalogs of description data between the five software and hardware modules 14 1; 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 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 areas, the structure or the storage mode and the replication of stored data.
  • catalogs are local, such as the catalog C B i, containing description data specific to the software module and hardware M 1 such as the local infrastructure and the local operation of the server 12 ! and its storage devices, or the warehouse organization of the software and hardware module ⁇ ⁇ .
  • This catalog is replicated in triplicate, including one on the software and hardware module 14i.
  • 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 ⁇ ⁇ and 14 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 B5 is saved on the module 14 5 of the domain 32 and on the modules 14i and 14 2 of the domain 28.
  • 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).
  • the 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 operated on it since its inception.
  • the description data and / or modification actions that can be performed on these data are advantageously defined so that the actions are as much as possible commutative, that is to say that two actions give a same result regardless of the order of their execution. For example, multiplying the number of modifiable fields in the same description data statistically limits the number of potential conflicts since the probability that two actions are executed simultaneously on the same data field is reduced. For example also, by defining counter type fields and possible incremental changes on these fields, the corresponding actions are made commutative in case of conflict.
  • 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:
  • 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 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.
  • 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 the software and hardware modules 14, and 14 k also comprising a replication of the description data D, via the transmission network 26, 30, 34.
  • 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 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 the update of 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 upon receipt of the synchronization message M, performs the action A on the replication Dk 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 '.
  • 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 the 'between them, the software and hardware module 14 J; in a step 202.
  • 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,.
  • This 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 and hardware module 14, including the replication Dj.
  • a synchronization message MB is generated by the software and hardware module 14,.
  • This message MB comprises 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).
  • the message MB is transmitted in particular to the software and hardware module 14, including the replication Di.
  • a step 208 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 208.
  • the value val" results from the action A on val", that is to say, the combination of the actions A and B on the value val of the description data D if we assume, as detailed above, that the commutativity of the actions A and B is acquired by definition or by management
  • the synchronization method previously described makes it possible to keep each software and hardware module up-to-date for the management of the service description data provided by the computer system 10, as long as each software and hardware module is able to receive and process synchronization messages which addressed to him.
  • the method described does not make it possible to make up for any delay taken by compared to other software and hardware modules in the management of description data.
  • FIG. 5 Such an embodiment is partially illustrated in FIG. 5. It consists in providing specific additional steps for updating a software and hardware module when it is put into operation within the computer system 10. Of course, these steps These additional services are not intended to run when this software and hardware module is the first to be put in working order in the computer system. This embodiment applies when the software and hardware module is active in the computer system while other software and hardware modules with replications of its catalogs are already in working order and synchronized by the method described with reference to the FIGS. 3 and 4.
  • a software and hardware module 14 selects a software and hardware module 14, for the synchronization of one of its description data catalogs. 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 concerning 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 receiving any new synchronization message concerning this catalog.
  • step 300 also, during a step 304, 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.
  • This search for differences between two replications of the same catalog can be facilitated when the description data catalog is structured according to a tree in which the description data is either nodes (when they have a direct or indirect relationship with at least one description datum "girl"), or leaves (when they are located at the end of the tree in this hierarchical representation).
  • each node of the tree can be associated with a global signature that represents the sum of the signatures of its data "girls", that is to say the description data located downstream of this node 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.
  • 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. Whenever it processes an update of description data, it transmits a synchronization message, in accordance with the method described with reference to FIG. 3, to the software and hardware modules comprising a replication of this description data with the exception software and hardware module 14 ,.
  • the frozen representation of the contents of the catalog is deactivated on the software and hardware module side 14, during a step 314 and the software and hardware module 14, is informed in a step 316.
  • Steps 300 to 318 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)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Multi Processors (AREA)
  • Hardware Redundancy (AREA)

Abstract

Dans ce procédé de synchronisation de modules logiciels (14i, 14j, 14k) 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 de description d'un service, au moins une partie des données de description (Di, Dj, Dk) est répliquée sur une pluralité de modules logiciels. Le procédé comporte les étapes suivantes : - exécution (100), sur un premier module logiciel (14i), d'une action (A) agissant sur une donnée de description (Di), - transmission (102) d'un message de synchronisation (M) identifiant l'action à l'ensemble des autres modules logiciels (14j, 14k) du système informatique comportant une réplication (Dj, Dk) de cette donnée de description, - sur réception de ce message (M) par l'un quelconque des modules logiciels concernés, exécution (104, 106) de l'action identifiée sur ce module logiciel de manière à agir sur la réplication de la donnée de description située sur ce module logiciel.

Description

PROCEDE ET SYSTEME DE SYNCHRONISATION DE MODULES LOGICIELS D'UN SYSTEME INFORMATIQUE DISTRIBUE EN GRAPPE DE SERVEURS, APPLICATION AU STOCKAGE DE DONNEES
La présente invention concerne un procédé et un système de synchronisation de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau. Elle concerne également l'application d'un tel procédé à un service de stockage de données et 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 de description d'un service, au moins une partie des données de description étant répliquée sur une pluralité de modules logiciels. 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 de description 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 de description répliquées. En outre, dans ce type d'application, les données de description et leurs modifications possibles peuvent être définies de manière à optimiser la synchronisation en rendant autant que possible les modifications commutatives : multiplication du nombre de champs distincts dans une même donnée de description, modifications définies de façon incrémentale pour éviter les conflits, définition de règles « a priori » de gestion de conflits potentiels, etc. Au vu de ce qui précède, même si la synchronisation des données de description n'est pas aussi complexe dans le cas envisagé que dans une application d'édition collaborative de données, où plusieurs intervenants interviennent sur des données dont les modifications ne sont généralement pas commutatives, des problèmes apparaissent lorsque le serveur ou 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. II 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 des problèmes et contraintes précités. L'invention a donc pour objet un procédé de synchronisation 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 de description d'un service, dans lequel au moins une partie des données de description est répliquée sur une pluralité de modules logiciels, caractérisé en ce qu'il comporte, à chaque exécution, sur l'un quelconque des modules logiciels dit premier module logiciel, d'une action agissant sur une donnée de description gérée par ce premier module logiciel, les étapes suivantes :
- transmission par le premier module logiciel d'un message de synchronisation identifiant l'action à l'ensemble des autres modules logiciels du système informatique comportant une réplication de cette donnée de description,
- 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 de description située sur ce module logiciel.
Ainsi, l'exécution d'une action sur un premier module logiciel du système informatique 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 gérant une réplication de la donnée de description 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 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 de description concernée par l'action. Aucun module logiciel ne joue donc de rôle privilégié ou particulier du point de vue de la gestion des données de description du service, 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, l'exécution de l'action sur le premier module logiciel provoquant la mise à jour d'un indice de version et d'une signature de la donnée de description concernée, l'exécution de l'action sur l'un quelconque des modules logiciels comportant une réplication de cette donnée de description provoque la même mise à jour d'indice de version et de signature de la réplication de la donnée de description concernée. II est ainsi possible de vérifier à tout moment que les réplications de données de description sont effectivement synchronisées.
De façon optionnelle, la mise à jour de la signature de la donnée de description concernée est conçue de manière à être incrémentale et commutative. Cela permet de gérer d'éventuels conflits d'actions croisées. En effet, même si, comme cela a été précisé précédemment, les actions elles-mêmes peuvent être commutatives ou leurs conflits gérés par des règles a priori, il est avantageux que les signatures soient définies également de manière à rendre leurs mises à jour commutatives.
De façon optionnelle, l'incrément de signature est le résultat d'une génération aléatoire de donnée.
De façon optionnelle, l'ensemble de données de description comportant une arborescence dans laquelle chaque donnée de description est soit un nœud comportant au moins un élément fils, soit une feuille de terminaison de l'arborescence, chaque nœud de l'arborescence est associé à une signature globale correspondant à la somme des signatures des données de description situées en aval de ce nœud dans l'arborescence. Cela permet notamment de parcourir plus rapidement l'ensemble des données de description pour vérifier la synchronisation de deux réplications de cet ensemble.
De façon optionnelle, un procédé de synchronisation de modules logiciels d'un système informatique distribué en grappe de serveurs selon l'invention peut en outre comporter les étapes suivantes :
- lors de la mise en fonctionnement d'un module logiciel comportant une partie des données de description, extraction d'un état des réplications de cette partie des données de description sur au moins un autre module logiciel, et enregistrement du module logiciel en tant que récepteur potentiel d'au moins un message de synchronisation identifiant une action sur une réplication de ses données de description située sur un autre module logiciel,
- synchronisation des données de description du module logiciel avec les données de description 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 une application d'un procédé de synchronisation de modules logiciels tel que décrit précédemment, à un système informatique distribué en grappe de serveurs pour la fourniture d'un service de stockage de données distribué entre des périphériques de stockage reliés chacun à un serveur du système informatique.
De façon optionnelle, les données de description comportent au moins l'un des éléments de l'ensemble constitué de données décrivant l'infrastructure générale et le fonctionnement général du système informatique, de données décrivant des utilisateurs du service de stockage de données et leurs droits d'accès, de données décrivant la structure ou le mode de stockage et la réplication de données stockées, et de données décrivant l'infrastructure locale et le fonctionnement local d'un serveur ou module logiciel du système informatique.
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 de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau tel que défini précédemment lorsque ledit programme est exécuté sur un ordinateur.
Enfin l'invention a également pour objet un système de synchronisation 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 de description d'un service, dans lequel au moins une partie des données de description est répliquée sur une pluralité de modules logiciels, caractérisé en ce qu'il comporte, sur chaque module logiciel gérant des données de description : - des moyens d'émission d'un message de synchronisation, identifiant une action agissant sur une donnée de description, vers l'ensemble des autres modules logiciels du système informatique comportant une réplication de cette donnée de description, chaque fois qu'une telle action est exécutée sur ce module logiciel, et - des moyens d'exécution d'une action agissant sur une donnée de description et identifiée dans un message de synchronisation, de manière à agir sur la réplication de la donnée de description située sur ce module logiciel, en réponse à la réception par ce module logiciel du message de synchronisation.
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 selon un mode de réalisation de l'invention,
- la figure 4 illustre un cas particulier d'exécution du procédé de la figure 3, dans lequel un éventuel conflit d'exécutions d'actions croisées est résolu,
- la figure 5 illustre partiellement les étapes successives d'un procédé de synchronisation selon un autre mode de réalisation de l'invention. 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 ; 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 14i du serveur 12i 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 ^ 2^. 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 2O1 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 12^ Enfin, il comporte une quatrième couche logicielle et matérielle 22i, 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 14i.
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 et conformément à l'invention, 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 ; 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 M1 telles que l'infrastructure locale et le fonctionnement local du serveur 12! et de ses périphériques de stockage, ou l'organisation en entrepôts du module logiciel et matériel λΛλ. Ce catalogue est répliqué en trois exemplaires, dont un sur le module logiciel et matériel 14i. 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 λΛλ et 142 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 CB5 est sauvegardé sur le module 145 du domaine 32 et sur les modules 14i et 142 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 est assurée.
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 de description, vers l'ensemble des autres modules logiciels du système informatique comportant une réplication de cette donnée de description, suite à l'exécution de cette action sur ce module logiciel, et
- des moyens d'exécution d'une action agissant sur une donnée de description et identifiée dans un message de synchronisation, de manière à agir sur la réplication de la donnée de description située sur ce module logiciel, en réponse à la réception du message de synchronisation. Un procédé de synchronisation des catalogues de données de description particulièrement avantageux va maintenant être détaillé, conformément à un mode de réalisation de l'invention.
Tout d'abord, il convient de préciser qu'une synchronisation d'un catalogue 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 du système informatique. 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.
Comme indiqué précédemment, les données de description et/ou les actions de modification que l'on peut exécuter sur ces données sont avantageusement définies de sorte que les actions soient autant que possible commutatives, c'est-à- dire que deux actions donnent un même résultat quel que soit l'ordre de leur exécution. Par exemple, en multipliant le nombre de champs modifiables dans une même donnée de description on limite statistiquement le nombre de conflits potentiels puisque la probabilité pour que deux actions soient exécutées simultanément sur un même champ de donnée est réduite. Par exemple également, en définissant des champs de type compteur et des modifications incrémentales possibles sur ces champs, on rend les actions correspondantes commutatives en cas de conflit. Enfin, lorsqu'un champ de donnée de description et les actions correspondantes ne peuvent pas être définis pour que ces dernières soient commutatives (paramètre de type « couleur » et action de type « changement de couleur », par exemple), il est aussi possible de définir des règles « a priori » de gestion de conflits (priorités, critères de décision prédéfinis, etc.), de générer des alarmes en cas de conflit pour une gestion « manuelle » du conflit ou de bloquer les accès multiples pour toute action sur ces champs de données. En tout état de cause, on notera que ce problème de gestion des conflits potentiels entre actions exécutées quasi-simultanément et portant sur une même donnée de description est différent du problème de synchronisation en tant que tel résolu par l'invention, même s'il se pose dans un même contexte et s'il permet d'optimiser cette synchronisation.
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 3, lors d'une première étape 100, 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 102 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 aux modules logiciels et matériels 14, et 14k comportant également une réplication de la donnée de description D, via le réseau de transmission 26, 30, 34.
Ensuite, lors d'une étape 104, à réception du message de synchronisation M, 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 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 106, à 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 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 3 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 4.
En effet, lors d'une première étape 200, 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 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 202. 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 200 et 202, 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 204 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 206 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 208, à 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 210, à 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 208. 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 si l'on suppose, comme détaillé précédemment, que la commutativité des actions A et B est acquise par définition ou par gestion des conflits. 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 208 et 210, les réplications Di et Dj sont correctement synchronisées, leurs versions identiques attestant de l'identité de leurs valeurs.
Le procédé de synchronisation précédemment décrit permet de maintenir chaque module logiciel et matériel à jour pour la gestion des données de description du service fourni par le système informatique 10, tant que chaque module logiciel et matériel est apte à recevoir et traiter des messages de synchronisation qui lui sont adressés. En revanche, lors de la mise en fonctionnement d'un module logiciel et matériel, par exemple par l'ajout d'un nouveau serveur ou suite à une interruption locale de service, le procédé décrit ne permet pas de rattraper un éventuel retard pris par rapport aux autres modules logiciels et matériels dans la gestion des données de description.
Il peut alors être envisagé de mettre en œuvre un mode de réalisation de l'invention résolvant aussi ce problème supplémentaire. Un tel mode de réalisation est illustré partiellement sur la figure 5. Il consiste à prévoir des étapes supplémentaires spécifiques de mise à jour d'un module logiciel et matériel lors de sa mise en fonctionnement au sein du système informatique 10. Bien sûr, ces étapes supplémentaires n'ont pas vocation à s'exécuter lorsque ce module logiciel et matériel est le premier à être mis en état de fonctionnement dans le système informatique. Ce mode de réalisation s'applique lorsque le module logiciel et matériel entre en activité dans le système informatique alors que d'autres modules logiciels et matériels comportant des réplications de ses catalogues sont déjà en état de fonctionnement et synchronisés grâce au procédé décrit en référence aux figures 3 et 4. Selon ce mode de réalisation, lors d'une première étape 300 au cours de laquelle un module logiciel et matériel 14, entre en activité dans le système informatique 10, celui-ci sélectionne un module logiciel et matériel 14, pour la synchronisation de l'un de ses catalogues de données de description. 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 300, 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 302, 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 300 également, lors d'une étape 304, 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 302, lors d'une étape 306, 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 308, 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 310, 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 312, 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 3, aux modules logiciels et matériels 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 314 et le module logiciel et matériel 14, en est informé lors d'une étape 316.
Ainsi, lors de dernières étapes respectives 318 et 320, 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 306 à 316, de manière à résorbe 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 3 et 4 lorsque la situation se présente. Les étapes 300 à 318 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'un système informatique distribué en plusieurs serveurs pour la fourniture d'un service, de sorte que chaque serveur du système, et plus précisément chaque module logiciel et matériel agissant sur un serveur pour la fourniture de ce service, puisse jouer un rôle similaire aux autres et pallier une défaillance.

Claims

REVENDICATIONS
1. Procédé de synchronisation de modules logiciels (141 ; 1813 142, 143, 144, 145) d'un système informatique (10) distribué en plusieurs serveurs (1213 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, CB3, CB4, CB5) de données de description d'un service, dans lequel au moins une partie des données de description est répliquée sur une pluralité de modules logiciels, caractérisé en ce qu'il comporte, à chaque exécution, sur l'un quelconque des modules logiciels dit premier module logiciel (14,), d'une action (A) agissant sur une donnée de description (Di) gérée par ce premier module logiciel, les étapes suivantes :
- transmission (102) par le premier module logiciel (14,) d'un message de synchronisation (M) identifiant l'action (A) à l'ensemble des autres modules logiciels (14J; 14k) du système informatique comportant une réplication (Dj, Dk) de cette donnée de description,
- sur réception de ce message (M) par l'un quelconque des modules logiciels concernés, exécution (104, 106) de l'action identifiée sur ce module logiciel de manière à agir sur la réplication de la donnée de description située sur ce module logiciel.
2. Procédé de synchronisation de modules logiciels selon la revendication 1 , dans lequel l'exécution (100) de l'action (A) sur le premier module logiciel (14,) provoquant la mise à jour d'un indice de version (N) et d'une signature (S) de la donnée de description concernée (Di), l'exécution (104, 106) de l'action (A) sur l'un quelconque des modules logiciels (14,, 14j) comportant une réplication (Dj, Dk) de cette donnée de description provoque la même mise à jour d'indice de version (N) et de signature (S) de la réplication de la donnée de description concernée.
3. Procédé de synchronisation de modules logiciels selon la revendication 2, dans lequel la mise à jour de la signature (S) de la donnée de description concernée est conçue de manière à être incrémentale et commutative.
4. Procédé de synchronisation de modules logiciels selon la revendication 3, dans lequel l'incrément de signature est le résultat d'une génération aléatoire de donnée.
5. Procédé de synchronisation de modules logiciels selon l'une quelconque des revendications 2 à 4, dans lequel, l'ensemble (CA, CBi , C62, C63, C64, C65) de données de description comportant une arborescence dans laquelle chaque donnée de description est soit un nœud comportant au moins un élément fils, soit une feuille de terminaison de l'arborescence, chaque nœud de l'arborescence est associé à une signature globale correspondant à la somme des signatures (S) des données de description situées en aval de ce nœud dans l'arborescence.
6. Procédé de synchronisation de modules logiciels selon l'une quelconque des revendications 1 à 5, comprenant en outre les étapes suivantes :
- lors de la mise en fonctionnement (300) d'un module logiciel (14,) comportant une partie des données de description, extraction (302) d'un état des réplications de cette partie des données de description sur au moins un autre module logiciel (14,), et enregistrement (304) du module logiciel (14,) en tant que récepteur potentiel d'au moins un message de synchronisation identifiant une action sur une réplication de ses données de description située sur un autre module logiciel, - synchronisation (306, 308, 310, 312) des données de description du module logiciel (14,) avec les données de description de l'autre module logiciel (14,) et, pendant cette synchronisation, mise dans une file d'attente des messages de synchronisation éventuellement reçus,
- une fois la synchronisation terminée (314, 316), traitement de la file d'attente (318, 320).
7. Application d'un procédé de synchronisation de modules logiciels selon l'une quelconque des revendications 1 à 6, à un système informatique (10) distribué en plusieurs serveurs (121 ; 122, 123, 124, 125) interconnectés en réseau (26, 30, 34) pour la fourniture d'un service de stockage de données distribué entre des périphériques de stockage reliés chacun à un serveur du système informatique.
8. Application d'un procédé de synchronisation de modules logiciels selon la revendication 7, dans laquelle les données de description comportent au moins l'un des éléments de l'ensemble constitué de données décrivant l'infrastructure générale et le fonctionnement général du système informatique, de données décrivant des utilisateurs du service de stockage de données et leurs droits d'accès, de données décrivant la structure ou le mode de stockage et la réplication de données stockées, et de données décrivant l'infrastructure locale et le fonctionnement local d'un serveur ou module logiciel du système informatique.
9. 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 de modules logiciels d'un système informatique (10) distribué en plusieurs serveurs (121 ; 122, 123, 124, 125) interconnectés en réseau selon l'une quelconque des revendications 1 à 6 lorsque ledit programme est exécuté sur un ordinateur.
10. Système de synchronisation de modules logiciels (1415 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, CB4, CB5) de données de description d'un service, dans lequel au moins une partie des données de description est répliquée sur une pluralité de modules logiciels, caractérisé en ce qu'il comporte, sur chaque module logiciel (14,) gérant des données de description :
- des moyens d'émission d'un message de synchronisation (M), identifiant une action (A) agissant sur une donnée de description (Di), vers l'ensemble des autres modules logiciels (14,, 14k) du système informatique comportant une réplication (Dj, Dk) de cette donnée de description, chaque fois qu'une telle action (A) est exécutée sur ce module logiciel (14,), et - des moyens d'exécution d'une action (A) agissant sur une donnée de description et identifiée dans un message de synchronisation (M), de manière à agir sur la réplication (Di) de la donnée de description située sur ce module logiciel (14,), en réponse à la réception (104, 106) par ce module logiciel (14,) du message de synchronisation.
PCT/FR2009/050955 2008-06-06 2009-05-22 Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees WO2009147357A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2011512177A JP2011522337A (ja) 2008-06-06 2009-05-22 サーバクラスタに配信されるコンピュータシステムのソフトウェアモジュールの同期化方法、同期化システムおよびデータストレージへの適用
EP09757733A EP2300944A1 (fr) 2008-06-06 2009-05-22 Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees
US12/996,285 US20110088013A1 (en) 2008-06-06 2009-05-22 Method and system for synchronizing software modules of a computer system distributed as a cluster of servers, application to data storage

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR08/03140 2008-06-06
FR0803140A FR2932289B1 (fr) 2008-06-06 2008-06-06 Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees.

Publications (1)

Publication Number Publication Date
WO2009147357A1 true WO2009147357A1 (fr) 2009-12-10

Family

ID=39816591

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/050955 WO2009147357A1 (fr) 2008-06-06 2009-05-22 Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees

Country Status (5)

Country Link
US (1) US20110088013A1 (fr)
EP (1) EP2300944A1 (fr)
JP (1) JP2011522337A (fr)
FR (1) FR2932289B1 (fr)
WO (1) WO2009147357A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108512877A (zh) * 2017-02-28 2018-09-07 腾讯科技（北京）有限公司 一种服务器集群中分享数据的方法和装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2938356B1 (fr) * 2008-11-10 2011-06-24 Active Circle Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs
US20180293915A1 (en) * 2015-10-15 2018-10-11 The Board Of Regents Of The Nevada System Of Higher Education On Behalf Of The University Of Ne Synchronizing software modules
US11720347B1 (en) 2019-06-12 2023-08-08 Express Scripts Strategic Development, Inc. Systems and methods for providing stable deployments to mainframe environments
US11086757B1 (en) * 2019-06-12 2021-08-10 Express Scripts Strategic Development, Inc. Systems and methods for providing stable deployments to mainframe environments

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060184589A1 (en) * 2000-06-21 2006-08-17 Microsoft Corporation Linked Value Replication
US20080005195A1 (en) * 2006-06-30 2008-01-03 Microsoft Corporation Versioning synchronization for mass p2p file sharing
WO2008008448A2 (fr) * 2006-07-12 2008-01-17 Eastman Kodak Company Gestion globale d'actifs

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6678882B1 (en) * 1999-06-30 2004-01-13 Qwest Communications International Inc. Collaborative model for software systems with synchronization submodel with merge feature, automatic conflict resolution and isolation of potential changes for reuse
US6457170B1 (en) * 1999-08-13 2002-09-24 Intrinsity, Inc. Software system build method and apparatus that supports multiple users in a software development environment
US6385768B1 (en) * 1999-09-30 2002-05-07 Unisys Corp. System and method for incorporating changes as a part of a software release
US6854069B2 (en) * 2000-05-02 2005-02-08 Sun Microsystems Inc. Method and system for achieving high availability in a networked computer system
US7752214B2 (en) * 2000-09-01 2010-07-06 Op40, Inc. Extended environment data structure for distributed digital assets over a multi-tier computer network
US6938045B2 (en) * 2002-01-18 2005-08-30 Seiko Epson Corporation Image server synchronization
US7096228B2 (en) * 2002-03-27 2006-08-22 Microsoft Corporation Method and system for managing data records on a computer network
US7483923B2 (en) * 2003-08-21 2009-01-27 Microsoft Corporation Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
US7290015B1 (en) * 2003-10-02 2007-10-30 Progress Software Corporation High availability via data services
FR2870022B1 (fr) * 2004-05-07 2007-02-02 Canon Kk Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
US20060195340A1 (en) * 2004-12-15 2006-08-31 Critical Connection Inc. System and method for restoring health data in a database
US20060155781A1 (en) * 2005-01-10 2006-07-13 Microsoft Corporation Systems and methods for structuring distributed fault-tolerant systems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060184589A1 (en) * 2000-06-21 2006-08-17 Microsoft Corporation Linked Value Replication
US20080005195A1 (en) * 2006-06-30 2008-01-03 Microsoft Corporation Versioning synchronization for mass p2p file sharing
WO2008008448A2 (fr) * 2006-07-12 2008-01-17 Eastman Kodak Company Gestion globale d'actifs

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
JAGADISH H V ET AL: "Scalable versioning in distributed databases with commuting updates", DATA ENGINEERING, 1997. PROCEEDINGS. 13TH INTERNATIONAL CONFERENCE ON BIRMINGHAM, UK 7-11 APRIL 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 7 April 1997 (1997-04-07), pages 520 - 531, XP010218573, ISBN: 978-0-8186-7807-3 *
LEE Y-W ET AL: "OPERATION-BASED UPDATE PROPAGATION IN A MOBILE FILE SYSTEM", PROCEEDINGS OF THE USENIX ANNUAL TECHNICAL CONFERENCE, 1 January 1999 (1999-01-01), pages 43 - 56, XP009068288 *
MARTINS V. ET AL: "Survey of data replication in P2P systems", February 2007 (2007-02-01), XP002501325, Retrieved from the Internet <URL:http://hal.archives-ouvertes.fr/docs/00/12/93/73/PDF/Survey_of_data_replication_in_P2P_systems.PDF> [retrieved on 20081017] *
RAMSEY N ET AL: "An algebraic approach to file synchronization", SOFTWARE ENGINEERING NOTES, ACM, NEW YORK, NY, US, vol. 26, no. 5, 1 September 2001 (2001-09-01), pages 175 - 185, XP002295139, ISSN: 0163-5948 *
SAITO Y ET AL: "Replication: Optimistic Approaches", INTERNET CITATION, XP007901701, Retrieved from the Internet <URL:http://www.hpl.hp.com/techreports/2002/HPL-2002-33.pdf> [retrieved on 20070209] *
SAITO Y ET AL: "TAMING AGGRESSIVE REPLICATION IN THE PANGAEA WIDE-AREA FILE SYSTEM", PROCEEDINGS OF THE USENIX SYMPOSIUM ON OPERATING SYSTEMS DESIGN AND IMPLEMENTATION, 9 December 2002 (2002-12-09), pages 15 - 30, XP009068269 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108512877A (zh) * 2017-02-28 2018-09-07 腾讯科技（北京）有限公司 一种服务器集群中分享数据的方法和装置

Also Published As

Publication number Publication date
US20110088013A1 (en) 2011-04-14
FR2932289A1 (fr) 2009-12-11
EP2300944A1 (fr) 2011-03-30
JP2011522337A (ja) 2011-07-28
FR2932289B1 (fr) 2012-08-03

Similar Documents

Publication Publication Date Title
JP7044879B2 (ja) クライアント同期サービスのためのローカルツリーの更新
EP1815359B1 (fr) Système et procédé de sauvegarde distribuée pérenne des données
US8548957B2 (en) Method and system for recovering missing information at a computing device using a distributed virtual file system
US20170220614A1 (en) Consistent ring namespaces facilitating data storage and organization in network infrastructures
FR2931970A1 (fr) Procede de generation de requetes de manipulation d&#39;une base de donnees d&#39;initialisation et d&#39;administration d&#39;une grappe de serveurs , support de donnees et grappe de serveurs correspondants
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
US8140480B1 (en) Off-host cataloging of backup information
EP4026016A1 (fr) Migration d&#39;une chaîne de blocs de données
WO2006016085A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
EP2556447B1 (fr) Gestion de partage de fichiers informatiques entre au moins deux dispositifs
WO2010052441A1 (fr) Procede et systeme de synchronisation d&#39;un ensemble de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs
EP1912408B1 (fr) Procédé de gestion d&#39;une base de données partitionnée dans un réseau de communication
EP3903210A1 (fr) Reseau de communication securisee et tracee
WO2015087019A1 (fr) Procédé de synchronisation de données entre un ensemble de terminaux
FR3073061B1 (fr) Procede de communication entre processus, programme d’ordinateur et installation informatique correspondants
EP3080706B1 (fr) Procédé de sauvegarde de données stockées sur un terminal
EP2353076A1 (fr) Procede et systeme de stockage virtualise d&#39;un ensemble de donnees numeriques
WO2015067892A1 (fr) Procédé de protection de métadonnées
Meye Dependability in cloud storage
FR3100350A1 (fr) migration d’une chaîne de blocs de données
FR3100351A1 (fr) connexion à chaîne de blocs de données
Salmon Putting home data management into perspective
WO2014140506A1 (fr) Procede de synchronisation de structures de donnees arborescentes, systeme et programme d&#39;ordinateur associes
WO2009047397A2 (fr) Système informatique amélioré comprenant plusieurs noeuds en réseau

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011512177

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 12996285

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2009757733

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE