Brevet FR2940570A1 — publié le 20100625

SEANODES4.FRD 1 Système de stockage comprenant plusieurs noeuds en réseau avec gestion de la parité L'invention concerne les systèmes informatiques comprenant plusieurs postes informatiques dits noeuds interconnectés en un réseau. Les réseaux modernes comportent des stations utilisateurs qui sont reliées à un ou plusieurs serveurs et peuvent partager des applications etlou des espaces de stockage de manière locale ou distante. 10 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). L'utilisation de ces systèmes perfectionnés présente certains désavantages, comme les coûts 15 associés, les limitations de performance et d'extensibilité, et la lourdeur générale de l'installation qui leur correspond. 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 pannes ainsi que dans la quantité d'espace allouée à la redondance des données. 25 L'invention vient améliorer la situation. A cet effet, l'invention propose un outil informatique de stockage de données dans un 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 et des 30 données de parité, l'outil étant implanté sur chaque station et comprenant 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. 20 Dans cet outil, le virtualiseur établit une correspondance entre un groupe d'adresses virtuelles et un groupe d'adresses de stockage donnés pour stocker les données de stockage correspondantes ainsi que des données de parité, les adresses de stockage de chaque groupe étant réparties sur des unités de stockage distinctes. En outre, le gestionnaire d'accès comprend les éléments suivants : - un verrouilleur, agencé pour verrouiller ou déverrouiller l'accès à une adresse de stockage sur une unité de stockage de la station sur laquelle est implanté l'outil, - un actionneur d'accès, agencé pour effectuer un accès à une adresse de stockage sur unité de 10 stockage de la station sur laquelle est implanté l'outil, - un contrôleur de parité, agencé pour calculer des données de parité, - un connecteur, agencé pour permettre un échange de données entre le gestionnaire d'accès et un autre gestionnaire d'accès, - un relayeur, agencé pour transmettre des données caractéristiques d'une requête d'accès, du 15 gestionnaire d'accès vers un autre gestionnaire d'accès, - un constructeur, agencé pour construire, à partir de données de requête d'accès à une adresse de stockage, une séquence ordonnée d'appel de certains au moins des éléments des gestionnaires d'accès des stations comportant les adresses de stockage du groupe d'adresses désigné par ladite requête d'accès, 20 ladite séquence ordonnée comprenant au moins un appel au relayeur, et comprenant, pour chaque appel ultérieur d'un relayeur, un appel préalable au verrouilleur du gestionnaire d'accès de ce relayeur. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la 25 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, 30 - 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 procédé d'accès à un fichier dans le système de la figure 1, - la figure 6 montre un exemple de mise en oeuvre d'une opération de la figure 5, et - les figures 7 à I l représentent des séquences d'opérations de la figure 6 pour divers accès selon le procédé de la figure 5. 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 pas 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 Ni, 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. Les30 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 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 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 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 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 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, 10 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 applicatif, un rôle de noeud stockant, ou encore ces deux rôles à la fois. 15 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. 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 station représentée dans cet exemple peut représenter l'une des stations N1, N2 ou N3. La station Nx présente individuellement une structure semblable à celle de la structure globale 25 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 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. 30 L'accès direct à l'espace de stockage 38 est géré par un gestionnaire d'accès 44. 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. 20 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. 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 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 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 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 de 30 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. 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 5 représente un procédé mis en oeuvre par le système pour accéder à un 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 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. 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. Les requêtes d'accès virtuel comportent chacune : - l'adresse virtuelle visée, - 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 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. 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 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. 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 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 fichier. 25 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. 30 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.20 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 : - 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, l'écriture, la resynchronisation ou la vérification, - 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, 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. 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 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 : - 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. 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. 10 En fait, chaque requête d'accès physique est placée dans une file d'attente de requête du 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 20 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. La figure 4 montre différents éléments du gestionnaire d'accès 44 pour exécuter les requêtes d'accès physique (ci-après requêtes d'accès). Dans l'exemple décrit ici, le gestionnaire d'accès comprend un verrouilleur 80, un actionneur d'accès 82, un contrôleur de parité 84, un connecteur 86, un relayeur 88, et un constructeur 90. 30 Le constructeur 90 est un élément qui reçoit les données qui décrivent une requête d'accès, et qui construit la séquence d'exécution de la requête. Le constructeur 90 part de paramètres décrivant l'état général du système, ainsi que des données particulières à la requête d'accès, comme l'adresse visée et la nature de la requête. 25 Par paramètres décrivant l'état général du système, on entend toute donnée qui permet au constructeur de déterminer si une des unités de stockage à laquelle un accès doit être fait pour mener à bien la requête est en panne, et si oui laquelle. Par nature de la requête, on entend la notion de lecture ou d'écriture vue plus haut. En effet, une opération de lecture ne nécessite pas de modification de données et pourra généralement être traitée avec une séquence plus simple. A partir de ces informations, le constructeur 90 va appliquer un schéma générique de 10 séquence tiré des paramètres mentionnés plus haut, et le particulariser avec le cas particulier de cette requête. Les différents schémas génériques seront décrits avec les figures 7 à 11. 15 Dans la séquence établie par le constructeur 90, des appels aux éléments du gestionnaire d'accès 44 sont prévus selon un ordre choisi. Des appels à des éléments d'un autre gestionnaire d'accès 44 sont également prévus lorsqu'il est nécessaire d'accéder à des données situées sur une unité de stockage qui n'est pas gérée par le gestionnaire d'accès 44 courant. 20 Pour toute requête d'accès, le constructeur 90 va recevoir du virtualiseur le groupe d'adresses correspondant à l'adresse physique concernée. Ce groupe d'adresses est transmis selon un ordre fixé qui correspond à un classement des 25 adresses dans le groupe d'adresses correspondant, par exemple celui des adresses virtuelles correspondantes. Ainsi, pour deux séquences distinctes, le constructeur 90 appellera les adresses du groupe d'adresses correspondant selon l'ordre fixé. Le verrouilleur 80 est un élément critique qui a pour fonction d'empêcher ou de libérer l'accès à des données sur une unité de stockage. Cet élément est critique car il permet de maintenir la cohérence des données. Comme on l'a vu plus haut et comme cela apparaîtra mieux par la suite, il est crucial de ne pas modifier certaines données au cours d'une séquence. 30 Le verrouilleur 80 peut effectuer des verrouillages stricts, c'est-à-dire qui excluent tout accès aux données verrouillées. En variante, le verrouilleur 80 peut effectuer des verrouillages sélectifs en fonction de l'accès envisagé pour les données verrouillées. Ainsi, un verrouillage dit � de lecture � autorisera la réalisation d'un autre verrouillage de lecture. L'actionneur d'accès 82 est le gestionnaire physique du gestionnaire d'accès 44. C'est cet élément qui va concrètement aller lire et écrire sur les unités de stockage contrôlées par le gestionnaire d'accès. 10 Le contrôleur de parité 84 est un élément du gestionnaire d'accès qui a pour fonction de calculer un élément de donnée de parité. Comme cela apparaîtra mieux par la suite, le constructeur est agencé pour générer des séquences qui, lorsque cela est nécessaire, génèrent des données de parité � au fil de l'eau �. Cela permet de réduire la quantité de données qui est transmise et augmente la résilience aux pannes. 15 Le connecteur 86 est un élément du gestionnaire d'accès qui permet la communication entre deux gestionnaires d'accès gérant des unités de stockage distinctes, afin de partager des données. 20 Le connecteur 86 peut être mis en oeuvre de différentes manières. Dans une première mise en oeuvre, le connecteur effectue des envois directs d'une source vers une destination. Cela signifie que la source s'attend à ce qu'un tampon de réception soit libre sur la destination pour recevoir cet envoi. Cette mise en oeuvre est directe et peu coûteuse en communication, mais elle présente des faiblesses dans le sens que, si la destination ne possède pas de tampon libre pour recevoir l'envoi, celui-ci sera perdu et une erreur sera générée. 30 Dans une deuxième mise en oeuvre, le connecteur 86 va stocker un pointeur sur la ressource qu'il cherche à partager, et partager ce pointeur. Ainsi, la destination peut venir consulter ce pointeur et ainsi accéder à distance à la ressource. 25 Cette mise en oeuvre est moins risquée et un peu plus coûteuse en communication, et assez simple à mettre en oeuvre. Enfin, dans une troisième mise en oeuvre, le connecteur 86 va créer un espace pour la ressource, et gérer cet espace sur la base d'un identifiant logique. Le connecteur 86 transmettra cet identifiant logique à la destination, qui pourra l'utiliser pour interagir avec le connecteur 86 et accéder à la ressource. Cette mise en oeuvre est plus fiable que la deuxième mise en oeuvre, mais elle est un peu plus 10 complexe à mettre en oeuvre. Le relayeur 88 est un élément du gestionnaire d'accès qui a pour fonction de transmettre un état de requête à un autre gestionnaire d'accès, conformément au schéma établi par la séquence. Comme on le verra plus bas, le relayeur 88 peut être mis en oeuvre de nombreuses manières. Ainsi, le relayeur 88 peut transmettre une séquence entre deux gestionnaires d'accès, ou un indicateur de progression de la séquence avec les éléments qui ont permis de générer cette séquence. Comme on l'a vu plus haut, l'utilisation d'un stockage de la parité représente un certain nombre de défis à maîtriser. Le premier de ces défis est de maintenir la cohérence des données. En effet, la cohérence est 25 assez simple à maintenir dans un système à réplication, puisque toutes les données sont toujours dupliquées. En outre, les données dupliquées ne sont impactées que par une modification des données auxquelles elles correspondent. A l'opposé, dans les systèmes à parité, les données de parité ne représentent pas directement 30 des données. En outre, ces données sont fréquemment modifiées, puisque toute écriture sur une des données d'un bloc d'adresses va impacter la donnée de parité correspondante. De nombreux problèmes surgissent alors, comme la gestion de la concurrence d'accès à des données d'un même groupe d'adresses. En effet, comme on vient de le voir, une modification 15 20 due à une écriture d'une donnée impacte la donnée de parité du bloc d'adresses correspondant. Donc si on cherche à écrire sur deux données d'un même groupe d'adresses, et si les opérations ne sont pas synchronisées correctement, il existe un risque important que la donnée de parité soit fausse, car basée sur une version ancienne des données qui viennent d'être écrite. Ce cas relativement simple est encore complexifié lorsqu'une panne d'un disque intervient 10 lors d'une écriture. Des solutions ont été proposées pour gérer ce type de problèmes. Elles reposent généralement sur la synchronisation des unités de stockage entre elles par un � chef d'orchestre �. Cependant cela est lourd et peu efficace. 15 La Demanderesse a développé un outil bien plus performant et fiable. Il ressort de ce qui précède que : - chaque station stocke un gestionnaire d'accès qui gère tous les accès aux unités de stockage de cette station, 20 - les gestionnaires d'accès sont indépendants entre eux, et - une requête d'accès est mise en oeuvre au moyen d'une machine à états dont une partie est exécutée par chaque gestionnaire d'accès concerné. Ainsi, comme les gestionnaires d'accès sont découplés, ils peuvent opérer plus librement. La 25 machine à état qui définit les opérations nécessaires à l'exécution de la requête peut ainsi être réalisée sous la forme d'une séquence d'appels au gestionnaire d'accès, l'avancement dans la séquence pouvant être conditionné par la réception de données d'un autre gestionnaire d'accès. 30 Pour fonctionner de manière indépendante comme cela a été décrit plus haut, le gestionnaire d'accès exécute les requêtes comme une suite d'appels aux éléments décrits ci-dessus, en fonction d'un état de séquence. La figure 6 représente un schéma générique de traitement d'une requête par le gestionnaire d'accès. Dans une opération 100, le gestionnaire d'accès reçoit un ordre d'exécution d'une requête d'accès (opération 60 de la figure 5). A réception de cet ordre avec les paramètres correspondants décrits plus haut, il appelle le constructeur 90 pour établir la séquence d'exécution de la requête. Dans une opération 102, un compteur d'appel est créé. Ce compteur indique quel est l'indice du prochain appel qui doit être exécuté. S'en suit une boucle d'incrémentation d'indice d'appel et d'exécution d'appel, dans laquelle le gestionnaire d'accès détermine dans une opération 104 l'état d'exécution de l'appel correspondant à l'indice courant. L'état d'exécution peut prendre plusieurs valeurs : - attente : état qui signifie que le gestionnaire d'accès doit attendre des données d'un autre gestionnaire d'accès ou un signal d'activation, - prêt : état qui signifie que l'appel peut être exécuté sans risque de compromettre la bonne exécution de la requête, - fini : état qui signifie que le dernier appel de la séquence a été exécuté avec succès et que le gestionnaire d'accès peut considérer que la requête d'accès a été exécutée, et - erreur : état qui signifie qu'un évènement imprévu est arrivé qui compromet l'exécution correcte de la requête. Lorsque le gestionnaire d'accès reçoit d'un autre gestionnaire d'accès les données nécessaires à l'exécution de l'appel correspondant à l'indice courant, l'état d'exécution passe de � attente � à � prêt �. Dans ce cas, c'est une opération distante exécutée sur un gestionnaire d'accès distant qui provoque le changement d'état. Par exemple, le déverrouillage d'une ressource par un verrouilleur d'un gestionnaire d'accès nécessite la réception d'informations d'accusé d'exécution du relayeur du gestionnaire d'accès qui le suit dans la séquence.30 Le changement d'état peut être également local, par exemple lorsqu'une opération par un gestionnaire d'accès nécessite des données résultant d'une opération d'un autre élément de ce même gestionnaire d'accès. Par exemple, le calcul d'un morceau de parité par le contrôleur de parité nécessite la lecture par l'actionneur d'accès des données nécessaires à ce calcul. Cela apparaîtra mieux avec les figures 7 à 11. Ensuite dans une opération 106, le gestionnaire d'accès teste si l'état d'exécution est � fini � ou � erreur �. Si c'est le cas, alors l'exécution de la séquence est terminée dans une opération 108. Dans le cas où l'état était � fini �, le gestionnaire d'accès procède avec la séquence suivante. Dans le cas où l'état était � erreur �, le gestionnaire d'accès rappelle le constructeur avec cet état d'exécution, ainsi qu'avec les paramètres originaux de la requête d'accès, afin de reconstruire une séquence qui permette de mener à bien la requête originale en tenant compte de l'état d'erreur. Dans le cas où l'état est � attente � ou � prêt �, la boucle se poursuit dans une opération 110 qui teste cet état. Dans le cas où l'état d'exécution est � attente �, la boucle reprend avec l'opération 104 pour déterminer si l'état d'exécution a évolué. Sinon, la boucle se poursuit avec une opération 112 dans laquelle l'appel correspondant à l'indice courant est exécuté. Le compteur d'appel est incrémenté dans une opération 114, et la boucle reprend avec 30 l'opération 104 pour déterminer l'état d'exécution de l'appel suivant. Le module d'administration 46 est capable de gérer la détection d'autres types d'erreurs, comme la perte totale de l'accès à un disque à cause d'une défaillance matérielle ou réseau.25 Dans ce cas, tous les gestionnaires d'accès 44 concernés par une telle panne reçoivent du module d'administration 46 un ordre impératif d'arrêt des requêtes en cours, et un jeu de requêtes d'accès adaptées à cette situation est émis. Bien sûr, un gestionnaire d'accès 44 peut traiter en parallèle plusieurs requêtes dès lors qu'elles ne visent pas des ressources verrouillées. Les figures 7 à 11 vont maintenant servir à décrire divers types de séquences mises en oeuvre par le gestionnaire d'accès. Sur les figures 7 à 11, les séquences sont représentées par des suites d'opérations agencées verticalement et en plusieurs colonnes. Une suite d'opérations liées verticalement indique que ces opérations sont réalisées par des 15 éléments d'un même gestionnaire d'accès. Chaque colonne indique donc les opérations à réaliser par chaque gestionnaire d'accès concerné par une requête donnée. Les séquences des figures 7 à 1 1 correspondent aux contextes suivants : - sur la figure 7, l'opération est une opération de lecture dans laquelle aucune erreur n'est 20 présente, c'est-à-dire que toutes les ressources nécessaires à cette lecture sont accessibles et fonctionnelles, - sur la figure 8, l'opération est une opération de lecture dans laquelle l'unité de stockage sur laquelle est située les données à lire est inaccessible. Il est donc nécessaire de recouvrer ces données à partir des données de toutes les autres adresses de ce groupe d'adresse, et des 25 données de parité correspondantes, - sur la figure 9, l'opération est une opération d'écriture dans laquelle aucune erreur n'est présente, c'est-à-dire que toutes les ressources nécessaires à cette écriture sont accessibles et fonctionnelles. Il faut donc écrire les données concernées et modifier les données de parité en conséquence, 30 - sur la figure 10, l'opération est une opération d'écriture dans laquelle l'unité de stockage sur laquelle les données à écrire doivent être stockées est inaccessible. Il faut donc calculer les données de parités tenant compte de cette écriture à partir des données de toutes les autres adresses de ce groupe d'adresses, et écrire ces nouvelles données de parité, et10 - sur la figure 11, l'opération est une opération d'écriture dans laquelle l'unité de stockage sur laquelle sont situées les données de parité est inaccessible. Il faut donc simplement écrire les données. Dans ce qui suit, il sera fait référence aux adresses qui sont associées à l'adresse visée par la requête en tant que � groupe d'adresses correspondant �. Dans ce qui suit, dans une figure donnée, un gestionnaire d'accès pourra être désigné aussi bien par son nom (c'est-à-dire gestionnaire d'accès de l'unité de stockage qui stocke des données choisies) que par son numéro de colonne (par exemple, le premier gestionnaire d'accès est celui qui correspond à la première colonne, etc.). Le gestionnaire d'accès qui reçoit la requête sera nommé gestionnaire d'accès initial, et le gestionnaire d'accès qui gère l'unité de stockage des données de parité sera nommé gestionnaire d'accès de parité. Dans toutes les figures, la colonne d'opérations le plus à gauche représente les opérations du gestionnaire d'accès initial. Les opérations mises en oeuvre par le gestionnaire d'accès initial sont les mêmes pour toutes les séquences : - initier la séquence (référence 720, 820, 920, 1020 et 1120), - transmettre la séquence à un gestionnaire d'accès concerné (référence 722, 822, 922, 1022, 1122), et - terminer la séquence (référence 724, 824, 924, 1024 et 1124) à réception d'un accusé correspondant du gestionnaire auquel a été transmise la séquence. En outre, bien que le gestionnaire d'accès du client émetteur de la requête d'accès soit représenté dans la première colonne en tant que gestionnaire d'accès initial, ce gestionnaire d'accès initial pourrait également être impliqué dans une autre colonne. En effet, un client émetteur de requête d'accès peut également stocker des données de stockage ou de parité. Dans ce cas, son gestionnaire d'accès joue un rôle double dans la séquence. Dans toutes les figures, la colonne d'opération le plus à droite représente les opérations du gestionnaire d'accès de parité, à l'exception de la figure 7 où il est inutile et de la figure 11 où il est inaccessible. Les opérations mises en oeuvre par le gestionnaire d'accès de parité sont les mêmes pour toutes les séquences : - initier la séquence (référence 826, 926, et 1026), - verrouiller l'accès aux données de parité pour les autres séquences (référence 828, 928, et 1028), - lire les données de parité locales, ainsi que les données de parité mise à disposition par le gestionnaire d'accès qui a initié la séquence (référence 830, 930, et 1030), - calculer les données de parité mises à jour sur la base des données lues (référence 832, 932, et 1032), - écrire les données de parité mises à jour (référence 834, 934, et 1034), sur le gestionnaire d'accès le plus à gauche dans le cas d'une opération de lecture, et localement dans le cas d'une opération d'écriture, - déverrouiller l'accès aux données de parité pour les autres séquences (référence 836, 936, et 1036), - envoyer un accusé d'exécution au gestionnaire d'accès qui a initié la séquence (référence 828, 928, et 1028), et - finir la séquence localement (référence 840, 940, et 1040). Comme cela a été décrit plus haut, le passage d'une opération à l'autre est conditionné à un changement d'état. Le changement d'état peut être de deux natures : - éloigné, lorsque c'est une opération sur un autre gestionnaire d'accès qui induit le changement. C'est par exemple le cas pour les opérations d'initialisation et de déverrouillage (sauf pour le gestionnaire d'accès de l'unité de stockage qui reçoit les données de parité), - local, lorsque c'est une opération sur le même gestionnaire d'accès qui induit le changement. C'est par exemple le cas pour les opérations de lecture, de calcul de parité, d'écriture (locale ou éloignée), et de transmission de requête. Sur les figures, un changement d'état éloigné est symbolisé par une flèche d'une colonne à une autre, et un changement d'état local est symbolisé par une flèche verticale au sein d'une colonne. Comme cela apparaît sur les figures, à chaque fois qu'une opération d'un gestionnaire d'accès donné change l'état d'un autre gestionnaire d'accès, l'opération suivante dans la séquence du gestionnaire d'accès donné est conditionnée par un changement d'état éloigné commandé par l'autre gestionnaire d'accès. Cela assure la robustesse des séquences. On notera que les � opérations � de chaque séquence peuvent être composées de plusieurs appels à des éléments du gestionnaire d'accès concerné. Ainsi, les opérations sont ici regroupées par type d'action. Dans ce qui suit, il sera fait mention de séquence de lecture (ou d'écriture) � classique � ou � dégradée �. Ces deux termes se veulent en opposition l'un à l'autre et désignent un état de panne du système associé à ces opérations. Ainsi, par � classique �, on entend que le système est totalement fonctionnel, et que toutes les ressources sont accessibles. C'est donc un état idéal, exempt de toute panne. Par � dégradé �, on entend au contraire que le système a subi une panne identifiée, et les séquences sont adaptées pour tenir compte de cette panne. La figure 7 est une séquence de lecture �classique �, c'est-à-dire lorsqu'il n'y a aucun problème et que l'unité de stockage sur laquelle la ressource à lire est stockée est disponible. Dès lors, seul le gestionnaire d'accès qui émet la requête et le gestionnaire d'accès de l'unité de stockage qui stocke les données à lire sont impliqués. L'opération 722 comprend alors un appel au connecteur 86, qui va mettre à disposition un 30 emplacement pour recevoir une écriture éloignée contenant les données lues. Une fois l'appel au connecteur 86 réalisé, le relayeur 88 transmet la requête de lecture au gestionnaire d'accès de l'unité de stockage qui stocke les données à lire.25 Le deuxième gestionnaire d'accès effectue alors les opérations suivantes : - initialiser la séquence localement (742), - appeler le verrouilleur 80 (744) pour verrouiller l'accès aux données à lire pour les autres séquences, - appeler l'actionneur d'accès 82 (746) pour lire les données voulues, - appeler le connecteur 86 (748) avec ces données pour réaliser l'écriture éloignée dans le tampon ouvert par l'opération 722, - appeler le verrouilleur 80 (750) pour déverrouiller l'accès aux données à lire pour les autres séquences, - appeler le relayeur 88 (752) pour permettre au gestionnaire d'accès initial de passer à l'opération 724, et - terminer la séquence localement (754). La figure 8 est une séquence de lecture � dégradée �, c'est-à-dire que l'unité de stockage sur laquelle sont situées les données à lire n'est pas accessible. Il faut donc lire toutes les données des autres adresses du groupe d'adresses correspondant, ainsi que les données de parité pour recouvrer les données que l'on souhaite lire. Sur cette figure, on voit apparaître quatre colonnes : - la première colonne représente les opérations du gestionnaire d'accès initial, - la deuxième colonne représente les opérations du gestionnaire d'accès de l'unité de stockage qui comprend la première des adresses du groupe d'adresses correspondant, - la troisième colonne représente les opérations des gestionnaires d'accès des unités de stockages qui comprennent les autres adresses du groupe d'adresse correspondant (les pointillés sont là pour indiquer qu'il y en a plusieurs), et - la quatrième colonne représente les opérations du gestionnaire d'accès de parité. Comme on va le voir, les séquences des deuxième et troisième colonnes sont très similaires. La seule différence entre ces séquences est que, pour la deuxième colonne, il n'existe pas encore de portion de données de parité. Dès lors, le calcul d'une nouvelle portion de données de parité n'est pas nécessaire, puisque ce sont les données du groupe d'adresses correspondant qui forment la portion de données de parité. Comme pour la séquence de lecture normale, l'opération 822 comprend un appel au connecteur 86, qui va mettre à disposition un emplacement pour recevoir une écriture éloignée contenant les données lues. Une fois l'appel au connecteur 86 réalisé, le relayeur 88 transmet la requête de lecture au deuxième gestionnaire d'accès. La séquence du deuxième gestionnaire d'accès comprend les opérations suivantes : - initialiser la séquence localement (842), - appeler le verrouilleur 80 (844) pour verrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences, - appeler l'actionneur d'accès 82 (846) pour lire les données locales du groupe d'adresses correspondant, - transmettre (850) la séquence au troisième gestionnaire d'accès, - appeler le verrouilleur 80 (852) pour déverrouiller l'accès aux données à lire pour les autres séquences, - appeler le relayeur 88 (854) pour permettre au gestionnaire d'accès initial de passer à l'opération 824, et pour permettre au troisième gestionnaire d'accès de passer à l'opération 872, et - terminer la séquence localement (856). L'opération 850 comprend l'appel au connecteur 86 pour mettre les données du groupe d'adresses correspondant locales dans un tampon à disposition du troisième gestionnaire d'accès, en tant que portion de données de parité. Lorsque cela est fait, le relayeur 88 est appelé pour transmettre la séquence au troisième gestionnaire d'accès. Le troisième gestionnaire d'accès va alors exécuter la séquence suivante : 30 - initialiser la séquence localement (858), - appeler le verrouilleur 80 (860) pour verrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences,25 - appeler l'actionneur d'accès 82 (862) pour lire les données locales du groupe d'adresses correspondant, ainsi que le connecteur 86 pour lire les portions de données de parité du gestionnaire d'accès qui a initialisé la séquence locale, - appeler le contrôleur de parité 84 (864) pour calculer une nouvelle portion de données de parité, - transmettre (866) la séquence au prochain troisième gestionnaire d'accès ou, si ils ont tous été appelés, au gestionnaire d'accès de parité, - appeler le verrouilleur 80 (868) pour déverrouiller l'accès aux données à lire pour les autres séquences, - appeler le relayeur 88 (870) pour permettre au deuxième gestionnaire d'accès de passer à l'opération 852, ou au troisième gestionnaire d'accès précédent de passer à l'opération 868, et pour permettre au troisième gestionnaire d'accès suivant de passer à l'opération 872, et - terminer la séquence localement (872). L'opération 866 est similaire à l'opération 850, et comprend l'appel au connecteur 86 pour mettre à disposition la portion de données de parité au gestionnaire d'accès suivant, puis l'appel au relayeur 88 pour transmettre effectivement la séquence. Lorsque tous les troisièmes gestionnaires d'accès ont initialisé leur séquence, la portion de données de parité qui a été calculée au fil de l'eau contient des données correspondant à la parité de toutes les données du groupe d'adresses correspondant, à l'exception des données du gestionnaire d'accès de l'unité de stockage non accessible, et des données de parité. Le gestionnaire d'accès de parité (ou quatrième gestionnaire d'accès) va alors exécuter la séquence décrite plus haut. Lorsque le gestionnaire d'accès de parité a exécuté l'opération 838, cela change l'état du troisième gestionnaire d'accès initialisé en dernier, et permet l'exécution sur celui-ci de l'opération 868. Dès lors, une vague de déverrouillage remonte tous les troisièmes gestionnaires d'accès et le deuxième gestionnaire d'accès jusqu'au gestionnaire d'accès initiale.30 Ensuite, l'opération 854 crée une contre-vague d'accusé d'exécution en sens inverse, et permet la terminaison de la séquence localement sur le deuxième gestionnaire d'accès, les troisièmes gestionnaires d'accès ainsi que sur le gestionnaire d'accès de parité. On voit donc que la séquence s'exécute par propagation de la gauche vers la droite d'une portion de données de parité qui est calculée au fil de l'eau, avec verrouillage des données locales à chaque fois pour préserver la cohérence des données. Lorsque ce calcul est fait, on obtient les données que l'on souhaite lire, et une vague de déverrouillage suivie d'une contre-vague pour terminer localement la séquence sur chacun des gestionnaires d'accès. Cette vague permet de libérer les tampons qui ont été ouverts pour l'exécution des séquences. Ainsi, même si une autre panne survenait, il serait possible de reprendre la requête sur la base des différents tampons et verrouillages effectués. Bien que la vague d'accusé d'exécution et la contre-vague d'accusé d'exécution soient représentées dans la seule opération 870, elles représentent deux opérations distinctes d'appel au relayeur 88, et c'est le deuxième appel (la contre-vague) qui déclenche la terminaison localement de la séquence sur les gestionnaires d'accès. La figure 9 est une séquence d'écriture � classique �, c'est-à-dire lorsqu'il n'y a aucun problème et que l'unité de stockage sur laquelle la ressource à écrire est stockée est disponible. Dès lors, seul le gestionnaire d'accès initial, le gestionnaire d'accès de l'unité de stockage qui stocke les données à écrire et le gestionnaire d'accès de parité sont impliqués. Sur cette figure, on voit apparaître trois colonnes : 30 - la première colonne représente les opérations du gestionnaire d'accès initial, - la deuxième colonne représente les opérations du gestionnaire d'accès de l'unité de stockage sur laquelle la ressource à écrire est stockée, - la troisième colonne représente les opérations du gestionnaire d'accès de parité.25 Comme pour la séquence de lecture normale, l'opération 922 comprend un appel au connecteur 86, qui va mettre un emplacement à disposition du deuxième gestionnaire d'accès pour accéder aux données à écrire. Une fois l'appel au connecteur 86 réalisé, le relayeur 88 transmet la requête de lecture au deuxième gestionnaire d'accès. La séquence du deuxième gestionnaire d'accès comprend les opérations suivantes : - initialiser la séquence localement (942), - appeler le verrouilleur 80 (944) pour verrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences, - appeler l'actionneur d'accès 82 (946) pour lire les données locales du groupe d'adresses correspondant, ainsi que le connecteur 86 pour lire les données à écrire du gestionnaire d'accès initial, - appeler le contrôleur de parité 84 (948) pour calculer une portion de données de parité sur la base des données locales du groupe d'adresse correspondant et des données à écrire du gestionnaire d'accès initial, - transmettre (950) la séquence au gestionnaire d'accès de parité, - appeler l'actionneur d'accès 82 (951) pour écrire sur l'unité de stockage concernée les données à écrire du gestionnaire d'accès initial, - appeler le verrouilleur 80 (952) pour déverrouiller l'accès aux données à lire pour les autres séquences, - appeler le relayeur 88 (954) pour permettre au gestionnaire d'accès initial de passer à l'opération 924, et au gestionnaire d'accès de parité de passer à l'opération 940, et - terminer la séquence localement (956). L'opération 950 comprend l'appel au connecteur 86 pour mettre la portion de données de parité dans un tampon à disposition du gestionnaire d'accès de parité. Ensuite, dans l'opération 951, l'actionneur d'accès 82 écrit localement les données à écrire du gestionnaire d'accès initiales à la place des données locales du groupe d'adresses correspondant. L'ordre des opérations 950 et 951 permet d'accroître le parallélisme de l'exécution de la séquence (comme le gestionnaire de parité peut commencer à travailler plus tôt). Cependant, l'ordre de ces opérations pourrait être inversé. Lorsque cela est fait, le relayeur 88 est appelé pour transmettre la séquence au gestionnaire d'accès de parité. Le gestionnaire d'accès de parité (ou troisième gestionnaire d'accès) va alors exécuter la séquence décrite plus haut. On notera qu'ici, l'opération 934 consiste à écrire localement les nouvelles données de parité qui sont tirées des anciennes données de parité et des nouvelles données écrites. Ainsi, même si une panne survenait, il serait possible de reprendre la requête sur la base des 15 différents tampons et verrouillages effectués. Lorsque le gestionnaire d'accès de parité a exécuté l'opération 938, cela change l'état du deuxième gestionnaire d'accès, et permet l'exécution sur celui-ci de l'opération 952. 20 Cela induit ensuite l'opération 954, qui permet à la fois au gestionnaire d'accès initial et au gestionnaire d'accès de parité de terminer localement la séquences. La figure 10 représente une opération d'écriture � dégradée �, dans laquelle l'unité de stockage sur laquelle les données doivent être écrites n'est pas accessible. Il faut donc lire toutes les données des autres adresses du groupe d'adresses correspondant, ainsi que les données de parité pour stocker les données que l'on souhaite écrire dans de nouvelles données de parité. 30 Sur cette figure, on voit apparaître quatre colonnes : - la première colonne représente les opérations du gestionnaire d'accès initial, - la deuxième colonne représente les opérations du gestionnaire d'accès de l'unité de stockage qui comprend la première des adresses du groupe d'adresses correspondant, 25 - la troisième colonne représente les opérations des gestionnaires d'accès des unités de stockages qui comprennent les autres adresses du groupe d'adresse correspondant (les pointillés sont là pour indiquer qu'il y en a plusieurs), et - la quatrième colonne représente les opérations du gestionnaire d'accès de parité. Comme on va le voir, les séquences des deuxième et troisième colonnes sont très similaires. La seule différence entre ces séquences est que, pour la deuxième colonne, il n'existe pas encore de portion de données de parité. Dès lors, le calcul d'une nouvelle portion de données 10 de parité est réalisé en calculant la parité entre les données locales du groupe d'adresses correspondant et les données à écrire. Comme pour la séquence d'écriture normale, l'opération 1022 comprend un appel au connecteur 86, qui va mettre un emplacement à disposition du deuxième gestionnaire d'accès 15 pour accéder aux données à écrire. Une fois l'appel au connecteur 86 réalisé, le relayeur 88 transmet la requête d'écriture au deuxième gestionnaire d'accès. 20 La séquence du deuxième gestionnaire d'accès comprend les opérations suivantes : - initialiser la séquence localement (1042), - appeler le verrouilleur 80 (1044) pour verrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences, - appeler l'actionneur d'accès 82 (1046) pour lire les données locales du groupe d'adresses 25 correspondant, - appeler le contrôleur de parité 84 (1048) pour calculer une portion de données de parité sur la base des données locales du groupe d'adresse correspondant et des données à écrire du gestionnaire d'accès initial, - transmettre (1050) la séquence au troisième gestionnaire d'accès, 30 - appeler le verrouilleur 80 (1052) pour déverrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences, - appeler le relayeur 88 (1054) pour permettre au gestionnaire d'accès initial de passer à l'opération 1024, et pour permettre au troisième gestionnaire d'accès de passer à l'opération 1072, et5 - terminer la séquence localement (1056). L'opération 1050 comprend l'appel au connecteur 86 pour mettre la portion de données de parité de l'opération 1048 dans un tampon à disposition du troisième gestionnaire d'accès. Lorsque cela est fait, le relayeur 88 est appelé pour transmettre la séquence au troisième gestionnaire d'accès. Le troisième gestionnaire d'accès va alors exécuter la séquence suivante : 10 - initialiser la séquence localement (1058), - appeler le verrouilleur 80 (1060) pour verrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences, - appeler l'actionneur d'accès 82 (1062) pour lire les données locales du groupe d'adresses correspondant, ainsi que le connecteur 86 pour lire la portion de données de parité du 15 gestionnaire d'accès qui a initialisé la séquence locale, - appeler le contrôleur de parité 84 (1064) pour calculer une nouvelle portion de données de parité, - transmettre (1066) la séquence au prochain troisième gestionnaire d'accès ou, si tous les troisièmes gestionnaires d'accès ont été initialisés, au gestionnaire d'accès de parité, 20 - appeler le verrouilleur 80 (1068) pour déverrouiller l'accès aux données locales du groupe d'adresses correspondant pour les autres séquences, - appeler le relayeur 88 (1070) pour permettre au deuxième gestionnaire d'accès de passer à l'opération 1052, ou au troisième gestionnaire d'accès précédent de passer à l'opération 1068, et pour permettre au troisième gestionnaire d'accès suivant de passer à l'opération 1072, et 25 - terminer la séquence localement (1072). L'opération 1066 est similaire à l'opération 1050, et comprend l'appel au connecteur 86 pour mettre à disposition la portion de données de parité au gestionnaire d'accès suivant, puis l'appel au relayeur 88 pour transmettre effectivement la séquence. Lorsque tous les troisièmes gestionnaires d'accès ont initialisé leur séquence, la portion de données de parité qui a été calculée au fil de l'eau contient des données correspondant à la parité de toutes les données du groupe d'adresses correspondant, à l'exception des données du gestionnaire d'accès de l'unité de stockage non accessible, et des données de parité. 28 30 Le gestionnaire d'accès de parité (ou quatrième gestionnaire d'accès) va alors exécuter la séquence décrite plus haut. On notera qu'ici, l'opération 1034 consiste à écrire localement les nouvelles données de parité qui sont tirées des anciennes données de parité et des nouvelles données écrites. Comme l'unité de stockage qui devrait stocker ces données écrites n'est pas accessible, ce sont les nouvelles données de parité qui représentent ces données écrites. Lorsque le gestionnaire d'accès de parité a exécuté l'opération 1038, cela change l'état du troisième gestionnaire d'accès initialisé en dernier, et permet l'exécution sur celui-ci de l'opération 1068. Dès lors, une vague de déverrouillage remonte tous les troisièmes gestionnaires d'accès et le deuxième gestionnaire d'accès jusqu'au gestionnaire d'accès initiale. Ensuite, l'opération 1054 crée une contre-vague d'accusé d'exécution en sens inverse, et permet la terminaison de la séquence localement sur le deuxième gestionnaire d'accès, les troisièmes gestionnaires d'accès ainsi que sur le gestionnaire d'accès de parité. On voit donc que la séquence s'exécute par propagation de la gauche vers la droite d'une portion de données de parité qui est calculée au fil de l'eau, avec verrouillage des données locales à chaque fois pour préserver la cohérence des données. 25 Lorsque ce calcul est fait, on obtient les données que l'on souhaite écrire, et une vague de déverrouillage suivie d'une contre-vague de terminaison localement des séquences vient permettre de libérer les tampons qui ont été ouverts pour l'exécution des séquences. La figure 11 représente une opération d'écriture � dégradée �, dans laquelle l'unité de 30 stockage des données de parité n'est pas accessible. Dès lors, cette opération est une simple opération d'écriture qui n'implique que le gestionnaire d'accès initial et le gestionnaire d'accès de l'unité de stockage sur laquelle la ressource à écrire est stockée (ci-après deuxième gestionnaire d'accès).20 Cette opération est très similaire à celle de la figure 9, sauf que toutes les interactions avec le gestionnaire d'accès de parité sont supprimées. Comme pour la séquence d'écriture normale, l'opération 1122 comprend un appel au connecteur 86, qui va mettre un emplacement à disposition du deuxième gestionnaire d'accès pour accéder aux données à écrire. Ainsi, le deuxième gestionnaire d'accès exécute les opérations suivantes : - une initialisation (1142) similaire à l'opération 942, - un verrouillage (1144) similaire à l'opération 944, - une lecture des données à écrire (1146) qui comprend une lecture des données à écrire similaire à celle à l'opération 946, mais sans la lecture des données locales, - une écriture de ces données (1151) similaire à celle de l'opération 951, - un déverrouillage (1152) similaire à l'opération 952, - un appel au relayeur (1154) similaire à l'opération 954, et - une terminaison de séquence locale (1156) similaire à l'opération 956. Les séquences décrites avec les figures 7 à 11 sont aisément adaptables pour réaliser les opérations de synchronisation de parité et de vérification de parité. En effet, la synchronisation de parité implique le calcul de nouvelles données de stockage ou de parité pour mettre à jour des données erronées, et l'opération de vérification de parité consiste à calculer la portion de parité pour toutes les adresses d'un groupe d'adresses correspondant, et à vérifier qu'elle correspond aux données de parité correspondantes. Les séquences décrites avec les figures 7 à 11 représentent un mode de réalisation avantageux car elles permettent des verrouillages et déverrouillages ordonnés, répartis et propagés en chaîne. 30 Plus précisément, après l'appel au premier relayeur, chaque appel ultérieur d'un relayeur implique un appel préalable au verrouilleur du gestionnaire d'accès de ce relayeur. 25 De plus, tous les appels aux verrouilleurs pour verrouiller l'accès à des adresses de stockage comprenant des données de stockage sont préalables à un appel au verrouilleur pour verrouiller l'accès à une adresse de stockage comprenant les données de parité associées. Enfin, tous les appels aux verrouilleurs pour verrouiller l'accès à des adresses de stockage sont préalables à un quelconque appel à un verrouilleur pour déverrouiller une adresse de stockage. Cela permet de garantir la cohérence des données et d'éviter les situations d'interblocage. Plus particulièrement, dans le cas de survenance de panne, la synchronisation des données est garantie. En outre, comme l'exécution de la séquence est répartie sur tous les gestionnaires d'accès, le client émetteur de la requête n'est plus un point dont une panne prête à conséquence, et cette panne peut être mieux gérée, comme les séquences peuvent se terminer sans le client. Cela est particulièrement intéressant pour la gestion des pannes dans le cas où le client stocke des données du groupe d'adresses correspondant de la séquence. Cela signifie également que la récupération d'une panne client a un coût moins élevé comme 20 il suffit à chaque séquence de reprendre là où elle s'était arrêtée, sans nécessiter une resynchronisation des données de parité. En outre, cette propagation contrôlée permet également un calcul au fil de l'eau des portions de données de parité. Cela permet de répartir la charge de calcul entre les différents serveurs, ce qui est intéressant pour la gestion de parités complexes. Cela permet également de répartir la charge de communication liée aux opérations faisant appel à la parité. 30 Cela est également favorable pour les situations d'exception comme les modes de fonctionnement dégradé, ou les phases de reconstruction et de vérification de synchronisation (cohérence), comme ces opérations impactent tous les gestionnaires d'accès d'un groupe d'adresses correspondant donné. 25 Par ailleurs, le mécanisme de double acquittement et la terminaison de la requête en cas de panne augmentent la fiabilité et la robustesse du système. Enfin, ces séquences pourraient être adaptées à des méthodes de correction d'erreur similaires à la parité, mentionnées plus haut comme � parités complexes�, comme les codes de Reed-Solomon ou les codes LDPC (par exemple Gallager). Ces codes diffèrent de la parité décrite plus haut par le fait qu'ils impliquent plusieurs données de parité pour chaque groupe d'adresses, et plus une seule comme décrit plus haut. Cependant, les principes décrits ici, comme l'ordre de verrouillage (données avant parité) et de déverrouillage (pas de verrouillage après un déverrouillage), ainsi que les règles de propagation de la séquence sur les gestionnaire d'accès pourraient être appliqués de manière similaire. II serait possible d'alléger certaines des séquences, par exemple en supprimant le principe du double acquittement. Il serait également possible de réduire la latence en transmettant la séquence à chaque fois très 20 tôt après le verrouillage, par exemple juste après le verrouillage. Cela permettrait en effet d'initialiser plus rapidement les lectures de données locales de groupe d'adresse correspondant par chacun des gestionnaires d'accès. 25 En effet, une transmission anticipée permet de paralléliser partiellement l'exécution de la séquence localement par les différents gestionnaires d'accès, tout en maintenant la cohérence des données. Il est également prévu que le connecteur 86 met à disposition des données pour une lecture 30 éloignée, ou au contraire écrit à distance selon les situations. Dans le cas de la lecture de données, l'écriture à distance est intéressante car cela permet de réduire la latence. Cependant, il serait possible de fonctionner en lecture éloignée à partir du gestionnaire d'accès initial. 15 Cette variante peut être intéressante car elle permet alors à un client de gérer la charge réseau associée à ces séquences. En effet, certaines séquences peuvent induire des flux de communications conséquents, et il peut être intéressant de laisser le client choisir l'ordonnancement des requêtes impliquant des communications réseau, plutôt que de laisser une multitude de serveurs le noyer sous les requêtes. En ce qui concerne la propagation des portions de données de parité, c'est la lecture à distance qui est intéressante, car elle ne nécessite pas l'ouverture, à l'avance, d'un espace pour stocker ces données. Cependant, notamment dans la variante de transmission de requête anticipée, il serait possible de mettre en oeuvre une écriture à distance, en prévoyant que celle-ci est déclenchée après la mise à disposition de l'espace mémoire correspondant du côté du gestionnaire d'accès cible. Par ailleurs, bien qu'il soit ici décrit l'utilisation d'écriture et de lecture à distance afin d'économiser les tampons, il serait possible de les remplacer par des envois et des réceptions, 20 moyennant une gestion dynamique appropriée des tampons. Lorsque le constructeur d'un gestionnaire d'accès est appelé par un relayeur, le rôle de ce constructeur est limité à une instanciation sur le gestionnaire d'accès de la séquence reçue. 25 Il apparaît également qu'une requête est associée à une séquence, qui est elle-même composée de séquences locales essentiellement indépendantes. Il ressort de cela qu'en variante le constructeur de chaque gestionnaire d'accès pourrait � construire � la séquence locale à réception d'un message d'un relayeur. Cette construction peut être presque totale, c'est-à-dire que le constructeur ne reçoit qu'un nombre minimal d'informations, telles qu'un indicateur du gestionnaire d'accès qui l'a appelé, un indicateur du gestionnaire d'accès suivant, et une indication de rôle (comme le numéro de colonne et le type d'opération). 30 Plusieurs modes de réalisation ont été décrits plus haut, avec des caractéristiques optionnelles. À chaque fois que cela a paru possible, la combinaison de ces caractéristiques avec chacun de ces modes de réalisation a été décrite. Cependant, c'est l'ensemble des combinaisons des caractéristiques des modes de réalisation décrits qui rentre dans la portée de l'invention. Il doit donc être compris que toutes les combinaisons des modes de réalisation entre eux et 10 des caractéristiques optionnelles sont décrites dans la présente description, ainsi que leurs équivalents, même lorsque cela n'a pas été explicitement décrit par souci de simplicité. En outre l'invention concerne également un procédé de gestion de données, applicable dans un réseau comprenant plusieurs stations de stockage de données, comportant les étapes 15 suivantes : 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 ainsi que 20 des données de parité, b. sur la base de ladite association par groupe d'adresses, déterminer l'adresse de stockage correspondant à ladite adresse virtuelle, ainsi que le groupe d'adresses de stockage stockant les données de stockage et les données de parité, c. émettre une requête d'accès désignant ladite adresse de stockage vers un gestionnaire d'accès de la station émettrice de la requête, d. exécuter ladite requête d'accès en construisant une séquence ordonnée comprenant, pour 30 chaque gestionnaire d'accès concerné, une ou plusieurs opérations choisies parmi le groupe qui comprend : - un verrouillage ou un déverrouillage de l'accès à une adresse de stockage gérée par le gestionnaire d'accès, - un accès à une adresse de stockage gérée par le gestionnaire d'accès, 25 - un calcul de données de parité, - un échange de données avec un autre gestionnaire d'accès, et - une transmission de données de requête vers un autre gestionnaire d'accès, ladite séquence comprenant au moins une transmission de données de requête du gestionnaire d'accès de la station émettrice de la requête vers un autre gestionnaire d'accès, et, pour chaque transmission ultérieure, un verrouillage de l'accès à une adresse accédée par le gestionnaire d'accès concerné. Ce procédé prévoit en outre que : * tous les verrouillages de l'accès à des adresses de stockage comprenant des données de stockage sont préalables à un verrouillage de l'accès à une adresse de stockage comprenant les données de parité associées, * tous les verrouillages de l'accès à des adresses de stockage sont préalables à un quelconque déverrouillage d'une adresse de stockage, et * après chaque transmission, un verrouillage de l'accès à une adresse de stockage est réalisé par le gestionnaire d'accès appelé. 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 et des données de parité, 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, caractérisé en ce que : * le virtualiseur (36) établit une correspondance entre un groupe d'adresses virtuelles et un groupe d'adresses de stockage données pour stocker les données de stockage correspondantes ainsi que des données de parité, les adresses de stockage de chaque groupe étant réparties sur des unités de stockage (38) distinctes, * le gestionnaire d'accès (44) comprend les éléments suivants : - un verrouilleur (80), agencé pour verrouiller ou déverrouiller l'accès à une adresse de stockage sur une unité de stockage (38) de la station sur laquelle est implanté l'outil, - un actionneur d'accès (82), agencé pour effectuer un accès à une adresse de stockage sur unité de stockage (38) de la station sur laquelle est implanté l'outil, - un contrôleur de parité (84), agencé pour calculer des données de parité, 20 - un connecteur (86), agencé pour permettre un échange de données entre le gestionnaire d'accès et un autre gestionnaire d'accès, - un relayeur (88), agencé pour transmettre des données caractéristiques d'une requête d'accès, du gestionnaire d'accès vers un autre gestionnaire d'accès, - un constructeur (90), agencé pour construire, à partir de données de requête d'accès à 25 une adresse de stockage, une séquence ordonnée d'appels de certains au moins des éléments des gestionnaires d'accès des stations comportant les adresses de stockage du groupe d'adresses désigné par ladite requête d'accès, ladite séquence ordonnée comprenant au moins un appel au relayeur (88), et comprenant, pour chaque appel ultérieur d'un relayeur (88), un appel préalable au 30 verrouilleur (80) du gestionnaire d'accès (40) de ce relayeur (88). 2. Outil selon la revendication 1, caractérisé en ce que le constructeur (90) est agencé pour construire une séquence dans laquelle : 36- tous les appels aux verrouilleurs (80) pour verrouiller l'accès à des adresses de stockage comprenant des données de stockage sont préalables à un appel au verrouilleur (80) pour verrouiller l'accès à une adresse de stockage comprenant les données de parité associées, et - tous les appels aux verrouilleurs (80) pour verrouiller l'accès à des adresses de stockage sont préalables à un quelconque appel à un verrouilleur (80) pour déverrouiller une adresse de stockage. 3. Outil selon la revendication 2, caractérisé en ce que le constructeur (90) est agencé pour construire une séquence dans laquelle, après ledit au moins un appel au relayeur (88), le gestionnaire d'accès (44) cible appelle son verrouilleur (80) pour verrouiller l'accès à une adresse de stockage. 4. Outil selon la revendication 3, caractérisé en ce que le constructeur (90) est agencé pour construire une séquence dans laquelle, lorsqu'un relayeur (88) appelle le gestionnaire d'accès (44) qui gère l'accès aux données de parité, la séquence comprend un appel aux éléments suivants de ce gestionnaire d'accès (44) : au verrouilleur (80) pour verrouiller l'adresse des données de parité, à l'actionneur d'accès (82) pour lire les données de parité, au connecteur (86) pour lire une portion de données de parité, au contrôleur de parité (84) avec les données de parité et la portion de données de parité, à l'actionneur d'accès (82) ou au connecteur (86) pour écrire des données tirées du contrôleur de parité (84), au verrouilleur (80) pour déverrouiller l'accès aux données de parité, et au relayeur (88) pour transmettre un accusé d'exécution. 5. Outil selon la revendication 4, caractérise en ce que le constructeur est agencé pour construire une séquence dans laquelle chaque appel au verrouilleur d'un gestionnaire d'accès donné est suivi par au moins un appel à l'actionneur d'accès du gestionnaire d'accès donné pour lire des données de stockage associées à l'adresse de stockage verrouillée, un appel à au moins un élément du gestionnaire d'accès donné, choisi parmi l'actionneur d'accès, le contrôleur de parité, et le connecteur, et un appel au verrouilleur du gestionnaire d'accès donné pour déverrouiller l'adresse de stockage verrouillée. 6. Outil selon la revendication 5, caractérisé en ce que le constructeur (90) est agencé pour construire une séquence dans laquelle l'appel au verrouilleur (80) d'un gestionnaire d'accès (44) donné est suivi par l'appel du relayeur (88) dudit gestionnaire d'accès (44) donné pour transmettre un accusé d'exécution au gestionnaire d'accès (44) du relayeur (88) qui a appelé le gestionnaire d'accès (44) donné. 7. Outil selon la revendication 6, caractérisé en ce que le constructeur (90) est agencé pour construire une séquence dans laquelle l'appel au verrouilleur (80) d'un gestionnaire d'accès (44) autre que celui qui gère l'accès aux données de parité est conditionné par la réception d'un accusé d'exécution d'un autre gestionnaire d'accès (44). 8. Outil selon la revendication 6 ou 7, caractérisé en ce que le constructeur (90) est agencé pour construire une séquence dans laquelle la réception de l'accusé d'exécution par le gestionnaire d'accès (44) du relayeur (88) qui a appelé le gestionnaire d'accès (44) donné est suivie par l'appel du relayeur (88) pour transmettre un contre-accusé d'exécution au gestionnaire d'accès (44) donné.