FR 2907993 A1 20080502 FR 0609406 A 20061026 SEANODES1.FRD 1 Système informatique 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. 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). 15 L'utilisation de ces systèmes perfectionnés présente certains désavantages, comme les coûts associés, les limitations de performance et d'extensibilité, et la lourdeur générale de l'installation qui leur correspond. Par ailleurs, avec les réseaux modernes, l'utilisation de ces systèmes 20 perfectionnés représente une sous utilisation du matériel déjà présent dans le réseau. L'invention vise à améliorer la situation. 25 À cet effet, l'invention propose un système informatique comprenant plusieurs postes informatiques dits noeuds interconnectés en un réseau. Certains au moins des noeuds, dits stockants, comprennent au moins une unité de mémoire locale à accès direct, et un serveur de stockage agencé pour gérer l'accès à cette unité de mémoire locale sur la base d'une file d'attente de requêtes 30 d'accès. Certains au moins des noeuds, dits applicatifs, comprennent chacun : 2907993 * un environnement d'application muni : - d'un gestionnaire de système de fichiers, agencé pour maintenir une représentation de fichiers accessibles depuis ce noeud sous forme d'adresses 5 virtuelles, et - d'un module de correspondance, capable de maintenir une correspondance entre chaque adresse virtuelle et au moins une adresse physique sur une unité de mémoire locale d'un noeud stockant, et * un client de stockage capable d'interagir avec l'un quelconque des serveurs de stockage, sur la base d'une requête d'accès désignant une adresse physique. 15 Dans ce système informatique, au moins l'un des serveurs de stockage est agencé pour exécuter les requêtes d'accès contenues dans sa file d'attente dans un ordre déterminé en fonction d'un jeu de règles formant critères de performance, et impliquant un ou plusieurs paramètres d'état de la ou des unités de mémoire locale. 20 Un tel système informatique présente l'avantage d'utiliser les ressources de stockage intrinsèques des stations (qui seront également appelées noeuds) du réseau afin de stocker de manière efficace les données. Dans ces stations, le serveur de stockage peut être utilisé pour optimiser l'utilisation du réseau et des 25 ressources de stockage. Ce système permet ainsi de faire un usage maximal des capacités intrinsèques du réseau sans faire usage de systèmes spécialisés. L'invention concerne également un procédé de gestion de données, applicable 30 dans un réseau comprenant plusieurs postes informatiques interconnectés, dits noeuds, comportant les étapes suivantes : 2 2907993 3 a. émettre une requête de fichier depuis un noeud applicatif du réseau, sur la base d'une représentation sous forme d'adresses virtuelles, b. sur la base d'une correspondance entre chaque adresse virtuelle et au moins 5 une adresse physique sur une unité de mémoire locale d'un noeud stockant du réseau, déterminer au moins une adresse physique correspondant à ladite adresse virtuelle, c. émettre une requête d'accès désignant ladite adresse physique vers un 10 serveur de stockage gérant l'accès à son unité de mémoire locale, et d. placer la requête d'accès dans une file d'attente dudit serveur de stockage, et exécuter les requêtes d'accès contenues dans ladite file d'attente, dans un ordre déterminé en fonction de d'un jeu de règles formant critères de performance, et impliquant un ou plusieurs paramètres d'état de la ou des unités de mémoire locale et/ou du noeud stockant concerné (charge processeur, occupation de la mémoire centrale, etc..). D'autres avantages et caractéristiques de l'invention apparaîtront mieux à la 20 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, 25 30 2907993 4 - la figure 5 montre un exemple d'implémentation fonctionnelle d'une partie du procédé de la figure 4, la figure 6 montre un exemple d'une boucle d'ordonnancement et d'exécution 5 dans un serveur de stockage dans le cadre de l'implémentation de la figure 5, - les figures 7 à 10 montrent des exemples de fonctions de la figure 6. Les dessins et la description ci-après contiennent, pour l'essentiel, des 10 é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 15 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. 2907993 5 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 NI, 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 5 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 physiquement dans un espace de stockage virtuel 24 qui est réparti sur 10 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 15 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 NI, N2 et N3, l'espace logique privé 28 20 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 25 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 30 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. 2907993 6 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 5 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 noeud dédié au stockage ou un noeud dédié à des applications. 20 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. L'ensemble des ressources applicatives, de stockage et de système de fichiers 25 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 NI, N2 et N3, dont les ressources sont intégralement réparties, tant au niveau applicatif qu'au niveau du système de 30 fichiers et du stockage. 10 15 2907993 7 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 NI, N2 ou N3. 5 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. 10 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. 15 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 20 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. II en est de même pour la couche de virtualisation 36, le client de stockage 44 25 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. 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 30 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 2907993 8 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 5 fichiers et les adresses virtuelles des données qui composent ce fichier sont réalisée au niveau du système de fichiers qui exploite cet espace logique, les données "physiques" étant stockées dans les 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. 10 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 15 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 20 remplies. Le travail accompli par la couche de virtualisation peut être réalisé de différentes manières. Dans un exemple de réalisation, la couche de virtualisation distribue les données sur les ressources de stockage hétérogènes 25 pour trouver le meilleur compromis entre l'exploitation du débit des ressources de stockage du réseau, et l'exploitation de capacité de stockage de ces ressources. Un exemple de cette couche de virtualisation est décrit dans les paragraphes [0046] à [0062] du brevet EP 1 454 269 B1. 30 La couche de virtualisation 36 peut également incorporer un mécanisme de sauvegarde des données écrites. Ce mécanisme peut par exemple reposer sur une duplication sélective de chaque requête en écriture avec des adresses 2907993 9 physiques situées sur des espaces de stockages physiques situés sur des stations distinctes, à la manière d'un RAID. La table de correspondance 42 n'est pas nécessairement un simple tableau. 5 Elle peut notamment contenir des informations de configuration concernant le ou les espaces logiques dont elle maintient les correspondances. Dans ce cas, elle peut notamment interagir avec des mécanismes de la couche de virtualisation 36 qui pour mettre à jour la répartition des correspondances adresses virtuelles / adresses physiques afin d'assurer le meilleur compromis 10 entre l'exploitation du débit des ressources de stockage du réseau, et l'exploitation de capacité de stockage de ces ressources. Un exemple de réalisation de ces mécanismes est décrit dans les paragraphes [0063] à [0075] du brevet EP 1 454 269 B1. 15 Pour la suite de la description, il importe peu que les ressources considérées soient réparties ou pas. 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 20 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 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 : 30 - un identifiant du fichier concerné pour le système de fichiers et une adresse dans ce fichier, 25 2907993 10 - 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. 10 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 15 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 à 20 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 25 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. 30 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. 5 2907993 11 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à 5 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 10 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. 15 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. 20 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 : 25 - 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 30 - le type d'action visée, à savoir la lecture ou l'écriture. 2907993 12 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. 5 Une boucle est alors lancée, dans laquelle une condition d'arrêt 58 est atteinte lorsqu'une requête d'accès physique à é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 10 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 15 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, 20 jusqu'à la couche d'accès physique. II 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. 25 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. Cette interaction sera précisée au moyen de la figure 5. 30 Comme on peut le voir sur la figure 5, l'exécution d'une requête d'accès physique par un client de stockage 44 comprend d'abord la réception de la 2907993 13 requête d'accès physique par le serveur de stockage 46 considéré. Cette réception est ici réalisée sous la forme de l'envoi d'un en-tête ou "header" 62 qui indique au serveur de stockage 46 le type de requête, la taille de cette requête, et l'adresse physique qui sont visés. 5 La requête via son en-tête est alors stockée dans une file d'attente 64 du serveur de stockage 46. La file d'attente 64 comprend l'ensemble des requêtes d'accès non encore exécutées envoyées par l'ensemble des clients de stockage 44 au serveur de stockage 46 en question, ainsi que leur état 10 d'exécution. Un serveur de stockage 46 peut comporter plusieurs files d'attente 64, par exemple une file d'attente pour chaque client de stockage 44 du réseau, ou encore une file d'attente pour chaque espace de stockage dont le serveur de 15 stockage 46 gère l'accès, ou tout autre agencement utile pour l'implémentation des stratégies d'ordonnancement qui seront décrites plus bas. Le serveur de stockage 46 peut ainsi recevoir en cascade une quantité importante de requêtes d'un ou plusieurs clients de stockage et exécuter celles-20 ci dans l'ordre le plus favorable pour l'occupation de la station sur laquelle il s'exécute, l'occupation des disques qu'il gère, et l'occupation réseau en général. Dans ce qui est connu, la relation client de stockage / serveur de stockage est 25 dite "orientée client". Dans ce type de relation, c'est la file d'attente des requêtes du client de stockage 44 qui prévaut, et le client n'est autorisé à envoyer une nouvelle requête d'accès à un serveur que lorsque celui-ci a répondu à la requête précédente. 30 L'architecture décrite ici constitue une "orientation serveur" de la gestion de l'accès à l'espace de stockage. Contrairement à ce qui est connu, un client de stockage 44 donné peut ainsi envoyer une multitude de requêtes d'accès à un 2907993 14 même serveur de stockage 46, sans que celui-ci n'ait à retourner d'abord le résultat d'une requête émise antérieurement par le client de stockage 44. Cela permet de mieux équilibrer la charge disque et réseau dans les accès entrée/sortie et est particulièrement avantageux. 5 Parallèlement à la réception des requêtes dans sa file d'attente 64, le serveur de stockage 46 effectue une étape 66 en boucle dans laquelle il ordonne et exécute les requêtes reçues dans la file d'attente. La requête correspondant à l'en-tête 62 est donc traitée dans cette boucle, dans l'ordre déterminé par le 10 serveur de stockage. Dans l'étape 66, le serveur exécute un ordonnancement des requêtes dans la file d'attente 64, afin d'optimiser localement l'utilisation des espaces de stockage dont il gère l'accès ainsi que l'utilisation de la station sur laquelle il 15 s'exécute en prenant en compte des paramètres comme la charge processeur, l'occupation de la mémoire centrale de la station, etc. L'ordonnancement et l'exécution effectués à l'étape 66 sont précisés à l'aide de la figure 6. 20 À un instant donné, le serveur de stockage 46 a dans sa file d'attente un ensemble de requêtes pouvant prendre divers états. Ces états peuvent être par exemple "à traiter" (lorsqu'une requête vient d'être reçue dans la file d'attente), "en attente d'exécution" (lorsque le serveur de stockage 46 a l'ensemble des 25 données nécessaires à l'exécution d'une requête et a programmé son exécution à un moment ultérieur), ou encore "en cours d'exécution". Il apparaît par ailleurs que ces requêtes ont au moins deux natures distinctes. Une première nature est qualifiée de "réseau", et désigne un échange qui doit 30 être réalisé entre le serveur de stockage 46 et un client de stockage 44 donné. L'autre nature est qualifiée de "disque" et désigne un accès que doit réaliser le 2907993 15 serveur de stockage 46 sur l'un des espaces de stockage qu'il gère, pour lire ou écrire des données. L'ordonnancement de l'étape 66 est réalisé sur la base de la nature de ces 5 requêtes et de leur état, de paramètres d'état du réseau du système et de paramètres d'état des espaces de stockages gérés par le serveur de stockage 46, ainsi que l'utilisation de la station sur laquelle il s'exécute en prenant en compte des paramètres comme la charge processeur, l'occupation de la mémoire centrale de la station, etc. 10 La description de l'étape 66 va être faite dans le cas où le serveur de stockage gère plusieurs disques de stockage de données. Il en résulte que de nombreux éléments qui sont de nature globale par rapport à la boucle sont des tables, éventuellement multidimensionnelles. Ainsi, il sera fait appel à un tableau Last Sect, qui comporte une seule ligne, et dont chaque colonne désigne le dernier secteur accédé pour le disque correspondant à cette colonne. 20 De même, il sera fait appel à une matrice Tm_Used, dans laquelle les lignes désignent chacune un client de stockage, et les colonnes chacune un disque, les valeurs des éléments au croisement de la ligne x et de la colonne y représentant le temps d'occupation du disque y pour des requêtes émises par le client x. 25 La boucle de l'étape 66 traite des données 70. Les données 70 contiennent une liste de requêtes File et une liste de requêtes List_Req. La liste de requêtes File contient un ensemble de requêtes ayant un état "à traiter", c'est-à-dire les requêtes reçues instantanément dans la ou les files d'attente du serveur de 30 stockage. La liste List_Req contient un ensemble de requêtes ayant un état "en attente d'exécution" ou "en cours d'exécution". Ces requêtes sont chacune 15 2907993 16 accompagnées d'un indicateur d'âge. L'indicateur d'âge d'une requête indique le nombre de boucles qui ont été parcourues depuis que cette requête a été ajoutée à la liste List_Req. 5 Dans une étape 72, le serveur de stockage appelle une fonction Init() avec pour argument les listes File et List_Req. La fonction lnit() est décrite plus avant avec la figure 7. La fonction Init() débute dans une étape 700, avec dans une étape 702 l'appel 10 d'une fonction Add_New_Req() qui a pour arguments les listes File et List_Req. La fonction Add_New Req() a pour rôle de prendre toutes les nouvelles requêtes de la liste File et les ajouter à la liste List_Req. Dans la liste List_Req, l'indicateur d'âge des nouvelles requêtes est initialisé à 0 par la fonction Add_New_Req(). 15 L'étape 702 est suivie par une double condition portant sur l'occupation du serveur de stockage, afin d'optimiser le fonctionnement du système. La première condition est testée dans une étape 704, dans laquelle un indicateur d'attente Stat_Wt est testé. Lorsque l'indicateur Stat_Wt est égal à 0, cela signifie qu'aucune attente n'a eu lieu lors de la boucle précédente. De manière inverse, une attente lors de la boucle précédente est indiquée par un indicateur Stat_Wt égal à 1. 25 La deuxième condition est testée dans une étape 706, dans laquelle le serveur de stockage vérifie qu'il y a plus de deux requêtes dans la liste File. Si l'une de ces conditions n'est pas remplie, à savoir s'il y a eu attente lors de la boucle précédente, ou si plus de deux requêtes sont dans la liste File, alors la 30 fonction lnit() se poursuit dans une étape 708 dans laquelle l'indicateur Stat_Wt est mis à 0 pour la prochaine boucle. 20 2907993 17 Ensuite, dans une étape 710, le serveur de stockage teste si la liste List_Req est vide. Si ce n'est pas le cas, la fonction Init() se termine à l'étape 712, et la boucle d'ordonnancement peut se prolonger pour traiter les requêtes de la liste List_Req. 5 Si la liste List_Req est vide, alors il n'y a pas lieu de poursuivre la boucle d'ordonnancement, et le serveur de stockage attend une milliseconde par une fonction Wait(1) dans une étape 714, puis met l'indicateur Stat_Wt à 1 pour la prochaine boucle et reprend à l'étape 702, pour récupérer d'éventuelles 10 nouvelles requêtes reçues par la ou les files d'attente du serveur de stockage. Après la fonction Init(), le serveur de stockage appelle une fonction Run_Old() dans une étape 76. Cette fonction a pour but d'exécuter les requêtes de List Req qui ont un indicateur d'âge très élevé. La fonctionRun_Old() est décrite au moyen de la figure 8, et retourne un indicateur Rst égal à 1 si une requête âgée est exécutée, et égal à 0 sinon. Après une étape de départ 800, le serveur de stockage appelle dans une 20 étape 802 une fonction Max Age(). La fonction Max Age() prend comme argument la liste List_Req et retourne l'indicateur d'âge le plus élevé des requêtes de List_Req. Si cet indicateur d'âge est supérieur à 150, alors dans une étape 804, le 25 serveur de stockage appelle une fonction Age() qui prend comme arguments la liste List_Req et le nombre 120. La fonction Age() détermine l'ensemble des requêtes de List_Req qui ont un indicateur d'âge supérieur à 120. Ces requêtes sont stockées dans une liste de requêtes List_Old. 30 Ensuite, dans une étape 806, le serveur de stockage appelle une fonction Req_Min_Sect() avec la liste List_Old et le tableau Last_Sect comme arguments. La fonction Req_Min_Sect() permet de déterminer quelle est la 15 2907993 18 requête parmi la liste List_Old qui présente le secteur d'accès de requête le plus proche du dernier secteur accédé récemment. Cela est réalisé en calculant, pour chaque requête contenue dans List _01d, la 5 valeur absolue de la distance entre le secteur de disque visé et le dernier secteur accédé de ce disque, comme contenu dans Last Sect. Une fois que le minimum est déterminé, la requête correspondante est stockée dans une requête Req. 10 Ensuite, le serveur de stockage exécute la requête Req en l'appelant comme argument d'une fonction Exec() dans une étape 808. La fonction Exec() exécute la requête Req, mesure le temps d'exécution de cette requête et stocke ce temps dans un nombre Tex. 15 L'exécution d'une requête est décrite à l'aide de la figure 9. Cette exécution est basée sur un triplet adresse physique û taille û type de requête 900 que contient l'en-tête dans la file d'attente 64. Dans une étape 902, un test sur le type de la requête détermine la chaîne des 20 entrées/sorties disques et réseau à effectuer. Si c'est une requête en écriture, le serveur de stockage demande au client de stockage de lui envoyer les données d'écriture dans une étape 904. Le serveur de stockage attend les données, et, à réception, les inscrit dans l'espace 25 désigné par l'adresse physique dans une étape 906. Le serveur de stockage 46 émet alors un accusé de réception d'écriture 908 au client de stockage 44 afin de confirmer l'écriture. Après cela, l'exécution se termine dans une étape 914. Si c'est une requête en lecture, le serveur de stockage 46 accède aux données contenues dans l'espace désigné par l'adresse physique dans une étape 910, 30 2907993 19 jusqu'à la taille de la requête, et transmet celles-ci au client de stockage 44 dans une étape 912. Après cela, l'exécution se termine dans une étape 914. Une fois la requête Req exécutée, le serveur de stockage met à jour la liste 5 List_Req dans une étape 810. Cette mise à jour est réalisée en appelant une fonction Upd() avec comme arguments la liste List_Req et le nombre T_ex. Cette fonction retire la requête Req des listes List_Req et List_Old, et met à jour une matrice Tm_Used, en ajoutant le nombre Tex à l'élément au croisement 10 de la ligne qui correspond au client de stockage 44 qui a émis la requête Req, et de la colonne qui correspond au disque visé par la requête Req. Cela permet de tenir à jour l'occupation de chaque disque par chaque client de stockage. Enfin, le tableau Last_Sect est mis à jour à la colonne du disque qui a été accédé par la requête Req, pour tenir compte du dernier secteur réellement 15 accédé. Le serveur de stockage 46 teste ensuite dans une étape 812 si la liste List_Old est vide. Si c'est le cas, alors l'indicateur Rst est mis à 1 dans une étape 814 pour indiquer qu'une requête "âgée" a été exécutée et la fonction Run_Old() se 20 termine dans une étape 816. Si ce n'est pas le cas, la fonction Run_Old() retourne à l'étape 806 pour exécuter les autres requêtes âgées restantes. Dans le cas où la fonction Max Age() retourne un indicateur d'âge inférieur à 150, alors l'indicateur Rst est mis à 0 dans une étape 818 pour indiquer 25 qu'aucune requête "âgée" n'a été exécutée, et la fonction Run_Old() se termine dans une étape 820. La boucle d'ordonnancement et d'exécution se poursuit ensuite par un test sur l'indicateur Rst dans une étape 78, afin de déterminer si une requête "âgée" a 30 été exécutée. Si c'est le cas, alors le serveur de stockage réitère la boucle avec l'étape 72 en réappelant la fonction Init(). 2907993 20 Sinon, le serveur de stockage termine la boucle d'ordonnancement et d'exécution en appelant une fonction Run_Min_Use() avec comme argument la liste List_Req. 5 La fonction Run_Min_Use() est décrite à l'aide de la figure 10. Après initialisation dans une étape 1000, le serveur de stockage 46 appelle une fonction Add Age() avec comme argument le nombre 1 dans une étape 1002. La fonction Add_Age() incrémente de 1 l'indicateur d'âge de toutes les requêtes de la liste List Req, et initialise un compteur Min_t à 0. 10 Dans une étape 1004, le serveur de stockage 46 appelle ensuite une fonction Use_Inf Min_t() avec comme arguments la liste List_Req et le compteur Min_t. La fonction Use_Inf Min_t() parcourt la liste List Req, et vérifie pour chaque requête si l'élément de la matrice Tm_Used au croisement de la ligne 15 correspondant au client de stockage 44 qui l'a émise et de la colonne correspondant au disque qu'elle désigne est inférieur à Min_t. Concrètement, cela signifie qu'une requête donnée est sélectionnée si le client qui l'a émise a déjà occupé le disque qu'elle vise pendant un temps inférieur à 20 Min_t. Toutes les requêtes ainsi sélectionnées sont stockées dans une liste List Min Req. Dans une étape 1006, le serveur de stockage teste si List_Min_Req est vide. Si c'est le cas, alors le compteur Min_t est incrémenté de 1 dans une étape 1008, 25 et l'étape 1004 est répétée. Une fois que la liste List_Min_Req contient au moins une requête, le serveur de stockage 46 exécute des étapes 1010, 1012 et 1014 qui ne diffèrent des étapes 906, 908, et 910 précédemment décrites qu'en ce que c'est la liste 30 List_Min_Req qui est ici utilisée, au lieu de la liste List_Old. 2907993 21 Après l'exécution de la requête la plus favorable selon les étapes 1010, 1012 et 1014, le serveur de stockage 46 appelle une fonction Rst_Tm_Used() dans une étape 1016. 5 La fonction Rst_Tm_Used() a pour but de réinitialiser la matrice Tm_Used dans le cas où un client de stockage 44 a beaucoup utilisé les disques par rapport aux autres clients de stockage. Pour cela, la fonction Rst_Tm_Used() additionne tous les éléments de la 10 matrice Tm_Used. Cela représente la somme totale des temps d'occupation des disques gérés par le serveur de stockage 46, par la totalité des clients de stockage 44. Si cette somme totale excède une valeur prédéterminée, alors tous les 15 éléments de la matrice Tm_Used sont mis à 0. Sinon, la matrice Tm_Used est inchangée. Après l'étape 1016, la fonction Run_Min_Use() se termine dans une étape 1018, et la boucle d'ordonnancement et d'exécution est recommencée à 20 l'étape 72. La fonction Run_Min_Use() permet donc d'ordonner l'exécution des requêtes sur la base d'informations contenues dans l'en-tête des requêtes, indépendamment de la présence des données éventuellement désignées par 25 ces requêtes. II est donc ainsi possible d'ordonner l'exécution d'une quantité importante de requêtes, notamment des requêtes en écriture, sans surcharger l'espace mémoire avec les données à écrire de ces requêtes. Dans d'autres applications, il serait néanmoins envisageable de n'ordonner que les requêtes de la liste File pour lesquelles l'ensemble des données 30 2907993 22 nécessaires à l'exécution de la requête sont disponibles. Cela pourrait être fait en assurant en parallèle une boucle d'alimentation en données, assurant ainsi que l'espace alloué au stockage des données de requête est rempli de manière à optimiser la quantité de requêtes à ordonner. La description de l'étape 66 a été faite dans le cas où le serveur de stockage gère plusieurs disques de stockage de données. Il en résulte que de nombreux éléments qui sont de nature globale par rapport à 10 la boucle ont été des tables, parfois multidimensionnelles. Dans le cas où le serveur de stockage ne gère qu'un seul disque, la situation peut être simplifiée. Alors, l'élément Last_Sect devient une valeur simple, et l'élément Tm_Used un tableau à une dimension (les clients de stockage). 15 Par ailleurs, l'ordonnancement a été réalisé ici en plaçant toutes les requêtes des files d'attente du serveur de stockage ensemble. Cependant, il serait possible de distinguer les requêtes en fonction de la file d'attente dont elles sont issues respectivement, soit en indiciant la liste List_Req, soit en exécutant un ordonnancement pour chaque file d'attente, en série ou en parallèle. 20 Comme il apparaît à la lecture de ce qui précède, la boucle d'ordonnancement et d'exécution comprend trois parties principales traitées en série : - une première partie de gestion des nouvelles requêtes ; - une deuxième partie de traitement des requêtes les plus âgées ; - une troisième partie de traitement des requêtes issues des clients de stockage qui ont le moins utilisé le serveur de stockage. Il apparaît clairement que ces parties sont indépendantes les unes des autres et qu'une boucle simplifiée pourrait ne contenir qu'une seule ou plusieurs de 5 25 30 2907993 23 celles-ci. Il apparaît également clair que le traitement de ces parties pourrait être parallèle, et qu'au lieu de réinitialiser la boucle après l'exécution des requêtes "âgées", il serait possible de réaliser la troisième partie. 5 Les deuxièmes et troisièmes parties doivent être perçues comme des exemples particuliers de concepts plus généraux. Ainsi, dans la deuxième partie, le traitement des requêtes "âgées" relève d'un souci de gérer les requêtes "exceptionnelles", qui, pour une quelconque raison, 10 ne sont pas exécutées en priorité par l'algorithme. C'est cette idée directrice qu'il convient de retenir, en ce sens que d'autres implémentations pour éviter de tels cas pourraient être envisagés. En ce qui concerne la troisième partie, le concept général est d'ordonner les 15 requêtes en fonction d'un critère quantitatif basé sur la relation entre le client de stockage et le serveur de stockage. Ainsi, dans l'exemple décrit, un critère quantitatif de temps d'utilisation des unités de mémoire locales est utilisé pour discriminer les requêtes entre elles. 20 Il serait cependant possible d'utiliser d'autres critères quantitatifs, basés sur des statistiques caractérisant les interactions client de stockage û serveur de stockage, comme le taux moyen d'échange de données, la latence réseau moyenne constatée lors de ces interactions, le taux de perte de paquets, etc. 25 Par ailleurs, l'implémentation ici décrite est donnée à titre d'exemple simplifié, et elle pourrait être améliorée encore par l'utilisation de techniques de programmation classiques, comme l'usage de tampons, ou encore la prise en compte d'autres paramètres pour l'ordonnancement. 30 Dans ce qui a été présenté, l'ordonnancement est basé sur une stratégie favorisant deux axes principaux : l'exécution des requêtes âgées, et le partage de la charge entre les disques et les clients. 2907993 24 D'autres stratégies peuvent être implémentées (en changeant en correspondance ce qui précède) pour favoriser d'autres approches comme : - la maximisation de l'exploitation de la bande passante disque, par exemple en 5 agrégeant les requêtes qui sont contiguës ou presque en une seule requête, ce qui permet d'économiser un accès disque ; - la maximisation de l'exploitation de la latence disque, par exemple en générant au niveau du serveur de stockage des requêtes d'optimisation visant 10 le centre du ou des disques pour diminuer la latence, ou en générant des requêtes prédictives (c'est-à-dire visant des données en prévision d'une future requête) au niveau du serveur de stockage. D'autres stratégies et leur implémentation, ainsi que de nombreuses variantes 15 apparaîtront de manière évidente à l'homme du métier. Ainsi, 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 20 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). 25 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. 30 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 2907993 25 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. 5 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 Serial 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, 20 * 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 25 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 30 module Exanodes Clustered Service Manager de l'application Exanodes (marque déposée) de la société Seanodes (marque déposée). 10 15 2907993 26 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 noeuds applicatifs, et * un ensemble de dispositifs informatiques réalisés conformément à ce qui 5 précède, et qui jouent le rôle de serveurs du réseau et de noeuds 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. 10 L'invention englobe le système informatique comprenant les noeuds applicatifs et les noeuds stockant dans leur ensemble. Elle englobe également les éléments individuels de ce système informatique, et notamment les noeuds applicatifs et les noeuds stockants dans leur individualité, ainsi que les divers moyens pour les réaliser. 15 De même, le procédé de gestion de données est à considérer dans sa globalité, c'est-à-dire dans l'interaction des noeuds applicatifs et des noeuds stockants, mais également dans l'individualité des postes informatiques adaptés pour réaliser les noeuds applicatifs et les noeuds 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. 25 L'invention couvre également, en tant que produits, les éléments logiciels décrits, mis à disposition sous tout "medium" (support) lisible par ordinateur. L'expression "medium lisible par ordinateur" comprend les supports de stockage de données, magnétiques, optiques et/ou électroniques, aussi bien 30 qu'un support ou véhicule de transmission, comme un signal analogique ou numérique. 20 Revendications 1. Système informatique comprenant plusieurs postes informatiques dits noeuds interconnectés en un réseau, - certains au moins des noeuds, dits stockants, comprenant au moins une unité de mémoire locale (38) à accès direct, et un serveur de stockage (46) agencé pour gérer l'accès à cette unité de mémoire locale (46) sur la base d'une file d'attente (64) de requêtes d'accès, - certains au moins des noeuds, dits applicatifs, comprenant chacun : * un environnement d'application muni : 15 - d'un gestionnaire de système de fichiers (18, 20, 22), agencé pour maintenir une représentation de fichiers accessibles depuis ce noeud sous forme d'adresses virtuelles, et - d'un module de correspondance (36), capable de maintenir une 20 correspondance entre chaque adresse virtuelle et au moins une adresse physique sur une unité de mémoire locale (38) d'un noeud stockant, * un client de stockage (44) capable d'interagir avec l'un quelconque des serveurs de stockage (46), sur la base d'une requête d'accès désignant une 25 adresse physique, caractérisé en ce que l'un au moins des serveurs de stockage (46) est agencé pour exécuter les requêtes d'accès contenues dans sa file d'attente (64) dans un ordre déterminé en fonction d'un jeu de règles formant critères de 30 performance, et impliquant un ou plusieurs paramètres d'état de la ou des unités de mémoire locale (38). 27 10 2907993 28 2. Système informatique selon la revendication 1, caractérisé en ce que le jeu de règles implique en outre un ou plusieurs paramètres d'état du noeud stockant concerné. 5 3. Système informatique selon la revendication 1 ou 2, caractérisé en ce que le jeu de règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) et basée sur le contenu d'un en-tête (62) de chaque requête, et en ce que cette règle est opératoire en l'absence d'autres données associées à ces requêtes. 4. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le jeu de règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) et basée sur un critère quantitatif établi sur la base d'interactions antérieures de ce client de stockage (44) avec le serveur de stockage (46) concerné. 5. Système informatique selon la revendication 4, caractérisé en ce que le critère quantitatif est établi sur la base de la durée de sollicitation antérieure du serveur de stockage (46) concerné par le client de stockage. 6. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le jeu de règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) et basée sur la durée de présence des requêtes dans la file d'attente (64). 25 7. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le jeu de règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) et basée sur la distance entre l'adresse physique désignée par chaque requête et une adresse physique 30 accédée précédemment par le serveur de stockage (46). 2907993 29 8. Système informatique selon l'une des revendications précédentes, caractérisé en ce que l'un au moins des serveurs de stockage (46) est agencé pour exécuter les requêtes d'accès contenues dans sa file d'attente (64) dans un ordre déterminé en fonction d'un jeu de règles choisi parmi une pluralité de 5 jeux de règles différents formant stratégies quant aux critères de performance. 9. Système informatique selon l'une des revendications précédentes, caractérisé en ce que certains au moins des clients de stockage (44) sont autorisés à émettre sélectivement une requête d'accès à un serveur de 10 stockage donné, avant la complétion d'une requête d'accès à ce serveur de stockage (46), émise antérieurement par le client de stockage considéré. 10. Système informatique selon l'une des revendications précédentes, caractérisé en ce que certains au moins des serveurs de stockage (46) gèrent 15 plusieurs unités de mémoire locale (38). 11. Système informatique selon l'une des revendications précédentes, caractérisé en ce que certains au moins des noeuds sont des noeuds applicatifs et des noeuds stockants. 20 12. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le module de correspondance (36) comprend une table de correspondance (42) comprenant une correspondance entre chaque adresse virtuelle et au moins une adresse physique sur une unité de mémoire locale (38) d'un noeud stockant, et un moteur (40) agencé pour définir l'adresse physique pour une requête donnée en interrogeant la table de correspondance (42) avec une adresse virtuelle, et de transmettre la requête donnée avec l'adresse physique déterminée au client de stockage (44) concerné pour exécution de la requête donnée. 2907993 30 13. Procédé de gestion de données, applicable dans un réseau comprenant plusieurs postes informatiques interconnectés, dits noeuds, comportant les étapes suivantes : 5 a. émettre une requête de fichier depuis un noeud applicatif du réseau, sur la base d'une représentation sous forme d'adresses virtuelles, b. sur la base d'une correspondance entre chaque adresse virtuelle et au moins une adresse physique sur une unité de mémoire locale (38) d'un noeud 10 stockant du réseau, déterminer au moins une adresse physique correspondant à ladite adresse virtuelle, c. émettre une requête d'accès désignant ladite adresse physique depuis un client de stockage (44) vers un serveur de stockage (46) gérant l'accès à l'unité 15 de mémoire locale (38) associée à ladite adresse physique, caractérisé en ce que le procédé comporte en outre l'étape suivante : d. placer la requête d'accès dans une file d'attente (64) dudit serveur de 20 stockage (46), et exécuter les requêtes d'accès contenues dans ladite file d'attente (64), dans un ordre déterminé en fonction d'un jeu de règles formant critères de performance, et impliquant un ou plusieurs paramètres d'état de la ou des unités de mémoire locale (38). 25 14. Procédé selon la revendication 13, caractérisé en ce que le jeu de règles implique en outre un ou plusieurs paramètres d'état du noeud stockant concerné. 15. Procédé selon la revendication 13 ou 14, caractérisé en ce que le jeu de 30 règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) et basée sur le contenu d'un entête (62) de chaque requête, 2907993 31 et en ce que cette règle est opératoire en l'absence d'autres données associées à ces requêtes. 16. Procédé selon l'une des revendications 13 à 15, caractérisé en ce que le 5 jeu de règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) et basée sur un critère quantitatif établi sur la base d'interactions antérieures du client de stockage (44) émettant chaque requête avec le serveur de stockage (46) concerné. 10 17. Procédé selon la revendication 16, caractérisé en ce que le critère quantitatif est établi sur la base de la durée de sollicitation antérieure du serveur de stockage (46) concerné par le client de stockage. 18. Procédé selon l'une des revendications 13 à 17, caractérisé en ce que le 15 jeu de règles comprend une règle propre à la sélection de requêtes présentes dans la file d'attente (64) depuis un temps choisi. 19. Procédé selon l'une des revendications 13 à 18, caractérisé en ce que le jeu de règles comprend une règle propre à la sélection de requêtes présentes 20 dans la file d'attente (64) et basée sur la distance entre l'adresse physique désignée par chaque requête et une adresse physique accédée précédemment par le serveur de stockage (46). 20. Procédé selon l'une des revendications 13 à 19, caractérisé en ce que le 25 jeu de règles comprend plusieurs règles choisies parmi une pluralité de jeux de règles différents formant stratégies quant aux critères de performance. 21. Procédé selon l'une des revendications 13 à 20, caractérisé en ce que l'étape c. peut être reproduite par un même émetteur de requête d'accès (44) 30 avec une autre adresse physique, avant la complétion de l'étape d. pour une requête d'accès à ce serveur de stockage (46), émise antérieurement par l'émetteur de requête d'accès (44) considéré. 2907993 32 22. Procédé selon l'une des revendications 13 à 21, caractérisé en ce que caractérisé en ce que certains au moins des serveurs de stockage (46) comportent une file d'attente (64) pour chaque émetteur (44) de requête d'accès. 23. Procédé selon l'une des revendications 13 à 22, caractérisé en ce que caractérisé en ce que certains au moins des serveurs de stockage (46) gèrent l'accès à plusieurs unités de mémoire locale (38). 10 24. Dispositif informatique formant noeud stockant agencé pour effectuer l'étape d. du procédé selon l'une des revendications 13 à 23. 5