Search

EP-4736004-A1 - METHOD FOR ADAPTING THE DIMENSIONING OF A VIRTUALISATION INFRASTRUCTURE TO A SERVICE LOAD

EP4736004A1EP 4736004 A1EP4736004 A1EP 4736004A1EP-4736004-A1

Abstract

The invention relates to a method for adapting the dimensioning of a virtualisation infrastructure to a service load, the virtualisation infrastructure implementing a protection scheme N:B in which, for N virtualisation units which absorb the service load in a nominal mode, there are B backup virtualisation units which make it possible to guarantee absorption of the service load in the event of a failure affecting at most B virtualisation units. According to this method, a decision to add or remove a virtualisation unit (UV) to a set ( set ) of virtualisation units which are instantiated to implement the service is made according to: - the number B of backup virtualisation units defined in the protection scheme; - a comparison between a total service load reached SL and a maximum service load PLmax authorised per virtualisation unit (UV) of the set ( set ).

Inventors

  • LEMOINE, Benoît

Assignees

  • ORANGE

Dates

Publication Date
20260506
Application Date
20240625

Claims (12)

  1. [Claim 1] Method 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, said method being characterized in that a decision to add or remove a virtualization unit (UV) to a set of virtualization units instantiated for the implementation of said service is made according to: - the number B of backup virtualization units defined in said protection scheme; - a comparison between a total service load reached SL and a maximum service load PLmax authorized per virtualization unit (UV) of said set.
  2. [Claim 2] A method according to claim 1, characterized in that said decision to add or remove a virtualization unit is governed by the formula: with - R(k) the number of virtualization units instantiated at time k; - R(k+1) the number of virtualization units to be instantiated at a time k + 1, after said time k; - PL p the service load reached at the level of a virtualization unit p of said set between time k and time k+L called current service load.
  3. [Claim 3] Method according to claim 1, characterized in that said maximum authorized PL max service load per virtualization unit is automatically estimated based on at least one comparison data between a current service load reached at the level of at least one virtualization unit and a CPU load resulting from said current service load reached at the level of said at least one virtualization unit.
  4. [Claim 4] Method according to claim 1, characterized in that said maximum authorized PL mœi service load per virtualization unit is estimated automatically based on at least one comparison data between a current service load reached at the level of at least one virtualization unit and at least one predetermined quality of service parameter associated with said at least one virtualization unit.
  5. [Claim 5] Method according to claim 4, characterized in that said at least one quality of service parameter comprises a response time to said service, representative of a processing time for a service request on said at least one virtualization unit.
  6. [Claim 6] A method according to claim 1, characterized in that a selection, from among a plurality of virtualization nodes available within said virtualization infrastructure, of a target virtualization node within which a virtualization unit is added or removed in response to said decision takes into account at least one technical characteristic associated with said virtualization nodes of said plurality.
  7. [Claim 7] Method according to claim 6, characterized in that said at least one technical characteristic comprises an operating clock frequency associated with at least one virtualization node of said plurality.
  8. [Claim 8] Method according to claim 7, characterized in that said operating clock frequency associated with at least one virtualization node of said plurality is communicated to an orchestration module (Mod_ORC) in charge of said selection, in a step of enrolling said virtualization node with said orchestration module, in addition to a total CPU processing capacity associated with said virtualization node.
  9. [Claim 9] A method according to claim 8, characterized in that 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.
  10. [Claim 10] Method according to claim 9, characterized in that said normalization factor is defined by a ratio between said operating clock frequency and a predefined reference clock frequency (Clk_ref), common to all the virtualization nodes of said plurality.
  11. [Claim 11] 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 units of virtualization absorbing said service load in a nominal mode, there are B backup virtualization units to ensure absorption of said service load in the event of failure of at most B virtualization units, said system being characterized in that it comprises a scaling module (Mod_ME) configured to deliver a decision to add or remove a virtualization unit (UV) to a set of virtualization units instantiated for the implementation of said service, said decision being made according to: - the number B of backup virtualization units defined in said protection scheme; - a comparison between a total service load reached SL and a maximum service load PLmax authorized per virtualization unit (UV) of said set.
  12. [Claim 12] Computer program product downloadable from a communications network and/or stored on a computer-readable medium and/or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a method according to any one of claims 1 to 10, when executed by a computer.

Description

Description Title of the invention: Method for adapting the sizing of a virtualization infrastructure to a service load. Technical field [0001] 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. Prior art [0002] Many communication networks use virtualized functions instantiated on virtualization nodes hosted in virtual machines or in servers grouped into clusters, or "clusters" within data centers. In the remainder of the document, mention is made of virtualization nodes hosted in servers but it is understood that the teaching of this document also applies to the case of virtualization nodes hosted in virtual machines. [0003] An example of managing the instantiation of virtualized functions is known as “Kubernetes”. A Kubernetes architecture comprises at least one cluster of virtualization nodes. Such a cluster of virtualization nodes comprises at least a first node called a management node, or “Kubernetes master node”, and a plurality of computing nodes, or “Kubernetes worker node” intended to instantiate virtualized functions. [0004] The management node includes, among other things, a database called ETCD which consists of a dynamic configuration register of the computing nodes. [0005] A computing node comprises a plurality of virtualization units or “pods”. Each virtualization unit is provided with resources enabling the execution of one or more tasks. A task, when executed, contributes to the implementation of a virtualized service or function. [0006] 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. Thus, in response to an increase in the load, a greater number of virtualization units is deployed (in an operation known as “scale out”). "). Conversely, in response to a decrease in load, 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. [0007] A simplified description is given, in relation to [Fig.l], of a classic Kubemetes architecture, allowing the implementation of such a mechanism. [0008] As previously described, in such an architecture, a number R (called “Replicas”) of UV virtualization units are deployed on one or more virtualization nodes, for the implementation of a service. [0009] A Mod_S probe module measures an average CPU usage (i.e. a CPU usage, or processor usage, of the computer servers on which they are deployed) per virtualization unit, on the set of instantiated UV virtualization units. [0010] At the level of an automatic scaling module Mod_ME (“Autoscaler”) this average CPU usage of a virtualization unit is compared to a threshold value expressed in the form of a ratio of 0% to 100% (“targets”) of a guaranteed nominal CPU value for each virtualization unit (“requests”). This guaranteed nominal CPU value “requests” was reserved at the time of installation of the virtualization unit on its virtualization node. [0011] The result of this comparison is used to adapt the number R of instantiated replicas. For example, if the average CPU usage per virtualization unit exceeds the threshold value targets, requests, a decision is transmitted to an installation module Mod_INS to increase the number R of replicas, i.e. to increase the number of virtualization units UV instantiated for the implementation of the service. The number of virtualization units that the scaling module Mod_ME can decide to deploy is however limited between a predefined lower limit “MINPODS” and an upper limit “MAXPODS”. [0012] A load distribution module Mod_LB distributes the service load SL over all of the R available virtualization units. As an illustration and not a limitation, this service load SL can be defined as a number of service requests per second, in this case, the load distribution module Mod_LB relays a portion I //? of the service requests on each of the R virtualization units. In another example, the service load can also be defined as a rate of Internet packets to be sent by the virtualization units, in this case, the load distribution module Mod_LB relays the service requests on each of the R virtualization units so that the rate of Internet packets sent by each of the virtualization units approaches the ratio I //? of the total rate of Internet