WO2025003099A1 - Procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service - Google Patents

Procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service Download PDF

Info

Publication number
WO2025003099A1
WO2025003099A1 PCT/EP2024/067746 EP2024067746W WO2025003099A1 WO 2025003099 A1 WO2025003099 A1 WO 2025003099A1 EP 2024067746 W EP2024067746 W EP 2024067746W WO 2025003099 A1 WO2025003099 A1 WO 2025003099A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtualization
service load
units
service
unit
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.)
Ceased
Application number
PCT/EP2024/067746
Other languages
English (en)
Inventor
Benoît LEMOINE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to CN202480043455.3A priority Critical patent/CN121444073A/zh
Priority to EP24736017.5A priority patent/EP4736004A1/fr
Publication of WO2025003099A1 publication Critical patent/WO2025003099A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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]
    • G06F9/5094—Allocation of resources, e.g. of the central processing unit [CPU] where the allocation takes into account power or heat criteria

Definitions

  • Title of the invention Method for adapting the sizing of a virtualization infrastructure to a service load.
  • the invention lies in the field of load distribution over a set of computing resources. More particularly, the present invention relates to horizontal scaling mechanisms, according to which a number of resources deployed for the implementation of a service is automatically adapted according to the service load to be absorbed.
  • a Kubernetes architecture also integrates various load distribution mechanisms, including a mechanism known as “Horizontal Pod Auto scaling”, which makes it possible to automatically adapt the number of virtualization units installed on all of the virtualization nodes according to a current load level associated with the service to be implemented, i.e. a current load level that must be able to be absorbed in order to guarantee satisfactory quality of the service provided.
  • a current load level associated with the service to be implemented
  • scale out a greater number of virtualization units is deployed (in an operation known as “scale out”).
  • scale in virtualization units that have become unnecessary are removed (in an operation called "scale in"), for example to make them available for the implementation of another service, but also for energy saving considerations.
  • said operating clock frequency is used to normalize a CPU processing capacity to be reserved for a virtualization unit within said target virtualization node, by applying a normalization factor.
  • said normalization factor is defined by a ratio between said operating clock frequency and a predefined reference clock frequency, common to all the virtualization nodes of said plurality.
  • the present technique also relates to a system for adapting the dimensioning of a virtualization infrastructure to a service load, said virtualization infrastructure implementing an N:B protection scheme in which for N virtualization units absorbing said service load in a nominal mode, there are B backup virtualization units making it possible to guarantee absorption of said service load in the event of failure of at most B virtualization units.
  • a scaling module configured to deliver a decision to add or remove a virtualization unit to a set of virtualization units instantiated for the implementation of said service, said decision being made according to:
  • Such a system further comprises, in various particular embodiments, means enabling it to implement the characteristics of the method previously described in any one of its embodiments, with the same advantages.
  • the proposed technique also relates to a computer program product downloadable from a communication network and/or stored on a computer-readable medium and/or executable by a microprocessor, comprising program code instructions for executing a method of adapting the dimensioning of a virtualization infrastructure to a service load, as described above in any of its embodiments, when executed on a computer.
  • the proposed technique also aims at a recording medium readable by a computer. diner on which is recorded a computer program comprising program code instructions for executing the steps of the method as described above, in any of its embodiments.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program contained therein is remotely executable.
  • the program according to the invention may in particular be downloaded over a network, for example the Internet.
  • FIG 1 schematically presents the different modules of a Kubemetes architecture, and their inputs-outputs, according to the prior art
  • FIG.2 illustrates an example of the effects of implementing a horizontal scaling mechanism within a Kubemetes architecture without a protection scheme, according to the prior art
  • FIG.3 illustrates an example of the effects of implementing a horizontal scaling mechanism within a Kubemetes architecture implementing a protection scheme, according to the prior art
  • FIG.5 illustrates an example of undesirable hysteresis phenomena associated with prior art solutions in the event of a large empty load, which the present technique aims to eliminate;
  • FIG.6 illustrates an example of the effects of implementing a horizontal scaling mechanism within a modified Kubemetes architecture according to the present technique
  • FIG.7 presents a sequence diagram illustrating the selection mechanisms of a virtualization node and reservation of processing capacity for a virtualization unit, as conventionally implemented within a Kubemetes architecture according to the prior art;
  • FIG.8 presents a sequence diagram illustrating the mechanisms for selecting a virtualization node and reserving processing capacity for a virtualization unit, as implemented in a particular embodiment of the proposed technique
  • FIG.10 describes a simplified architecture of an electronic system for implementing the proposed technique, in a particular embodiment.
  • the present technique relates to a method for adapting the sizing of a virtualization infrastructure to a service load.
  • the proposed technique relates more particularly to improvements to the classic horizontal automatic scaling mechanism (“Horizontal Pod Autoscaling”) of a Kubemetes architecture implementing an N:B protection scheme, aimed at improving its energy performance.
  • Horizontal Pod Autoscaling classic horizontal automatic scaling mechanism
  • the number B of backup virtualization units provided in the protection scheme implemented is provided as input to the scaling module.
  • the probe module is modified so that it no longer measures a CPU load of the virtualization units, but a service load PL p reached at the level of the virtualization units.
  • a new reference threshold value PL max is provided at the input of the scaling module, corresponding to a maximum service load tolerated per virtualization unit, this new threshold value PL max replacing the threshold value “targets.requests” - i.e. the percentage of the CPU load reserved per Pod - used in the classic Kubernetes architecture of the prior art.
  • the maximum admissible service load PL max is for example automatically estimated based on a comparison between a current service load reached at the level of one or more virtualization units and a CPU load resulting from said current service load on the virtualization unit(s) considered.
  • the maximum admissible service load P nax is for example automatically estimated based on a comparison between a current service load reached at the level of one or more virtualization units and at least one predetermined quality of service parameter.
  • a predetermined quality of service parameter corresponds for example to a response time to the service, representative of a processing time of a service request on the virtualization unit(s) considered.
  • the new formula for calculating the trigger threshold of a scaling operation consists in calculating the sum of the service loads of each virtualization unit and dividing it by the maximum service load PL max accepted per virtualization unit, rounding the result obtained to the next higher integer, and adding to it the quantity B of virtualization units provided in the targeted protection scheme, according to the following formula:
  • idle load also referred to as "noload” throughout the figures
  • noload we mean here a more or less significant residual CPU load on the virtualization units, potentially existing even when the service load is zero, i.e. even when the virtualization units are not processing any data related to the service in question.
  • the triggers of scale out and scale in at the same level eg a scale out in which the number of replicas goes from 2 to 3 virtualization units, or a scale in out in which the number of replicas goes from 3 to 2 virtualization units
  • the same SL Service load values ie at the same abscissa value, at the integer level
  • an N:B protection scheme makes it possible to support the failure of B virtualization units among the N virtualization units intended to support the nominal service load, in a situation where all the virtualization units can be considered equivalent. This is generally the case when a virtualization infrastructure is deployed on new computer servers, in most cases identical for cost reasons (it is generally less expensive to purchase identical equipment in large quantities than to purchase equipment with varied technical characteristics in smaller quantities).
  • said technical characteristic is the operating clock frequency of said virtualization nodes, potentially different from one node to another.
  • each virtualization node when it is enrolled within a cluster of virtualization nodes, each virtualization node (for example the virtualization node i “Node_i” illustrated in [Fig. 7]) provides an orchestration module Mod_ORC (or “scheduler”) with its total CPU processing capacity “total_CPU_i” (note that for reasons of simplification, the orchestration module, although existing, has not been shown in FIGS. 1 and 4 previously described, its operation and its interactions with the other modules not being modified in the embodiments previously described). Before any reservation of processing time on the node i, this total CPU processing capacity “total_CPU_i” corresponds to an available processing capacity “ Available _CPU_i » on the node.
  • Mod_ORC or “scheduler”
  • the installation module Mod_INS determines the required processing capacity
  • the orchestration module Mod_ORC transmits to the installation module Mod_INS, in a step 75, identification information of the chosen virtualization node. On the basis of this information, in a step 76, the installation module Mod_INS instantiates the virtualization unit on the chosen virtualization node, and configures it so that the “requests” CPU load portion always remains available for this virtualization unit.
  • the nominal operating frequencies are generally different, a node N ; working for example at the frequency Clk_i, and a node Nj at the frequency Clk J.
  • the number of cycles per unit of time, and therefore the number of reservable cycles per unit of time are also different between a virtualization unit installed on the node Ni and a virtualization unit installed on the node Nj, and therefore the maximum service loads PLmax_i and PLmax _J accepted respectively by each of these two virtualization units are also different, which poses a problem for defining the parameter PLmax to be provided as input to the scaling module (this parameter PLmax cannot be equal to both PLmax_i and PL max _J) for the implementation of the first level of improvement described in relation to figures 4 to 6.
  • FIG.8 takes up the nature and order of the steps already described in relation to [Fig.7], which remain similar, but it is proposed in some of these steps to involve a normalization factor.
  • a predetermined “Clk_ref” parameter is defined at the orchestration module level, in order to serve as a reference clock frequency for comparing the nominal clock frequencies of the different virtualization nodes.
  • each virtualization node (e.g. virtualization node i “Node_i” shown in [Fig.8]) provides the orchestration module Mod_ORC with its nominal operating clock frequency (“Clk_i” for node i), in addition to its total CPU processing capacity (“total_CPU_i” for node i). Before any processing time reservation on node i, this total CPU processing capacity “total_CPU_i” corresponds to an available processing capacity “Available _CPU _i” on the node.
  • the installation module Mod_INS determines the processing capacity required for this virtualization unit (possibly by calculating the sum of the capacities required for each of the containers that compose it), then asks the orchestration module Mod_ORC, in a step 83, to reserve these resources in the best possible node.
  • the orchestration module Mod_ORC performs filtering of the nodes by comparing not the required processing capacity "requests" to the available processing capacity at the within the different virtualization nodes (for example "Available _CPU_i” for node i), but at a normalized available processing capacity based on a ratio between the operating frequency of the node considered and the reference clock frequency, i.e. "available _CPU _i * (Clk_i / Clk_rej)" for node i.
  • the orchestration module Mod_ORC then performs a ranking ("scoring") of the nodes thus preselected according to multiple criteria, such as the load rate for example, which allows it to determine the best node for the instantiation of the new virtualization unit.
  • the orchestration module Mod_ORC reserves in the chosen virtualization node, in a step 84, a quantity “requests / (Clk_i/Clk_ref)” of CPU required for this virtualization unit (in the example of [Fig. 8], it is considered that node i is thus chosen, and the orchestration module Mod_ORC therefore removes the quantity “requests / (Clk_i/Clk_ref)” from the processing capacity available for this node).
  • the orchestration module Mod_ORC transmits to the installation module Mod_INS, in a step 85 during step 75 of [Fig. 7], identification information of the chosen virtualization node, but also the value of the corrective factor “(Clk_i/Clk_ref)” to be applied in the following step.
  • the installation module Mod_INS instantiates the virtualization unit on the chosen virtualization node, and configures it so that the CPU load portion “requests / (Clk_i/Clk_rej)” always remains available for this virtualization unit.
  • a normalization of the operations performed is carried out by applying a corrective factor (Clk_i/Clk_ref), as highlighted in bold in [Fig.8].
  • the present technique also relates to a system for adapting the sizing of a virtualization infrastructure to a service load, said virtualization infrastructure implementing an N:B protection scheme in which for N virtualization units absorbing said service load in a nominal mode, there are B backup virtualization units making it possible to guarantee absorption of said service load in the event of failure of at most B virtualization units.
  • a system comprises means enabling it to carry out the method previously described in any one of its embodiments. More particularly, such a system according to the present technique comprises a scaling module configured to deliver a decision to add or remove a virtualization unit to a set of virtualization units instantiated for the implementation of said service, said decision being made as a function of:
  • such a system further comprises, in various particular embodiments, in addition to the scaling module, various other modules (e.g. probe module, installation module, orchestration module, load distribution module) configured to allow the implementation of the characteristics of the method previously described in any of its embodiments, with the same advantages.
  • various other modules e.g. probe module, installation module, orchestration module, load distribution module
  • FIG. 10 schematically and simplifiedly represents certain structural elements of such a system, in a particular embodiment.
  • This system comprises for example a memory 11 consisting of a buffer memory M, a processing unit 12, equipped for example with a microprocessor pP, and controlled by the computer program Pg 13, implementing steps of the method for adapting the sizing of a virtualization infrastructure to a service load, according to at least one embodiment of the invention.
  • the code instructions of the computer program 13 are loaded into the buffer memory before being executed by the processor of the processing unit 12.
  • the processing unit 12 receives for example as input E information stored in the memory 11 (eg values MINPODS, MAXPODS, a number B of backup virtualization units, a maximum service load PLmax authorized per virtualization unit, etc.), as well as information coming from a probe module, representative of a total service load reached SL measured by the probe module.
  • the microprocessor of the processing unit 12 then carries out the steps of the method for adapting the dimensioning of the virtualization infrastructure, according to the instructions of the computer program 13. More particularly, these operations deliver as output S a decision to add or remove a virtualization unit to the set of virtualization units instantiated for the implementation of the service, at an optimal time to maximize the energy performance of the Kubemetes architecture.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

L'invention se rapporte à un procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d'au plus B unités de virtualisation. Selon ce procédé, une décision d'ajouter ou de retirer une unité de virtualisation (UV) à un ensemble (set) d'unités de virtualisation instanciées pour la mise en œuvre dudit service est effectuée en fonction : - du nombre B d'unité de virtualisation de sauvegarde défini dans ledit schéma de protection; - d'une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation (UV) dudit ensemble (set).

Description

Description
Titre de l’invention : Procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service.
Domaine technique
[0001] L’invention se situe dans le domaine de la répartition de charge sur un ensemble de ressources informatiques. Plus particulièrement la présente invention concerne les mécanismes de mise à l’échelle horizontale, selon lesquels un nombre de ressources déployées pour la mise en œuvre d’un service est adapté automatiquement en fonction de la charge de service à absorber.
Art antérieur
[0002] De nombreux réseaux de communication utilisent des fonctions virtualisées ins- tanciées sur des nœuds de virtualisation hébergés dans des machines virtuelles ou dans des serveurs regroupés en grappes, ou « clusters » au sein de centres de données. Dans la suite du document, il est fait mention de nœuds de virtualisation hébergés dans des serveurs mais il est entendu que l’enseignement du présent document s’applique également au cas de nœuds de virtualisation hébergés dans des machines virtuelles.
[0003] Un exemple de gestion d’instanciation de fonctions virtualisées est connu sous l’appellation « Kubernetes ». Une architecture Kubernetes comprend au moins une grappe de nœuds de virtualisation. Une telle grappe de nœuds de virtualisation comprend au moins un premier nœud dit nœud de gestion, ou « Kubernetes master node », et une pluralité de nœuds de calcul, ou « Kubernetes worker node » destinés à instancier des fonctions virtualisées.
[0004] Le nœud de gestion comprend, entre autres, une base de données dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs.
[0005] Un nœud de calcul comprend une pluralité d’unités de virtualisation ou « pods ». Chaque unité de virtualisation est dotée de ressources permettant l’exécution d’une ou plusieurs tâches. Une tâche, lorsqu’elle est exécutée, contribue à la mise en œuvre d’un service ou d’une fonction virtualisée.
[0006] Une architecture Kubernetes intègre par ailleurs divers mécanismes de répartition de charge, dont un mécanisme connu sous le nom de « Horizontal Pod Auto scaling », qui permet d’adapter automatiquement le nombre d’unités de virtualisation installées sur l’ensemble des nœuds de virtualisation en fonction d’un niveau de charge courant associé au service à mettre en œuvre, c’est-à-dire un niveau de charge courant qu’il convient d’être en capacité d’absorber afin de garantir une qualité satisfaisante du service fourni. Ainsi, en réponse à une augmentation de la charge, un nombre plus important d’unités de virtualisation est déployé (dans une opération dite de « scale out »). À l’inverse, en réponse à une diminution de la charge, des unités de virtualisation devenues inutiles sont retirées (dans une opération dite de « scale in »), afin par exemple de les rendre disponibles pour la mise en œuvre d’un autre service, mais également pour des considérations d’économie énergétique.
[0007] On décrit de manière simplifiée, en relation avec la [Fig.l], une architecture classique Kubemetes, permettant la mise en œuvre d’un tel mécanisme.
[0008] Comme décrit précédemment, dans une telle architecture, un nombre R (dit
« Replicas ») d’unités de virtualisation UV est déployé sur un ou plusieurs nœuds de virtualisation, pour la mise en œuvre d’un service.
[0009] Un module sonde Mod_S mesure un usage CPU moyen (i.e. un usage CPU, ou usage processeur, des serveurs informatiques sur lesquelles elles sont déployées) par unité de virtualisation, sur l’ensemble set des unités de virtualisation UV instanciées.
[0010] Au niveau d’un module de mise à l’échelle automatique Mod_ME (« Autoscaler ») cet usage CPU moyen d’une unité de virtualisation est comparé à une valeur seuil exprimée sous la forme d’un ratio de 0% à 100% (« targets ») d’une valeur CPU nominale garantie pour chaque unité de virtualisation (« requests »). Cette valeur CPU nominale garantie « requests » a été réservée au moment de l’installation de l’unité de virtualisation sur son nœud de virtualisation.
[0011] Le résultat de cette comparaison est utilisé pour adapter le nombre R de replicas instanciés. Par exemple, si l’usage CPU moyen par unité de virtualisation dépasse la valeur seuil targets, requests, une décision est transmise à un module d’installation Mod_INS d’augmenter le nombre R de replicas, c’est-à-dire d’augmenter le nombre d’unités de virtualisation UV instanciées pour la mise en œuvre du service. Le nombre d’unités de virtualisation que le module de mise à l’échelle Mod_ME peut décider de déployer est toutefois borné entre une limite basse « MINPODS » et une limite haute « MAXPODS » prédéfinies.
[0012] Un module de répartition de charge Mod_LB répartit la charge de service SL sur l’ensemble des R unités de virtualisation disponibles. A titre illustratif et non limitatif, cette charge de service SL peut être définie comme un nombre de requêtes de service par seconde, dans ce cas, le module de répartition de charge Mod_LB relaie une portion I //? des requêtes de service sur chacune des R unités de virtualisation. Dans un autre exemple, la charge de service peut aussi être définie comme un débit de paquets Internet devant être émis par les unités de virtualisation, dans ce cas, le module de répartition de charge Mod_LB relaie les requêtes de service sur chacune des R unités de virtualisation de sorte que le débit de paquets Internet émis par chacune des unités de virtualisation se rapproche du ratio I //? du débit total de paquets Internet émis par l’ensemble des unités de virtualisation.
[0013] Le processus de dimensionnement mis en œuvre (i.e. l’adaptation du nombre de réplicas) est ainsi régi par une règle pouvant être formalisée sous la forme de l’équation suivante :
Figure imgf000005_0001
[0016] - R(k) le nombre d’unités de virtualisation instanciées à un instant k ;
[0017] - R(k+1 ) le nombre d’unités de virtualisation à instancier à un instant k + 7, postérieur audit instant k ;
[0018] - usagep l’usage CPU mesuré par le module sonde pour l’unité de virtualisation p entre l’instant k et l’instant k+ ,
[0019] - ceil la fonction d’arrondi à l’entier supérieur ;
[0020] - et les contraintes supplémentaires, non formalisées dans l’équation (1) mais mises en œuvre, selon lesquelles R(k+1 ) est automatiquement fixé à la valeur MINPODS si le résultat de l’équation (1) devient inférieur à MINPODS, et R(k+1 ) est automatiquement fixé à la valeur MAXPODS si le résultat de l’équation (1) devient supérieur à MAXPODS.
[0021] La [Fig.2] illustre sur un exemple les effets du mécanisme de mise à l’échelle précédemment décrit, dans une configuration dans laquelle targets est fixé à 100%, MINPODS à 1, et MAXPODS à 4. Comme MINPODS est fixé à 1, au minimum une unité de virtualisation est instanciée. Lorsque la charge de service (en abscisse) augmente et dépasse la charge maximale (seuil targets. requests, ici égal à requests') définie pour une unité de virtualisation (franchissement de l’abscisse de valeur 1), une nouvelle unité de virtualisation est instanciée (le nombre de réplica R passe de 1 à 2). Lorsque la charge de service augmente encore et dépasse la charge maximale définie pour deux unités de virtualisation (franchissement de l’abscisse de valeur 2), une nouvelle unité de virtualisation est instanciée (le nombre de réplica R passe de 2 à 3). De telles opérations de « scale out » peuvent être répétées pour adapter automatiquement le nombre d’unités de virtualisation instanciées à un niveau de charge croissant, jusqu’à ce que le nombre maximal d’unités de virtualisation défini par MAXPODS (ici quatre), soit atteint. À l’inverse, lorsque la charge de service diminue, à chaque franchissement à la baisse d’une unité en abscisse, le retrait d’une unité de virtualisation est mis en œuvre. De telles opération de « scale in » peuvent être répétées pour adapter automatiquement le nombre d’unités de virtualisation instanciées à un niveau de charge décroissant, jusqu’à ce que le nombre minimal d’unités de virtualisation défini par MINPODS (ici un), soit atteint.
[0022] La configuration illustrée en relation avec la [Fig.2] ne permet toutefois pas de pallier de manière rapide une éventuelle défaillance d’une unité de virtualisation. Par exemple, comme illustré sur cette [Fig.2] par la flèche D, en cas de défaillance d’une unité de virtualisation parmi trois unités de virtualisation en service, la charge de service est répartie sur les deux unités de virtualisation restantes encore fonctionnelles, mais la charge moyenne supportée par ces deux unités devient supérieure à la charge maximale qu’elles peuvent absorber (dépassement du seuil targets.requests en ordonnées), et la fourniture du service attendu n’est donc plus garantie (risque de ralentissement, de coupures, etc.), le système étant devenu sous-dimensionné du fait de la défaillance. Cette situation perdure le temps que Kubemetes met à réinstancier une unité de virtualisation alternative à l’unité défaillante. Plusieurs causes peuvent retarder l’instanciation d’une unité alternative. Le choix du nœud de virtualisation peut être par exemple retardé par manque de ressources sur les nœuds de virtualisation existants et la nécessité d’attendre l’installation d'un nouveau nœud de virtualisation. Le téléchargement de l’image de l’unité de virtualisation sur le nœud de virtualisation choisi pour l’héberger peut par exemple être également retardé à cause d’une surcharge du réseau, etc.
[0023] Une solution classique à ce problème consiste à adopter un schéma de protection selon lequel pour N unités de virtualisation nécessaires pour absorber une charge dans des conditions nominales (i.e. sans défaillance), on prévoit B unités de virtualisation supplémentaires (schéma de protection de type N:B) permettant de palier jusqu’à un nombre prédéterminé d’éventuelles défaillances sans que la qualité de service soit dégradée, et donc de manière transparente pour l’utilisateur. Les paramètres targets, MINPODS et MAXPODS sont alors adaptés en fonction du schéma de protection souhaité.
[0024] La [Fig.3] illustre ce mécanisme sur l’exemple d’un schéma de protection 4:1. Dans une telle configuration, MINPODS est fixé à 2 et targets à 50%, ce qui permet de garantir qu’au moins deux unités de virtualisation sont déployées, et qu’en cas de défaillance d’une unité de virtualisation dans la situation la moins favorable, c’est-à-dire lorsque deux unités de virtualisation seulement sont déployées, l’unité de virtualisation encore fonctionnelle reste en mesure d’absorber la totalité de la charge de service auparavant répartie sur les deux unités. MAXPODS est par ailleurs fixé à 5, afin d’obtenir une charge de service garantie correspondant la charge totale pouvant être absorbée par quatre unités de virtualisation dans des conditions nominales, et ceci même en cas de défaillance d’une unité de virtualisation.
[0025] Le mécanisme de protection précédemment décrit est donc efficace en ce qu’il permet d’éviter que le système se retrouve ponctuellement sous dimensionné par rapport à une charge à absorber, en cas de défaillance d’un nombre prédéterminé d’unités de virtualisation.
[0026] Une telle solution n’est cependant pas optimale sur le plan de l’efficacité énergétique. En effet, comme visible sur la [Fig.3], elle conduit à des surdimensionnements ponctuels du système, conséquences du fait que la valeur targets est fixée pour garantir le service dans le cas le plus défavorable, et qu’elle reste donc constante quel que soit le nombre d’unités de virtualisation déployées. Ainsi, on constate par exemple sur cette [Fig.3] que le passage de trois à quatre unités de virtualisation est réalisé de manière très précoce, alors qu’il aurait pu survenir plus tardivement, idéalement au niveau de l’abscisse de valeur 2, sans que cela remette en cause la capacité du système à garantir le service même en cas de défaillance d’une unité de virtualisation.
[0027] Autrement dit, bien qu’efficaces pour assurer une adaptation du nombre d’unités de virtualisation à déployer en fonction d’une évolution d’une charge de service, ainsi qu’une protection selon un schéma de protection prédéfini, les moments de déclenchement des opérations de « scale in » (retrait d’une unité de virtualisation en cas de baisse de charge) et de « scale out » (ajout d’une unité de virtualisation en cas de hausse de charge) ne sont clairement pas optimisés en termes de vue performance énergétique avec les solutions actuelles (les opérations de « scale out » étant déclenchées de manière trop précoce et les opérations de « scale in » de manière trop tardive, pour la quasi-totalité d’entre-elles).
[0028] D’un point de vue plus global, à l’heure où la réduction des émissions de gaz à effet de serre est devenue un enjeu capital pour lutter contre le réchauffement climatique à l’échelle planétaire, les mécanismes existants de dimensionnement automatique des systèmes informatiques en réponse à l’évolution d’une charge de service restent largement perfectibles sur les aspects d’économies de ressources, tant énergétiques que matérielles.
[0029] Par exemple lorsque d’anciens serveurs informatiques sont réutilisés comme nœuds de virtualisation à côté de serveurs informatiques plus récents, les performances hétérogènes ne permettent pas de garantir que les B unités de virtualisations réparties sur des serveurs informatiques de performance différente des de celle serveurs informatiques sur lesquels les A unités de virtualisation nominales sont hébergées puissent pallier la défaillance de B unités parmi les A unités de virtualisation nominales.
[0030] Fa présente invention a pour objet de résoudre tout ou partie des inconvénients précédemment cités.
Résumé de l’invention
[0031] Fa présente technique permet de proposer une solution visant à remédier à certains inconvénients de l’art antérieur. Selon un aspect, la présente technique se rapporte en effet à un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour A unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Selon le principe général de la technique proposée, une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre dudit service est effectuée en fonction :
[0032] - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ;
[0033] - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation dudit ensemble.
[0034] De cette manière, contrairement aux solutions de l’art antérieur, le déclenchement d’une décision d’ajouter ou de retirer une unité de virtualisation est optimisé en termes de performances énergétiques, en ce qu’il prend non seulement en compte le nombre B d’unités de virtualisation de sauvegarde prévus dans le cadre du schéma de protection visé, mais également en ce qu’il repose sur l’évaluation d’une charge de service plutôt que d’une charge CPU, i.e. sur une donnée complètement indépendante d’une charge CPU à vide résiduelle potentiellement présente au niveau des unités de virtualisation.
[0035] Dans un mode de réalisation particulier, ladite décision d’ajouter ou de retirer une unité de virtualisation est régie par la formule :
Figure imgf000008_0001
[0037] avec
[0038] - R(k) le nombre d’unités de virtualisation instanciées à un instant k ;
[0039] - R(k+1 ) le nombre d’unités de virtualisation à instancier à un instant k + 7, postérieur audit instant k ;
[0040] - PLp la charge de service atteinte au niveau d’une unité de virtualisation p dudit ensemble entre l’instant k et l’instant k+1, dite charge de service courante.
[0041] De cette manière, les déclenchements de scale out et de scale in à un même niveau - i.e. d’un nombre M à M+l unités de virtualisation lors d’une l’augmentation de la charge de service ou d’un nombre M+l à M unités de virtualisation lors d’une baisse de la charge de service - surviennent pour les mêmes valeurs de charge de Service SL, garantissant ainsi une efficacité énergétique optimale.
[0042] Dans un mode de réalisation particulier, ladite charge de service PLmax maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et une charge CPU résultante de ladite charge de service courante atteinte au niveau de ladite au moins une unité de virtua- lisation. De manière alternative, dans un autre mode de réalisation particulier, ladite charge de service PLmax maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et au moins un paramètre de qualité de service prédéterminé associé à ladite au moins une unité de virtualisation.
[0043] De cette manière, la technique proposée peut être mise en œuvre de manière simple et automatique, sans modifications majeures du module de mise à l’échelle d’une architecture Kubemetes, une charge de service pouvant être rapportée dans un format proche d’une charge CPU.
[0044] Selon une caractéristique particulière de ce mode de réalisation, ledit au moins un paramètre de qualité de service comprend un temps de réponse audit service, représentatif d’un temps de traitement d’une requête de service sur ladite au moins une unité de virtualisation.
[0045] Dans un mode de réalisation particulier, une sélection, parmi une pluralité de nœuds de virtualisation disponibles au sein de ladite infrastructure de virtualisation, d’un nœud de virtualisation cible au sein duquel une unité de virtualisation est ajoutée ou retirée en réponse à ladite décision tient compte d’au moins une caractéristique technique associée auxdits nœuds de virtualisation de ladite pluralité.
[0046] De cette manière, la présente technique peut être mise en œuvre même au sein d’architecture Kubernetes reposant sur la mise en œuvre de serveurs informatiques aux caractéristiques techniques hétérogènes, dans la mesure où ces caractéristiques sont prises en compte pour la sélection d’un nœud de virtualisation sur lequel ajouter ou retirer une unité de virtualisation lors de l’adaptation du dimensionnement de l’infrastructure de virtualisation à l’évolution d’une charge de service.
[0047] Dans un mode de réalisation particulier, ladite au moins une caractéristique technique comprend une fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité.
[0048] De cette manière, on dispose d’un moyen simple, par la connaissance de telles fréquences d’horloge, de comparer par unité de temps les capacités de traitement des différents nœuds de virtualisation disponibles pour l’ajout ou le retrait d’une unité de virtualisation.
[0049] Selon une caractéristique particulière, ladite fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité est communiquée à un module d’orchestration en charge de ladite sélection, dans une étape d’enrôlement dudit nœud de virtualisation auprès dudit module d’orchestration, en complément d’une capacité totale de traitement CPU associée audit nœud de virtualisation.
[0050] De cette manière, le module d’orchestration est à même de comparer les capacités de traitement des différents nœuds de virtualisation, même lorsque ceux-ci sont mis en œuvre sur des dispositifs électroniques aux caractéristiques techniques hétérogènes.
[0051] Dans un mode de réalisation particulier, ladite fréquence d’horloge de fonctionnement est utilisée pour normaliser une capacité de traitement CPU à réserver à une unité de virtualisation au sein dudit nœud de virtualisation cible, par application d’un facteur de normalisation. Selon une caractéristique particulière, ledit facteur de normalisation est défini par un ratio entre ladite fréquence d’horloge de fonctionnement et une fréquence d’horloge de référence prédéfinie, commune à l’ensemble des nœuds de virtualisation de ladite pluralité.
[0052] De cette manière, par l’utilisation d’un tel facteur de normalisation, la comparaison des capacités de traitement des différents nœuds de virtualisation et l’obtention de capacités de traitement normalisées sont encore simplifiées.
[0053] Selon un autre aspect, la présente technique se rapporte également à un système d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N :B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Selon la technique proposée, un tel système comprend un module de mise à l'échelle configuré pour délivrer une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre dudit service, ladite décision étant effectuée en fonction :
[0054] - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ;
[0055] - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation dudit ensemble.
[0056] Un tel système comprend par ailleurs, dans divers modes de réalisation particuliers, des moyens lui permettant de mettre en œuvre les caractéristiques du procédé précédemment décrits dans l’un quelconque de ses modes de réalisation, avec les mêmes avantages.
[0057] Selon un autre aspect, la technique proposée se rapporte également à un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour l’exécution d'un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, tel que décrit précédemment dans l’un quelconque de ses modes de réalisation, lorsqu’il est exécuté sur un ordinateur.
[0058] La technique proposée vise également un support d’enregistrement lisible par un or- dinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé tel que décrit précédemment, dans l’un quelconque de ses modes de réalisation.
[0059] Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. 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 une clé USB ou un disque dur.
[0060] D'autre part, un tel support d'enregistrement 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, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par exemple le réseau Internet.
[0061] Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
Figures
[0062] D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[0063] [Fig 1 présente de manière schématique les différents modules d’une architecture Ku- bemetes, et leurs entrées-sorties, selon l’art antérieur ;
[0064] [Fig.2] illustre un exemple des effets de la mise en œuvre d’un mécanisme de mise à l’échelle horizontale au sein d’une architecture Kubemetes sans schéma de protection, selon l’art antérieur ;
[0065] [[Fig.3] illustre un exemple des effets de la mise en œuvre d’un mécanisme de mise à l’échelle horizontale au sein d’une architecture Kubemetes implémentant un schéma de protection, selon l’art antérieur ;
[0066] [Fig.4] présente de manière schématique les différents modules d’une architecture
Kubemetes modifiée, et leurs entrées-sorties, dans un mode de réalisation particulier de la technique proposée ;
[0067] [Fig.5] illustre un exemple de phénomènes indésirables d’hystérésis associés aux solutions de l’art antérieur en cas de charge à vide importante, que la présente technique vise à supprimer ;
[0068] [Fig.6] illustre un exemple des effets de la mise en œuvre d’un mécanisme de mise à l’échelle horizontale au sein d’une architecture Kubemetes modifiée selon la présente technique ;
[0069] [Fig.7] présente un diagramme de séquence illustrant les mécanismes de sélection d’un nœud de virtualisation et de réservation de capacité de traitement pour une unité de virtualisation, tels que mis en œuvre de manière classique au sein d’une architecture Kubemetes selon l’art antérieur ;
[0070] [Fig.8] présente un diagramme de séquence illustrant les mécanismes de sélection d’un nœud de virtualisation et de réservation de capacité de traitement pour une unité de virtualisation, tels que mis en œuvre dans un mode de réalisation particulier de la technique proposée ;
[0071] [Fig.9] présente de manière schématique les différents modules d’une architecture
Kubemetes modifiée, et leurs entrées-sorties, dans un autre mode de réalisation particulier de la technique proposée ;
[0072] [Fig.10] décrit une architecture simplifiée d’un système électronique pour la mise en œuvre de la technique proposée, dans un mode de réalisation particulier.
Description détaillée de l’invention
[0073] La technique décrite ci-après permet de remédier à certains des inconvénients précités.
[0074] Sur toutes les figures du présent document, les éléments et étapes de même nature sont désignés par une même référence numérique.
[0075] Selon un premier aspect, la présente technique se rapporte à un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service. La technique proposée se rapporte plus particulièrement à des perfectionnements du mécanisme classique de mise à l’échelle automatique horizontale (« Horizontal Pod Autoscaling ») d’une architecture Kubemetes implémentant un schéma de protection N:B, visant à en améliorer la performance énergétique.
[0076] On présente de manière schématique, en relation avec la [Fig.4], une architecture Kubemetes modifiée selon la présente technique.
[0077] Par rapport à l’architecture Kubemetes classique tel que précédemment décrite en relation avec la [Fig.l], la présente technique repose dans son principe général sur une combinaison de deux modifications principales visant à optimiser le déclenchement, par un module de mise à l'échelle (« Autoscaler »), d’une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre d’un service. Ces modifications comprennent, au niveau dudit module de mise à l'échelle :
[0078] - d’une part la prise en compte du nombre B d’unités de virtualisation de sauvegarde prévues dans le schéma de protection mis en œuvre ;
[0079] - d’autre part la mise en œuvre d’une comparaison basée non plus sur une charge
CPU, mais sur une charge de service.
[0080] Plus particulièrement, la mise en œuvre de ces modifications nécessite plusieurs adaptations conjointes de l’architecture Kubernetes, illustrées sur la [Fig.4] dans un mode de réalisation particulier de la technique proposée et présentées ci-après.
[0081] Selon une première adaptation, le nombre B d’unités de virtualisation de sauvegarde prévues dans le schéma de protection mis en œuvre est fourni en entrée du module de mise à l’échelle.
[0082] Selon une deuxième adaptation, le module sonde est modifié afin qu’il mesure non plus une charge CPU des unités de virtualisation, mais une charge de service PLp atteinte au niveau des unités de virtualisation.
[0083] Selon une troisième adaptation, une nouvelle valeur seuil de référence PLmax est fournie en entrée du module de mise à l’échelle, correspondant une charge de service maximale tolérée par unité de virtualisation, cette nouvelle valeur de seuil PLmax se substituant à la valeur de seuil « targets.requests » - i.e. au pourcentage de la charge CPU réservée par Pod - utilisée dans l’architecture Kubernetes classique de l’art antérieur.
[0084] Selon une caractéristique particulière, la charge de service maximale admissible PL max est par exemple estimée automatiquement en fonction d’une comparaison entre une charge de service courante atteinte au niveau d’une ou plusieurs unités de virtualisation et une charge CPU résultante de ladite charge de service courante sur la ou les unités de virtualisation considérées.
[0085] Selon une autre caractéristique particulière, de manière alternative, la charge de service maximale admissible P nax est par exemple estimée automatiquement en fonction d’une comparaison entre une charge de service courante atteinte au niveau d’une ou plusieurs unités de virtualisation et au moins un paramètre de qualité de service prédéterminé. À titre illustratif et non limitatif, un tel paramètre de qualité de service prédéterminé correspond par exemple à un temps de réponse au service, représentatif d’un temps de traitement d’une requête de service sur la ou les unités de virtualisation considérées.
[0086] La nouvelle formule pour calculer le seuil de déclenchement d’une opération de mise à l'échelle consiste à calculer la somme des charges de service de chaque unité de virtualisation et à la diviser par la charge de service maximale PLmax acceptée par unité de virtualisation, à arrondir le résultat obtenu à l’entier supérieur, et à y ajouter la quantité B d’unités de virtualisation prévues dans le schéma de protection visé, selon la formule suivante :
Figure imgf000013_0001
[0089] - R(k) le nombre d’unités de virtualisation instanciées à un instant k ;
[0090] - R(k+1 ) le nombre d’unités de virtualisation à instancier à un instant k + 7, postérieur audit instant k ;
[0091] - ceil la fonction d’arrondi à l’entier supérieur ;
[0092] - et les contraintes supplémentaires, non formalisées dans l’équation (2) mais toujours mises en œuvre, selon lesquelles R(k+1 ) est automatiquement fixé à la valeur MINPODS si le résultat de l’équation (2) devient inférieur à MINPODS, et R(k+1 ) est automatiquement fixé à la valeur MAXPODS si le résultat de l’équation (2) devient supérieur à MAXPODS.
[0093] Une telle implémentation selon la technique proposée est avantageuse sur de nombreux plans.
[0094] En premier lieu, elle peut être mise en œuvre sans modifications majeures du module de mise à l’échelle d’une architecture Kubernetes, dans la mesure où une charge de service peut être rapportée dans un format proche d’une charge CPU.
[0095] En deuxième lieu, elle permet de rendre les décisions de mise à l’échelle - i.e. le déclenchement de l’ajout ou du retrait d’une unité de virtualisation - indépendante de la charge CPU à vide des unités de virtualisation. Par charge à vide (également désignée sous le terme « noload » dans l’ensemble des figures), on entend ici une charge CPU résiduelle sur les unités de virtualisation plus ou moins importante, potentiellement existante même lorsque la charge de service est nulle, c’est-à-dire alors même que les unités de virtualisation ne traitent aucune donnée liée au service en question.
[0096] L’inventeur a en effet mis en évidence que la charge CPU des unités de virtualisation peut varier de façon non linéaire par rapport à la charge de service qu’ils absorbent, ce phénomène étant d’autant plus accentué que la charge à vide des unités de virtualisation est importante. Aussi, l’utilisation selon l’art antérieur de la charge CPU des unités de virtualisation comme critère pour déterminer le déclenchement d’une opération de mise à l’échelle, même en adaptant ce mécanisme pour prendre en compte le nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection, entraine l’apparition de deux phénomènes d’hystérésis tels qu’illustrés de façon schématique sur la [Fig.5] :
[0097] - lorsque la charge de service (en abscisse) augmente, l’ajout d’une unité de virtualisation se produit de manière trop précoce par rapport au moment nominal en termes d’efficacité énergétique ;
[0098] - lorsque la charge de service (en abscisse) diminue, le retrait d’une unité de virtualisation se produit de manière trop tardive par rapport au moment nominal en termes d’efficacité énergétique.
[0099] Par ces deux phénomènes l’efficacité énergétique du mécanisme de mise à l’échelle horizontale se dégrade, et ce d’autant plus que la charge à vide est importante.
[0100] La combinaison des deux modifications principales d’une architecture Kubernetes telle que proposée selon le principe général de la présente technique - i.e. la prise en compte du nombre d’unités de virtualisation de sauvegarde d’une part, et l’utilisation de la charge de service plutôt que de la charge CPU d’autre part, en tant que critères de décision des opérations de mise à l’échelle - est donc particulièrement intéressante, en ce que ces modifications sont complémentaires et synergiques afin d’atteindre une efficacité énergétique optimale.
[0101] En particulier, du fait de la relation directe entre la charge de service totale SL et la charge de service prise en charge par chaque unité de virtualisation (selon la formule il n’y a pas d’effet d’hystérésis et les phénomènes indésirables pré-
Figure imgf000015_0001
cédemment décrits ne se produisent pas avec la technique proposée, même en cas de charge CPU à vide importante au niveau des unités de virtualisation. Comme illustré de manière schématique en relation avec la [Fig.6], et à la différence de la situation de la [Fig.5] , lorsque la présente technique est mise en œuvre, les déclenchements de scale out et de scale in à un même niveau (e.g. un scale out dans lequel le nombre de replica passe de 2 à 3 unités de virtualisation, ou un scale in out dans lequel le nombre de replica passe de 3 à 2 unités de virtualisation) surviennent pour les mêmes valeurs de charge de Service SL (i.e. à la même valeur d’abscisse, au niveau d’un entier), garantissant ainsi une efficacité énergétique optimale, équivalente à la meilleure efficacité énergétique pouvant être obtenue en ce qui concerne les déclenchements des opérations de mise à l’échelle.
[0102] Les différents aspects de la présente technique précédemment décrits se rapportent à la détermination du meilleur moment pour effectuer une opération de scale in ou de scale out.
[0103] On s’intéresse par la suite, de manière complémentaire, à d’autres aspects de la présente technique, se rapportant au choix du nœud de virtualisation sur lequel doit être ajouté ou retiré une unité de virtualisation lors de telles opérations.
[0104] Les perfectionnements associés aux modes de réalisation décrits précédemment sont efficaces tant que les unités de virtualisation d’un schéma de protection sont déployées sur des nœuds de virtualisation homogènes, c’est-à-dire présentant des caractéristiques techniques sensiblement équivalentes. En effet, un schéma de protection N:B permet de supporter la défaillance de B unités de virtualisation parmi les N unités de virtualisation prévues pour supporter la charge de service nominale, dans une situation où toutes les unités de virtualisation peuvent être considérées comme équivalentes. C’est généralement le cas lorsqu’une infrastructure de virtualisation est déployée sur des serveurs informatiques neufs, dans la plupart des cas identiques pour des raisons de coûts (il est en général moins cher d’acheter des équipements identiques en grande quantité que d’acheter des équipements aux caractéristiques techniques variées en plus petites quantités). [0105] Dans certaines situations, il arrive toutefois que les serveurs utilisés pour la mise en œuvre d’une infrastructure de virtualisation ne soient pas tous identiques en termes de caractéristiques techniques (par exemple, en cas de réutilisation dans un centre de données de serveurs informatiques d’origines diverses, par exemple en provenance de plateformes démantelées avant la fin de la période de support garanti par les vendeurs de ces serveurs informatiques). En tout état de cause, de telles situations sont amenées à être de plus en plus fréquentes, dans un contexte global d’impératif d’économies de ressources où les incitations à réexploiter des appareils existants dans des opérations de « seconde vie » plutôt qu’à en acquérir des neufs tendent à se multiplier. Les nœuds de virtualisation sur lesquels les unités de virtualisation sont susceptibles d’être ins- tanciées exploitent alors des processeurs qui ont potentiellement des capacités de traitement différentes.
[0106] Il est donc proposé, dans un mode de réalisation de la présente technique, de tenir compte d’au moins une caractéristique technique associée aux nœuds de virtualisation disponibles, lors de la sélection d’un nœud de virtualisation au sein duquel une unité de virtualisation est ajoutée ou retirée en réponse à une décision de mise à l’échelle automatique.
[0107] Dans un mode de réalisation, ladite caractéristique technique est la fréquence d’horloge de fonctionnement desdits nœuds de virtualisation, potentiellement différente d’un nœud à un autre.
[0108] Pour faciliter la compréhension de la problématique qui se pose en présence de nœuds aux caractéristiques techniques hétérogènes et la solution proposée, on décrit ci- après, en relation avec la [Fig.7], la séquence connue qui permet, dans le cadre d’une architecture Kubemetes classique, de réserver pour chaque unité de virtualisation la capacité de traitement « requests » déjà introduite en relation avec l’art antérieur, exprimée en portion de CPU. On peut considérer qu’une telle capacité de traitement correspond à une fraction de temps, ou bien encore à une fraction du nombre de cycles d’horloge réservables par unité de temps.
[0109] Dans une étape préliminaire 71, lors de son enrôlement au sein d’une grappe (ou « cluster ») de nœuds de virtualisation, chaque nœud de virtualisation (par exemple le nœud i de virtualisation « Node_i » illustré sur la [Fig.7]) fournit à un module d’orchestration Mod_ORC (ou « scheduler ») sa capacité totale « total_CPU_i » de traitement CPU (à noter que pour des raisons de simplification, le module d’orchestration, bien qu’existant, n’a pas été représenté sur les figures 1 et 4 précédemment décrites, son fonctionnement et ses interactions avec les autres modules n'étant pas modifié dans les modes de réalisation précédemment décrits). Avant toute réservation de temps de traitement sur le nœud i, cette capacité totale « total_CPU_i » de traitement CPU correspond à une capacité de traitement disponible « Available _CPU_i » sur le nœud.
[0110] Ultérieurement, lorsqu’une décision de scale out est prise par le module de mise à l’échelle Mod_ME, celui-ci transmet, dans une étape 72, une demande d’instanciation d’une nouvelle unité de virtualisation à un module d’installation Mod_INS.
[0111] Le module d’installation Mod_INS détermine alors la capacité de traitement requise
« requests » pour cette unité de virtualisation (éventuellement en calculant la somme des capacités requises pour chacun des conteneurs qui la compose), puis demande au module d’orchestration Mod_ORC, dans une étape 73, de réserver ces ressources dans le meilleur nœud possible.
[0112] À cette fin, le module d’orchestration Mod_ORC présélectionne «filtering ») les nœuds ayant suffisamment de capacité non encore réservée par d’autres unités de virtualisation déjà installées en leur sein, en comparant la capacité de traitement requise « requests » à la capacité de traitement disponible au sein des différents nœuds de virtualisation (par exemple « Available CPU _i » pour le nœud i). Le module d’orchestration Mod_ORC effectue ensuite un classement (« scoring ») des nœuds présélectionnés selon de multiples critères, tel que le taux de charge par exemple, ce qui lui permet de déterminer le meilleur nœud pour l’instanciation de la nouvelle unité de virtualisation, et d’y réserver, dans une étape 74, la quantité « requests » de CPU requise pour cette unité de virtualisation (dans l’exemple de la [Fig.7], on considère que le nœud i est ainsi choisi, et le module d’orchestration Mod_ORC retire donc la quantité « requests » à la capacité de traitement disponible pour ce nœud).
[0113] Le module d’orchestration Mod_ORC transmet au module d’installation Mod_INS, dans une étape 75 des informations d’identification du nœud de virtualisation choisi. Sur la base de ces informations, dans une étape 76, le module d’installation Mod_INS instancie l’unité de virtualisation sur le nœud de virtualisation choisi, et le configure de manière à ce que la portion de charge CPU « requests » reste bien toujours disponible pour cette unité de virtualisation.
[0114] Dans le cas d’une infrastructure de virtualisation comprenant des nœuds de virtualisation associés à des processeurs de caractéristiques techniques différentes, les fréquences nominales de fonctionnement sont généralement différentes, un nœud N; travaillant par exemple à la fréquence Clk_i, et un nœud Nj à la fréquence Clk J. Il en résulte que le nombre de cycles par unité de temps, et donc le nombre de cycles ré- servables par unité de temps sont également différents entre une unité de virtualisation installé sur le nœud Ni et une unité de virtualisation installée sur le nœud Nj, et donc que les charge de service maximale PLmax_i et PLmax _J acceptées respectivement par chacune de ces deux unités de virtualisation sont également différentes, ce qui pose un problème pour définir le paramètre PLmax à fournir en entrée du module de mise à l’échelle (ce paramètre PLmax ne pouvant pas être égal à la fois à PLmax_i et à PL max _J) pour la mise en œuvre du premier niveau d’amélioration décrit en relation avec les figures 4 à 6.
[0115] Des modifications complémentaires de l’architecture Kubemetes sont donc proposées dans un mode de réalisation particulier de la présente technique, de manière à ce que les perfectionnements précédemment proposés dans le cadre de la présente technique eu égard à l’optimisation de la performance énergétique soient également compatibles avec des infrastructures de virtualisation comprenant des processeurs de caractéristiques techniques différentes.
[0116] Ces modifications, complémentaires aux modifications proposées précédentes, sont présentées en relation avec la [Fig.8], et consistent en des adaptations de la séquence de réservation de capacité de traitement des unités de virtualisation.
[0117] Plus particulièrement, la [Fig.8] reprend la nature et l’ordre des étapes déjà décrites en relation avec la [Fig.7], qui restent similaires, mais il est proposé dans certaines de ces étapes de faire intervenir un facteur de normalisation.
[0118] En premier lieu, un paramètre « Clk_ref» prédéterminé est défini au niveau du module d’orchestration, afin de servir de fréquence d’horloge de référence pour comparer les fréquences d’horloge nominale des différents nœuds de virtualisation.
[0119] Dans une étape préliminaire 81, pendant de l’étape 71 d’enrôlement de la [Fig.7]
, chaque nœud de virtualisation (par exemple le nœud i de virtualisation « Node_i » illustré sur la [Fig.8]) fournit au module d’orchestration Mod_ORC sa fréquence d’horloge nominale de fonctionnement (« Clk_i » pour le nœud i), en plus de sa capacité totale de traitement CPU (« total_CPU_i » pour le nœud i). Avant toute réservation de temps de traitement sur nœud i, cette capacité totale « total_CPU_i » de traitement CPU correspond à une capacité de traitement disponible « Available _CPU _i » sur le nœud.
[0120] Ultérieurement, lorsqu’une décision de scale out est prise par le module de mise à l’échelle Mod_ME, celui-ci transmet, dans une étape 82 similaire à l’étape 72 précédemment décrite en relation avec la [Fig.7], une demande d’instanciation d’une nouvelle unité de virtualisation au module d’installation Mod_INS.
[0121] Comme dans l’étape 73 précédemment décrite en relation avec la [Fig.7], le module d’installation Mod_INS détermine alors la capacité de traitement requise pour cette unité de virtualisation (éventuellement en calculant la somme des capacités requises pour chacun des conteneurs qui la compose), puis demande au module d’orchestration Mod_ORC, dans une étape 83, de réserver ces ressources dans le meilleur nœud possible.
[0122] Toutefois, à la différence du processus illustré en [Fig.7], le module d’orchestration Mod_ORC réalise un filtrage («filtering ») des nœuds en comparant non pas la capacité de traitement requise « requests » à la capacité de traitement disponible au sein des différents nœuds de virtualisation (par exemple « Available _CPU_i » pour le nœud i), mais à une capacité de traitement disponible normalisée en fonction d’un ratio entre la fréquence de fonctionnement du nœud considéré et la fréquence d’horloge de référence, soit « available _CPU _i * ( Clk_i / Clk_rej) » pour le nœud i. Le module d’orchestration Mod_ORC effectue ensuite un classement (« scoring ») des nœuds ainsi présélectionnés selon de multiples critères, tel que le taux de charge par exemple, ce qui lui permet de déterminer le meilleur nœud pour l’instanciation de la nouvelle unité de virtualisation. À la différence de l’étape 74 précédemment décrite en relation avec la [Fig.7], le module d’orchestration Mod_ORC réserve dans le nœud de virtualisation choisi, dans une étape 84, une quantité « requests / ( Clk_i/Clk_ref) » de CPU requise pour cette unité de virtualisation (dans l’exemple de la [Fig.8], on considère que le nœud i est ainsi choisi, et le module d’orchestration Mod_ORC retire donc la quantité « requests / ( Clk_i/Clk_ref) » à la capacité de traitement disponible pour ce nœud).
[0123] Le module d’orchestration Mod_ORC transmet au module d’installation Mod_INS, dans une étape 85 pendant de l’étape 75 de la [Fig.7], des informations d’identification du nœud de virtualisation choisi, mais également la valeur du facteur correctif « ( Clk_i/ Clk_ref) » à appliquer à l’étape suivante. Sur la base de ces informations, dans une étape 86 pendant de l’étape 76 de la [Fig.7], le module d’installation Mod_INS instancie l’unité de virtualisation sur le nœud de virtualisation choisi, et le configure de manière à ce que la portion de charge CPU « requests / ( Clk_i/Clk_rej) » reste bien toujours disponible pour cette unité de virtualisation.
[0124] En d’autres termes, à chaque étape, il est procédé à une normalisation des opérations effectuées par application d’un facteur correctif (Clk_i/Clk_ref), comme mis en évidence en gras sur la [Fig.8].
[0125] Cette normalisation a pour effet que les charges de service PLmax_i et PLmax _J maximales admissibles respectivement par chacune de deux unités de virtualisation i et j déployées sur des nœuds de virtualisation i et j fonctionnant à des fréquences d’horloge nominales « Clk_i » et « Clk_j » différentes restent identiques, et cohérentes par rapport à la valeur PLmax fournie par configuration au module de mise à l’échelle, comme illustré en relation avec la [Fig.9].
[0126] De cette manière, les perfectionnements proposés dans le cadre de la présente technique pour améliorer la performance énergique des opérations de mise à l’échelle peuvent être mis en œuvre non seulement sur des infrastructures de virtualisation reposant sur des équipements aux caractéristiques techniques similaires, mais également sur des infrastructures de virtualisation comprenant des équipements de caractéristiques techniques hétérogènes.
[0127] Bien entendu, bien que présenté en relation avec une opération de scale out, le principe de normalisation décrit en relation avec la [Fig.9] est également appliqué dans le cadre d’une opération de scale in, lorsqu’il s’agit de déterminer sur quel nœud de virtualisation retirer une unité de virtualisation.
[0128] Selon un autre aspect, la présente technique se rapporte également à un système d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Un tel système comprend des moyens lui permettant de réaliser le procédé précédemment décrit dans l’un quelconque de ses modes de réalisation. Plus particulièrement, un tel système selon la présente technique comprend un module de mise à l'échelle configuré pour délivrer une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre dudit service, ladite décision étant effectuée en fonction :
[0129] - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ;
[0130] - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation dudit ensemble.
[0131] Comme illustré sur la [Fig.9], un tel système comprend par ailleurs, dans divers modes de réalisation particuliers, en complément du module de mise à l'échelle, divers autres modules (e.g. module sonde, module d’installation, module d’orchestration, module de répartition de charges) configurés pour permettre la mise en œuvre des caractéristiques du procédé précédemment décrits dans l’un quelconque de ses modes de réalisation, avec les mêmes avantages.
[0132] La [Fig.10] représente, de manière schématique et simplifiée, certains éléments structurels d’un tel système, dans un mode de réalisation particulier. Ce système comprend par exemple une mémoire 11 constituée d’une mémoire tampon M, une unité de traitement 12, équipée par exemple d’un microprocesseur pP, et pilotée par le programme d’ordinateur Pg 13, mettant en œuvre des étapes du procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, selon au moins un mode de réalisation de l’invention.
[0133] Ainsi, ces éléments structurels sont utilisés par les différents modules précédemment décrits, de manière à optimiser la performance énergétique d’une architecture Ku- bemetes.
[0134] À l’initialisation, les instructions de code du programme d’ordinateur 13 sont chargées dans la mémoire tampon avant d’être exécutées par le processeur de l’unité de traitement 12. Pour la mise en œuvre des opérations effectuées par un module de mise à l'échelle, l’unité de traitement 12 reçoit par exemple en entrée E des informations stockées dans la mémoire 11 (e.g. des valeurs MINPODS, MAXPODS, un nombre B d’unités de virtualisation de sauvegarde, une charge de service maximale PLmax autorisée par unité de virtualisation, etc.), ainsi que des informations en provenance d’un module sonde, représentatives d’une charge de service totale atteinte SL mesurée par le module sonde.
[0135] Le microprocesseur de l’unité de traitement 12 réalise alors les étapes du procédé d’adaptation du dimensionnement de l’infrastructure de virtualisation, selon les instructions du programme d’ordinateur 13. Plus particulièrement, ces opérations délivrent en sortie S une décision d’ajouter ou de retirer une unité de virtualisation à l’ensemble d’unités de virtualisation instanciées pour la mise en œuvre du service, à un moment optimal pour maximiser la performance énergétique de l’architecture Ku- bemetes.

Claims

Revendications
[Revendication 1] Procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation, ledit procédé étant caractérisé en ce qu’une décision d’ajouter ou de retirer une unité de virtualisation (UV) à un ensemble (set) d’unités de virtualisation instanciées pour la mise en œuvre dudit service est effectuée en fonction :
- du nombre B d’unités de virtualisation de sauvegarde défini dans ledit schéma de protection ;
- d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation (UV) dudit ensemble (set).
[Revendication 2] Procédé selon la revendication 1, caractérisé en ce que ladite décision d’ajouter ou de retirer une unité de virtualisation est régie par la formule :
Figure imgf000022_0001
avec
- R(k) le nombre d’unités de virtualisation instanciées à un instant k ;
- R(k+1 ) le nombre d’unités de virtualisation à instancier à un instant k + 1, postérieur audit instant k ;
- PLp la charge de service atteinte au niveau d’une unité de virtualisation p dudit ensemble entre l’instant k et l’instant k+L dite charge de service courante.
[Revendication 3] Procédé selon la revendication 1, caractérisé en ce que ladite charge de service PLmax maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et une charge CPU résultante de ladite charge de service courante atteinte au niveau de ladite au moins une unité de virtualisation.
[Revendication 4] Procédé selon la revendication 1, caractérisé en ce que ladite charge de service PLmœi maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et au moins un paramètre de qualité de service prédéterminé associé à ladite au moins une unité de virtualisation.
[Revendication 5] Procédé selon la revendication 4, caractérisé en ce que ledit au moins un paramètre de qualité de service comprend un temps de réponse audit service, représentatif d’un temps de traitement d’une requête de service sur ladite au moins une unité de virtualisation.
[Revendication 6] Procédé selon la revendication 1, caractérisé en ce qu’une sélection, parmi une pluralité de nœuds de virtualisation disponibles au sein de ladite infrastructure de virtualisation, d’un nœud de virtualisation cible au sein duquel une unité de virtualisation est ajoutée ou retirée en réponse à ladite décision tient compte d’au moins une caractéristique technique associée auxdits nœuds de virtualisation de ladite pluralité.
[Revendication 7] Procédé selon la revendication 6, caractérisé en ce que ladite au moins une caractéristique technique comprend une fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité.
[Revendication 8] Procédé selon la revendication 7, caractérisé en ce que ladite fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité est communiquée à un module d’orchestration (Mod_ORC) en charge de ladite sélection, dans une étape d’enrôlement dudit nœud de virtualisation auprès dudit module d’orchestration, en complément d’une capacité totale de traitement CPU associée audit nœud de virtualisation.
[Revendication 9] Procédé selon la revendication 8, caractérisé en ce que ladite fréquence d’horloge de fonctionnement est utilisée pour normaliser une capacité de traitement CPU à réserver à une unité de virtualisation au sein dudit nœud de virtualisation cible, par application d’un facteur de normalisation.
[Revendication 10] Procédé selon la revendication 9, caractérisé en ce que ledit facteur de normalisation est défini par un ratio entre ladite fréquence d’horloge de fonctionnement et une fréquence d’horloge de référence (Clk_ref) prédéfinie, commune à l’ensemble des nœuds de virtualisation de ladite pluralité.
[Revendication 11] Système d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation, ledit système étant caractérisé en qu’il comprend un module de mise à l'échelle (Mod_ME) configuré pour délivrer une décision d’ajouter ou de retirer une unité de virtualisation (UV) à un ensemble (set) d’unités de virtualisation instanciées pour la mise en œuvre dudit service, ladite décision étant effectuée en fonction :
- du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ;
- d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation (UV) dudit ensemble (set).
[Revendication 12] Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé selon l'une quelconque des revendications 1 à 10, lorsqu’il est exécuté par un ordinateur.
PCT/EP2024/067746 2023-06-28 2024-06-25 Procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service Ceased WO2025003099A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202480043455.3A CN121444073A (zh) 2023-06-28 2024-06-25 用于使虚拟化基础设施的规模适配于服务负载的方法
EP24736017.5A EP4736004A1 (fr) 2023-06-28 2024-06-25 Procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2306779 2023-06-28
FR2306779A FR3150611A1 (fr) 2023-06-28 2023-06-28 Procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service.

Publications (1)

Publication Number Publication Date
WO2025003099A1 true WO2025003099A1 (fr) 2025-01-02

Family

ID=88069066

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/067746 Ceased WO2025003099A1 (fr) 2023-06-28 2024-06-25 Procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service

Country Status (4)

Country Link
EP (1) EP4736004A1 (fr)
CN (1) CN121444073A (fr)
FR (1) FR3150611A1 (fr)
WO (1) WO2025003099A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3796167A1 (fr) * 2019-09-23 2021-03-24 SAS Institute Inc. Gestion de routeur par un gestionnaire de grappe de traitement de flux d'événements

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3796167A1 (fr) * 2019-09-23 2021-03-24 SAS Institute Inc. Gestion de routeur par un gestionnaire de grappe de traitement de flux d'événements

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LEMOINE BENOIT: "Energy Efficiency of N:1 Protection Setups with Kubernetes Horizontal Pod Autoscaler", 2022 25TH CONFERENCE ON INNOVATION IN CLOUDS, INTERNET AND NETWORKS (ICIN), IEEE, 7 March 2022 (2022-03-07), pages 126 - 130, XP034115456, DOI: 10.1109/ICIN53892.2022.9758129 *

Also Published As

Publication number Publication date
EP4736004A1 (fr) 2026-05-06
CN121444073A (zh) 2026-01-30
FR3150611A1 (fr) 2025-01-03

Similar Documents

Publication Publication Date Title
EP1043658A1 (fr) Procédé d'amélioration des performances d'un système multiprocesseur comprenant une file d'attente de travaux et architecture de système pour la mise en oeuvre du procédé
WO2013068662A1 (fr) Procédé, programme d'ordinateur et dispositif d'allocation de ressources informatiques d'un cluster pour l'exécution d'un travail soumis audit cluster
WO2020174156A1 (fr) Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée
FR2915006A1 (fr) Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.
EP3051416B1 (fr) Procédé de commande de déploiement d'un programme a exécuter dans un parc de machines
WO2014072628A1 (fr) Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-coeurs
EP2049967A2 (fr) Coeur processeur a frequence pilotee et procede de demarrage dudit coeur processeur dans un mode programme
WO2016198762A1 (fr) Procédé et système de détermination d'une configuration de serveurs cible pour un déploiement d'une application logicielle
EP4736004A1 (fr) Procédé d'adaptation du dimensionnement d'une infrastructure de virtualisation à une charge de service
EP3991356B1 (fr) Procédé d'allocation de ressources d'une infrastructure de réseau
FR3078462A1 (fr) Procede et dispositif de controle d'un acces a une ressource d'un systeme informatique par des applications logicielles
FR3119121A1 (fr) Procédé et serveur pour la gestion de groupes de batteries rechargeables mobiles pour des stations multiples
WO2012038000A1 (fr) Procede de gestion de taches dans un microprocesseur ou un ensemble de microprocesseurs
FR3071630A1 (fr) Procede de gestion de modules logiciels embarques pour un calculateur electronique d'un appareil electrique de coupure
WO2025132515A1 (fr) Procédé d'optimisation du dimensionnement d'une infrastructure de virtualisation à une charge de service
EP4432086A1 (fr) Procédé et système de déploiement d'une application saas
EP3437406B1 (fr) Procédé de gestion de l'allocation de fréquences porteuses
BE1029586B1 (fr) Adaptation a une defaillance potentielle pour gestion de projet
WO2025114164A1 (fr) Procédé de déploiement d'un service dans un environnement distribué
FR3104876A1 (fr) Adaptation synchronisée d’un sous-ensemble virtuel d’un réseau dédié à un service
EP4206907A1 (fr) Procédé et système de supervision de mise à jour de logiciel de support dans une infrastructure de fourniture de services
FR3060791A1 (fr) Procede et dispositif de mise a jour
FR3103986A1 (fr) Procédé de répartition de ressources dans une infrastructure en réseau
EP2860630A1 (fr) Procédé de transfert de données dans un environnement dynamique
WO2026041625A1 (fr) Procédé d'affectation d'unités informatiques dans une architecture d'informatique en nuage

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24736017

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2024736017

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2024736017

Country of ref document: EP

Effective date: 20260128

ENP Entry into the national phase

Ref document number: 2024736017

Country of ref document: EP

Effective date: 20260128

WWP Wipo information: published in national office

Ref document number: 2024736017

Country of ref document: EP