FR2870951A1 - Systeme de memorisation de donnees de niveau utilisateur - Google Patents

Abstract

La présente invention concerne un système de mémorisation de données et d'accès à des données à utiliser avec un ou plusieurs systèmes de traitement parallèle comportant une pluralité de noeuds (1-1, 1-2, ..., 1-n) pour une application (3) d'entrée/sortie de fichier parallèle. L'application est divisée en plusieurs applications individuelles (3-1, 3-2, ..., 3-k) s'exécutant sur un noeud individuel. Un fichier de données (2), accessible à l'application, est divisé en plusieurs fragments de fichier (2-1, 2-2, ..., 2-n) qui sont mémorisés dans une pluralité de moyens de mémorisation indépendants (5-1, 5-2, ..., 5-1). Au moins un traitement d'entrée/sortie séparé (4-1, 4-2, ..., 4-o) est lancé par une application individuelle sur un noeud comportant un accès aux moyens de mémorisation comportant le fragment de fichier auquel l'application a accès. Le système comporte un moyen d'informations de distribution délivrant des informations de la distribution des fragments à au moins l'une des applications individuelles.

Description

SYSTÈME DE MÉMORISATION DE DONNÉES DE NIVEAU

UTILISATEUR

La présente invention concerne un système de mémorisation de données et d'accès à des données destiné à être utilisé avec un ou plusieurs systèmes de traitement parallèle. Plus particulièrement, la présente invention concerne un Système de Mémorisation de Données de niveau Utilisateur (UDS) permettant d'augmenter les performances d'une application qui exécute une entrée/sortie de fichier parallèle.

Alors que la puissance de calcul et les performances de communication de nombreux systèmes informatiques à performances élevées (HPC) sont d'un niveau très élevé permettant l'exécution efficace d'applications massivement parallèles, on peut observer que la largeur de bande d'entrée et de sortie (I/O) effective de telles applications chute en dessous de ce niveau de performance. Avec des solutions actuelles, le potentiel des performances réelles du matériel d'entrée/sortie installé n'est pas bien exploité.

Pour obtenir une largeur de bande accumulée suffisante pour les applications parallèles même avec l'infrastructure d'entrée/sortie disponible, des utilisateurs et des opérateurs système utilisent souvent des "solutions de rechange". Une manière typique consiste à diviser ou partitionner l'entrée pour une application en un ou plusieurs sousfichiers pour chaque traitement d'une application parallèle. Chaque traitement lit ou écrit ensuite uniquement ce sous-fichier en utilisant une interface d'entrée/sortie séquentielle telle que l'entrée/sortie de Fortran, pendant qu'aucun autre traitement n'accède à ce sous-fichier. Le problème avec cette approche est la représentation statique des sousfichiers en traitement et le temps système élevé du prétraitement et du post-traitement. De plus, pour obtenir les performances maximales, il est souvent nécessaire d'étaler les sous-fichiers à travers de multiples systèmes de fichiers, ce qui ajoute encore davantage de complexité.

Si ces systèmes de fichiers ne peuvent pas faire l'objet d'un accès par tous les noeuds de calcul, par exemple dans le cas où l'on utilise les systèmes de fichiers locaux rapides sur les noeuds de calcul, l'application va même échouer à s'exécuter si la distribution des fichiers ne correspond pas au positionnement des traitements. Du fait que le positionnement des traitements est effectué par le système de planification et est par conséquent arbitraire, il est très difficile d'obtenir des performances optimales de cette manière.

Des systèmes de fichiers distribués tels que le Système de Fichiers en Réseau (NFS), le Système de Fichiers Andrew (AFS), ou le Système de Fichiers Global (GFS) sont uniquement conçus pour fournir un accès distribué à des fichiers à partir de multiples machines clientes. Cependant, les systèmes de fichiers distribués ne sont pas conçus pour des écritures concourantes à largeur de bande élevée que nécessitent typiquement des applications parallèles.

Les systèmes de fichiers parallèles disponibles dans le commerce, tels que le Système de Fichiers Personnel (PFS), le Système de Fichiers d'Entrée/Sortie Parallèle (PIOFS) et le Système de Fichiers Parallèle Général (GPFS) sont souvent disponibles uniquement pour des plate-formes spécifiques. Comme décrit par exemple dans le document US-A-6 032 216, ce système comporte un système de fichiers à disque partagé s'exécutant sur de multiples ordinateurs ayant chacun leur propre cas d'un système d'exploitation et étant couplés pour un accès partagé à des données parallèle à des fichiers résidant sur des disques partagés reliés au réseau. Un noeud de métadonnées gère des métadonnées de fichier pour des actions de lecture et d'écriture parallèles. Des jetons de métadonnées sont utilisés pour l'accès commandé aux métadonnées et une sélection et un changement initiaux du noeud de métadonnées.

Un système de fichiers parallèle destiné à des grappes sous Linux, appelé Système de Fichiers Virtuel Parallèle (PVFS) a pour but principal de fournir un accès à vitesse élevée à des données de fichier pour des applications parallèles basées sur Linux. Le système PVFS fournit un large espace de noms cohérents à une grappe sous Linux, permet l'entrelacement commandé par un utilisateur de données à travers des disques sur différents noeuds d'entrée/sortie, et permet à des opérations binaires existantes de fonctionner sur des fichiers PVFS sans la nécessité d'une recompilation. Le système PVFS est 2870951 4 conçu sous forme d'un système client-serveur ayant de multiples serveurs, appelés démons d'entrée/sortie. Des démons d'entrée/sortie sont statiquement conçus pour s'exécuter sur des noeuds prédéterminés séparés dans la grappe, appelés noeuds d'entrée/sortie, qui ont des disques qui leurs sont associés. Chaque fichier PVFS est entrelacé à travers les disques sur les noeuds d'entrée/sortie. Au moment où le système de fichiers est installé, l'utilisateur spécifie quels noeuds de la grappe vont servir en tant que noeud d'entrée/sortie. Les traitements d'application interagissent avec le système PVFS via une bibliothèque client. Les traitements d'application communiquent directement avec le gestionnaire PVFS via un protocole de contrôle de transmission (TCP) relativement lent lors de l'exécution d'opérations telles qu'une ouverture, une création, une fermeture, et une suppression de fichiers. Lorsqu'une application ouvre un fichier, le gestionnaire renvoie à l'application les emplacements des noeuds d'entrée/sortie statiques prédéterminés sur lesquels des données de fichiers sont mémorisées.

La présente invention fournit une solution aux problèmes décrits cidessus. Le système selon la présente invention n'est pas un système de fichiers commandé par un noyau, mais au lieu de cela il fonctionne dans un espace utilisateur, en utilisant les systèmes de fichiers disponibles de la meilleure manière possible pour obtenir une largeur de bande d'entrée/sortie parallèle accumulée élevée.

2870951 5 Le système selon la présente invention, également nommé dans ce qui va suivre Système de Mémorisation de Données de niveau Utilisateur (UDS), va se caractériser par une largeur de bande d'entrée/sortie élevée pour les applications parallèles en utilisant de préférence une Interface de Passage de Message pour Entrées/Sorties (MPI-IO) qui permet la mise à l'échelle avec le nombre de traitements impliqués. L'interface MPI-IO est la partie de l'Interface de Passage de Message (MPI) standard qui spécifie comment a lieu un accès à des fichiers en parallèle dans une application MPI. Pour l'accès à un fichier, qui ne nécessite pas de performances élevées, comme la gestion de tâches, d'autres procédés pour accéder à un fichier peuvent être utilisés. Le système est capable de bénéficier d'une quelconque infrastructure d'entrée/sortie donnée, sans une quelconque dépendance vis-à-vis du système de fichiers réel utilisé pour mémoriser les données sur celui-ci.

Sa souplesse va permettre à l'utilisateur de choisir parmi un quelconque emplacement de mémorisation visible dans le système, partagé ou nonpartagé entre les noeuds, qui s'adapte au mieux aux impératifs de son application spécifique.

Plus précisément, la présente invention propose un système de mémorisation de données et d'accès à des données destiné à être utilisé avec un ou plusieurs systèmes de traitement parallèle comportant une pluralité de noeuds pour une application d'entrée/sortie de fichier parallèle: ladite application peut être divisée en une pluralité d'applications individuelles et chacune desdites applications individuelles peut s'exécuter sur un noeud individuel, un fichier de données accessible pour ladite application peut être divisé en une pluralité de fragments de fichier, lesdits fragments de fichier peuvent être mémorisés dans une pluralité de moyens de mémorisation 10 indépendants accessibles dans le système de traitement parallèle, au moins un traitement d'entrée/sortie séparé peut être lancé par une application individuelle sur un noeud, qui peut comporter un accès aux moyens de 15 mémorisation comportant le fragment de fichier qui fait l'objet d'un accès par l'application, les applications individuelles et lesdits traitements d'entrée/sortie séparés peuvent communiquer via des messages d'Interface de Passage de Message (MPI), au moins un moyen d'informations de distribution peut être sont adapté pour délivrer des informations de la distribution des fragments de fichier à au moins l'une des applications individuelles, et dans lequel le système de mémorisation de données et d'accès à des données peut être basé au-dessus d'un système de fichiers disponible natif des noeuds.

La présente invention propose également un système de mémorisation de données et d'accès à des données destiné à être utilisé avec un ou plusieurs systèmes de traitement parallèle comportant une pluralité de noeuds pour une application d'entrée/sortie de fichier parallèle, caractérisé en ce que: ladite application peut être divisée en une pluralité d'applications individuelles et chacune 10 desdites applications individuelles peut s'exécuter sur un noeud individuel, un fichier de données accessible pour ladite application peut être divisé en une pluralité de fragments de fichier, lesdits fragments de fichier peuvent être mémorisés dans une pluralité de moyens de mémorisation indépendants accessibles dans le système de traitement parallèle, dans lequel les données d'un fichier de données peuvent être lues et/ou mémorisées et/ou créées et/ou transformées dans/entre des représentations de type de données différentes dans une mémoire et le fichier mémorisé dans les différents moyens de mémorisation.

Dans ce cas, au moins un traitement d'entrée/sortie séparé peut être lancé par une application individuelle sur un noeud, qui comporte un accès aux moyens de mémorisation comportant le fragment de fichier qui fait l'objet d'un accès par l'application.

Les applications individuelles et lesdits traitements d'entrée/sortie séparés peuvent communiquer via des messages d'Interface de Passage de Message (MPI).

Le système peut comporter au moins un moyen d'informations de distribution adapté pour délivrer des informations de la distribution des fragments de fichier à au moins l'une des applications individuelles.

Le système de mémorisation de données et d'accès à des données peut être basé au-dessus d'un système de fichiers disponible natif des noeuds.

Les données peuvent être transformées lors d'un transfert à partir de la mémoire vers les moyens de mémorisation.

Les données peuvent être transformées lors d'un transfert à partir des moyens de mémorisation vers la mémoire.

La transformation de données peut être prévue 20 pour des fichiers qui font l'objet d'un accès via une interface MPI-I0.

Le système peut fournir une transformation de données implicite entre des représentations de type de données différentes.

Un utilisateur peut explicitement spécifier une transformation de données via une interface MPI-IO.

Le type de données boutiste natif de la machine sur laquelle l'application s'exécute peut être utilisé lors d'une création d'un nouveau fichier avec une interface MPI-IO.

2870951 9 Lorsqu'un fichier existant est ouvert via une interface MPI-I0 pour effectuer une lecture ou une écriture, un boutisme des données peut être automatiquement transformé pour correspondre à la fois à la représentation des données dans la mémoire de la machine sur laquelle l'application s'exécute et à un paramétrage boutiste mémorisé du fichier.

L'ordre d'octets de tous les éléments de données peut être changé lors de toutes opérations de lecture et d'écriture lorsqu'un boutisme de la machine est différent d'un paramétrage boutiste du fichier.

Les données peuvent être directement transférées entre la mémoire et le fichier lorsqu'un boutisme natif de la machine est identique à un paramétrage boutiste du fichier.

Des attributs de fichier de différentes représentations de type de données peuvent être récupérés et établis depuis l'extérieur via des outils de ligne de commande.

Lors d'un accès à un fichier via une interface externe, les données peuvent être lues à partir de la mémoire ou écrites dans celle-ci sans aucune transformation.

Un format de données peut être l'un du groupe constitué de: type grosboutiste, type petit-boutiste, externe32 ou toute autre représentation de type de fichier commune.

Chaque application individuelle peut être autorisée à accéder à tout le fichier de données.

Un seul traitement d'entrée/sortie séparé peut être lancé par l'application sur un noeud, qui comporte l'accès aux moyens de mémorisation comportant le fragment de fichier qui fait l'objet d'un accès par l'application.

Le système de mémorisation de données n'est pas limité à utiliser des noeuds prédéfinis, des moyens de mémorisation et des trajets sur ces noeuds.

Au moins un des moyens de mémorisation peut être un dispositif de mémorisation locale d'un noeud.

Au moins un des moyens de mémorisation peut être un dispositif de mémorisation partagé d'une pluralité de certains noeuds.

L'utilisateur et/ou un administrateur système 15 peut être autorisé à spécifier où les fragments de fichier doivent être mémorisés.

L'accès à un fichier de l'application peut être commandé par l'application et les applications individuelles elles-mêmes.

Le système peut fournir une visibilité globale de chaque fichier de données constitué d'une pluralité de fragments de fichier.

Le système peut comporter une pluralité de moyens d'informations de distribution.

Le système peut fournir des programmes de service pour accéder, lister, supprimer et modifier le fichier de données par des commandes globales.

L'application peut s'exécuter sur un ordinateur parallèle ou sur une pluralité d'ordinateurs 30 connectés via un réseau. 25

Les fragments de fichier et des dispositifs de mémorisation peuvent être accessibles via un système de fichiers natif.

Chaque noeud peut être capable d'exécuter lesdites applications individuelles et est capable de fournir un accès d'entrée/sortie à un fragment de fichier voulu.

Les moyens d'informations de distribution peuvent s'exécuter sur un ou plusieurs desdits noeuds 10 ou sur au moins un noeud supplémentaire.

Les moyens d'informations de distribution peuvent maintenir une base de données qui conserve un enregistrement de chaque fichier et le fragment de fichier correspondant.

Les moyens d'informations de mémorisation peuvent fournir un espace de noms de système pour gérer la mémorisation et l'accès à ces fichiers.

Sur chaque noeud, un démon peut être prévu pour délivrer des informations des fragments de fichier 20 aux moyens d'informations de distribution.

Chaque démon peut s'exécuter en tant que traitement résident ou peut être lancé à la demande sous le compte d'utilisateur respectif.

La communication entre l'application des applications individuelles et les moyens d'informations de distribution peut être effectuée via un protocole TCP/IP.

Des mécanismes d'échange crypté pour la communication TCP/IP peuvent être utilisés.

2870951 12 Les moyens d'informations de distribution peuvent représenter un nom de fichier d'un fichier dans une méta-représentation locale qui contient toutes les informations pour accéder aux fragments de fichier distribués.

Le système selon la présente invention est un système qui permet à l'utilisateur, en particulier d'un système informatique à performances élevées, d'accroître les performances de son application qui effectue une entrée/sortie de fichier parallèle. Une application parallèle est divisée en une pluralité d'applications individuelles (AP), qui sont destinées à s'exécuter sous forme de traitements séparés éventuellement sur des noeuds différents. Le concept de base d'augmentation des performances est qu'un fichier est entrelacé dans des fragments de fichier à travers des dispositifs de mémorisation rapides, par exemple locaux, d'une pluralité de noeuds informatiques du système. La pluralité ou une partie de la pluralité des noeuds informatiques sont destinés à l'exécution des applications individuelles de l'application parallèle. Le système de la présente invention n'est pas un système de fichiers classique, mais une manière de mémoriser et d'accéder à des données d'une manière commandée par un utilisateur. Par conséquent, les fragments de fichier sont en principe encore accessibles via les systèmes de fichiers natifs respectifs.

Du fait qu'il est nécessaire d'accéder 30 également à des parties d'un fichier, c'est-à-dire aux fragments de fichier, qui ne se trouvent sur aucun des noeuds exécutant actuellement des traitements, un modèle de transfert "tiers" est utilisé. De préférence, un traitement d'entrée/sortie séparé (IOP) est lancé sur chaque noeud, qui conserve une partie du fichier, c'est-à-dire un fragment de fichier, devant faire l'objet d'un accès. Pour certaines situations spécifiques, il peut également être souhaitable de lancer plusieurs traitements d'entrée/sortie séparés sur un noeud unique. Les traitements exécutés, c'est-à-dire les applications individuelles (AP) et les traitements IOP communiquent de préférence via des messages MPI, où des messages MPI fournissent essentiellement la manière la plus rapide de communiquer entre traitements dans un système HPC, et un système UDS est capable d'exploiter ces performances. La largeur de bande effective pour accéder à un tel fichier peut par conséquent atteindre la largeur de bande accumulée des systèmes de fichiers indépendants du fait que la largeur de bande des messages MPI est typiquement beaucoup plus élevée que la largeur de bande d'opérations d'entrée/sortie.

En tant que système de niveau utilisateur, la manière selon laquelle le système UDS mémorise des données peut être complètement personnalisée par l'utilisateur. Ceci est possible du fait que le système UDS n'est pas un système de fichiers fixe, mais fonctionne un niveau au-dessus de tout système de fichiers disponible. L'utilisateur peut indiquer au système UDS quels systèmes de fichiers et quels noeuds doivent être utilisés pour mémoriser un fichier spécifique tandis que le fichier suivant dans l'espace de noms peut à nouveau être mémorisé sur un ensemble totalement différent de systèmes de fichiers. Ces systèmes de fichiers peuvent être distribués à travers un quelconque sous-ensemble des noeuds informatiques dans le système qui peuvent exécuter des applications MPI. Le fichier est divisé (entrelacé) à travers tous les systèmes de fichiers spécifiés bloc par bloc, avec une taille de bloc définissable par l'utilisateur (taille d'entrelacement) qui s'adapte au mieux aux caractéristiques de l'application, au système de fichiers et aux dispositifs de mémorisation sous-jacents. Il n'est pas nécessaire que les systèmes de fichiers utilisés pour entrelacer un fichier soient partagés entre deux noeuds informatiques quelconques. Ceci permet l'exploitation des performances des systèmes de fichiers d'un noeud local. Cependant, chaque fichier, appelé également fichier UDS par la suite, reste toujours globalement visible et accessible à des applications sensibles au système UDS, indépendamment du noeud informatique sur lesquel il s'exécute. Ceci combine un accès de fichier local à largeur de bande élevée avec la facilité d'utilisation d'un système de fichiers partagés. A ces deux caractéristiques, le système UDS ajoute une communication inter-traitements à performances élevées de l'interface MPI, une intégration étroite d'accès à des fichiers dans la bibliothèque MPI et la souplesse d'un système de niveau utilisateur.

Du fait que le système UDS divise des fichiers et mémorise les fragments de fichier dans des systèmes de fichiers distincts (ou des emplacements distincts dans le même système de fichiers), il fonctionne dans un espace de noms séparé, qui est géré par des moyens d'informations de distribution, appelés également par la suite serveur de noms UDS. Dans ce but, le serveur de noms maintient une base de données, qui conserve un enregistrement et un certain état global pour chaque fichier UDS. Par conséquent, des fichiers qui sont créés via le système UDS sont situés à l'intérieur de cet espace de noms, c'est-à-dire que toutes les informations de la distribution de fichiers sont mémorisées dans la base de données du serveur de noms, tandis que les fragments de fichier physiques sont mémorisés sur les disques de mémorisation distribués. En conséquence, il n'est pas possible d'ouvrir directement un fichier à l'extérieur de cet espace de noms (par exemple un fichier situé dans un répertoire personnel d'un utilisateur) via le système UDS. Pour réaliser cela, le fichier doit tout d'abord être importé dans l'espace de noms UDS. L'environnement UDS offre différentes manières d'effectuer une telle importation. De même, un fichier situé à l'intérieur de l'espace de noms UDS ne peut pas faire directement l'objet d'un accès en utilisant des programmes, qui ne sont pas sensibles au système UDS, par exemple, il n'est pas possible d'effectuer une opération de copie sur un fichier UDS en utilisant la commande cp d'Unix standard. Le fichier doit d'abord être exporté à partir de l'espace de noms UDS, ou faire l'objet d'un accès dans l'espace de noms UDS en utilisant un outil de ligne de commande UDS tel que udscp, qui est l'équivalent de la commande cp pour le système UDS.

Le système selon la présente invention fournit les plus fortes performances d'entrée/sortie et une facilité d'utilisation satisfaisante par l'intermédiaire des moyens suivants: (i) localement, la possibilité d'utiliser les dispositifs de mémorisation les plus rapides dans le système. Ceux-ci peuvent être un disque dur local dans les noeuds ou tout autre dispositif de mémorisation qui est accessible pour un traitement d'une application MPI; (ii) une largeur de bande d'accès à des fichiers très efficace: du fait qu'un fichier est entrelacé à travers de nombreux noeuds ou systèmes de fichiers, chaque unité d'entrelacement est actionnée par un traitement d'entrée/sortie séparé. Du fait que la largeur de bande des accès concourants des traitements d'entrée/sortie aux systèmes de fichiers indépendants s'ajoute à la largeur de bande d'entrée/sortie des applications, une largeur de bande très efficace en résulte; (iii) une largeur de bande inter-traitements élevée: du fait que toutes les communications inter-traitements sont de préférence réalisées via des messages MPI, un très petit temps d'attente et une largeur de bande élevée sont disponibles, et une grande fraction de la largeur de bande d'entrée/sortie obtenue par les traitements d'entrée/sortie sur les systèmes de fichiers, par exemple locaux, peut être délivrée à l'application. Il n'existe pas d'impératif obligatoire concernant le protocole de contrôle de transmission - protocole Internet TCP/IP dans le trajet de communications de données; (iv) la souplesse: du fait que tout trajet valide sur les noeuds informatiques peut être choisi pour conserver les fragments de fichier, l'utilisateur a une souplesse complète concernant la manière selon laquelle mémoriser les données, telle qu'en utilisant un dispositif de mémorisation sur mémoire extrêmement rapide pour des fichiers de travail ou un dispositif de mémorisation permanent pour d'autres types de fichiers. Ceci permet également un compromis entre des performances maximales et une accessibilité externe renforcée des fichiers.

Le système selon la présente invention supporte au moins trois manières pour spécifier l'emplacement où les fragments de fichier sont mémorisés, lesquels fragments constituent un fichier dans le système UDS. Elles sont déterminées par le nom du fichier lorsqu'il est créé dans le système de mémorisation UDS. Cette création peut être réalisée à l'aide d'une application MPI (en appelant la commande MPI File open()) ou via un outil externe. Une première manière possible spécifie un fichier via un trajet personnel, par exemple, un trajet commençant par ou -nom utilisateur' spécifie le répertoire principal des utilisateurs courants ou donnés sur chaque noeud informatique utilisé pour mémoriser un fragment de fichier. Habituellement, si les répertoires principaux sont montés à partir d'un serveur distant sur chaque noeud informatique, ceci va donner en résultat une faible largeur de bande et doit uniquement être utilisé pour des petits fichiers. Cependant, certains systèmes sont configurés pour attribuer à l'utilisateur un répertoire principal sur un système de fichiers local sur chaque noeud. Dans ces cas, une largeur de bande élevée peut être obtenue. Une deuxième manière concerne un trajet explicite, par exemple un trajet commençant par spécifie un trajet réel qui sera utilisé sur tous les noeuds informatiques. Ceci signifie que le trajet spécifié doit être valide sur tous ces noeuds, mais pas nécessairement pointé vers un système de fichiers local. Une largeur de bande élevée sera obtenue uniquement si le trajet conduit à un système de fichiers local. Une troisième manière concerne un trajet implicite, par exemple des trajets qui commencent par un métasigne et une chaîne dépendant du système, telle que '#local/'ou "#fcraid/'. Ces trajets virtuels seront ensuite résolus par le système UDS en utilisant une représentation plus complexe (spécifiée par l'utilisateur ou même dynamique) des noeuds dans des systèmes de fichiers.

Il existe essentiellement deux interfaces disponibles pour accéder à des fichiers, à savoir en utilisant l'interface MPI-IO et les outils de "ligne de commande". L'interface MPI-IO complète telle que définie dans la norme MPI-2 est supportée. Grâce à celle-ci, l'utilisateur peut créer ou ouvrir des fichiers, lire et écrire des données à partir d'un fichier ouvert à l'aide de diverses fonctions de lecture et d'écriture, rassembler des informations concernant le fichier et manipuler sa taille, fermer un fichier et supprimer un fichier. Des opérations telles que lister le contenu d'un répertoire, renommer, déplacer ou copier un fichier ne peuvent pas être directement supportées par cette interface. Pour exécuter des opérations sur des fichiers via l'interface MPI-I0, l'utilisateur a besoin d'exécuter une application MPI sur le système.

Lorsqu'un fichier est ouvert via la commande MPI File open() telle que celle fournie par l'interface MPI, les actions suivantes sont effectuées par le système UDS: 1) de préférence, une application individuelle unique AP du groupe de traitements qui ouvre le fichier (chef de groupe) contacte le serveur de noms UDS, en délivrant la liste de noeuds sur lesquels des traitements du groupe s'exécutent. La communication entre le chef de groupe et le serveur de noms est de préférence effectuée via le protocole TCP/IP en utilisant un mécanisme d'échange crypté ou d'autres moyens de cryptage, qui garantissent l'authenticité à un niveau de sécurité de système de fichiers. 2) Le serveur de noms représente le nom de fichier donné dans sa méta-représentation locale de l'espace de noms UDS complet, qui est mémorisé dans une hiérarchie de répertoires et de fichiers sur un système de fichiers local. Chaque fichier UDS est représenté par un métafichier dans cette hiérarchie qui contient toutes les informations pour accéder au fichier UDS distribué réel et ses attributs. 3) Si leserveur de noms trouve un métafichier correspondant, il indique que le fichier existe déjà, il passe les informations nécessaires au chef de groupe. Ces informations sont constituées pour la plus grande partie d'une liste <noeud,trajet> d'uplets qui décrit l'emplacement des fragments de fichier. 4) Si le serveur de noms ne trouve pas de métafichier correspondant, il indique que le fichier n'existe pas. Dans le cas où l'application souhaite créer le fichier, le serveur de noms crée le métafichier correspondant et renvoie une liste <noeud,trajet> d'uplets sur la base du trajet spécifié et la liste de noeuds qui étaient contenus dans la demande d'ouverture initiale du chef de groupe. 5) Le chef de groupe transmet la réponse à tous les traitements dans les groupes (les applications AP), qui génèrent alors collectivement les traitements d'entrée/sortie requis. De préférence, exactement un traitement d'entrée/sortie séparé (IOP) par noeud est fourni dans la liste. Cependant, pour certaines raisons, il serait avantageux d'exécuter plusieurs traitements d'entrée/sortie séparés sur un noeud. Toute communication entre les applications AP et les traitements IOP est de préférence effectuée via l'interface MPI qui garantit des performances élevées.

6) Les traitements IOP ouvrent (ou créent) les fragments de fichier locaux et notifient en retour les applications AP sur le succès de cette opération. Si tous les fragments de fichier peuvent faire l'objet d'un accès, les traitements IOP attendent des demandes de lecture/écriture (ou autres) entrantes des traitements d'application. 7) Chaque opération d'ouverture de fichier est approuvée ou annulée par le chef de groupe qui collecte les résultats de l'opération de toutes les applications AP et traitements IOP. Si une erreur apparaît, si par exemple, au moins un traitement IOP ne peut pas accéder à un fragment de fichier, ce problème est notifié au serveur de noms UDS. Si l'opération MPI File open() est associée à un fichier qui existait déjà, le serveur de noms va marquer le fichier comme étant corrompu. L'administrateur peut alors tenter de rétablir les fragments de fichier concernés. Si l'opération MPI File open() avait pour but de créer un nouveau fichier, la spécification de trajet n'était probablement pas valide sur tous les noeuds, et le métafichier qui a été créé est à nouveau supprimé.

Lorsque des données font l'objet d'un accès tel que par des opérations d'accès en lecture ou en écriture, les étapes suivantes sont exécutées dans le système UDS: 1) sur la base de la position de l'accès dans le fichier et du motif d'entrelacement des fragments de fichier qui était déterminé lorsque le fichier a été créé, chaque application individuelle AP peut calculer quel ensemble de traitements IOP est nécessaire pour desservir la demande. 2) Si l'application AP exécute un accès à un fichier individuel, elle envoie des demandes à chacun des traitements IOP correspondants et vérifie leur réponse d'une manière bloquante ou nonbloquante. 3) Pour des accès à des fichiers collectifs, par exemple toutes les applications AP effectuent un accès à un fichier synchronisé conjointement, une application AP par noeud informatique communique avec bon nombre (pas nécessairement tous) des traitements IOP au nom des autres traitements d'application sur le noeud. Les données provenant des traitements IOP ou allant vers ces derniers sont ensuite redistribuées à l'intérieur des applications AP, en utilisant une communication MPI intranoeuds et inter-noeuds. De telles optimisations sont uniquement possibles avec un accès à un fichier collectif; ceci est la raison pour laquelle un accès à un fichier collectif doit être utilisé à chaque fois que ceci est possible. 4) Les protocoles de transport traités par les traitements IOP incluent de préférence une communication MPI et un accès au fichier. Ces opérations peuvent être effectuées en pipeline pour augmenter le débit. De plus, les traitements IOP peuvent utiliser des opérations d'entrée/sortie asynchrones (si elles sont disponibles sur le système de fichiers donné) pour réaliser le chevauchement entre les communications MPI et les accès aux fichiers.

La seconde interface disponible pour accéder aux fichiers est fournie par des outils "de ligne de commande". Le système de fichiers UDS est situé au-dessus d'un système de fichiers natif et n'est pas visible en tant que tel en utilisant des commandes Unix classiques qui exécutent des opérations sur les fichiers telles que le listage des répertoires (1s), la suppression (rm), la copie (cp) ou la création de répertoires (mkdir). Ces outils peuvent uniquement agir sur les fragments de fichier distribués qui constituent un fichier UDS, mais n'ont pas connaissance de cette distribution. Par inadvertance, un utilisateur peut supprimer certains des fragments de fichier sans savoir que le fragment de fichier appartient à un fichier distribué. Pour cette raison, le système UDS va nommer les fragments de fichier de telle manière qu'il apparaisse clairement à l'utilisateur qu'il s'agit d'une partie d'un fichier UDS. De plus, le système UDS va inclure une plage d'utilitaires de lignes de commande qui offrent ces fonctions standards pour gérer les fichiers dans le système de fichiers. Après ces fonctions standards, des outils supplémentaires seront disponibles pour importer ou exporter un fichier à partir du système de fichiers UDS, par exemple copier un fichier à partir d'un système de fichiers standard visible sur un frontal vers un emplacement spécifié à l'intérieur du système de fichiers UDS, et vice versa, récupérer des informations spécifiques à un système UDS sur un fichier, ou même changer la distribution ou l'entrelacement d'un fichier UDS.

La présente invention va maintenant être davantage décrite en se reportant aux dessins annexés sur lesquels des références numériques analogues font référence à des parties analogues sur les diverses vues, et sur lesquels: - la figure 1 représente une configuration d'un premier mode de réalisation d'un système de mémorisation de données et d'accès à des données selon la présente invention, - la figure 2 représente une configuration d'un autre mode de réalisation selon la présente invention, - la figure 3 représente une configuration 5 d'un mode de réalisation supplémentaire selon la présente invention, - la figure 4 représente des exemples de composants permanents sur des noeuds informatiques selon la présente invention, - la figure 5 illustre une application effectuant un accès à un fichier nouvellement créé, - la figure 6 illustre une situation possible lorsqu'une application ouvre un fichier existant, - la figure 7 représente la situation 15 lorsqu'un fichier est importé dans l'espace de noms UDS en utilisant un outil de ligne de commande, - la figure 8 représente la situation lorsqu'un outil de ligne de commande interroge un serveur de noms quant à un état de fichier, - la figure 9 représente la situation lorsqu'un outil de ligne de commande sonde un fichier, et - la figure 10 indique un fichier entrelacé à travers de multiples noeuds.

L'architecture d'un système de mémorisation de données et d'accès à des données selon la présente invention est illustré sur la figure 1, représentant une communication et un flux de données entre des composants UDS, pour une configuration typique d'un centre informatique à performances élevées. La figure 1 représente deux scénarios typiques pour un système informatique à performances élevées ayant six noeuds informatiques 1-1 à 1-6, chacun avec un dispositif de mémorisation locale 5-1 à 5-6. Une application parallèle API est constituée de deux applications individuelles 3-1 (AP1N 0) et 3-2 (AP1N 1) s'exécutant sur les noeuds 1-1 et 1-2. Ces deux applications individuelles ou traitements viennent juste de créer un nouveau fichier, qui est entrelacé à travers les deux noeuds 1-1 et 1-2 exécutant l'application. Le fichier est constitué de deux fragments de fichier chacun mémorisé sur un dispositif de mémorisation locale 5-1 et 5-2, respectivement. Pour accéder au fichier, c'est-à-dire aux deux fragments de fichier, deux traitements d'entrée/sortie séparés IOP 4-1 (I0P1N 0) et 4-2 (I0P1N 1) sont engendrés. Cette configuration offre habituellement une meilleure largeur de bande possible. Un second scénario est représenté avec une application AP2, constituée de trois applications individuelles AP2N O, N 1 et N 2. Elles ont ouvert un fichier qui existe déjà. Il a été créé sur les noeuds 1-3 et 1-4. Pour accéder à ce fichier, c'est-à-dire aux deux fragments de fichier mémorisés sur les dispositifs de mémorisation 5-3 et 5-4, deux traitements d'entrée/sortie séparés, I0P2N O et I0P2N 1, ont été engendrés sur ces noeuds 1-3 et 1-4. L'emplacement des parties du fichier, les fragments de fichier, peut être choisi librement par un utilisateur et des droits d'administrateur ne sont pas obligatoirement nécessaires. Une gestion d'un système UDS, à savoir une mémorisation permanente d'un espace de noms du système de fichiers est effectuée par un serveur de noms 6 s'exécutant de préférence sur un système externe. Ce serveur de noms fournit à une application, c'est-à-dire à au moins l'une des applications individuelles 4-x, des informations indiquant comment accéder à un fichier qui a été mémorisé au préalable par l'exécution d'une autre application.

Une autre configuration matérielle selon la présente invention est représentée sur la figure 2. Un nombre de n noeuds informatiques 1-1 à 1n servent à exécuter une application parallèle et sont connectés par un commutateur IXS à temps d'attente faible et à largeur de bande élevée. De préférence, chaque noeud 1-1 à 1-n est équipé d'un dispositif de mémorisation locale 5-1 à 5-y qui est seulement visible sur ce noeud, où x est égal à n si sur chaque noeud exact d'un dispositif de mémorisation est fourni. L'accès au dispositif de mémorisation locale, qui est par exemple effectué via un Système de Fichiers Super-UX (SFS), fournit une largeur de bande élevée même pour des petits blocs, y compris une mise en cache. De plus, tous les noeuds 1- 1 à 1-n peuvent accéder à de nombreux grands réseaux de mémorisation partagés à distance 5-(y+l) à 5-1 via des liaisons de type Fibre Channel (FC), en utilisant par exemple un Système de Fichiers Réseau Global (GFS) fourni par les noeuds de mémorisation. L'accès à des systèmes de fichiers GFS à distance est habituellement beaucoup plus lent qu'à un système SFS, spécifiquement pour des petits blocs de données. Cependant, ces ensembles de mémorisation peuvent également faire directement l'objet d'un accès depuis les noeuds de mémorisation, qui peuvent également servir de noeuds frontaux pour un accès utilisateur interactif. Une connexion directe entre des systèmes frontaux 6-1 à 6-p et les noeuds 1-1 à 1-n est de préférence une liaison TCP/IP à largeur de bande faible telle qu'une Commutation Ethernet Gigabit. Au moins sur l'un de ces systèmes frontaux 6-x, un serveur de noms UDS s'exécute.

La première manière d'exploiter un tel système via le système UDS consiste à mémoriser des fichiers, et/ou des fragments de fichier sur les systèmes de fichiers SFS locaux, basés par exemple sur une mémoire ou un disque. Pour spécifier cela, un trajet UDS explicite, tel que "/uds' ou '/xmu' qui existe sur tous les noeuds, peut être utilisé. Si le système UDS est configuré en conséquence, un trajet implicite peut également être utilisé avec les mêmes performances. Un trajet personnel n'est pas recommandé pour une entrée/sortie à grande échelle du fait que les répertoires personnels sont habituellement montés via le système NFS. Le fait de procéder ainsi à l'aide de trajets implicites ou explicites offre les performances les plus élevées pour l'accès via l'interface MPI-I0. Cependant, l'importation ou l'exportation d'un fichier est plus lente lorsque les fichiers ont besoin d'être montés sur les systèmes de fichiers GFS partagés. Dans une configuration qui n'implémente pas de mémorisation partagée entre les systèmes frontaux 6-1 à 6-p et les noeuds informatiques 1-1 à 1-n, l'importation/exportation a besoin d'être effectuée via la liaison TCP/IP entre ces deux entités, entraînant en résultat des valeurs de largeur de bande faible pour les opérations d'importation/exportation.

La mémorisation à distance 5-(y+l) à 5-1 via le système GFS peut également être utilisée pour la mémorisation de fichiers à l'aide du système UDS. Cependant, ceci signifie habituellement que la représentation d'un noeud informatique sur un système de fichiers n'est plus nécessairement de type 1:1. Une représentation circulaire fixe des noeuds informatiques en systèmes de fichiers va fournir des performances sous-optimales pour tous les cas dans lesquels une application s'exécute sur de nombreux noeuds informatiques qui sont représentés dans le même système de fichiers. Au lieu de cela, le système UDS doit tenter de distribuer le fichier d'une manière régulière à travers les systèmes de fichiers disponibles, en utilisant une représentation dynamique de noeuds informatiques dans des systèmes de fichiers. Ceci peut signifier un système de fichiers par noeud informatique, mais d'autres distributions, par exemple plusieurs systèmes de fichiers par noeud et traitement IOP, ou une configuration dans laquelle seul un sous-ensemble des noeuds exécute un traitement IOP, sont également possibles. Le fait qu'il est efficace d'utiliser plus de systèmes de fichiers que de noeuds informatiques (actifs) dépend de la capacité du système de fichiers distant à effectuer une entrée/sortie asynchrone, ou requiert une fonctionnalité supplémentaire (processus) dans les traitements d'entrée/sortie.

Le système UDS va également supporter des applications d'entrée/sortie héritées aussi bien que possible. Cependant, un changement des appels d'entrée/sortie standards (open(), read(), write(), close()) en équivalents de MPI-IO correspondants (MPI File open(), MPI File read(), MPI File write(), MPI File close()) est obligatoire. Habituellement, il s'agit d'une tâche très simple. Une technique d'entrée/sortie typique dans une application d'héritage consiste à ce que chaque traitement accède à un fichier indépendant. Pour un accès en lecture, ces fichiers ou fragments de fichier ont besoin d'être placés dans un emplacement qui peut être atteint pendant un traitement. Sans système UDS, ceci signifie que les fichiers ou fragments de fichier sont placés sur un système de fichiers distant unique, qui n'est pas ensuite typiquement capable de fournir une largeur de bande suffisante pour tous les traitements effectuant un accès à leur fichier, ou ont besoin d'être copiés sur des systèmes de fichiers différents qui peuvent délivrer une largeur de bande accumulée plus élevée pour les accès aux fichiers concourants. Pour un accès en écriture, l'utilisateur doit prendre soin, après l'exécution du programme, de collecter tous les fichiers individuels ou fragments de fichier à partir des différents systèmes de fichiers et de les joindre éventuellement ensemble dans un fichier unique. Cette distribution manuelle peut devenir très complexe, spécialement si tous les traitements ne peuvent pas accéder à tous les systèmes de fichiers comme ceci est le cas lors de l'utilisation de systèmes de fichiers locaux des noeuds informatiques. Ceci amène de nombreux utilisateurs à utiliser l'approche plus lente. Pour de telles applications, le système UDS ne peut pas augmenter la largeur de bande par comparaison à la distribution manuelle optimale des fichiers. Cependant, il peut largement simplifier le procédé pour atteindre des performances similaires. Ceci est réalisé en important le répertoire avec les fichiers d'entrée d'une manière qui distribue les fichiers complets (pas d'entrelacement appliqué) à travers les systèmes de fichiers disponibles. L'application peut alors accéder à tous les fichiers en utilisant une spécification de trajet UDS implicite (virtuel) unique. Bien que la distribution qui est effectuée durant l'opération d'importation ne puisse pas fournir d'emplacement optimal (placer les fichiers sur le noeud sur lequel s'exécute un traitement) dans la plupart des cas, le concept de transfert tiers garantit que chaque traitement peut accéder au fichier à la largeur de bande MPI-IO ou locale (quoiqu'elle soit plus petite).

L'architecture de la figure 3 illustre une configuration typique d'un centre informatique à performances élevées. Le mode de réalisation de la figure 3 comporte quatre noeuds informatiques 1-1 à 1-4 qui exécutent des applications parallèles. Ils offrent plusieurs Unités Centrales de Traitement (CPU), dispositifs de mémoire et de mémorisation locale 5-1 à 5-4. La largeur de bande d'accès à ces dispositifs de mémorisation 5-1 à 5-4 est très élevée, même pour de plus petits blocs du fait que le système de fichiers est capable d'effectuer une mise en cache efficace. Cependant, l'accès peut uniquement être effectué par des traitements s'exécutant sur ce noeud. Typiquement, seule une petite fraction de la capacité de mémorisation locale est utilisée pour le système d'exploitation; en utilisant le système UDS, la capacité totale peut être utilisée pour des fichiers globalement visibles et accessibles. Les noeuds informatiques 1-1 à 1-4 sont connectés via une interconnexion de passation de message à temps d'attente faible et à largeur de bande élevée 8, utilisable via des messages MPI. Un frontal 10 est utilisé pour l'ouverture de session, le transfert de données, l'édition et la compilation et éventuellement la visualisation. Il s'agit d'un système ayant une mémorisation accessible à l'utilisateur limitée, par exemple tel que des répertoires personnels de l'utilisateur. Le frontal 10 est connecté aux noeuds informatiques 1-1 à 1-4 via Ethernet (Gigabit). Un système de mémorisation externe 11 conserve les fichiers de données plus grands de l'utilisateur, et habituellement différents espaces de travail. Ce système de mémorisation 11 est constitué d'un grand nombre d'ensembles de disques indépendants 5-5. Il est relié aux noeuds informatiques 1-1 à 1-4 et au frontal 10 via de multiples connexions de type Fibre Channel (FC) 9. Cependant, la largeur de bande maximale qu'un traitement unique sur un noeud informatique peut obtenir via cette connexion 9 est inférieure à celle des dispositifs de mémorisation locaux 5-1 à 5-4 du noeud informatique 1-1 à 1-4, spécialement pour des petites tailles d'accès. Après ces composants que chaque centre informatique utilise, un système séparé est utilisé pour exécuter le serveur de noms UDS 6. Le serveur de noms 6 gère tous les fichiers UDS distribués et fournit à ses clients les informations nécessaires pour récupérer les fragments qui constituent un fichier. Bien que le serveur de noms 6 puisse être exécuté sur le frontal 10 ou même sur l'un des noeuds informatiques 1-1 à 1-4, il est envisageable de l'exécuter sur un système séparé. Sans l'exécution d'un serveur de noms UDS 6, aucun fichier UDS ne peut être ouvert, et aucune information concernant l'espace de noms UDS n'est accessible. Par conséquent, il est important d'augmenter la disponibilité du système exécutant les serveurs de noms UDS. Pour réaliser cela, il est préféré d'exécuter de multiples serveurs de noms, par exemple redondants, 6-1 et 6-2 sur des hôtes séparés, comme représenté dans le mode de réalisation de la figure 3. Ces hôtes 6-1 et 6-2 ont besoin d'accéder à une base de données commune, qui est de préférence réalisée via un système de mémorisation séparé 12 ayant des caractéristiques de disponibilité élevée. Le serveur de noms 6 est connecté aux noeuds informatiques 1-1 à 1-4 et au frontal 10 via une liaison Ethernet (Gigabit). Un autre avantage au fait de ne pas exécuter le serveur de noms 6 sur l'un des noeuds informatiques 1-1 à 1-6 est la réduction de la charge de calcul non- associée aux applications s'exécutant sur le noeud. Il est également possible que des hôtes externes 13, tels que les stations de travail des utilisateurs aient accès au reste du système uniquement via le réseau Ethernet (Gigabit).

La figure 4 est la même architecture que la figure 3, mais représente certains composants logiciels supplémentaires du système UDS. Les composants permanents s'exécutent de préférence constamment sous un compte utilisateur spécial ou une racine et sont décrits sur la figure 4 par les références numériques 7-1 à 7-4. D'autres composants du système UDS sont exécutés de préférence à la demande et peuvent être observés dans les exemples de scénarios de la figure 5 à la figure 9. Le serveur de noms UDS 6 gère l'espace de noms UDS. Dans ce but, il maintient une base de données qui garde un enregistrement pour chaque fichier UDS et les fragments de fichier. De plus, un certain état global est maintenu de manière permanente dans cette base de données. Plusieurs serveurs de noms 6-1 et 6-2, comme représenté sur la figure 4 à la figure 10, peuvent être utilisés pour maintenir le système UDS disponible même si un serveur de noms connaît une défaillance pour une raison particulière. Le serveur de noms 6 est interrogé à chaque fois qu'un fichier UDS est créé, réouvert, fermé, déplacé, supprimé ou si des informations concernant l'état actuel d'un fichier UDS sont requises. Le serveur de noms 6 n'est pas requis pour l'accès effectif aux données de fichier. Les traitements d'entrée/sortie séparés 4-x (IOP) sont en fait une partie de l'application MPI de l'utilisateur (AP), mais ne sont pas visibles à l'utilisateur où x est un nombre entier naturel. Les traitements d'entrée/sortie séparés sont engendrés par un composant UDS à l'intérieur de la bibliothèque MPI juste au moment où l'application ouvre un fichier UDS. Au moins un traitement d'entrée/sortie séparé 4-x est lancé sur chaque noeud sur lequel se trouvent des fragments du fichier UDS. Dans certaines situations spécifiques, il peut également être préférable que plusieurs traitements d'entrée/sortie séparés soient lancés sur un noeud, ou qu'un traitement d'entrée/sortie séparé soit lancé sur un noeud sur lequel ne se trouve pas le fragment de fichier voulu lui-même mais sur un disque partagé qui est connecté à ce noeud. Pour un nouveau fichier, ceux- ci sont (par défaut) les noeuds sur lesquels l'application, c'est-à-dire les applications individuelles 3-x, s'exécutent. Les traitements d'entrée/sortie séparés communiquent avec les traitements d'application via des messages MPI. Les démons UDS 7-x (udsd) sont exécutés sur les noeuds informatiques 1-x en tant que traitement de service.

Ils sont nécessaires pour fournir des informations concernant des fragments de fichier UDS au serveur de noms 6 et aux outils de ligne de commande UDS 8. De plus, ils sont utilisés pour effectuer un ensemble limité d'actions sur les fragments, telles que la suppression, la copie, etc. Les démons s'exécutent de préférence comme des traitements résidents sous la racine, mais peuvent également être lancés à la demande, par exemple sous le compte de l'utilisateur respectif, si des traitements résidents ne sont pas souhaités. Les outils de ligne de commande UDS 8 permettent à l'utilisateur de gérer l'espace de noms UDS également depuis l'extérieur, par exemple des hôtes non-informatiques 13. Les outils de ligne de commande 8 donnent des listes de répertoire et délivrent des informations d'état de fichiers, et sont également utilisés pour échanger des fichiers entre l'espace de noms UDS et tout système de fichiers externe. Les outils de ligne de commande 8 peuvent être exécutés sur tout noeud externe 10, 13 qui peut se connecter au serveur de noms 6 et au noeuds informatiques 1-x, par exemple via le protocole TCP/IP. Les exemples de scénarios donnés sur la figure 5 à la figure 9 représentent les composants UDS actifs, leurs relations et activités d'accès aux fichiers impliquées dans la réalisation d'une certaine tâche. Ces activités sont décrites ci-dessous pour illustrer l'interaction des composants UDS pour les tâches typiques effectuées par un utilisateur.

Une application MPI effectuant des accès à un fichier UDS nouvellement créé est illustrée sur la figure 5. Une application MPI d'un utilisateur, par exemple larry, est constituée dans cet exemple de six traitements ou applications individuelles 3-1 à 3-6, s'exécutant sur des noeuds informatiques 1-2, 1-3 et 1-4. L'application ouvre un fichier nommé uds:/uds/larry/output data.dat. Du fait que le serveur de noms 6 ne connaît pas ce fichier, un nouveau fichier est créé. Le nouveau fichier va de préférence être entrelacé à travers tous les noeuds 1-2 à 1-4 sur lesquels l'application s'exécute actuellement.

Cependant, il est également possible, si on le souhaite, d'entrelacer le fichier à travers un quelconque noeud voulu comme représenté par exemple sur la figure 1. Le nom de fichier implique que le fichier soit mémorisé dans le trajet/uds/larry, représenté dans un système de fichiers local sur chaque noeud informatique 1-2, 1-3 et 1-4. Par conséquent, ce répertoire doit exister et être accessible à l'utilisateur sur tous les noeuds impliqués. Toutes les activités d'entrée/sortie sont effectuées par les traitements d'entrée/sortie séparés 4-x (IOP) qui ont été engendrés par le système UDS lorsque le fichier a été ouvert. Une fois que les traitements d'entrée/sortie séparés 4-x ont créé des fragments de fichier sur les noeuds 1-2 à 1-4, ils réalisent tous les accès au fichier au nom des traitements d'application 3-x. L'échange de données entre les applications individuelles 3-x et les traitements d'entrée/sortie séparés 4-x est effectué via des messages MPI, à la fois à l'intérieur d'un noeud et entre des traitements sur des noeuds différents.

La situation dans laquelle une application MPI ouvre un fichier UDS existant est illustrée sur la figure 6. Dans cet exemple, une application MPI, constituée de deux traitements 3-1 et 3-2 s'exécute sur un noeud informatique 1-1. Elle ouvre actuellement un fichier UDS existant, qui a été préalablement créé par une autre exécution d'une application. Le traitement 3-1 de l'application se connecte au serveur de noms 6-2 pour obtenir les informations indiquant la manière d'accéder au fichier. Le serveur de noms 6-2 indique à l'application individuelle 3-1 que le fichier est constitué d'un fragment unique, qui se trouve sur le noeud informatique 1-2. Pour accéder à ce fichier, le système UDS engendre le traitement d'entrée/sortie séparé 4-1 sur ce noeud informatique 1-2, qui accède au fichier et échange les données avec l'application 3-1, 3-2 en utilisant des messages MPI.

L'utilisation d'un outil de ligne de commande 8 tel que de l'importation d'un fichier dans l'espace de noms UDS est illustré sur la figure 7. Dans cet exemple, l'utilisateur harry souhaite transférer un fichier d'entrée, qui est actuellement situé dans son format natif sur le système de mémorisation externe (nom de fichier /ext/home/harry/input.dat), dans l'espace de noms UDS. Du fait que l'utilisateur doit effectuer des lectures répétées à partir de ce grand fichier, l'utilisateur souhaite qu'il soit placé aussi proche des traitements d'application que possible. Par conséquent, il est de préférence placé sur les disques locaux 5-x. Du fait que l'utilisateur exécute typiquement son application 3-x sur les deux noeuds informatiques 1-1 et 1-4, il décide d'entrelacer le fichier à travers deux noeuds, également. Pour réaliser cela, il appelle la commande 8-1: udscp -p -f 2 - n 1-1, 1-4/ext/home/harry/input.dat uds:/usd/harry à partir du noeud frontal 10. L'option -f 2 définit le nombre de fragmentsde fichier (facteur d'entrelacement) à deux. La commande de copie (udscp) des outils de ligne de commande 8 rentre en contact avec le serveur de noms 6 (6-1), qui lui indique les noeuds à utiliser. Ensuite, la commande de copie (udscp) se connecte aux démons 7- 1 et 7-4 (udsd) sur chacun de ces noeuds 1-1 et 1-4, qui engendrent un traitement enfant 70-1 et 70-4 en tant que traitement de service pour répondre aux demandes de cet utilisateur, où le traitement de service 70- 1 et 70-4 s'exécute dans le contexte de l'utilisateur demandeur. Pour effectuer l'action demandée, les traitements de service 70-1 et 70- 4 transfèrent les parties respectives du fichier d'entrée vers l'emplacement spécifié sur les disques locaux 5-1 et 5-4 (/uds/harry). Du fait que l'utilisateur a fourni l'option -p, les traitements de service 70-1 et 70-4 accèdent tous deux directement au fichier d'entrée et le lisent en parallèle via le réseau de mémorisation. Les traitements de service n'ont pas à échanger de données quelconques l'un avec l'autre durant cette importation. Si le fichier d'entrée n'est pas directement accessible aux traitements de service, comme s'il était mémorisé sur un disque local du noeud frontal, la commande de copie 8-1 (udscp) envoie le fichier au traitement de service via la même connexion utilisée pour envoyer la demande au démon 7-x.

La situation lorsqu'un outil de ligne de commande 8 interroge le serveur de noms 6 est illustrée sur la figure 8. Un autre utilisateur souhaite avoir des informations d'état concernant un fichier UDS spécifique. L'utilisateur utilise un outil de ligne de commande UDS différent 8-1 (udsls) dans ce but. La commande 8-1 (udsls) contacte le serveur de noms 6 et délivre les informations à l'utilisateur. Si l'utilisateur avait ajouté l'option -n à sa commande, la commande udsls vérifie les informations reçues en provenance du serveur de noms avec l'état actuel des fragments de fichier sur les noeuds. Cette vérification est effectuée en contactant les démons UDS.

Un autre exemple d'utilisation d'un outil de ligne de commande 8 pour sonder un fichier UDS est représenté sur la figure 9. Comme dans le précédent exemple, l'utilisateur a indiqué qu'il n'exige pas que les informations renvoyées soient les informations les plus actuelles disponibles, il suffit de renvoyer les informations dont le serveur de noms 6 dispose dans sa base de données. Cependant, si en même temps une application avait ouvert le fichier pour y ajouter des données, certaines informations telles que la taille de fichier renvoyé par le serveur de noms 6 ne vont pas correspondre à la taille accumulée réelle des fragments sur les noeuds. Pour obtenir ces informations actualisées, la commande udsls va contacter les démons 7-x sur les noeuds respectifs 1-x. Ce cas est représenté pour l'outil de ligne de commande UDS 8-1 qui est exécuté par exemple sur le système externe 13.

2870951 40 Après la connexion au serveur de noms 6-1, cet outil a également une connexion à un traitement de service généré par le démon 701 sur le noeud informatique 1-1. Ce traitement de service rassemble des informations actualisées concernant le fragment de fichier mémorisé dans le disque local 5-1 et le délivre à la commande udsls.

On doit noter que l'utilisation du système UDS n'est pas du tout limitée à l'exemple de configuration cité ci-dessus, et aux activités présentées. Du fait de sa souplesse, l'utilisateur peut également créer des fichiers UDS sur le système de mémorisation externe de cette configuration, ou exploiter toute autre configuration non-couverte par

cet exemple.

Dans un mode de réalisation préféré de la présente invention, un but consiste à fournir une largeur de bande d'entrée/sortie modulable pour accéder à un fichier unique avec une application MPI. La largeur de bande doit par conséquent être modulée selon la taille de l'application. Dans ce contexte, la taille d'une application prend en considération le nombre de traitements également appelés applications individuelles utilisés pour exécuter l'application.

Typiquement, ceci est directement lié à la taille du problème traité par cette application, et à la quantité d'entrée/sortie que cette application doit réaliser. L'utilisation d'un nombre croissant de traitements pour une application signifie l'utilisation d'un plus grand nombre de noeuds informatiques du fait qu'il existe 2870951 41 souvent un rapport fixe dépendant du système entre le nombre de traitements et le nombre de noeuds utilisés pour exécuter les traitements. Pour moduler la largeur de bande d'entrée/sortie en fonction du nombre de noeuds 1-x, chaque fichier UDS est distribué à travers un nombre arbitraire de noeuds d'une manière régulière: le fichier est de préférence divisé linéairement en blocs de taille fixe, et le premier bloc de données est mémorisé sur le premier noeud, le deuxième bloc sur le deuxième noeud etc. Pour n noeuds conservant les blocs du fichier, le (n+l)-ième bloc est à nouveau mémorisé sur le premier noeud, en utilisant un motif de distribution circulaire. Ce type de distribution est appelé entrelacement. La taille des blocs est appelée unité d'entrelacement, et le nombre de noeuds utilisés pour distribuer le fichier est appelé facteur d'entrelacement. La figure 10 illustre la distribution entrelacée d'un fichier unique 20 entre un nombre de trois noeuds 1-1 à 1-3 en commençant par le noeud 1-1. Les fichiers partiels obtenus en résultat 20-1, 20-2 et 20-3 sur chaque noeud sont les fragments ou des fragments de fichier.

Du fait que chaque noeud 1-x accède à ses blocs de données indépendamment des autres noeuds, la largeur de bande de tous ces accès concurrents atteint la largeur de bande totale disponible pour l'application. Cependant, pour une exploitation complète de ce résultat, il est nécessaire que chaque noeud utilise un système de mémorisation qui est indépendant de tous les autres noeuds. Ceci peut être réalisé en utilisant les disques locaux des noeuds, qui ne sont pas visibles à l'extérieur du noeud. Si les noeuds 1-x utilisent des dispositifs de mémorisation 11 qui sont partagés entre les noeuds, la largeur de bande effective telle qu'exploitée par l'application peut être inférieure à la largeur de bande qu'un noeud unique exploite par le nombre de noeuds. Le degré de cette dégradation dépend des caractéristiques du dispositif de mémorisation utilisé, et de la manière selon laquelle l'application accède au fichier. Dans le pire des cas, les multiples noeuds peuvent accéder au fichier avec une largeur de bande accumulée qui n'est pas supérieure à la largeur de bande exploitée par un noeud unique. Dans ce mode de réalisation préféré, le système UDS crée un nouveau fichier sur tous les noeuds sur lesquels l'application MPI s'exécute. Le meilleur emplacement pour le fichier se trouve sur les disques locaux 5-1 à 5-4 d'un noeud. Cependant, le système UDS ne se limite pas à créer un nouveau fichier à tout emplacement quelconque prédéfini sur les noeuds. Au lieu de cela, du fait que les fragments sont juste des fichiers réguliers, ils peuvent être placés sur un quelconque système de fichiers et représentés dans un dispositif de mémorisation situé sous celui-ci, qui est visible sur les noeuds. L'utilisateur a la liberté totale de placer un fichier UDS dans l'emplacement qu'il souhaite, en fonction de ces besoins en termes de largeur de bande d'entrée/sortie, de capacité, d'accessibilité externe et autres facteurs, par exemple tels que la persistance limitée du contenu du système de fichiers due à des politiques système. Pour aider l'utilisateur dans la spécification des emplacements de mémorisation concernant un fichier, le système UDS supporte au moins trois types différents de spécifications de trajet comme décrit en détail ci-dessus.

D'un point de vue utilisateur, l'utilisation de système UDS depuis une application MPI est très simple et exige uniquement l'utilisation d'un nom de fichier UDS. Tous les objets MPI restent supportés lors de l'utilisation d'un système UDS. Les applications MPI qui vont utiliser le système UDS restent des applications MPI normales et sont lancées en utilisant les commandes de lancement mpirun et mpiexec, d'une manière classique. Pour accéder à des fichiers UDS depuis l'interface MPI, il est uniquement nécessaire de fournir un nom de fichier à la fonction MPI concernée, tel que "MPI _ File_ open()", qui implique une spécification de trajet UDS comme décrit en détail ci-dessus. Un nouveau fichier va alors être entrelacé à travers tous les noeuds 1-x exécutant des traitements qui sont une partie du dispositif de communication passé à la fonction "MPI File open()". Si un trajet implicite était utilisé, le fichier sera entrelacé à travers tous les noeuds 1-1 à 1-n, qui sont associés à ce trajet implicite. Il est également possible de spécifier explicitement les noeuds à utiliser, ou le facteur d'entrelacement. Si un fichier existant est ouvert, il restera de préférence entrelacé à travers ces noeuds sur lesquels il a été entrelacé lorsqu'il a été créé. Le système UDS garantit que les données entre les noeuds sur lesquels les applications individuelles 3-x de l'application 3 s'exécutent, et les noeuds qui mémorisent le fichier, sont efficacement échangées. Des informations de fichier supplémentaires peuvent être délivrées par l'application 3 à la bibliothèque MPI en utilisant des objets "MPI Info" lors de l'ouverture d'un fichier. Vice versa, la bibliothèque MPI délivre des informations concernant un fichier UDS ouvert qui peuvent être récupérées en utilisant également des objets MPI Info. L'interface MPI-IO définit un format de données commun pour les éléments de type MPI unique écrits dans un fichier. Ce format de données peut être choisi en utilisant la représentation de données externe32. Cependant, pour un espace de noms UDS unique qui fait l'objet d'un accès par plusieurs applications MPI s'exécutant dans le système sur la base d'une bibliothèque MPI, le système UDS est capable de gérer par exemple le format de données relatif au mode boutiste des fichiers automatiquement pour délivrer à chaque application une vue correcte des données dans le fichier même en cas d'utilisation de la représentation de données par défaut.

Le système UDS est capable de gérer différents formats de données, dans lequel une gestion particulière va être décrite plus en détail. Selon un mode de réalisation, le système UDS établit les paramètres d'ordre d'octets (gros-boutiste ou petit-boutiste) de fichiers UDS au moment d'une création via l'interface MPI-I0. Lorsqu'un fichier est tout d'abord créé, le type boutiste (gros ou petit) utilisé pour les données écrites dans ce fichier par cette application est le type boutiste natif de la machine utilisée. Ceci signifie que le contenu d'un fichier nouvellement créé devient une copie binaire exacte des données en mémoire. Le type boutiste d'un fichier UDS peut être déterminé en utilisant l'outil de ligne de commande udsstat. De préférence, il n'est pas envisagé de changer le type boutiste d'un fichier UDS du fait que ceci va entraîner une corruption de données en cas d'utilisation incohérente. Cependant, l'outil de ligne de commande udsadmin permet d'établir le type boutiste d'un fichier UDS. Certaines plate-formes supportent un mode de largeur étendue qui augmente la taille des types de données de nombre entier et de données à virgule flottante à au moins 8 octets. Si un nouveau fichier est créé, et que la représentation de données est établie à externe32 avant que des données quelconques aient été écrites dans le fichier, le système UDS va également mémoriser les caractéristiques de format de données associées. Dans ces cas, le système UDS gère ce format de données étendu de la même manière qu'il gère différents formats boutistes. De même, ces attributs de fichier peuvent être récupérés et établis depuis l'extérieur via les outils de ligne de commande udsstat et udsadmin. Pour des fichiers UDS qui ne sont pas créés via l'interface MPI-IO, mais via l'interface externe, ces attributs de fichier peuvent nécessiter d'être spécifiés d'une manière explicite.

Lorsqu'un fichier UDS existant est ouvert via l'interface MPI-IO pour une lecture ou écriture, le type boutiste des données est automatiquement transformé pour correspondre à la fois à la représentation requise des données dans la mémoire de la machine sur laquelle l'application s'exécute et au paramétrage boutiste mémorisé du fichier UDS. Ceci s'applique pour tous les types de données MPI à octets multiples prédéfinis, et également pour les éléments conformes de types de données MPI dérivés. Ceci signifie que si la machine boutiste natif est différente du paramétrage boutiste du fichier, l'ordre d'octets de tous les éléments de données sera changé lors de toutes les opérations de lecture et d'écriture. Si à la fois le boutiste de la machine et le paramètre boutiste du fichier, sont identiques, les données sont directement transférées entre la mémoire et le fichier.

Naturellement, la largeur de bande d'accès au fichier sera supérieure pour un accès à un fichier qui n'implique pas de réordonnancement des octets.

Il est possible de privilégier la transformation de données implicites en imposant un certain type boutiste d'un fichier. Ceci peut être effectué en passant un objet "MPI Info" approprié à une fonction "MPI File open()" ou "MPI File set info()".

Cet objet doit contenir la clé endian file qui supporte les valeurs indiquant gros, petit et natif. Les valeurs gros et petit amènent toutes les données écrites à être transformées dans le format boutiste respectif avant qu'elles soient mémorisées dans le fichier. De même, des données lues à partir du fichier seront supposées avoir le format boutiste indiqué et seront transformées en boutiste natif de la machine avant d'être mémorisées en mémoire. Pour la valeur native, les opérations équivalentes sont effectuées sur la base du format boutiste natif de la machine. Du fait que l'utilisation de ce procédé privilégie explicitement le format boutiste du fichier comme géré par le système UDS, le système UDS ne va pas changer le paramétrage permanent du format boutiste du fichier avec le serveur de noms.

Ceci implique le risque de corrompre des données d'un fichier si la transformation de données explicites est incorrectement utilisée. La transformation de boutiste implicite, dans le présent mode de réalisation, s'applique uniquement à des fichiers qui font l'objet d'un accès via l'interface MPI-IO, en utilisant la représentation de données native. Si un fichier fait l'objet d'un accès via l'interface externe du système UDS, les données sont lues à partir de la mémoire ou écrites dans celle-ci sans aucune transformation. Si le fichier fait l'objet d'un accès via l'interface MPI-IO via une représentation de données différente de native, les données sont transformées uniquement conformément à la représentation de données utilisée, sans transformation quelconque de boutiste implicite. Si des données sont écrites dans le fichier à cette occasion, le système UDS va marquer le paramétrage boutiste de ce fichier comme étant inconnu. La même chose est vraie pour les fichiers UDS qui n'ont pas été créés via l'interface MPI-IO, mais via l'interface externe.

L'accès à des fichiers UDS ayant un paramètre de boutiste inconnu via l'interface MPI-IO va faire en sorte que l'opération de lecture/écriture va générer l'erreur MPI ERR FORMAT si la représentation de données native est en place et l'opération de lecture/écriture utilise un type de données MPI qui requiert une transformation de boutiste. Les données seront transférées entre la mémoire et le fichier sans aucune transformation de données effectuée. Ceci signifie, si l'application sait comment manipuler les données correctement, qu'elle peut se poursuivre en dépit de cette condition d'erreur.

Si le type boutiste des noeuds sur lesquels des traitements d'une application MPI unique ne sont pas les mêmes pour tous les noeuds, le paramétrage boutiste de ce fichier sera inconnu depuis le début, si on utilise la représentation de données native. Dans ce cas, il est recommandé d'utiliser la représentation de données externe32 qui va établir le type boutiste à gros.

La description détaillée ci-dessus est destinée uniquement à illustrer certains modes préférés de réalisation de la présente invention. Elle n'est en aucun cas destinée à limiter la portée de la présente invention telle que définie dans les revendications.

2870951 49

Claims (39)

REVENDICATIONS

1. Système de mémorisation de données et d'accès à des données destiné à être utilisé avec un ou plusieurs systèmes de traitement parallèle comportant une pluralité de noeuds (1-1, 1-2, ..., 1-n) pour une application (3) d'entrée/sortie de fichier parallèle, caractérisé en ce que: a) ladite application (3) est divisée en une pluralité d'applications individuelles (3-1, 3-2, 3-k) et chacune desdites applications individuelles (3-1, 3-2, ..., 3-k) peut s'exécuter sur un noeud individuel (1-1, 1-2, ..., 1-n), b) un fichier de données (2) accessible pour ladite application est divisé en une pluralité de fragments de fichier (2-1, 2-2, ..., 2-m), c) lesdits fragments de fichier (2-1, 2-2, ..., 2-m) sont mémorisés dans une pluralité de moyens de mémorisation indépendants (5-1, 5-2, 5-1) accessibles dans le système de traitement parallèle, d) au moins un traitement d'entrée/sortie séparé (4-1, 4-2, ..., 4-o) est lancé par une application individuelle (3-1, 3-2, ..., 3-k) sur un noeud (1-1, 1-2, 1-n), qui comporte un accès aux moyens de mémorisation (5-1, 5-2, ..., 51) comportant le fragment de fichier (2-1, 2-2, ..., 2-m) qui fait l'objet d'un accès par l'application (3), e) les applications individuelles (3-1, 3-2, 3-k) et lesdits traitements d'entrée/sortie séparés (4-1, 4-2, ..., 4-o) communiquent via des message d'Interface de Passage de Message (MPI), f) au moins un moyen d'informations de distribution (6) est adapté pour délivrer des informations de la distribution des fragments de fichier (2-1, 2-2, ..., 2-m) à au moins l'une des applications individuelles (3-1, 3-2, ..., 3-k), et g) dans lequel le système de mémorisation de données et d'accès à des données est basé au- dessus d'un système de fichiers disponible natif des noeuds (1-1, 1-2, ... , 1-n).

2. Système de mémorisation de données et d'accès à des données destiné à être utilisé avec un ou plusieurs systèmes de traitement parallèle comportant une pluralité de noeuds (1-1, 1-2, ..., 1-n) pour une application (3) d'entrée/sortie de fichier parallèle, caractérisé en ce que: a) ladite application (3) est divisée en une pluralité d'applications individuelles (3-1, 3-2, 3-k) et chacune desdites applications individuelles (3-1, 3-2, ..., 3-k) peut s'exécuter sur un noeud individuel (1-1, 1-2, ..., 1-n), b) un fichier de données (2) accessible pour ladite application est divisé en une pluralité de fragments de fichier (2-1, 2-2, ..., 2-m), c) lesdits fragments de fichier (2-1, 2-2, 2-m) sont mémorisés dans une pluralité de moyens de mémorisation indépendants (5-1, 5-2, 5-1) accessibles dans le système de traitement parallèle, d) dans lequel les données d'un fichier de données (2) peuvent être lues et/ou mémorisées et/ou créées et/ou transformées dans/entre des représentations de type de données différentes dans une mémoire et le fichier (2) mémorisé dans les différents moyens de mémorisation.

3. Système selon la revendication 2, caractérisé en ce qu'au moins un traitement d'entrée/sortie séparé (4-1, 4-2, ..., 4-o) est lancé par une application individuelle (3-1, 3-2, ..., 3-k) sur un noeud (1-1, 1-2, ..., 1-n), qui comporte un accès aux moyens de mémorisation (5-1, 5-2, ..., 51) comportant le fragment de fichier (2-1, 2-2, ..., 2-m) qui fait l'objet d'un accès par l'application (3).

4. Système selon la revendication 3, caractérisé en ce que les applications individuelles (3-1, 3-2, 3-k) et lesdits traitements d'entrée/sortie séparés (4-1, 4-2, ..., 4-o) communiquent via des messages d'Interface de Passage de Message (MPI).

5. Système selon la revendication 2, 3 ou 4, caractérisé en ce qu'il comporte au moins un moyen d'informations de distribution (6) adapté pour délivrer des informations de la distribution des fragments de fichier (21, 2-2, ..., 2-m) à au moins l'une des applications individuelles (3-1, 32, ..., 3-k).

6. Système selon l'une quelconque des revendications 2 à 5, caractérisé en ce que le système de mémorisation de données et d'accès à des données est basé au-dessus d'un système de fichiers disponible natif des noeuds (1-1, 1-2, ..., 1-n).

7. Système selon l'une quelconque des 30 revendications 2 à 6, caractérisé en ce que les données 2870951 52 sont transformées lors d'un transfert à partir de la mémoire vers les moyens de mémorisation.

8. Système selon l'une quelconque des revendications 2 à 7, caractérisé en ce que les données 5 sont transformées lors d'un transfert à partir des moyens de mémorisation vers la mémoire.

9. Système selon l'une quelconque des revendications 2 à 8, caractérisé en ce que la transformation de données est prévue pour des fichiers qui font l'objet d'un accès via une interface MPI-I0.

10. Système selon l'une quelconque des revendications 2 à 9, caractérisé en ce que le système fournit une transformation de données implicite entre des représentations de type de données différentes.

11. Système selon l'une quelconque des revendications 2 à 10, caractérisé en ce qu'un utilisateur peut explicitement spécifier une transformation de données via une interface MPI-IO.

12. Système selon l'une quelconque des revendications 2 à 11, caractérisé en ce que le type de données boutiste natif de la machine sur laquelle l'application s'exécute est utilisé lors d'une création d'un nouveau fichier (2) avec une interface MPI-IO.

13. Système selon l'une quelconque des revendications 2 à 12, caractérisé en ce que, lorsqu'un fichier existant (2) est ouvert via une interface MPI-IO pour effectuer une lecture ou une écriture, un boutisme des données est automatiquement transformé pour correspondre à la fois à la représentation des données dans la mémoire de la machine sur laquelle 2870951 53 l'application s'exécute et à un paramétrage boutiste mémorisé du fichier (2).

14. Système selon l'une quelconque des revendications 2 à 13, caractérisé en ce que l'ordre d'octets de tous les éléments de données va être changé lors de toutes opérations de lecture et d'écriture lorsqu'un type boutisme natif de la machine est différent d'un paramétrage boutiste du fichier (2).

15. Système selon l'une quelconque des revendications 2 à 13, caractérisé en ce que les données sont directement transférées entre la mémoire et le fichier lorsqu'un boutisme natif de la machine est identique à un paramétrage boutiste du fichier (2).

16. Système selon l'une quelconque des revendications 2 à 15, caractérisé en ce que des attributs de fichier de différentes représentations de type de données peuvent être récupérés et établis depuis l'extérieur via des outils de ligne de commande.

17. Système selon l'une quelconque des revendications 2 à 16, caractérisé en ce que lors d'un accès à un fichier via une interface externe, les données sont lues à partir de la mémoire ou écrites dans celle-ci sans aucune transformation.

18. Système selon l'une quelconque des revendications 2 à 17, caractérisé en ce qu'un format de données peut être l'un du groupe constitué de: type gros-boutiste, type petit-boutiste, externe32 ou toute autre représentation de type de fichier commune.

19. Système selon l'une quelconque des revendications 1 à 18, caractérisé en ce que chaque application individuelle (3-1, 3-2, ..., 3-k) peut être autorisée à accéder à tout le fichier de données (2).

20. Système selon l'une quelconque des revendications 1 ou 3 à 19, caractérisé en ce qu'un seul traitement d'entrée/sortie séparé (4-1, 4-2,

., 4-o) est lancé par l'application sur un noeud (1-1, 1-2, ..., 1-n), qui comporte l'accès aux moyens de mémorisation (5-1, 5-2, ..., 5-1) comportant le fragment de fichier (2-1, 2-2, ..., 2-m) qui fait l'objet d'un accès par l'application (3)...CLMF:

21. Système selon l'une quelconque des revendications 1 à 20, caractérisé en ce que le système de mémorisation de données n'est pas limité à utiliser des noeuds prédéfinis (1-1, 1-2, ..., 1-n), des moyens de mémorisation (5-1, 5-2, ..., 5-1) et des trajets sur ces noeuds (1-1, 1-2, ..., 1-n).

22. Système selon l'une quelconque des revendications 1 à 21, caractérisé en ce qu'au moins un des moyens de mémorisation (5-1, 5-2, ..., 5-1) est un dispositif de mémorisation locale d'un noeud (1-1, 1-2, 1-n).

23. Système selon l'une quelconque des revendications 1 à 22, caractérisé en ce qu'au moins un des moyens de mémorisation (5-1, 5-2, ..., 5-1) est un dispositif de mémorisation partagé d'une pluralité de certains noeuds (1-1, 1-2, ..., 1-n).

24. Système selon l'une quelconque des

revendications 1 à 23, caractérisé en ce que

l'utilisateur et/ou un administrateur système est autorisé à spécifier où les fragments de fichier (2-1, 2-2, ..., 2-m) doivent être mémorisés.

25. Système selon l'une quelconque des revendications 1 à 24, caractérisé en ce que l'accès à 5 un fichier de l'application (3) est commandé par l'application (3) et les applications individuelles (3-1, 3-2, ..., 3-k) elles-mêmes.

26. Système selon l'une quelconque des revendications 1 à 25, caractérisé en ce que le système 10 fournit une visibilité globale de chaque fichier de données (2) constitué d'une pluralité de fragments de fichier (2-1, 22, ..., 2-m).

27. Système selon l'une quelconque des revendications 1 à 26, caractérisé en ce que le système comporte une pluralité de moyens d'informations de distribution (6-1, 6-2, ..., 6-p).

28. Système selon l'une quelconque des revendications 1 à 27, caractérisé en ce que le système fournit des programmes de service (8) pour accéder, lister, supprimer et modifier le fichier de données (2) par des commandes globales.

29. Système selon l'une quelconque des

revendications 1 à 28, caractérisé en ce que

l'application peut s'exécuter sur un ordinateur parallèle ou sur une pluralité d'ordinateurs connectés via un réseau.

30. Système selon l'une quelconque des revendications 1 à 29, caractérisé en ce que les fragments de fichier (2-1, 2-2, 2-m) et des dispositifs de mémorisation sont accessibles via un système de fichiers natif.

31. Système selon l'une quelconque des revendications 1 à 30, caractérisé en ce que chaque noeud (1-1, 1-2, ..., 1-n) est capable d'exécuter lesdites applications individuelles (3-1, 3-2, ..., 3-k) et est capable de fournir un accès d'entrée/sortie à un fragment de fichier voulu (2-1, 2-2, ..., 2-m).

32. Système selon l'une quelconque des revendications 1 ou 5 à 31, caractérisé en ce que les moyens d'informations de distribution (6) s'exécutent sur un ou plusieurs desdits noeuds (1-1, 1-2, ..., 1-n) ou sur au moins un noeud supplémentaire.

33. Système selon l'une quelconque des revendications 1 ou 5 à 32, caractérisé en ce que les moyens d'informations de distribution (6) maintiennent une base de données qui conserve un enregistrement de chaque fichier (2) et le fragment de fichier correspondant (2-1, 2-2, ..., 2-m).

34. Système selon l'une quelconque des revendications 1 ou 5 à 33, caractérisé en ce que les moyens d'informations de mémorisation (6) fournissent un espace de noms de système pour gérer la mémorisation et l'accès à ces fichiers (2).

35. Système selon l'une quelconque des revendications 1 ou 5 à 34, caractérisé en ce que sur chaque noeud (1-1, 1-2, ..., 1-n), un démon (71, 7-2, 7-n) est prévu pour délivrer des informations des fragments de fichier aux moyens d'informations de distribution (6).

36. Système selon la revendication 35, caractérisé en ce que chaque démon s'exécute en tant que traitement résident ou peut être lancé à la demande sous le compte d'utilisateur respectif.

37. Système selon l'une quelconque des revendications 1 ou 5 à 36, caractérisé en ce que la communication entre l'application (3) des applications individuelles (3-1, 3-2, ..., 3-k) et les moyens d'informations de distribution (6) est effectuée via un protocole TCP/IP.

38. Système selon la revendication 37, caractérisé en ce que des mécanismes d'échange crypté pour la communication TCP/IP sont utilisés.

39. Système selon l'une quelconque des revendications 1 ou 5 à 38, caractérisé en ce que les moyens d'informations de distribution (6) représentent un nom de fichier d'un fichier (2) dans une métareprésentation locale qui contient toutes les informations pour accéder aux fragments de fichier distribués (2-1, 2-2, ..., 2-m).