FR3031204A1 - Procede et systeme d'allocation de ressources de traitement pour l'execution d'un programme d'un equipement client - Google Patents

Abstract

La présente invention concerne un procédé (60) d'allocation de ressources de traitement (40) pour l'exécution d'un programme d'un équipement client (20), comportant une étape (61) préalable au cours de laquelle des ressources de traitement disponibles se connectent à un serveur de gestion (30), et des étapes de : - (64) connexion de l'équipement client à un serveur d'exécution, - (66) envoi d'une requête d'allocation de ressources de traitement au serveur de gestion, - (67) sélection, par le serveur de gestion, de ressources de traitement à allouer, dites « ressources de traitement réservées », - (68) commande d'un transfert des connexions des ressources de traitement réservées du serveur de gestion vers le serveur d'exécution (50), - (69) exécution du programme de l'équipement client au moyen des ressources de traitement réservées.

Description

1 DOMAINE TECHNIQUE La présente invention appartient au domaine des systèmes de calcul distribués, et concerne plus particulièrement un procédé et un système d'allocation dynamique de ressources de traitement pour l'exécution d'un 5 programme soumis par un équipement client. ÉTAT DE LA TECHNIQUE Selon l'état de l'art, afin de pouvoir exécuter un programme distribué sur plusieurs machines, un équipement client doit avant tout connaître les besoins en termes de ressources physiques requises par son programme 10 (définir le nombre de processeurs, la quantité de mémoire par processeur, l'espace de stockage, etc.). Il doit ensuite commencer par réserver les machines, s'y connecter, les configurer, et les provisionner, c'est à dire installer et activer l'ensemble des composants nécessaires à chacune des machines pour l'exécution dudit programme. Une fois tous ces pré-requis remplis, le 15 programme peut enfin être exécuté. Un des inconvénients des systèmes de calcul distribués actuels réside donc dans la difficulté, pour l'équipement client, d'identifier les machines susceptibles d'exécuter le programme, et de les réserver. En outre, il n'existe pas de mécanisme permettant de s'assurer simplement que les machines 20 réservées sont dédiées à l'équipement client, de sorte que des machines peuvent se retrouver partagées entre plusieurs équipements clients, éventuellement au détriment de la qualité de service de chacun desdits équipement clients. EXPOSÉ DE L'INVENTION 25 La présente invention a pour objectif de remédier à tout ou partie des limitations des solutions de l'art antérieur, notamment celles exposées ci-avant, en proposant une solution qui permette d'avoir une allocation dynamique de ressources de traitement pour l'exécution d'un programme d'un équipement client, et ce d'une manière transparente pour l'équipement client.

30 En outre, la présente invention a également pour objectif de proposer une solution qui permette d'assurer que les ressources de traitement allouées à un équipement client lui sont effectivement réservées. A cet effet, et selon un premier aspect, l'invention concerne un 3031204 2 procédé d'allocation de ressources de traitement pour l'exécution d'un programme d'un équipement client. Ledit procédé comporte une étape préalable au cours de laquelle des ressources de traitement disponibles se connectent à un serveur de gestion, ledit serveur de gestion mémorisant une liste desdites ressources de traitement disponibles qui lui sont connectées, et des étapes de : - connexion de l'équipement client à un serveur d'exécution, - envoi, par le serveur d'exécution au serveur de gestion, d'une requête d'allocation de ressources de traitement pour l'exécution du programme de l'équipement client, - sélection, par le serveur de gestion et parmi la liste de ressources de traitement disponibles, de ressources de traitement à allouer au serveur d'exécution, dites « ressources de traitement réservées », en fonction de la requête d'allocation, - commande, par le serveur de gestion, d'un transfert des connexions des ressources de traitement réservées dudit serveur de gestion vers le serveur d'exécution, - exécution, par le serveur d'exécution, du programme de l'équipement client au moyen des ressources de traitement réservées. Par conséquent, un serveur d'exécution s'occupe d'exécuter le programme pour le compte de l'équipement client, en particulier de répartir le programme sur différentes ressources de traitement et de collecter les différents résultats fournis par lesdites ressources de traitement. En outre, un serveur de gestion s'occupe d'allouer des ressources de traitement disponibles qui lui sont connectées, c'est-à-dire des ressources de traitement pré-réservées par ledit serveur de gestion. Sur requête d'allocation reçue du serveur d'exécution pour le compte de l'équipement client, le serveur de gestion sélectionne des ressources de traitement à allouer au serveur d'exécution, et commande une connexion de celles-ci audit serveur d'exécution. Ainsi, la connexion de chaque ressource de traitement sélectionnée est transférée au serveur d'exécution, de sorte que lesdites ressources de traitement sont effectivement réservées au serveur d'exécution 3031204 3 et ne peuvent plus être allouées à un autre équipement client par ledit serveur de gestion. Dans des modes particuliers de mise en oeuvre, le procédé d'allocation de ressources de traitement peut comporter en outre l'une ou 5 plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en oeuvre, le procédé d'allocation de ressources de traitement comporte des étapes, préalables à la connexion entre l'équipement client et le server d'exécution, de : 10 - connexion entre l'équipement client et le serveur de gestion, - activation du serveur d'exécution par le serveur de gestion. Du fait que c'est le serveur de gestion qui active le serveur d'exécution sur requête d'un équipement client, on comprend que ledit serveur de gestion correspond au premier point de contact pour chaque équipement client. Par 15 exemple, le serveur de gestion dispose d'une adresse IP publique pouvant être obtenue par les équipements clients. Le serveur de gestion active alors un serveur d'exécution pour chaque équipement client qui le souhaite, et délègue à ce serveur d'exécution les tâches relatives à l'exécution du programme, en particulier la répartition du programme à exécuter sur les différentes ressources 20 de traitement réservées et la collecte des résultats. Par conséquent, un seul et même serveur de gestion est utilisé par les équipements clients. Toutefois, le serveur de gestion s'occupe principalement de l'allocation des ressources de traitement. Le serveur de gestion ne s'occupe alors pas de l'exécution des programmes, qui sont exécutés par des serveurs 25 d'exécution dédiés respectifs desdits équipements clients, activés de manière dynamique, sur requête, par ledit serveur de gestion. Dans des modes particuliers de mise en oeuvre, la liste des ressources de traitement disponibles mémorisée par le serveur de gestion comporte des caractéristiques et/ou un identifiant pour chaque ressource de traitement 30 disponible. De telles dispositions permettent de mettre en oeuvre des mécanismes d'allocation des ressources de traitement plus évolués, et donc d'avoir une allocation plus efficace, par exemple en optimisant l'adéquation entre les 3031204 4 capacités de traitement des ressources de traitement réservées et la requête d'allocation reçue du serveur d'exécution. Dans des modes particuliers de mise en oeuvre, les caractéristiques d'une ressource de traitement correspondent à une capacité de traitement 5 et/ou à une localisation géographique de ladite ressource de traitement. Dans des modes particuliers de mise en oeuvre, après l'exécution du programme, les ressources de traitement réservées, à nouveau disponibles, se connectent au serveur de gestion. Dans des modes particuliers de mise en oeuvre, les ressources de 10 traitement comportent au moins un objet adapté à générer des données à traiter. Dans des modes particuliers de mise en oeuvre, les ressources de traitement comportent au moins un actionneur. Dans des modes particuliers de mise en oeuvre, la sélection des 15 ressources de traitement à allouer au serveur d'exécution est effectuée en fonction d'au moins un des critères suivants : - critère de proximité par rapport au serveur d'exécution, - critère de performances, - critère de qualité de service.

20 Dans des modes particuliers de mise en oeuvre, le procédé d'allocation de ressources de traitement comporte, pour au moins une ressource de traitement réservée, dite « serveur auxiliaire d'exécution », des étapes de : - envoi, par le serveur auxiliaire d'exécution au serveur de gestion, 25 d'une requête d'allocation de ressources de traitement pour l'exécution d'une partie du programme de l'équipement client, - sélection, par le serveur de gestion et parmi la liste de ressources de traitement disponibles, de ressources de traitement à allouer au serveur auxiliaire d'exécution, dites « ressources auxiliaires de 30 traitement réservées », en fonction de la requête d'allocation, - commande, par le serveur de gestion, d'un transfert des connexions des ressources auxiliaires de traitement réservées dudit serveur de gestion vers le serveur auxiliaire d'exécution, 3031204 5 - exécution, par le serveur auxiliaire d'exécution, de la partie du programme de l'équipement client au moyen des ressources auxiliaires de traitement réservées. Ainsi, une des ressources de traitement réservées peut se comporter 5 comme serveur auxiliaire d'exécution et requérir auprès du serveur de gestion des ressources de traitement qui lui seront réservées. L'aspect dynamique de l'allocation des ressources de traitement est encore amélioré. En effet, ces ressources de traitement sont allouées au serveur auxiliaire d'exécution de manière transparente pour le serveur d'exécution (et donc pour l'équipement 10 client), et pourront en outre être libérées par ledit serveur auxiliaire dès que la partie du programme reçue aura été exécutée, potentiellement avant les autres ressources de traitement réservées au serveur d'exécution. Selon un second aspect, la présente invention concerne un système d'allocation de ressources de traitement pour l'exécution d'un programme d'un 15 équipement client. Ledit système comporte des ressources de traitement adaptées à exécuter le programme, chaque ressource de traitement comportant des moyens de connexion et étant configurée pour se connecter à un serveur de gestion lorsque ladite ressource de traitement est disponible, ledit serveur de gestion comportant des moyens de mémorisation d'un liste des 20 ressources de traitement disponibles qui lui sont connectées. En outre, le serveur de gestion est configuré pour : - recevoir une requête d'allocation de ressources de traitement d'un serveur d'exécution connecté à l'équipement client, - sélectionner, parmi la liste de ressources de traitement disponibles, 25 des ressources de traitement à allouer au serveur d'exécution, dites « ressources de traitement réservées », en fonction de la requête d'allocation, - commander un transfert des connexions des ressources de traitement réservées dudit serveur de gestion vers le serveur 30 d'exécution pour exécuter le programme de l'équipement client. Dans des modes particuliers de réalisation, le système d'allocation de ressources de traitement peut comporter en outre l'une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons 3031204 6 techniquement possibles. Dans des modes particuliers de réalisation, l'équipement client comporte des moyens de connexion au serveur de gestion, et ledit serveur de gestion est configuré pour activer le serveur d'exécution et pour commander la 5 connexion entre l'équipement client et ledit serveur d'exécution. Dans des modes particuliers de réalisation, la liste des ressources de traitement disponibles mémorisée par le serveur de gestion comporte des caractéristiques et/ou un identifiant pour chaque ressource de traitement disponible.

10 Dans des modes particuliers de réalisation, les ressources de traitement comportent au moins un objet adapté à générer des données à traiter. Dans des modes particuliers de réalisation, au moins un objet est connecté au serveur de gestion ou au serveur d'exécution par l'intermédiaire 15 d'un proxy, ledit proxy étant configuré pour maintenir la connexion active lorsqu'aucune donnée n'est générée. Dans des modes particuliers de réalisation, les ressources de traitement comportent au moins un actionneur. PRÉSENTATION DES FIGURES 20 L'invention sera mieux comprise à la lecture de la description suivante, donnée à titre d'exemple nullement limitatif, et faite en se référant aux figures qui représentent : - Figures 1 et 2: des représentations schématiques de deux exemples de réalisation d'un système d'allocation de ressources de 25 traitement, - Figure 3 : un diagramme représentant les principales étapes d'un mode préféré de mise en oeuvre d'un procédé d'allocation de ressources de traitement, - Figures 4, 5 et 6 : des représentations schématiques de l'évolution 30 au cours du temps du système d'allocation de la figure 1, suite à la connexion d'un équipement client, - Figure 7 : un diagramme représentant un exemple de séquence de messages échangés pour d'allocation de ressources de traitement 3031204 7 et pour l'exécution d'un programme de l'équipement client. Dans ces figures, des références identiques d'une figure à une autre désignent des éléments identiques ou analogues. Pour des raisons de clarté, les éléments représentés ne sont pas à l'échelle, sauf mention contraire.

5 DESCRIPTION DÉTAILLÉE DE MODES DE RÉALISATION La figure 1 représente schématiquement un exemple de réalisation d'un système 10 d'allocation de ressources de traitement pour exécuter un programme (c'est-à-dire un logiciel) soumis par un équipement client 20. Tel qu'illustré par la figure 1, le système 10 d'allocation comporte un 10 serveur de gestion 30, auquel sont connectées plusieurs ressources de traitement 40 disponibles pour exécuter des programmes soumis par des équipements clients 20. Dans la suite de description, on se place de manière non limitative dans le cas où toutes les connexions sont des connexions TCP/IP. Rien n'exclut, suivant d'autres exemples, de considérer d'autres types 15 de connexions. En outre, des connexions de types différents peuvent coexister au sein du système 10 d'allocation. Dans l'exemple illustré par la figure 1, les ressources de traitement 40 sont uniquement des machines 41 disposant d'une capacité de traitement en termes de puissance de calcul (processeur, ASIC, FPGA, etc.) et de quantité 20 de mémoire, adaptées à traiter des données par exemple fournies par l'équipement client 20. Il est à noter que les machines 41 peuvent être virtuelles ou réelles. Une machine réelle correspond à un équipement matériel qui n'offre qu'une seule ressource de traitement 40. Dans le cas où un équipement matériel offre 25 plusieurs ressources de traitement 40 distinctes, alors chacune de ces ressources de traitement correspond à une machine virtuelle. Par exemple, dans un équipement matériel comportant plusieurs processeurs, chaque processeur peut être assimilé à une machine virtuelle, et être alloué en tant que ressource de traitement 40 distincte.

30 Toutefois, les machines 41, virtuelles ou réelles, susceptibles d'être connectées au serveur de gestion 30 correspondent de préférence à plusieurs équipements matériels distincts, afin notamment d'assurer une disponibilité minimale en cas de panne d'un desdits équipements matériels.

3031204 8 La figure 2 représente schématiquement un mode préféré de réalisation d'un système 10 d'allocation dans lequel certaines des ressources de traitement 40, susceptibles de se connecter au serveur de gestion 30, sont des objets 42 adaptés à générer des données à traiter. Dans un tel cas, les 5 données à traiter par les machines 41 allouées peuvent provenir exclusivement du ou des objets 42 alloués, ou peuvent provenir à la fois de l'équipement client 20 et d'un ou de plusieurs objets 42. Les objets 42 peuvent être par exemple des capteurs qui effectuent des mesures de manière récurrente. Par exemple, il peut s'agir de compteurs 10 de fluides (électricité, gaz, eau, etc.) qui émettent de façon récurrente les consommations mesurées en vue d'établir les factures associées, des stations météorologies, des serveurs de données (flux boursiers, etc.), etc. Dans le cas où un objet 42 émet de données de façon intermittente, il peut éventuellement s'avérer avantageux, tel qu'illustré par la figure 2, de 15 connecter cet objet 42 au serveur de gestion 30 par l'intermédiaire d'un proxy 43. Le proxy 43 est de préférence configuré pour maintenir la connexion active lorsqu'aucune donnée n'est générée. De telles dispositions permettent d'éviter que l'objet 42 ne se déconnecte du fait d'une absence prolongée d'émission de données, alors que ledit objet 42 est par ailleurs disponible en tant que 20 ressource de traitement 40. Dans des modes préférés de réalisation, certaines ressources de traitement 40 susceptibles de se connecter au serveur de gestion sont des actionneurs (non représentés sur les figures). Par exemple, pour exécuter un programme de contrôle de la consommation et de la température à l'intérieur 25 d'un bâtiment, il est possible de considérer des objets 42 de type capteurs de température, répartis à l'intérieur du bâtiment, qui fournissent des mesures locales de température, et de contrôler en fonction de ces mesures des actionneurs susceptibles d'influencer localement la température (moteurs de volets roulants, radiateurs commandables, fenêtres motorisées, etc.).

30 Les ressources de traitement 40, qu'il s'agisse de machines 41 (virtuelles ou réelles), d'objets 42 ou encore d'actionneurs, sont connectées au serveur de gestion 30 par des réseaux de communication respectifs, éventuellement hétérogènes. Tout réseau de communication adapté peut être 3031204 9 mis en oeuvre entre une ressource de traitement 40 et le serveur de gestion 30, y compris des moyens de communication sans fil. La figure 3 représente schématiquement un mode préféré de mise en oeuvre d'un procédé 60 d'allocation de ressources de traitement.

5 Tel qu'illustré par la figure 3, le procédé 60 d'allocation comporte tout d'abord une étape 61 au cours de laquelle des ressources de traitement disponibles se connectent au serveur de gestion 30. Le serveur de gestion 30 est configuré pour maintenir à jour une liste des ressources de traitement disponibles qui lui sont connectées.

10 Dans des modes préférés de mise en oeuvre, chaque ressource de traitement 40 disponible indique au serveur de gestion 30 des caractéristiques et/ou un identifiant de ladite ressource de traitement 40. La liste de ressources de traitement disponibles, maintenue par le serveur de gestion 30, comporte alors de préférence des caractéristiques et/ou un identifiant pour chaque 15 ressource de traitement 40 disponible. Les caractéristiques que peut indiquer une ressource de traitement 40 disponible, en particulier une machine 41, sont par exemple les capacités de traitement de cette machine 41. Par exemple, une machine 41 peut déclarer auprès du serveur de gestion 30 la puissance de calcul et la quantité de 20 mémoire disponibles. Une machine 41 peut également fournir des informations plus détaillées au serveur de gestion 30, comme par exemple indiquer la présence d'accélérateurs de fonctions mathématiques (par exemple un ASIC spécialisé en chiffrement/déchiffrement, en codage/décodage de canal, etc., un DSP spécialisé en traitement numérique du signal, etc.). Chaque objet 42 peut 25 également déclarer ses capacités de traitement, et indiquer par exemple le type de données qu'il génère. De même, chaque actionneur peut indiquer le type d'action qu'il est capable d'effectuer. Les caractéristiques que peut indiquer une ressource de traitement 40 disponibles peuvent également être, alternativement ou en complément, une 30 localisation géographique de ladite ressource de traitement 40. En outre, il peut s'avérer avantageux de pouvoir identifier de manière biunivoque, grâce à un identifiant unique, une ressource de traitement 40 particulière ou un groupe particulier de ressources de traitement 40.

3031204 10 Notamment, les objets 42 ne génèrent pas nécessairement tous le même type de données, et les actionneurs n'effectuent pas nécessairement tous le même type d'action. Ils ne sont donc pas tous interchangeables et doivent pouvoir être distingués les uns des autres.

5 Bien que la figure 3 ne fasse apparaître, de manière schématique, qu'une seule étape 61, on comprend que les connexions des différentes ressources de traitement 40 disponibles au serveur de gestion 30 peuvent être étalées au cours du temps et que, à un instant donné, le serveur de gestion 30 disposera d'un ensemble de ressources de traitement 40 disponibles.

10 Dans l'exemple illustré par la figure 3, le procédé 60 d'allocation comporte une étape 62 de connexion entre l'équipement client 20 et le serveur de gestion 30, au cours de laquelle l'équipement client 20 indique au serveur de gestion 30 qu'il souhaite faire exécuter un programme. De préférence, le serveur de gestion 30 dispose d'une adresse IP publique, pouvant être obtenue 15 par les équipements clients souhaitant faire exécuter un programme, et souhaitant à cet effet se faire allouer des ressources de traitement 40 par ledit serveur de gestion 30. Suite à l'étape 62 de connexion entre l'équipement client 20 et le serveur de gestion 30, le procédé 60 d'allocation comporte par exemple une 20 étape 63 d'activation, par le serveur de gestion 30, d'un serveur d'exécution 50. Le serveur de gestion 30 et le serveur d'exécution 50 sont par exemple des processus exécutés sur un même équipement matériel. Rien n'exclut cependant, suivant d'autres exemples, que le serveur de gestion 30 et le serveur d'exécution 50 correspondent à des équipements matériels distincts.

25 Le serveur d'exécution 50 est un processus en charge, pour le compte de l'équipement client 20, de l'exécution du programme. Le serveur d'exécution 50 est de préférence dédié à un seul équipement client 20. Toutefois, un même équipement matériel peut comporter plusieurs serveurs d'exécution (processus différents) actifs simultanément.

30 Ensuite, le procédé 60 d'allocation comporte une étape 64 de transfert de la connexion de l'équipement client 20 du serveur de gestion 30 vers le serveur d'exécution 50, au cours de laquelle on effectue une connexion entre l'équipement client 20 et le serveur d'exécution 50 et, éventuellement, une 3031204 11 déconnexion entre ledit équipement client 20 et le serveur de gestion 30. A l'issue de cette étape 64 de transfert, le serveur de gestion 30 et le serveur d'exécution 50 sont également connectés entre eux. Les figures 4 et 5 représentent schématiquement le système 10 5 d'allocation de la figure 1 à l'issue des étapes respectivement 62 de connexion entre l'équipement client 20 et le serveur de gestion, et 64 de transfert de la connexion entre l'équipement client 20 et le serveur de gestion 30. Par rapport à la figure 4, on constate que le système 10 d'allocation de la figure 5 comporte en outre le serveur d'exécution 50. En outre, la connexion entre l'équipement 10 client 20 et le serveur de gestion 30 n'est plus directe, mais l'équipement client 20 est connecté au serveur d'exécution 50, et ledit serveur d'exécution 50 est connecté au serveur de gestion 30. Il est à noter que rien n'exclut, suivant d'autres exemples, que l'équipement client 20 se connecte directement à un serveur d'exécution 50, 15 sans passer préalablement par le serveur de gestion 30. Dans un tel cas, le procédé 60 d'allocation ne comporte pas les étapes 62 de connexion entre l'équipement client 20 et le serveur de gestion et 63 d'activation du serveur d'exécution 50 par ledit serveur de gestion 30, et l'étape 64 de transfert se résume à une étape de connexion entre l'équipement client 20 et le serveur 20 d'exécution 50. La connexion préalable entre l'équipement client 20 et le serveur de gestion 30 correspond toutefois à un mode préféré de mise en oeuvre dans la mesure où, dans l'hypothèse où aucune ressource de traitement 40 ne serait disponible, l'équipement client 20 en sera immédiatement informé sans avoir à se connecter préalablement à un serveur d'exécution 50.

25 Dans l'exemple non limitatif illustré par la figure 3, le procédé 60 d'allocation comporte une étape 65 d'envoi, par l'équipement client 20, du programme à exécuter au serveur d'exécution 50. A partir du programme reçu de l'équipement client 20, le serveur d'exécution 50 établit une requête d'allocation des ressources de traitement 40 30 nécessaires. Alternativement, le serveur d'exécution 50 peut recevoir la requête d'allocation directement de l'équipement client 20, auquel cas le programme peut être reçu ultérieurement, par exemple une fois que les ressources de traitement 40 ont été réservées. Ensuite, le procédé 60 3031204 12 d'allocation comporte une étape 66 d'envoi de la requête d'allocation au serveur de gestion 30. Tel qu'illustré par la figure 3, le procédé 60 d'allocation comporte alors une étape 67 de sélection, par le serveur de gestion 30 et parmi la liste de 5 ressources de traitement disponibles, de ressources de traitement 40 à allouer au serveur d'exécution 50, désignées ci-après par « ressources de traitement réservées », en fonction de la requête d'allocation reçue. La sélection, par le serveur de gestion 30, peut s'effectuer de manière très simple. Par exemple, le serveur de gestion 30 peut, dans la limite du 10 nombre de ressources de traitement disponibles, allouer au serveur d'exécution 50 le nombre de ressources de traitement demandées dans la requête d'allocation. En outre, si l'identifiant d'une des ressources de traitement est fourni dans la requête d'allocation, le serveur de gestion 30 peut allouer la ressource de traitement correspondant à l'identifiant fourni, si elle est 15 disponible, ou rejeter la requête d'allocation, éventuellement en proposant une ressource de traitement 40 dont les caractéristiques sont semblables à celles de la ressource de traitement identifiée dans la requête d'allocation. Notamment, il est avantageux de pouvoir identifier de manière biunivoque différents objets 42 (ou groupes d'objets 42) afin de s'assurer que les données 20 traitées sont bien celles prévues, générées par un objet 42 spécifique ou par un objet 42 d'un groupe spécifique d'objets. De même, il est préférable de pouvoir identifier de manière biunivoque différents actionneurs (ou groupes d'actionneurs) afin de s'assurer que l'action réalisée est bien l'action prévue. Toutefois, et de préférence, d'autres critères peuvent être pris en 25 compte pour optimiser l'allocation des ressources de traitement. Par exemple, si le serveur de gestion 30 connaît les localisations géographiques des ressources de traitement 40 et du serveur d'exécution 50 (par exemple connue a priori du serveur de gestion 30 ou reçue dans la requête d'allocation), alors le serveur de gestion 30 peut sélectionner les 30 ressources de traitement 40 qui sont les plus proches du serveur d'exécution 50, afin de minimiser la latence liée aux échanges entre ledit serveur d'exécution 50 et les ressources de traitement réservées (critère de proximité). Suivant un autre exemple, si la requête d'allocation indique que des 3031204 13 fonctions mathématiques spécifiques doivent être utilisées lors de l'exécution du programme, alors le serveur de gestion 30 peut sélectionner des ressources de traitement 40 qui, d'après la liste, comportent des accélérateurs pour ces fonctions mathématiques (critère de performances).

5 Suivant un autre exemple, si la requête d'allocation indique des contraintes strictes en termes de délai pour obtenir le résultat de l'exécution du programme (priorité haute), ou bien au contraire qu'aucune contrainte de délai n'est imposée (priorité basse), alors le serveur de gestion 30 peut sélectionner un nombre plus ou moins important de ressources de traitement 40 et/ou 10 sélectionner des ressources de traitement 40 qui, d'après la liste, présentent des niveaux de qualité de service, en termes de délai, plus ou moins élevés (critère de qualité de service). Il est à noter en outre que le serveur de gestion peut mémoriser, pour chaque équipement client 20 susceptible de se connecter, une quantité 15 maximale de ressources de traitement autorisée. Dans un tel cas, la requête d'allocation comporte un identifiant de l'équipement client 20 à l'origine de cette requête d'allocation, et le serveur de gestion 30 alloue des ressources de traitement dans la limite de la quantité maximale de ressources de traitement autorisée pour l'équipement client 20 identifié dans la requête d'allocation.

20 A l'issue de l'étape 67 de sélection, une ou plusieurs ressources de traitement sont réservées. Le procédé 60 d'allocation comporte ensuite une étape 68 de transfert au cours de laquelle les connexions des ressources de traitement 40 réservées au serveur de gestion 30 sont transférées vers le serveur d'exécution 50. Ainsi, à l'issue de l'étape 68 de transfert les ressources 25 de traitement 40 réservées sont connectées au serveur d'exécution 50 et, par exemple, déconnectées dudit serveur de gestion 30. Le serveur de gestion 30 peut cependant également se comporter comme un proxy entre le serveur d'exécution 50 et les ressources de traitement 40 réservées. Les ressources de traitement réservées sont alors supprimées, par le serveur de gestion 30, de la 30 liste de ressources de traitement disponibles, ou simplement indiquées comme n'étant plus disponibles. La figure 6 représente schématiquement le système 10 d'allocation de la figure 1 à l'issue de l'étape 68 de transfert des connexions entre les 3031204 14 ressources de traitement 40 réservées et le serveur de gestion 30. Par rapport à la figure 5, on constate qu'une seule ressource de traitement a été réservée, en l'occurrence une machine 41R, et que celle-ci est connectée au serveur d'exécution 50 mais n'est plus, dans l'exemple représenté, connectée au 5 serveur de gestion 30. Le procédé 60 d'allocation comporte ensuite une étape 69 d'exécution, par le serveur d'exécution 50, du programme de l'équipement client 20 au moyen des ressources de traitement réservées. En particulier, le serveur d'exécution 50, qui a préalablement reçu le programme à exécuter de 10 l'équipement client 20, répartit les différentes parties (ou tâches) du programme sur les différentes ressources de traitement 40 réservées (fonction « map » dans la littérature anglo-saxonne), et collecte les résultats des exécutions de ces différentes parties par lesdites ressources de traitement réservées (fonction « reduce » dans la littérature anglo-saxonne).

15 De préférence, chaque ressource de traitement 40 réservée se reconnecte au serveur de gestion 30 immédiatement après avoir exécuté la partie du programme reçue. De telles dispositions permettent de libérer au plus tôt chaque ressource de traitement réservée, afin de la rendre à nouveau disponible pour d'autres équipements clients 20. Toutefois, une ressource de 20 traitement 40 réservée, après avoir exécuté la partie du programme reçue, peut également rester connectée au serveur d'exécution 50 jusqu'à ce que ledit serveur d'exécution 50 l'autorise à se reconnecter au serveur de gestion 30. De son côté, le serveur de gestion 30 actualise la liste de ressources de traitement disponibles en fonction des reconnexions de ressources de 25 traitement 40 auparavant réservées. Dans des modes préférés de mise en oeuvre, chaque ressource de traitement 40 réservée peut se comporter à son tour comme serveur auxiliaire d'exécution et requérir auprès du serveur de gestion 30 des ressources de traitement qui lui seront réservées, dites « ressources auxiliaires de traitement 30 réservées ». Les étapes pour ce faire sont essentiellement les mêmes que pour le serveur d'exécution 50. Par exemple, cela pourra être le cas si ladite ressource de traitement 40 réservée détermine que la partie du programme reçue peut être parallélisée, ou si elle reçoit de nouvelles données à traiter d'un 3031204 15 objet 42 ou de l'équipement client 20, etc. Une ressource auxiliaire de traitement réservée peut également se comporter, à son tour, comme serveur auxiliaire d'exécution, etc. On comprend donc que la topologie des ressources de traitement 40 réservées peut évoluer au cours du temps, afin de s'adapter 5 en temps réel aux besoins de l'exécution du programme reçu. La figure 7 représente schématiquement, à titre d'exemple non limitatif, une séquence de messages échangés pour l'allocation de ressources de traitement 40 et l'exécution du programme de l'équipement client 20. Les messages représentés sur la figure 7 correspondent principalement à des 10 messages échangés au cours des étapes 65 d'envoi du programme, 66 d'envoi de la requête d'allocation, 67 de sélection des ressources de traitement réservées, 68 de transfert des connexions entre les ressources de traitement réservées et le serveur de gestion 30, et 69 d'exécution du programme. Tel qu'illustré par la figure 7, l'équipement client 20 envoie au serveur 15 d'exécution 50, dans un message M1, le programme à exécuter, par exemple un tâche consistant en une série de calculs et de tirages aléatoires, ladite tâche devant être itérée 1000 fois. Le serveur d'exécution 50 envoie alors la requête d'allocation, dans un message M2, dans laquelle ledit serveur d'exécution 50 demande par exemple 20 au serveur de gestion 30 un nombre de ressources de traitement 40 égal au nombre d'itérations de la tâche (1000). Le serveur de gestion 30 indique alors au serveur d'exécution 50, dans un message M3, qu'il est prêt à lui allouer immédiatement un nombre de ressources de traitement 40 par exemple égal à 100.

25 Le serveur d'exécution 50 indique alors au serveur de gestion 30, dans un message M4, qu'il accepte de se faire allouer les 100 ressources de traitement proposées par ledit serveur de gestion 30. Le serveur de gestion 30 commande alors un transfert de connexion par l'envoi d'un message M5 aux ressources de traitement 40 réservées. Suite 30 à la réception du message M5, chaque ressource de traitement réservée envoie un message M6 au serveur d'exécution 50, par lequel elle se connecte audit serveur d'exécution 50. Les transferts de connexions sont asynchrones et ne sont donc pas forcément simultanés.

3031204 16 Dès d'une ressource de traitement 40 réservée est connectée au serveur d'exécution 50, celle-ci reçoit du serveur d'exécution 50, dans un message M7, le code de la tâche et commence à l'exécuter. Dès qu'une ressource de traitement 40 réservée a fini d'exécuter une 5 itération de la tâche, elle l'indique au serveur d'exécution 50, par un message M8, et reste connectée au serveur d'exécution 50. Ainsi, cette ressource de traitement 40 réservée peut être utilisée, par le serveur d'exécution 50, pour une nouvelle itération de la tâche sans transaction supplémentaire avec le serveur de gestion 30.

10 En outre, le serveur d'exécution 50 peut envoyer à nouveau des requêtes d'allocation au serveur de gestion 30, afin d'essayer d'obtenir d'autres ressources de traitement 40, et ce tant que le nombre (1000) d'itérations de la tâche n'a pas été atteint. Lorsque toutes les tâches ont été affectées, dès qu'une ressource de 15 traitement réservée termine son exécution, notifiée au serveur d'exécution 50 par un message M8, ledit serveur d'exécution 50 libère ladite ressource de traitement réservée par un message M9. Suite à la réception du message M9, la ressource de traitement réservée se déconnecte du serveur d'exécution 50 et se reconnecte au serveur de gestion 30.

20 Une fois la dernière ressource de traitement 40 réservée libérée et les résultats retournés au serveur d'exécution 50, celui les compile et les renvoie à l'équipement client 20 dans un message M10. Ensuite, le serveur d'exécution 50 peut par exemple déconnecter l'équipement client 20 et se terminer. Dans l'exemple illustré par la figure 7, on a considéré le cas d'un 25 programme non persistant, correspondant à une tâche devant être exécutée un nombre prédéterminé de fois (« batch » dans la littérature anglo-saxonne). Il est à noter que l'invention est également applicable pour l'exécution de programmes persistants (ou services). Dans un tel cas, le serveur d'exécution 50 ne se termine pas, et certaines ressources de traitement 40 réservées 30 peuvent éventuellement rester connectées audit serveur d'exécution 50, afin notamment de ne pas perdre leur état interne (mémoire, fonctions globales, variables globales, etc.) permettant d'exécuter le programme persistant.

Claims (10)

1. REVENDICATIONS1 - Procédé (60) d'allocation de ressources de traitement (40) pour l'exécution d'un programme d'un équipement client (20), caractérisé en ce qu'il comporte une étape (61) préalable au cours de laquelle des ressources de traitement disponibles se connectent à un serveur de gestion (30), ledit serveur de gestion mémorisant une liste desdites ressources de traitement disponibles qui lui sont connectées, et des étapes de : - (64) connexion de l'équipement client à un serveur d'exécution, - (66) envoi, par le serveur d'exécution (50) au serveur de gestion, d'une requête d'allocation de ressources de traitement pour l'exécution du programme de l'équipement client, - (67) sélection, par le serveur de gestion et parmi la liste de ressources de traitement disponibles, de ressources de traitement à allouer au serveur d'exécution, dites « ressources de traitement réservées », en fonction de la requête d'allocation, - (68) commande, par le serveur de gestion, d'un transfert des connexions des ressources de traitement réservées dudit serveur de gestion vers le serveur d'exécution, - (69) exécution, par le serveur d'exécution, du programme de l'équipement client au moyen des ressources de traitement réservées.
2. 2 - Procédé (60) selon la revendication 1, comportant des étapes, préalables à la connexion entre l'équipement client et le serveur d'exécution, de : - (62) connexion entre l'équipement client et le serveur de gestion, - (63) activation du serveur d'exécution par le serveur de gestion.
3. 3 - Procédé (60) selon l'une des revendications précédentes, dans lequel la liste des ressources de traitement disponibles mémorisée par ledit serveur de gestion comporte des caractéristiques et/ou un identifiant pour chaque ressource de traitement disponible.
4. 4 - Procédé (60) selon l'une des revendications précédentes, dans lequel les ressources de traitement comportent au moins un objet (42) adapté à générer des données à traiter et/ou au moins un actionneur. 3031204 18
5. 5 - Procédé (60) selon l'une des revendications précédentes, dans lequel la sélection des ressources de traitement à allouer au serveur d'exécution est effectuée en fonction d'au moins un des critères suivants : - critère de proximité par rapport au serveur d'exécution, 5 - critère de performances, - critère de qualité de service.
6. 6 - Procédé (60) selon l'une des revendications précédentes, comportant, pour au moins une ressource de traitement réservée, dite « serveur auxiliaire d'exécution », des étapes de : 10 - envoi, par le serveur auxiliaire d'exécution au serveur de gestion, d'une requête d'allocation de ressources de traitement pour l'exécution d'une partie du programme de l'équipement client, - sélection, par le serveur de gestion et parmi la liste de ressources de traitement disponibles, de ressources de traitement à allouer au 15 serveur auxiliaire d'exécution, dites « ressources auxiliaires de traitement réservées », en fonction de la requête d'allocation, - commande, par le serveur de gestion, d'un transfert des connexions des ressources auxiliaires de traitement réservées dudit serveur de gestion vers le serveur auxiliaire d'exécution, 20 - exécution, par le serveur auxiliaire d'exécution, de la partie du programme de l'équipement client au moyen des ressources auxiliaires de traitement réservées.
7. 7 - Système (10) d'allocation de ressources de traitement (40) pour l'exécution d'un programme d'un équipement client (20), caractérisé en ce 25 qu'il comporte des ressources de traitement, chaque ressource de traitement comportant des moyens de connexion et étant configurée pour se connecter à un serveur de gestion (30) lorsque ladite ressource de traitement est disponible, ledit serveur de gestion comportant des moyens de mémorisation d'un liste des ressources de traitement disponibles qui lui 30 sont connectées et étant configuré pour : - recevoir une requête d'allocation de ressources de traitement d'un serveur d'exécution (50) connecté à l'équipement client, - sélectionner, parmi la liste de ressources de traitement disponibles, 3031204 19 des ressources de traitement à allouer au serveur d'exécution, dites « ressources de traitement réservées », en fonction de la requête d'allocation, commander un transfert des connexions des ressources de 5 traitement réservées dudit serveur de gestion vers le serveur d'exécution pour exécuter le programme de l'équipement client.
8. 8 - Système (10) selon la revendication 7, dans lequel l'équipement client comporte des moyens de connexion au serveur de gestion, et dans lequel ledit serveur de gestion est configuré pour activer le serveur d'exécution et 10 pour commander la connexion entre l'équipement client et ledit serveur d'exécution.
9. 9 - Système (10) selon l'une des revendications 7 à 8, dans lequel la liste des ressources de traitement disponibles mémorisée par le serveur de gestion comporte des caractéristiques et/ou un identifiant pour chaque ressource 15 de traitement disponible.
10. 10 - Système (10) selon l'une des revendications 7 à 9, dans lequel les ressources de traitement comportent au moins un objet (42) adapté à générer des données à traiter et/ou au moins un actionneur.