Brevet FR2944893A1 — publié le 20101029

SEANODES5.FRD 1 Système de stockage comprenant plusieurs noeuds en réseau avec gestion de synchronisation d'écriture L'invention concerne un système de stockage comprenant plusieurs noeuds en réseau 5 avec gestion de synchronisation d'écriture. Les réseaux modernes comportent des stations utilisateurs qui sont reliées à un ou plusieurs serveurs et peuvent partager des applications et/ou des espaces de stockage de manière locale ou distante. Dans le cadre d'applications partagées faisant usage d'une quantité importante de données ou dans le cadre du partage d'une quantité importante de données, il est fréquent de faire appel à des systèmes de stockage spécialisés, tels que les Storage Area Network (ou SAN). 15 L'utilisation de ces systèmes perfectionnés présente certains désavantages, comme les coûts associés, les limitations de performance et d'extensibilité, et la lourdeur générale de l'installation qui leur correspond. 20 Par ailleurs, avec les réseaux modernes, l'utilisation de ces systèmes perfectionnés représente une sous utilisation du matériel déjà présent dans le réseau. Enfin, les systèmes qui ont été proposés qui utilisent le matériel déjà présent dans le réseau ont des performances insatisfaisantes, notamment en termes de gestion des 25 pannes ainsi que dans la quantité d'espace allouée à la redondance des données. L'invention vient améliorer la situation. A cet effet, l'invention propose un outil informatique de stockage de données dans un 30 réseau de stations, chaque station comprenant une ou plusieurs unités de stockage dont certaines au moins comportent des adresses de stockage propres à recevoir des données de stockage. 10 Cet outil est implanté sur chaque station et comprend d'une part un virtualiseur associant des adresses virtuelles et des adresses de stockage, et d'autre part un gestionnaire d'accès aux adresses de stockage de cette station, agencé pour communiquer avec les gestionnaires d'accès d'autres stations pour exécuter une requête par accès à un stockage volatile et/ou à un stockage persistent des unités de stockage de ces stations. Chaque gestionnaire d'accès est agencé pour synchroniser sélectivement le stockage volatile et le stockage persistent de certaines au moins des unités de stockage dont il gère l'accès, en fonction d'un état d'écriture de certaines des adresses virtuelles associées aux adresses de stockage de ces unités de stockage. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : - la figure 1 montre une vue fonctionnelle générale d'un système informatique selon l'invention, - la figure 2 montre un exemple d'implémentation logique du système de la figure 1, - la figure 3 montre un exemple de composition d'un élément de la figure 2, - la figure 4 montre un exemple de composition d'un élément de la figure 3, - la figure 5 montre un exemple d'une variante de l'élément de la figure 2, - la figure 6 montre un procédé d'accès à un fichier dans le système de la figure 1, - la figure 7 montre un exemple de mise en oeuvre d'une opération de la figure 6, - la figure 8 montre un exemple de mise en oeuvre d'une autre opération de la figure 6, et - la figure 9 montre un exemple de mise en oeuvre d'une opération de la figure 7. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas30 d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits. La figure 1 représente un schéma général d'un système informatique selon l'invention. Dans ce système, un environnement d'application 2 a accès à un gestionnaire de système de fichiers 4. Une couche de virtualisation 6 établit la correspondance entre le gestionnaire de système de fichiers 4 et des serveurs de stockage 8. La figure 2 représente une implémentation logique du système de la figure 1. Dans cette implémentation, un ensemble de stations 10, également appelées ici noeuds sont interconnectées en un réseau dont elles constituent les ressources physiques et applicatives. Dans l'exemple ici décrit, le réseau est constitué de 5 stations, notées Ni avec i variant entre 1 et 5. L'environnement d'application 2 est réalisé en une couche applicative répartie 12 sur les N1, N2 et N3, en une couche applicative 14 sur le N4 et une couche applicative 16 sur le N5. On notera que le terme poste ou station utilisé ici doit être interprété de manière générale, et comme désignant des éléments informatiques du réseau sur lesquels tournent des applications ou des programmes de serveur, ou les deux. Le gestionnaire de système de fichiers 4 est réalisé en un système de fichiers réparti 18, et deux systèmes de fichiers non répartis 20 et 22. Le système 18 est réparti sur les N1, N2 et N3 et définit l'ensemble des fichiers accessibles depuis la couche applicative répartie 12. Les systèmes de fichiers 20 et 22 définissent respectivement l'ensemble des fichiers accessibles depuis les couches applicatives 14 et 16. Les fichiers désignés par les systèmes de fichiers 18, 20 et 22 sont stockés dans un espace de stockage virtuel 24 qui est réparti sur l'ensemble des Ni avec i variant entre 1 et 5. L'espace de stockage virtuel 24 est ici réparti en un espace logique partagé 26, et deux espaces logiques privés 28 et 30. L'espace logique partagé 26 correspond à l'espace accessible depuis la couche applicative répartie 12 au moyen du système de fichiers réparti 18, et les espaces logiques privés 28 et 30 à l'espace accessible depuis les couches applicatives 14 et 16 au moyen des systèmes de fichiers 20 et 22. L'espace logique 26 est réparti sur les N1, N2 et N3, l'espace logique privé 28 sur les N3 10 et N4, et l'espace logique privé 30 sur le N5. Ainsi, une application de la couche 12 (respectivement 14, 16) "voit" les données stockées dans l'espace logique 26 (respectivement 28, 30) au moyen du système de fichiers 18 (respectivement 20, 22), bien que celles-ci ne soient pas forcément 15 physiquement présentes sur l'un des disques de stockage de la station 10 qui utilise cette application. Par ailleurs, les espaces 26, 28 et 30 sont purement logiques, c'est-à-dire qu'ils ne représentent pas directement des espaces de stockage physiques. Les espaces logiques 20 sont cartographiés au moyen d'adresses virtuelles qui sont référencées ou contenues dans les systèmes de fichiers 18, 20 et 22. Pour accéder aux données de ces fichiers, il est nécessaire de faire appel à un module de correspondance. Le module de correspondance contient une table de correspondance 25 entre les adresses virtuelles des données dans les espaces logiques et des adresses physiques qui désignent les espaces de stockage physiques dans lesquels ces données sont réellement stockées. Plusieurs réalisations sont possibles pour le module de correspondance. La répartition 30 des espaces de stockage physiques décrite ici est un exemple destiné à montrer la portée très générale de l'invention. Comme on peut le voir dans l'exemple présenté, chaque station est utilisée à la fois pour la couche applicative et pour la couche de stockage. Cette multifonctionnalité permet d'utiliser l'espace libre sur l'ensemble des stations du réseau, plutôt que laisser cet espace inoccupé. Dans le cadre de l'invention, il serait cependant possible de spécialiser certaines des stations, et de créer un noeud dédié au stockage ou un noeud dédié à des applications. Cela signifie que, dans le cadre de l'invention, toute station peut jouer un rôle de noeud 10 applicatif, un rôle de noeud stockant, ou encore ces deux rôles à la fois. L'ensemble des ressources applicatives, de stockage et de système de fichiers peuvent être intégrées localement sur chaque station, ou bien réparties sur les stations du réseau. 15 C'est par exemple le cas des stations N1, N2 et N3, dont les ressources sont intégralement réparties, tant au niveau applicatif qu'au niveau du système de fichiers et du stockage. La figure 3 représente un exemple d'architecture d'une station 10 de la figure 2. La 20 station représentée dans cet exemple peut représenter l'une des stations N1 à N5. La station Nx présente individuellement une structure semblable à celle de la structure globale représentée sur la figure 1. Elle comporte ainsi une couche applicative 32, un système de fichiers 34, une couche de virtualisation 36 et un espace de stockage 38 sous 25 la forme d'une mémoire locale à accès direct. La couche de virtualisation 36 comporte un moteur 40 et une table de correspondance 42. L'accès direct à l'espace de stockage 38 est géré par un gestionnaire d'accès 44. 30 L'exemple décrit ici représente un mode de réalisation perfectionné de l'invention, dans lequel toutes les ressources, tant applicatives que de stockage, sont réparties sur le réseau.5 6 Cela signifie par exemple que le système de fichiers 34 n'est pas intégralement présent sur cette station, mais réparti sur plusieurs d'entre elles, et que l'accès à celui-ci implique la communication avec d'autres noeuds du réseau qui contiennent les données recherchées. Il en est de même pour la couche de virtualisation 36 et le gestionnaire d'accès 44. La répartition de ces éléments est gérée au moyen d'un module d'administration 46. Pour la suite de la description, il importe peu que les ressources considérées soient réparties ou pas. 10 Le module d'administration 46 est principalement utilisé lors de la création et de la mise à jour des espaces logiques. Lors de la création ou de la modification d'un espace logique, le module d'administration 46 appelle la couche de virtualisation 36 pour créer la table de correspondance entre chaque adresse virtuelle de l'espace logique et une 15 adresse physique sur un noeud de stockage donné. Ensuite, les correspondances entre un fichier accessible par ce système de fichiers et les adresses virtuelles des données qui composent ce fichier sont réalisées au niveau du système de fichiers qui exploite cet espace logique, les données "physiques" étant 20 stockées aux adresses physiques associées dans la table de correspondance aux adresses virtuelles, conformément à la cartographie établie lors de la création de l'espace logique. Cela signifie que, dès la création d'un espace logique par le module d'administration, les correspondances entre les adresses virtuelles et les adresses physiques sont établies. Les 25 adresses virtuelles apparaissent ainsi "vides" au système de fichier accédant à l'espace logique, bien que les adresses physiques qui leur correspondent soient déjà "réservées" par le biais de la table de correspondance. C'est lorsque le lien entre les données des fichiers de cet espace et les adresses virtuelles 30 de ces données est établi que les adresses physiques sont remplies. Dans le mode de réalisation décrit ici, la table de correspondance 42 est un tableau qui contient des informations permettant de retrouver les correspondances. Lorsqu'une application fait appel à un espace mémoire donné, le moteur 40 interagit avec la table 42 pour établir l'adresse physique correspondante. On comprendra qu'ici, la table 42 n'est pas une � look-up table � classique, mais plutôt une table qui stocke un nombre d'informations restreint mais qui permet au moteur 40 de recouvrer les adresses physiques. 10 En effet, comme cela sera explicité plus bas, les adresses sur les différentes unités de stockage sont associées par bloc, ce qui permet de retrouver une adresse rapidement, sans avoir à stocker toutes les correspondances possibles. La figure 6 représente un procédé mis en oeuvre par le système pour accéder à un 15 fichier. L'accès à un fichier par une application de la couche applicative d'un noeud donné est initialisé par une requête d'accès fichier 50. La requête d'accès fichier 50 comporte : - un identifiant du fichier concerné pour le système de fichiers et une adresse dans ce 20 fichier, - la taille de la requête, c'est-à-dire le nombre de bits à accéder à la suite de l'adresse du fichier visé, - le type de requête, à savoir la lecture ou l'écriture, et - un identifiant de tampon pour stocker les données lues ou obtenir les données à écrire. 25 Dans une opération 52, le système de fichiers détermine une ou plusieurs adresses virtuelles pour les données de ce fichier, et génère une ou plusieurs requêtes d'accès virtuel sur la base de la requête 50 et de ces adresses virtuelles. 30 Les requêtes d'accès virtuel comportent chacune : - l'adresse virtuelle visée,5 8 - la taille de la requête, c'est-à-dire le nombre de bits à accéder à la suite de l'adresse virtuelle visée, - le type de requête, qui est identique à celui de la requête 50, et - un identifiant de tampon pour stocker les données lues ou obtenir les données à écrire. Si l'on se rapporte au système décrit sur la figure 2, l'opération 52 consiste à déterminer l'espace logique (ou volume logique) et la ou les adresses virtuelles sur cet espace désignées par la requête 50, et à produire une ou plusieurs requêtes d'accès virtuel. 10 Le terme d'accès virtuel signifie que l'on accède à des adresses de la couche virtuelle. Cependant, comme il ressort clairement de ce qui précède, cet accès n'est pas virtuel en lui-même et implique un accès à des données physiques correspondantes. Il existe une différence de niveau entre les requêtes d'accès fichiers et les requêtes 15 d'accès virtuel. En effet, une requête d'accès fichier va viser le contenu d'une quantité importante d'adresses virtuelles, afin de permettre de reconstituer le contenu d'un fichier, alors qu'une requête virtuelle vise le contenu d'un bloc de données associé à cette adresse. 20 La ou les requêtes d'accès virtuel obtenues sont alors transmises à la couche de virtualisation, qui détermine la ou les adresses physiques et les espaces de stockage correspondants dans une opération 54. Pour déterminer les adresses physiques, la couche de virtualisation opère en utilisant le 25 moteur 40 et la table de correspondance 42. Dans le cadre d'une requête d'accès en lecture, les données du fichier existent déjà, et le moteur 40 appelle la table de correspondance 42 avec la ou les adresses virtuelles de ce fichier pour déterminer par correspondance la ou les adresses physiques des données du 30 fichier. 10 Dans le cadre d'une requête d'accès en écriture, les données du fichier n'existent pas forcément de manière préalable. Néanmoins, comme on l'a vu plus haut, les correspondances entre adresses virtuelles et adresses physiques sont figées, et le moteur 40 opère donc de la même manière que dans le cadre d'une requête en lecture pour déterminer la ou les adresses physiques des données. Dans tous les cas, une fois que le moteur 40 a déterminé les adresses physiques, il génère dans une opération 56 des requêtes d'accès physique qu'il transmet au gestionnaire d'accès 44. Dans l'opération 56, les requêtes d'accès physique sont générées sur la base de la requête 50 et de la ou des adresses physiques déterminées à l'opération 54. Ces requêtes comportent : 15 - l'adresse physique visée, - la taille de la requête, c'est-à-dire le nombre de bits à accéder à la suite de l'adresse physique visée par la requête, - le type d'action visée, à savoir la lecture ou l'écriture de données, la resynchronisation ou la vérification de parité, 20 - un identifiant de tampon pour stocker les données lues ou obtenir les données à écrire, et - des données complémentaires nécessaires à l'exécution de la requête. L'adresse physique et la taille de la requête sont obtenues directement de l'opération 54, 25 et le type de la requête est hérité du type de la requête d'accès virtuel concernée. Dans le cadre de l'invention, les données sont stockées selon un schéma de parité. Cela signifie qu'à chaque adresse virtuelle correspond une unique adresse physique. Cependant, les différents espaces logiques sont répartis sur toutes les unités de 30 stockage 38, c'est-à-dire que les adresses de stockage d'une unité de stockage donnée vont recevoir des données correspondant à des adresses virtuelles de presque tous les espaces logiques. En outre, les adresses virtuelles et les adresses physiques correspondantes sont regroupées par blocs d'adresses, et une adresse physique supplémentaire est affectée à chaque bloc pour stocker des données de parité. Les données de parité sont calculées en réalisant une opération � ou exclusif � avec toutes les données du bloc. Ainsi, si un disque contenant une des adresses physiques du bloc tombe en panne, il reste possible d'accéder aux données perdues, à partir des données des autres adresses 10 du bloc et des données de parité correspondantes. Cela signifie néanmoins que la gestion des accès concurrents à des données d'un bloc donné et le maintien de la cohérence entre les données d'un bloc et ses données de parité sont des objectifs cruciaux. Les données complémentaires de la requête d'accès physique servent à fournir au gestionnaire d'accès 44 les informations nécessaires à la réalisation de ces objectifs. Ainsi, ces données peuvent comprendre : 20 - le volume logique et/ou l'adresse virtuelle qui correspond à l'adresse physique visée, - l'ensemble des adresses physiques du bloc auquel appartient l'adresse physique visée, - un identifiant d'une unité de stockage tombée en panne ou désynchronisée, et - un indicateur de modèle de requête à mettre en oeuvre. 25 Une boucle est alors lancée, dans laquelle une condition d'arrêt 58 est atteinte lorsqu'une requête d'accès physique a été émise au gestionnaire d'accès 44 pour toutes les adresses physiques obtenues à l'opération 52. En fait, chaque requête d'accès physique est placée dans une file d'attente de requête du 30 gestionnaire d'accès 44 pour exécution dans une opération 60. Le gestionnaire d'accès 44 peut optionnellement comporter plusieurs files d'attente, par exemple une file d'attente par noeud avec lequel il interagit. 15 Dans cette boucle, toutes les requêtes d'accès physique de l'opération 56 sont représentées comme exécutées successivement pour des raisons de simplicité. Cependant, l'exécution peut également être réalisée en parallèle, et pas seulement en série. Pour l'exécution d'une requête d'accès physique donnée, le gestionnaire d'accès 44 va déterminer une séquence d'appels conditionnés à des éléments qui lui sont propres et/ou à d'autres éléments de gestionnaires d'accès 44 contrôlant les autres unités de stockage. Comme cela apparaît maintenant, le système de l'invention fonctionne selon un paradigme client/serveur, c'est-à-dire que les requêtes sont émises par des clients, et que ces requêtes sont exécutées par des serveurs, qui envoient au client un accusé d'exécution de ces requêtes. Ainsi, les gestionnaires d'accès 44 communiquent entre eux soit en tant que client, soit en tant que serveur, pour exécuter les requêtes d'accès physiques en correspondance des requêtes d'accès virtuel. 20 Cette relation client/serveur peut être implicite, comme cela est le cas dans le mode de réalisation de la figure 3, c'est-à-dire que le gestionnaire d'accès 44 peut jouer les deux rôles, ou être explicite, comme cela est représenté sur la figure 5, où le gestionnaire d'accès 44 est composé par deux modules 44a et 44b qui jouent respectivement le rôle de client et de serveur. 25 La première implémentation (gestionnaire d'accès �pluridisciplinaire �) est intéressante car elle permet d'accorder au gestionnaire d'accès des fonctions plus avancées, par exemple une génération de requête plus poussée pour la gestion de parité. 30 La deuxième implémentation (un � client � et un � serveur � bien distincts) est intéressante car elle est plus simple à mettre en oeuvre et car elle permet de spécialiser chaque module pour ses tâches. 15 Par ailleurs, bien que l'exemple décrit ici prévoie que les données sont stockées avec un schéma de parité, d'autres schémas pourraient être utilisés, comme l'utilisation de parités multiples, de réplication simple ou multiple, ou d'autres schémas assurant la redondance dans un stockage réparti et la tolérance aux pannes, ainsi que les schémas à hachurage sans redondance. La figure 4 représente la composition d'une unité de stockage 38. Comme on peut le voir sur cette figure, chaque unité de mémoire comprend un espace de stockage persistent 38a et un espace de stockage volatile 38b. Cette composition permet d'obtenir des gains de performance conséquents. En effet, l'espace de stockage volatile 38b peut être réalisé avec de la mémoire dite rapide du type RAM ou autre mémoire à faible latence, tandis que l'espace de stockage persistent 38a peut être réalisé avec de la mémoire dite de stockage du type disque dur, bande ou autre. Ainsi, l'unité de mémoire 38 peut écrire des données reçues dans l'espace de stockage volatile 38b, et indiquer au gestionnaire d'accès 44 que la requête a été effectuée plus rapidement que si l'écriture avait été réalisée directement sur l'espace de stockage persistent 38a. Ensuite, il reste à synchroniser l'espace de stockage volatile 38b et l'espace de stockage persistent 38a, pour pérenniser ces écritures. Dans les systèmes classiques, c'est l'unité de stockage 38 elle-même qui régule les cycles de synchronisation de l'espace de stockage volatile 38b et de l'espace de stockage persistent 38a. Cette structure pour les unités de stockage 38 est donc très avantageuse en termes de performances. Cependant, elle présente le désavantage que le gestionnaire d'accès 44 ne sait pas quel est l'état de synchronisation de chacune des unités de stockage 38 qu'il gère. Cela est pénalisant car il existe de nombreux cas dans lesquels il est critique que la synchronisation ait été effectuée, notamment afin de préserver la cohérence des données entre les différentes unités de stockage dans le cadre du stockage distribué décrit ici. Pour pallier à cela, des types de requêtes d'accès distincts ont été définis, et portent le nom de �barrière �. Les barrières sont un exemple d'opération avec synchronisation forcée. Les barrières sont émises au niveau applicatif, et comprennent deux opérations. La première opération vise à assurer que toutes unités de stockage concernées par la deuxième opération sont bien synchronisées avant l'exécution de celle-ci. L'exécution d'une barrière implique donc une première requête de synchronisation, suivie d'une deuxième requête qui est la requête que l'on souhaite effectivement réaliser. En général, les requêtes de synchronisation sont suivies d'une requête d'écriture, mais il peut également arriver qu'elles soient suivies d'une requête de lecture. La transformation de la requête de barrière de type � logique � en deux requêtes de type �physiques� est réalisée par le virtualiseur 36. Ainsi, lorsque celui-ci reçoit en entrée une requête de type barrière, il stocke dans sa file d'attente les deux requêtes comme décrit ci-dessus. Classiquement, les requêtes de synchronisation qui sont envoyées aux unités de stockage ne sont pas distinctives, et synchronisent entièrement les espaces de stockage volatile 38b et permanent 38a des unités de stockage qui les reçoivent. Dans le cadre du stockage distribué décrit ici, cela peut être une source de pertes de performance conséquente. En effet, chaque unité de stockage 38 reçoit des données qui correspondent à des adresses virtuelles appartenant à des volumes logiques distincts. Ainsi, les différents accès qui vont avoir pour résultat de solliciter l'espace de stockage volatile 38b ont de grandes chances de concerner des adresses virtuelles de volumes logiques distincts. Lorsque les opérations de synchronisation forcée portent sur l'ensemble de l'espace de stockage volatile, il est donc très courant que cette opération porte sur de nombreuses adresses de stockage pour lesquelles cette synchronisation n'est pas nécessaire. Il est même courant que cette synchronisation ait pour résultat l'écriture dans l'espace de stockage persistant 38a de données qui correspondent exclusivement à des adresses virtuelles qui appartiennent à un volume logique pour lequel cette synchronisation n'est pas nécessaire. Dans ce cas, la synchronisation est non seulement inutile, mais également génératrice de 15 baisse de performance, car cette synchronisation fait perdre un temps précieux avant le traitement de la requête de la deuxième opération de la barrière. Comme on va le voir avec les figures 7 et 8, l'invention propose de réaliser le gestionnaire d'accès 44 de sorte que ces problèmes sont évités, soit en exécutant les 20 requêtes de synchronisation très rapidement, soit en les évitant dans certains cas. Du côté serveur, l'opération d'exécution de la requête physique 60 peut être mise en oeuvre par le gestionnaire d'accès 44 conformément au procédé représenté sur la figure 7. La requête qui doit être transmise par le gestionnaire d'accès 44 client est reçue par le gestionnaire d'accès 44 serveur dans une opération 70, et dans une opération 72, le type de cette requête est vérifié pour voir s'il correspond à une requête de synchronisation. 30 On notera incidemment que c'est forcément le cas pour la première requête d'une requête de type barrière. 25 Comme on l'a mentionné plus haut, il est possible que le cache de l'unité de stockage 38 visée comprenne effectivement des données, mais que ces données soient associées à des adresses virtuelles qui n'appartiennent pas à l'espace logique sur lequel la requête en cours est exécutée. Si la requête n'est pas de type synchronisation, alors elle est envoyée et exécutée par l'unité de stockage 38 dans une opération 74. A réception de l'accusé d'exécution de l'opération 74, une table d'écriture est mise à 10 jour dans une opération 76. Cette table et cette opération seront décrites plus avant plus bas. Ensuite, l'accusé d'exécution de cette requête peut être renvoyé dans une opération 78, ce qui déclenche l'envoi d'un accusé d'exécution au gestionnaire d'accès 44 client qui a 15 envoyé cette requête. Si la requête est une requête de synchronisation, alors dans une opération 80, une fonction WriTbl_StO qui prend la requête de l'opération 70 comme argument détermine s'il est possible d'éviter cette synchronisation. Afin de décrire la fonction WriTbl_St() et l'opération 76 ainsi que la table d'écriture suggérée, il convient de déterminer quel type d'informations permettent de prendre cette décision. 25 Comme on l'a vu plus haut, il est possible d'éviter une synchronisation d'une unité de stockage 38 lorsque les données de son espace de stockage volatile 38b comprennent des données qui sont associées à un volume logique distinct de celui de la requête de l'opération 70. 30 Dès lors, afin d'éviter d'avoir à synchroniser toutes les données de l'espace de stockage volatile 38b, le gestionnaire d'accès 44 est agencé pour maintenir la table d'écriture mentionnée plus haut. 20 Cette table d'écriture peut être mise en oeuvre de plusieurs manières, et elle est maintenue à jour par l'opération 76 et sa pendante, l'opération 84 non encore décrite. D'une manière générale, la table d'écriture va représenter une sorte de mémoire à court terme des opérations d'écriture qui ont récemment été faites sur les unités de stockage 38 gérée par le gestionnaire d'accès 44. Ainsi, chaque entrée de la table d'écriture associe d'une part une plage d'adresses virtuelles, et d'autre part une plage d'adresses de stockage qui lui correspond sur les unités de stockage qui sont gérées par le gestionnaire d'accès 44. On notera qu'il y aura autant d'entrées que de couples plages d'adresses de stockage-plage d'adresses virtuelles. Dans l'exemple décrit ici, la table d'écriture est une table à double index, c'est-à-dire que chaque entrée est désignée par deux indices distincts. Ainsi, le premier indice concerne la plage d'adresses de stockage, et le deuxième indice concerne la plage d'adresses virtuelles. Pour atteindre une entrée de la table d'écriture, il est donc nécessaire de disposer à la fois d'une adresse de stockage et de l'adresse virtuelle associée. Cela est prévu comme décrit plus haut avec la figure 6. Dans chaque entrée, la valeur `l' (un) indique qu'une écriture a été réalisée depuis la dernière opération de synchronisation pour cette plage d'adresses virtuelles, et pour la plage d'adresses de stockage correspondante, tandis que la valeur `0' (zéro) indique le contraire. Ainsi, considérons une requête de synchronisation pour une adresse de stockage donnée et une adresse virtuelle associée. Alors, si l'entrée de la table d'écriture pour la plage d'adresses de stockage à laquelle appartient l'adresse de stockage donnée et pour la plage d'adresses virtuelles à laquelle appartient l'adresse virtuelle associée contient la valeur `0', cela signifie qu'il n'y a pas lieu de faire cette synchronisation. Dans ce cas, l'opération 80 se poursuit comme précédemment avec l'opération 78. On voit donc que dans ce cas, la requête de synchronisation est réduite à sa plus simple expression, c'est-à-dire que l'accusé d'exécution est immédiatement envoyé, ce qui économise un temps de traitement considérable qui aurait correspondu au temps nécessaire à la synchronisation (superflue) de l'espace de stockage volatile 38b. Dans le cas contraire, l'opération 80 est suivie par une synchronisation dans une opération 82. La synchronisation de l'opération 82 peut varier en fonction de la portée des plages d'adresses virtuelles et des plages d'adresses de stockage considérés pour la table d'écriture. En faisant varier le nombre d'entrées de cette table, on définit la granularité de l'analyse de besoin de synchronisation, mais avec un coût de stockage et de traitement en conséquence. Une mise en oeuvre simple et efficace est de prévoir une entrée pour chaque volume logique ayant une adresse de stockage associée sur les unités de stockage gérées par le gestionnaire d'accès 44. 25 Ainsi, à une entrée correspond une plage d'adresses virtuelles composée du volume logique en entier, et une plage d'adresses de stockage qui correspond à une unité de stockage 38 entière. Dans ce cas, à chaque fois qu'une écriture est réalisée pour un volume logique donné 30 sur une unité de stockage donnée, la prochaine requête de synchronisation portant sur une adresse virtuelle de ce volume logique sera forcément exécutée.20 Ce mode de réalisation est avantageux car il est très simple et léger à mettre en oeuvre, tout en offrant un gain de performances important. Une mise en oeuvre un peu plus évoluée consisterait à augmenter le nombre d'entrées de 5 la table d'écriture, par exemple en créant plusieurs entrées pour chaque volume logique associé à une unité de stockage donnée. En effet, pour réaliser le stockage, il est possible de regrouper les adresses de stockage sur les unités de stockage 38 en plage de taille fixe, par exemple par plage de 1 Go, de 10 sorte que ces adresses de stockage restent associées à des adresses virtuelles d'un seul et même volume logique. Dès lors, si l'on prévoit une entrée pour chacune de ces plages d'adresses de stockage, la synchronisation après une écriture n'aura lieu que si cette synchronisation vise une 15 adresse virtuelle pour le volume logique pour lequel cette écriture a été réalisée, et seulement pour les adresses de stockages regroupées. Dans ce cas, on voit qu'il devient intéressant de remplacer les requêtes Synchronize_Cache, qui provoquent la synchronisation de l'espace de stockage volatile 20 et de la mémoire persistante, par Synchronize_Cache(LBA, Count) qui permettent de synchroniser des plages d'adresses uniquement au lieu de l'ensemble de l'espace de stockage volatile 38b. Une fois la synchronisation effectuée, l'opération 84, qui est identique à l'opération 76 25 vient mettre à jour la table d'écriture. La fonction Upd_WriTblO, qui prend la requête de l'opération 70 comme argument, est la fonction qui va permettre de maintenir la table d'écriture. 30 Cette fonction met en oeuvre les principes suivants : après une requête de synchronisation, toutes les entrées de la table d'écriture qui ont été synchronisées avec l'espace de stockage persistent sont remises à `0' (zéro). Cela signifie que toutes les entrées sont remises à `0' (zéro) après une requête Synchronize_Cache, et seulement celles concernées par les adresses visées après une requête Synchronize_Cache(LBA, Count) ; après une requête d'écriture, toutes les entrées de la table d'écriture qui ont vu une opération d'écriture dans l'espace de stockage volatile sont mises à `1' (un) si elles étaient à `0' (zéro), et maintenues à `1' (un) dans le cas contraire ; et - après une requête de lecture, aucune modification n'est faite. Ensuite, ce procédé se termine avec l'opération 78 comme précédemment. Avec la figure 8, on a représenté un procédé similaire à celui de la figure 7, mais qui est cette fois mis en oeuvre du côté du gestionnaire d'accès 44 qui agit comme client, c'est-à-dire celui qui émet la requête d'accès. 15 Ce procédé diffère de celui représenté sur la figure 7 en ce qu'il permet d'éviter l'émission de requêtes de synchronisation dans certains cas. En effet, comme il est mis en oeuvre par le gestionnaire d'accès 44 client, c'est-à-dire avant que la requête de synchronisation soit transmise au gestionnaire d'accès 44 20 serveur qui gère l'accès aux unités de stockage 38 concernées par cette requête, il est possible d'éviter la transmission de cette requête. Cela assure des gains encore plus importants car le coût réseau associé à l'envoi de la requête et le retour de son accusé sont économisés par rapport au procédé de la figure 7. Ainsi les opérations 90 à 104 correspondent aux opérations 70 à 84, à cela prêt qu'elles sont réalisées par le gestionnaire d'accès 44 client, par exemple juste avant l'envoi de la requête reçue à l'opération 70. 30 Les seules différences sont que les opérations 94 et 96 et 102 et 104 sont exécutées dans un ordre inversé par rapport à leurs équivalentes 74 et 76 et 82 et 84. 25 Cela est dû au fait que le procédé décrit avec la figure 7 est situé côté serveur, et qu'il est préférable de mettre à jour la table d'écriture une fois que les opérations ont effectivement été réalisées, c'est-à-dire à complétion, alors que le procédé décrit avec la figure 8 est situé côté client, ce qui rend préférable de mettre à jour la table d'écriture dès l'envoi de la requête, c'est-à-dire à réception. Il serait néanmoins possible d'exécuter le procédé de la figure 7 à réception, et celui de la figure 8 à complétion. En outre, les opérations 74 et 82 sont des requêtes d'exécution, c'est-à-dire qu'elles déclenchent directement une exécution par l'unité de stockage 38 concernée, alors que les opérations 96 et 104 sont des opérations d'envoi de requête au gestionnaire d'accès 44 serveur. Comme on l'a vu, les opérations 94 et 102 portent sur une table d'écriture dont les valeurs reflètent l'état d'écriture des plages d'adresses de stockage et des plages d'adresses virtuelles. Cette table d'écriture est bien sûre distincte de celle décrite avec la figure 7. Les tables d'écritures des figures 7 et 8 peuvent toutes deux être stockées dans une mémoire persistante ou volatile. Dans la pratique, comme elles représentent une mémoire à court terme des opérations d'écritures qui ont été récemment réalisées, il est préféré de les stocker dans la mémoire volatile associée au module d'administration 46. La figure 9 représente un traitement qui est mis en oeuvre par le noyau du système d'exploitation pour gérer les différents types de protocoles physiques des unités de stockage 38. Ce traitement est mis en oeuvre directement après l'opération 74. En effet, bien que le mode de réalisation décrit ici soit principalement prévu pour être mis en oeuvre avec des ressources communiquant selon le protocole SCSI, il est possible que les unités de stockage 38 fonctionnent selon un autre protocole, par exemple du type SATA ou PATA, plus généralement ATA. Dans une première opération 110, le système d'exploitation reçoit et adapte une requête d'accès physique Req en fonction de l'unité de stockage 38 sur laquelle elle porte. Dans ce cas, il est nécessaire que les requêtes, originellement SCSI, soient � traduites � pour être interprétées correctement par les unités de stockage. Pour cela, dans une opération 112, le système d'exploitation teste si l'unité de stockage 38 cible met en oeuvre le protocole SCSI, au moyen d'une fonction TgtSCSIQ. La fonction TgtSCSI() prend la requête Req comme argument, et renvoie une valeur qui indique si l'unité de stockage que vise la requête Req met en oeuvre le protocole SCSI. Cette information peut être présente dans la requête Req comme information complémentaire, ou le système d'exploitation peut comprendre une table qui indique les protocoles mis en oeuvre par les unités de stockage. D'autres implémentations restent possibles. Si l'unité de stockage 38 met en oeuvre le protocole SCSI, alors la requête Req lui est transmise dans une opération 114. La requête Req est considérée comme exécutée lorsque le gestionnaire d'accès 44 reçoit un accusé de l'unité de stockage 38 concernée dans une opération 116. Ensuite, le gestionnaire d'accès 44 peut lui-même envoyer un accusé d'exécution au gestionnaire d'accès 44 qui l'a sollicité pour cette requête, et ainsi de suite jusqu'à ce que la couche applicative reçoive l'accusé qui indique que toutes les requêtes d'accès physique associées à la requête d'accès virtuel ont été exécutées. Pour interpréter la requête Req, une fonction Adapt() est appelée avec la requête Req comme argument dans une opération 118, et retourne une requête Regl. La fonction Adapt() ici est basée sur les correspondances suivantes. Dans l'exemple décrit ici, cette distinction porte principalement sur les requêtes SCSI suivantes :30 - Synchronize_Cache, qui provoque la synchronisation de l'espace de stockage volatile et de la mémoire persistente ; - WriteFUA, qui impose une écriture sur l'espace de stockage mémoire persistent avant de renvoyer l'accusé d'exécution ; et - Read FUA, qui impose une écriture sur l'espace de stockage mémoire persistent de données lues à partir de l'espace de stockage volatile avant de renvoyer l'accusé d'exécution. Dans le protocole SATA, la requête Synchronize_Cache a pour équivalent la requête 10 Flush_Cache, et les requêtes Write_FUA (respectivement Read_FUA) doivent être traduites par deux requêtes successives Write (respectivement Read) et Flush_Cache. Ainsi, lorsque le gestionnaire d'accès 44 reçoit une requête de type barrière, elle est composée d'une requête de type Synchronize_Cache suivie d'une requête de type 15 Write_FUA ou Read_FUA. Une fois � traduite � pour le protocole SATA, cette barrière devient une requête Flush_Cache, suivie d'une requête Write (ou Read le cas échéant), suivie d'une autre requête Flush_Cache. On notera bien que l'exécution successive de ces requêtes nécessite à chaque fois la 20 réception d'un accusé d'exécution de la part de l'unité de stockage 38 pour passer à l'étape suivante. Dans le cas de la barrière d'écriture traduite en protocole SATA, cela donne les échanges suivants : 25 - le gestionnaire d'accès envoie la requête Flush_Cache() à l'unité de stockage 38 visée ; - l'unité de stockage visée renvoie un accusé d'exécution de Flush_Cache() ; - le gestionnaire d'accès envoie la Write( à l'unité de stockage 38 visée ; - l'unité de stockage visée renvoie un accusé d'exécution de WriteO ; 30 - le gestionnaire d'accès envoie la requête Flush_Cache() à l'unité de stockage 38 visée ; et l'unité de stockage visée renvoie un accusé d'exécution de Flush_Cache(). Ce n'est qu'après ce dernier accusé d'exécution que l'opération 76 peut être exécutée. Dans d'autres modes de réalisation, d'autres protocoles que le SATA peuvent être mis en oeuvre, et la fonction Adapt() est modifiée en conséquence. Ensuite, dans une opération 120, la requête Regl est envoyée à l'unité de stockage 38, et l'exécution de la requête Req se prolonge avec l'opération 116. Bien que les figures 7, 8 et 9 aient été décrites en rapport avec un même mode de 10 réalisation, il est manifeste qu'elles pourraient être mises en oeuvre séparément. En outre, les requêtes de synchronisation sont décrites ici comme le résultat de requêtes issues de la couche d'application. Cependant, les gestionnaires d'accès pourraient être mis en oeuvre avec des ordonnanceurs propres. Par ailleurs, les mises à jour des tables d'écriture pourraient également être réalisées à réception de la requête pour le cas du gestionnaire d'accès serveur, ou à complétion de la requête pour le cas du gestionnaire d'accès client, ou entre ces deux évènements. 20 Dans le cas où les gestionnaires d'accès traitent des requêtes en parallèle, ils comporteront des mécanismes appropriés pour la gestion de concurrence de sorte que les tables d'écriture restent cohérentes. Ces ordonnanceurs pourraient notamment contrôler à intervalles réguliers les tables 25 d'écritures, et provoquer des synchronisations lors de moments favorables, par exemple lorsque la file d'attente des requêtes est vide, ce qui permettrait d'obtenir des augmentations de performances encore supérieures. En outre l'invention concerne également un procédé de gestion de données, applicable 30 dans un réseau comprenant plusieurs stations de stockage de données, comportant les étapes suivantes : 15 a. émettre une requête de fichier depuis une station, sur la base d'une représentation sous forme d'adresses virtuelles, lesdites adresses virtuelles étant associées par groupe à des adresses de stockage données pour stocker les données de stockage correspondantes, b. sur la base de ladite association par groupe d'adresses, déterminer une adresse de stockage correspondant à ladite adresse virtuelle, ainsi que l'unité de stockage sur laquelle est située cette adresse, c. émettre une requête d'accès désignant ladite adresse de stockage vers un gestionnaire 10 d'accès de la station émettrice de la requête, d. exécuter cette requête d'accès par accès avec synchronisation sélective à un stockage volatile et/ou à un stockage persistent de certaines au moins des unités de stockage du gestionnaire d'accès de l'unité de stockage déterminée, en fonction d'un état d'écriture 15 de certaines des adresses virtuelles associées aux adresses de stockage de ces unités de stockage. 25 Revendications1. Outil informatique de stockage de données dans un réseau de stations, chaque station comprenant une ou plusieurs unités de stockage (38) dont certaines au moins comportent des adresses de stockage propres à recevoir des données de stockage, l'outil étant implanté sur chaque station et comprenant d'une part un virtualiseur (36) associant des adresses virtuelles et des adresses de stockage, et d'autre part un gestionnaire d'accès (44) aux adresses de stockage de cette station, agencé pour communiquer avec les gestionnaires d'accès d'autres stations pour exécuter une requête par accès à un stockage volatile (38b) et/ou à un stockage persistent (38a) des unités de stockage de ces stations, caractérisé en ce que chaque gestionnaire d'accès (44) est agencé pour synchroniser sélectivement le stockage volatile (38b) et le stockage persistent (38a) de certaines au moins des unités de stockage (38) dont il gère l'accès, en fonction d'un état d'écriture de certaines des adresses virtuelles associées aux adresses de stockage de ces unités de stockage (38). 2. Outil informatique selon la revendication 1, dans lequel chaque gestionnaire d'accès maintient une table d'écriture respective dont les entrées sont chacune associées d'une part à une plage d'adresses de stockage sur une unité de stockage, et d'autre part à une plage d'adresses virtuelles qui sont associées aux adresses de stockage de cette plage, la valeur de chaque entrée indiquant un état d'écriture pour la plage d'adresses de stockage et la plage d'adresses virtuelles associées à cette entrée. 3. Outil informatique selon la revendication 2, dans lequel la table d'écriture porte sur des unités de stockage gérées par le gestionnaire d'accès qui la maintient. 4. Outil informatique selon la revendication 2 ou 3, dans lequel chaque gestionnaire d'accès est agencé, à complétion d'une requête d'accès d'écriture dans une adresse de stockage donnée, pour définir l'entrée de la table d'écritureassociée à cette adresse et à l'adresse virtuelle correspondante avec une valeur indiquant qu'une opération d'écriture a été exécutée. 5. Outil informatique selon la revendication 2 ou 3, dans lequel chaque gestionnaire d'accès est agencé, à réception d'une requête d'accès d'écriture dans une adresse de stockage donnée, pour définir l'entrée de la table d'écriture associée à cette adresse et à l'adresse virtuelle correspondante avec une valeur indiquant qu'une opération d'écriture a été exécutée. 6. Outil informatique selon l'une des revendications 2 à 5, dans lequel chaque gestionnaire d'accès est agencé, à réception d'une requête d'accès de synchronisation désignant une adresse virtuelle et une adresse de stockage sur une unité de stockage, pour synchroniser le stockage volatile et le stockage persistent de l'unité de stockage désignée, pour la plage d'adresses de stockage dont la valeur de l'entrée dans la table d'écriture associée à cette plage et à la plage d'adresses virtuelles désignée par la requête d'accès de synchronisation indique qu'une opération d'écriture a été enregistrée. 7. Outil informatique selon l'une des revendications précédentes, dans lequel les gestionnaires d'accès communiquent entre eux selon un paradigme client-serveur. 8. Outil informatique selon la revendication 7, dans lequel chaque gestionnaire d'accès comprend une unité dite cliente pour envoyer une requête d'accès à un gestionnaire d'accès d'une autre station, et une unité dite serveur pour recevoir une requête de ce type et pour gérer en conséquence l'accès aux unités de stockage concernées. 9. Outil informatique selon l'une des revendications précédentes, dans lequel le gestionnaire d'accès comprend un ordonnanceur agencé pour générer des requêtes de synchronisation.