FR3043480A1 - METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY - Google Patents
METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY Download PDFInfo
- Publication number
- FR3043480A1 FR3043480A1 FR1560717A FR1560717A FR3043480A1 FR 3043480 A1 FR3043480 A1 FR 3043480A1 FR 1560717 A FR1560717 A FR 1560717A FR 1560717 A FR1560717 A FR 1560717A FR 3043480 A1 FR3043480 A1 FR 3043480A1
- Authority
- FR
- France
- Prior art keywords
- equipment
- resources
- remote execution
- cluster
- computer
- 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 36
- 238000012937 correction Methods 0.000 title description 2
- 238000013468 resource allocation Methods 0.000 title description 2
- 238000012545 processing Methods 0.000 claims abstract description 68
- 238000012986 modification Methods 0.000 claims abstract description 15
- 230000004048 modification Effects 0.000 claims abstract description 15
- 238000012795 verification Methods 0.000 claims abstract description 5
- 230000008569 process Effects 0.000 claims description 8
- 238000004891 communication Methods 0.000 claims description 4
- 230000001186 cumulative effect Effects 0.000 claims description 3
- 238000007726 management method Methods 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 7
- 238000013459 approach Methods 0.000 description 6
- 230000015572 biosynthetic process Effects 0.000 description 6
- 238000005265 energy consumption Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000010267 cellular communication Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 101710190597 Uroporphyrinogen decarboxylase 1, chloroplastic Proteins 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000032258 transport Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
Abstract
L'invention porte notamment sur un procédé de regroupement d'équipements (4-10) d'un nuage informatique, comprenant les étapes suivantes : traitement indépendant de chaque requête d'une pluralité de requêtes d'exécution déportée d'une tâche informatique pour former des grappes d'équipements (N1, N2, N3) regroupant chacune des équipements du nuage informatique qui offrent des ressources pour le traitement distribué entre les équipements de la grappe d'une tâche informatique faisant l'objet d'une requête d'exécution déportée ; - vérification de faisabilité de l'exécution déportée de chacune des tâches informatiques par les grappes d'équipements formées à l'issue dudit traitement indépendant ; - modification des ressources offertes pour le traitement de tâches informatiques d'exécution déportée non faisable, - suite à ladite modification des ressources, réitération de l'étape de traitement indépendant pour les requêtes d'exécution déportée correspondant aux tâches informatique d'exécution déportée non faisable.The invention relates in particular to a method of grouping equipment (4-10) of a computer cloud, comprising the following steps: independent processing of each request of a plurality of remote execution requests of a computer task for forming clusters of equipment (N1, N2, N3) grouping each of the computing cloud equipment that provides resources for the distributed processing between the cluster equipment of a computing task that is the subject of an execution request deported; verification of the feasibility of the remote execution of each of the IT tasks by the clusters of equipment formed at the end of said independent processing; - modification of the resources offered for the processing of non-feasible remote execution computer tasks, - following said modification of the resources, reiteration of the independent processing step for the remote execution requests corresponding to the remote execution computer tasks not feasible.
Description
PROCÉDÉ ET SYSTÈME POUR LA CONSTITUTION DE GRAPPES D'ÉQUIPEMENTS D'UN NUAGE INFORMATIQUE AVEC ALLOCATION DE RESSOURCES DISTRIBUÉE ET CORRECTION DE FAISABILITÉ CENTRALISÉE
DESCRIPTION
DOMAINE TECHNIQUE
Le domaine de l'invention est celui du traitement déporté de tâches informatiques par lequel certaines tâches sont déportées d'un appareil électronique à un nuage informatique où elles sont exécutées de manière distribuée par différents équipements du nuage. L'invention concerne plus particulièrement le partage des ressources informatiques du nuage entre différents appareils sollicitant une exécution déportée d'une tâche informatique par le nuage.
ÉTAT DE LA TECHNIQUE ANTÉRIEURE
Les équipements sans fil, tels que par exemple des équipements mobiles d'usager ou encore des capteurs sans fil, sont de plus en plus capables d'exécuter des applications logicielles complexes qui nécessitent des capacités de traitement informatique importantes dont résultent notamment des besoins en termes de ressources mémoire et énergétiques.
Ces ressources sont toutefois limitées, et venir déporter l'exécution de certaines tâches informatiques de l'équipement sans fil vers un équipement tiers distant du système de communication radio cellulaire offre la possibilité d'étendre les capacités de l'équipement sans fil ainsi que la durée de vie de sa batterie.
Avec l'émergence d'équipements mobiles d'usager avancés de type « smartphone » et l'arrivée de nouvelles applications consommatrices de trafic de données, les opérateurs de réseaux de télécommunication cellulaire doivent faire face à une montée exponentielle du trafic de données. Ceci a pour conséquence une congestion de plus en plus accrue des cellules du réseau d'accès, et donc une dégradation de la qualité de service offerte aux usagers du réseau. Une évolution de ces réseaux visant à répondre à ce problème de congestion consiste à y introduire des points d'accès locaux de faible puissance offrant une couverture radio limitée, généralement dédiée pour un usage résidentiel ou en entreprise. Ainsi l'adjonction, aux côtés des stations de base classiques couvrant une macro-cellule de plus de 2 km de rayon, de points d'accès locaux de faible puissance couvrant une petite cellule telle qu'une micro-cellule (rayon inférieur à 2 km), une pico-cellule (dont la portée est inférieur à 200 m), ou une femto-cellule (portée de l'ordre de 10 à 50 m) permet de répondre à cette croissance du trafic.
Si de tels points d'accès locaux permettent d'amener des ressources radio à proximité des usagers, ils amènent également à proximité des usagers des ressources en termes de mémoire et de capacités de traitement qui peuvent être exploitées pour déporter une partie des tâches informatiques devant être exécutées par les équipements mobiles d'usager. De la même manière, une passerelle de collecte de données de capteurs sans fil dispose de ressources pouvant être exploitées par les capteurs.
Il est ainsi envisagé que de tels équipements puissent former un nuage informatique en venant mettre en commun leurs ressources informatiques (capacités de calcul et de stockage) et les rendre disponibles à distance pour permettre le traitement déporté d'une tâche informatique dont l'exécution est requise par un appareil électronique. Se pose alors le problème de déterminer combien d'équipements et lesquels doivent être associés pour réaliser ce traitement déporté, et comment planifier leur coopération.
Le regroupement d'équipements du nuage pour former une grappe d'équipements à même de réaliser le traitement d'une tâche informatique dont l'exécution déportée est sollicitée par un appareil électronique peut être réalisé de manière statique ou dynamique.
Dans un regroupement statique, une grappe d'équipements prédéfinie est associée à chaque appareil électronique. Cette stratégie n'est pas efficace notamment lorsque le nombre d'appareils électroniques ayant accès au nuage informatique augmente. Elle ne tient en outre pas compte des besoins en termes de ressources pour l'exécution déportée d'une tâche informatique.
Dans un regroupement dynamique, la configuration des grappes change au cours du temps. On connaît ainsi de Oueis, J.; Calvanese Strinati, E.; Barbarossa, S., "Small Cell Clustering for Efficient Distributed Cloud Computing," Personal Indoor and Mobile Radio Communications (PIMRC), 2014 IEEE 25th International Symposium on, 9-12 Sept. 2014, une technique de regroupement dynamique basée sur des critères de consommation d'énergie et de délai d'exécution qui permet de répondre à une qualité d'expérience attendue par l'usager de l'appareil électronique.
Cette technique ne permet de résoudre que le cas mono-utilisateur où un seul appareil électronique souhaite accéder aux ressources offertes par les équipements du nuage informatique. Or de multiples appareils électroniques peuvent solliciter l'exécution déportée d'une tâche informatique et ainsi concourir pour les ressources offertes par les équipements du nuage informatique.
Une solution répondant à ce cas multi-utilisateurs est présentée dans Oueis, J; Calvanese Strinati, E.; Sardelliti, S; Barbarossa, S., "Small Cell Clustering for Efficient Distributed Fog Computing: A Multi-user Case," IEEE 82nd Vehicular Technology Conférence, VTC 2015-Fall, 6-9 Sept. 2015. Cette solution propose de déterminer conjointement les grappes à former pour répondre aux requêtes d'exécution déportée émanant simultanément de plusieurs appareils électroniques. Cette détermination est réalisée en solutionnant un problème d'optimisation visant à minimiser la consommation énergétique tout en respectant les contraintes de délai d'exécution de chacune des requêtes.
On connaît par ailleurs de Oueis, J; Calvanese Strinati, E.; Barbarossa, S., "The Fog Balancing: Load Distribution for Small Cell Cloud Computing," IEEE 81st Vehicular Technology Conférence, VTC 2015-Spring, 11-14 May, 2015, une solution algorithmique qui permet également de répondre au cas multi-utilisateurs, mais de manière moins complexe en réalisant un ordonnancement des requêtes d'exécution déportée et en ne formant des grappes d'équipements que lorsqu'une requête ne peut être traitée directement par le point d'accès local de l'appareil ayant émis la requête.
Ces solutions aux cas multi-utilisateurs s'avèrent plus performantes qu'un regroupement statique. Elles nécessitent toutefois d'être implémentées de manière centralisée au niveau d'une entité de gestion. Or de telles solutions centralisées nécessitent que l'entité de gestion collecte les informations nécessaires. Elles présentent également des limitations, notamment en termes de délai et de complexité, en présence d'un nombre important d'appareils électroniques sollicitant une exécution déportée et d'équipements dans le nuage.
Une solution distribuée selon laquelle l'approche mono-utilisateur serait exploitée indépendamment pour chacune des requêtes d'exécution déportée n'est quant à elle pas en mesure de garantir une qualité d'expérience suffisante pour l'ensemble des utilisateurs.
EXPOSÉ DE L'INVENTION L'invention a pour objectif d'apporter une prise de décision pour la formation de grappes applicable au cas multi-utilisateurs qui soit rapide et peu complexe, tout en garantissant une qualité d'expérience suffisante à l'ensemble des utilisateurs. Pour ce faire, l'invention propose un procédé de regroupement d'équipements d'un nuage informatique, comprenant les étapes suivantes : traitement indépendant de chaque requête d'une pluralité de requêtes d'exécution déportée d'une tâche informatique pour former des grappes d'équipements regroupant chacune des équipements du nuage informatique qui offrent des ressources pour le traitement distribué entre les équipements de la grappe d'une tâche informatique faisant l'objet d'une requête d'exécution déportée ; vérification de faisabilité de l'exécution déportée de chacune des tâches informatiques par les grappes d'équipements formées à l'issue dudit traitement indépendant ; modification des ressources offertes pour le traitement de tâches informatiques d'exécution déportée non faisable, suite à ladite modification des ressources, réitération de l'étape de traitement indépendant pour les requêtes d'exécution déportée correspondant aux tâches informatique d'exécution déportée non faisable. L'invention propose ainsi une stratégie hybride avec à la fois une approche distribuée où chaque requête d'exécution déportée est traitée de manière indépendante des autres, ce qui apporte un gain de temps et de simplicité par rapport à un traitement centralisé des requêtes, et une approche centralisée où les contraintes du nuage sont prises en considération pour vérifier la faisabilité et éventuellement corriger l'allocation de ressources issue du traitement indépendant de chacune des requêtes, ce qui permet de garantir une qualité d'expérience pour l'ensemble des utilisateurs.
Certains aspects préférés mais non limitatifs de ce procédé sont les suivants : - la vérification de faisabilité comprend la vérification, pour chacune des grappes formées suite à une requête d'exécution déportée d'une tâche informatique, que l'offre de ressources de l'ensemble des équipements de la grappe est suffisante pour permettre l'exécution de la tache informatique ; - l'étape de modification des ressources consiste à ne plus offrir de ressources pour le traitement une tâche informatique d'exécution non faisable, et à permettre d'offrir les ressources qui ne sont plus offertes au traitement de ladite tâche informatique d'exécution non faisable au traitement d'au moins une autre tâche informatique d'exécution non faisable ; - la détermination de faisabilité comprend la vérification qu'un équipement du nuage est en excès lorsque le cumul de l'offre de ressources de l'équipement dans chacune des grappes d'équipements excède un seuil d'offre, l'exécution d'une tâche informatique n'étant pas faisable lorsque la grappe d'équipements correspondant à ladite tâche inclut un équipement en excès ; - l'étape de modification des ressources consiste à faire offrir, pour le traitement de la ou des tâches informatiques d'exécution déportée non faisable, les ressources en excès dudit seul d'offre par les équipements de la ou des grappes incluant ledit équipement en excès ; - chaque grappe comporte au moins un équipement destinataire d'au moins une requête d'exécution déportée émise par un appareil électronique ; - l'étape de traitement indépendant de chacune des requêtes d'exécution déportée est réalisée de manière décentralisée, chacun des équipements destinataires d'une requête d'exécution déportée traitant de manière indépendante l'au moins une requête d'exécution déportée émise par un appareil électronique pour former au moins une grappe d'équipement ; - la vérification de la faisabilité de l'exécution déportée des tâches informatiques est réalisée par une unité de gestion centrale. L'invention s'étend à un système apte à mettre en oeuvre le procédé.
BRÈVE DESCRIPTION DES DESSINS D'autres aspects, buts, avantages et caractéristiques de l'invention apparaîtront mieux à la lecture de la description détaillée suivante de formes de réalisation préférées de celle-ci, donnée à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels : - la figure 1 est un schéma illustrant les équipements d'un nuage participant à un système de traitement déporté de tâches informatiques conforme à l'invention ; - la figure 2 est un schéma illustrant l'approche hybride, distribuée puis centralisée, d'un procédé de constitution de grappes d'équipements conforme à l'invention ; - la figure 3 illustre les différentes opérations réalisées de manière distribuée dans le cadre du procédé de constitution de grappes d'équipements conforme à l'invention ; - la figure 4 illustre les différentes opérations réalisées de manière centralisée dans le cadre du procédé de constitution de grappes d'équipements conforme à l'invention ; - la figure 5 est un schéma comparant le taux de satisfaction d'utilisateur en fonction du nombre d'utilisateurs par cellule pour différentes stratégies d'exécution déportée de tâches informatiques.
EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS
En référence à la figure 1, l'invention porte sur un procédé de regroupement d'équipements 4-10 formant un nuage informatique en vue de former des grappes d'équipements NI, N2, N3 regroupant chacune des équipements 4, 6-8 ; 4, 6, 9 ; 5, 8 qui offrent chacun des ressources informatiques pour réaliser un traitement distribué entre les équipements de la grappe d'une tâche informatique dont l'exécution déportée est requise par un appareil électronique 1, 2, 3. L'appareil électronique 1, 2, 3 est typiquement un appareil sans fil, tel que par exemple un appareil mobile d'usager ou encore un capteur sans fil, relié à un réseau de communication cellulaire par l'intermédiaire d'un point d'accès local 4, 5, en particulier un point d'accès de faible puissance couvrant une petite cellule telle qu'une micro-cellule, une pico-cellule, ou une femto-cellule. Dans l'exemple de la figure 1, les appareils électroniques 1, 2 disposent du même point d'accès local 4.
Les équipements 4-10 pouvant être regroupés pour former les grappes NI, N2, N3 sont typiquement des points d'accès locaux au réseau de communication cellulaire. On retrouve dans chaque grappe un équipement source qui est chargé, dans un premier temps du procédé selon l'invention, de former la grappe et un ou plusieurs équipements cibles. Dans l'exemple de la figure 1, on retrouve une première grappe NI constituée de l'équipement source 4 et des équipements cibles 6-8 pour l'exécution déportée d'une tâche informatique d'un premier appareil 1, une deuxième grappe N2 constituée de l'équipement source 4 et des équipements cibles 6, 9 pour l'exécution déportée d'une tâche informatique d'un deuxième appareil 2, et une troisième grappe N3 constituée de l'équipement source 5 et de l'équipement cible 8 pour l'exécution déportée d'une tâche informatique d'un troisième appareil 3.
Un équipement source correspond typiquement à un point d'accès local 4, 5 auquel un appareil électronique 1, 2, 3 est connecté, sans pour autant que cela ne soit limitatif.
Les équipements cibles 6-10 peuvent être les points d'accès locaux directement dans la portée de l'équipement source, ou encore des points d'accès locaux pouvant être atteint par plusieurs sauts depuis l'équipement source. Et un équipement cible peut lui-même participer au procédé selon l'invention en agissant en tant qu'équipement source pour la constitution d'une grappe, par exemple une sous-grappe au sein d'une grappe formée par l'équipement source 2 servant de point d'accès local à l'appareil électronique.
Dans le cadre de l'invention, chaque grappe est formée dynamiquement et les équipements qui la forment, ainsi que la manière dont ils y coopèrent, sont amenés à changer au cours du temps. Le procédé selon l'invention peut notamment être mis en œuvre suite à une étape préalable de transmission par chaque appareil électronique 1, 2, 3 à destination de l'équipement source 4, 5 auquel il est associé d'une requête d'exécution déportée d'une tâche informatique. Cette requête peut prendre la forme d'une description de la tâche informatique, à savoir un ensemble d'instructions à exécuter avec une contrainte de latence donnée (par exemple pour un appareil k, Wk instructions à exécuter dans un temps maximal de Ak secondes).
La figure 2 illustre la stratégie hybride selon l'invention consistant à réaliser de manière distribuée des opérations D pour chacune des requêtes d'exécution déportée d'une tâche informatique afin de former une grappe d'équipements correspondante, et à réaliser de manière centralisée des opérations C pour vérifier la faisabilité et éventuellement corriger l'offre de ressources issue du traitement distribué de chacune des requêtes.
Reprenant l'exemple de la figure 1, les appareils 1, 2, 3 requièrent l'exécution déportée d'une tâche informatique auprès de l'équipement source 4, 5 auquel ils sont associés (équipement source 4 pour les appareils 1 et 2, équipement source 5 pour l'appareil 3). Au cours d'une première étape du procédé selon l'invention, chacune de ces requêtes d'exécution reportée est traitée de manière indépendante des autres requêtes par l'équipement source destinataire de la requête. Ainsi l'équipement source 4 traite la requête issue de l'appareil 1 indépendamment des requêtes concurrentes issues des appareils 2 et 3. De la même manière, l'équipement source 4 traite la requête issue de l'appareil 2 indépendamment des requêtes concurrentes issues des appareils 1 et 3, et l'équipement source 5 traite la requête issue de l'appareil 3 indépendamment des requêtes concurrentes issues des appareils 1 et 2. L'objectif du traitement distribué d'une requête est de former une grappe d'équipements regroupant des équipements du nuage qui offrent des ressources pour le traitement distribué entre les équipements de la grappe d'une tâche informatique faisant l'objet d'une requête d'exécution déportée. L'offre de ressources d'un équipement dans une grappe correspond typiquement à l'exécution d'un nombre donné d'instructions de la tâche, à un taux d'exécution (nombre d'instructions par seconde) donné. Toujours en référence à la figure 1, le résultat de ce traitement distribué est la formation de la première grappe NI pour l'exécution d'une tâche requise par l'appareil 1, de la deuxième grappe N2 pour l'exécution d'une tâche requise par l'appareil 2, et de la troisième grappe N3 pour l'exécution d'une tâche requise par l'appareil 3.
Le traitement indépendant de chacune des requêtes consiste à considérer un cas mono-utilisateur pour la formation de chacune des grappes, en négligeant l'existence de requêtes issues d'autres appareils qui concourent pourtant pour l'accès aux mêmes ressources informatiques offertes par le nuage. Ce traitement indépendant recherche une solution qui peut être qualifiée d'égoïste puisqu'elle ne prend en compte que les propres intérêts du mono-utilisateur (par exemple sa propre minimisation de délai, de consommation d'énergie, etc.) lors de la constitution de la grappe d'équipements à même d'exécuter la tâche informatique qui est déportée vers le nuage. Ainsi chaque équipement source détermine la grappe préférée pour chacune des requêtes d'exécution déportée qu'il reçoit, chaque requête étant considérée isolément sans prise en considération de l'existence de requêtes concurrentes.
La recherche d'une solution égoïste peut par exemple être mise en oeuvre comme rapporté dans les travaux déjà mentionnés précédemment de Oueis, J.; Calvanese Strinati, E.; Barba rossa, S., "Small Cell Clustering for Efficient Distributed Cloud Computing," Personal Indoor and Mobile Radio Communications (PIMRC), 2014 IEEE 25th International Symposium on, 9-12 Sept. 2014.
On considère dans ce qui suit un nuage informatique constitué par un ensemble N = {1, ...,N} d'équipements. Chaque équipement n£N dispose d'une capacité de calcul de Fn instructions/seconde.
On considère par ailleurs un ensemble K = {1, ...,K} d'appareils électroniques susceptibles de requérir l'exécution déportée de tâches informatiques dans le nuage. Chaque appareil k G K est associé à un équipement source. L'ensemble S = {1, ...,S} correspond à l'ensemble des équipements source avec S < K and S <= N . Le sous-ensemble KscK représente l'ensemble des appareils qui sont associés avec l'équipement source s.
Chaque appareil déporte l'exécution de tâches informatiques en envoyant des requêtes d'exécution déportée à l'équipement source auquel il est associé. Une requête d'exécution déportée est envoyée par un appareil k G K et consiste à requérir le calcul de Wk instructions dans un temps maximal de Ak secondes.
Lors de l'étape de traitement indépendant des requêtes d'exécution déportée, les équipements sources forment des grappes devant permettre le traitement de ces requêtes en choisissant les équipements à inclure dans la grappe et la manière de répartir la charge de calcul entre ces équipements. A l'issue de cette étape de traitement indépendant, chaque équipement n G N offre, pour la grappe formée pour le traitement d'une requête issue d'un appareil k, de prendre en charge le calcul de Wkn instructions à un tauxfkn.
Les équipements peuvent notamment communiquer entre eux par l'intermédiaire d'une liaison sans fil point à point, par exemple de type OFDMA. On considère que le nombre de bits devant être transmis est proportionnel à la taille du bloc d'instructions Wkn, soit wknQuL en liaison montante et WknQDL en liaison descendante, avec Qul et Qdl des constantes qui permettent de tenir compte respectivement de la surcharge due aux communications montantes et descendantes et du ratio entre le nombre de bits de sortie et d'entrée associés à l'exécution du bloc d'instruction par un équipement.
Le traitement indépendant, égoïste, de chacune des requêtes d'exécution déportée pour former une grappe d'équipements peut notamment viser à rechercher une solution minimisant la consommation d'énergie dans la grappe formée pour une requête issue d'un appareil k correspondant à Wk instructions dans un temps maximal de Ak secondes. La consommation d'énergie associée à un équipement n dans la grappe formée pour l'appareil k par l'équipement source s est notée p£n. Cette consommation correspond à l'exécution de Wkn instructions à un taux fkn. La durée nécessaire à cette exécution Δ^η vaut pour l'équipement source lorsque celui-ci participe au calcul, et fkn pour un équipement cible participant au calcul. Le problème d'optimisation peut s'exprimer comme suit :
Vw v» V»
Vn
La deuxième condition garantit que toutes les Wk instructions sont exécutées. La troisième condition garantit que la consommation d'énergie associée à chaque équipement de la grappe est inférieure à une valeur limite Pmax. La quatrième condition garantit que la capacité de calcul allouée par un équipement de la grappe reste inférieure à la capacité de calcul totale de l'équipement. Enfin la cinquième condition garantit que le délai de traitement associé à l'équipement n est inférieur à la contrainte de latence Ak imposée pour le traitement de la tâche informatique.
Le délai de traitement Δ*η associé à l'équipement n est plus précisément :
où Θ = 0UL + 0DL, et RsniPsn) est Ie débit qui peut être obtenu en utilisant une puissance de transmission ρ£η sur les liaisons montante et descendante entre l'équipement source s et l'équipement cible n.
Sur la figure 3 qui illustre les différentes opérations réalisées de manière distribuée dans le cadre du procédé selon l'invention, l'étape de traitement indépendant des requêtes d'exécution déportée pour former les différentes grappes porte la référence « DET-CLST ». Cette étape peut être précédée d'une étape préalable « INT » au cours de laquelle chaque équipement source met à jour sa connaissance des capacités de calcul des équipements cibles qui sont offertes au nuage informatique. Elle peut être succédée par une étape postérieure « REP-CLST » de notification à une entité de gestion centrale du résultat de l'étape de traitement indépendant de chacune des requêtes d'exécution déportée. Cette notification est réalisée par chacun des équipements source ayant participé au traitement d'au moins une requête d'exécution déportée pour former au moins une grappe d'équipement. Pour chaque requête k, cette notification fait état de la distribution de la charge (quels sont les équipements regroupés dans la grappe) et des ressources alloués par chacun des équipements de la grappe (VP^n,/fcn), le cas échéant accompagné de la métrique ayant servi à former la grappe (p^n dans l'exemple présenté ci-dessus).
Dans une variante de réalisation, le résultat de l'étape de traitement indépendant de chacune des requêtes d'exécution déportée peut être diffusé aux différents équipements sources pour les informer des intentions des appareils quant aux ressources locales des équipements sources qu'ils comptent (temporairement ou constamment) exploiter.
En référence à la figure 4, l'unité de gestion centrale est chargée, au cours d'une étape « FSB ? », de vérifier la faisabilité de l'exécution déportée de chacune des tâches informatiques par les grappes d'équipements formées à l'issue dudit traitement indépendant. Selon leur faisabilité, l'unité de gestion centrale vient départager les tâches informatiques entre tâches dont l'exécution déportée peut être réalisée par la grappe correspondante formée par le traitement indépendant égoïste (tâches faisables) et tâches dont l'exécution déportée ne peut être réalisée par la grappe correspondante formée par le traitement indépendant égoïste (tâches non faisables). L'analyse de faisabilité vise à vérifier si le système dans sa globalité peut satisfaire l'exécution des tâches par les grappes issues du traitement indépendant. Elle peut prendre en considération la pertinence des solutions égoïstes (par exemple si elles amènent à réduire la consommation énergétique). Cette analyse de faisabilité peut par ailleurs être biaisée, via la diffusion d'un paramètre de biais ou encore par les appareils électroniques eux-mêmes, par exemple sur la base d'une connaissance statistique des solutions égoïstes élaborées pour les requêtes d'exécution déportée précédentes issues d'un appareil. Les appareils électroniques peuvent par ailleurs appartenir (ou estimer appartenir, par exemple à un moment donné, à une localisation donnée, à un besoin donné) à différentes classes de services chacune associée à un niveau de priorité venant biaiser la vérification de faisabilité. Des exemples de vérification de faisabilité sont les suivants.
Il est tout d'abord possible que la recherche d'une solution égoïste pour la formation d'une grappe associée à une requête d'exécution déportée ne conduise pas à une solution viable (type d'infaisabilité noté FL1 sur la figure 4), notamment en ce que l'offre de ressources de l'ensemble des équipements de la grappe est insuffisante pour permettre l'exécution de la tâche informatique. L'exécution déportée n'est alors pas faisable. Dans un mode de réalisation possible, ce type d'infaisabilité est directement notifiée à l'unité de gestion centrale par l'équipement source en charge de former la grappe.
Un autre type d'infaisabilité (noté FL2 sur la figure 4) est une infaisabilité résultant de l'union des différents grappes formées de manière indépendante. En particulier, un équipement, dit équipement en excès d'offre, peut se retrouver inclus dans différentes grappes, et le cumul de l'offre de ressources de cet équipement dans chacune des grappes d'équipements excède un seuil d'offre. Typiquement, un équipement peut offrir d'exécuter dans l'ensemble des différentes grappes un nombre d'instructions supérieur à un nombre d'instructions qu'il peut (ou qu'il est habilité à) exécuter. Il en découle que l'exécution déportée des tâches informatiques comptant cet équipement en excès d'offre dans leurs grappes d'équipements n'est pas faisable.
Pour chacune des tâches dont l'exécution est déterminée par l'unité de gestion centrale comme étant faisable par la grappe correspondante formée par le traitement indépendant égoïste, les ressources offertes par les différents équipements de la grappe sont alors effectivement allouées au traitement distribué de la tâche.
Pour les autres tâches, à savoir celles dont l'exécution est déterminée comme n'étant pas faisable, on procède à une modification des ressources offertes pour le traitement de ces tâches, et on réitère, sur la base de cette offre de ressources modifiée, l'étape de traitement indépendant de chacune des requêtes d'exécution déportée correspondant à l'une de ces tâches non faisables. La modification des ressources offertes aux tâches non faisables tient compte des ressources effectivement allouées aux tâches d'exécution déportée faisable et qui ne peuvent dont plus être offertes pour les tâches d'exécution déportée non infaisable.
La modification des ressources peut également prendre en compte des valeurs correctives de l'offre de ressources déterminées de manière à tenter de résoudre l'infaisabilité d'exécution de certaines tâches. En référence à la figure 4, la modification des ressources peut ainsi tenter de résoudre le type d'infaisabilité FL1 (tâche infaisable du fait d'une offre de ressources insuffisante par les équipements de la grappe), et/ou le type d'infaisabilité FL2 (équipement en excès d'offre affectant l'ensemble des tâches associées à une grappe dans laquelle on retrouve l'équipement en excès).
Dans un mode de réalisation possible, une modification des ressources visant à résoudre le type d'infaisabilité FL1 consiste à modifier une répartition au sein des équipements entre ressources dédiées à l'exécution d'instructions déportées depuis les appareils ayant l'équipement comme équipement source, et ressources pouvant être offertes dans une grappe où l'équipement forme un équipement cible. Notamment, les ressources dédiées aux appareils ayant l'équipement comme équipement source peuvent être temporairement augmentées afin d'éviter qu'une requête d'exécution déportée issue de l'un de ces appareils soit déterminée comme présentant une infaisabilité de type FL1.
Dans un autre mode de réalisation possible, une modification des ressources visant à résoudre le type d'infaisabilité FL1 consiste à ne plus offrir de ressources pour le traitement de l'une des tâches informatiques présentant une infaisabilité de type FL1, et à permettre d'offrir les ressources qui ne sont plus offertes à ladite tâche informatique au traitement d'au moins une autre tâche informatique présentant une infaisabilité de type FL1.
En d'autres termes, on procède à une élimination « ELIM » de la requête d'exécution déportée de la tâche à qui on n'offre plus de ressources, et on met à jour « UPD1 » les capacités de calcul des différents équipements pour tenir compte de la libération de ressources préalablement offertes à la requête éliminée.
Ainsi, la modification des ressources offertes par les équipements conduit à une mise à jour de la capacité de calcul F'n disponible au niveau de chacun des équipements et à une mise à jour de la charge W'n de chacun des équipements selon
, Vn, où j est l'index de la requête éliminée et
L'offre de ressources ainsi modifiée W'n, F'n est communiquée au cours d'une étape « REP-UDP » aux équipements source associés aux requêtes d'exécution déterminés comme non faisables. Ces requêtes font alors de nouveau chacune l'objet d'un traitement indépendant égoïste sur la base de l'offre de ressources modifiée.
Dans le cadre de ce mode de réalisation, la tâche informatique à qui la modification des ressources n'offre plus de ressources (sa requête d'exécution déportée est supprimée) peut être celle des tâches informatiques présentant une infaisabilité de type FL1 qui requiert une rapidité d'exécution — la plus élevée.
La requête à éliminer peut toutefois être sélectionnée de manière différente, par exemple via une sélection aléatoire, ou encore en utilisant une métrique alternative à la rapidité d'exécution, par exemple une métrique de type proportionnelle équitable ou une métrique de type échéance proche consistant à ne pas supprimer les requêtes présentant les contraintes temporelles les plus élevées.
Dans un mode de réalisation possible, une modification des ressources pouvant être offertes visant à résoudre le type d'infaisabilité FL2 où un équipement est en excès d'offre consiste à faire offrir, pour le traitement de la ou des tâches informatiques d'exécution déportée non faisable, les ressources en excès dudit seuil d'offre par les équipements de la ou des grappes incluant ledit équipement en excès.
Avant modification des ressources, la charge de calcul au niveau de chaque équipement s'exprime selon Wn = Σ/Li wnfc. Le seuil d'offre d'un équipement est noté Thn. Un équipement est en excès lorsque Wn > Thn ce qui est déterminé au cours d'une étape « CAL-EXC » représentée sur la figure 4. On note Xn les ressources offertes en excès, soit Xn=Wn — Thn. Dans le cadre de ce mode de réalisation, on cherche à ce que cette charge de calcul en excès soit offerte par d'autres équipements, et plus particulièrement par les équipements de la ou des grappes incluant ledit équipement en excès.
On vient ensuite mettre à jour au cours d'une étape « UDP2 » la capacité de calcul disponible au niveau de chaque équipement, selon
Puis on procède à la redistribution des ressources en excès au cours d'une étape « DISTR ». Dans ce qui suit, bptnk correspond au temps de traitement minimal d'un bit (transmission et calcul) qu'un équipement peut offrir à une requête d'index k :
OU Rmax est le débit maximal pouvant être atteint.
La redistribution des ressources offertes en excès par un équipement d'index b (Xb>0) peut suivre les règles suivantes pour déterminer les charges de calcul w'nk pouvant être offertes après modification des ressources en cherchant à optimiser le temps de traitement des différentes tâches informatiques.
La première condition ci-dessus garantit que la redistribution de la charge en excès n'excède pas la charge offerte par l'équipement en excès. La deuxième condition garantit que la redistribution de la charge vise à assurer le traitement des requêtes associées à une grappe incluant l'équipement en excès. La troisième condition garantit que
la redistribution de la charge n'est pas réalisée vers des équipements ne disposant plus de capacités de calcul. Enfin, la dernière condition garantit que toute la charge en excès est bien redistribuée.
La redistribution des ressources n'est pas limitée à cet exemple, et s'étend par exemple au cas où la redistribution tient compte d'un niveau de priorité (associé à un appareil ou un équipement source) pour qu'un équipement, sur lequel la charge en excès est distribuée, offre plus ou moins de de capacité de calcul. L'offre de ressources ainsi modifiée W'n, F'n est communiquée au cours d'une étape « REP-UDP » aux équipements source associés aux requêtes d'exécution déterminés comme non faisables car étant associées à des grappes qui incluent l'équipement en excès. Ces requêtes font alors de nouveau chacune l'objet d'un traitement indépendant égoïste sur la base de l'offre de ressources modifiée.
Suite au traitement indépendant égoïste des requêtes non faisables sur la base de l'offre de ressources modifiée, leur faisabilité est de nouveau évaluée pour allouer l'offre de ressources du traitement indépendant aux requêtes désormais faisables et procéder à un nouveau traitement indépendant des requêtes toujours non faisables prenant en considération des valeurs correctives de l'offre de ressources pour ces requêtes, etc.
Cet algorithme itératif se poursuit jusqu'à ce que les requêtes soient toutes faisables ou toutes éliminées, ou encore jusqu'à ce qu'un critère d'arrêt soit vérifié (par exemple un nombre maximal d'itérations, un délai maximal pour la formation des grappes, un nombre maximal d'instructions calculées, ou encore lorsque le gain de performance entre des itérations successives reste inférieur à un seuil).
La figure 5 est un schéma comparant le taux de satisfaction d'utilisateur QoE en fonction du nombre d'utilisateurs N par cellule pour différentes stratégies d'exécution déportée de tâches informatiques. Sur cette figure, la courbe A correspond à une implémentation avec résolution totalement centralisée d'un problème d'optimisation multi-utilisateur, la courbe B correspond à une implémentation totalement distribuée de l'approche mono-utilisateur, la courbe C correspond au traitement déporté de tâches informatiques par les équipements sources, sans formation de grappes pour associer des équipements cibles aux équipements source, et la courbe D correspond à une implémentation de l'invention. L'invention offre un gain de 20-30% du taux de satisfaction utilisateur par rapport à une implémentation sans formation de grappes (courbe C). L'invention s'accompagne d'une perte de 15-20% du taux de satisfaction utilisateur par rapport à l'implémentation l'approche multi-utilisateur centralisée (courbe A), au bénéfice de la simplicité et d'un gain de temps dans la formation des grappes. L'invention n'est pas limitée au procédé tel que précédemment décrit, mais s'étend à un système de traitement déporté d'une tâche informatique dans un nuage informatique configuré pour mettre en œuvre ce procédé, et en particulier à un système comprenant au moins un équipement destinataire configuré pour traiter de manière indépendante au moins une requête d'exécution déportée émise par un appareil électronique pour former au moins une grappe d'équipements regroupant des équipements du nuage informatique qui offrent des ressources pour le traitement distribué de la tâche informatique faisant l'objet de la requête d'exécution déportée, et une unité de gestion centrale configurée pour vérifier la faisabilité de l'exécution déportée d'au moins une tâche informatique par l'au moins une grappe d'équipement formée par l'au moins un équipement destinataire.
METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY
DESCRIPTION
TECHNICAL AREA
The field of the invention is that of the remote processing of computer tasks by which certain tasks are deported from an electronic device to a computer cloud where they are executed in a distributed manner by different devices of the cloud. The invention more particularly relates to the sharing of computing resources of the cloud between different devices requesting remote execution of a computer task by the cloud.
STATE OF THE PRIOR ART
Wireless equipment, such as for example mobile user equipment or wireless sensors, is increasingly capable of running complex software applications that require significant computing capabilities, including the need for memory and energy resources.
These resources are limited, however, and deporting the execution of certain computer tasks from the wireless equipment to a remote third party equipment of the cellular radio communication system offers the possibility of extending the capabilities of the wireless equipment as well as the lifetime of its battery.
With the emergence of advanced smartphone-based mobile user devices and the advent of new applications that consume data traffic, cellular telecommunication network operators are facing an exponential rise in data traffic. This results in an increasingly increased congestion of the cells of the access network, and therefore a degradation of the quality of service offered to network users. An evolution of these networks to address this congestion problem is to introduce low-power local access points with limited radio coverage, usually dedicated for residential or corporate use. Thus adding, alongside conventional base stations covering a macro-cell of more than 2 km radius, low-power local access points covering a small cell such as a micro-cell (radius less than 2 km), a pico-cell (whose range is less than 200 m), or a femto-cell (range of about 10 to 50 m) can respond to this growth in traffic.
If such local access points bring radio resources close to the users, they also bring resources to the users in terms of memory and processing capabilities that can be exploited to deport part of the computer tasks in front of the users. be performed by mobile user equipment. In the same way, a wireless sensor data collection gateway has resources that can be exploited by the sensors.
It is thus envisaged that such equipment could form a computing cloud by pooling their computing resources (computation and storage capacities) and make them available remotely to enable the remote processing of a computer task whose execution is required by an electronic device. This raises the problem of determining how much equipment and which equipment should be associated to carry out this remote treatment, and how to plan their cooperation.
The grouping of cloud equipment to form a cluster of equipment capable of performing the processing of a computer task whose remote execution is requested by an electronic device can be performed statically or dynamically.
In a static grouping, a predefined equipment cluster is associated with each electronic device. This strategy is not effective especially when the number of electronic devices having access to the cloud increases. It also does not take into account the resource requirements for remote execution of an IT task.
In a dynamic grouping, cluster configuration changes over time. De Oueis, J .; Calvanese Strinati, E .; Barbarossa, S., "Small Cell Clustering for Efficient Distributed Cloud Computing," Personal Indoor and Mobile Radio Communications (PIMRC), 2014 IEEE 25th International Symposium on, 9-12 Sept. 2014, a dynamic grouping technique based on energy consumption and turnaround time which makes it possible to respond to a quality of experience expected by the user of the electronic device.
This technique only solves the single-user case where only one electronic device wishes to access the resources offered by the cloud computing equipment. However, multiple electronic devices may request the remote execution of a computer task and compete for the resources offered by the cloud computing equipment.
A solution responding to this multi-user case is presented in Oueis, J; Calvanese Strinati, E .; Sardelliti, S; Barbarossa, S., "Small Cell Clustering for Efficient Distributed Computing Fog: A Multi-user Case," IEEE 82nd Vehicular Technology Conference, VTC 2015-Fall, 6-9 Sept. 2015. This solution proposes to jointly determine which clusters to train to respond to remote execution requests from multiple electronic devices simultaneously. This determination is made by solving an optimization problem designed to minimize energy consumption while respecting the time constraints of each request.
Oueis, J; Calvanese Strinati, E .; Barbarossa, S., "The Fog Balancing: Load Distribution for Small Cell Cloud Computing," IEEE 81st Vehicular Technology Conference, VTC 2015-Spring, 11-14 May, 2015, an algorithmic solution that also addresses the multi-user case , but in a less complex way by performing a schedule of remote execution requests and by forming clusters of devices only when a request can not be processed directly by the local access point of the device that issued the request .
These solutions to multi-user cases are more efficient than a static grouping. However, they need to be implemented centrally at the level of a management entity. Such centralized solutions require the management entity to collect the necessary information. They also have limitations, especially in terms of time and complexity, in the presence of a large number of electronic devices requesting remote execution and equipment in the cloud.
A distributed solution according to which the single-user approach would be exploited independently for each of the remote execution requests is not able to guarantee a sufficient quality of experience for all the users.
DISCLOSURE OF THE INVENTION The object of the invention is to provide decision-making for the formation of clusters applicable to the multi-user case which is rapid and not very complex, while guaranteeing a sufficient quality of experience for all the users. users. To do this, the invention proposes a method of grouping equipment of a computing cloud, comprising the following steps: independent processing of each request of a plurality of remote execution requests of a computer task to form clusters equipment combining each of the computing cloud equipment that provides resources for the distributed processing between the equipment of the cluster of a computer task that is the subject of a remote execution request; verification of the feasibility of the remote execution of each of the computer tasks by the clusters of equipment formed at the end of said independent processing; modification of the resources offered for the processing of non-feasible remote execution computer tasks, following said modification of the resources, reiteration of the independent processing step for the remote execution requests corresponding to the non-feasible remote execution computer tasks. The invention thus proposes a hybrid strategy with both a distributed approach where each remote execution request is processed independently of the others, which saves time and simplicity compared to a centralized processing of requests, and a centralized approach where the constraints of the cloud are taken into consideration to verify the feasibility and possibly correct the allocation of resources resulting from the independent processing of each request, which guarantees a quality of experience for all users.
Some preferred but nonlimiting aspects of this method are the following: the feasibility check includes verifying, for each of the clusters formed following a request for remote execution of a computer task, that the resource offer of the all the equipment in the cluster is sufficient to enable the computer task to be performed; the step of modifying the resources consists in no longer offering resources for the processing of a computer task of non-feasible execution, and in making it possible to offer the resources that are no longer available to the processing of said non-performing computer task; feasible to process at least one other non-feasible execution computer task; - the feasibility determination includes verifying that an equipment in the cloud is in excess when the cumulative supply of equipment resources in each of the equipment clusters exceeds a supply threshold, the execution of a computer task not being feasible when the equipment cluster corresponding to said task includes excess equipment; the step of modifying the resources consists in having the resources in excess of said one offer offered by the equipment of the at least one cluster including said equipment in question, provided for the processing of the non-feasible remote execution computer task or tasks; excess; - Each cluster has at least one equipment recipient of at least one remote execution request issued by an electronic device; the independent processing step of each of the remote execution requests is carried out in a decentralized manner, each of the equipment receiving a remote execution request processing independently the at least one remote execution request issued by a remote execution request; electronic apparatus for forming at least one cluster of equipment; - the verification of the feasibility of the remote execution of IT tasks is carried out by a central management unit. The invention extends to a system capable of implementing the method.
BRIEF DESCRIPTION OF THE DRAWINGS Other aspects, objects, advantages and characteristics of the invention will appear better on reading the following detailed description of preferred embodiments thereof, given by way of non-limiting example, and made in reference to the accompanying drawings in which: - Figure 1 is a diagram illustrating the equipment of a cloud participating in a remote processing system of computer tasks according to the invention; FIG. 2 is a diagram illustrating the hybrid approach, distributed and then centralized, of a method of constituting clusters of equipment according to the invention; FIG. 3 illustrates the various operations performed in a distributed manner as part of the method of constituting clusters of equipment according to the invention; FIG. 4 illustrates the various operations performed centrally in the context of the method of constituting clusters of equipment according to the invention; FIG. 5 is a diagram comparing the user satisfaction rate as a function of the number of users per cell for different remote execution strategies of IT tasks.
DETAILED PRESENTATION OF PARTICULAR EMBODIMENTS
Referring to Figure 1, the invention relates to a method of grouping equipment 4-10 forming a computer cloud to form clusters of equipment NI, N2, N3 each comprising equipment 4, 6-8; 4, 6, 9; 5, 8 which each provide computing resources for performing distributed processing between the cluster equipment of a computing task whose remote execution is required by an electronic apparatus 1, 2, 3. The electronic apparatus 1, 2, 3 is typically a wireless device, such as for example a mobile user device or a wireless sensor, connected to a cellular communication network via a local access point 4, 5, in particular a low power access point covering a small cell such as a micro-cell, a pico-cell, or a femto-cell. In the example of FIG. 1, the electronic devices 1, 2 have the same local access point 4.
Devices 4-10 that can be grouped together to form the NI, N2, N3 clusters are typically local access points to the cellular communication network. In each cluster, there is a source equipment that is initially loaded with the method according to the invention to form the cluster and one or more target devices. In the example of FIG. 1, there is a first NI cluster consisting of the source equipment 4 and the target devices 6-8 for the remote execution of a computer task of a first device 1, a second cluster N2. consisting of the source equipment 4 and the target equipment 6, 9 for the remote execution of a computer task of a second apparatus 2, and a third cluster N3 consisting of the source equipment 5 and the target equipment 8 for the remote execution of a computer task of a third apparatus 3.
A source equipment typically corresponds to a local access point 4, 5 to which an electronic device 1, 2, 3 is connected, without however being limiting.
The target devices 6-10 may be the local access points directly within the range of the source equipment, or the local access points that can be reached by several jumps from the source equipment. And a target equipment can itself participate in the method according to the invention by acting as a source equipment for the constitution of a cluster, for example a sub-cluster within a cluster formed by the source equipment 2 serving as a local access point to the electronic device.
In the context of the invention, each cluster is dynamically formed and the equipment that forms it, as well as the way in which they cooperate, are caused to change over time. The method according to the invention can in particular be implemented following a preliminary step of transmission by each electronic device 1, 2, 3 to the source equipment 4, 5 with which it is associated with a remote execution request. of an IT task. This request can take the form of a description of the computer task, namely a set of instructions to execute with a given latency constraint (for example for a device k, Wk instructions to be executed in a maximum time of Ak seconds) .
FIG. 2 illustrates the hybrid strategy according to the invention of distributing D operations for each of the remote execution requests of a computer task in a distributed manner in order to form a corresponding equipment cluster, and to perform centrally C operations to verify the feasibility and possibly correct the supply of resources from the distributed processing of each request.
Taking the example of FIG. 1, the devices 1, 2, 3 require the remote execution of a computer task with the source equipment 4, 5 with which they are associated (source equipment 4 for the devices 1 and 2, source equipment 5 for the device 3). During a first step of the method according to the invention, each of these executed execution requests is processed independently of the other requests by the source equipment recipient of the request. Thus the source equipment 4 processes the request from the device 1 independently of the concurrent requests from the devices 2 and 3. In the same way, the source equipment 4 processes the request from the device 2 independently of the competing requests from devices 1 and 3, and the source equipment 5 processes the request from the device 3 independently of the competing requests from the devices 1 and 2. The purpose of the distributed processing of a request is to form a cluster of equipment grouping cloud devices that provide resources for distributed processing between cluster devices of a computing task that is the subject of a remote execution request. The resource offer of a device in a cluster typically corresponds to the execution of a given number of instructions of the task, at a given execution rate (number of instructions per second). Still with reference to FIG. 1, the result of this distributed processing is the formation of the first NI cluster for the execution of a task required by the apparatus 1, of the second cluster N2 for the execution of a task required by the apparatus 2, and the third cluster N3 for the execution of a task required by the apparatus 3.
The independent treatment of each of the requests consists in considering a single-user case for the formation of each cluster, neglecting the existence of queries from other devices that nevertheless concur for access to the same computing resources offered by the cloud. . This independent treatment seeks a solution that can be described as selfish since it only takes into account the interests of the single-user (eg his own minimization of delay, energy consumption, etc.) during the constitution. the cluster of equipment capable of performing the computer task that is deported to the cloud. Thus each source equipment determines the preferred cluster for each remote execution request it receives, each request being considered in isolation without taking into consideration the existence of concurrent requests.
The search for a selfish solution can for example be implemented as reported in the works already mentioned previously by Oueis, J .; Calvanese Strinati, E .; Barba Rossa, S., "Small Cell Clustering for Efficient Distributed Cloud Computing," Personal Indoor and Mobile Radio Communications (PIMRC), 2014 IEEE 25th International Symposium on, 9-12 Sept. 2014.
In the following, we consider a computer cloud consisting of a set N = {1, ..., N} of equipment. Each equipment has a capacity of calculating Fn instructions / second.
We also consider a set K = {1, ..., K} of electronic devices that may require the remote execution of computer tasks in the cloud. Each device k GK is associated with a source equipment. The set S = {1, ..., S} corresponds to all the source equipment with S <K and S <= N. The subset KscK represents all the devices that are associated with the source equipment s.
Each device transports the execution of computer tasks by sending remote execution requests to the source equipment with which it is associated. A remote execution request is sent by a device k GK and consists in requiring the calculation of Wk instructions in a maximum time of Ak seconds.
In the step of independent processing of the remote execution requests, the source equipment forms clusters to allow the processing of these requests by choosing the equipment to be included in the cluster and how to distribute the computing load between these devices. At the end of this independent processing step, each equipment n GN offers, for the cluster formed for processing a request from a device k, to support the computation of Wkn instructions at a rate fkn.
The equipment may in particular communicate with each other via a wireless point-to-point link, for example of the OFDMA type. It is considered that the number of bits to be transmitted is proportional to the size of the instruction block Wkn, wknQuL uplink and WknQDL downlink, with Qul and Qdl constants that allow to take into account respectively the overload due to uplink and downlink communications and the ratio between the number of output and input bits associated with the execution of the instruction block by a device.
The independent, selfish treatment of each of the remote execution requests to form a cluster of equipment may in particular aim to find a solution that minimizes the energy consumption in the cluster formed for a request from a device k corresponding to Wk. instructions in a maximum time of Ak seconds. The energy consumption associated with equipment n in the cluster formed for the apparatus k by the source equipment was noted p n. This consumption corresponds to the execution of Wkn instructions at a rate fkn. The time required for this execution Δ ^ η is for the source equipment when it participates in the calculation, and fkn for a target equipment participating in the calculation. The optimization problem can be expressed as follows:
Vw v »V»
Vn
The second condition ensures that all Wk statements are executed. The third condition ensures that the energy consumption associated with each equipment in the cluster is less than a limit value Pmax. The fourth condition ensures that the computing capacity allocated by a device in the cluster remains less than the total computing capacity of the equipment. Finally, the fifth condition ensures that the processing time associated with the equipment is less than the latency constraint Ak imposed for the processing of the computing task.
The processing time Δ * η associated with the equipment is more precisely:
where Θ = 0UL + 0DL, and RsniPsn) is the rate that can be obtained by using transmission power ρ £ η on the uplink and downlink between the source equipment s and the target equipment n.
In FIG. 3, which illustrates the various operations performed in a distributed manner in the context of the method according to the invention, the step of independent processing of the remote execution requests to form the various clusters bears the reference "DET-CLST". This step may be preceded by a prior step "INT" during which each source equipment updates its knowledge of the computing capabilities of the target equipment that are offered to the cloud. It can be replaced by a later step "REP-CLST" of notification to a central management entity of the result of the independent processing step of each remote execution request. This notification is performed by each of the source devices that participated in the processing of at least one remote execution request to form at least one equipment cluster. For each request k, this notification reports on the distribution of the load (which are the equipment grouped in the cluster) and the resources allocated by each of the equipment of the cluster (VP ^ n, / fcn), where appropriate accompanied by the metric used to form the cluster (p in the example presented above).
In an alternative embodiment, the result of the independent processing step of each of the remote execution requests can be broadcast to the different source equipment to inform them of the intentions of the devices as to the local resources of the source equipment that they rely on (temporarily or constantly) exploit.
With reference to FIG. 4, the central management unit is loaded during a step "FSB? », To verify the feasibility of the remote execution of each of the IT tasks by the clusters of equipments formed at the end of the said independent processing. According to their feasibility, the central management unit separates the computer tasks between tasks whose remote execution can be carried out by the corresponding cluster formed by selfish independent processing (feasible tasks) and tasks whose remote execution can not be realized. by the corresponding cluster formed by selfish independent treatment (tasks not feasible). The feasibility analysis aims to verify whether the system as a whole can satisfy the performance of tasks by clusters resulting from independent processing. It can take into consideration the relevance of selfish solutions (for example if they lead to reducing energy consumption). This feasibility analysis can also be biased, via the diffusion of a bias parameter or even by the electronic devices themselves, for example on the basis of a statistical knowledge of selfish solutions developed for remote execution requests. from a device. Electronic devices can also belong (or consider belonging, for example at a given time, to a given location, to a given need) to different classes of services each associated with a priority level biasing the feasibility check. Examples of feasibility checks are as follows.
It is first possible that the search for a selfish solution for the formation of a cluster associated with a remote execution request does not lead to a viable solution (type of infeasibility noted FL1 in FIG. 4), in particular in that the supply of resources of all the equipment of the cluster is insufficient to allow the execution of the computer task. Remote execution is not feasible. In one possible embodiment, this type of infeasibility is directly notified to the central management unit by the source equipment in charge of forming the cluster.
Another type of infeasibility (denoted FL2 in FIG. 4) is an infeasibility resulting from the union of the various clusters formed independently. In particular, equipment, said excess supply equipment, may be included in different clusters, and the cumulative supply of resources of this equipment in each of the clusters of equipment exceeds an offer threshold. Typically, an equipment can offer to execute in the set of different clusters a number of instructions greater than a number of instructions that it can (or is authorized to) perform. It follows that the remote execution of computer tasks with this equipment in excess of supply in their equipment clusters is not feasible.
For each of the tasks whose execution is determined by the central management unit as being feasible by the corresponding cluster formed by selfish independent processing, the resources offered by the different equipment of the cluster are then effectively allocated to the distributed processing of the task.
For the other tasks, namely those whose execution is determined to be not feasible, the resources available for the processing of these tasks are modified, and it is reiterated, on the basis of this modified supply of resources, the independent processing step of each of the remote execution requests corresponding to one of these non-feasible tasks. Modifying the resources available for non-feasible tasks takes into account the resources actually allocated to feasible remote execution tasks that can no longer be offered for non-infeasible remote execution tasks.
The resource modification can also take into account corrective values of the supply of determined resources so as to try to solve the infeasibility of performing certain tasks. With reference to FIG. 4, the modification of the resources can thus attempt to resolve the type of infeasibility FL1 (task that is unfeasible due to an insufficient supply of resources by the equipment of the cluster), and / or the type of infeasibility FL2 (over-supply equipment affecting all the tasks associated with a cluster in which the equipment in excess is found).
In one possible embodiment, a modification of the resources to resolve the type of infeasibility FL1 consists of modifying a distribution within the equipment between resources dedicated to the execution of remote instructions from the devices having the equipment as source equipment. and resources that can be offered in a cluster where the equipment forms a target equipment. In particular, the resources dedicated to the devices having the equipment as source equipment can be temporarily increased in order to avoid that a remote execution request coming from one of these devices is determined as presenting an infeasibility of the FL1 type.
In another possible embodiment, a modification of the resources intended to resolve the type of infeasibility FL1 consists in no longer offering resources for the processing of one of the computer tasks having an infeasibility of type FL1, and to allow for provide the resources that are no longer available to said computer task to the processing of at least one other computer task with an infeasibility type FL1.
In other words, we carry out an "ELIM" elimination of the remote execution request of the task to which we no longer offer resources, and we update "UPD1" the calculation capacities of the different equipment for take into account the release of resources previously offered to the eliminated query.
Thus, the modification of the resources offered by the equipment leads to an update of the F'n calculation capacity available at the level of each of the equipment and to an update of the W'n load of each of the equipment according to
, Vn, where j is the index of the eliminated query and
The supply of resources thus modified W'n, F'n is communicated during a "REP-UDP" step to the source equipment associated with the execution requests determined as not feasible. These queries are each again subject to selfish self-treatment based on the modified resource offer.
In the context of this embodiment, the computer task to which the modification of the resources no longer offers resources (its remote execution request is deleted) can be that of the computer tasks having an infeasibility of type FL1 which requires a speed execution - the highest.
The request to be eliminated can however be selected differently, for example via a random selection, or by using an alternative metric to the speed of execution, for example a fair proportional type metric or a close deadline type metric consisting of Do not delete requests with the highest time constraints.
In one possible embodiment, a modification of the resources that can be offered to solve the type of infeasibility FL2 where a device is in excess of supply is to offer, for the processing of the computer tasks of remote execution not feasible, resources in excess of said supply threshold by the equipment of the cluster or clusters including said equipment in excess.
Before modifying the resources, the computing load at the level of each equipment is expressed according to Wn = Σ / Li wnfc. The supply threshold of equipment is noted Thn. An equipment is in excess when Wn> Thn which is determined during a step "CAL-EXC" represented in FIG. 4. Xn is denoted the resources offered in excess, ie Xn = Wn-Thn. In the context of this embodiment, it is sought that this excess computing load is provided by other equipment, and more particularly by the equipment of the cluster or clusters including said equipment in excess.
Then comes to update during a step "UDP2" the available computing capacity at the level of each equipment, according to
Then we redistribute the excess resources during a "DISTR" stage. In what follows, bptnk is the minimum processing time of a bit (transmission and calculation) that a device can offer to an index query k:
OR Rmax is the maximum flow that can be achieved.
The redistribution of the resources offered in excess by an index equipment b (Xb> 0) can follow the following rules to determine the w'nk computational loads that can be offered after modification of the resources by seeking to optimize the processing time of the different computer tasks.
The first condition above ensures that the redistribution of the excess load does not exceed the load provided by the excess equipment. The second condition ensures that the redistribution of the load is intended to ensure the processing of queries associated with a cluster including excess equipment. The third condition ensures that
the redistribution of the load is not carried out to equipments no longer having calculation capacities. Finally, the last condition ensures that all the excess load is well redistributed.
The redistribution of resources is not limited to this example, and extends for example in the case where the redistribution takes into account a priority level (associated with a source apparatus or equipment) for an equipment, on which the excess load is distributed, offers more or less computing capacity. The modified supply of resources W'n, F'n is communicated during a "REP-UDP" step to the source devices associated with the execution requests determined as not feasible because they are associated with clusters that include the excess equipment. These queries are each again subject to selfish self-treatment based on the modified resource offer.
As a result of the selfish self-treatment of non-feasible queries based on the modified resource offer, their feasibility is again evaluated to allocate the independent processing resource offer to the now feasible queries and proceed to a new independent query processing always not feasible taking into consideration corrective values of the supply of resources for these requests, etc.
This iterative algorithm continues until the queries are all feasible or all eliminated, or until a stop criterion is verified (for example a maximum number of iterations, a maximum delay for training clusters, a maximum number of calculated instructions, or when the performance gain between successive iterations remains below a threshold).
Figure 5 is a diagram comparing the QoE user satisfaction rate as a function of the number of users N per cell for different remote execution strategies of IT tasks. In this figure, curve A corresponds to a fully centralized implementation of a multi-user optimization problem, curve B corresponds to a fully distributed implementation of the single-user approach, curve C corresponds to remote processing. computer tasks by the source equipment, without forming clusters for associating target equipment with the source equipment, and the curve D corresponds to an implementation of the invention. The invention offers a gain of 20-30% in the user satisfaction rate compared to an implementation without cluster formation (curve C). The invention is accompanied by a loss of 15-20% of the user satisfaction rate compared to the implementation of the centralized multi-user approach (curve A), in favor of simplicity and time savings in the formation of clusters. The invention is not limited to the method as previously described, but extends to a remote processing system of a computer task in a computer cloud configured to implement this method, and in particular to a system comprising minus a destination equipment configured to independently process at least one remote execution request issued by an electronic device to form at least one cluster of equipment comprising computer cloud equipment that provides resources for the distributed processing of the computing task subject of the remote execution request, and a central management unit configured to verify the feasibility of the remote execution of at least one computer task by the at least one equipment cluster formed by the less a recipient equipment.
Claims (12)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1560717A FR3043480B1 (en) | 2015-11-09 | 2015-11-09 | METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1560717A FR3043480B1 (en) | 2015-11-09 | 2015-11-09 | METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3043480A1 true FR3043480A1 (en) | 2017-05-12 |
| FR3043480B1 FR3043480B1 (en) | 2017-12-15 |
Family
ID=55345975
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1560717A Active FR3043480B1 (en) | 2015-11-09 | 2015-11-09 | METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3043480B1 (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2502266A (en) * | 2012-05-21 | 2013-11-27 | Vodafone Ip Licensing Ltd | Controlling availability of a pool of surplus resource capabilities of control units associated with one or more base stations |
| US20140287754A1 (en) * | 2013-03-24 | 2014-09-25 | Mariana Goldhamer | Offloading mobile applications to base stations |
-
2015
- 2015-11-09 FR FR1560717A patent/FR3043480B1/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2502266A (en) * | 2012-05-21 | 2013-11-27 | Vodafone Ip Licensing Ltd | Controlling availability of a pool of surplus resource capabilities of control units associated with one or more base stations |
| US20140287754A1 (en) * | 2013-03-24 | 2014-09-25 | Mariana Goldhamer | Offloading mobile applications to base stations |
Non-Patent Citations (2)
| Title |
|---|
| JESSICA OUEIS ET AL: "The Fog Balancing: Load Distribution for Small Cell Cloud Computing", 2015 IEEE 81ST VEHICULAR TECHNOLOGY CONFERENCE (VTC SPRING 2015) : GLASGOW, SCOTLAND, UNITED KINGDOM, 11 - 14 MAY 2015, 1 May 2015 (2015-05-01), Piscataway, NJ, pages 1 - 6, XP055292054, ISBN: 978-1-4799-8088-8, DOI: 10.1109/VTCSpring.2015.7146129 * |
| OUEIS JESSICA ET AL: "Small Cell Clustering for Efficient Distributed Fog Computing: A Multi-User Case", 2015 IEEE 82ND VEHICULAR TECHNOLOGY CONFERENCE (VTC2015-FALL), IEEE, 6 September 2015 (2015-09-06), pages 1 - 5, XP032857347, DOI: 10.1109/VTCFALL.2015.7391144 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3043480B1 (en) | 2017-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3066565B1 (en) | Method and computer program for the off-site execution of computing tasks of an item of wireless equipment | |
| US9955290B2 (en) | Opportunistic offloading of tasks between nearby computing devices | |
| US10244023B2 (en) | Active offline storage management for streaming media application used by multiple client devices | |
| WO2019148569A1 (en) | Method and system for sending request for acquiring data resource | |
| US11212778B2 (en) | Facilitation of channel selection within a wireless network | |
| Jiang et al. | Efficient D2D content caching using multi-agent reinforcement learning | |
| EP2198644A2 (en) | Radio measurement in a radio communication network | |
| FR3016108B1 (en) | MANAGING THE QUALITY OF APPLICATIONS IN A COOPERATIVE COMMUNICATION SYSTEM | |
| FR3096204A3 (en) | Capping the pace of inbound transactions in established inbound stateful exchanges in a distributed computing environment | |
| EP3923138A1 (en) | Control of transfer of calculation tasks in multi-access periphery computing | |
| FR3045859A1 (en) | METHOD AND APPARATUS FOR FORMING A COMPUTER CLOUD STORING THE RESULT OF EXECUTION FROM A COMPUTER TASK | |
| FR3043480A1 (en) | METHOD AND SYSTEM FOR COMPILING CLUSTERS OF COMPUTER CLOUD EQUIPMENT WITH DISTRIBUTED RESOURCE ALLOCATION AND CORRECTION OF CENTRALIZED FEASIBILITY | |
| WO2015114224A1 (en) | Method of communication between a battery powered terminal and a base station and associated communication network | |
| US9621486B2 (en) | System and methods for assigning communication requests to range of transmission control protocol ports | |
| WO2017049448A1 (en) | Bandwidth sharing method, and related apparatus and system | |
| Rawat et al. | A critical analysis on integration of fog computing and cloud computing | |
| FR2966684A1 (en) | METHOD, DEVICES AND COMPUTER PROGRAM FOR DYNAMICALLY SELECTING FREQUENCY BANDS FOR UPLINK COMMUNICATION OF POWER-CONTROLLED OFDMA OR SC-FDMA TERMINALS | |
| US11800343B2 (en) | Emergency monitoring application mobility management | |
| FR3042618A1 (en) | METHOD, DEVICES AND SYSTEM FOR ESTABLISHING A COMPUTER CLOUD WITH REPLY DELAY SIGNALING | |
| WO2023203718A1 (en) | Wireless communication method and wireless communication system | |
| EP2875687A1 (en) | Method for managing the configuration of a telecommunication network | |
| FR3126828A1 (en) | DYNAMIC INTEGRATION PROCESS IMPLEMENTED DURING THE FEDERATION OF RADIOCOMMUNICATION NETWORKS AND COMPUTER PROGRAM PRODUCT | |
| FR3124619A1 (en) | CALCULATION METHOD AT THE NETWORK EDGE USING A GENERATIVE DATA MODEL | |
| FR3107974A1 (en) | Method and device for allocating network resources to a vehicle | |
| CN117201614A (en) | Resource allocation method and device, data downloading method and device and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20170512 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 9 |