EP3732560A1 - 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

Info

Publication number
EP3732560A1
EP3732560A1 EP18842433.7A EP18842433A EP3732560A1 EP 3732560 A1 EP3732560 A1 EP 3732560A1 EP 18842433 A EP18842433 A EP 18842433A EP 3732560 A1 EP3732560 A1 EP 3732560A1
Authority
EP
European Patent Office
Prior art keywords
data
processes
servers
slices
application
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP18842433.7A
Other languages
German (de)
English (en)
Inventor
Philippe Couvee
Simon Derr
Antoine PERCHER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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
Publication of EP3732560A1 publication Critical patent/EP3732560A1/fr
Pending legal-status Critical Current

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

  • the invention relates to the field of data storage methods with reduced access time to stored data, as well as the field of corresponding application execution methods using these data storage methods.
  • 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.
  • a second disadvantage of this first prior art is that, according to the invention, even after each read operation and each write operation has been made very fast, if there is a large number to perform, and this is particularly the case for several applications each managing a large number of data, the overall access time to stored files remains important, or very important, the scale of the overall time of running applications. This time of access to the stored files is particularly noticeable at the level of the progress of the applications, during the these applications are carried out during a very large process of data processing, such as a large calculation, because then the many periodic phases of data backup ("checkpoint" in English) inherently occupy a proportion important overall time of progress of this process of treatment, for example of the order of 10 to 20 minutes every hour.
  • the optimization of the unwinding time is mainly centered on the reduction of the calculation time of the applications.
  • this second prior art often only deals with reducing the calculation time of the application because it is considered better controlled and more important.
  • decreasing the input / output time that is to say reading and / or writing each partial result backup, will be able to pay first because this backup time can take from 10% to 30% of the total execution time of an application, and then can be achieved regardless of the internal logic of the application.
  • the management of the input / output time could be made upstream of the execution of the application, that is to say at the level of a optimization of the distribution of data which would then be carried out by an upstream design phase which of course would then save the time of the observation phase.
  • this would be achieved at the cost of two major disadvantages which would be on the one hand the total dependence of the application with respect to a single type of storage system and on the other hand the increase in difficulty development of the application to incorporate this additional constraint.
  • the object of the present invention is to provide a storage method at least partially overcomes the aforementioned drawbacks.
  • 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.
  • the present invention proposes a storage method that can be adapted to either data file slices, or even groups of data, or slices of data objects, this storage being performed on different data servers, or even on different storage spaces of data servers, these different storage spaces of data servers, or these different data servers, being accessible separately and independently of each other by applications outside their data servers.
  • the present invention also proposes a method for executing application processes corresponding to one or other of these storage methods, and more particularly to the method of storing file slices of data on different data servers.
  • a method of storing, on data servers, slices of data files resulting from the execution of several processes of one or more applications comprising: a division of the slices data files stored on different data servers, characterized in that: this distribution is performed so that slices of data files that can be accessed later simultaneously by different application processes are stored on different data servers. data, so as to reduce subsequent access, at each of all or part of these data servers, simultaneously by too many application processes, and in that: the determination of the slices of data files that can be accessed simultaneously by different application processes was carried out, during a preliminary phase of implementation n of these application processes, by observing the behavior of these application processes to access, over time, these slices of stored data files.
  • 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.
  • a method for executing several processes of one or more applications comprising: a first phase of observation of the progress of said processes and of their way of accessing data over time; stored during said execution, during which the determination of the slices of data files that can be accessed simultaneously by different processes application is performed, a second phase of setting data storage by said processes on data servers and on their storage spaces, associating the data file slots with storage spaces on the data servers, a third phase distribution of the data file slices stored on different data servers and their storage spaces, this distribution being performed so that the data file slices that can be accessed later simultaneously by different application processes are stored on different data servers, if necessary on different storage spaces of these data servers, so as to reduce subsequent access to each of all or part of these data servers, if any of these storage spaces at the same time by too many application processes.
  • a method of storing, on data servers, data resulting from the execution of several processes comprising: a distribution of the data stored on different data servers, characterized in that: distribution is performed so that groups of data that can be accessed later simultaneously by different processes are stored on different data servers, so as to reduce subsequent access to each of all or part of these data servers , simultaneously by too many processes, and in that: the determination of the groups of data that can be accessed simultaneously by different processes has been performed, during a preliminary phase of execution of these processes, by the observation of the behavior of these processes to access, over time, these groups of stored data.
  • a method of storing, on data servers, slices of data objects resulting from the execution of several processes of one or more applications comprising: a distribution of the slices of data objects stored on different data servers, characterized in that: this distribution is performed so as to that slices of data objects that can later be accessed simultaneously by different application processes are stored on different data servers, so as to reduce subsequent access to each of all or part of these data servers , at the same time by too many application processes, and in that: the determination of the slices of data objects that can be accessed simultaneously by different application processes has been performed, during a preliminary execution phase of these application processes, by observing the behavior of these application processes to access, over time, these slices of stored data objects.
  • the invention comprises one or more of the following features which can be used separately or in partial combination with one another or in total combination with one another, or with one or the other of the aforementioned objects of the invention. .
  • said determination of the slices of data files that can be accessed simultaneously by different application processes has been performed, during a preliminary phase of execution of these processes for a single application or application by application in case plurality of applications, by observing the behavior of these processes of a single application at a time to access, over time, these slices of stored data files.
  • the application or applications are portable on other types of data storage servers.
  • the application is therefore independent of a data storage system, and this is made possible because the optimization of the distribution of the data is performed downstream, by a phase of observation of the behavior of the application, at instead of being carried out by a design phase in upstream which certainly would save the time of the observation phase but at the cost of two major disadvantages which are on the one hand the total dependence of the application with respect to a single type of storage system and on the other hand the increase the difficulty of developing the application incorporating this additional constraint.
  • the processes of the application include repetitive calculations.
  • observation phase will offer an excellent compromise, namely to be simple and short and allow a high optimization of the distribution of the data storage areas resulting in a significant decrease in the time of entry / exit during the course of the proceedings. execution of the application.
  • said repetitive calculations include weather forecast calculations.
  • weather forecasting calculations are a particularly critical example of very repetitive and highly complex calculations, that is to say, requiring a lot of resources but allowing a high optimization of the distribution of the data storage areas that can lead to a significant reduction.
  • the input / output time during the execution of the execution of the application is to say, requiring a lot of resources but allowing a high optimization of the distribution of the data storage areas that can lead to a significant reduction.
  • the application or applications are executed within a network comprising several thousand compute nodes, preferably at least 5000 compute nodes, preferably at least 10000 compute nodes.
  • said distribution of the slices of data files stored on different data servers or on different storage spaces of different data servers is performed by a library of functions which: on the one hand intercepts the creation of data files, on the other hand realizes the storage of the slices of these data files on the storage spaces on the data servers that were associated with them during said preliminary phase of execution of the application processes.
  • 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. 1 schematically represents an example of a storage system to which the storage method according to one embodiment of the invention can be applied.
  • FIG. 2 diagrammatically represents an example of a random storage method that can generate the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • Figure 3 schematically shows an example of storing data of several application files on several servers generating the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • FIG. 4 diagrammatically represents an example of a first phase of several application processes generating the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • 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.
  • 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.
  • FIG. 7 schematically represents an example of a second phase of several application processes using the solution proposed by the storage method according to one embodiment of the invention.
  • FIG. 8 schematically represents an example of synthesis of the observation phase of the storage method according to one embodiment of the invention.
  • FIG. 9 schematically represents an example of synthesis of the parameterization phase of the storage method according to one embodiment of the invention.
  • FIG. 1 schematically represents an example of a storage system to which the storage method according to one embodiment of the invention can be applied.
  • a calculation node 1 performs a calculation and from time to time needs to read and / or write data to the data servers 3 and 4 using a metadata server 2.
  • the data server 3 (OSS for "object storage server” in English) comprises several disk spaces 31 to 33 of data (OST for "object storage target” in English).
  • the data server 4 comprises several disk spaces 41 to 43 of data.
  • the metadata server 2 (MDS for "meta data server” in English) comprises several disk spaces 41 to 43 of metadata (MDT for "meta data target” in English).
  • the language used by the compute node to communicate with the servers 2 to 4 is for example the language Luster (free software language or "open source" in English).
  • the computation node 1 sends a file opening request 11 to the metadata server 2.
  • the metadata server 2 returns a response 12 containing attributes and file identifiers. Among these attributes are a chunk block size of the data file to be stored as well as a list of data servers or even a list of data disk spaces.
  • the computation node 1 sends the data server 3 a request 13 for reading data or a request 14 for writing data.
  • the data server 3 reads or writes the data on one of the disk spaces 31 to 33 of data.
  • the computation node 1 sends the data server 4 a data read request 15 or a data write request 16.
  • the data server 4 reads or writes the data on one of the disk spaces 41 to 43 of data.
  • 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.
  • FIG. 2 diagrammatically represents an example of a random storage method that can generate the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • 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 file system When creating a file 5, the file system must choose which servers 3 or 4 data and which disk space 31 to 33 and / or 41 to 43 will be used to store its contents.
  • the algorithms used today are based on a method of random type ("round robin" in English) in order to distribute the data randomly on all data servers 3 and 4 and promote a seamless filling.
  • the principle is that we set in advance a size of elementary slice of data ("stripe" in English) and a number of disk spaces 31 to 43 for each file 5 to create.
  • FIG. 3 schematically represents an example of data storage of several application files on several servers generating the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • the first slice 611 is stored on the server 100
  • the second slice 612 is stored on the server 101
  • the third slice 613 is stored on the server 102
  • the fourth slice 614 is stored on the server 103.
  • the first slice 621 is stored on the server 103
  • the second slice 622 is stored on the server 100
  • the third slice 623 is stored on the server 101
  • the fourth slice 624 is stored on the server 102.
  • the first slice 631 is stored on the server
  • the second slice 632 is stored on the server 103
  • the third slice 633 is stored on the server 100
  • the fourth slice 634 is stored on the server 101.
  • the first slice 641 is stored on the server 101
  • the second slice 642 is stored on the server 102
  • the third slice 643 is stored on the server 103
  • the fourth slice 644 is stored on the server 100.
  • FIG. 4 diagrammatically represents an example of a first phase of several application processes generating the problem solved by the solution proposed by the storage method according to one embodiment of the invention.
  • Four processes 65 to 68 of applications will have to access over time, whether for a reading of data or for writing data, to their respective files stored on the servers 100 to 103 as detailed in Figure 3.
  • 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.
  • the server 100 to which the four processes 65 to 68 want to make four simultaneous access 75 to 78, will only be able to respond to these requests with a speed four times less than its nominal speed, which will multiply by four the overall time of completion of the four accesses 75 to 78.
  • a speed four times less than its nominal speed which will multiply by four the overall time of completion of the four accesses 75 to 78.
  • server on which the data were stored with a random strategy For reasons of dependence between the data, at the end of the calculation, each of the processes 65 to 68 begins to write in its result file the data of the column corresponding to its rank in the parallel computing application. The result is that all the processes "attack" at the same time the same data server, here 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 table of FIG. 6 represents the access requirements for the four files 61 to 64 arranged in columns during five periods of time. These access requirements are identified during the observation phase of the execution of the applications and the corresponding storage of their data. During the first, fourth and fifth periods of time, no file needs to be accessed. On the other hand, during the second period of time, as well as during the third period of time, the first slice 611 of the file 61 must be accessed simultaneously, the second slice 622 of the file 62, the third slice 633 of the file 63, the fourth slice 644 of the file 64.
  • 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.
  • the solution proposed by this embodiment of the invention is therefore based on the possibility of observing the behavior of an application or the application processes 65 to 68 during multiple executions and to register it in a database. knowledge to derive an ideal distribution profile of files 61 to 64 created on data servers 100 to 103.
  • 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.
  • FIG. 7 schematically represents an example of a second phase of several application processes using the solution proposed by the storage method according to one embodiment of the invention.
  • the data storage performed is the same for all slices of all files. This storage is the following.
  • the first slice 611 is stored on the server 100
  • the second slice 612 is stored on the server 101
  • the third slice 613 is stored on the server 102
  • the fourth slice 614 is stored on the server 103.
  • 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 first slice 641 is stored on the server
  • the second slice 642 is stored on the server 101
  • the third slice 643 is stored on the server 102
  • the fourth slice 644 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.
  • This mechanism can notably be implemented in the form of a function library intercepting the file creations of the application processes and performing this operation with predetermined parameters. This library will have access to the ideal placement information of files 61 to 64 that have been developed from the analysis of previous executions.
  • FIG. 8 schematically represents an example of synthesis of the observation phase of the storage method according to one embodiment of the invention.
  • 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.
  • FIG. 8 schematically represents an example of synthesis of the parameterization phase of the storage method according to one embodiment of the invention.
  • 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.
EP18842433.7A 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 Pending EP3732560A1 (fr)

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

Publications (1)

Publication Number Publication Date
EP3732560A1 true EP3732560A1 (fr) 2020-11-04

Family

ID=62017429

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18842433.7A Pending 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

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

Family Cites Families (12)

* 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
US8281181B2 (en) * 2009-09-30 2012-10-02 Cleversafe, Inc. Method and apparatus for selectively active dispersed storage memory device utilization
US8539197B1 (en) * 2010-06-29 2013-09-17 Amazon Technologies, Inc. Load rebalancing for shared resource
CN102142006B (zh) * 2010-10-27 2013-10-02 华为技术有限公司 分布式文件系统的文件处理方法及装置
US10410137B2 (en) * 2013-08-23 2019-09-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for analyzing accesses to a data storage type and recommending a change of storage type
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

Also Published As

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

Similar Documents

Publication Publication Date Title
EP1483673B1 (fr) Methode de stockage de blocs de donnees dans une memoire
FR3000578A1 (fr) Systeme et procede de calcul partage utilisant une fourniture automatisee de ressources informatiques heterogenes
EP2366147A1 (fr) Gestionnaire physique de barriere de synchronisation entre processus multiples
EP2776927A1 (fr) Procédé, programme d'ordinateur et dispositif d'allocation de ressources informatiques d'un cluster pour l'exécution d'un travail soumis audit cluster
US20050165823A1 (en) Binary dependency database
WO2015004207A1 (fr) Procede d'optimisation de traitement parallele de donnees sur une plateforme materielle
Gonçalves Junior et al. A multi-criteria approach for assessing cloud deployment options based on non-functional requirements
WO2013107819A1 (fr) Procédé d'optimisation de traitement parallèle de données sur une plateforme matérielle.
EP3732560A1 (fr) Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees
EP3579108A1 (fr) Contrôleur de partage de ressources d'une plate-forme informatique et procédé associé de partage des ressources
EP2856323B1 (fr) Procédé, dispositif et programme d'ordinateur de contrôle dynamique de distances d'accès mémoire dans un système de type numa
FR2906955A1 (fr) Systeme de gestion de droits numeriques.
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
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
EP3239851B1 (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)
FR3073298A1 (fr) Procede et dispositif de recherche de marge d’optimisation de ressources d’une chaine applicative
FR3094509A1 (fr) Système de stockage redondant de données, procédé et programme d’ordinateur correspondants.
EP4113297A1 (fr) Procédé de gestion des travaux dans un système informatique et système associé
EP2572253B1 (fr) Procede d'optimisation de gestion de veille d'un microprocesseur permettant la mise en oeuvre de plusieurs coeurs logiques et programme d'ordinateur mettant en oeuvre un tel procede
CN117076696A (zh) 数据处理方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200625

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220307

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERGIES ALTERNATIVES

Owner name: BULL SAS

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230330