FR3076001A1 - 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 PDFInfo
- Publication number
- FR3076001A1 FR3076001A1 FR1763236A FR1763236A FR3076001A1 FR 3076001 A1 FR3076001 A1 FR 3076001A1 FR 1763236 A FR1763236 A FR 1763236A FR 1763236 A FR1763236 A FR 1763236A FR 3076001 A1 FR3076001 A1 FR 3076001A1
- Authority
- FR
- France
- Prior art keywords
- data
- processes
- application
- slices
- servers
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 170
- 238000013500 data storage Methods 0.000 title claims description 16
- 230000008569 process Effects 0.000 claims abstract description 121
- 238000009826 distribution Methods 0.000 claims abstract description 38
- 238000003860 storage Methods 0.000 claims description 84
- 238000004364 calculation method Methods 0.000 claims description 21
- 230000003252 repetitive effect Effects 0.000 claims description 6
- 230000006870 function Effects 0.000 claims description 3
- 230000006399 behavior Effects 0.000 description 17
- 238000011161 development Methods 0.000 description 9
- 238000005457 optimization Methods 0.000 description 7
- 230000009467 reduction Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 5
- 230000015572 biosynthetic process Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000003786 synthesis reaction Methods 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 238000005520 cutting process Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 241001522296 Erithacus rubecula Species 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000001684 chronic effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000002932 luster Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000001575 pathological effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000007306 turnover Effects 0.000 description 1
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]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Human Computer Interaction (AREA)
- Environmental & Geological Engineering (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Atmospheric Sciences (AREA)
- Environmental Sciences (AREA)
- Ecology (AREA)
- Biodiversity & Conservation Biology (AREA)
- Life Sciences & Earth 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 Γ 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 rinvention, 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 l’exécution de l’application.
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 Γ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 Γ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 Γ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 Γ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 Γ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 Γ 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 Γ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 Γ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. H 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 Γ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 (12)
- REVENDICATIONS1. 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.
Priority Applications (4)
| 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 |
| 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 |
| 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 |
| 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 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1763236 | 2017-12-27 | ||
| 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 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3076001A1 true FR3076001A1 (fr) | 2019-06-28 |
| FR3076001B1 FR3076001B1 (fr) | 2021-05-28 |
Family
ID=62017429
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1763236A Active 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 |
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)
| 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)
| 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)
| 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 |
| 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 |
-
2017
- 2017-12-27 FR FR1763236A patent/FR3076001B1/fr active Active
-
2018
- 2018-12-20 EP EP18842433.7A patent/EP3732560A1/fr active Pending
- 2018-12-20 US US16/958,314 patent/US11561934B2/en active Active
- 2018-12-20 WO PCT/FR2018/053447 patent/WO2019129958A1/fr unknown
Patent Citations (1)
| 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 |
|---|---|
| WO2019129958A1 (fr) | 2019-07-04 |
| FR3076001B1 (fr) | 2021-05-28 |
| US20210064575A1 (en) | 2021-03-04 |
| EP3732560A1 (fr) | 2020-11-04 |
| US11561934B2 (en) | 2023-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20180165348A1 (en) | Distributed storage of aggregated data | |
| FR3000578A1 (fr) | Systeme et procede de calcul partage utilisant une fourniture automatisee de ressources informatiques heterogenes | |
| 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 | |
| WO2003071430A1 (fr) | Méthode de stockage de blocs de données dans une mémoire | |
| FR3025909A3 (fr) | Audit de video sur le web | |
| US20220067004A1 (en) | Merges using key range data structures | |
| Waibel et al. | Cost-optimized redundant data storage in the cloud | |
| FR2972090B1 (fr) | Determination de la validite d'un abonnement pour l'utilisation de contenus numeriques | |
| EP3579108B1 (fr) | Contrôleur de partage de ressources d'une plate-forme informatique et procédé associé de partage des ressources | |
| FR3076001A1 (fr) | Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees | |
| 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 | |
| FR2897961A1 (fr) | Procede de gestion de l'execution d'un jeu video pour la diffusion en temps reel de publicites dynamiques | |
| FR2767399A1 (fr) | Procede de determination du temps de demarrage d'un systeme informatique | |
| 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 | |
| FR3082018A1 (fr) | Dispositif et procede pour l'optimisation de l'utilisation dans le temps des ressources d'une infrastructure informatique | |
| Quaresma et al. | Validation of a simulation model for faas performance benchmarking using predictive validation | |
| FR3074939A1 (fr) | Procede de gestion du systeme de fichiers d'un terminal informatique | |
| WO2020193761A1 (fr) | Système de stockage redondant de données, procédé et programme d'ordinateur correspondants | |
| FR2980007A1 (fr) | Procede, dispositif et programme d'ordinateur pour allouer dynamiquement des ressources d'un cluster a l'execution de processus d'une application | |
| EP3239851A1 (fr) | Gestion de l'accès a des données dans un système de stockage | |
| EP4113297A1 (fr) | Procédé de gestion des travaux dans un système informatique et système associé | |
| NL2015243B1 (en) | Method and system for predictively providing software. | |
| CN117076696A (zh) | 数据处理方法、装置、电子设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20190628 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| TQ | Partial transmission of property |
Owner name: BULL SAS, FR Effective date: 20220809 Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERG, FR Effective date: 20220809 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |