Brevet FR2932289A1 — publié le 20091211

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 oeuvre 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 clu 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 � noeuds � 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 répliquées. Ceci pose des problèmes 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 oeuvre dans des serveurs de ressources. Il apparaît donc que certains éléments du réseau de communication, le serveur principal et les serveurs cle 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 les étapes suivantes : exécution, sur un premier module logiciel, d'une action agissant sur une donnée de description, transmission d'un message 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 quellconque 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. Il 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. 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 noeud comportant au moins un élément fils, soit une feuille de terminaison de l'arborescence, chaque noeud de l'arborescence est associé à une signature globale correspondant à la somme des signatures des données de description situées en aval de ce noeud 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 5 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 10 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 15 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 20 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 25 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. 30 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, suite à l'exécution de cette action sur le module logiciel émetteur du message de synchronisation, 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 le module logiciel récepteur du message de synchronisation, en réponse à la réception 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 25 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, 30 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 35 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 121, 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 oeuvre 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 oeuvre plus générale de l'invention. Le module logiciel et matériel 141 du serveur 121 est détaillé sur la figure 1. Il comporte une première couche logicielle 161 constituée d'un système d'exploitation du serveur 121. II comporte une deuxième couche logicielle 181 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 201 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 121. Enfin, il comporte une quatrième couche logicielle et matérielle 221, 241 d'entrepôts de données, comportant au moins un entrepôt de données sur disque dur 221 et/ou au moins un entrepôt de données sur bandes magnétiques 241. 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 141. Dans l'exemple illustré par la figure 1, les serveurs 121, 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 Intemet. 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) 141, 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 141, 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. II 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 CB1, contenant des données de description propres au module logiciel et matériel 141 telles que l'infrastructure locale et le fonctionnement local du serveur 121 et de ses périphériques de stockage, ou l'organisation en entrepôts du module logiciel et matériel 141. Ce catalogue est répliqué en trois exemplaires, dont un sur le module logiciel et matériel 141. Pour améliorer la sécurité et la robustesse du système informatique 10, le catalogue CB1 peut être répliqué dans plusieurs domaines différents. Ici, le système complet comportant deux domaines 28 et 32, le catalogue CB1 est par exemple sauvegardé sur les modules 141 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 CB2, CB3, CB4 et CB5. Par exemple, le catalogue CB2 est sauvegardé sur les modules 142 et 143 du domaine 28 et sur le module 144 du domaine 32 ; le catalogue CB3 est sauvegardé sur le module 143 du domaine 28 et sur les modules 144 et 145 du domaine 32 ; le catalogue CB4 est sauvegardé sur le module 144 du domaine 32 et sur les modules 141 et 143 du domaine 28 ; et le catalogue CB5 est sauvegardé sur le module 145 du domaine 32 et sur les modules 141 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 35 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 rnessage 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. 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 + Incr(A), où Incr(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 + Incr(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équentiellernent 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 141. 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 Incr(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 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 Incr(A) généré par le module logiciel et matériel 14;. Ensuite également, lors d'une étape 106, à réception du message de 35 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 noeuds 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épliications 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 + Incr(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 + Incr(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 Incr(A). Lors de cette même étape, le message MA est transmis notamment au module logiciel et matériels 14j 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 Incr(B). Lors de cette même étape, le message MB est transmis notamment au module logiciel et matériel 141 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 + Incr(A) + Incr(B). Enfin, lors d'une étape 210, à réception du message de synchronisation MA, 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 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. La valeur N" est égale à N' + 1, soit N + 2. Enfin, la valeur de S"' est égale à s" + Incr(A) = S + Incr(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 clans la gestion des données de description. Il peut alors être envisagé de mettre en oeuvre 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. II 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 14j 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 rnodule logiciel et matériel 14j 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 14j é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 14j 35 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 noeuds (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 noeud 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 noeud 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 noeud de l'arbre a une même signature globale dans les deux réplications du catalogue, cela signifie que ce noeud et l'ensemble des données � filles � de ce noeud 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 noeud. Lors de cette même étape, le module logiciel et matériel 14j 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 141. 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 141 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 14j 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, conforrné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 catallogue 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 14i 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 14J 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 141 pour la mise à jour de l'ensemble de ses catalogues de données de description. II 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. REVENDICATIONS1. Procédé de synchronisation de modules logiciels (141, 181, 142, 143, 144, 145) d'un système informatique (10) distribué en 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, CB1, CB2, 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 les étapes suivantes : exécution (100), sur un premier module logiciel (14), d'une action (A) agissant sur une donnée de description (Di), transmission (102) d'un message de synchronisation (M) identifiant l'action (A) à l'ensemble des autres modules logiciels (14, 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 rnodule 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,, 14) 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, CB1, CB2, CB3, CB4, CB5) de données de description comportant une arborescence dans laquelle chaque donnéede description est soit un noeud comportant au moins un élément fils, soit une feuille de terminaison de l'arborescence, chaque noeud 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 noeud dans l'arborescence. 6. Procédé de synchronisation dle 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 (14j), 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 (14j) 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 deprogramme 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 (141, 181, 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, CB1, CB2, 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, sur chaque module logiciel 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, suite à l'exécution (100) de cette action sur le module logiciel émetteur (14;) du message de synchronisation, 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 (Dj, Dk) de la donnée de description située sur le module logiciel récepteur (14;, 14k) du message de synchronisation, en réponse à la réception (104, 106) du message de synchronisation.25