WO2019129958A1 - Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees - Google Patents

Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees Download PDF

Info

Publication number
WO2019129958A1
WO2019129958A1 PCT/FR2018/053447 FR2018053447W WO2019129958A1 WO 2019129958 A1 WO2019129958 A1 WO 2019129958A1 FR 2018053447 W FR2018053447 W FR 2018053447W WO 2019129958 A1 WO2019129958 A1 WO 2019129958A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
processes
servers
slices
application
Prior art date
Application number
PCT/FR2018/053447
Other languages
English (en)
Inventor
Philippe Couvee
Simon Derr
Antoine PERCHER
Original Assignee
Bull Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull Sas filed Critical Bull Sas
Priority to US16/958,314 priority Critical patent/US11561934B2/en
Priority to EP18842433.7A priority patent/EP3732560A1/fr
Publication of WO2019129958A1 publication Critical patent/WO2019129958A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01W—METEOROLOGY
    • G01W1/00—Meteorology
    • G01W1/10—Devices for predicting weather conditions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/183—Provision of network file services by network file servers, e.g. by using NFS, CIFS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Definitions

  • a first disadvantage of this first prior art is that this more complex and more expensive technology, especially for several applications each managing a large amount of data, makes the overall system complex and expensive.
  • the invention aims at providing a data storage method and an application execution method, which, rather than being limited to reducing the time of each file access or only to optimize the calculation time applications, and in particular to seek to over-optimize this computing time applications, considers that it is particularly interesting on the one hand to seek to streamline and organize the access time to files stored by applications, and on the other hand to carry out this rationalization and this organization in an efficient way, first by basing itself on the actual progress of the applications and on their effective interaction, by observing them in their actual functioning, and then by proposing principles of rationalization and the stored file access strategy, which will be more independent of both the type of server and the rs storing data and the type of applications taking place, thus offering increased robustness to changes.
  • a method of storing, on storage spaces of data servers, slices of data files resulting from the execution of several processes of one or more applications comprising: a distribution slices of data files stored on different storage spaces of different data servers, characterized in that: this distribution is carried out so that slices of data files that can be accessed later simultaneously by different processes of application are stored on different storage spaces of different data servers, so as to reduce subsequent access to each of all or part of these storage spaces simultaneously by too many application processes, and in that: Determine which data file slices can be accessed simultaneously by different app processes During a preliminary phase of execution of these application processes, the application of the behavior of these application processes to access, over time, these slices of stored data files was carried out.
  • the processes of the application include repetitive calculations.
  • the data file slices are immediately and directly stored in the right places which will then reduce the access time to these slices of data files.
  • FIG. 6 schematically represents an example of a first phase of several application processes using the solution proposed by the storage method according to one embodiment of the invention.
  • the largest calculators also called supercomputers, are today composed of several thousand independent compute nodes, such as compute node 1, collectively running one or more parallel applications, that is, an application. executes on a large number of calculation nodes 1 simultaneously.
  • the compute node 1 has a data file 5 to store.
  • the file 5 is divided into eight slices 51 to 58.
  • the data storage strategy is a random strategy, that is to say that the file slices are stored randomly on all the data disk spaces that have been assigned to the data file 5, here the data spaces 31 and 32 of the data server 3 and the data spaces 41 and 42 of the data server 4.
  • the data server 3 stores the slices 51 and 55 on the data disk space 31 and the slices 52 and 56 on the data disk space 32.
  • the data server 4 stores the slices 53 and 57 on the data disk space 41 and the slices 54 and 58 on the disk space 42 of data.
  • the data represents a local version of a four-column matrix data model. If the size of a column is of the same order of magnitude as that of a slice of file, or even just a multiple of a slice of file, we find a correspondence between the columns of the matrix and the storage slices files 61 to 64.
  • FIG. 5 schematically represents an example of a second phase of the unfolding of several application processes generating the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • the four processes 65 to 68 of applications will have to access over time, whether for a reading of data or for a writing of data, to their respective files stored on the servers 100 to 103 as detailed in FIG. Chance here doing things wrong, at the same time, the process 65 wants to access the slot 611 stored on the server 100, the process 66 wants to access 76 to the slice 622 still stored on the server 100, the process 67 wants to make an access 77 to the slot 633 still stored on the server 100, the process 68 wants to make an access 78 to the slot 644 still stored on the server 100.
  • FIG. 6 schematically represents an example of a first phase of several application processes using the solution proposed by the storage method according to one embodiment of the invention.
  • the solution proposed by this embodiment to solve this problem consists here in directing the creation of the files 61 to 64 on a set of data servers 100 to 103 from previous observations of executions of the processes 65 to 68 of the application or applications to determine the future behavior in terms of simultaneous access to the files 61 to 64.
  • an analysis can be performed to detect simultaneous accesses performed by the application processes 65 to 68 or applications.
  • the accesses are classified by access periods and by file regions accessed as a slot number, as shown in the table of Figure 6.
  • the first slice 621 is stored on the server 100
  • the second slice 622 is stored on the server 101
  • the third slice 623 is stored on the server 102
  • the fourth slice 624 is stored on the server 103.
  • the first slice 631 is stored on the server 100
  • the second slice 632 is stored on the server 101
  • the third slice 633 is stored on the server 102
  • the fourth slice 634 is stored on the server 103.
  • the strategy will consist here in deducing from the table of FIG. 6 that the slices of one and the same rank of these four files 61 to 64 would ideally be placed on different data servers 100 to 103, in order to make them all work simultaneously and in parallel, during the second and third periods of time. This corresponds to the ideal distribution of files 61 to 64 on data servers 100 to 103 as shown in FIG.
  • Different applications 83 or different application process (s), are instrumented so that their behavior is observed during the execution of their execution.
  • an observation software 82 of the behavior of these applications 83 observes their behavior to determine the profile of each of the applications 83. Once determined, the profile of each application 83 is stored on an archival space 81 application profiles 83.
  • Optimal application parameterization software 84 reads on the archiving space 81 of the profiles of the applications 83, the profiles of the applications. With the aid of these application profiles, this optimal application programming software 84 will parameterize each of the applications so that it becomes an instrumented application 85 for the acceleration of its behavior, and more specifically for the reduction of its time. data exchange with the data storage servers.
  • the applications 85 will be launched with the acceleration library which will be parameterized by analyzing the previous behaviors recorded in the knowledge base stored on the repository space 81
  • the acceleration library will then tell the file system how to distribute the file slots on the disk space so as to avoid future conflicts of access and thus optimize the performance in terms of execution time in particular.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Environmental & Geological Engineering (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Ecology (AREA)
  • Environmental Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de stockage, sur des serveurs (3, 4) de données, de tranches (51 à 58) de fichiers (5, 61 à 64) de données issues de l'exécution de plusieurs processus (65 à 68) d'une ou de plusieurs applications (83, 85), comprenant : une répartition des tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées sur différents serveurs (3, 4) de données, caractérisé en ce que : cette répartition est réalisée de manière à ce que des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d'être accédées ultérieurement simultanément par différents processus (65 à 68) d'application (83, 85) soient stockées sur différents serveurs (3, 4) de données, de manière à réduire l'accès ultérieur, à chacun de tout ou partie de ces serveurs (3, 4) de données, simultanément par trop de processus (65 à 68) d'application (83, 85), et en ce que : la détermination des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d'être accédés simultanément par différents processus (65 à 68) d'application (83, 85) a été effectuée, lors d'une phase préalable d'exécution de ces processus (65 à 68) d'application (83, 85), par l'observation du comportement de ces processus (65 à 68) d'application (83, 85) pour accéder, au cours du temps, à ces tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées.

Description

PROCEDE DE STOCKAGE DE DONNEES ET PROCEDE D’EXECUTION D’APPLICATION AVEC REDUCTION DU TEMPS
D’ACCES AUX DONNEES STOCKEES
DOMAINE DE L’INVENTION
L’invention concerne le domaine des procédés de stockage de données avec une réduction du temps d’accès aux données stockées, ainsi que le domaine des procédés d’exécution d’application(s) correspondants utilisant ces procédés de stockage de données.
CONTEXTE DE L’INVENTION
Selon un premier art antérieur, puisque le temps d’accès aux fichiers stockés, que ce soit en lecture ou en écriture, est un temps globalement non négligeable dans le temps total de déroulement d’une application, il est prévu de diminuer ce temps d’accès aux fichiers stockées, en rendant plus rapide chaque opération de lecture et chaque opération d’écriture, souvent au prix d’une technologie plus complexe et plus coûteuse.
Un premier inconvénient de ce premier art antérieur est que cette technologie plus complexe et plus coûteuse, en particulier pour plusieurs applications gérant chacune un grand nombre de données, rend le système global complexe et coûteux.
Un deuxième inconvénient de ce premier art antérieur est que, selon l’invention, même une fois que chaque opération de lecture et chaque opération d’écriture a été rendue très rapide, s’il y en a un grand nombre à effectuer, et ceci est en particulier le cas pour plusieurs applications gérant chacune un grand nombre de données, le temps global d’accès aux fichiers stockées reste important, voire très important, à l’échelle du temps global de déroulement des applications. Ce temps d’accès aux fichiers stockés est particulièrement notable à l’échelle du déroulement des applications, lors le déroulement de ces applications s’effectue au cours d’un processus très volumineux de traitement de données, comme par exemple un gros calcul, car alors, les nombreuses phases périodiques de sauvegarde des données (« checkpoint » en langue anglaise) occupent intrinsèquement une proportion importante du temps global de déroulement de ce processus de traitement, par exemple de l’ordre de 10 à 20 minutes toutes les heures.
Selon un deuxième art antérieur, l’optimisation du temps de déroulement est surtout centrée sur la réduction du temps de calcul des applications.
D’une part, ce second art antérieur souvent ne s’occupe que de diminuer le temps de calcul de l’application car celui-ci est considéré comme mieux maîtrisé et comme plus important. Toutefois, selon l’invention, diminuer le temps d’entrée / sortie, c’est-à-dire de lecture et/ou d’écriture à chaque sauvegarde de résultat partiel, va pouvoir d’abord devenir payant car ce temps de sauvegarde peut prendre de 10% à 30% du temps d’exécution total d’une application, et ensuite peut être réalisé quelle que soit la logique interne de l’application.
D’autre part, dans ce deuxième art antérieur, la gestion des accès aux zones de stockage et la gestion des goulots d’étranglement associés sont souvent considérées comme susceptibles de générer un surcoût important dissuasif, ce qui sera d’autant plus vrai que les calculs des applications sont répétitifs, car alors la gestion des goulots d’étranglement deviendrait un problème chronique. Cependant, selon l’invention, ceci n’est pas tout à fait le cas, surtout si cette gestion est effectuée par observation du comportement d’accès des processus de l’application aux zones de stockage lors de l’exécution en conditions réelles de l’application, et qu’elle est suivie d’une adaptation correspondante de la répartition des zones de stockage pour les données en fonction de la manière dont ces données vont devoir être ultérieurement accédées par les processus de l’application.
Enfin, la gestion du temps d’entrée / sortie pourrait être faite en amont de l’exécution de l’application, c’est-à-dire au niveau d’une optimisation de la répartition des données qui serait alors réalisée par une phase de conception en amont laquelle bien sûr économiserait alors le temps de la phase d’observation. Mais, selon l’invention, ceci serait réalisé au prix de deux inconvénients majeurs qui seraient d’une part la totale dépendance de l’application par rapport à un seul type de système de stockage et d’autre part l’accroissement de la difficulté de développement de l’application devant intégrer cette contrainte supplémentaire.
RESUME DE L’INVENTION
Le but de la présente invention est de fournir un procédé de stockage palliant au moins partiellement les inconvénients précités.
Plus particulièrement, l’invention vise à fournir un procédé de stockage de données et un procédé d’exécution d’application, qui, plutôt que de se limiter soit à réduire le temps de chaque accès fichier ou bien à seulement optimiser le temps de calcul des applications, et en particulier à chercher à sur-optimiser ce temps de calcul des applications, considère qu’il est particulièrement intéressant d’une part de chercher à rationaliser et à organiser le temps d’accès aux fichiers stockés par les applications, et d’autre part à effectuer cette rationalisation et cette organisation de manière efficace, d’abord en se basant sur le déroulement effectif des applications et sur leur interaction effective, en les observant dans leur fonctionnement effectif, et ensuite en proposant des principes de rationalisation et d’organisation au niveau de la stratégie d’accès aux fichiers stockés, laquelle sera plus indépendante à la fois du type de serveurs stockant les données et du type d’applications se déroulant, offrant ainsi une robustesse accrue aux changements.
A cette fin, la présente invention propose un procédé de stockage qui peut s’adapter soit à des tranches de fichiers de données, soit même à des groupes de données, ou encore à des tranches d’objets de données, ce stockage étant effectué sur différents serveurs de données, ou même sur différents espaces de stockage de serveurs de données, ces différents espaces de stockage de serveurs de données, ou bien ces différents serveurs de données, étant accessibles séparément et indépendamment les uns des autres par des applications extérieures à leurs serveurs de données. A cette fin, la présente invention propose également un procédé d’exécution de processus d’application(s) correspondant à l’un ou à l’autre de ces procédés de stockage, et plus particulièrement au procédé de stockage de tranches de fichiers de données sur différents serveurs de données.
Selon l’invention, il est d’abord prévu un procédé de stockage, sur des serveurs de données, de tranches de fichiers de données issues de l’exécution de plusieurs processus d’une ou de plusieurs applications, comprenant : une répartition des tranches de fichiers de données stockées sur différents serveurs de données, caractérisé en ce que : cette répartition est réalisée de manière à ce que des tranches de fichiers de données susceptibles d’être accédées ultérieurement simultanément par différents processus d’application soient stockées sur différents serveurs de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs de données, simultanément par trop de processus d’application, et en ce que : la détermination des tranches de fichiers de données susceptibles d’être accédés simultanément par différents processus d’application a été effectuée, lors d’une phase préalable d’exécution de ces processus d’application, par l’observation du comportement de ces processus d’application pour accéder, au cours du temps, à ces tranches de fichiers de données stockées.
Ainsi, il est obtenu une diminution notable de la moyenne du temps d’entrée / sortie, en lecture et/ou en écriture de données, pour toutes les phases de calcul, pour prix d’une augmentation seulement ponctuelle lors d’une ou plusieurs phases de calcul initiales permettant de mieux répartir les données stockées en fonction de leur accès ultérieur au cours du temps par les différents processus d’application. Cela permet donc d’éviter les engorgements au niveau des serveurs de données. Selon l’invention, il est ensuite prévu un procédé de stockage, sur des espaces de stockage de serveurs de données, de tranches de fichiers de données issues de l’exécution de plusieurs processus d’une ou de plusieurs applications, comprenant : une répartition des tranches de fichiers de données stockées sur différents espaces de stockage de différents serveurs de données, caractérisé en ce que : cette répartition est réalisée de manière à ce que des tranches de fichiers de données susceptibles d’être accédées ultérieurement simultanément par différents processus d’application soient stockées sur différents espaces de stockage de différents serveurs de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces espaces de stockage, simultanément par trop de processus d’application, et en ce que : la détermination des tranches de fichiers de données susceptibles d’être accédés simultanément par différents processus d’application a été effectuée, lors d’une phase préalable d’exécution de ces processus d’application, par l’observation du comportement de ces processus d’application pour accéder, au cours du temps, à ces tranches de fichiers de données stockées.
Ainsi, il est obtenu une diminution notable de la moyenne du temps d’entrée / sortie, en lecture et/ou en écriture de données, pour toutes les phases de calcul, pour prix d’une augmentation seulement ponctuelle lors d’une ou plusieurs phases de calcul initiales permettant de mieux répartir les données stockées en fonction de leur accès ultérieur au cours du temps par les différents processus d’application. Cela permet donc d’éviter les engorgements au niveau des espaces de stockage gérés par les serveurs de données.
Selon l’invention, il est également prévu un procédé d’exécution de plusieurs processus d’une ou de plusieurs applications, comprenant : une première phase d’observation du déroulement desdits processus et de leur manière d’accéder au cours du temps aux données stockées pendant ladite exécution, pendant laquelle la détermination des tranches de fichiers de données susceptibles d’être accédés simultanément par différents processus d’application est effectuée, une deuxième phase de paramétrage du stockage des données par lesdits processus sur des serveurs de données et sur leurs espaces de stockage, associant aux tranches de fichiers de données des espaces de stockage sur les serveurs de données, une troisième phase de répartition des tranches de fichiers de données stockées sur différents serveurs de données et sur leurs espaces de stockage, cette répartition étant réalisée de manière à ce que les tranches de fichiers de données susceptibles d’être accédées ultérieurement simultanément par différents processus d’application soient stockées sur différents serveurs de données, le cas échéant sur différents espaces de stockage de ces serveurs de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs de données, le cas échéant de ces espaces de stockage, simultanément par trop de processus d’application.
Selon l’invention, il est encore prévu un procédé de stockage, sur des serveurs de données, de données issues de l’exécution de plusieurs processus, comprenant : une répartition des données stockées sur différents serveurs de données, caractérisé en ce que : cette répartition est réalisée de manière à ce que des groupes de données susceptibles d’être accédés ultérieurement simultanément par différents processus soient stockés sur différents serveurs de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs de données, simultanément par trop de processus, et en ce que : la détermination des groupes de données susceptibles d’être accédés simultanément par différents processus a été effectuée, lors d’une phase préalable d’exécution de ces processus, par l’observation du comportement de ces processus pour accéder, au cours du temps, à ces groupes de données stockées.
Selon l’invention, il est enfin prévu un procédé de stockage, sur des serveurs de données, de tranches d’objets de données issues de l’exécution de plusieurs processus d’une ou de plusieurs applications, comprenant : une répartition des tranches d’objets de données stockées sur différents serveurs de données, caractérisé en ce que : cette répartition est réalisée de manière à ce que des tranches d’objets de données susceptibles d’être accédées ultérieurement simultanément par différents processus d’application soient stockées sur différents serveurs de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs de données, simultanément par trop de processus d’application, et en ce que : la détermination des tranches d’objets de données susceptibles d’être accédés simultanément par différents processus d’application a été effectuée, lors d’une phase préalable d’exécution de ces processus d’application, par l’observation du comportement de ces processus d’application pour accéder, au cours du temps, à ces tranches d’objets de données stockées.
Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles, avec l’un ou l’autre des objets de l’invention précités.
De préférence, ladite détermination des tranches de fichiers de données susceptibles d’être accédés simultanément par différents processus d’application a été effectuée, lors d’une phase préalable d’exécution de ces processus pour une seule application ou bien application par application en cas de pluralité d’applications, par l’observation du comportement de ces processus d’une seule application à la fois pour accéder, au cours du temps, à ces tranches de fichiers de données stockées.
Ainsi, l’optimisation de la répartition des données est seulement réalisée au niveau de chaque application. Ceci est beaucoup plus simple et rapide et presqu’ aussi efficace que de la réaliser simultanément pour plusieurs applications susceptibles d’être simultanément exécutées.
De préférence, la ou les applications sont portables sur d’autres types de serveurs de stockage de données.
Ainsi, l’application est donc indépendante d’un système de stockage de données, et cela est rendu possible car l’optimisation de la répartition des données est réalisée en aval, par une phase d’observation du comportement de l’application, au lieu d’être réalisée par une phase de conception en amont laquelle certes économiserait le temps de la phase d’observation mais au prix de deux inconvénients majeurs qui sont d’une part la totale dépendance de l’application par rapport à un seul type de système de stockage et d’autre part l’accroissement de la difficulté de développement de l’application intégrant cette contrainte supplémentaire.
De préférence, les processus de l’application incluent des calculs répétitifs.
Ainsi, la phase d’observation va offrir un excellent compromis, à savoir être simple et courte et permettre une optimisation élevée de la répartition des zones de stockage des données entraînant une diminution importante du temps d’entrée / sortie au cours du déroulement de l’exécution de l’application.
De préférence, lesdits calculs répétitifs incluent des calculs de prévisions météorologiques.
Ainsi, les calculs de prévisions météorologiques sont un exemple particulièrement critique de calculs très répétitifs et très complexes, c’est-à- dire requérant beaucoup de ressources mais permettant une optimisation élevée de la répartition des zones de stockage de données pouvant entraîner une réduction importante du temps d’entrée / sortie au cours du déroulement de G exécution de 1’ applic ation .
De préférence, la ou les applications sont exécutés au sein d’un réseau comprenant plusieurs milliers de nœuds de calcul, de préférence au moins 5000 nœuds de calcul, de préférence au moins 10000 nœuds de calcul.
Ainsi, l’optimisation du stockage étant d’autant plus complexe et critique dans ce type de grand réseau, l’invention devient alors d’autant plus intéressante.
De préférence, à chaque fichier sont associés une taille maximale de tranche de fichier pouvant être stockée d’un coup et un nombre maximal d’espaces de stockage sur lesquels ce fichier peut être stocké, la taille maximale de tranche de fichier restant de préférence inférieur à 2 Mo (Mo = Mégaoctet) et valant avantageusement 1 Mo, le nombre maximal d’espaces de stockage restant de préférence inférieur à 10 et valant avantageusement
5.
Ainsi, ce découpage du fichier en tranches et cette distribution des tranches sur plusieurs espaces de stockage permet de diminuer encore mieux les accès simultanés du même espace de stockage par trop de processus d’application.
De préférence, ladite répartition des tranches de fichiers de données stockées sur différents serveurs de données ou sur différents espaces de stockage de différents serveurs de données, est réalisée par une bibliothèque de fonctions qui : d’une part intercepte les créations de fichiers de données, d’autre part réalise le stockage des tranches de ces fichiers de données sur les espaces de stockage sur les serveurs de données qui leur ont été associés lors de ladite phase préalable d’exécution des processus d’application.
Ainsi, les tranches de fichiers de données sont immédiatement et directement stockées aux bons endroits qui réduiront ensuite le temps d’accès à ces tranches de fichiers de données.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés.
BREVE DESCRIPTION DES DESSINS
La figure 1 représente schématiquement un exemple de système de stockage auquel peut s’appliquer le procédé de stockage selon un mode de réalisation de l’invention.
La figure 2 représente schématiquement un exemple de déroulement d’un procédé de stockage aléatoire susceptible de générer le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
La figure 3 représente schématiquement un exemple de stockage de données de plusieurs fichiers d’applications sur plusieurs serveurs générant le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
La figure 4 représente schématiquement un exemple d’une première phase de déroulement de plusieurs processus d’applications générant le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
La figure 5 représente schématiquement un exemple d’une deuxième phase de déroulement de plusieurs processus d’applications générant le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
La figure 6 représente schématiquement un exemple d’une première phase de déroulement de plusieurs processus d’applications utilisant la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
La figure 7 représente schématiquement un exemple d’une deuxième phase de déroulement de plusieurs processus d’applications utilisant la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
La figure 8 représente schématiquement un exemple de synthèse de la phase d’observation du procédé de stockage selon un mode de réalisation de l’invention.
La figure 9 représente schématiquement un exemple de synthèse de la phase de paramétrage du procédé de stockage selon un mode de réalisation de l’invention.
DESCRIPTION DETAILLEE DE L’INVENTION
La figure 1 représente schématiquement un exemple de système de stockage auquel peut s’appliquer le procédé de stockage selon un mode de réalisation de l’invention. Un nœud de calcul 1 déroule un calcul et a besoin de temps en temps de lire et/ou d’écrire des données dans les serveurs 3 et 4 de données à l’aide d’un serveur 2 de métadonnées. Le serveur 3 de données (OSS pour « object storage server » en langue anglaise) comprend plusieurs espaces disques 31 à 33 de données (OST pour « object storage target » en langue anglaise). Le serveur 4 de données comprend plusieurs espaces disques 41 à 43 de données. Le serveur 2 de métadonnées (MDS pour « meta data server » en langue anglaise) comprend plusieurs espaces disques 41 à 43 de métadonnées (MDT pour « meta data target » en langue anglaise).
Le langage utilisé par le nœud de calcul pour communiquer avec les serveurs 2 à 4 est par exemple le langage Lustre (langage logiciel libre ou « open source » en langue anglaise). Le nœud de calcul 1 envoie une requête 11 d’ouverture de fichier au serveur 2 de métadonnées. Le serveur 2 de métadonnées renvoie une réponse 12 contenant des attributs et des identifiants de fichier. Parmi ces attributs, se trouvent une taille de bloc de découpage du fichier de données à stocker ainsi qu’une liste de serveurs de données ou bien même une liste d’espaces disques de données. Le nœud de calcul 1 envoie au serveur 3 de données une requête 13 de lecture de données ou une requête 14 d’écriture de données. Le serveur 3 de données lit ou écrit les données sur l’un des espaces disques 31 à 33 de données. Le nœud de calcul 1 envoie au serveur 4 de données une requête 15 de lecture de données ou une requête 16 d’écriture de données. Le serveur 4 de données lit ou écrit les données sur l’un des espaces disques 41 à 43 de données.
Les plus grands calculateurs, encore appelés supercalculateurs, sont aujourd’hui composés de plusieurs milliers de nœuds de calcul indépendants, comme le nœud de calcul 1, exécutant collectivement une ou plusieurs applications parallèles, c’est-à-dire qu’une application s’exécute sur un grand nombre de nœuds de calculs 1 simultanément.
Ces supercalculateurs utilisent en général, pour l’accès aux données d’entrée et pour l’écriture des résultats, un système de fichier lui-même parallèle, composé en général de plusieurs dizaines de serveurs comme les serveurs 3 et 4 de données.
La figure 2 représente schématiquement un exemple de déroulement d’un procédé de stockage aléatoire susceptible de générer le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
Le nœud de calcul 1 a un fichier 5 de données à stocker. Le fichier 5 est découpé en huit tranches 51 à 58. La stratégie de stockage de données est une stratégie aléatoire, c’est-à-dire que les tranches de fichiers sont stockées de manière aléatoire sur l’ensemble des espaces disques de données qui ont été affectés au fichier 5 de données, ici les espaces disques 31 et 32 de données du serveur 3 de données et les espaces disques 41 et 42 de données du serveur 4 de données. Le serveur 3 de données stocke les tranches 51 et 55 sur l’espace disque 31 de données et les tranches 52 et 56 sur l’espace disque 32 de données. Le serveur 4 de données stocke les tranches 53 et 57 sur l’espace disque 41 de données et les tranches 54 et 58 sur l’espace disque 42 de données.
Lors de la création d’un fichier 5, le système de fichier doit choisir quels serveurs 3 ou 4 de données et quels espaces disque 31 à 33 et/ou 41 à 43 seront utilisés pour stocker son contenu. Les algorithmes utilisés aujourd’hui se basent sur une méthode de type aléatoire (« round robin » en langue anglaise) dans le but de répartir les données de façon aléatoire sur l’ensemble des serveurs 3 et 4 de données et favoriser un remplissage homogène.
Le principe est que l’on fixe à l’avance une taille de tranche élémentaire de données (« stripe » en langue anglaise) et un nombre d’espaces disques 31 à 43 pour chaque fichier 5 à créer.
Avec ces deux valeurs fixées respectivement à par exemple 1 Mégaoctets pour la taille de la tranche et à quatre pour le nombre d’espaces disques 31 et 32 et 41 et 42 sur serveurs 3 et 4 de données, on pourra alors avoir la répartition aléatoire telle que représentée sur la figure 2 pour un fichier de 8 Mégaoctets. Les quatre espaces 31 et 32 et 41 et 42 disques ont été choisis aléatoirement par le système de fichier pour assurer un remplissage homogène.
La figure 3 représente schématiquement un exemple de stockage de données de plusieurs fichiers d’applications sur plusieurs serveurs générant le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
Quatre fichiers 61 à 64 de données contenant chacun quatre tranches de données doivent être stockés sur quatre serveurs de données 100 à 103. Avec une stratégie aléatoire de stockage, le stockage réalisé est par exemple le suivant.
Pour le fichier 61, la première tranche 611 est stockée sur le serveur 100, la deuxième tranche 612 est stockée sur le serveur 101, la troisième tranche 613 est stockée sur le serveur 102, la quatrième tranche 614 est stockée sur le serveur 103.
Pour le fichier 62, la première tranche 621 est stockée sur le serveur 103, la deuxième tranche 622 est stockée sur le serveur 100, la troisième tranche 623 est stockée sur le serveur 101, la quatrième tranche 624 est stockée sur le serveur 102.
Pour le fichier 63, la première tranche 631 est stockée sur le serveur
102, la deuxième tranche 632 est stockée sur le serveur 103, la troisième tranche 633 est stockée sur le serveur 100, la quatrième tranche 634 est stockée sur le serveur 101.
Pour le fichier 64, la première tranche 641 est stockée sur le serveur 101, la deuxième tranche 642 est stockée sur le serveur 102, la troisième tranche 643 est stockée sur le serveur 103, la quatrième tranche 644 est stockée sur le serveur 100.
Les applications scientifiques présentent différents comportements types en ce qui concerne l’accès aux données. Un comportement type fréquent est le mode dit « fichier par processus » dans lequel chaque processus de l’application parallèle, et il y en a jusqu’à plusieurs dizaines de milliers, crée un fichier 5 pour y stocker les résultats qu’il a calculé. En général, une étape ultérieure agrège ces résultats partiels pour les exploiter plus facilement ensuite.
Lors de la création d’une telle quantité de fichiers 5 par une application, il est fréquent que plusieurs fichiers 5 soient créés sur les mêmes espaces disques 31 à 43, compte tenu de leur nombre limité par rapport au nombre de nœuds de calcul 1. Cependant, la sélection des espaces disques 31 à 43 étant faite au moment de la création du fichier 5, ce mécanisme ne peut pas prendre en compte les profils d’accès futurs aux fichiers 5, et en particulier le fait que ces accès soient effectués simultanément par plusieurs processus sur leurs fichiers 5 respectifs, ce qui a pour effet de diviser la performance d’accès entre tous les processus qui l’utilisent.
La solution classique à ce problème consiste, comme expliqué préalablement, à répartir les données de tous les fichiers 5 en découpant chacun en tranches 51 à 58 réparties à tour de rôle sur chacun des espaces disques 31 et 32 et 41 et 42 des serveurs 3 et 4. Mais ce mécanisme ne permet toujours pas de répondre à tous les cas d'usage, et certains restent particulièrement problématiques.
Ainsi, l'exemple d'une application parallèle à quatre processus d’applications, A, B, C et D. Chacun de ces processus stocke ses données respectivement dans les fichiers 61 à 64 qui sont tous découpés en quatre tranches et réparti sur quatre serveurs de données 100 à 103. Afin d'éviter les problèmes évoqués précédemment, la répartition des données sur les serveurs 100 à 103 est décalée de manière différente dans chacun des fichiers 61 à 64, comme montré sur la figure 3.
La figure 4 représente schématiquement un exemple d’une première phase de déroulement de plusieurs processus d’applications générant le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention. Quatre processus 65 à 68 d’applications vont devoir accéder au cours du temps, que ce soit pour une lecture de données ou pour une écriture de données, à leurs fichiers respectifs stockés sur les serveurs 100 à 103 comme détaillé à la figure 3.
Les données représentent une version locale d'un modèle matriciel de données à quatre colonnes. Pour peu que la taille d'une colonne soit du même ordre de grandeur que celui d'une tranche de fichier, ou bien alors même juste un multiple d’une tranche de fichier, on retrouve une correspondance entre les colonnes de la matrice et les tranches de stockage des fichiers 61 à 64.
La figure 5 représente schématiquement un exemple d’une deuxième phase de déroulement de plusieurs processus d’applications générant le problème résolu par la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
Les quatre processus 65 à 68 d’applications vont devoir accéder au cours du temps, que ce soit pour une lecture de données ou pour une écriture de données, à leurs fichiers respectifs stockés sur les serveurs 100 à 103 comme détaillé à la figure 3. Le hasard faisant ici mal les choses, au même moment, le processus 65 veut faire un accès 75 à la tranche 611 stockée sur le serveur 100, le processus 66 veut faire un accès 76 à la tranche 622 stockée toujours sur le serveur 100, le processus 67 veut faire un accès 77 à la tranche 633 stockée toujours sur le serveur 100, le processus 68 veut faire un accès 78 à la tranche 644 stockée toujours sur le serveur 100. Le serveur 100, auquel les quatre processus 65 à 68 veulent faire quatre accès 75 à 78 simultanés, ne va pouvoir répondre à ces requêtes qu’avec une vitesse quatre fois moindre que sa vitesse nominale, ce qui va multiplier par quatre le temps global de réalisation des quatre accès 75 à 78. Voici un exemple d’augmentation drastique du temps global d’accès lorsque des accès simultanés tombent mal sur le même serveur, serveur sur lequel les données ont été stockées avec une stratégie aléatoire. Pour des raisons de dépendance entre les données, à la fin du calcul, chacun des processus 65 à 68 commence à écrire dans son fichier résultat les données de la colonne correspondant à son rang dans l'application de calcul parallèle. Le résultat est alors que tous les processus « attaquent » en même temps le même serveur de données, ici le serveur 100.
La conséquence immédiate de ce comportement est un débit instantané du serveur 100 qui est divisé par quatre par rapport au cas optimal. Il s’agit ici d’un cas particulièrement pathologique mettant en œuvre une application particulière avec des tailles de structures de données particulièrement problématiques. Mais souvent, dans une réalité statistiquement plus fréquente, on pourra souvent se retrouver avec une application écrivant ses données sur un serveur environ deux fois moins vite qu’elle ne le pourrait.
La figure 6 représente schématiquement un exemple d’une première phase de déroulement de plusieurs processus d’applications utilisant la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
Le tableau de la figure 6 représente sur les besoins d’accès aux quatre fichiers 61 à 64 disposés en colonnes au cours de cinq périodes de temps. Ces besoins d’accès sont identifiés au cours de la phase d’observation de l’exécution des applications et du stockage correspondant de leurs données. Au cours des première, quatrième et cinquième périodes de temps, aucun fichier n’a besoin d’être accédé. En revanche, au cours de la deuxième période de temps, ainsi qu’au cours de la troisième période de temps, doivent être accédées simultanément la première tranche 611 du fichier 61, la deuxième tranche 622 du fichier 62, la troisième tranche 633 du fichier 63, la quatrième tranche 644 du fichier 64.
La solution proposée par ce mode de réalisation pour résoudre ce problème consiste ici à diriger la création des fichiers 61 à 64 sur un ensemble de serveurs de données 100 à 103 à partir d’observations antérieures d’exécutions des processus 65 à 68 de l’application ou des applications pour en déterminer le comportement futur en termes d’accès simultanés aux fichiers 61 à 64. Ainsi, il sera possible de positionner les fichiers 61 à 64 ou même les tranches des fichiers 61 à 64 accédés simultanément par les processus 65 à 68 d’application(s) sur des serveurs de données 100 à 103 différents si possible, ou au moins différents pour la plupart des tranches de fichier, ou faire une répartition homogène, ou au moins plus homogène, des fichiers 61 à 64, ou des tranches des fichiers 61 à 64, accédés simultanément sur les serveurs de données 100 à 103 disponibles.
La solution proposée par ce mode de réalisation de l’invention repose donc sur la possibilité d’observer le comportement d’une application ou des processus d’application(s) 65 à 68 lors de multiple exécutions et de l’enregistrer dans une base de connaissance pour en tirer un profil idéal de répartition des fichiers 61 à 64 créés sur les serveurs de données 100 à 103.
Dans le domaine du calcul scientifique des supercalculateurs, il est courant que la même application soit exécutée de nombreuses fois lors d’une campagne d’étude. Par exemple, les organismes de prévision météorologique effectuent les mêmes calculs toutes les quelques heures sur les toutes dernières mesures de paramètres physiques.
Une fois la base de connaissance constituée, une analyse peut être effectuée pour détecter les accès simultanés effectués par les processus 65 à 68 de l’application ou des applications. Les accès sont classés par périodes d’accès et par régions de fichiers accédées, sous forme de numéro de tranche, comme représenté sur le tableau de la figure 6.
La figure 7 représente schématiquement un exemple d’une deuxième phase de déroulement de plusieurs processus d’applications utilisant la solution proposée par le procédé de stockage selon un mode de réalisation de l’invention.
Cette fois-ci, grâce à la phase préalable d’observation, compte-tenu des besoins d’accès identifiés au cours du temps, au lieu d’une stratégie aléatoire prédéterminée, c’est une stratégie différente déterminée après coup en fonction des besoins d’accès identifiés préalablement et adaptée à ces besoins d’accès pré-identifiés qui est choisie. Cette stratégie différente, parfaitement adaptée aux processus des applications considérées ici, n’aurait pas pu être devinée sans phase d’observation préalable, car ce type de stockage correspondant au fait de stocker toutes les mêmes tranches de chaque fichier sur un même serveur est habituellement un stockage qui n’est pas utilisé, car étant parfaitement symétrique, il serait au contraire plutôt considéré comme source plus probable d’engorgement des accès, comme risquant plus probablement de causer des goulots d’étranglement dans l’échange de données entre processus d’applications et serveurs de stockage.
Plus précisément, le stockage des données réalisé est le même pour toutes les tranches de tous les fichiers. Ce stockage est le suivant.
Pour le fichier 61, la première tranche 611 est stockée sur le serveur 100, la deuxième tranche 612 est stockée sur le serveur 101, la troisième tranche 613 est stockée sur le serveur 102, la quatrième tranche 614 est stockée sur le serveur 103.
Pour le fichier 62, la première tranche 621 est stockée sur le serveur 100, la deuxième tranche 622 est stockée sur le serveur 101, la troisième tranche 623 est stockée sur le serveur 102, la quatrième tranche 624 est stockée sur le serveur 103.
Pour le fichier 63, la première tranche 631 est stockée sur le serveur 100, la deuxième tranche 632 est stockée sur le serveur 101, la troisième tranche 633 est stockée sur le serveur 102, la quatrième tranche 634 est stockée sur le serveur 103.
Pour le fichier 64, la première tranche 641 est stockée sur le serveur
100, la deuxième tranche 642 est stockée sur le serveur 101, la troisième tranche 643 est stockée sur le serveur 102, la quatrième tranche 644 est stockée sur le serveur 103.
La stratégie va consister ici à déduire du tableau de la figure 6 que les tranches d’un même rang de ces quatre fichiers 61 à 64 seraient idéalement placées sur des serveurs de données 100 à 103 différents, afin de les faire tous travailler simultanément et en parallèle, lors des deuxième et troisième périodes de temps. Cela correspond à la répartition idéale des fichiers 61 à 64 sur les serveurs de données 100 à 103 telle que représentée sur la figure
7.
Pour obtenir ce placement, qui ne serait pas naturellement généré par le système de fichier, un mécanisme est inséré qui lui indique comment faire ce placement idéal sur les serveurs de données 100 à 103 au moment de la création du fichier par les processus 65 à 68 de l’application ou des applications. Ce mécanisme peut notamment être implémenté sous la forme d’une bibliothèque de fonctions interceptant les créations de fichier des processus de l’application et effectuant cette opération avec des paramètres prédéterminés. Cette bibliothèque aura accès aux informations de placement idéal des fichiers 61 à 64 qui ont été élaborés à partir de l’analyse des exécutions précédentes.
La figure 8 représente schématiquement un exemple de synthèse de la phase d’observation du procédé de stockage selon un mode de réalisation de l’invention.
Différentes applications 83, ou différents processus d’application(s), sont instrumentées pour que leur comportement soit observé lors du déroulement de leur exécution. Pendant cette phase d’observation, un logiciel d’observation 82 du comportement de ces applications 83 observe leur comportement pour déterminer le profil de chacune des applications 83. Une fois déterminé, le profil de chaque application 83 est stocké sur un espace d’archivage 81 des profils des applications 83.
On aura donc deux phases dans la mise en œuvre de la stratégie proposée par ce mode de réalisation de l’invention. Dans une première phase, représentée au niveau de la figure 8, les applications 83, ou les processus d’application(s), lancées par les utilisateurs seront observées pour construire la base de connaissance stockée sur un espace d’archivage 81. La figure 9 représente schématiquement un exemple de synthèse de la phase de paramétrage du procédé de stockage selon un mode de réalisation de l’invention.
Un logiciel de paramétrage 84 optimal des applications lit sur l’espace d’archivage 81 des profils des applications 83, les profils des applications. A l’aide de ces profils d’applications, ce logiciel de paramétrage 84 optimal des applications va paramétrer chacune des applications pour qu’elle devienne une application 85 instrumentée pour l’accélération de son comportement, et plus précisément pour la réduction de son temps d’échange de données avec les serveurs de stockage de données.
Dans cette deuxième phase, représentée au niveau de la figure 9, les applications 85 seront lancées avec la bibliothèque d’accélération qui sera paramétrée grâce à l’analyse des comportements précédents enregistrés dans la base de connaissance stockée sur l’espace d’archivage 81. La bibliothèque d’accélération indiquera alors au système de fichier comment répartir les tranches de fichier sur les espaces disques de façon à éviter les conflits futurs d’accès et ainsi optimiser la performance en termes de durée d’exécution notamment.
Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.

Claims

REVENDICATIONS
1. Procédé de stockage, sur des serveurs (3, 4) de données, de tranches (51 à 58) de fichiers (5, 61 à 64) de données issues de l’exécution de plusieurs processus (65 à 68) d’une ou de plusieurs applications (83, 85), comprenant :
une répartition des tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées sur différents serveurs (3, 4) de données, caractérisé en ce que :
cette répartition est réalisée de manière à ce que des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d’être accédées ultérieurement simultanément par différents processus (65 à 68) d’application (83, 85) soient stockées sur différents serveurs (3, 4) de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs (3, 4) de données, simultanément par trop de processus (65 à 68) d’application (83, 85),
et en ce que :
la détermination des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d’être accédées simultanément par différents processus (65 à 68) d’application (83, 85) a été effectuée, lors d’une phase préalable d’exécution de ces processus (65 à 68) d’application (83, 85), par l’observation du comportement de ces processus (65 à 68) d’application (83, 85) pour accéder, au cours du temps, à ces tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées.
2. Procédé de stockage, sur des espaces de stockage (31 à 43) de serveurs (3, 4) de données, de tranches (51 à 58) de fichiers (5, 61 à 64) de données issues de l’exécution de plusieurs processus (65 à 68) d’une ou de plusieurs applications (83, 85), comprenant : une répartition des tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées sur différents espaces de stockage (31 à 43) de différents serveurs (3, 4) de données,
caractérisé en ce que :
cette répartition est réalisée de manière à ce que des tranches (51 à
58) de fichiers (5, 61 à 64) de données susceptibles d’être accédées ultérieurement simultanément par différents processus (65 à 68) d’application (83, 85) soient stockées sur différents espaces de stockage (31 à 43) de différents serveurs (3, 4) de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces espaces de stockage (31 à 43), simultanément par trop de processus (65 à 68) d’application (83, 85),
et en ce que :
la détermination des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d’être accédés simultanément par différents processus (65 à 68) d’application (83, 85) a été effectuée, lors d’une phase préalable d’exécution de ces processus (65, 68) d’application (83, 85), par l’observation du comportement de ces processus (65 à 68) d’application (83, 85) pour accéder, au cours du temps, à ces tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées.
3. Procédé de stockage selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite détermination des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d’être accédés simultanément par différents processus (65 68) d’application (83, 85) a été effectuée, lors d’une phase préalable d’exécution de ces processus (65 à 68) pour une seule application (83, 85) ou bien application (83, 85) par application (83, 85) en cas de pluralité d’applications (83, 85), par l’observation du comportement de ces processus (65 à 68) d’une seule application (83, 85) à la fois pour accéder, au cours du temps, à ces tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées.
4. Procédé de stockage selon l’une quelconque des revendications précédentes, caractérisé en ce que la ou les applications (83, 85) sont portables sur d’autres types de serveurs (3, 4) de stockage de données.
5. Procédé de stockage selon l’une quelconque des revendications précédentes, caractérisé en ce que les processus (65 à 68) de l’application (83, 85) incluent des calculs répétitifs.
6. Procédé de stockage selon la revendication 5, caractérisé en ce que lesdits calculs répétitifs incluent des calculs de prévisions météorologiques.
7. Procédé de stockage selon l’une quelconque des revendications précédentes, caractérisé en ce que la ou les applications (83, 85) sont exécutés au sein d’un réseau comprenant plusieurs milliers de nœuds de calcul (1), de préférence au moins 5000 nœuds de calcul (1), de préférence au moins 10000 nœuds de calcul (1).
8. Procédé de stockage selon l’une quelconque des revendications précédentes, caractérisé en ce que, à chaque fichier (5, 61 à 64) sont associés une taille maximale de tranche (51 à 58) de fichier (5, 61 à 64) pouvant être stockée d’un coup et un nombre maximal d’espaces de stockage (31 à 43) sur lesquels ce fichier (5, 61 à 64) peut être stocké, la taille maximale de tranche (51 à 58) de fichier (5, 61 à 64) restant de préférence inférieure à 2 Mo et valant avantageusement 1 Mo, le nombre maximal d’espaces de stockage (31 à 43) restant de préférence inférieur à 10 et valant avantageusement 5.
9. Procédé de stockage selon l’une quelconque des revendications précédentes, caractérisé en ce que :
ladite répartition des tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées sur différents serveurs (3, 4) de données ou sur différents espaces de stockage (31 à 43) de différents serveurs (3,
4) de données, est réalisée par une bibliothèque de fonctions qui : o d’une part intercepte les créations de fichiers (5, 61 à 64) de données,
o d’autre part réalise le stockage des tranches (51 à 58) de ces fichiers (5, 61 à 64) de données sur les espaces de stockage (31 à 43) sur les serveurs (3, 4) de données qui leur ont été associés lors de ladite phase préalable d’exécution des processus (65 à 68) d’application (83, 85).
10. Procédé d’exécution de plusieurs processus (65 à 68) d’une ou de plusieurs applications (83, 85), comprenant :
une première phase d’observation du déroulement desdits processus (65 à 68) et de leur manière d’accéder au cours du temps aux données stockées pendant ladite exécution, pendant laquelle la détermination des tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d’être accédés simultanément par différents processus (65 à 68) d’application (83, 85) est effectuée, une deuxième phase de paramétrage du stockage des données par lesdits processus (65 à 68) sur des serveurs (3, 4) de données et sur leurs espaces de stockage (31 à 43), associant aux tranches (51 à 58) de fichiers (5, 61 à 64) de données des espaces de stockage (31 à 43) sur les serveurs (3, 4) de données,
une troisième phase de répartition des tranches (51 à 58) de fichiers (5, 61 à 64) de données stockées sur différents serveurs de données et sur leurs espaces de stockage (31 à 43), cette répartition étant réalisée de manière à ce que les tranches (51 à 58) de fichiers (5, 61 à 64) de données susceptibles d’être accédées ultérieurement simultanément par différents processus (65 à 68) d’application (83, 85) soient stockées sur différents serveurs (3, 4) de données, le cas échéant sur différents espaces de stockage (31 à 43) de ces serveurs (3, 4) de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs (3, 4) de données, le cas échéant de ces espaces de stockage (31 à 43), simultanément par trop de processus (65 à 68) d’application (83, 85).
11. Procédé de stockage, sur des serveurs (3, 4) de données, de données issues de l’exécution de plusieurs processus (65 à 68), comprenant : une répartition des données stockées sur différents serveurs (3, 4) de données,
caractérisé en ce que :
cette répartition est réalisée de manière à ce que des groupes de données susceptibles d’être accédés ultérieurement simultanément par différents processus (65 à 68) soient stockés sur différents serveurs (3, 4) de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs (3, 4) de données, simultanément par trop de processus (65 à 68),
et en ce que :
la détermination des groupes de données susceptibles d’être accédés simultanément par différents processus (65 à 68) a été effectuée, lors d’une phase préalable d’exécution de ces processus
(65 à 68), par l’observation du comportement de ces processus (65 à 68) pour accéder, au cours du temps, à ces groupes de données stockées.
12. Procédé de stockage, sur des serveurs (3, 4) de données, de tranches d’objets de données issues de l’exécution de plusieurs processus (65 à 68) d’une ou de plusieurs applications (83, 85), comprenant :
une répartition des tranches d’objets de données stockées sur différents serveurs (3, 4) de données,
caractérisé en ce que :
cette répartition est réalisée de manière à ce que des tranches d’objets de données susceptibles d’être accédées ultérieurement simultanément par différents processus (65 à 68) d’application (83, 85) soient stockées sur différents serveurs (3, 4) de données, de manière à réduire l’accès ultérieur, à chacun de tout ou partie de ces serveurs (3, 4) de données, simultanément par trop de processus (65 à 68) d’application (83, 85),
et en ce que :
la détermination des tranches d’objets de données susceptibles d’être accédés simultanément par différents processus (65 à 68) d’application (83, 85) a été effectuée, lors d’une phase préalable d’exécution de ces processus (65 à 68) d’application (83, 85), par l’observation du comportement de ces processus (65 à 68) d’application (83, 85) pour accéder, au cours du temps, à ces tranches d’objets de données stockées.
PCT/FR2018/053447 2017-12-27 2018-12-20 Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees WO2019129958A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/958,314 US11561934B2 (en) 2017-12-27 2018-12-20 Data storage method and method for executing an application with reduced access time to the stored data
EP18842433.7A EP3732560A1 (fr) 2017-12-27 2018-12-20 Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1763236A FR3076001B1 (fr) 2017-12-27 2017-12-27 Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees
FR1763236 2017-12-27

Publications (1)

Publication Number Publication Date
WO2019129958A1 true WO2019129958A1 (fr) 2019-07-04

Family

ID=62017429

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2018/053447 WO2019129958A1 (fr) 2017-12-27 2018-12-20 Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees

Country Status (4)

Country Link
US (1) US11561934B2 (fr)
EP (1) EP3732560A1 (fr)
FR (1) FR3076001B1 (fr)
WO (1) WO2019129958A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3076001B1 (fr) * 2017-12-27 2021-05-28 Bull Sas Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8769238B1 (en) * 2010-06-29 2014-07-01 Amazon Technologies, Inc. Load rebalancing for shared resource

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7010532B1 (en) * 1997-12-31 2006-03-07 International Business Machines Corporation Low overhead methods and apparatus for shared access storage devices
US8296812B1 (en) * 2006-09-01 2012-10-23 Vudu, Inc. Streaming video using erasure encoding
US8381025B2 (en) * 2009-09-30 2013-02-19 Cleversafe, Inc. Method and apparatus for dispersed storage memory device selection
CN102142006B (zh) * 2010-10-27 2013-10-02 华为技术有限公司 分布式文件系统的文件处理方法及装置
WO2015026273A1 (fr) * 2013-08-23 2015-02-26 Telefonaktiebolaget L M Ericsson (Publ) Procédé et système d'analyse d'accès à un type de mémorisation de données et recommandations de changement de type de mémorisation
US10037340B2 (en) * 2014-01-21 2018-07-31 Red Hat, Inc. Tiered distributed storage policies
FR3076001B1 (fr) * 2017-12-27 2021-05-28 Bull Sas Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees
US10594773B2 (en) * 2018-01-22 2020-03-17 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US11144502B2 (en) * 2019-03-08 2021-10-12 Netapp Inc. Object store file system format for representing, storing, and retrieving data in an object store according to a structured format
US11893064B2 (en) * 2020-02-05 2024-02-06 EMC IP Holding Company LLC Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace
US20210390080A1 (en) * 2020-06-15 2021-12-16 Nutanix, Inc. Actions based on file tagging in a distributed file server virtual machine (fsvm) environment

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8769238B1 (en) * 2010-06-29 2014-07-01 Amazon Technologies, Inc. Load rebalancing for shared resource

Also Published As

Publication number Publication date
US11561934B2 (en) 2023-01-24
FR3076001B1 (fr) 2021-05-28
FR3076001A1 (fr) 2019-06-28
US20210064575A1 (en) 2021-03-04
EP3732560A1 (fr) 2020-11-04

Similar Documents

Publication Publication Date Title
US8732118B1 (en) Distributed performance of data aggregation operations
FR3000578A1 (fr) Systeme et procede de calcul partage utilisant une fourniture automatisee de ressources informatiques heterogenes
EP1483673B1 (fr) Methode de stockage de blocs de donnees dans une memoire
FR2982386A1 (fr) Procede, programme d'ordinateur et dispositif d'allocation de ressources informatiques d'un cluster pour l'execution d'un travail soumis audit cluster
EP2366147A1 (fr) Gestionnaire physique de barriere de synchronisation entre processus multiples
US20050165823A1 (en) Binary dependency database
WO2015004207A1 (fr) Procede d'optimisation de traitement parallele de donnees sur une plateforme materielle
WO2013107819A1 (fr) Procédé d'optimisation de traitement parallèle de données sur une plateforme matérielle.
Waibel et al. Cost-optimized redundant data storage in the cloud
EP3579108B1 (fr) Contrôleur de partage de ressources d'une plate-forme informatique et procédé associé de partage des ressources
WO2019129958A1 (fr) Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees
FR2907623A1 (fr) Gestion de droits numeriques basee sur les modifications apportees a l'environnement d'un dispositif.
EP2709008B1 (fr) Procédé et dispositif de décompte du temps déporté pour unité de traitement dans un système de traitement de l'information
EP3724752B1 (fr) Procede de gestion du systeme de fichiers d'un terminal informatique
FR2991074A1 (fr) Procede, dispositif et programme d'ordinateur de controle dynamique de distances d'acces memoire dans un systeme de type numa
EP2704010A1 (fr) Procédé et dispositif de traitement de commandes dans un ensemble d'éléments informatiques
FR2897961A1 (fr) Procede de gestion de l'execution d'un jeu video pour la diffusion en temps reel de publicites dynamiques
EP2953029B1 (fr) Methodes et systemes de test de performances a debit configurable
EP3483733B1 (fr) Procede et dispositif de recherche de marge d'optimisation de ressources d'une chaine applicative
Emara et al. Geographically distributed data management to support large-scale data analysis
EP3239851A1 (fr) Gestion de l'accès a des données dans un système de stockage
FR2980007A1 (fr) Procede, dispositif et programme d'ordinateur pour allouer dynamiquement des ressources d'un cluster a l'execution de processus d'une application
Keita Big Data et Technologies de Stockage et de Traitement des Données Massives: Comprendre les bases de l’écosystème HADOOP (HDFS, MAPREDUCE, YARN, HIVE, HBASE, KAFKA et SPARK)
Jia et al. Implementing a GPU-based machine learning library on Apache spark
EP3948574A1 (fr) Système de stockage redondant de données, procédé et programme d'ordinateur correspondants

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18842433

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018842433

Country of ref document: EP

Effective date: 20200727