FR2996656A1 - Systeme de traitement comportant une pluralite d'instances de serveur et un module de mise a l'echelle automatique - Google Patents

Abstract

Un système de traitement, typiquement dit en nuage, comporte une pluralité d'instances de serveur (210, 211, 212) et un module de mise à l'échelle automatique (201) adapté pour dynamiquement créer et supprimer au moins une instance de serveur en fonction de besoins en capacité de traitement dudit système. Chaque instance de serveur dispose d'une unité de stockage local (220, 221, 222) et comporte des moyens de communication avec au moins une autre instance de serveur, lesdits moyens de communication étant adaptés pour stocker sur l'unité de stockage local de ladite ou desdites autre(s) instance(s) de serveur des données à pérenniser lorsque le module de mise à l'échelle automatique ordonne une suppression de ladite instance de serveur

Description

La présente invention concerne un système de traitement comportant une pluralité d'instances de serveur et un module de mise à l'échelle automatique adapté pour dynamiquement créer et supprimer au moins une instance de serveur en fonction de besoins en capacité de traitement dudit système.

De nos jours, des systèmes de traitement, généralement dits en nuage (« coud computing systems » en anglais), permettent à un utilisateur de déporter sur des serveurs distants des stockages et des traitements informatiques traditionnellement localisés sur des serveurs locaux ou sur des postes utilisateurs. L'utilisateur n'a alors pas à gérer de serveurs informatiques ni d'infrastructure coordonnant ces serveurs informatiques, et peut cependant accéder de manière évolutive à des services via lesquels l'utilisateur peut faire exécuter des applications de traitement de données. La Fig. 1 illustre schématiquement un système de traitement en nuage selon l'état de la technique. Le système de traitement en nuage comporte un module de mise à l'échelle automatique (« auto-scaling module » en anglais) 101 dont la fonction principale est de dynamiquement créer et supprimer des instances de serveur 110, 111, 112, en fonction de besoins en capacité de traitement simultané dudit système. Le module de mise à l'échelle automatique 101 dispose typiquement d'une liste d'instances de serveur actives dans le système de traitement en nuage. Le module de mise à l'échelle automatique 101 communique avec ces instances de serveur 110, 111, 112 dans le cadre d'une mise en oeuvre de dimensionnement (« provisioning » en anglais) du système de traitement en nuage. On citera par exemple le système EC2 (« Elastic Compute Cloud » en anglais) de la société Amazon Web Services LLC. Les instances de serveur 110, 111, 112 disposent d'unités de stockage local 120, 121, 122 respectives. Ces unités de stockage local 120, 121, 122 permettent aux instances de serveur 110, 111, 112 respectives de stocker des valeurs temporaires de données, ou des fichiers temporaires, obtenus et utilisés au cours des traitements que les instances de serveur 110, 111, 112 effectuent. Chaque unité de stockage 120, 121, 122 est dite de stockage local car elle appartient à la plateforme matérielle sur laquelle l'instance de serveur 110, 111, 112 respective est implémentée. Chaque unité de stockage local 120, 121, 122 correspond typiquement à un système de fichiers sur une portion prédéterminée d'un disque dur (« hard disk drive » en anglais) de ladite plateforme matérielle. Afin de pérenniser les résultats des traitements effectués par les instances de serveur 110, 111, 112, notamment à la suppression d'au moins une instance de serveur, les instances de serveur 110, 111, 112 disposent d'une unité commune de stockage distant 130. Cette unité commune de stockage distant 130 permet en outre aux instances de serveur 110, 111, 112 de partager des fichiers communs. Par exemple, dans le cadre d'un service de dématérialisation de documents, l'instance de serveur 110 peut être amenée à effectuer un premier traitement sur un fichier représentatif d'un document numérisé, comme par exemple un traitement de reconnaissance de caractères, et l'instance de serveur 111 peut être amenée à effectuer un second traitement sur ce fichier, comme par exemple un traitement de tatouage numérique (« digital watermarking » en anglais). Les instances de serveur 110, 111 accèdent alors audit fichier à partir de l'unité commune de stockage distant 130 et stockent sur l'unité commune de stockage distant 130 le résultat de leurs traitements respectifs. Une telle architecture pose un problème de performance. En effet, la multitude d'accès à l'unité commune de stockage distant 130 effectués par les instances de serveur 110, 111, 112 engendre un trafic de données fortement consommateur en bande passante entre chaque plateforme implémentant une telle instance de serveur 110, 111, 112 et l'unité commune de stockage distant 130. De plus, une telle architecture nécessite la mise en place d'une plateforme matérielle distante comportant l'unité commune de stockage distant 130, ce qui pose des problèmes de coûts et de complexité de mise en oeuvre. Il est donc souhaitable de pallier ces inconvénients de l'état de la technique, et notamment de fournir une solution plus efficace en termes de performance et de coût matériel, et qui soit plus simple de mise en oeuvre. L'invention concerne un système de traitement comportant une pluralité d'instances de serveur et un module de mise à l'échelle automatique adapté pour dynamiquement créer et supprimer au moins une instance de serveur en fonction de besoins en capacité de traitement dudit système, chaque instance de serveur disposant d'une unité de stockage local. Le système est tel que chaque instance de serveur comporte des moyens de communication avec au moins une autre instance de serveur, lesdits moyens de communication étant adaptés pour stocker sur l'unité de stockage local de ladite ou desdites autre(s) instance(s) de serveur des données à pérenniser lorsque le module de mise à l'échelle automatique ordonne une suppression de ladite instance de serveur. Ainsi, les performances sont accrues, la mise en oeuvre est simplifiée et à coût réduit du fait de reposer sur les unités de stockage local des instances de serveur. Selon un mode de réalisation particulier, chaque unité de stockage d'instance de serveur est adaptée pour exporter un système de fichiers, et en ce que lesdites données à pérenniser sont sous la forme de fichiers. L'identification et l'organisation des données sont ainsi facilitées. Selon un mode de réalisation particulier, le module de mise à l' échelle automatique comporte des moyens de transmission aux instances de serveur d'une liste identifiant chacune desdites instances de serveur. Ainsi, les instances de serveur ont dynamiquement connaissance des instances de serveur effectivement présentes dans le système de traitement. Selon un mode de réalisation particulier, chaque instance de serveur comporte un module d'interface de communication avec chacune des autres instances de serveur identifiées dans ladite liste. Ainsi, un maximum de flexibilité est apporté pour pérenniser les données. Selon un mode de réalisation particulier, chaque instance de serveur comporte une application adaptée pour effectuer un traitement dans le cadre d'un service mis en oeuvre par ledit système de traitement et un module de gestion de stockage rendant transparent le stockage de données manipulées par ladite application au cours dudit traitement. Ainsi, les applications pour la mise en oeuvre du service peuvent être développées en faisant abstraction de l'implémentation effective du stockage de données. Selon un mode de réalisation particulier, chaque instance de serveur comporte : des moyens d'ordonner le stockage par l'unité de stockage local de ladite instance de serveur de chaque donnée manipulée par ladite application au cours dudit traitement ; des moyens de détection d'un ordre de suppression d'instance de serveur ; des moyens d'identification de chaque donnée stockée par l'unité de stockage local de ladite instance de serveur et qui est à pérenniser après la suppression de ladite instance de serveur, lesdits moyens d'identification étant mis en oeuvre sur détection dudit ordre de suppression ; des moyens de transfert à au moins une autre instance de serveur de chaque donnée identifiée. Ainsi, la pérennité des données est assurée de manière simple et les temps d'accès aux données sont globalement réduits. Selon un mode de réalisation particulier, les unités de stockage local des instances de serveur forment, en ce qui concerne lesdites données à pérenniser, un regroupement redondant de disques indépendants. Ainsi, les données sont pérennisées même en cas de dysfonctionnement ou de disparition d'une instance de serveur. Selon un mode de réalisation particulier, chaque unité de stockage d'instance de serveur comporte un premier espace mémoire dédié au stockage desdites données à pérenniser, et un second espace mémoire dédié au stockage uniquement local de données temporaires. Ainsi, la gestion des données est simplifiée. L'invention concerne également un procédé mis en oeuvre par un système de traitement comportant une pluralité d'instances de serveur et un module de mise à l'échelle automatique, ledit module de mise à l'échelle automatique créant et supprimant dynamiquement au moins une instance de serveur en fonction de besoins en capacité de traitement dudit système, chaque instance de serveur disposant d'une unité de stockage local. Le procédé est tel que chaque instance de serveur communique avec au moins une autre instance de serveur pour stocker sur l'unité de stockage local de ladite ou desdites autre(s) instance(s) de serveur des données à pérenniser lorsque le module de mise à l'échelle automatique ordonne une suppression de ladite instance de serveur. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : - la Fig. 1 illustre schématiquement un système de traitement en nuage selon l'état de la technique ; - la Fig. 2 illustre schématiquement un système de traitement selon la présente invention ; - la Fig. 3 illustre schématiquement une architecture d'instance de serveur dans le système de traitement de la Fig. 2 ; - la Fig. 4 illustre schématiquement un exemple d'architecture matérielle supportant au moins une instance de serveur de la Fig. 3 ; - la Fig. 5 illustre schématiquement un algorithme, mis en oeuvre par un module de mise à l'échelle automatique, de diffusion d'une liste d'instances de serveur actives dans le système de traitement de la Fig. 2 ; - la Fig. 6 illustre schématiquement un algorithme de traitement d'un ordre de lecture de fichier, mis en oeuvre par un module de gestion de stockage ; - la Fig. 7 illustre schématiquement un algorithme de traitement d'un ordre d'effacement de fichier, mis en oeuvre par le module de gestion de stockage ; - la Fig. 8 illustre schématiquement un algorithme de traitement d'un ordre de suppression d'instance de serveur.

Afin d'améliorer les performances d'un système de traitement, typiquement dit en nuage (« cloud computing » en anglais), il est proposé de s'appuyer sur des unités de stockage local d'instances de serveur, qui sont habituellement utilisées pour stocker des valeurs temporaires de données ou des fichiers temporaires lors de traitements mis en oeuvre par ces instances de serveur. Chaque instance de serveur communique alors avec au moins une autre instance de serveur pour stocker sur l'unité de stockage local de cette autre instance de serveur des données à pérenniser lorsqu'une suppression de ladite instance de serveur est ordonnée. La Fig. 2 illustre schématiquement un système de traitement selon la présente invention. Le système de traitement comporte un module de mise à l'échelle automatique 201 dont la fonction principale est de dynamiquement créer et supprimer des instances de serveur 210, 211, 212, en fonction de besoins en capacité de traitement simultané dudit système. Le système de traitement comporte une pluralité d'instances de serveur. Le module de mise à l'échelle automatique 201 dispose typiquement d'une liste d'instances de serveur actives dans le système de traitement.

Le module de mise à l'échelle automatique 201 communique avec ces instances de serveur 210, 211, 212 dans le cadre d'une mise en oeuvre de dimensionnement du système traitement. Les instances de serveur 210, 211, 212 disposent respectivement d'unités de stockage local 220, 221, 222. Ces unités de stockage local 220, 221, 222 permettent aux instances de serveur 210, 211, 212 de stocker des données, ou des fichiers, obtenus et/ou utilisés au cours des traitements que les instances de serveur 210, 211, 212 effectuent. Chaque unité de stockage 220, 221, 222 est dite de stockage local car elle appartient à la plateforme matérielle sur laquelle l'instance de serveur 210, 211, 212 respective est implémentée. Chaque unité de stockage local 220, 221, 222 est préférentiellement adaptée pour exporter un système de fichiers implémenté sur une portion prédéterminée d'un disque dur de ladite plateforme matérielle, et les données qui y sont stockées le sont sous forme de fichiers. Les unités de stockage 220, 221, 222 étant locales du point de vue respectivement des instances de serveur 210, 211, 212, les données et fichiers peuvent y être rapidement stockés et rapidement récupérés, comparativement à une unité de stockage d'une plateforme distante. Les instances de serveur 210, 211, 212 mettent en oeuvre un mécanisme distribué de pérennisation de données, reposant sur une utilisation des unités de stockage locales 220, 221, 222. La Fig. 3 illustre schématiquement une architecture de chacune des instances de serveur 210, 211, 212. Prenons l'exemple de l'instance de serveur 210. L'instance de serveur 210 comporte une application 301, un module de gestion de stockage 302, un module d'interface 310 de communication avec le module de mise à l'échelle automatique 201, un module d'interface 320 de communication avec au moins une des autres instances de serveur du système de traitement, i.e. les instances de serveur 211, 212 dans le système de la Fig. 2, et un module d'interface 330 de communication avec l'unité de stockage local 220. Préférentiellement, le module d'interface de communication 330 permet à l'instance de serveur 210 de communiquer avec chacune des autres instances de serveur 211, 212 identifiées dans la liste d'instances de serveur fournie par le module de mise à l'échelle automatique 201. L'application 301 est adaptée pour effectuer des traitements sur des données, ou des fichiers, dans le cadre d'un service mis en oeuvre par le système de traitement. Par exemple, dans le cadre d'un service de dématérialisation comme déjà mentionné, l'application 301 met en oeuvre le traitement de reconnaissance de caractère ou de tatouage numérique. Le module d'interface de communication 310 permet au module de mise à l'échelle automatique 201 d'ordonner une mise en place de ressources pour établir un contexte d'exécution du traitement, à la création de l'instance de serveur 210, et d'ordonner une libération des ressources pour ce contexte, à la suppression de l'instance de serveur 210. Les ordres y afférant sont transmis par le module d'interface de communication 310 à l'application 301. Le module d'interface de communication 310 permet en outre au module de mise à l'échelle automatique 201 de fournir à l'instance de serveur 210 une liste identifiant chacune des instances de serveur actives dans le système de traitement. Cette liste est transmise par le module d'interface de communication 310 au module de gestion de stockage 302. Un algorithme de diffusion de cette liste d'instances de serveur actives est décrit ci-après en relation avec la Fig. 5.

Le module de gestion de stockage 302 a pour fonctions principales de rendre transparent pour l'application 301 le mécanisme de pérennisation de données et de mettre en oeuvre ce mécanisme de pérennisation de données. Pour ce faire, le module de gestion de stockage 302 et le module d'interface 320 sont adaptés pour stocker sur l'unité de stockage local d'au moins une autre instance de serveur des données à pérenniser lorsque le module de mise à l'échelle automatique 201 ordonne une suppression de l'instance de serveur 210. Le module de gestion de stockage 302 interagit avec le module d'interface 330 de communication avec l'unité de stockage local 220 pour : obtenir des données, ou des fichiers, stockées sur l'unité de stockage local 220 ; écrire des données, ou des fichiers, à stocker sur l'unité de stockage local 220 ; et ordonner que soient effacées des données, ou des fichiers, stockées sur l'unité de stockage local 220. Le module de gestion de stockage 302 interagit avec le module d'interface 320 de communication avec au moins une autre instance de serveur du système de traitement pour : obtenir des données, ou des fichiers, stockées sur l'unité de stockage local de cette autre instance de serveur ; transférer des données, ou des fichiers, à stocker sur l'unité de stockage local de cette autre instance de serveur ; et ordonner que soient effacées des données, ou des fichiers, stockées sur l'unité de stockage local de cette autre instance de serveur.

Le comportement du module de gestion de stockage 302, dans un mode de réalisation particulier, est décrit ci-après en relation avec les Figs. 6 et 7, en ce qui concerne respectivement des opérations de lecture et d'écriture de fichiers. Le comportement du module de gestion de stockage 302, en ce qui concerne la suppression de l'instance de serveur 210 dans ce mode de réalisation particulier, est décrit ci-après en relation avec la Fig. 8. Dans un autre mode de réalisation particulier, les unités de stockage local 220, 221, 222 des instances de serveur 210, 211, 212 forment, en ce qui concerne les données à pérenniser, un regroupement redondant de disques indépendants RAID (« Redundant Array of Independent Disks » en anglais). Selon un premier exemple, un mécanisme de type RAID 0 peut être mis en oeuvre de manière à ce que le module de gestion de stockage 302 utilise au moins l'unité de stockage local d'au moins une autre instance de serveur comme miroir de stockage des données à pérenniser. Selon un second exemple, un mécanisme de type RAID 5 peut être mis en oeuvre de manière à ce que le module de gestion de stockage 302 utilise au moins l'unité de stockage local d'au moins une autre instance de serveur pour introduire dans le système de traitement des données de redondance permettant, après suppression de l'instance de serveur 210, de récupérer les données qui étaient à pérenniser. Dans un mode de réalisation particulier, chaque unité de stockage local d'instance de serveur comporte un premier espace mémoire dédié au stockage des données à pérenniser, et un second espace mémoire dédié au stockage uniquement local de données temporaires. Cela facilite la mise en oeuvre du mécanisme de type RAID. La Fig. 4 illustre schématiquement un exemple d'architecture d'une plateforme matérielle sur laquelle le module de mise à l'échelle automatique 201 et/ou au moins une instance de serveur 210, 211, 212 est implémenté. La plateforme matérielle comporte, reliés par un bus de communication 410 : un processeur ou CPU (« Central Processing Unit » en anglais) 400 ; une mémoire vive RAM (« Random Access Memory » en anglais) 401 ; une mémoire morte ROM (« Read Only Memory » en anglais) 402 ; une unité de stockage, tel qu'un disque dur HDD 403 ; une interface 404 permettant de communiquer avec d'autres plateformes matérielles du système de traitement via un réseau de communication. Le processeur 400 est capable d'exécuter des instructions chargées dans la RAM 401 à partir de la ROM 402, d'une mémoire externe (non représentée), d'un support de stockage, ou d'un réseau de communication. Lorsque la plateforme matérielle est mise sous tension, le processeur 400 est capable de lire de la RAM 401 des instructions et de les exécuter. Ces instructions forment au moins un programme d'ordinateur causant la mise en oeuvre, par le processeur 400, des algorithmes et étapes décrits ci-après. Les algorithmes et étapes décrits ci-après sont ainsi implémentés sous forme logicielle par exécution d'un ensemble d'instructions par une machine programmable, tel qu'un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur. La Fig. 5 illustre schématiquement un algorithme, mis en oeuvre par le module de mise à l'échelle automatique 201, de diffusion d'une liste d'instances de serveur actives dans le système de traitement de la Fig. 2.

Dans une étape 501, le module de mise à l'échelle automatique 201 détecte un besoin de création ou de suppression d'une instance de serveur. Le module de mise à l'échelle automatique 201 procède alors, ou ordonne, à la création ou à la suppression de l'instance de serveur. Dans le cadre de la création d'une instance de serveur, le module de mise à l'échelle automatique 201 communique à l'instance de serveur créée un ordre de mise en place de ressources pour établir un contexte d'exécution du ou des traitement(s) à effectuer par l'application 301 de l'instance de serveur créée. Dans le cadre de la suppression d'une instance de serveur, le module de mise à l'échelle automatique 201 communique à l'instance de serveur à supprimer un ordre de libération de ressources dudit contexte. Dans une étape 502 suivante, le module de mise à l'échelle automatique 201 met à jour une liste d'instances de serveur actives dans le système de traitement, suite à l'opération de création ou de suppression de ladite instance de serveur. Dans une étape 503 suivante, le module de mise à l'échelle automatique 201 transmet à chacune des instances de serveur actives dans le système de traitement liste des instances de serveur actives, après mise à jour. La diffusion de cette liste permet à chacune des instances de serveur d'avoir la connaissance des autres instances de serveur dans le système de traitement, afin de mettre en place des transferts de données à pérenniser.

La Fig. 6 illustre schématiquement un algorithme de traitement d'un ordre de lecture de fichier, mis en oeuvre par le module de gestion de stockage 302, dans un mode de réalisation particulier. Considérons l'instance de serveur 210. Dans une étape 601, le module de gestion de stockage 302 reçoit un ordre de lecture de fichier, en provenance de l'application 301. D'une manière plus générale, le module de gestion de stockage 302 reçoit un ordre de lecture de données stockées. L'application 301 envoie un tel ordre au module de gestion de stockage 302 lorsque l'application 301 doit obtenir un fichier, ou des données, dans le cadre d'un traitement effectué dans le cadre du service mis en oeuvre par le système de traitement. Par exemple, dans le cadre d'un service de dématérialisation comme déjà mentionné, l'application 301 requiert d'obtenir un document numérisé dans le cadre du traitement de reconnaissance de caractère, ou l'application 301 requiert d'obtenir des données de marquage à insérer dans un document dans le cadre du traitement de tatouage numérique. Dans une étape 602 suivante, le module de gestion de stockage 302 détermine si le fichier, ou plus généralement les données, est stocké par l'unité de stockage local 220 ou par une unité de stockage local d'une des autres instances de serveur du système de traitement. Si le fichier, ou les données, est stocké localement, une étape 603 est effectuée ; sinon, une étape 604 est effectuée.

Dès que le module de gestion de stockage 302 doit déterminer si un fichier, ou des données, est stocké par l'unité de stockage local 220 ou par une unité de stockage local d'une autre instance de serveur, le module de gestion de stockage 302 peut requérir auprès de l'unité de stockage local 220 une recherche du fichier, ou des données, concernées. En variante, le module de gestion de stockage 302 peut garder une trace de tout fichier, ou données, que le module de gestion de stockage 302 ordonne d'écrire sur l'unité de stockage local 220 ou d'effacer de l'unité de stockage local 220. Dans l'étape 603, le module de gestion de stockage 302 obtient le fichier, ou plus généralement les données, via l'interface de communication 330, c'est-à-dire à partir de l'unité de stockage local 220. Le fichier, ou les données, obtenu est transmis à l'application 301. Il est alors mis fin à l'algorithme. Dans l'étape 604, le module de gestion de stockage 302 obtient le fichier, ou plus généralement les données, via l'interface de communication 320, c'est-à-dire à partir de l'unité de stockage local d'une autre instance de serveur. Pour ce faire, le module de gestion de stockage 302 sélectionne une instance de serveur active dans la liste d'instances de serveur actives reçues à l'étape 503 déjà décrite, puis requiert le fichier, ou les données, auprès de cette instance de serveur par le biais d'un message dédié. Le module de gestion de stockage 302 de cette instance de serveur sélectionnée reçoit ledit message via l'interface de communication 320 et vérifie si le fichier, ou les données, requis est stocké sur l'unité de stockage local. Si tel est le cas, le module de gestion de stockage 302 de cette instance de serveur sélectionnée obtient le fichier, ou les données, via l'interface de communication 330, c'est-à-dire à partir de l'unité de stockage local de cette instance de serveur sélectionnée, et transmet le fichier, ou les données, en réponse au message reçu ; sinon, le module de gestion de stockage 302 de cette instance de serveur sélectionnée retourne un message d'erreur. Le module de gestion de stockage 302 sélectionne alors une autre instance de serveur active dans la liste d'instances de serveur actives, puis réitère la requête, et ce jusqu'à ce qu'une instance de serveur fournisse le fichier, ou les données, requis.

Dans une étape 605 suivante, le module de gestion de stockage 302 transmet le fichier, ou les données, à l'application 301, ainsi qu'au module de communication 320 pour stockage du fichier, ou des données, sur l'unité de stockage local 220. Dans une étape 606 suivante, le module de gestion de stockage 302 ordonne à l'instance de serveur qui a fourni le fichier, ou les données, d'effacer ce fichier, ou ces données. Le module de gestion de stockage 302 de l'instance de serveur qui a fourni le fichier, ou les données, procède alors à l'effacement du fichier, ou des données, de son unité de stockage local. Le module de gestion de stockage 302 de l'instance de serveur qui a fourni le fichier, ou les données, peut aussi procéder de lui-même à cet effacement, une fois le fichier, ou les données, transféré. Il est alors mis fin à l' algorithme. Lorsque l'application 301 requiert l'écriture d'un fichier, ou plus généralement de données, le module de gestion de stockage 302 ordonne l'écriture de ce fichier, ou de ces données, sur l'unité de stockage local 220 via l'interface de communication 330. Ainsi, en conjonction avec l'algorithme de la Fig. 6, chaque donnée manipulée par l'application 301 est stockée sur l'unité de stockage local 220. La Fig. 7 illustre schématiquement un algorithme de traitement d'un ordre d'effacement de fichier, mis en oeuvre par le module de gestion de stockage 302, dans le cadre du mode de réalisation particulier de la Fig. 6. Considérons l'instance de serveur 210. Dans une étape 701, le module de gestion de stockage 302 reçoit un ordre d'effacement de fichier, en provenance de l'application 301. D'une manière plus générale, le module de gestion de stockage 302 reçoit un ordre d'effacement de données stockées.

Dans une étape 702 suivante, le module de gestion de stockage 302 détermine si le fichier, ou plus généralement les données, est stocké par l'unité de stockage local 220 ou par une unité de stockage d'une des autres instances de serveur actives du système de traitement. Si le fichier, ou les données, est stocké localement, une étape 703 est effectuée ; sinon, une étape 704 est effectuée.

Dans l'étape 703, le module de gestion de stockage 302 ordonne l'effacement du fichier, ou plus généralement des données, via l'interface de communication 330, c'est-à-dire à l'unité de stockage local 220. Il est alors mis fin à l'algorithme. Dans l'étape 704, le module de gestion de stockage 302 ordonne l'effacement du fichier, ou plus généralement des données, via l'interface de communication 320, c'est-à-dire à une autre instance de serveur. Pour ce faire, le module de gestion de stockage 302 sélectionne une instance de serveur active dans la liste d'instances de serveur actives reçues à l'étape 503 déjà décrite, puis ordonne l'effacement du fichier, ou des données, auprès de cette instance de serveur par le biais d'un message dédié. Le module de gestion de stockage 302 de cette instance de serveur sélectionnée reçoit ledit message via l'interface de communication 320 et vérifie si le fichier, ou les données, requis est stocké sur l'unité de stockage local. Si tel est le cas, le module de gestion de stockage 302 de cette instance de serveur sélectionnée ordonne l'effacement du fichier, ou des données, via l'interface de communication 330, c'est- à-dire à l'unité de stockage local de cette instance de serveur sélectionnée ; sinon, le module de gestion de stockage 302 de cette instance de serveur sélectionnée retourne un message d'erreur. Le module de gestion de stockage 302 sélectionne alors une autre instance de serveur active dans la liste d'instances de serveur actives, puis réitère la requête, et ce jusqu'à effacement du fichier, ou des données. En variante, le module de gestion de stockage 302 peut ordonner l'effacement du fichier, ou des données, à l'ensemble des autres instances de serveur de la liste d'instances de serveur actives. L'instance de serveur pour laquelle le fichier, ou les données, est stocké localement procède alors à l'effacement effectif du fichier, ou des données. Il est alors mis fin à l' algorithme.

La Fig. 8 illustre schématiquement un algorithme de traitement d'un ordre de suppression d'instance de serveur, dans le cadre du mode de réalisation particulier des Figs. 6 et 7. Considérons l'instance de serveur 210. Dans une étape 801, l'application 301 reçoit un ordre de suppression d'instance de serveur via le module d'interface 310, c'est-à-dire en provenance du module de mise à l'échelle automatique 201. L'application 301 transmet cet ordre au module de gestion de stockage 302. Dans une étape 802 suivante, sur détection dudit ordre de suppression, le module de gestion de stockage 302 identifie chaque fichier, ou plus généralement chaque donnée, stocké par l'unité de stockage local 220, et qui doit être pérennisé à la suppression de l'instance de serveur 210. Dans une étape 803 suivante, le module de gestion de stockage 302 transfère via l'interface de communication 320 chaque fichier, ou chaque donnée, identifié. Chaque fichier, ou chaque donnée, à pérenniser est alors transféré à une autre instance de serveur pour stockage sur l'unité de stockage local de cette autre instance de serveur.

Le module de gestion de stockage 302 peut mettre en place un mécanisme de balance de charge, de manière à répartir équitablement, ou selon les capacités des unités de stockage locales des autres instances de serveur, la consommation d'espace mémoire liée au stockage des fichiers, ou des données, à pérenniser. Pour effectuer ce transfert, le module de gestion de stockage 302 utilise la liste des instances de serveur actives reçue à l'étape 503 déjà décrite. Dans une étape 804 suivante, l'application 301 procède à la suppression de l'instance de serveur, c'est-à-dire à la libération des ressources qui avaient été allouées au contexte d'exécution du ou des traitement(s) mis en oeuvre par l'application 301.

Claims (9)

1. REVENDICATIONS1) Système de traitement comportant une pluralité d'instances de serveur (210, 211, 212) et un module de mise à l'échelle automatique (201) adapté pour dynamiquement créer et supprimer au moins une instance de serveur en fonction de besoins en capacité de traitement dudit système, chaque instance de serveur disposant d'une unité de stockage local (220, 221, 222), caractérisé en ce que chaque instance de serveur comporte des moyens de communication (302, 320) avec au moins une autre instance de serveur, lesdits moyens de communication étant adaptés pour stocker sur l'unité de stockage local de ladite ou desdites autre(s) instance(s) de serveur des données à pérenniser lorsque le module de mise à l'échelle automatique ordonne une suppression de ladite instance de serveur.
2. 2) Système de traitement selon la revendication 1, caractérisé en ce que chaque unité de stockage d'instance de serveur est adaptée pour exporter un système de fichiers, et en ce que lesdites données à pérenniser sont sous la forme de fichiers.
3. 3) Système de traitement selon l'une quelconque des revendications 1 et 2, caractérisé en ce que le module de mise à l'échelle automatique comporte des moyens de transmission aux instances de serveur d'une liste identifiant chacune desdites instances de serveur.
4. 4) Système de traitement selon la revendication 3, caractérisé en ce que chaque instance de serveur comporte un module d'interface de communication (320) avec chacune des autres instances de serveur identifiées dans ladite liste.
5. 5) Système de traitement selon la revendication 4, caractérisé en ce que chaque instance de serveur comporte une application (301) adaptée pour effectuer un traitement dans le cadre d'un service mis en oeuvre par ledit système de traitement et un module de gestion de stockage (302) rendant transparent le stockage de données manipulées par ladite application au cours dudit traitement.
6. 6) Système de traitement selon la revendication 5, caractérisé en ce que chaque instance de serveur comporte :- des moyens d'ordonner le stockage par l'unité de stockage local de ladite instance de serveur de chaque donnée manipulée par ladite application au cours dudit traitement ; - des moyens de détection (801) d'un ordre de suppression d'instance de serveur ; - des moyens d'identification (802) de chaque donnée stockée par l'unité de stockage local de ladite instance de serveur et qui est à pérenniser après la suppression de ladite instance de serveur, lesdits moyens d'identification étant mis en oeuvre sur détection dudit ordre de suppression ; des moyens de transfert (803) à au moins une autre instance de serveur de chaque donnée identifiée.
7. 7) Système de traitement selon la revendication 5, caractérisé en ce que les unités de stockage local des instances de serveur forment, en ce qui concerne lesdites données à pérenniser, un regroupement redondant de disques indépendants.
8. 8) Système de traitement selon la revendication 7, caractérisé en ce que chaque unité de stockage d'instance de serveur comporte un premier espace mémoire dédié au stockage desdites données à pérenniser, et un second espace mémoire dédié au stockage uniquement local de données temporaires.
9. 9) Procédé mis en oeuvre par un système de traitement comportant une pluralité d'instances de serveur (210, 211, 212) et un module de mise à l'échelle automatique (201), ledit module de mise à l'échelle automatique créant et supprimant dynamiquement au moins une instance de serveur en fonction de besoins en capacité de traitement dudit système, chaque instance de serveur disposant d'une unité de stockage local (220, 221, 222), caractérisé en ce que chaque instance de serveur communique avec au moins une autre instance de serveur pour stocker sur l'unité de stockage local de ladite ou desdites autre(s) instance(s) de serveur des données à pérenniser lorsque le module de mise à l'échelle automatique ordonne une suppression de ladite instance de serveur.