Arrière-plan de l’invention

[0001] La présente description se rapporte au domaine des réseaux de télécommunications et, plus précisément, à des procédés et à des dispositifs de répartition de ressources au sein d’une infrastructure en réseau. [0002] Dans ce contexte, les réseaux de télécommunications mettent en œuvre des d’équipements physiques offrant des services de communication fixe, sans fil et mobile. Toutefois, en raison de l’augmentation croissante des débits de données proposés aux clients de ces services, la consommation électrique de ces réseaux est de plus en plus importante, et il n’est pas toujours possible d’installer de nouveaux équipements physiques adaptés dans les infrastructures existantes.

[0003] Pour pallier ces limitations, il est connu des méthodes de virtualisation permettant de générer des fonctions de réseau virtualisées sur un dispositif d’hébergement d’une infrastructure en réseau existante. En particulier, une fonction de réseau virtualisée de type VNF (ou « Virtual Network Function », en anglais), dite aussi fonction virtuelle ou instance de fonction virtuelle, peut être mise en œuvre sur un serveur physique banalisé et être déployée en divers endroits de l’infrastructure selon les besoins des opérateurs et des clients.

[0004] Ainsi, une fonction virtuelle peut être installée sur un dispositif d’hébergement d’une infrastructure en réseau, par exemple une entité de gestion, une machine virtuelle VM (ou « Virtual Machine », en anglais), un conteneur d’un serveur ou directement sur un serveur informatique, adapté pour accueillir la fonction virtualisée.

[0005] Une fonction virtuelle comprend typiquement un ensemble de composants logiciels, et permet une mise en œuvre virtualisée d’opérations ou de services habituellement effectués par du matériel physique dédié, tels que des serveurs ou des processeurs de calcul banalisés. Ceci permet de fournir des fonctionnalités similaires à celles fournies par des équipements physiques, mais sans nécessiter d’implantation matérielle.

[0006] Actuellement, des méthodes sont connues pour permettre à un opérateur d’un réseau de télécommunications d’instancier, de supprimer et/ou de déplacer des fonctions virtuelles dans une infrastructure en réseau donnée.

[0007] Cependant, les méthodes connues présentent de nombreux inconvénients lors du déploiement de nouvelles instances de service, notamment parce que celles-ci imposent des contraintes en termes de consommation de ressources et/ou lorsque les équipements de l’infrastructure sont de faible capacité.

[0008] Dans un premier exemple, lorsqu’on souhaite déployer une instance d’une fonction virtuelle sur un dispositif d’hébergement d’une infrastructure en réseau, par exemple pour pallier un nombre important de demandes de connexion à un réseau de télécommunications, un partage de charge et/ou de ressources entre l’instance à déployer et les instances déjà présentes doit être mis en œuvre ; on parle dans ce cas d’opération de « scale-out », en anglais.

[0009] Dans un deuxième exemple, lorsqu’une instance existante est à supprimer dans l’infrastructure, par exemple pour réduire la consommation électrique de l’infrastructure conjointement à une réduction d’un nombre de demandes de connexion à un réseau de télécommunications, une mise à jour du partage de charge et de ressources entre les instances présentes peut être mise en œuvre ; on parle dans ce cas d’opération de « scale-in », en anglais.

[0010] Cependant, les mécanismes connus et les algorithmes correspondants qui sont utilisés pour répartir des ressources lors de la virtualisation de fonctions réseau présentent plusieurs inconvénients majeurs au regard de la répartition des ressources entre instances de fonctions virtuelles. C’est notamment le cas lors de l’activation de nouvelles instances de service lors d’une augmentation de la demande ou lors de la désactivation d’instances de service en fonctionnement lors d’une diminution de la demande.

[0011] Tout d’abord, les mécanismes connus ne permettent pas d’obtenir un niveau de performance optimal lors d’une opération de « scale-in ». En effet, lorsque plusieurs fonctions virtuelles sont instanciées au sein d’une même infrastructure, les mécanismes connus ne permettent que d’effectuer un choix aléatoire de l’instance à supprimer. Il n’est donc pas possible de mettre en œuvre une suppression déterminée, qui tiendrait compte par exemple de la présence d’autres instances dans l’infrastructure.

[0012] Les mécanismes connus présentent des inconvénients similaires lors d’opérations de « scale-out » ou, plus généralement, lorsqu’on souhaite instancier de nouvelles fonctions virtuelles dans une même infrastructure.

[0013] En outre, le déploiement ou la suppression d’instances de fonctions virtuelles dans une infrastructure en réseau au moyen des mécanismes connus ne tient pas compte des types de ressources consommées par ces instances, et ne tient pas compte non plus de la quantité de ces ressources.

[0014] Ensuite, un serveur informatique utilisé comme dispositif d’hébergement par des instances de fonctions virtuelles est généralement partagé au sein d’une infrastructure en réseau. Il en résulte que plusieurs instances de fonctions virtuelles peuvent utiliser ensemble les mêmes ressources de ce serveur informatique, ce qui pose problème pour fournir une nouvelle répartition des ressources lors d’opérations de « scale-in » et de « scale-out ». En particulier, choisir aléatoirement une instance de fonction virtuelle à supprimer peut avoir un impact dommageable sur le trafic passant par celle-ci, c’est-à-dire sur sa charge de trafic.

[0015] Or, un objectif important des opérateurs de télécommunications actuels est de pouvoir maximiser la charge de trafic pouvant circuler sur leurs réseaux tout en préservant la qualité de service, et la qualité de service pouvant être fournie dépend directement de la charge de trafic associée.

[0016] De plus, la manière dont sont réparties des instances de fonctions virtuelles sur des nœuds de service d’une infrastructure en réseau est susceptible d’évoluer dans le temps ; il en résulte que la charge de trafic, la consommation de ressources et le coût opérationnel correspondant évolue également dans le temps, ce que les mécanismes connus ne prennent pas en compte.

[0017] La présente divulgation a pour objet d’apporter des améliorations par rapport à l’état de la technique. En particulier, l’état de la technique nécessite de nouveaux procédés et de nouveaux dispositifs pour répartir des ressources avec un meilleur niveau de performance entre des instances dans une infrastructure en réseau.

Objet et résumé de l’invention [0018] Les présentes proposent de fournir des procédés et des dispositifs optimisant l'organisation, la coordination, la gestion et la répartition des différentes ressources utilisées par des systèmes informatiques complexes, notamment lorsque lesdits systèmes informatiques sont virtualisés.

[0019] Afin d’améliorer la situation et de répondre aux inconvénients décrits précédemment, il est proposé selon un premier objet des présentes, un procédé de répartition d’une consommation de ressources dans une infrastructure en réseau comportant une pluralité de dispositifs d’hébergement, ledit procédé étant mis en œuvre par un ordonnanceur configuré pour être connecté à ladite infrastructure, le procédé comprenant les étapes suivantes: - attribuer, à chaque dispositif d’hébergement de ladite pluralité, un coefficient de pondération qui est fonction d’une instance courante d’une fonction virtuelle, d’une part, et d’au moins un type de ressource consommable par ladite instance courante, d’autre part, l’instance courante étant paramétrable pour être déployée sur l’un au moins des dispositifs d’hébergement de ladite pluralité ; - sélectionner au moins un dispositif d’hébergement parmi la pluralité, le dispositif d’hébergement sélectionné ayant le coefficient de pondération minimum ; et - paramétrer l’instance courante pour être déployée sur le dispositif d’hébergement sélectionné.

[0020] Dans les présentes, une fonction virtuelle peut être installée sur un dispositif d’hébergement d’une infrastructure en réseau. Un dispositif d’hébergement comprend, typiquement, un serveur informatique. Le dispositif d’hébergement peut aussi comprendre toute entité adaptée pour accueillir une telle fonction virtuelle, par exemple une entité de gestion, une machine virtuelle VM (ou « Virtual Machine », en anglais), ou encore un conteneur. [0021] Dans les présentes, l’installation d’une fonction virtuelle comprend le déploiement d’une ou de plusieurs instances de cette fonction virtuelle sur un ou plusieurs dispositifs d’hébergement.

[0022] Dans les présentes, une infrastructure en réseau comporte typiquement un ou plusieurs dispositifs d’hébergement, parmi lesquels des serveurs informatiques physiques et/ou des serveurs informatiques virtuels, raccordés entre eux en réseau, par exemple au sein d’un centre de données.

[0023] Dans les présentes, l'expression "réseau" désigne différents types de réseaux, en particulier des réseaux de télécommunication et des réseaux de communication de données, qu'ils fournissent des services fixes ou mobiles.

[0024] Dans les présentes, l'expression "réseau " désigne aussi tout service de réseau fonctionnant sur une infrastructure en réseau dans laquelle des fonctions virtuelles sont déployées. En d'autres termes, les réalisations décrites dans les présentes peuvent aussi être appliquées au cas d’infrastructures en réseau utilisant un ou plusieurs éléments matériels dédiés sous la forme de fonctions physiques de type PNF (ou « Physical Network Function », en anglais).

[0025] Dans les présentes, plusieurs instances d’une même fonction virtuelle peuvent être déployées sur un même dispositif d’hébergement d’une infrastructure en réseau, ou sur différents dispositifs d’hébergement de cette infrastructure en réseau.

[0026] Dans les présentes, un déploiement d’une instance de fonction virtuelle sur un dispositif d’hébergement donné implique typiquement qu’en fonctionnement, cette instance va consommer un ou plusieurs types de ressources, en particulier une ressource d’énergie électrique. De même, une suppression d’une instance de fonction virtuelle sur un dispositif d’hébergement donné implique typiquement une libération de ressources d’un ou de plusieurs types, en particulier une ressource d’énergie électrique.

[0027] Dans les présentes, l’étape d’attribution du coefficient de pondération peut comprendre une étape de calcul dudit coefficient de pondération.

[0028] Dans les présentes, et de manière non limitative, un coefficient de pondération est un indicateur numérique et quantifiable, par exemple une grandeur physique, qui dépend donc d’une instance donnée et d’au moins un type de ressource donné, cette ressource étant consommable par cette instance. En comparant les valeurs relatives de différents coefficients de pondération, il est possible de classer différents dispositifs d’hébergement.

[0029] Ainsi, il est possible de paramétrer une ou plusieurs instances d’une fonction virtuelle de sorte à consommer plus ou moins de ressources d’un type donné. Ceci permet donc de répartir de manière optimale la répartition de charge, de trafic et/ou de ressources correspondantes dans l’infrastructure en réseau.

[0030] Ceci permet aussi de mettre en œuvre un déploiement ou une suppression optimisée d’instances de fonctions virtuelles dans une infrastructure en réseau, ce déploiement ou cette suppression tenant compte du type de ressource utilisée par ces instances ainsi que de la quantité de cette ressource ou de ces ressources.

[0031] Dans une réalisation, l’étape de paramétrage comprend:

- allouer, pour ledit au moins un type de ressource, une quantité de ladite ressource à l’instance courante paramétrée.

[0032] Ceci permet de fournir un procédé de répartition de ressources dans une infrastructure en réseau tenant compte des coefficients de pondération calculés et/ou attribués.

[0033] Ceci permet aussi de fournir un procédé de répartition de ressources d’un type donné ou de différents types entre plusieurs instances déployées sur un même dispositif d’hébergement.

[0034] Dans une réalisation, une valeur de la quantité allouée de la ressource est inférieure ou égale à une valeur maximale qui est fonction d’au moins un coefficient de pondération attribué au dispositif d’hébergement sélectionné.

[0035] Ceci permet d’optimiser l’allocation de ressources entre plusieurs instances déployées sur un même dispositif d’hébergement. Eventuellement, ceci peut s’appliquer aussi, lorsque c’est le cas, à l’optimisation de l’allocation de ressources entre plusieurs instances déployées sur des dispositifs d’hébergement distincts.

[0036] Ainsi, il est possible de concentrer la charge de trafic de fonctions virtuelles sur des instances ayant une efficacité énergétique la plus élevée possible. [0037] Ainsi, prendre en compte un coefficient de pondération permet de pondérer la répartition d’instances de fonctions virtuelles dans l’infrastructure en réseau de sorte à déployer d’abord les instances qui présentent un coefficient de pondération plus petit.

[0038] Dans un cas particulier, par exemple pour un réseau de télécommunications, il est possible de concentrer une charge de trafic gérée par une fonction virtuelle donné sur la ou les instances de celle-ci présentant une efficacité énergétique la plus élevée possible.

[0039] Dans une réalisation, l’étape de paramétrage comprend en outre: mettre à jour au moins un coefficient de pondération attribué à un dispositif d’hébergement de la pluralité en fonction de la valeur de la quantité allouée de la ressource.

[0040] Dans une réalisation particulière, la mise à jour peut non seulement se rapporter à l’instance courante, mais aussi à toute autre instance éventuellement présente sur ledit dispositif d’hébergement.

[0041] Dans une réalisation, le coefficient de pondération mis à jour est enregistré par l’ordonnanceur sur l’instance courante et/ou est émis par l’instance courante sous forme d’un message vers un répartiteur de trafic connecté à l’infrastructure en réseau, ledit message comprenant le coefficient de pondération mis à jour de ladite instance paramétrée

[0042] Dans les présentes, un trafic est un trafic de paquets de données ou de signaux, tels que des signaux de commande, transitant par des nœuds, des serveurs ou en particulier des dispositifs d’hébergement de l’infrastructure en réseau.

[0043] Ceci permet de mettre en œuvre un déploiement (ou une suppression) d’instances de fonctions virtuelles dans une infrastructure en réseau tenant compte de l’évolution temporelle des positions sur lesquelles de telles instances sont déployées et des quantités de ressources d’un type donné consommées par ces instances. [0044] Ceci permet aussi de répartir de manière optimale la charge de trafic sur les instances d’une fonction virtuelle, et de fournir une information précise de l’efficacité énergétique de chaque instance de cette fonction virtuelle.

[0045] Dans une réalisation, le coefficient de pondération est proportionnel à un ratio entre une quantité réservée dudit au moins un type de ressource par l’instance courante de ladite fonction virtuelle lorsque ladite instance courante est installée sur le dispositif d’hébergement sélectionné et une somme d’une quantité réservée de ressources de même type par toute autre instance de la fonction virtuelle, ladite autre instance étant distincte de l’instance courante.

[0046] Dans une réalisation, le coefficient de pondération comprend une somme dudit ratio pour tout type de ressource réservée par l’instance courante.

[0047] Dans une réalisation, le coefficient de pondération prend en compte un coût énergétique, ledit coût énergétique étant choisi parmi un coût énergétique à vide, un coût énergétique en veille, un coût énergétique en phase de démarrage, un coût énergétique en phase de charge intermédiaire ou un coût énergétique à pleine charge.

[0048] Ceci permet de déterminer un coefficient de pondération fonction d’un type de ressource et d’une instance courante paramétrée pour être déployée sur un dispositif d’hébergement sans considérer que la charge de trafic correspondante soit nulle ou proche de zéro.

[0049] Dans une réalisation, l’étape de paramétrage comprend un déploiement de l’instance courante sur le dispositif d’hébergement sélectionné.

[0050] Ceci permet de répartir de manière optimale une charge de trafic au moyen d’une création d’instances d’une fonction virtuelle au sein de l’infrastructure en réseau.

[0051] Dans une réalisation, au moins l’une des étapes parmi l’étape d’attribution, l’étape de sélection ou l’étape de paramétrage est mise en œuvre sur réception d’une requête d’allocation de ressources, ladite requête d’allocation étant émise par un dispositif tiers connecté à l’ordonnanceur. [0052] Dans les présentes, la réception de ladite requête d’allocation de ressources peut être faite par une instance telle que l’instance courante, par l’ordonnanceur ou encore par le répartiteur de trafic.

[0053] Dans les présentes, ledit dispositif tiers peut être une entité client, par exemple un terminal mobile, configuré pour être connecté à l’infrastructure en réseau, notamment à un dispositif d’hébergement de ladite infrastructure, ou encore à l’ordonnanceur s’il est connecté à l’infrastructure.

[0054] Ceci permet au dispositif tiers de déclencher et éventuellement d’orchestrer la répartition des ressources en un instant donné.

[0055] Dans une réalisation, la requête d’allocation comprend la quantité de la ressource à allouer.

[0056] Dans une réalisation, un type de ressource est choisi parmi une ressource de calcul, une ressource de mémoire ou, une ressource de réseau et une ressource d’énergie.

[0057] Par exemple, un processeur et une mémoire compris dans une infrastructure en réseau fournissent des ressources de calcul, qui sont des quantités mesurables pouvant être allouées à ou fournies par des fonctions virtuelles ou physiques. Par exemple, des ressources requises de type CPU (« Central Processing Unit », en anglais) sont mesurées en unités de processeur.

[0058] Ceci permet d’optimiser la répartition de ressources dans l’infrastructure en fonction du type de ces ressources.

[0059] Les différents aspects du procédé de répartition qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.

[0060] Selon un deuxième objet des présentes, il est aussi proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des réalisations du premier objet, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.

[0061] Un tel programme informatique peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

[0062] Selon un troisième objet des présentes, il est aussi proposé un support de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des réalisations du premier objet.

[0063] Un tel support de stockage d’informations peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple sur un disque dur.

[0064] D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.

[0065] Alternativement, le support d'informations peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.

[0066] Selon un quatrième objet des présentes, il est aussi proposé un ordonnanceur pour répartir une consommation de ressources dans une infrastructure en réseau comportant une pluralité de dispositifs d’hébergement, ledit ordonnanceur étant configuré pour être connecté à ladite infrastructure et pour:

- attribuer, à chaque dispositif d’hébergement de ladite pluralité, un coefficient de pondération qui est fonction d’une instance courante d’une fonction virtuelle, d’une part, et d’au moins un type de ressource consommable par ladite instance courante, d’autre part, l’instance courante étant paramétrable pour être installée sur l’un au moins des dispositifs d’hébergement de ladite pluralité ;

- sélectionner au moins un dispositif d’hébergement parmi la pluralité, le dispositif d’hébergement sélectionné ayant le coefficient de pondération minimum ; et - paramétrer l’instance courante pour être installée sur le dispositif d’hébergement sélectionné.

[0067] Dans les présentes, les réalisations du premier objet peuvent s’étendre de manière similaire au quatrième objet.

[0068] Ceci permet de fournir un dispositif apte à gérer, c’est-à-dire à paramétrer, installer et/ou supprimer des instances de fonctions virtuelles sur des dispositifs d’hébergement d’une infrastructure en réseau.

[0069] Avantageusement, la répartition des ressources consommées par les instances déployées sur ces dispositifs d’hébergement est optimisée, car celle-ci se fait en fonction d’une optimisation mettant en œuvre une identification d’un coefficient de pondération le plus faible parmi une pluralité déterminée.

Brève description des dessins

[0070] D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :

[0071] [Fig. 1], la figure 1 , représente une vue schématique d’un environnement d’une infrastructure en réseau, selon un exemple de réalisation ;

[0072] [Fig. 2], la figure 2, représente une vue schématique d’une infrastructure en réseau, selon un exemple de réalisation ;

[0073] [Fig. 3], la figure 3, représente une évolution d’une puissance électrique consommée par un dispositif d’hébergement d’une infrastructure en réseau en fonction de son état de fonctionnement, selon un exemple de réalisation ;

[0074] [Fig. 4], la figure 4, représente des efficacités énergétiques d’instances de fonction virtuelle déployées sur un dispositif d’hébergement d’une infrastructure en réseau, selon un exemple de réalisation ;

[0075] [Fig. 5], la figure 5, représente sous forme d’organigramme, des étapes d’un procédé de répartition d’une consommation de ressources selon un exemple de réalisation ; [0076] [Fig. 6], la figure 6, représente des sous-étapes de mise à jour d’un coefficient de pondération pour un procédé de répartition d’une consommation de ressources selon un exemple de réalisation ;

[0077] [Fig. 7], la figure 7, représente sous forme d’organigramme, des étapes d’un procédé de répartition d’une consommation de ressources selon un exemple de réalisation ; et

[0078] [Fig. 8], la figure 8, représente un bloc-diagramme schématique d'un circuit de traitement selon un exemple de réalisation.

[0079] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.

Description des modes de réalisation

[0080] Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant.

[0081] Dans la suite de la description, on présente des modes de réalisation de l'invention dans une infrastructure en réseau. Cette infrastructure peut être mise en œuvre pour acheminer des données de communications à destination de terminaux fixes ou mobiles et l’invention peut être destinée à installer des fonctions virtuelles, par exemple des fonctions virtuelles utilisées pour l’acheminement et/ou le traitement de données provenant de ces terminaux.

[0082] Il est maintenant fait référence à la figure 1 , qui représente une infrastructure en réseau R et un ordonnanceur ORD pour la mise en œuvre d’un procédé de répartition d’une consommation de ressources.

[0083] De manière non limitative, l’infrastructure en réseau R comporte trois nœuds, ici trois dispositifs d’hébergement N1 , N2 et N3 qui sont chacun configurés pour accueillir des instances de fonction virtuelle, et, en particulier, au moins deux instances VF1 et VF2 d’une fonction virtuelle VF donnée. [0084] De manière non limitative, chacune des instances VF1 et VF2 est configurée pour consommer au moins quatre types différents de ressources T1 à T4. Cette séparation en types de ressources permet d’améliorer la répartition de la consommation de celles-ci lors de la mise en œuvre du procédé selon ses réalisations.

[0085] Dans les présentes, le type de ressource T 1 désigne une ressource de calcul pouvant être requise par une instance de fonction virtuelle. Par exemple, une ressource de type T1 est une ressource de type CPU (« Central Processing Unit », en anglais), c’est-à-dire une ressource de temps de calcul fournie par une unité centrale de traitement que comprend un dispositif d’hébergement, un serveur informatique ou un processeur de l’infrastructure en réseau R.

[0086] De manière équivalente, T1 peut désigner une ressource de calcul graphique, c’est-à-dire une ressource de type GPU (« Graphics Processing Unit », en anglais) fournie par une unité graphique de traitement que comprend un dispositif d’hébergement, un serveur informatique ou un processeur de l’infrastructure en réseau R.

[0087] Dans les présentes, le type de ressource T2 désigne une ressource de mémoire vive pouvant être requise par une instance de fonction virtuelle. Par exemple une ressource de type T2 est une ressource de type RAM (« Random Access Memory », en anglais), c’est-à-dire une ressource de mémoire fournie par une mémoire à accès non séquentiel que comprend un dispositif d’hébergement, un serveur informatique ou un processeur de l’infrastructure en réseau R.

[0088] Dans les présentes, le type de ressource T3 désigne une ressource de mémoire morte pouvant être requise par une instance de fonction virtuelle. Par exemple une ressource de type T3 est une ressource de type ROM (« Read-Only Memory », en anglais), de type DISK, le type DISK comprenant le type FIDD (« Flard Disk Drive », en anglais) et le type SDD (« Solid State Drive », en anglais). En toute généralité, Il s’agit d’une ressource de mémoire morte fournie par un disque sur un dispositif d’hébergement, un serveur informatique ou un processeur de l’infrastructure en réseau R. [0089] Dans les présentes, le type de ressource T4 désigne une ressource réseau pouvant être requise par une instance de fonction virtuelle. Par exemple une ressource de type T4 est une ressource de type NIC (« Network Interface Controller », en anglais), et plus généralement, une ressource telle qu’un taux de production, une vitesse ou un débit global de communication réseau d'un routeur, d’un dispositif d’hébergement, d’un serveur informatique, etc. de l’infrastructure en réseau R.

[0090] Comme il sera décrit dans la suite, l’ordonnanceur ORD est configuré pour mettre en œuvre des étapes d’attribution de coefficient de pondération, de sélection de dispositif d’hébergement, de paramétrage d’instance et éventuellement de déploiement d’instance, d’allocation d’une quantité de ressource et de mise à jour de coefficient de pondération selon l’un ou l’autre des exemples de réalisation tels que détaillés ci-après. [0091] Il est maintenant fait référence à la figure 2, qui représente une infrastructure en réseau R pour la mise en œuvre d’un procédé de répartition d’une consommation de ressources.

[0092] Comme illustré, l’infrastructure en réseau R comprend une architecture NFV telle que définie par l’ETSI (« European Télécommunications Standards Institute », en anglais).

[0093] Cette architecture NFV de l’infrastructure R comprend une infrastructure virtualisée NFVI (« Network Function Virtualisation Infrastructure », en anglais), qui fournit des ressources matérielles telles que des serveurs ou des cartes électroniques, ainsi que des ressources virtuelles, telles que des logiciels de virtualisation.

[0094] L’infrastructure virtualisée NFVI comprend une interface matérielle PRES apte à fournir des ressources physiques de calcul PCPU (ou PGPU, non représentées), des ressources physiques de mémoire PMEM, des ressources physiques réseau PNET et éventuellement des ressources physiques d’énergie PEN. [0095] L’infrastructure virtualisée NFVI comprend aussi une interface virtuelle VRES apte à fournir des ressources virtuelles de calcul VCPU (ou VGPU, non représentées), des ressources virtuelles de mémoire VMEM, des ressources virtuelles réseau VNET et éventuellement des ressources virtuelles d’énergie VEN.

[0096] L’infrastructure virtualisée NFVI comprend en outre une couche de virtualisation VL assurant une liaison entre l’interface matérielle PRES et l’interface virtuelle VRES. La couche de virtualisation VL permet de découpler l’implémentation logicielle des fonctions réseaux aux ressources physiques décrites précédemment.

[0097] L’infrastructure en réseau R comprend de plus un module VNF-EMS, ce module comprenant des fonctions virtuelles VNF1 , VNF2 et VNF3 qui peuvent être exécutées sur des équipements ou des composants de l’infrastructure virtualisée NFVI.

[0098] Ces fonctions virtuelles VNF1 , VNF2 et VNF3 sont connectées entre elles pour fournir un service réseau, et sont gérées à l’aide de systèmes de gestion élémentaire EMS1 , EMS2 et EMS3 correspondants qui sont configurés pour gérer et orchestrer les ressources de l’infrastructure virtualisée NFVI.

[0099] L’infrastructure en réseau R comprend en outre un module de gestion NFV- MAN configuré pour gérer les services réseaux de bout en bout.

[0100] Le module de gestion NFV-MAN comprend un orchestrateur ORC qui est responsable du cycle de vie des services réseau tant au niveau logiciel que matériel.

[0101] Le module de gestion NFV-MAN comprend aussi un gestionnaire MAN de fonctions virtuelles, connecté au module VNF-EMS, et qui est en charge du cycle de vie des fonctions virtuelles VNF1 , VNF2 et VNF3. Le module de gestion NFV- MAN permet, en particulier, d’automatiser le déploiement de ces fonctions virtuelles.

[0102] Le module de gestion NFV-MAN comprend en outre un gestionnaire de virtualisation VIM, connecté aux autres éléments du module de gestion NFV-MAN, et qui est en charge de la gestion des ressources de l’infrastructure virtualisée NFVI.

[0103] Par ailleurs, le module de gestion NFV-MAN est connecté à un module de service OSS, qui est configuré pour transmettre à celui-ci des informations telles que des informations de profil, des informations de domaine, des commandes d’un opérateur ou d’un gestionnaire de l’infrastructure en réseau R, etc.

[0104] Ainsi, l’infrastructure virtualisée NFVI permet de déployer des services réseaux, à la demande, sur des nœuds de l’infrastructure en réseau R, et en particulier, sur des dispositifs d’hébergement tels que des serveurs informatiques dans celle-ci. Les fonctions virtuelles VNF1, VNF2 et VNF3 peuvent ainsi être déployées dynamiquement et à la demande, dans la limite des capacités de l’infrastructure virtualisée NFVI.

[0105] Il est maintenant fait référence à la figure 3, qui représente un exemple d’évolution de la puissance électrique consommée par un dispositif d’hébergement selon son état de fonctionnement, ce dispositif d’hébergement étant par exemple un serveur informatique de l’infrastructure en réseau R.

[0106] Dans les présentes, un dispositif d’hébergement tel qu’un serveur informatique fonctionne selon différents états de fonctionnement possibles, parmi lesquels un état S1 de fonctionnement en veille, un état S2 de fonctionnement en phase de démarrage, un état S3 de fonctionnement à vide, un état S4 de fonctionnement en charge intermédiaire et un état S5 de fonctionnement à pleine charge.

[0107] Sur la figure 3 est représentée la situation d’un serveur informatique activé à partir d’un état de veille et sur lequel on déploie une pluralité d’instances de fonction virtuelle, de manière progressive, après la fin de sa phase de démarrage.

[0108] En mode veille, dans l’état S1, la puissance électrique consommée par le serveur est non-nulle, sensiblement constante et égale à PO. Cette puissance électrique PO est inférieure à la puissance minimale Pmin, qui correspond à la puissance qui est consommée par le serveur lorsqu’il fonctionne à vide, dans l’état S3, c’est-à-dire lorsque celui-ci est activé mais n’héberge aucune instance.

[0109] Lors d’une activation à partir du mode veille, c’est-à-dire lorsque le serveur est placé dans l’état S2 qui correspond à une phase de démarrage, le serveur consomme une puissance Pstart qui est constante et supérieure à la puissance Pmin, qui est la puissance correspondante du serveur lorsqu’il n’héberge aucune instance.

[0110] Lors du déploiement d’instances sur le serveur de manière successive, c’est- à-dire une instance après l’autre, le serveur entre dans l’état S4 et consomme une puissance électrique augmentant linéairement, jusqu’à atteindre une valeur maximale, Pmax, dans l’état S5 lorsque le dispositif d’hébergement est à pleine charge.

[0111] Dans les présentes, une désactivation progressive d’un serveur informatique à pleine charge peut être illustrée de manière analogue, c’est-à-dire en faisant passer le serveur de l’état S5 à l’état S4 en supprimant des instances déployées sur celui-ci, puis de l’état S4 à l’état S3 lorsque toutes les instances sont supprimées, puis de l’état S3 à l’état S1 lorsque le serveur est mis en veille, par exemple. Ainsi, il est possible de mettre en veille un serveur informatique à partir d’un état où celui- ci n’héberge plus aucune instance de fonction virtuelle, pour atteindre une consommation énergétique négligeable.

[0112] Typiquement, un serveur informatique qui fait office de dispositif d’hébergement dans une infrastructure en réseau R conforme aux exemples de réalisation décrits dans les présentes est raccordé à un circuit d’alimentation électrique. La puissance électrique PO consommée par un tel serveur informatique, dans l’état S1 , est typiquement de l’ordre d’une dizaine de Watts.

[0113] Lorsque ce serveur informatique est mis en phase de démarrage (avec une durée généralement de moins de 5 minutes), la puissance électrique Pstart consommée dans l’état S2 est de l’ordre de 150 à 200 Watts en moyenne. A l’issue de cette phase de démarrage, la consommation à vide du serveur se stabilise lors de son passage dans l’état S3, avec une puissance Pmin de l’ordre de 120 Watts. Typiquement, la puissance Pstart a une valeur supérieure à celle de la puissance Pmin.

[0114] Au cours de l’état S4, c’est-à-dire lorsque le serveur héberge un nombre de plus en plus important d’instances de fonction virtuelle, la consommation de puissance électrique du serveur augmente progressivement depuis Pmin jusque Pmax. Cette augmentation est fonction du nombre d’instances ainsi que de la charge de chaque instance.

[0115] Il convient de noter que la consommation électrique d’un serveur informatique typique n’est pas proportionnelle au nombre d’instances de fonctions virtuelles qu’il héberge. En régime permanent, cependant, cette consommation correspond globalement à une fonction affine de la charge, dont la valeur à l’origine est non nulle.

[0116] En outre, il convient de noter que lorsqu’une instance de fonction virtuelle est supprimée sur un serveur informatique, la valeur à l’origine de la consommation électrique correspond à un nombre plus petit d’instances de fonctions virtuelles. Il en résulte que l’efficacité énergétique associée est modifiée au détriment des éventuelles instances restantes qui sont déployées sur le serveur informatique.

[0117] Lorsque le serveur informatique passe dans l’état S5, c’est-à-dire lorsqu’il fonctionne à pleine charge, c’est-à-dire que toutes ses ressources sont utilisées par l’ensemble des instances qu’il héberge, le serveur consomme une puissance électrique Pmax qui est typiquement de l’ordre de 500 Watts, c’est-à-dire une puissance élevée mais néanmoins inférieure à la puissance électrique maximale pouvant être fournie par l’alimentation électrique du serveur, qui est de l’ordre de 1000 Watts.

[0118] Cette évolution de la puissance électrique consommée par un serveur informatique en fonction de l’état dans lequel il se trouve s’applique aussi au cas d’une pluralité de serveurs, par exemple 8 à 16 serveurs. Ces serveurs sont par exemple intégrés dans une armoire électrique ou un châssis commun. Ainsi, dans le cas où ces serveurs n’ont pas d’alimentation électrique individuelle, l’armoire ou le châssis fournit une alimentation électrique commune à l’ensemble des serveurs.

[0119] Il est maintenant fait référence aux équations 1 à 3 ci-dessous, pour calculer un ou plusieurs coefficients de pondération associés à une ou plusieurs instances courantes, d’une part, et d’un ou plusieurs types de ressources consommables par cette ou ces instances courantes, d’autre part. [0120] Comme décrit ci-après, ces équations permettent de déterminer un ou plusieurs coefficients de pondération en fonction d’une puissance consommée par une instance de fonction virtuelle qui est à déployer ou qui est déployée sur un dispositif d’hébergement de l’infrastructure en réseau R.

[0121] La puissance consommée par une instance de fonction virtuelle à déployer ou déployée sur un dispositif d’hébergement dépend du type de ressource qu’elle requiert, et pour chacun de ces types de ressource, de la quantité de ressource réservée et de la quantité de ressource utilisée.

[0122] Dans les présentes, une quantité de ressource réservée par une instance ou un dispositif hébergeant une telle instance est définie comme étant la quantité de ressource correspondante pouvant être fournie afin de pallier une demande, en particulier le fonctionnement de cette instance une fois déployée. Par exemple, un opérateur ou un gestionnaire de l’infrastructure en réseau R doit pouvoir garantir l’alimentation suffisante en ressources (de calcul, de mémoire ou d’autre type) des instances déployées sur les dispositifs d’hébergement qu’elle comprend, et notamment en cas de variation soudaine et/ou importante de la demande lorsque l’infrastructure est sollicitée.

[0123] Pour chaque type de ressource, il est établi que la puissance consommée par une instance courante de fonction virtuelle dépend de la somme de la quantité de ressources réservée par cette instance courante et de la quantité de ressources utilisée par celle-ci. Ainsi, pour chaque type de ressource, l’équation 1 ci-dessous définit la puissance consommée par le dispositif d’hébergement, notée « Pi », définie comme une fonction affine de la quantité de ressources utilisées « Qi », en fonction du type « i » de ressource, la valeur de i variant ici de 1 à 4.

[0124] [Math. 1]

Pi = Ai + Bi * Qi

[0125] Dans l’équation 1 , « Ai » et « Bi » désignent les coefficients de la fonction affine « Pi ». Les valeurs des coefficients « Ai » et « Bi » peuvent être déterminées par des mesures, par exemple des mesures de puissance de calibration effectuées sur un dispositif d’hébergement représentatif tel qu’un dispositif d’hébergement configuré avec l’ensemble des ressources, ou avec un sous-ensemble des ressources, lorsque ce dispositif est en fonctionnement, par exemple dans l’état S3.

[0126] Les valeurs numériques des produits « Bi ^* Qi » dans l’équation 1 peuvent être déterminés directement pour chaque type de ressource connaissant les valeurs de « Qi ». Les valeurs des coefficients « Ai » sont calculables indirectement : ceux- ci sont en effet liés par la puissance minimale Pmin qui est consommée par le dispositif d’hébergement dans l’état S3. Cette puissance minimale est égale à la somme des parties constantes de la fonction affine définie dans l’équation 1 , ladite somme étant effectuée sur toutes les valeurs possibles de l’indice « i », c’est-à-dire pour l’ensemble des types de ressources.

[0127] Ainsi, on peut montrer que la puissance consommée « Pi », en particulier la puissance consommée à vide dans l’état S3, pour une ressource de type Ti réservée par une instance courante, ici une instance VFj de fonction virtuelle déployée sur un dispositif d’hébergement, dépend de la quantité de ressources de ce type qui est réservée par VFj, d’une part, et de la quantité de ressources du même type qui est réservée par l’ensemble des autres instances présentes sur le même dispositif d’hébergement, d’autre part. Pour chaque type de ressource, la somme des puissances consommées par les instances présentes sur le dispositif d’hébergement est ainsi égale à la partie constante de fonction affine définie dans l’équation 1 .

[0128] Connaissant la puissance consommée par une instance courante VFj à déployer ou déployée sur un dispositif d’hébergement, il est alors possible de déterminer le coût énergétique « Ej » de celle-ci pendant un intervalle de temps « dt » donné. Ce coût énergétique est donné par l’équation 2 ci-dessous.

[0129] [Math. 2]

Ej = J Pj. dt

[0130] Dans les présentes, on définit aussi l’efficacité énergétique comme étant égale au rapport entre la charge de trafic « Lj » à traiter par une instance et la quantité d’énergie (ou coût énergétique) « Ej » nécessaire pour réaliser le traitement de cette charge de trafic pendant un intervalle de temps « dt » donné. Cette définition est donnée par l’équation 3 ci-dessous. [0131] [Math. 3]

EF] = Lj/Ej

[0132] Sur cette base, on peut déterminer une répartition de la charge de trafic entre plusieurs instances d’une fonction virtuelle, pour en déduire des coefficients de pondération pouvant être comparés entre eux.

[0133] Dans les présentes, on définit deux types distincts de coefficients de pondération, correspondant à deux réalisations différentes.

[0134] Une première réalisation se réfère à un coefficient de pondération selon l’équation 4 ci-dessous. [0135] [Math. 4]

Wij (Qij)res / å (Qij')res

[0136] Ce coefficient de pondération est proportionnel à un ratio entre une quantité « Qij » d’au moins un type Ti de ressource réservée par une instance VFj de fonction virtuelle et une somme d’une quantité « Qij’ » réservée de ressources de même type par toute autre instance VFj’ de la fonction virtuelle, ladite autre instance étant distincte de l’instance VFj, les quantités réservées étant celles estimée lorsque cette instance VFj ou VFj’ est déployée sur le dispositif d’hébergement sélectionné.

[0137] Une deuxième réalisation se réfère à un coefficient de pondération « sommé » selon l’équation 5 ci-dessous, la somme étant mise en œuvre sur l’ensemble des types de ressources, Ti. On obtient ainsi une somme du ratio de l’équation 4 pour tout type de ressource réservée par une instance courante.

[0138] [Math. 5]

Wj = åWij [0139] Pour illustrer ces réalisations, on fait par exemple référence à la figure 4, qui illustre la détermination d’un coefficient de pondération pour la mise en œuvre d’un procédé de répartition d’une consommation de ressources selon l’une ou l’autre des réalisations décrites dans les présentes.

[0140] Connaissant la relation de dépendance existant entre la puissance électrique des ressources réservées par type de ressource, la quantité de ressources réservées pour chaque type, et éventuellement d’autres facteurs tels que l’évolution spatiale et temporelle du trafic dans l’infrastructure en réseau R, on peut en déduire l’efficacité énergétique « EFj » de l’instance VFj d’une fonction virtuelle en fonction de la charge de trafic « Lj » et de la quantité de ressources « Qj » qui lui sont associées.

[0141] On notera que la quantité de ressources « Qj » pourra être réservée pour une instance VFj de fonction virtuelle afin de lui permettre de traiter une charge de trafic « Lj » pendant un intervalle de temps « dt » donné. La relation entre cette quantité de ressources et la charge de trafic est donnée par l’équation 6 ci-dessous, dans laquelle « Kj » désigne une constante de proportionnalité correspondante à VFj.

[0142] [Math. 6]

/ Qj. dt = Kj * Lj

[0143] En particulier, la figure 4 illustre la détermination d’un coût énergétique définissant un tel coefficient de pondération, dans la situation où deux instances VF1 et VF2 d’une fonction virtuelle sont déployées sur un ou plusieurs dispositifs d’hébergement. En ordonnée est représentée l’efficacité énergétique maximale « EFk » d’instances de fonction virtuelle en fonction de la charge de trafic « Lk » correspondante pendant un intervalle de temps « dt » donné. L’efficacité énergétique maximale « EFk » et la charge de trafic « Lk » associés à une instance « k » sont liés par l’équation 7 ci-dessous.

[0144] [Math. 7]

EFk = Lk/(j Ak. dt + Bk * Kk * Lk)

[0145] Sur la figure 4, l’efficacité énergétique EF1 est celle d’un dispositif d’hébergement pour lequel toutes les ressources réservées sont utilisées tandis que l’efficacité énergétique EF2 est celle d’un dispositif d’hébergement pour lequel une partie seulement des ressources réservées est utilisée.

[0146] Dès lors, il est possible de comparer les efficacités énergétiques EF1 et EF2 de deux instances VF1 et VF2 en comparant les pentes à l’origine « SU » et « SI2 » des courbes associées. Ces pentes à l’origine permettent de définir des coefficients de pondération W1 et W2, ici pour un type de ressource donnée, ici dans le cas où les charges de trafic L1 et L2 sont égales à zéro.

[0147] Considérant un seul type de ressource, la valeur de la pente à l’origine « SU » est mathématiquement égale à « 1/Em1 », où « Em1 » représente l’énergie consommée par les ressources réservées sur le dispositif d’hébergement par l’instance VF1 lorsqu’elle ne traite aucun trafic pendant l’intervalle de temps « dt ».

[0148] Cette propriété se démontre mathématiquement en dérivant l’efficacité énergétique maximale « EFk » donnée dans l’équation 7 en fonction de la charge de trafic « Lk » et en prenant la limite de la dérivée lorsque « Lk » se rapproche de zéro.

[0149] Dans les présentes, ceci se généralise à tout type de ressource Ti.

[0150] Dans le cas présent, on déduit que la pente à l’origine « SU » est de valeur plus grande que la pente à l’origine « SI2 », et donc que la valeur de « Em1 » est plus petite que la valeur de « Em2 », où « Em2 » représente l’énergie consommée par les ressources réservées sur le dispositif d’hébergement par l’instance VF1 lorsqu’elle ne traite aucun trafic pendant l’intervalle de temps « dt ». On fournit ainsi une grandeur physique permettant de comparer le coût énergétique et l’efficacité énergétique d’instances de fonction virtuelle en vue d’une répartition de celles-ci sur un ou plusieurs dispositifs d’hébergement d’une infrastructure en réseau R.

[0151] Par extension aux deux types de coefficients de pondération définis précédemment, deux types distincts de coûts énergétiques à vide peuvent être définis en lien avec la description précédente de l’efficacité énergétique et de l’énergie consommée par une instance. Un premier type se rapporte à la valeur du coût énergétique à vide d’une instance VFj pour un type de ressource Ti donné, « CEVij », est égal à la valeur de « Emj » pour ce type de ressource. Le deuxième type se rapporte à la valeur du coût énergétique à vide « sommé » d’une instance VFj, « CEVj », est égale à l’addition des valeurs de « Emj » pour tous les types Ti de ressource.

[0152] De manière non limitative, d’autres types de coefficients de pondération, et en particulier de coûts énergétiques, peuvent être définis à partir des courbes d’efficacité énergétique. Dans une réalisation possible, le coût énergétique d’une instance peut être un coût énergétique évalué suivant un état de fonctionnement spécifique d’un dispositif d’hébergement adapté pour héberger celle-ci, par exemple l’un des états S2, S3, S4 ou S5 correspondant, respectivement, à une veille, une phase de démarrage, une phase de charge intermédiaire ou une pleine charge du dispositif d’hébergement.

[0153] Ainsi, la courbe d’efficacité énergétique « EFk » d’une instance courante peut être utilisée pour définir un coefficient de pondération autrement que par la pente à l’origine de cette courbe d’efficacité énergétique, et donc un coût énergétique qui n’est pas nécessairement le coût énergétique à vide de l’instance.

[0154] La pente de cette courbe peut être évaluée dans le cas de valeurs non-nulles de la charge de trafic « Lk ». Par exemple, cette pente peut être évaluée dans un cas où l’on considère la limite de l’efficacité énergétique lorsque la charge de trafic est considérée comme tendant vers l’infini positif. En effet, comme c’est le cas pour les courbes représentées sur la figure 4, l’efficacité énergétique d’une instance dans le cas d’une charge de trafic très grande présente un comportement asymptotique, ce qui fournit un maximum pouvant être utilisé comme coefficient de pondération.

[0155] Il est maintenant fait référence à la figure 5, qui représente sous forme d’organigramme, des étapes F1 à F6 d’un procédé de répartition d’une consommation de ressources selon une réalisation.

[0156] Dans cette réalisation, une instance courante de fonction virtuelle à déployer sur un dispositif d’hébergement est, par exemple, une machine virtuelle configurée pour être instanciée sur un serveur informatique.

[0157] Sur la base de l’exemple représenté pour la figure 1 , l’ordonnanceur ORD, lorsqu’il est connecté à l’infrastructure R, attribue, lors d’une étape F1 , à l’un ou chacun des dispositifs N1 à N3, un coefficient de pondération dépendant d’une l’instance parmi VF1 et VF2 et d’un type de ressource parmi T1 , T2, T3 et T4. Il peut s’agir d’une instance ou de plusieurs de ces instances, alors désignée(s) instance(s) courante(s).

[0158] En outre, cette attribution peut être mise en œuvre pour un ou plusieurs types de ressources, de manière simultanée ou successive. [0159] Dans les présentes, un coefficient de pondération « Wki » désigne le coefficient de pondération correspondant à une instance courante de fonction virtuelle VFk, pour la ressource de type Ti.

[0160] Lors de l’étape F1 , l’ordonnanceur ORD attribue à chaque dispositif d’hébergement huit coefficients de pondération, parmi lesquels quatre coefficients W11 , W12, W13 et W14 qui correspondent à l’instance VF1 et quatre coefficients W21 , W22, W23 et W24 qui correspondent à l’instance VF2. Ces coefficients de pondération définissent chacun une valeur numérique, ce qui permet de les comparer entre eux.

[0161] En particulier, ces coefficients de pondération ont une valeur qui peut varier en fonction de l’instance de fonction virtuelle, du type de ressource et éventuellement de l’état du dispositif d’hébergement sur lequel cette instance peut être déployée.

[0162] On considère ici le cas simplifié de coefficients de pondération égaux aux coûts énergétiques à vide CEVij, qui sont fonction de l’instance courante VFj et du type de ressource Ti.

[0163] Lorsque les coûts énergétiques à vide ont été attribués aux dispositifs d’hébergement parmi N1 , N2 et N3, l’ordonnanceur ORD sélectionne, lors de l’étape F2, un dispositif d’hébergement, cette sélection étant effectuée de sorte à minimiser le coût énergétique à vide.

[0164] Typiquement, cette sélection est mise en œuvre de sorte que le coût énergétique à vide associé à un type de ressource donné et attribué au dispositif d’hébergement est inférieur ou égal aux coefficients de pondération associés au même type de ressource et attribués aux autres dispositifs d’hébergement de l’infrastructure R.

[0165] Ultérieurement, en cas d’allocation d’une quantité d’une ressource d’un type donné à un dispositif d’hébergement, ceci permet de s’assurer que cette quantité est inférieure ou égale à une valeur maximale, celle-ci étant fonction d’au moins un coût énergétique à vide attribué au dispositif d’hébergement sélectionné.

[0166] Par exemple, si une valeur numérique du coût énergétique à vide CEV23 correspondant à la consommation de ressources de mémoire morte par l’instance VF2, la valeur du coût énergétique à vide CEV23 attribué au dispositif N2 étant inférieure ou égale aux valeurs des coûts énergétiques à vide CEV23 attribués aux dispositifs N1 et N3, l’ordonnanceur ORD sélectionne le dispositif N2.

[0167] Lors de l’étape F3, et lorsqu’au moins un dispositif d’hébergement a été sélectionné, par exemple le dispositif N2, parmi la pluralité de dispositifs N1 à N3, l’ordonnanceur ORD paramètre l’une ou les instances VF1 et VF2 de la fonction virtuelle au cours d’une étape F3 en vue de la déployer sur le dispositif sélectionné, ici N2.

[0168] Dans une réalisation, l’ordonnanceur ORD peut aussi mettre en œuvre, au cours d’une étape F4, un déploiement de l’instance courante sur le dispositif d’hébergement sélectionné. Par exemple, l’ordonnanceur ORD déploie l’instance VF1 sur le dispositif d’hébergement N3 si la valeur du coût énergétique à vide CEV1 1 attribué à N3 est inférieure à la valeur de CEV11 attribué à N2 et à la valeur de CEV11 attribué à N1. Ce déploiement peut être mis en œuvre pour un ou plusieurs types de ressources, de manière simultanée ou successive.

[0169] Dans une réalisation, l’ordonnanceur ORD peut en outre mettre en œuvre, au cours d’une étape F5, une allocation d’une quantité de ressources à l’instance courante paramétrée, par exemple via l’émission d’une requête d’allocation. Cette requête d’allocation comprend de préférence la quantité de la ressource à allouer.

[0170] Cette ou ces ressource(s) peuvent être de n’importe quel type parmi T1 , T2, T3 et T4. Par exemple, une instance courante VF1 paramétrée pour être déployée sur le dispositif N2 car le coefficient de pondération CEV14 y est minimum peut se voir allouer une quantité de ressource réseau correspondante en vue de fournir cette ressource réseau à VF1 .

[0171] Dans une réalisation, l’ordonnanceur ORD peut par ailleurs mettre en œuvre, au cours d’une étape F6, une mise à jour de coefficient de pondération attribué à un dispositif d’hébergement donné en fonction de la valeur de la quantité allouée de la ressource lors de l’étape F5.

[0172] Par exemple, le déploiement de l’instance courante VF1 sur le dispositif N2 - ce déploiement découlant d’une sélection de N2 en raison d’une valeur minimale de CEV14 - altère inévitablement la capacité de N2 à continuer à fournir une quantité de ressource réseau de type T4. L’ordonnanceur ORD peut dès lors mettre à jour la valeur de CEV14 en une nouvelle valeur, CEV’14, qui tient compte de la présence de l’instance VF1 sur N2.

[0173] Le déploiement de l’étape F4, l’allocation de l’étape F5 et/ou la mise à jour de l’étape F6 peuvent/peut aussi être mis en œuvre par un dispositif autre que l’ordonnanceur ORD et connecté à l’infrastructure en réseau R.

[0174] Dans une réalisation particulière, l’étape de paramétrage comprend une suppression de l’instance courante sur le dispositif d’hébergement sélectionné ou un déplacement de l’instance courante sur un dispositif d’hébergement distinct du dispositif d’hébergement sélectionné.

[0175] Dans les présentes, cette réalisation particulière est de préférence mise en œuvre lorsque le coût énergétique à vide associé à un type de ressource donné et attribué à l’instance courante sur au dispositif d’hébergement est supérieur ou égal au coût énergétique à vide associés aux instances équivalentes et présentes sur d’aux autres dispositifs d’hébergement de l’infrastructure en réseau R.

[0176] Ceci permet de supprimer les instances les moins énergétiquement efficaces en cas de diminution de trafic. Par exemple, ceci est avantageux lorsque les instances de fonction virtuelle les plus énergétiquement efficaces sont regroupées sur un premier groupe de serveurs informatiques, et que les instances les moins énergétiquement efficaces sont regroupées sur un deuxième groupe de serveurs informatiques distincts du premier groupe.

[0177] Il est maintenant fait référence à la figure 6, qui représente des sous-étapes de mise à jour d’un coefficient de pondération pour un procédé de répartition d’une consommation de ressources selon une réalisation.

[0178] Ces sous-étapes permettent de mettre en œuvre une propagation des coefficients de pondération, par exemple des coûts énergétiques à vide, vers un dispositif configuré pour répartir la charge de trafic sur différentes instances d’une fonction virtuelle. [0179] Ceci permet de mettre à jour le coût énergétique à vide d’une instance de fonction virtuelle lors de l’ajout ou de la suppression d’une instance sur le même dispositif d’hébergement.

[0180] Dans une réalisation, ce dispositif est un répartiteur de trafic REP, ce répartiteur de trafic comprenant plusieurs équilibreurs de charge LB1 , LB2 et LB3. Par exemple, l’équilibreur de charge LB1 correspond à un plan de contrôle de fonctions virtuelles, configuré pour déterminer les itinéraires sur lequel transférer le trafic de ces fonctions virtuelles, l’équilibreur de charge LB2 correspond à un proxy http pour gérer l’accès à une autre infrastructure en réseau et l’équilibreur de charge LB3 correspond à une passerelle IP.

[0181] Comme ici illustré, le gestionnaire de virtualisation VIM joue le rôle d’ordonnanceur ORD tandis que le gestionnaire MAN de fonctions virtuelles joue le rôle d’entité cliente CE. Ni l’ordonnanceur ni l’entité cliente ne sont en relation directe avec dispositif configuré pour répartir la charge de trafic de chaque fonction virtuelle.

[0182] Dans une variante non illustrée, la répartition de charge peut être effectuée au niveau du plan de service, de sorte qu’un élément d’une fonction virtuelle peut être en charge de ce rôle.

[0183] Au cours de la sous-étape F41 , l’entité cliente CE émet une requête qui est fonction d’un type de ressource à l’ordonnanceur ORD, pour sélectionner un dispositif d’hébergement de l’infrastructure en réseau R sur lequel déployer une instance. Un nouveau coût énergétique à vide, CEVij, fonction du type de ressource et de l’instance courante, est alors notifié de l’ordonnanceur ORD à l’entité cliente CE au cours de la sous-étape F42. En outre, un nouveau coût énergétique à vide sommé, CEVj, fonction uniquement de l’instance courante, est déterminé en sommant les CEVij précédemment obtenus pour l’ensemble des types de ressource.

[0184] Au cours de la sous-étape F431 , l’ordonnanceur ORD notifie le nouveau coût énergétique à vide sommé CEVj à un serveur informatique SERV qui fait office de dispositif d’hébergement N. En outre, au cours de la sous-étape F432, l’ordonnanceur ORD notifie ce nouveau coût énergétique à vide sommé CEVj à une machine virtuelle VM qui fait office d’instance courante INS. Au cours de la sous- étape F433, l’entité cliente CE notifie le nouveau coût énergétique à vide sommé CEVj à un gestionnaire d’équipement réseau EM.

[0185] Au cours de la sous-étape F441 , le serveur informatique SERV notifie le nouveau coût énergétique à vide sommé CEVj reçu lors de la sous-étape F431 à l’équilibreur de charge LB3. Dans ce cas, la notification émise comprend typiquement un identifiant d’interface réseau relatif à l’instance de la fonction virtuelle, par exemple l’adresse MAC de l’interface de l’instance associée à son adresse IP.

[0186] Au cours de la sous-étape F442, la machine virtuelle VM notifie le nouveau coût énergétique à vide sommé CEVj reçu lors de la sous-étape F432 à l’équilibreur de charge LB2. Dans ce cas, la machine virtuelle implémente elle-même un routeur, et la notification émise comprend typiquement une adresse IP remplaçant l’adresse MAC que comprend la notification émise lors de la sous-étape F441. Ainsi, il est possible d’atteindre l’adresse IP via le routeur implémenté.

[0187] Dans une variante, lors de la sous-étape F444, le gestionnaire d’équipement réseau EM notifie le nouveau coût énergétique à vide sommé CEVj reçu lors de la sous-étape F433 à la machine virtuelle VM, qui la notifie lors de la sous-étape F442 décrite ci-dessus à l’équilibreur de charge LB2.

[0188] Au cours de la sous-étape F443, le gestionnaire d’équipement réseau EM notifie le nouveau coût énergétique à vide sommé CEVj reçu lors de la sous-étape F433 à l’équilibreur de charge LB1. Dans ce cas, la notification émise comprend typiquement un identifiant d’instance de fonction virtuelle, par exemple l’identifiant échangé entre l’ordonnanceur ORD et l’entité cliente CE lors de sa création.

[0189] Les notifications décrites précédemment sont, de préférence, des messages comprenant les coûts énergétiques à vide, sommés ou non, qui peuvent avoir préalablement été enregistrés par l’ordonnanceur ORD sur l’une ou l’autre des instances.

[0190] Ceci permet d’informer le répartiteur de trafic REP, ou tout autre dispositif configuré pour répartir la charge de trafic, de l’efficacité énergétique de chaque instance d’une fonction virtuelle. [0191] Dans une réalisation, une mise à jour de coefficients de pondération pour répartir une consommation de ressources peut être mise en œuvre en cascade.

[0192] Une telle mise en œuvre en cascade est préférée lorsque l’instance de fonction virtuelle correspond à un conteneur (ou « pod », en anglais) instancié sur un nœud virtuel de l’infrastructure en réseau R, par exemple un nœud de type Kubernetes, qui est lui-même instancié dans une machine virtuelle VM hébergée par un serveur informatique.

[0193] Cette mise en œuvre en cascade prévoit de mettre en œuvre deux sous- étapes F42 successives, comprenant une notification du coût énergétique à vide pour chaque type de ressource de chaque instance conformément aux réalisations précédentes pour lesquelles un dispositif d’hébergement, ici un nœud, est sélectionné en vue de déployer l’instance. Suite à cette double notification, la cascade prévoit de notifier une fois le coût énergétique à vide de chaque instance conformément aux réalisations précédentes pour lesquelles le coût énergétique à vide est mis à jour.

[0194] Pour ce faire, un conteneur de moteur d’orchestration d’un cluster Kubernetes peut être configuré pour calculer un nouveau coût énergétique à vide pour chaque type de ressource qu’il peut attribuer à un conteneur. De préférence, ceci est fait en prenant en compte le coût énergétique à vide CEVij reçu par celui-ci en provenance du gestionnaire de virtualisation VIM jouant le rôle d’ordonnanceur ORD, pour chaque type de ressource disponible sur la machine virtuelle VM. Comme décrit précédemment, ce coût énergétique à vide CEVij est fonction du type de ressource et de l’instance courante, et la machine virtuelle VM héberge le nœud sélectionné pour déployer le conteneur.

[0195] En outre, et plutôt que le coût énergétique à vide CEVij, il peut être pris en compte un coût énergétique à vide modifié CEVik, égal au coût énergétique à vide CEVij multiplié par la quantité de ressource « Oik » de ce type réservé par le conteneur et divisé par la quantité totale de ressources réservées par l’ensemble des conteneurs présents sur le nœud.

[0196] Si un nœud supplémentaire doit être activé dans une nouvelle machine virtuelle VM2, l’ordonnanceur ORD requiert la création de cette nouvelle machine virtuelle VM2 sur un serveur informatique déjà activé de l’infrastructure en réseau R. Le gestionnaire de virtualisation VIM peut, dans ce cas, sélectionner le serveur informatique sur lequel placer la nouvelle machine virtuelle VM2.

[0197] Il est maintenant fait référence à la figure 7, qui représente sous forme d’organigramme, des étapes G1 à G5 d’un procédé de répartition d’une consommation de ressources selon une réalisation simplifiée mise en œuvre par un ordonnanceur ORD.

[0198] De préférence, cette réalisation simplifiée peut être implémentée au moyen de logiciels ou de systèmes d’orchestration tels qu’OpenStack et Kubernetes.

[0199] Dans cette réalisation simplifiée, le procédé de répartition comprend une première étape G1 qui inclut une sélection d’un dispositif d’hébergement sur lequel déployer une instance de fonction virtuelle. G1 est par exemple mise en œuvre par l’ordonnanceur ORD, qui sélectionne un dispositif d’hébergement dont il a la responsabilité.

[0200] Cette sélection comprend un calcul d’un coefficient de pondération en fonction d’une instance courante d’une fonction virtuelle et d’au moins un type de ressource consommable par cette instance courante.

[0201] Pour ce faire, l’ordonnanceur ORD comprend une première base de données R1 comprenant des valeurs de quantités de ressources pouvant être allouées à un ensemble de dispositifs d’hébergement gérés par l’ordonnanceur ORD. De préférence, R1 comprend une première table M1 d’éléments, chaque élément de M1 correspondant à un dispositif d’hébergement donné et à un type de ressource donné.

[0202] Sur la base de cette première base de données, la création ou le déploiement d’une instance peut être requis selon un mécanisme prédéfini, par exemple en identifiant quel dispositif d’hébergement, parmi une pluralité, présente le coefficient de pondération minimum. Ce minimum peut être identifié en un instant donné, pour une instance donnée et pour un type de ressource donné. Ce mécanisme peut, en outre, tenir compte de règles d’affinité ou d’anti-affinité imposant des contraintes sur le ou les dispositifs d’hébergement à sélectionner. [0203] En outre, pour mettre en œuvre l’étape G1 , l’ordonnanceur ORD dispose aussi d’une deuxième base de données R2 comprenant des valeurs de quantités de ressources pouvant être allouées à un ensemble de dispositifs d’hébergement gérés par l’ordonnanceur ORD. R2 comprend une deuxième table M2 d’éléments, chaque élément de M2 correspondant non seulement à un dispositif d’hébergement donné et à un type de ressource donné, mais aussi à une instance donnée de fonction virtuelle et/ou à un identifiant donné, par exemple un identifiant d’un dispositif tiers configuré pour requérir la création d’une instance dans l’infrastructure en réseau R. Ceci permet de tracer les ressources déjà allouées à une ou plusieurs instances données.

[0204] Lorsque l’ordonnanceur ORD dispose des bases de données R1 et R2, l’étape G2 peut comprendre un contrôle d’un ou de plusieurs dispositifs d’hébergement dans l’infrastructure en réseau R, ce contrôle mettant en œuvre une vérification, sur la base des tables M1 et M2, de la quantité de ressources rendue disponible par ce ou ces dispositifs d’hébergement, et si cette quantité de ressources est suffisante ou non pour héberger une instance.

[0205] Lors de l’étape G1 de sélection, l’ordonnanceur ORD détermine un coefficient de pondération, en particulier un coût énergétique à vide, d’une instance courante VFj. Cette détermination est réalisée pour tout dispositif d’hébergement Nk de l’infrastructure en réseau R capable d’héberger l’instance.

[0206] Pour ce faire, et pour chaque instance VFj, l’ordonnanceur ORD dispose d’une table MCEV de coûts énergétiques à vide « CEVki » pour chaque type de ressource Ti et pour chaque dispositif d’hébergement Nk. La table MCEV peut être obtenue à partir des tables M1 et M2, ce qui permet de tenir compte à la fois des ressources réservées par l’instance VFj et de toutes les instances déployées sur le dispositif d’hébergement Nk. La sélection se fait ensuite en déterminant le dispositif d’hébergement correspondant à l’élément le plus petit de la table MCEV.

[0207] L’instance VFj est ensuite déployée par l’ordonnanceur ORD, ou par tout autre dispositif tiers, sur le dispositif d’hébergement sélectionné Nk.

[0208] Suite au déploiement de l’instance VFj par l’ordonnanceur ORD, par exemple pour le compte d’un client donné, l’ordonnanceur ORD met en œuvre une étape G2 comprenant une mise à jour de la table MCEV de coûts énergétiques à vide pour chaque type de ressource Ti et pour chaque dispositif d’hébergement Nk. Pour ce faire, l’ordonnanceur ORD peut générer une nouvelle table contenant le coût énergétique à vide des instances relatif à chaque type de ressource, en fonction du client, de l’instance, du dispositif d’hébergement et du type de ressource.

[0209] L’étape G2 peut comprendre, en outre, une mise à jour, pour chaque type de ressource Ti, le coût énergétique à vide des autres instances déployées sur le même dispositif d’hébergement.

[0210] Suite à l’étape G2, l’ordonnanceur ORD peut ensuite mettre en œuvre une étape G3 comprenant une lecture du coût énergétique à vide d’une instance.

[0211] Lors de l’étape G3, chaque instance détermine le coût énergétique à vide qui lui correspond en questionnant l’ordonnanceur ORD dont elle dépend, c’est-à- dire en lisant les éléments de la table MCEVM des coûts énergétiques à vide disponible sur l’ordonnanceur ORD. Pour effectuer cette détermination, il suffit par exemple à une instance courante VFj déployée de fournir à l’ordonnanceur ORD un premier identifiant, par exemple « VFj », et éventuellement, un deuxième identifiant d’un dispositif tiers d’un client. Ce deuxième identifiant permet d’effectuer une authentification, et donc d’augmenter la sécurité du procédé de répartition.

[0212] Lors de l’étape G3, l’ordonnanceur ORD détermine en outre le coût énergétique à vide total de l’instance en additionnant la contribution de chaque type de ressource relative à l’instance. En outre, l’ordonnanceur ORD transmet ce coût énergétique à vide total à l’instance.

[0213] Suite à l’étape G3 permettant une consultation du coût énergétique à vide (total) d’une instance, l’ordonnanceur ORD met en œuvre une étape G4 d’émission du coût énergétique à vide à un équilibreur de charge, par exemple, à l’un des équilibreurs de charge LB1 , LB2 et LB3 du répartiteur de trafic REP.

[0214] Ainsi, sur requête de l’un de ces équilibreurs de charge à l’intention d’une instance courante, ladite instance courante peut lui communiquer une information comprenant son état de fonctionnement, son coût énergétique à vide initial ou son coût énergétique à vide mis à jour au cours de l’une des étapes précédentes. [0215] Sur réception de cette information par l’équilibreur de charge, celui-ci met en œuvre un partage des ressources, par exemple de sorte que le trafic correspondant soit réparti en priorité sur les instances ayant le coût énergétique à vide le plus faible.

[0216] Ainsi, ce partage des ressources permet de prendre en compte le coût énergétique à vide en tant qu’élément de pondération de la répartition de charge.

[0217] Suite à l’étape G4 permettant un transfert d’une information de coût énergétique à vide à un équilibreur de charge, l’ordonnanceur ORD met en œuvre une étape G5 de lecture de coût énergétique à vide correspondant à des ressources de dispositifs d’hébergement gérés par l’ordonnanceur ORD.

[0218] Ainsi, lorsque l’ordonnanceur ORD a sélectionné un dispositif d’hébergement sur lequel déployer une instance comme c’est le cas lors de l’étape G1 , il met à jour la table MCEV qui donne, pour chacun des dispositifs d’hébergement, le coût énergétique à vide relatif à chaque type de ressource.

[0219] Ceci peut se faire par exemple en questionnant un ordonnanceur superviseur, par exemple un ordonnanceur serveur, dont il est le client.

[0220] A cet effet, l’ordonnanceur ORD client indique à l’ordonnanceur serveur un identifiant de l’instance courante relatif à chaque dispositif d’hébergement concerné et éventuellement, pour des raisons de sécurité, un ou plusieurs identifiants d’authentification de client.

[0221] L’ordonnanceur serveur transmet alors à l’ordonnanceur ORD, pour chaque type de ressource, le coût énergétique à vide de chaque instance dont il a la charge en tant que client.

[0222] La figure 8 représente un bloc-diagramme schématique d'un circuit de traitement informatique selon un exemple de mise en œuvre.

[0223] Selon un exemple, ledit circuit de traitement informatique est un processeur.

[0224] En particulier, ce circuit de traitement informatique est un système sur puce 1000. Par exemple, le système sur puce 1000 est adapté pour être intégré à un ordonnanceur ORD prévu pour être connecté à une infrastructure en réseau R, et est configuré pour mettre en œuvre un procédé de répartition de ressources selon l’une ou l’autre des réalisations décrites.

[0225] Le système sur puce 1000 comporte un bus de communication connecté, par exemple, à une unité centrale de traitement 1010, tel qu'un processeur ou un microprocesseur, et notée CPU.

[0226] Le système sur puce 1000 comporte aussi une mémoire à accès aléatoire 1020, notée RAM, pour mémoriser le code exécutable du procédé de répartition des ressources ainsi que les registres adaptés à enregistrer, mettre à jour, partager et propager des coefficients de pondération tels que des coûts énergétiques à vide. Pour la mise en œuvre du procédé selon des réalisations décrites précédemment, la capacité de mémoire du système sur puce 1000 peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple.

[0227] En outre, le système sur puce 1000 comporte une mémoire morte 1030, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des réalisations précédemment décrites, ainsi qu’une interface réseau 1040 qui est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmises ou reçues.

[0228] L'interface réseau 1040 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil).

[0229] Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur ou le microprocesseur 1010.

[0230] Par ailleurs, le système sur puce 1000 comporte une interface utilisateur 1050 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur, et un support de stockage optionnel 1060 noté HD.

[0231] Le système sur puce 1000 comporte en outre un module d’entrée-sortie 1070, noté IO, pour la réception, l'envoi de données depuis ou vers des périphériques externes tels que disque dur, support de stockage amovible ou autres. [0232] En particulier, le module d’entrée-sortie 1070 permet la réception et l’envoi de données depuis un dispositif tiers tel que, notamment, une entité client CE, un dispositif d’hébergement, une fonction virtuelle, une instance de fonction virtuelle, un répartiteur de trafic REP ou encore un autre ordonnanceur configuré pour être connecté à une autre infrastructure en réseau.

[0233] Dans un exemple présenté ici, le code exécutable peut être stocké dans une mémoire morte 1030, sur le support de stockage 1060 ou sur un support amovible numérique tel que par exemple un disque.

[0234] Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 1040, afin d'être stocké dans le support de stockage 1060, avant d'être exécuté.

[0235] L'unité centrale de traitement 1010 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 1010 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 1020, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple.

[0236] Dans l’exemple présenté ici, le système sur puce 1000 est un appareil programmable qui utilise un logiciel. Toutefois, à titre subsidiaire, la présente description peut être mise en œuvre dans n’importe quel type de matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).