Système informatique amélioré comprenant plusieurs noeuds en réseau

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 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).

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.

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.

L'invention vient améliorer la situation.

à cet effet, l'invention propose un outil informatique de stockage de données comprenant un module de correspondance relié à des unités de stockage, ledit module de correspondance comprenant une fonction de correspondance pour

déterminer au moins une première et une deuxième adresses de stockage à partir d'une adresse virtuelle reçue en entrée.

Selon un aspect particulier, le module de correspondance maintient une première table comprenant des données d'identification d'unités de stockage en panne, ainsi qu'une deuxième table comprenant des données de modification de blocs d'adresses virtuelles, et l'outil informatique comprend une unité de recouvrement agencée, au rétablissement d'une unité de stockage tombée en panne, pour mettre à jour les adresses de stockage de cette unité de stockage en appelant le module de correspondance avec des adresses virtuelles tirées de la deuxième table, sur la base des données de la première table.

D'autres avantages et caractéristiques de l'invention apparaîtront mieux à la lecture de la description qui suit d'exemples, donnée à titre illustratif et non limitatif, à partir 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 procédé d'accès à un fichier dans le système de la figure 1,

- la figure 5 montre un exemple d'implémentation d'un élément de la figure 3,

- la figure 6 montre une correspondance entre des espaces logiques et des espaces physiques gérée par l'élément de la figure 5,

- la figure 7 montre un exemple d'une fonction mise en œuvre par l'élément de la figure 5 pour établir la correspondance de la figure 6,

- la figure 8 montre un exemple d'implémentation d'une partie de la figure 7,

- les figures 9 et 10 montrent des exemples de fonctions s'exécutant en parallèle avec la fonction de la figure 7,

- la figure 11 montre une attribution des espaces logiques sur les espaces physiques en variante de la correspondance représentée sur la figure 6,

- la figure 12 montre une variante de la fonction de la figure 8 adaptée pour tenir compte de l'attribution de la figure 11 ,

- la figure 13 montre un exemple d'implémentation d'une partie de la figure 12,

- la figure 14 montre un exemple d'une fonction s'exécutant en parallèle avec la fonction de la figure 7, et

- la figure 15 montre une variante des figures 8 et 12 qui met en œuvre à la fois l'attribution représentée sur la figure 6 et celle représentée sur la figure 11.

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 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 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, et de créer un nœud 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 nœud applicatif, un rôle de nœud 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.

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 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. L'accès direct à l'espace de stockage 38 est géré par un client de stockage 44 et un serveur de stockage 46. Les rôles et les fonctionnements de ces éléments seront précisés plus bas.

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.

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 nœuds du réseau qui contiennent les données recherchées.

Il en est de même pour la couche de virtualisation 36, le client de stockage 44 et le serveur de stockage 46. La répartition de ces éléments est gérée au moyen d'un module d'administration 48.

Pour la suite de la description, il importe peu que les ressources considérées soient réparties ou pas.

Le module d'administration 48 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 48 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 nœud 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 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.

Comme cela apparaîtra mieux par la suite, la table de correspondance 42 ne contient pas la totalité des correspondances, mais seulement un jeu

d'informations nettement plus restreint, suffisant à rétablir extrêmement rapidement la correspondance.

Afin de mieux comprendre l'invention, il convient de bien différencier la couche applicative de la couche de stockage. En effet, la gestion de l'accès aux données stockées dans la couche de stockage est une approche qui présente de nombreux avantages par rapport à l'existant.

La figure 4 représente un procédé mis en œuvre par le système pour accéder à un fichier.

L'accès à un fichier par une application de la couche applicative d'un nœud 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é, et

- le type de requête, à savoir la lecture ou l'écriture.

Dans une étape 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, et

- le type de requête, qui est identique à celui de la requête 50.

Si l'on se rapporte au système décrit sur la figure 2, l'étape 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 "virtuelles".

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 étape 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, le fichier recherché existe déjà dans un espace de stockage 38, et le moteur 40 appelle la table de correspondance 42 avec la ou les adresses virtuelles pour déterminer par correspondance la ou les adresses physiques des données du fichier.

Dans le cadre d'une requête d'accès en écriture, le fichier n'existe pas forcément de manière préalable dans un espace de stockage 38. 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 étape 56 des requêtes d'accès physique qu'il transmet au client de stockage 44.

Dans l'étape 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'étape 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 ; et

- le type d'action visée, à savoir la lecture ou l'écriture.

L'adresse physique et la taille de la requête sont obtenues directement de l'étape 54, et le type de la requête est hérité du type de la requête d'accès virtuel concernée.

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 client de stockage 44 pour toutes les adresses physiques obtenues à l'étape 52.

En fait, chaque requête d'accès physique est placée dans une file d'attente de requête du client de stockage 44 pour exécution dans une étape 60. Le client de stockage 44 peut optionnellement comporter plusieurs files d'attente, par exemple une file d'attente par serveur de stockage 46 avec lequel il interagit.

Dans cette boucle, toutes les requêtes d'accès physique de l'étape 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.

Dans l'exemple décrit, des requêtes sont transmises de couche en couche, jusqu'à la couche d'accès physique. Il serait cependant possible de déterminer et de transmettre uniquement des adresses (virtuelles puis physiques), et de récupérer, au niveau de la couche physique, des propriétés choisies de la requête de fichier initiale pour former les requêtes d'accès physique.

Pour l'exécution d'une requête d'accès physique donnée, le client de stockage 44 interagit avec le serveur de stockage 46 de la station de stockage qui contient l'espace de stockage 38 sur lequel est située l'adresse physique désignée par la requête d'accès physique concernée.

La figure 5 représente un exemple de réalisation de la couche de virtualisation 36 de la figure 3.

Le moteur 40 comporte une file d'attente 402, une unité de détermination d'adresse 404 et une unité de recouvrement 406.

La file d'attente 402 reçoit toutes les requêtes d'accès virtuel pour la détermination des adresses physiques correspondantes. La détermination des adresses physiques est réalisée par l'unité de détermination d'adresse 404, en collaboration avec la table de correspondance 42.

Dans l'exemple décrit ici, la table de correspondance 42 ne contient qu'un jeu extrêmement restreint de données qui seront décrites par la suite. En effet, l'invention propose plusieurs schémas d'attribution d'espaces virtuels aux espaces physiques. Ces attributions permettent de déterminer rapidement et à moindre coût les correspondances adresse virtuelle / adresse physique sur la base d'algorithmes légers tout en offrant une qualité de service élevée. Cela est beaucoup plus performant en termes d'occupation processeur et mémoire que l'utilisation d'une table de correspondance directe telle une "look-up table" (en anglais).

L'unité de recouvrement 406 a pour fonction la mise à jour de certaines adresses physiques lorsqu'un espace de stockage d'une station donnée a cessé de fonctionner, comme cela sera décrit plus bas.

La figure 6 illustre un premier schéma d'attribution d'espaces virtuels aux espaces physiques de manière à tolérer des pannes dites corrélées. Par panne

corrélée, on entend une panne qui rend inopérant un ensemble d'espaces ou unités de stockage (ci-après disques) reliés entre eux (ci-après groupe de défaillance).

Dans d'autres modes de réalisation, on peut regrouper les disques par groupe de défaillance sur la base d'un critère de dépendance de panne. Un tel critère de dépendance de panne vise à rassembler entre eux des disques pour lesquels la probabilité d'une panne simultanée est importante, de manière à s'assurer que les données de ces disques ne sont pas répliquées sur l'un d'entre eux.

Comme exemple de critère de dépendance de panne, on peut citer l'appartenance à une même station-noeud, tant d'un point de vue matériel que logiciel, la liaison à un même nœud de réseau, tant d'un point de vue matériel que logiciel, la proximité de situation géographique, etc.

Pour prévenir de telles pannes, l'attribution d'espace virtuels aux espaces physiques est réalisée de sorte que :

- les données d'une adresse virtuelle sont stockées sur des disques qui appartiennent à des groupes de défaillance distincts ; et

- les données d'adresses virtuelles consécutives sont rassemblées dans des hachures qui s'étendent sur tous les disques.

Ainsi, sur l'exemple représenté, on part de quatre noeuds N1 à N4. Le nœud N1 comporte ici trois disques MU11, MU12 et MU 13, le nœud N2 trois disques MU21, MU22 et MU23, le nœud N3 un disque MU31 , et le nœud N4 trois disques MU41 , MU42 et MU43.

Dans l'exemple décrit ici, chaque nœud forme un groupe de défaillance, c'est-à- dire que, en termes de panne, on considère que les disques d'un nœud dépendent de celui-ci, mais que les disques de nœuds distincts sont indépendants les uns des autres.

Le groupe de défaillance N1 est donc composé des disques MU 11 à MU13, le groupe de défaillance N2 est composé des disques MU21 à MU23, le groupe de défaillance N3 est composé du disque MU31, et le groupe de défaillance N4 est composé des disques MU41 à MU43.

Dans d'autres modes de réalisation, on pourrait définir les groupes de défaillances de manière différente, par exemple par appartenance à une unité de réseau. Il est donc important de comprendre que les disques sont d'abord regroupés par groupe de défaillance et non seulement par nœud.

Dans un premier temps, l'attribution représentée sur la figure 6 part des groupes de défaillances pour définir des groupes de réplication qui permettent une duplication sûre des données.

L'affectation des disques des groupes de défaillance à un groupe de réplication suit un algorithme d'attribution qui met en œuvre les contraintes décrites plus haut.

Pour tenir compte de la première contrainte, il est nécessaire qu'il y ait au moins autant de groupes de réplication qu'il y a de disques dans le groupe de défaillance qui a le plus grand nombre de disques, conformément à l'équation

10 de l'Annexe A.

Ensuite, afin d'effectuer une répartition la plus souple possible en termes de charge, on fixe le nombre de disques par groupe de réplication selon l'équation

11 de l'Annexe A. Enfin, les disques sont attribués individuellement dans chaque groupe de réplication selon l'équation 12 de l'Annexe A.

Ainsi, dans l'exemple de la figure 6, le groupe de réplication GR1 comprend quatre disques qui correspondent respectivement aux disques MLM 1 , MU21 , MU31 et MU43, et les autres disques MU12 et MU13 du groupe de défaillance N1 sont respectivement affectés aux groupes GR2 et GR3.

D'autres algorithmes d'attribution des disques sont possibles, comme l'homme du métier le reconnaîtra. On notera par exemple que, pour l'attribution des disques aux groupes de réplicatipn, il serait également possible de prendre en compte l'espace disponible sur les disques, de manière à assurer des groupes de réplication de taille homogène. Une autre possibilité serait de prendre en compte leur performance pour obtenir des groupes de réplication de performance homogène.

Cela pourrait par exemple être réalisé : * lors de l'attribution des disques aux groupes de réplication, en compliquant l'algorithme, ou

^* après l'attribution décrite plus haut, en effectuant des échanges de disques entre groupes de réplication.

Dans un deuxième temps, pour tenir compte de la deuxième contrainte, les adresses virtuelles sont attribuées sur les disques triés par groupe de réplication. Dans chaque disque représenté, chaque numéro qui est représenté signifie l'association d'adresses virtuelles à des adresses physiques.

En effet, les adresses virtuelles sont réunies par ordre croissant en unités de hachurage ("striping unit" en anglais) de tailles définies. Les unités de hachurage sont elles même associées avec des adresses physiques sur les disques.

Comme on peut le voir dans la partie supérieure de la figure 6, les unités de hachurage sont affectées sur tous les disques de tous les groupes de réplication par ordre croissant, ligne par ligne. Les adresses virtuelles sont ainsi affectées par bloc aux groupes de réplication, de manière croissante.

Ainsi, la première unité de hachurage du premier disque du premier groupe de réplication reçoit l'indice 0, la première unité de hachurage du deuxième disque du premier groupe de réplication reçoit l'indice 1 , etc.

Une ligne d'unités de hachurage sera par la suite appelée hachure réelle. On remarque également dans la partie supérieure de la figure 6 que, pour une ligne sur deux, les unités de hachurage ne sont pas ordonnées par indice croissant.

Cela est du au fait que, pour tenir compte de la première contrainte, les données de chaque hachure réelle sont répliquées au sein du groupe de réplication auquel la première version est affectée. De ce fait, on associe des hachures réelles correspondantes par paires pour former à chaque fois une hachure principale.

Pour déterminer l'attribution des unités de hachurage pour la réplication, on utilise une équation qui assure que :

* deux répliques d'une même unité de hachurage ne sont pas stockées sur le même disque, et que * le décalage qui est réalisé à cet effet n'est pas constant, de sorte que lorsqu'un disque donné tombe en panne, la charge est répartie sur les autres disques.

Ainsi, dans l'exemple représenté sur la figure 6, les adresses physiques du disque MU11 de N1 reçoivent les unités de hachurage suivantes : 0, 3, 10, 12, 20, 21 , 30, 33, 40 et 42.

En outre, dans l'exemple décrit ici, les données sont répliquées sur des hachures réelles directement consécutives au sein de la hachure principale. Dans d'autres modes de réalisation, les données répliquées pourraient l'être dans des hachures réelles non consécutives.

Comme on peut le voir de ce qui précède, il suffit donc de connaître le nombre total de disques ainsi que le nombre de groupes de réplication pour déterminer une adresse physique à partir d'une adresse virtuelle.

La table de correspondance 42 est donc réduite à sa plus simple expression. On notera par ailleurs que, du fait de la réplication de données mentionnée plus haut, il y a deux fois plus d'adresses physiques que d'adresses virtuelles.

Dans l'exemple présenté sur la figure 6, ainsi que dans la suite de ce document, on réalise une réplication simple des données, ce qui a pour résultat de doubler la quantité de données stockées. Cependant, il serait possible de réaliser plus de deux répliques des données.

La figure 7 montre l'exemple d'une fonction qui permet de retrouver une adresse physique à partir d'une adresse virtuelle.

Dans l'exemple décrit ici, cette fonction est implémentée dans l'unité de détermination d'adresse 404. Elle part dans une opération 2000 d'une adresse virtuelle, par exemple tirée de la file d'attente 402.

Dans une opération 2020, un test est réalisé pour déterminer si l'adresse virtuelle est reliée à une requête en écriture. Si c'est le cas, dans une opération 2040, un test est réalisé pour déterminer si le système est en état dégradé, c'est-à-dire si l'un des disques est en panne. Si c'est le cas, une fonction Wrt_Drt_Z() est appelée en 2060.

Les opérations 2040, 2060 et 2080 sont reliées à des fonctions permettant la récupération rapide d'une panne de disque qui sera décrite plus avant avec les figures 9 et 10.

Dans le cas où la requête associée à l'adresse virtuelle est une requête de lecture, ou lorsque l'état du système est non dégradé, ou encore lorsque la fonction Wrt_Drt_Z() s'achève, une fonction SU_lnd() est appelée dans une opération 2070.

La fonction SUJ nd() part de l'adresse virtuelle dont on cherche la correspondance, et retourne l'indice d'unité de hachurage SU Ind. qui lui est associé. Cela est aisément réalisable comme la taille de chaque unité de hachurage est connue.

Sur la base de cet indice, une fonction Get_Phy_lnd() est appelée dans une opération 2080 qui détermine des indices d'adresses physiques correspondants.

Enfin, dans une opération 2100, les indices d'adresses physiques sont convertis en adresses physiques par une fonction Phy_Ad(). Cela est aisément réalisable comme la taille de chaque unité de hachurage est connue.

La fonction Get_Phy_lnd() va maintenant être décrite avec la figure 8. La fonction Get_Phy_lnd() reçoit les deux arguments suivants (opération 2082) :

^* l'indice de l'unité de hachurage dont on cherche la correspondance, et

* un tableau Ngr[] contenant une ligne dont les valeurs indiquent le nombre de disques pour chaque groupe de réplication.

Le tableau Ngr[] est utile car il permet de retrouver rapidement le nombre total de disques N et le nombre de groupe de réplication Ngr, et d'accéder tout aussi rapidement au nombre de disques par groupe de réplication.

Dans une autre implémentation, il est possible de passer directement N et Ngr en tant qu'arguments, mais un calcul est alors nécessaire lorsque l'on a besoin du nombre de disques au sein d'un groupe de réplication donné.

Le rôle de la fonction Get_Phy_lnd() est de retrouver l'indice de l'unité de hachurage dans le tri par groupe de défaillance à partir de son indice dans le tri par groupe de réplication. Dans une première opération 2084, une fonction

StripQ détermine un indice de hachure principale k, ainsi que l'indice m1 dans

les groupes de réplication du premier disque sur lequel l'adresse virtuelle est stockée. Cela est réalisé en appliquant les équations 20 et 21 de l'Annexe A.

Dans une opération 2086, une fonction Repl() détermine les indices de hachure réelle k1 et k2 pour tenir compte de la réplication des données. Cela est réalisé en appliquant les équations 22 et 23 de l'Annexe A.

Dans une opération 2088, une fonction Spl() détermine l'indice p du groupe de réplication qui correspond à l'indice de disque m1 , ainsi que l'indice q1 du disque m1 au sein de ce groupe de réplication. Cela est réalisé en appliquant les équations 24 et 25 de l'Annexe A.

Dans une opération 2090, une fonction Shft() détermine un indice q2 au sein du groupe de réplication d'indice p du disque sur lequel les données répliquées sont stockées. Cela est réalisé en appliquant l'équation 26 de l'Annexe A.

D'autres équations seraient bien évidemment utilisables, comme un simple décalage d'indice d'unité de hachurage. Dans ce cas plus simple, chaque disque au sein d'un groupe de réplication contient toutes les données répliquées d'un autre disque du même groupe.

Dans une opération 2097, une fonction Mrg() détermine un indice de disque m2 qui correspond à l'indice q2 au sein du groupe de réplication d'indice p. Cela est réalisé en appliquant l'équation 27 de l'Annexe A.

Dans une opération 2098, les indices m1 et m2 des disques classés par groupe de réplication sont convertis en indices de disques ni et n2 des disques classés par groupe de défaillance par une fonction Get_Dsk_lnd(). Cette fonction réalise l'opération inverse de l'équation 12 et applique les équations 28 et 29 de l'Annexe A.

Enfin, la fonction Get_Phy_lnd() retourne les indices adresses physiques déterminées dans une opération 2099.

Maintenant, la fonction Wrt_Drt_Z() va être décrite en rapport avec les figures 9 et 10. Comme mentionné plus haut, l'invention repose en partie sur la réplication des données en cas de panne. La fonction Wrt_Drt_Z() ainsi que la fonction décrite avec la figure 9 permettent une réintégration rapide d'un disque après une panne. Cette réintégration est décrite avec la figure 10.

Le principe de cette réintégration repose sur le marquage des zones virtuelles associées à un disque en panne lors d'une écriture.

En effet, aussi bien lors d'une requête en lecture que lors d'une absence d'accès, les données stockées ne sont pas modifiées. Dès lors, lorsqu'un disque revient d'une panne, il n'est pas nécessaire de mettre à jour ces données puisqu'elles n'ont pas été modifiées.

En revanche, s'il y a eu écriture, les données stockées sont potentiellement distinctes, et il faut rétablir la cohérence avec la version des données qui a subi l'écriture.

Pour cela, deux tables sont maintenues pendant l'exécution. La première table, dite de pannes, contient deux lignes, dont l'une reçoit des identifiants de disques et l'autre reçoit un indice croissant. La deuxième table, dite de zones, contient deux lignes, dont l'une reçoit des identifiants de zones, et l'autre reçoit un indice de modification.

Dans l'exemple décrit ici, la table de pannes est stockée sur chacun des disques dans un espace réservé par le module d'administration qui n'est pas utilisable pour le stockage des données. Cette table est maintenue cohérente sur l'ensemble des disques par le module d'administration. Cette table a une

taille fixée égale au nombre total de disques. La table de pannes est remplie au moyen de la fonction représentée sur la figure 9.

Ainsi, lorsqu'une panne est détectée, par exemple par le module d'administration 48 (opération 2200), cette fonction reçoit les identifiants de tous les disques en panne.

Dans une opération 2202, une fonction ls_Tgd_Dsk() cherche chacun des identifiants de disque en panne dans la table de pannes.

Pour chaque identifiant absent, la table de pannes crée une nouvelle entrée qui reçoit l'identifiant de disque dans la première ligne, et un indice incrémenté dans la seconde ligne (opération 2204). Sinon la fonction traite l'identifiant suivant (opération 2206).

En variante, la table de pannes est implémentée sous la forme d'une pile ou d'une liste chaînée. Dès lors, elle ne comporte qu'une ligne qui reçoit les indices de disques, et c'est l'indice de position de chaque identifiant dans la table qui sert d'indice croissant.

La fonction Wrt_Drt_Z() se base sur les indices de la table de pannes pour maintenir une vue à jour des zones associées à un disque en panne qui ont été modifiées.

Ainsi, comme on l'a vu plus haut, la fonction Wrt_Drt_Z() est appelée pour chaque requête en écriture, et elle a pour fonction de marquer dans la table de zones l'indice le plus élevé de la table de pannes.

Ainsi, lorsqu'une zone a un indice supérieur ou égal à celui d'un disque de la table de pannes, cela signifie que celle-ci a été modifiée après la panne du disque considéré.

Sur cette base, l'unité de recouvrement 406 peut exécuter la fonction de la figure 10 pour rétablir un disque après une panne. Pour cela, l'unité 406 part d'un indice i mis à zéro (opération 2300) et parcourt la table de zones.

A chaque fois, une comparaison entre l'indice associé au disque qu'on rétablit dans la table de pannes et celui de la zone d'indice i dans la table de zones indique si la zone a été modifiée après la panne du disque considéré (opération 2302).

Si oui, alors une fonction Upd_Z(i) met à jour les données de la zone concernée en récupérant les données répliquées qui lui correspondent (opération 2304). Ensuite, la table de zones est mise à jour pour refléter cette opération (2306).

Une fois la zone d'indice i à jour, une fonction End_Drt_Zone() supprime l'entrée de la table de pannes associée au disque rétabli, et parcourt la table de pannes pour majorer l'indice des zones par le maximum des indices restants. Cela assure une croissance lente des indices et évite de traiter des données trop grandes.

S'il reste des zones à parcourir, l'indice i est incrémenté (opération 2310). Sinon, la fonction se termine dans l'opération 2312.

On notera que la table de zones peut recevoir des zones de taille paramétrable. En effet, une entrée dans la table de zones est associée à une pluralité d'adresses virtuelles contiguës.

Dans le mode de réalisation décrit ici, cette table est stockée dans la zone des données réservées du volume logique auxquelles appartiennent les adresses virtuelles, c'est-à-dire qu'elle est également répartie sur tous les disques.

On notera que la zone des données réservées du volume logique n'est pas extensible indéfiniment. On notera également que l'appel à la table de zones constitue une requête en lecture dans le système.

II est donc nécessaire de trouver un compromis entre la granularité des données de la table de zones (qui augmente la performance du mécanisme de recouvrement), et le coût qui est associé à la multiplication des requêtes (qui augmente avec la granularité).

On peut voir les fonctions décrites avec les figures 9 et 10 comme des fonctions qui bouclent en parallèle avec l'exécution principale du système. En effet, pour assurer une sécurité maximale des informations, ces fonctions constituent des "interruptions".

Cela signifie que si la condition de leur lancement (disque qui tombe en panne ou disque qui est rétabli) est rencontrée, les requêtes de détermination d'adresse physique en cours d'exécution sont annulées et rejouées après exécution de ces fonctions.

Ces fonctions peuvent donc être réalisées directement dans la couche de virtualisation ou dans le module d'administration, en tant que fonctions séparées comme cela est présenté ici, ou en tant que partie intégrante des fonctions présentées plus haut.

La figure 11 représente une attribution des espaces virtuels aux espaces physiques en variante de celui de la figure 6. Ici, la tolérance aux pannes est également accrue, cette fois laissant volontairement des espaces libres au sein des groupes de réplication appelés unités de résilience.

Pour des raisons de clarté, on a représenté sur cette figure un seul groupe de réplication qui comprend sept disques. Parmi ces sept disques, on va définir

des hachures comprenant quatre unités de hachurage pour le stockage des données, et trois unités de résilience pour la tolérance des pannes.

Comme on le voit sur la figure 11 , les données sont toujours répliquées une fois, selon la même méthode que précédemment, mais il existe également un décalage avec chaque hachure. Ce décalage sert à assurer que tous les espaces laissés libres sont répartis sur l'ensemble des disques, ce qui garantit un meilleur équilibrage de la charge.

Comme pour les unités de hachurage, deux adresses physiques sont associées sur les disques à chaque unité de résilience SpO, Sp1 et Sp2. Sur la figure 11 , les adresses physiques associées à la même unité de résilience dans une hachure principale donnée sont référencées de manière identique.

Pour la détermination d'adresse physique avec l'attribution décrite avec la figure 11 , la fonction décrite avec la figure 7 reste utilisable, moyennant quelques modifications à la fonction Get_Phy_lnd().

Une telle fonction Get_Phy_lnd() en variante va maintenant être décrite avec la figure 12. On notera tout d'abord la différence de contexte entre l'attribution présentée sur la figure 6 et celle présentée sur la figure 11.

Dans le premier cas, les disques sont répartis en plusieurs groupes pour éviter les pannes corrélées, c'est-à-dire affectant plusieurs disques à la fois.

Dans le deuxième cas, certaines des unités de hachurage sont utilisées comme espace libre pour palier à une panne d'un ou plusieurs des disques, comme cela apparaîtra mieux plus bas.

II n'y alors pas a priori de regroupement des disques par groupe de réplication, bien que cela soit possible comme on le verra avec la figure 15.

La définition des unités de résilience en plus des unités de hachurage revient à répartir une partie des adresses physiques en un groupe de travail (celles qui reçoivent les données des unités de hachurage) d'une part, et en des groupes de panne (celles qui reçoivent les données des unités de résilience) d'autre part, en fonction d'un critère de tolérance de panne.

Un tel critère de tolérance de panne porte par exemple sur le nombre de pannes successives que l'on souhaite supporter, et donc le nombre de groupes de panne à gérer. Dans l'exemple présent, ce nombre est de trois. D'autres critères pourraient néanmoins être employés.

Dans l'exemple de la figure 12, la fonction Get_Phy_lnd () peut être vue comme deux blocs successifs :

* un bloc de traitement A pour déterminer les indices de disque et de hachure comme précédemment, sans tenir compte de la présence des unités de résilience, et

^* un bloc B qui traite les indices ainsi calculés pour tenir compte de la présence des unités de résilience et obtenir les indices réels.

La fonction Get_Phy_lnd() reçoit les trois arguments suivants (opération 2482) :

^* l'indice de l'unité de hachurage dont on cherche la correspondance,

^* le nombre de disques dans le système, et

^* le nombre d'unités de résilience.

Dans une première opération 2484, la fonction Strip() détermine un indice de hachure principal k, ainsi que l'indice mm1 du premier disque sur lequel l'adresse virtuelle est stockée.

L'opération 2484 diffère de l'opération 2084 de la figure 8 en ce que la fonction Strip() est appelée avec le nombre d'unités de hachurage, c'est-à-dire le nombre de disques moins le nombre d'unités de résilience.

Dans une opération 2486, la fonction Repl() détermine les indices de hachure réels k1 et k2 pour tenir compte de la réplication des données comme l'opération 2086.

Dans une opération 2490, la fonction Shft() détermine un indice mm2 du disque qui reçoit les données répliquées. L'opération 2490 diffère de l'opération 2090 de la figure 8 en ce que la fonction Shft() est appelée avec le nombre d'unités de hachurage, c'est-à-dire le nombre de disques moins le nombre d'unités de résilience.

Dans une opération 2492, une fonction Cp_Spr() détermine un indice m1 qui correspond à l'indice réel du disque associé à l'indice mm1. Cette fonction sert à modifier l'indice mm1 pour tenir compte de la présence des unités de résilience. Comme on le verra plus bas, l'indice m1 que retourne la fonction Cp_Spr() peut être un indice d'une unité de résilience.

Dans une opération 2494, une fonction Cp_Spr() détermine un indice m2 qui correspond à l'indice réel du disque associé à l'indice mm2. Cette fonction sert à modifier l'indice mm2 pour tenir compte de la présence des unités de résilience. Comme on le verra plus bas, l'indice m2 que retourne la fonction Cp_Spr() peut être un indice d'une unité de résilience.

Une fois les indices m1 et m2 déterminés, les indices d'adresses physiques sont retournés en 2499.

La fonction Cp_Spr() va maintenant être décrite avec la figure 13. Cette fonction reçoit comme arguments un indice de disque mm, un indice d'unité de hachurage k, un nombre total de disques N et un nombre d'unités de résilience S. La fonction Cp_Spr() commence par exécuter une fonction Spr() en 2602.

La fonction Spr() implémente l'équation 30 de l'Annexe A. La fonction Spr() reçoit trois arguments en entrée :

* l'indice de disque mm,

* l'indice d'unité de hachurage k ;

^* le nombre total de disques N.

Comme l'indice mm a été établi sur un nombre N-S de disques, la fonction Spr() permet donc d'établir un indice m qui prend en compte la présence des S unités de résilience.

Ensuite, un test détermine dans une opération 2604 si le disque associé à l'indice réel m est en panne et si une unité de résilience lui a été affectée.

Un exemple de mise en œuvre de la fonction 2604 est la tenue d'une table appelée ici table de résilience. Cette table contient une unique ligne, dans laquelle chaque colonne correspond à un disque d'indice m correspondant au numéro de la colonne.

La valeur stockée dans chaque colonne indique :

^* que le disque d'indice m n'est pas en panne, ou

* que le disque d'indice m est en panne, et la valeur stockée est alors un indice d'unité de résilience qui permet de déterminer l'indice du disque auquel est attribuée l'unité de résilience qui sera associée au disque d'indice m.

Une telle table de résilience est stockée sur chacun des disques et est synchronisée en permanence, en même temps que la table de pannes par exemple.

S'il faut utiliser une unité de résilience, alors l'indice mm est mis à jour dans une opération 2606 par une fonction Spr_2() qui implémente l'équation 31 de l'Annexe A en utilisant comme arguments le nombre total de disques N, le nombre d'unité de résilience S, et l'indice m qui vient d'être calculé.

Cette fonction part du principe que les données du disque d'indice m sont stockées dans chaque hachure sur l'unité de résilience dont l'indice de résilience est indiqué par la table de résilience, et qu'il suffit donc de connaître l'indice de hachure k pour déterminer l'indice du disque sur lequel l'unité de résilience voulue est attribuée.

Pour cela, après la mise à jour de l'indice mm, la fonction Cp_Spr() est relancée. Ainsi, dans le cas où deux pannes ont lieu successivement, si l'unité de résilience associée à l'un des disques en panne est située sur le deuxième disque en panne, la fonction Cp_Spr() est à nouveau répétée, de sorte que l'indice retourné correspond à une unité de résilience sur un disque fonctionnel.

De cette manière, de multiples pannes peuvent être tolérées, comme les unités de résilience peuvent être utilisées pour remplacer d'autres unités de résilience. Pour maintenir la table de résilience, et pour remplir les adresses physiques associées aux unités de résilience lors d'une panne, une fonction va maintenant être décrite avec la figure 14.

Lorsque le système détecte qu'un disque tombe en panne (opération 2700), cette fonction reçoit les identifiants de tous les disques en panne.

Dans une opération 2702, une fonction Spr_Dsk() modifie l'indice du disque en panne auquel n'est associée aucune unité de résilience. La valeur de son indice de résilience reçoit le premier indice de résilience non déjà attribué.

Ensuite, dans une opération 2704, les données répliquées des unités de hachurage qui étaient situées sur le disque qui est tombé en panne sont recopiées sur les unités de résilience associées au moyen d'une fonction Wrt_Spr_Dsk().

Pour améliorer la performance, la recopie n'est pas immédiatement réalisée : la fonction Wrt_Spr_Dsk() génère des requêtes d'écriture des données

disponibles sur l'unité de hachurage restante vers l'unité de résilience, et ces requêtes sont exécutées en concurrence avec les autres requêtes d'accès. Cela signifie que l'unité de résilience ne peut pas être utilisée tant que cette requête d'écriture n'a pas été réalisée. Enfin, la fonction se termine en 2706.

En variante, la fonction Wrt_Spr_Dsk() génère les requêtes d'écriture sur les unités de résilience et exécute ces requêtes avant toute autre requête d'accès.

On notera que, lorsque le disque est rétabli, il faut également recopier à nouveau les données répliquées sur celui-ci.

On peut voir la fonction décrite avec la figure 14 comme une fonction qui boucle en parallèle avec l'exécution principale du système. En effet, pour assurer une sécurité maximale des informations, cette fonction constitue une "interruption"

Cela signifie que si la condition de son lancement (disque qui tombe en panne) est rencontrée, les requêtes de détermination d'adresse physique en cours d'exécution sont annulées et rejouées après exécution de cette fonction.

Cette fonction peut donc être réalisée directement dans la couche de virtualisation ou dans le module d'administration, en tant que fonction séparée comme cela est présenté ici, ou en tant que partie intégrante des fonctions présentées plus haut.

Dans un mode de réalisation avantageux, l'attribution décrite avec la figure 6 et celle décrite avec la figure 11 sont mélangées, pour offrir un support de panne optimal.

Pour la détermination d'adresse physique avec une telle attribution, la fonction décrite avec la figure 7 reste utilisable, moyennant quelques modifications à la fonction Get_Phy_lnd().

Une telle fonction Get_Phy_lnd() en variante va maintenant être décrite avec la figure 15.

La fonction représentée sur la figure 15 est un mélange des variantes de la fonction Get_Phy_lnd() décrite avec les figures 8 et 12. Ainsi, elle présente de grandes similitudes avec celles-ci. C'est pourquoi certaines opérations n'ont pas été renumérotées.

Dans une opération 2482, la fonction Get_Phy_lnd() reçoit les arguments suivants :

^* l'indice de l'unité de hachurage dont on cherche la correspondance,

^* un tableau Ngr[] contenant une ligne dont les valeurs indiquent le nombre de disques pour chaque groupe de réplication, et

^* le nombre d'unités de résilience.

Comme pour la figure 8, le tableau Ngr[] est utile car il permet de retrouver rapidement le nombre total de disques N et le nombre de groupe de réplication Ngr, et d'accéder tout aussi rapidement au nombre de disques par groupe de réplication.

Dans une autre implémentation, il est possible de passer directement N et Ngr en tant qu'arguments, mais un calcul est alors nécessaire lorsque l'on a besoin du nombre de disques au sein d'un groupe de réplication donné.

Les opérations 2484 et 2486 sont ensuite réalisées de manière identique à celles de la figure 12, et l'opération 2488 est réalisée comme l'opération 2088 de la figure 8.

Ensuite, les opérations 2490 à 2494 sont réalisées comme dans le cas de la figure 12, en tenant compte du fait que cette opération est réalisée au sein d'un groupe de réplication.

Les indices des disques q1 et q2 au sein du groupe de réplication p sont ensuite transformés en indices de disque m1 et m2 dans des opérations 2496 et 2497 de manière analogue à l'opération 2097 de la figure 8.

Ensuite les indices m1 et m2 des disques classés par groupe de réplication sont convertis en indices de disques ni et n2 des disques classés par groupe de défaillance dans une opération 2498 comme l'opération 2098 de la figure 8.

Enfin, l'opération 2499 est réalisée comme l'opération 2099 de la figure 8, afin de retourner les indices d'adresses physiques.

Ce mode de réalisation est le mode de réalisation est très avantageux, car il offre une très grande tolérance aux diverses pannes, tant grâce à la répartition des données sur des disques appartenant à des groupes de défaillance distincts que grâce à l'utilisation des unités de résilience qui permet de contenir des pannes au sein des groupes de réplication.

En outre, la répartition par hachures décrite dans les modes décrits permet d'obtenir des performances très améliorées, comme les accès sont répartis sur des disques distincts.

Les unités de hachurage sont ici décrites comme ayant une taille fixe. Il serait néanmoins possible d'implémenter l'invention en affectant des tailles d'unités de hachurage différentes selon les groupes de réplication moyennant quelques modifications aux fonctions décrites.

Le moteur et la table de correspondance décrits ici forment un module de correspondance capable d'affecter les adresses virtuelles à des adresses physiques sur la base d'une règle comportant une formule arithmétique définie par les fonctions ci-dessus.

Bien que dans les modes de réalisation décrits plus haut ces fonctions constituent l'essentiel de la règle d'affectation, il serait possible d'utiliser une règle qui affecte de manière fixe une certaine partie des adresses virtuelles, et qui affecte une autre partie des adresses virtuelles avec les fonctions.

Bien que les modes de réalisations décrits ci-dessus lient la couche de virtualisation à un environnement applicatif en amont et à des disques physiques (ou unité de mémoires locales) en aval, l'homme du métier comprendra bien que la couche de virtualisation présentée ici pourrait être isolée de ces éléments.

Il faut donc envisager cette couche de manière indépendante, comme une brique logique (de virtualisation) au dessus et en dessous de laquelle peuvent être empilées des briques logiques supplémentaires.

Dans ce cadre, l'obtention d'adresses qui sont qualifiées "d'adresse physique" signifie avant tout une désabstraction de la couche de virtualisation. Ces adresses pourraient en effet être elles mêmes des adresses virtuelles d'un espace logique d'un serveur de stockage. De la même façon, les adresses virtuelles reçues en amont pourraient elles même correspondre à une désabstraction d'une couche de virtualisation supérieure.

L'application qui accède aux données stockées peut comporter un pilote qui gère les relations entre les divers éléments telle l'interaction application - système de fichiers, l'interaction système de fichiers - module de correspondance, l'interaction module de correspondance - client de stockage, implémentation de la stratégie du serveur de stockage en obtenant de chaque élément un résultat et en appelant l'élément suivant avec ce résultat (ou une forme modifiée de ce résultat).

En variante, le système est autonome et ne dépend pas de l'application qui appelle les données, et les éléments sont capables de communiquer entre eux,

de sorte que l'information descend puis remonte les couches d'élément en élément.

De même, les communications entre ces éléments peuvent être assurées de différentes manières, par exemple au moyen de l'interface POSIX, des protocoles IP ₁ TCP, UDP, d'une mémoire partagée, d'une RDMA (Remote Direct Access Memory). Il convient de garder à l'esprit que le but de l'invention est d'offrir les avantages de systèmes de stockage spécialisés sur la base des ressources réseaux existantes.

Un exemple de réalisation du système décrit ci-dessus est basé sur un réseau dans lequel les stations sont réalisées avec des ordinateurs comprenant :

* un processeur spécialisé ou généraliste (par exemple du type CISC ou RISC ou autre), * un ou plusieurs disques de stockage (par exemple des disques durs à interface Sériai ATA, ou SCSI, ou autre) ou tout autre type de stockage, et

* une interface réseau (par exemple Gigabit, Ethernet, Infiniband, SCI...)

* un environnement d'application basé sur un système d'exploitation (par exemple Linux) pour supporter des applications et offrir un gestionnaire de système de fichiers,

* un ensemble applicatif pour réaliser le module de correspondance, par exemple le module Clustered Logical Volume Manager de l'application Exanodes (marque déposée) de la société Seanodes (marque déposée),

* un ensemble applicatif pour réaliser le client de stockage et le serveur de stockage de chaque NBD, par exemple le module Exanodes Network Block

Device de l'application Exanodes (marque déposée) de la société Seanodes (marque déposée),

* un ensemble applicatif pour gérer les éléments répartis, par exemple le module Exanodes Clustered Service Manager de l'application Exanodes (marque déposée) de la société Seanodes (marque déposée).

Ce type de système peut être réalisé dans un réseau comportant :

* des stations utilisateurs classiques, adaptées à un usage applicatif sur un réseau et qui jouent le rôle de nœuds applicatifs, et

^* un ensemble de dispositifs informatiques réalisés conformément à ce qui précède, et qui jouent le rôle de serveurs du réseau et de nœuds de stockage.

D'autres matériels et applications apparaîtront à l'homme du métier pour réaliser des dispositifs en variante dans le cadre de l'invention.

L'invention englobe le système informatique comprenant les nœuds applicatifs et les nœuds stockant dans leur ensemble. Elle englobe également les éléments individuels de ce système informatique, et notamment les nœuds applicatifs et les nœuds stockants dans leur individualité, ainsi que les divers moyens pour les réaliser.

De même, le procédé de gestion de données est à considérer dans sa globalité, c'est-à-dire dans l'interaction des nœuds applicatifs et des nœuds stockants, mais également dans l'individualité des postes informatiques adaptés pour réaliser les nœuds applicatifs et les nœuds stockants de ce procédé.

La description qui précède a pour but de décrire un mode de réalisation particulier de l'invention. Elle ne saurait être considérée comme limitant ou décrivant celle-ci de manière limitative, et couvre notamment l'ensemble des combinaisons entre elles des caractéristiques des variantes décrites.

L'invention couvre également un procédé de stockage de données comprenant la détermination d'au moins une première et une deuxième adresses de stockage à partir d'une adresse virtuelle reçue en entrée, les adresses de stockages étant associées à des unités de stockage, et le stockage de données associées à ladite adresse virtuelle dans lesdites première et deuxième adresses de stockages déterminées, le procédé étant caractérisé en ce que :

* une première table comprenant des données d'identification d'unités de stockage en panne, ainsi qu'une deuxième table comprenant des données de modification de blocs d'adresses virtuelles sont maintenues, et

* au rétablissement d'une unité de stockage tombée en panne, les adresses de stockage de cette unité de stockage sont mises à jour à partir d'adresses virtuelles tirées de la deuxième table, sur la base des données de la première table.

Le procédé peut être en outre caractérisé en ce que : * à la modification d'une adresse virtuelle, la deuxième table stocke un indice pour le bloc d'adresses virtuelles auquel cette adresse appartient, ledit indice étant défini pour indiquer la postériorité par rapport à la panne la plus récente indiquée dans la première table ;

* au rétablissement d'une unité de stockage, les adresses de stockage de cette unité de stockage qui correspondent dans le module de correspondance à des adresses virtuelles qui appartiennent à des blocs d'adresses virtuelles dont l'indice dans la deuxième table indique une postériorité par rapport à l'indice de l'unité de stockage rétablie dans la première table sont mises à jour ;

* lors d'une panne d'une unité de stockage, la première table stocke un indice pour cette unité de stockage, ledit indice étant défini supérieur aux indices déjà définis dans la première table ;

^* à la modification d'une adresse virtuelle, la deuxième table stocke un indice pour le bloc d'adresses virtuelles auquel cette adresse appartient, ledit indice étant défini égal au maximum des indices définis dans la première table lors de la modification ;

* au rétablissement d'une unité de stockage, les adresses de stockage de cette unité de stockage qui correspondent dans le module de correspondance à des adresses virtuelles qui appartiennent à des blocs d'adresses virtuelles dont l'indice dans la deuxième table est supérieur ou égal à l'indice de l'unité de stockage rétablie dans la première table sont mises à jour ; et

^* lorsque les adresses de stockage d'une unité de stockage rétablie ont été mises à jour, la première table est mise à jour en effaçant l'indice correspondant

à l'unité de stockage rétablie, et la deuxième table est mise à jour en définissant les indices de la deuxième table qui sont supérieurs au maximum des indices définis dans la première table mise à jour comme égaux à ce maximum.

L'invention couvre également, en tant que produits, les éléments logiciels décrits, mis à disposition sous tout "médium" (support) lisible par ordinateur. L'expression "médium lisible par ordinateur" comprend les supports de stockage de données, magnétiques, optiques et/ou électroniques, aussi bien qu'un support ou véhicule de transmission, comme un signal analogique ou numérique.

ANNEXE A

SECTION 1

SECTION 2

ANNEXE A (suite)

SECTION 2 (suite)

SECTION 3