Method for adapting the dimensioning of a virtualisation infrastructure to a service load

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).

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 across 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 within data centers. In the remainder of the document, reference is made to 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 compute node comprises a plurality of virtualization units or "pods". Each virtualization unit is provided with resources to execute 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 allows the number of virtualization units installed on all virtualization nodes to be automatically adapted 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 load, a larger 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 known as "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 described previously, in such an architecture, a number R (called “Replicas”) of UV virtualization units is 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, over the entire 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 as 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 a Mod_INS installation module to increase the number R of replicas, i.e. to increase the number of UV virtualization units instantiated for the implementation of the service. The number of virtualization units that the Mod_ME scaling module can decide to deploy is however bounded between a predefined lower limit "MINPODS" and an upper limit "MAXPODS".

[0012] A load balancing module Mod_LB distributes the SL service load across all R available virtualization units. For illustrative and non-limiting purposes, this SL service load can be defined as a number of service requests per second; in this case, the load balancing module Mod_LB relays a portion I / / ? of the service requests to each of the R virtualization units. In another example, the service load can also be defined as a rate of Internet packets to be emitted by the virtualization units; in this case, the load balancing module Mod_LB relays the service requests to each of the R virtualization units so that the rate of Internet packets emitted by each of the virtualization units approaches the ratio I / / ? of the total rate of Internet packets emitted by all the virtualization units.

[0013] The sizing process implemented (i.e. the adaptation of the number of replicas) is thus governed by a rule that can be formalized in the form of the following equation:

[0016] - R(k) the number of virtualization units instantiated at time k;

[0017] - R(k+1) the number of virtualization units to be instantiated at a time k + 7, after said time k;

[0018] - use p the CPU usage measured by the probe module for the virtualization unit p between time k and time k+,

[0019] - ceil the rounding up function;

[0020] - and the additional constraints, not formalized in equation (1) but implemented, according to which R(k+1 ) is automatically set to the value MINPODS if the result of equation (1) becomes less than MINPODS, and R(k+1 ) is automatically set to the value MAXPODS if the result of equation (1) becomes greater than MAXPODS.

[0021] [Fig.2] illustrates on an example the effects of the scaling mechanism previously described, in a configuration in which targets is set to 100%, MINPODS to 1, and MAXPODS to 4. Since MINPODS is set to 1, at least one virtualization unit is instantiated. When the service load (on the abscissa) increases and exceeds the maximum load (threshold targets. requests, here equal to requests') defined for a virtualization unit (crossing the abscissa with value 1), a new virtualization unit is instantiated (the number of replicas R increases from 1 to 2). When the service load increases further and exceeds the maximum load defined for two virtualization units (crossing the abscissa with value 2), a new virtualization unit is instantiated (the number of replicas R increases from 2 to 3).Such "scale out" operations can be repeated to automatically adapt the number of instantiated virtualization units to an increasing load level, until the maximum number of virtualization units defined by MAXPODS (here four), is reached. Conversely, when the service load decreases, at each downward crossing of a unit on the abscissa, the removal of a virtualization unit is implemented. Such "scale in" operations can be repeated to automatically adapt the number of instantiated virtualization units to a decreasing load level, until the minimum number of virtualization units defined by MINPODS (here one), is reached.

[0022] The configuration illustrated in relation to [Fig.2] does not, however, allow a possible failure of a virtualization unit to be quickly overcome. example, as illustrated in this [Fig.2] by arrow D, in the event of failure of a virtualization unit among three virtualization units in service, the service load is distributed over the two remaining virtualization units still functional, but the average load supported by these two units becomes higher than the maximum load they can absorb (exceeding the targets.requests threshold in ordinate), and the provision of the expected service is therefore no longer guaranteed (risk of slowdown, outages, etc.), the system having become undersized due to the failure. This situation persists for the time it takes for Kubemetes to reinstantiate an alternative virtualization unit to the failed unit. Several causes can delay the instantiation of an alternative unit.The selection of the virtualization node may be delayed, for example, due to a lack of resources on existing virtualization nodes and the need to wait for the installation of a new virtualization node. Downloading the virtualization unit image to the virtualization node chosen to host it may also be delayed, for example, due to network overload, etc.

[0023] A classic solution to this problem is to adopt a protection scheme according to which for N virtualization units required to absorb a load under nominal conditions (i.e. without failure), B additional virtualization units are provided (N:B type protection scheme) making it possible to cope with up to a predetermined number of possible failures without the quality of service being degraded, and therefore in a manner transparent to the user. The parameters targets, MINPODS and MAXPODS are then adapted according to the desired protection scheme.

[0024] [Fig.3] illustrates this mechanism using a 4:1 protection scheme as an example. In such a configuration, MINPODS is set to 2 and targets to 50%, which ensures that at least two virtualization units are deployed, and that in the event of a virtualization unit failure in the worst-case scenario, i.e., when only two virtualization units are deployed, the still-functional virtualization unit remains able to absorb the entire service load previously distributed across the two units. MAXPODS is further set to 5, in order to obtain a guaranteed service load corresponding to the total load that can be absorbed by four virtualization units under nominal conditions, even in the event of a virtualization unit failure.

[0025] The protection mechanism described above is therefore effective in that it prevents the system from being temporarily undersized in relation to a load to be absorbed, in the event of failure of a predetermined number of virtualization units.

[0026] However, such a solution is not optimal in terms of energy efficiency. Indeed, as visible in [Fig.3], it leads to occasional oversizing of the system, consequences of the fact that the targets value is set to guarantee the service in the worst case, and that it therefore remains constant regardless of the number of virtualization units deployed. Thus, we see for example in this [Fig.3] that the transition from three to four virtualization units is carried out very early, whereas it could have occurred later, ideally at the level of the abscissa of value 2, without this calling into question the capacity of the system to guarantee the service even in the event of failure of a virtualization unit.

[0027] In other words, although effective in ensuring an adaptation of the number of virtualization units to be deployed according to a change in a service load, as well as protection according to a predefined protection scheme, the trigger times of the "scale in" operations (removal of a virtualization unit in the event of a drop in load) and "scale out" operations (addition of a virtualization unit in the event of an increase in load) are clearly not optimized in terms of energy performance with current solutions (the "scale out" operations being triggered too early and the "scale in" operations too late, for almost all of them).

[0028] From a more global point of view, at a time when the reduction of greenhouse gas emissions has become a key issue in the fight against global warming on a global scale, the existing mechanisms for automatic sizing of IT systems in response to changes in a service load remain largely improvable in terms of resource savings, both energy and material.

[0029] For example, when old computer servers are reused as virtualization nodes alongside newer computer servers, the heterogeneous performance does not guarantee that the B virtualization units distributed on computer servers of different performance than the computer servers on which the A nominal virtualization units are hosted can compensate for the failure of B units among the A nominal virtualization units.

[0030] The object of the present invention is to resolve all or part of the drawbacks mentioned above. Summary of the invention

[0031] The present technique makes it possible to propose a solution aimed at remedying certain drawbacks of the prior art. According to one aspect, the present technique relates to a method for adapting the sizing of a virtualization infrastructure to a service load, said virtualization infrastructure implementing an N:B protection scheme in which for A virtualization units 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. According to the general principle of the proposed technique, a decision to add or remove a virtualization unit to a set of virtualization units instantiated for the implementation of said service is made according to:

[0032] - the number B of backup virtualization units defined in said protection scheme;

[0033] - a comparison between a total service load reached SL and a maximum service load PLmax authorized per virtualization unit of said set.

[0034] In this way, unlike the solutions of the prior art, the triggering of a decision to add or remove a virtualization unit is optimized in terms of energy performance, in that it not only takes into account the number B of backup virtualization units provided within the framework of the intended protection scheme, but also in that it is based on the evaluation of a service load rather than a CPU load, i.e. on data completely independent of a residual idle CPU load potentially present at the level of the virtualization units.

[0035] In a particular embodiment, said decision to add or remove a virtualization unit is governed by the formula:

[0037] with

[0038] - R(k) the number of virtualization units instantiated at time k;

[0039] - R(k+1) the number of virtualization units to be instantiated at a time k + 7, after said time k;

[0040] - PL p the service load reached at the level of a virtualization unit p of said set between time k and time k+1, called the current service load.

[0041] In this way, the triggers of scale out and scale in at the same level - i.e. from a number M to M+l virtualization units when the service load increases or from a number M+l to M virtualization units when the service load decreases - occur for the same Service SL load values, thus ensuring optimal energy efficiency.

[0042] In a particular embodiment, said maximum authorized PLmax 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. lization. Alternatively, in another particular embodiment, said maximum authorized PLmax 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 at least one predetermined quality of service parameter associated with said at least one virtualization unit.

[0043] In this way, the proposed technique can be implemented in a simple and automatic way, without major modifications to the scaling module of a Kubemetes architecture, a service load can be reported in a format close to a CPU load.

[0044] According to a particular characteristic of this embodiment, 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.

[0045] In a particular embodiment, 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.

[0046] In this way, the present technique can be implemented even within Kubernetes architecture based on the implementation of computer servers with heterogeneous technical characteristics, to the extent that these characteristics are taken into account for the selection of a virtualization node on which to add or remove a virtualization unit when adapting the sizing of the virtualization infrastructure to the evolution of a service load.

[0047] In a particular embodiment, said at least one technical characteristic comprises an operating clock frequency associated with at least one virtualization node of said plurality.

[0048] In this way, we have a simple way, by knowing such clock frequencies, to compare per unit of time the processing capacities of the different virtualization nodes available for the addition or removal of a virtualization unit.

[0049] According to a particular characteristic, said operating clock frequency associated with at least one virtualization node of said plurality is communicated to an orchestration module 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.

[0050] In this way, the orchestration module is able to compare the capabilities of processing of different virtualization nodes, even when these are implemented on electronic devices with heterogeneous technical characteristics.

[0051] In a particular embodiment, 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. According to a particular characteristic, 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.

[0052] In this way, by using such a normalization factor, the comparison of the processing capabilities of different virtualization nodes and the obtaining of normalized processing capabilities are further simplified.

[0053] According to another aspect, 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. According to the proposed technique, such a system 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:

[0054] - the number B of backup virtualization units defined in said protection scheme;

[0055] - a comparison between a total service load reached SL and a maximum service load PLmax authorized per virtualization unit of said set.

[0056] Such a system further comprises, in various particular embodiments, means enabling it to implement the characteristics of the method previously described in any of its embodiments, with the same advantages.

[0057] According to another aspect, 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 sizing of a virtualization infrastructure to a service load, as described above in any of its embodiments, when executed on a computer.

[0058] 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 carrying out the steps of the method as described above, in any of its embodiments.

[0059] Such a recording medium may be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB flash drive or a hard disk.

[0060] On the other hand, 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.

[0061] The various embodiments mentioned above can be combined with each other to implement the invention. Figures

[0062] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which:

[0063] [Fig 1 schematically presents the different modules of a Kubemetes architecture, and their inputs-outputs, according to the prior art;

[0064] [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;

[0065] [[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;

[0066] [Fig.4] schematically presents the different modules of an architecture Modified Kubemetes, and their inputs-outputs, in a particular embodiment of the proposed technique;

[0067] [Fig.5] illustrates an example of undesirable hysteresis phenomena associated with prior art solutions under high empty load, which the present technique aims to eliminate;

[0068] [Fig.6] illustrates an example of the effects of implementing a horizontal scaling mechanism within a modified Kubemetes architecture according to the present technique;

[0069] [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;

[0070] [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;

[0071] [Fig.9] schematically presents the different modules of an architecture Modified Kubemetes, and their inputs-outputs, in another particular embodiment of the proposed technique;

[0072] [Fig.10] describes a simplified architecture of an electronic system for implementing the proposed technique, in a particular embodiment. Detailed description of the invention

[0073] The technique described below overcomes some of the above-mentioned drawbacks.

[0074] In all figures in this document, elements and steps of the same nature are designated by the same numerical reference.

[0075] According to a first aspect, 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.

[0076] A Kubemetes architecture modified according to the present technique is presented schematically, in relation to [Fig.4].

[0077] Compared to the classic Kubemetes architecture as previously described in relation to [Fig.l], the present technique is based in its general principle on a combination of two main modifications aimed at optimizing the triggering, by a scaling module ("Autoscaler"), of a decision to add or remove a virtualization unit to a set of virtualization units instantiated for the implementation of a service. These modifications include, at the level of said scaling module:

[0078] - on the one hand, taking into account the number B of backup virtualization units provided for in the protection scheme implemented;

[0079] - on the other hand the implementation of a comparison based no longer on a load CPU, but on a service load.

[0080] In particular, the implementation of these changes requires several joint adaptations of the Kubernetes architecture, illustrated in [Fig.4] in a particular embodiment of the proposed technique and presented below.

[0081] According to a first adaptation, the number B of backup virtualization units provided in the implemented protection scheme is provided as input to the scaling module.

[0082] According to a second adaptation, the probe module is modified so that it no longer measures a CPU load of the virtualization units, but a PL service load p reached at the level of virtualization units.

[0083] According to a third adaptation, a new reference threshold value PL max is provided as input to the scaling module, corresponding to a maximum service load tolerated per virtualization unit, this new PL threshold value maxreplacing the “targets.requests” threshold value – i.e. the percentage of CPU load reserved per Pod – used in the classic prior art Kubernetes architecture.

[0084] According to a particular characteristic, the maximum permissible service load PL m ax 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.

[0085] According to another particular characteristic, alternatively, 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. By way of illustration and not limitation, such a predetermined quality of service parameter corresponds for example to a response time to the service, representative of a processing time for a service request on the virtualization unit(s) considered.

[0086] The new formula for calculating the threshold for triggering a scaling operation is to calculate the sum of the service loads of each virtualization unit and divide it by the maximum service load PL maxaccepted per virtualization unit, to round the result obtained to the next higher integer, and to add to it the quantity B of virtualization units provided for in the protection scheme in question, according to the following formula:

[0089] - R(k) the number of virtualization units instantiated at time k;

[0090] - R(k+1) the number of virtualization units to be instantiated at time k + 7, subsequent to said instant k;

[0091] - ceil the rounding up function;

[0092] - and the additional constraints, not formalized in equation (2) but still implemented, according to which R(k+1 ) is automatically set to the value MINPODS if the result of equation (2) becomes less than MINPODS, and R(k+1 ) is automatically set to the value MAXPODS if the result of equation (2) becomes greater than MAXPODS.

[0093] Such an implementation according to the proposed technique is advantageous on many levels.

[0094] First, it can be implemented without major changes to the scaling module of a Kubernetes architecture, since a service load can be reported in a format close to a CPU load.

[0095] Second, it makes scaling decisions – i.e., triggering the addition or removal of a virtualization unit – independent of the idle CPU load of the virtualization units. By idle load (also referred to as “noload” throughout the figures), 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.

[0096] The inventor has in fact demonstrated that the CPU load of the virtualization units can vary non-linearly in relation to the service load that they absorb, this phenomenon being all the more accentuated as the idle load of the virtualization units is high. Also, the use according to the prior art of the CPU load of the virtualization units as a criterion for determining the triggering of a scaling operation, even by adapting this mechanism to take into account the number B of backup virtualization units defined in said protection scheme, leads to the appearance of two hysteresis phenomena as illustrated schematically in [Fig.5]:

[0097] - when the service load (on the abscissa) increases, the addition of a virtualization unit occurs too early compared to the nominal time in terms of energy efficiency;

[0098] - when the service load (on the abscissa) decreases, the removal of a virtualization unit occurs too late compared to the nominal time in terms of energy efficiency.

[0099] These two phenomena cause the energy efficiency of the horizontal scaling mechanism to deteriorate, especially as the empty load increases.

[0100] The combination of the two main modifications of a Kubernetes architecture as proposed according to the general principle of the present technique - i.e. the support taking into account the number of backup virtualization units on the one hand, and the use of service load rather than CPU load on the other hand, as criteria for deciding on scaling operations - is therefore particularly interesting, in that these modifications are complementary and synergistic in order to achieve optimal energy efficiency.

[0101] In particular, due to the direct relationship between the total service load SL and the service load supported by each virtualization unit (according to the formula there is no hysteresis effect and undesirable phenomena pre- previously described do not occur with the proposed technique, even in case of heavy idle CPU load at the virtualization units. As schematically illustrated in relation to [Fig.6], and unlike the situation in [Fig.5], when the present technique is implemented, the triggers of scale out and scale in at the same level (e.g. 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) occur for the same SL Service load values ​​(i.e. at the same abscissa value, at the level of an integer), thus guaranteeing optimal energy efficiency, equivalent to the best energy efficiency that can be obtained with regard to the triggers of scaling operations.

[0102] The various aspects of the present technique previously described relate to determining the best time to perform a scale in or scale out operation.

[0103] We are subsequently interested, in a complementary manner, in other aspects of the present technique, relating to the choice of the virtualization node on which a virtualization unit must be added or removed during such operations.

[0104] The improvements associated with the embodiments described above are effective as long as the virtualization units of a protection scheme are deployed on homogeneous virtualization nodes, i.e. having substantially equivalent technical characteristics. Indeed, an N:B protection scheme makes it possible to withstand 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 cheaper to purchase identical equipment in large quantities than to purchase equipment with varied technical characteristics in smaller quantities).

[0105] In certain situations, however, it may happen that the servers used for the implementation of a virtualization infrastructure are not all identical in terms of technical characteristics (for example, in the case of reuse in a data center of computer servers of various origins, for example from platforms dismantled before the end of the support period guaranteed by the vendors of these computer servers). In any event, such situations are likely to be increasingly frequent, in a global context of imperative resource savings where incentives to reuse existing devices in “second life” operations rather than to acquire new ones tend to multiply. The virtualization nodes on which the virtualization units are likely to be instantiated then exploit processors which potentially have different processing capacities.

[0106] It is therefore proposed, in one embodiment of the present technique, to take into account at least one technical characteristic associated with the available virtualization nodes, when selecting a virtualization node within which a virtualization unit is added or removed in response to an automatic scaling decision.

[0107] In one embodiment, said technical characteristic is the operating clock frequency of said virtualization nodes, potentially different from one node to another.

[0108] To facilitate understanding of the problem that arises in the presence of nodes with heterogeneous technical characteristics and the proposed solution, we describe below, in relation to [Fig.7], the known sequence which allows, within the framework of a classic Kubemetes architecture, to reserve for each virtualization unit the “requests” processing capacity already introduced in relation to the prior art, expressed in CPU portion. We can consider that such processing capacity corresponds to a fraction of time, or even to a fraction of the number of clock cycles reservable per unit of time.

[0109] In a preliminary step 71, upon its enrollment 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.

[0110] Subsequently, when a scale out decision is taken by the scaling module Mod_ME, the latter transmits, in a step 72, a request for instantiation of a new virtualization unit to an installation module Mod_INS.

[0111] The Mod_INS installation module then determines the required processing capacity “requests” 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 73, to reserve these resources in the best possible node.

[0112] To this end, the orchestration module Mod_ORC ​​preselects (filtering) the nodes having sufficient capacity not yet reserved by other virtualization units already installed within them, by comparing the required processing capacity (requests) with the available processing capacity within the different virtualization nodes (for example, "Available CPU _i" for node i). The orchestration module Mod_ORC ​​then performs a ranking (scoring) of the preselected nodes according to multiple criteria, such as the load rate for example, which allows it to determine the best node for instantiating the new virtualization unit, and to reserve there, in a step 74, the quantity (requests) of CPU required for this virtualization unit (in the example of [Fig. 7], it is considered that node i is thus chosen, and the orchestration module Mod_ORC ​​therefore removes the quantity (requests) from the available processing capacity for this node).

[0113] 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.

[0114] In the case of a virtualization infrastructure comprising virtualization nodes associated with processors of different technical characteristics, 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. As a result, 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 load PLmax_i and PLmax _J accepted respectively by each of these two virtualization units are also different, which poses a problem in defining the PLmax parameter to be provided as input to the scaling module (this PLmax parameter 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.

[0115] Additional modifications to the Kubemetes architecture are therefore proposed in a particular embodiment of the present technique, so that the improvements previously proposed within the framework of the present technique with regard to the optimization of energy performance are also compatible with virtualization infrastructures comprising processors of different technical characteristics.

[0116] These modifications, complementary to the previous proposed modifications, are presented in relation to [Fig.8], and consist of adaptations of the sequence of reservation of processing capacity of the virtualization units.

[0117] More specifically, [Fig.8] repeats 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 introduce a normalization factor.

[0118] First, a predetermined "Clk_ref" parameter is defined at the orchestration module level, to serve as a reference clock frequency to compare the nominal clock frequencies of the different virtualization nodes.

[0119] In a preliminary step 81, during the step 71 of enrollment of the [Fig.7] , each virtualization node (for example 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 reservation of processing time on node i, this total CPU processing capacity “total_CPU_i” corresponds to an available processing capacity “Available _CPU _i” on the node.

[0120] Subsequently, when a scale out decision is taken by the scaling module Mod_ME, the latter transmits, in a step 82 similar to step 72 previously described in relation to [Fig.7], a request for instantiation of a new virtualization unit to the installation module Mod_INS.

[0121] As in step 73 previously described in relation to [Fig.7], the installation module Mod_INS then 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.

[0122] However, unlike the process illustrated in [Fig.7], the orchestration module Mod_ORC ​​performs filtering of the nodes by comparing not the required processing capacity "requests" with the available processing capacity at the within the different virtualization nodes (for example "Available _CPU_i" for node i), but at a standardized 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. Unlike step 74 previously described in relation to [Fig. 7], 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], we consider 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).

[0123] 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 next step. On the basis of this information, in a step 86 during step 76 of [Fig. 7], 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.

[0124] In other words, at each step, 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].

[0125] This normalization has the effect that the maximum service loads PLmax_i and PLmax _J admissible respectively by each of two virtualization units i and j deployed on virtualization nodes i and j operating at different nominal clock frequencies “Clk_i” and “Clk_j” remain identical, and consistent with respect to the PLmax value provided by configuration to the scaling module, as illustrated in relation to [Fig.9].

[0126] In this way, the improvements proposed within the framework of the present technique for improving the energetic performance of scaling operations can be implemented not only on virtualization infrastructures based on equipment with similar technical characteristics, but also on virtualization infrastructures comprising equipment with heterogeneous technical characteristics.

[0127] Of course, although presented in relation to a scale out operation, the The normalization principle described in relation to [Fig.9] is also applied in the context of a scale-in operation, when determining which virtualization node to remove a virtualization unit from.

[0128] According to another aspect, 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. Such 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 according to:.

[0129] - the number B of backup virtualization units defined in said protection scheme;

[0130] - a comparison between a total service load reached SL and a maximum service load PLmax authorized per virtualization unit of said set.

[0131] As illustrated in [Fig.9], 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 one of its embodiments, with the same advantages.

[0132] [Fig. 10] represents, in a schematic and simplified manner, 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.

[0133] Thus, these structural elements are used by the different modules previously described, in order to optimize the energy performance of a Kubemetes architecture.

[0134] At initialization, 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. For the implementation of the operations performed by a module of scaling, the processing unit 12 receives for example at 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 from a probe module, representative of a total service load reached SL measured by the probe module.

[0135] The microprocessor of the processing unit 12 then carries out the steps of the method for adapting the sizing 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.

Claims

Claims

1. Method 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, 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 as a function of: - 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. 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. Method according to claim 1, characterized in that said service load PL maxmaximum authorized 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. Method according to claim 1, characterized in that said service load PL mœi maximum allowed 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. 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 of a service request on said at least one virtualization unit.

6. 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. 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. 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. 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. 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. 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 (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. 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 executing a method according to any one of claims 1 to 10, when executed by a computer.

Images